SharePoint Foundation 2010
See Also

Published: May 12, 2010

Explore these links to find out more about implementing Microsoft SharePoint Foundation 2010.

SharePoint Foundation 2010 is a versatile technology that organizations and business units of all sizes can use to increase the efficiency of business processes and improve team productivity. With tools for collaboration that help people stay connected across organizational and geographic boundaries, SharePoint Foundation 2010 gives people access to information they need.

Sites based on SharePoint Foundation 2010, called SharePoint sites, take file storage to a new level, providing communities for team collaboration that make it possible for users to collaborate on documents, tasks, and events, and make it easier for them to share contacts and other information. SharePoint Foundation 2010 enables managers of teams and sites to manage site content and user activity easily.

SharePoint Foundation 2010 also provides a foundation platform for building Web-based business applications that can flex and scale easily to meet the changing and growing needs of your business. Robust administrative controls for managing storage and Web infrastructure give IT departments a cost-effective way to implement and manage a high-performance collaboration environment.

SharePoint logo

Newly Published Content

See the following pages for new or updated content about SharePoint Foundation 2010:

  • Newly published content for SharePoint Foundation 2010

SharePoint logo

Documentation

The TechNet library contains articles that describe how to plan for, deploy, and use all the features of SharePoint Foundation 2010.

  • Newly published content for SharePoint Foundation 2010

  • Roadmap to SharePoint Foundation 2010 content

  • Downloadable content for SharePoint Foundation 2010

  • Product evaluation for SharePoint Foundation 2010

  • Getting started with SharePoint Foundation 2010

  • Planning and architecture for SharePoint Foundation 2010

  • Development for SharePoint Foundation 2010

  • Deployment for SharePoint Foundation 2010

  • Operations for SharePoint Foundation 2010

  • Security and protection for SharePoint Foundation 2010

  • Troubleshooting (SharePoint Foundation 2010)

  • Technical reference for SharePoint Foundation 2010

Related products:

  • Office Web Apps (Installed on SharePoint 2010 Products)

  • Search Server 2010

Legacy content:

  • Windows SharePoint Services 3.0

  • Windows SharePoint Services 2.0

TechNet logo

TechNet TechCenter

Visit the following site to access videos, community sites, documentation, and more.

  • Microsoft SharePoint Foundation 2010

Code

Downloads & Scripts

Access the following pages for both downloadable content and Windows PowerShell scripts:

  • Downloadable content for SharePoint Foundation 2010

  • Script Repository: Windows PowerShell for SharePoint 2010 Products

Blogs

Blogs

Check out the latest posts from the SharePoint Products documentation teams.

  • To the SharePoint

  • Get the Point

Forums

Forums & Newsgroups

Got questions? Talk to your peers, MVPs, and the SharePoint product teams.

  • General Questions and Answers

  • SharePoint 2010 - Setup, Upgrade, Administration and Operation

Stay Connected

Keep connected with the latest happenings with SharePoint Foundation 2010.

  • Follow us on Twitter

  • RSS feed for SharePoint Foundation 2010

Chat

Provide Feedback

Provide feedback about the documentation for SharePoint Foundation 2010 depending on the TechNet view, as follows:

  • Classic View. Use the Click to Rate and Give Feedback link at the top of the article in the TechNet Library. This delivers your feedback directly to the documentation team.

  • Lightweight View. Click the Feedback link at the bottom of the page. This delivers your feedback directly to the documentation team.

  • Scriptfree View. Click the Feedback link at the top of the article in the TechNet Library. This enables you to provide feedback about the scriptfree view to a forum.

To suggest content or request more documentation (or report an error), please contact us at ITSPDOCS@microsoft.com.

See Also

Other Resources

SharePoint Developer Center (MSDN)


Newly published content for SharePoint Foundation 2010

Published: 2009/12Dec/17

This article contains a list of new or updated content for Microsoft SharePoint Foundation 2010. This article is updated regularly.

In this article:

August 19, 2013 | March 11, 2013 | September 10, 2012 | August 20, 2012 | June 11, 2012 | May 28, 2012 | May 21, 2012 | May 1, 2012 | April 16, 2012 | April 2, 2012 | February 20, 2012 | February 13, 2012 |February 6, 2012 | January 16, 2012 | January 9, 2012 | January 2, 2012 | December 12, 2011 | December 5, 2011 | November 14, 2011 | October 17, 2011 | September 11, 2011 | September 5, 2011 | August 22, 2011 | August 8, 2011 | July 25, 2011 | July 11, 2011 │ July 4, 2011 | June 27, 2011 │ June 13, 2011 │ June 6, 2011 │ May 23, 2011 │ May 9, 2011 │ April 25, 2011 │ April 18, 2011 │ April 4, 2011 │ March 28, 2011 │ March 21, 2011 │ March 14, 2011 | March 7, 2011 │ February 28, 2011 │ February 21, 2011 │ February 7, 2011 │ January 31, 2011 │ January 24, 2011 │ January 17, 2011 │ January 10, 2011 │ December 13, 2010 │ December 6, 2010

Published the week of August 19, 2013

Updated article

Plan browser support (SharePoint Foundation 2010) Updated the statement about Firefox support.

Published the week of March 11, 2013

Updated article

Update alerts by using Windows PowerShell (SharePoint Foundation 2010) Updated the parameters of the Invoke-AlertFixup command.

Published the week of September 10, 2012

Updated article

Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010) Updated several code samples.

Published the week of August 20, 2012

Updated article

Content type and workflow planning (SharePoint Foundation 2010) Added links to newly-published white paper about changing core content types.

Published the week of June 11, 2012

New article

Support and licensing for Windows Azure (SharePoint Foundation 2010) Describes required information about deploying SharePoint 2010 Products on Windows Azure.

Published the week of May 28, 2012

Updated article

The Security Token Service is not available (SharePoint Foundation 2010) Added a new resolution: Install the missing assemblies into the global assembly cache manually.

Published the week of May 21, 2012

Updated article

Plan browser support (SharePoint Foundation 2010) Added mobile browser support matrix.

Published the week of May 1, 2012

Updated article

Plan browser support (SharePoint Foundation 2010) Added Windows XP to the list of supported operating systems for Internet Explorer.

Published the week of April 16, 2012

Updated article

Configure People Picker (SharePoint Foundation 2010) Updated information about restricting People Picker to search only users within a particular organizational unit (OU). Only a single site user directory path can be set at a time for a site collection.

Published the week of April 2, 2012

Updated articles

Databases require upgrade or not supported (SharePoint Foundation 2010) and Databases running in compatibility range, upgrade recommended (SharePoint Foundation 2010) Updated the Resolution to: Upgrade databases to SQL Server 2008 R2.

Plan browser support (SharePoint Foundation 2010) Updated the browser support matrix.

Published the week of February 20, 2012

Updated article

Upgrade-SPContentDatabase Updated the description of this cmdlet.

Published the week of February 13, 2012

Updated article

Timer job reference (SharePoint Foundation 2010) Added text indicating that timer job schedules may change when SharePoint Foundation service packs or cumulative updates are installed.

Published the week of February 6, 2012

Updated articles

Plan authentication methods (SharePoint Foundation 2010) Clarified why you would choose to implement each of the supported authentication methods and authentication modes.

Security and protection for SharePoint Foundation 2010 Updated to include information about Federal Information Security Management Act (FISMA) certification.

Published the week of January 16, 2012

Updated article

Update alerts by using Windows PowerShell (SharePoint Foundation 2010) Revised the procedure by adding a step for dot sourcing to run the script.

Published the week of January 9, 2012

New article

Understanding the Logging Database (SharePoint Foundation 2010) Describes the Microsoft SharePoint 2010 Products logging database, how to view monitoring information, and how to export monitoring information into Microsoft Excel.

Published the week of January 2, 2012

Updated article

Manage permission policies for a Web application (SharePoint Foundation 2010) Updated information about the maximum number of site collections per Web application.

Published the week of December 12, 2011

New article

Plan for claims-based authentication or classic-mode authentication (SharePoint Foundation 2010) Provides guidance about whether to use claims-based authentication or classic-mode authentication when you create a SharePoint Foundation 2010 Web application.

Updated article

Plan authentication methods (SharePoint Foundation 2010) Updated to clarify that you have to set network load balancing to single affinity when using claims-based authentication.

Published the week of December 5, 2011

New article

Some content databases are growing too large (SharePoint Foundation 2010) Describes how to resolve the SharePoint Health Analyzer event by editing the rule definition to prevent new sites from being added to the databases, and then moving some site collections to other databases.

Published the week of November 14, 2011

New articles

Database has large amounts of unused space (SharePoint Foundation 2010) Describes how to resolve the SharePoint Health Analyzer event by shrinking the database.

Databases exist on servers running SharePoint Foundation (SharePoint Foundation 2010) Describes how to resolve the SharePoint Health Analyzer event by moving the databases to a separate server.

Databases require upgrade or not supported (SharePoint Foundation 2010) Describes how to resolve the SharePoint Health Analyzer event by installing software updates.

Databases running in compatibility range, upgrade recommended (SharePoint Foundation 2010) Describes how to resolve the SharePoint Health Analyzer event by installing software updates.

Databases used by SharePoint have outdated index statistics (SharePoint Foundation 2010) Describes how to resolve the SharePoint Health Analyzer event by editing the rule definition so that the configuration is automatically repaired.

Databases within this farm are set to read only and will fail to upgrade unless it is set to a read-write state (SharePoint Foundation 2010) Describes how to resolve the SharePoint Health Analyzer event by setting the databases to read-write.

Drives used for SQL databases are running out of free space (SharePoint Foundation 2010) Describes how to resolve the SharePoint Health Analyzer event by freeing disk space on the database server computer or decreasing the number of days to store log files.

One or more servers is not responding (SharePoint Foundation 2010) Describes how to resolve the SharePoint Health Analyzer event by connecting the server to the network, restarting the SharePoint 2010 Timer service (SPTimerV4), or removing the server record from the SharePoint topology.

The Application Discovery and Load Balancer Service is not running in this farm (SharePoint Foundation 2010) Describes how to resolve the SharePoint Health Analyzer event by starting the Application Discovery and Load Balancer service on at least one server in the farm.

The local machine is not joined to a SharePoint server farm (SharePoint Foundation 2010) Describes how to resolve the SharePoint Health Analyzer event by creating a new farm or adding this computer to an existing farm.

The Security Token Service is not available (SharePoint Foundation 2010) Describes how to resolve the SharePoint Health Analyzer event by restarting the Security Token Service application pool.

The timer service failed to recycle (SharePoint Foundation 2010) Describes how to resolve the SharePoint Health Analyzer event by changing the schedule for the Timer Service Recycle job so that it does not conflict with other long-running timer jobs.

Web.config files are not identical on all machines in the farm (SharePoint Foundation 2010) Describes how to resolve the SharePoint Health Analyzer event by making the Web.config files identical on all front-end Web servers in the farm.

Published the week of October 17, 2011

New article

Configure Information Rights Management (SharePoint Foundation 2010) Describes how to configure Information Rights Management (IRM) in SharePoint Foundation 2010 and how to implement a Windows Rights Management Services (RMS) server.

Updated article

Install and configure RBS (SharePoint Foundation 2010) Corrected the msiexec syntax for installing the RBS client library on all additional Web and application servers.

Published the week of September 12, 2011

Updated article

Automatic update setting inconsistent across farm servers (SharePoint Foundation 2010) Added permissions information.

Published the week of September 5, 2011

New articles

Alternate access URLs have not been configured (SharePoint Foundation 2010) Describes how to resolve the SharePoint Health Analyzer event by changing the default zone URL.

Plan for administrative and service accounts (SharePoint Foundation 2010) Describes the accounts that you must plan for and describes the deployment scenarios that affect account requirements for SharePoint 2010 Products.

Product / patch installation or server upgrade required (SharePoint Foundation 2010) Describes how to resolve the SharePoint Health Analyzer event by deploying updates or upgrading.

Web.config file has incorrect settings for the requestFiltering element (SharePoint Foundation 2010) Describes how to resolve the SharePoint Health Analyzer event by changing the requestFiltering settings in the Web.config file.

Updated article

How to configure AD FS v 2.0 in SharePoint Foundation 2010 Added link to a video that illustrates procedures in this article.

Plan browser support (SharePoint Foundation 2010) Added a list of supported mobile browsers and a change to the guidance for Safari 4.04 on non-Windows operating systems.

Published the week of August 22, 2011

New article

Application pools recycle when memory limits are exceeded (SharePoint Foundation 2010) Describes how to change the application pool recycling settings in Internet Information Services (IIS).

Published the week of August 8, 2011

New article

Accounts used by application pools or service identities are in the local machine Administrators group (SharePoint Foundation 2010) Describes how to resolve the SharePoint Health Analyzer event by changing the user account to a predefined account, or to a domain user account that is not a member of the Administrators group.

Plan administrative tasks in a least-privilege environment (SharePoint Foundation 2010) Describes how to configure and maintain a Microsoft SharePoint Foundation 2010 environment by using least-privilege administration.

Updated articles

Plan for backup and recovery (SharePoint Foundation 2010), Prepare to back up and recover (SharePoint Foundation 2010), Recover content from an unattached content database (SharePoint Foundation 2010), Restore a site collection (SharePoint Foundation 2010), and Restore-SPSite Added a note about restoring a backup that you made before the farm was upgraded to SP1 to the farm after it is upgraded to SP1.

Restore pre-SP1 backups to an SP1 farm (SharePoint Foundation 2010) Provides information and procedures for restoring a backup that you made before the farm was upgraded to SP1 to the farm after it is upgraded to SP1.

Published the week of July 25, 2011

New article

Overview of security features in SharePoint Foundation 2010 Explains the security features that are available in SharePoint Foundation 2010.

Updated articles

New-SPUser Changed one of the values of the Permission Level parameter from Full to Full Control.

Plan for backup and recovery (SharePoint Foundation 2010) Corrected the upper size limit for performing a site collection backup from 85 GB to 100 GB.

Plan for disaster recovery (SharePoint Foundation 2010) Corrected information about the Application Registry service application.

Published the week of July 11, 2011

New article

Database attach upgrade video (SharePoint Foundation 2010) New videos available showing database attach upgrade process.

Updated articles

Back up a site collection (SharePoint Foundation 2010) Removed warning about UseSqlSnapshot parameter. This warning is not valid for Service Pack 1 and newer.

Configure Basic authentication for a claims-based Web application (SharePoint Foundation 2010), Configure Basic authentication for a classic-mode Web application (SharePoint Foundation 2010), Configure Digest authentication for a claims-based Web application (SharePoint Foundation 2010), and Configure Digest authentication for a classic-mode Web application (SharePoint Foundation 2010) Updated the IIS configuration procedure.

Plan for RBS (SharePoint Foundation 2010) Added note about the 200GB limit for RBS-enabled content databases. Removed the "Alternatives to using RBS" section.

Published the week of July 4, 2011

New articles

Best practices for operational excellence (SharePoint Foundation 2010) New article with best practices for keeping Microsoft SharePoint Foundation 2010 working well operationally.

Managing Multi-Terabyte Content Databases with SharePoint 2010 (white paper) Provides guidance and procedures for administering content databases in three size ranges: up to 200 gigabytes (GB), 200 GB-4 terabytes (TB), and larger than 4 TB.

Scale out collaboration sites (SharePoint Foundation 2010) Provides guidance and procedures for scaling out collaboration sites that are larger than 200 GB when you are using Remote BLOB Storage.

Updated articles

Attach databases and upgrade to SharePoint Foundation 2010 Updated with steps to set read-only databases back to read-write.

Checklist for database attach upgrade (SharePoint Foundation 2010) Updated with steps to set read-only databases back to read-write.

Published the week of June 27, 2011

New for SharePoint Foundation 2010 SP1

Service Pack 1 (SP1) for SharePoint Foundation 2010 (white paper) Describes the features that are included in Microsoft SharePoint Foundation 2010 Service Pack 1 (SP1) and provides guidelines to help ensure your solutions work with current and future releases of SharePoint Foundation 2010.

Restore a deleted site (SharePoint Foundation 2010), Restore a deleted site collection (SharePoint Foundation 2010), Get-SPDeletedSite, Remove-SPDeletedSite, and Restore-SPDeletedSite These articles describe functionality available in SharePoint Foundation 2010 SP1 to enable an administrator to restore a deleted site or site collection.

Updated for SharePoint Foundation 2010 SP1

Move-SPSite Updated to document the RbsProviderMapping parameter, which was added in SharePoint Foundation 2010 Service Pack 1 (SP1).

New articles

Claims-based authentication with Microsoft UAG 2010 (SharePoint Foundation 2010) Describes how to authenticate users from a partner organization through a server that is running Microsoft Forefront Unified Access Gateway (UAG) to a server that is running SharePoint Foundation.

Allow or prevent Contributors ability to edit scriptable Web Parts (SharePoint Foundation 2010) Describes how to allow Contributors to edit scriptable Web Parts.

Contribute permission level overview (SharePoint Foundation 2010) Explains the tasks that users who have the Contribute permission level can complete.

Remote BLOB Storage in SharePoint Foundation 2010 (video) Explains the basic concepts of Remote BLOB Storage (RBS) in SharePoint Foundation 2010.

Updated articles

Downloadable content for SharePoint Foundation 2010 Added eReader formats available for the downloadable book, Getting started with SharePoint Foundation 2010.

Published the week of June 13, 2011

New articles

Best practices for virtualization (SharePoint Foundation 2010) Provides best practice guidance for deploying and operating SharePoint Foundation 2010 in a virtual environment.

Recover content from an unattached content database (SharePoint Foundation 2010) Provides information about how you can restore or copy content — such as sites, site collections, lists, or document libraries — from a content database without having to attach the content database to the farm.

Updated articles

Plan for Kerberos authentication (SharePoint Foundation 2010) Added guidance about planning for SharePoint Foundation 2010 deployments that require Kerberos authentication for security, client identity delegation, and low network traffic.

Plan for backup and recovery (SharePoint Foundation 2010) Corrected information about Data Protection Manager. You cannot use Data Protection Manager to back up or restore RBS by using the FILESTREAM provider.

Published the week of June 6, 2011

New articles

Configure resource points for sandboxed solutions (SharePoint Foundation 2010) Describes how to use Windows PowerShell to configure resource points to restrict the resources consumed by sandboxed solutions.

Configure sandboxed solutions service tiers (SharePoint Foundation 2010) Describes how to improve the performance, security, and reliability of your sandboxed solutions by configuring tiers for the sandboxed solutions service.

Updated articles

Plan sandboxed solutions (SharePoint Foundation 2010) Added a section about how to plan sandboxed solutions service tiers, and updated information about planning resource usage quotas for sandboxed solutions.

Sandboxed solutions overview (SharePoint Foundation 2010) Added descriptions of tiers, quotas, and resource points, and added an illustration of tiers within the sandboxed solutions service.

Install and configure RBS (SharePoint Foundation 2010) Revised BLOB store provisioning syntax, revised Remote BLOB Store (RBS) installation syntax, added details to procedures, and reorganized the article.

Overview of RBS (SharePoint Foundation 2010) Added information about RBS components.

Plan for RBS (SharePoint Foundation 2010) Added information about the limits of RBS.

Published the week of May 23, 2011

New resource center

Operations and Manageability for SharePoint Foundation 2010 Find resources to learn about operations and manageability in SharePoint Foundation 2010 in two areas: server and farms, and services and solutions.

New articles

Design sample: collaboration sites (SharePoint Foundation 2010) Describes a practical implementation of logical architecture components to achieve a workable design.

Logical architecture components (SharePoint Foundation 2010) Discusses the planning considerations for each of the logical architecture elements that make up a solution design.

Best practices for extranet environments (SharePoint Foundation 2010) Describes planning and design recommendations for extranet environments in which users outside the internal network are given access to sites.

One or more categories are configured with verbose trace logging setting Provides information about this SharePoint Health Analyzer rule. The article describes the cause and includes a procedure that helps to ensure that diagnostic logging settings are configured correctly.

Identify users and analyze document usage (SharePoint Foundation 2010) Describes how to analyze the way people in your organization create and use documents to help you structure your document libraries and sites.

Document management overview (SharePoint Foundation 2010) Describes the document management planning process.

Updated articles

Manage site collection storage limits (SharePoint Foundation 2010) Added steps to configure settings for sandboxed solutions.

Resume upgrade (SharePoint Foundation 2010) Clarified a parameter for the passphrase for resuming an in-place upgrade.

Published the week of May 9, 2011

New articles

StorSimple RBS performance in SharePoint 2010 (white paper) Explains the Remote BLOB Storage (RBS) feature and analyzes how its performance affects key attributes of a SharePoint farm, such as database size, database backup size, transaction response times, and backup and restore times.

Database maintenance for SharePoint Foundation 2010 Provides information and guidelines for how to maintain the databases that host data and configurations for Microsoft SharePoint 2010 Products.

Updated articles

Sites and site collections overview (SharePoint Foundation 2010) Clarified guidance for how to choose a search template.

Maintain RBS (SharePoint Foundation 2010) Revised the "Running the RBS Maintainer" section.

Published the week of April 25, 2011

New article

Regional settings (SharePoint Foundation 2010) Lists the regional settings for SharePoint Foundation 2010: locale, time zone, sort order, calendar, and currency.

Updated articles

Plan for RBS (SharePoint Foundation 2010) Updated with information about alternatives to RBS and the costs and benefits of using RBS.

Overview of RBS (SharePoint Foundation 2010) Updated with additional information about RBS providers.

Published the week of April 18, 2011

New article

Building Windows Phone 7 applications with SharePoint 2010 Products and Unified Access Gateway (UAG): white paper Contains information for administrators and developers to understand how to develop and configure Windows Phone 7 applications to work with Microsoft SharePoint 2010 Products and Microsoft Forefront Unified Gateway Access (UAG).

Published the week of April 4, 2011

Updated article

Plan browser support (SharePoint Foundation 2010) Added information about support for Internet Explorer 9.

Published the week of March 28, 2011

New article

Health monitoring cmdlets (SharePoint Foundation 2010) Describes the health monitoring Windows PowerShell cmdlets introduced in the February 2011 Cumulative Update.

Updated article

Hardware and software requirements (SharePoint Foundation 2010) Added Windows Server 2008 R2 Service Pack 1 (SP1) to the list of minimum requirements.

Published the week of March 21, 2011

New article

Mobile device troubleshooting (SharePoint Foundation 2010) Contains information for troubleshooting mobile device issues.

Updated article

Harden SQL Server for SharePoint environments (SharePoint Foundation 2010) Updated with information about Windows Firewall with Advanced Security.

Published the week of March 14, 2011

Updated article

Move site collections between databases (SharePoint Foundation 2010) Added a note about the implications of auditing data during the site collection move.

Published the week of March 7, 2011

New article

Configure Client Certificate Authentication (SharePoint Foundation 2010) Describes how to configure client certificate authentication for SharePoint Foundation 2010.

Updated articles

Add-SPShellAdmin Updated to advise that this cmdlet is intended only for use with a database that uses Windows authentication.

SharePoint 2010 Products administration by using Windows PowerShell Added a section about scripts and execution policies.

Virtualization support and licensing (SharePoint Foundation 2010) Updated to clarify support and licencing requirements for virtualized farm servers.

Published the week of February 28, 2011

Updated article

Plan for disaster recovery (SharePoint Foundation 2010) Updated to clarify that asynchronous mirroring or log shipping is not supported for the Business Data Connectivity database.

Published the week of February 21, 2011

New article

Plan for mobile devices (SharePoint Foundation 2010) Describes the features that enable users to work with content in SharePoint Foundation 2010 by using their mobile devices. It also summarizes important questions to consider when you deploy these features.

Published the week of February 7, 2011

Updated article

Plan sandboxed solutions (SharePoint Foundation 2010) Changed Resources per Point and Absolute Limit for InvocationCount resource from <TBD> to 100.

Published the week of January 31, 2011

New articles

People Picker and claims provider planning (SharePoint Foundation 2010) Describes the People Picker control and how it works, its relationship to authentication and claims providers, and includes considerations for planning for People Picker. This section includes the following articles:

  • People Picker overview (SharePoint Foundation 2010)

  • Custom claims providers for People Picker (SharePoint Foundation 2010)

Configure People Picker (SharePoint Foundation 2010) and Peoplepicker-peopleeditoronlyresolvewithinsitecollection: Stsadm property (SharePoint Foundation 2010) Describe how to configure the People Picker control to filter and restrict the results that are displayed when a user searches for a user, group, or claim.

Published the week of January 24, 2011

New article

Configure Basic authentication for a classic-mode Web application (SharePoint Foundation 2010) Describes how to configure Basic authentication for a SharePoint Foundation 2010 classic-mode Web application.

Updated articles

Services architecture planning (SharePoint Foundation 2010) Updated with information about how to implement cross-farm service applications.

Published the week of January 17, 2011

New articles

Configure Basic authentication for a claims-based Web application (SharePoint Foundation 2010) Describes how to configure Basic authentication for a SharePoint Foundation 2010 claims-based Web application.

Configure Digest authentication for a claims-based Web application (SharePoint Foundation 2010) Describes how to configure Digest authentication for a SharePoint Foundation 2010 claims-based Web application.

Configure Digest authentication for a classic-mode Web application (SharePoint Foundation 2010) Describes how to configure Digest authentication for a SharePoint Foundation 2010 classic-mode Web application.

Updated articles

Configure external access for mobile devices (SharePoint Foundation 2010) Updated information about how to configure Forefront Unified Access Gateway to support Microsoft SharePoint Workspace Mobile 2010.

Configure mobile views (SharePoint Foundation 2010) Added procedures for changing the redirect behavior of a mobile browser or adding a supported mobile device by modifying the compat.browser file.

Install a software update (SharePoint Foundation 2010) Adjusted steps and diagrams for in-place update processes.

Restore a Web application (SharePoint Foundation 2010) Added content about object cache user account settings and updated SQL Server procedures.

Published the week of January 10, 2011

New article

Microsoft Press: Using Windows PowerShell to Perform and Automate Farm Administrative Tasks Provides an excerpt from "Microsoft SharePoint 2010 Administrator's Companion" that explores the SharePoint 2010 Management Shell and how to use Windows PowerShell to accomplish some basic administrative tasks.

Updated article

Multilingual user interface overview (SharePoint Foundation 2010) Updated the limitations section with information about shared components and site templates that are not enabled for the multilingual user interface.

Published the week of December 13, 2010

New article

Migrate a farm deployed on a failover cluster environment (SharePoint Foundation 2010) Provides guidance for the migration of a farm that is hosted on a failover cluster to another cluster.

Updated article

Deploy language packs (SharePoint Foundation 2010) Added a note that you must deactivate and then reactivate any language-specific features before you use the new language pack.

Published the week of December 6, 2010

New downloadable content

Visio stencils for architecture and planning posters Download the stencils the SharePoint Content Publishing team used for their technical diagrams to create or customize diagrams for your organization.


Roadmap to SharePoint Foundation 2010 content

This article describes the content available for IT professionals to assist you when you are planning, deploying, administering, and troubleshooting SharePoint Foundation 2010.

For SharePoint Foundation 2010 developer content, see the SharePoint Developer Center (http://go.microsoft.com/fwlink/p/?LinkId=159918).

Content resources

The SharePoint Foundation 2010 TechCenter (http://go.microsoft.com/fwlink/p/?LinkId=188950) is your primary gateway to in-depth technical information about SharePoint Foundation 2010. Through the TechCenter, you can access the following:

  • SharePoint Foundation 2010 Resource Centers (http://go.microsoft.com/fwlink/p/?LinkId=188951) Resource centers provide specific links to more information specific to a particular feature of SharePoint Foundation 2010. You can find resource centers for features such as installation and deployment, Business Connectivity Services, enterprise content management, and enterprise search, to name a few.

  • SharePoint Foundation 2010 Downloads (http://go.microsoft.com/fwlink/p/?LinkId=188952) Go to this page to download service packs, add-ins, tools, and trial software to help you optimize your SharePoint Foundation organization.

  • SharePoint Foundation 2010 library The library contains the most up-to-date IT pro content. This content is reviewed and approved by the SharePoint Foundation product team and will evolve over the life cycle of SharePoint Foundation 2010. Also make sure that you check out Newly published content for SharePoint Foundation 2010 in the library. This article contains a list of new or updated library content and is also available as an RSS feed. (http://go.microsoft.com/fwlink/p/?LinkId=188953). It is updated whenever a new article is published or an existing article is updated.

  • SharePoint Foundation 2010 support (http://go.microsoft.com/fwlink/p/?LinkId=188954) Locate support and troubleshooting resources for SharePoint Foundation. You can search the Microsoft Knowledge Base, TechNet, or blogs for additional help.

Offline resources

If you are working offline and need access to library articles, the following option is available to you:

  • SharePoint Foundation 2010 Technical Library in Compiled Help format (http://go.microsoft.com/fwlink/p/?LinkId=188955) This downloadable .chm file is updated monthly and includes all articles published to the library as of the .chm file's release date.

Additional resources

The following visual resources supplement the library articles and can assist you when you plan your projects:

  • Technical diagrams (SharePoint Foundation 2010) These poster-size models provide a visual representation of recommended solutions and correspond to various articles in the library. You can modify these models by using Microsoft Office Visio 2007 to reflect your plans for SharePoint Foundation and how it will fit into your own environment.

Community resources

You can use the community resources to learn more about SharePoint Foundation 2010 and to foster discussion, ask questions, and exchange ideas about your experiences with SharePoint Foundation 2010:

  • Microsoft SharePoint Team Blog (http://go.microsoft.com/fwlink/p/?LinkID=82560) This is the official blog of the SharePoint product group. It includes articles written by members of the product team, and product announcements and updates.

  • To The SharePoint (http://go.microsoft.com/fwlink/p/?LinkId=188956) This is the IT pro documentation team blog. This blog includes documentation highlights and announcements for SharePoint Foundation 2010.

  • SharePoint 2010 forums (http://go.microsoft.com/fwlink/p/?LinkId=188957) The forum provides a place for users and SharePoint Foundation product team members to discuss the product.


Downloadable content for SharePoint Foundation 2010

The content in this technical library is augmented by content available for download. You can download a copy of the entire Microsoft SharePoint Foundation 2010 TechNet library as a compiled help (.chm) file, or review the following table for a list of downloadable books, posters, and white papers. Some of the books are also available for sale from Amazon.com.

Content Description

Technical diagrams (SharePoint Foundation 2010)

Poster-sized illustrations of Microsoft SharePoint Foundation 2010 architecture and concepts.

Downloadable book: Getting started with SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=191145)

Getting started with SharePoint Foundation 2010 from Amazon.com (http://go.microsoft.com/fwlink/p/?LinkId=229276)

Downloadable and printable content that contains information about the capabilities of and requirements for SharePoint Foundation 2010. (Available in .doc, .pdf, or .xps file formats, and also in .epub or .mobi file formats for eReader devices.)

Downloadable book: Planning guide for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=196218)

Planning guide for SharePoint Foundation 2010 from Amazon.com (http://go.microsoft.com/fwlink/p/?LinkId=229272)

Downloadable and printable content that contains information about how to plan a deployment of SharePoint Foundation 2010. (Available in .doc, .pdf, or .xps file formats.)

Downloadable book: Business continuity management for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=203471)

Business continuity management for SharePoint Foundation from Amazon.com (http://go.microsoft.com/fwlink/p/?LinkId=229275)

Downloadable and printable content that contains information about how to plan business continuity management (backup and restore, disaster recovery) for SharePoint Foundation 2010. (Available in .doc, .pdf, or .xps file formats.)

Downloadable book: Upgrading to SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=196159)

Downloadable and printable content that contains information about how to upgrade to SharePoint Foundation 2010. (Available in .doc, .pdf, or .xps file formats.)

Downloadable book: Deployment guide for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=190807)

Deployment guide for SharePoint Foundation 2010 from Amazon.com (http://go.microsoft.com/fwlink/p/?LinkId=229269)

Downloadable and printable content that contains information about how to deploy SharePoint Foundation 2010. (Available in .doc, .pdf, or .xps file formats.)

Downloadable book: Operations guide for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=196162)

Operations guide for SharePoint Foundation from Amazon.com (http://go.microsoft.com/fwlink/p/?LinkId=229271)

Downloadable and printable content that contains information about how to operate and maintain servers, server farms, sites, and solutions in SharePoint Foundation 2010. (Available in .doc, .pdf, or .xps file formats.)

Downloadable book: Remote BLOB storage for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=203468)

Remote BLOB storage for SharePoint Foundation from Amazon.com (http://go.microsoft.com/fwlink/p/?LinkId=229273)

Downloadable and printable content that contains information about how to use Remote BLOB Storage (RBS) to optimize database storage resources in SharePoint Foundation 2010. (Available in .doc, .pdf, or .xps file formats.)

Downloadable book: Technical reference for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=196294)

Downloadable and printable content that contains information about the SharePoint Foundation 2010 provider for Windows PowerShell and other helpful reference information about general settings, security, and tools. (Available in .doc, .pdf, or .xps file formats.)

Deploying Broadcast Slide Show on SharePoint Foundation 2010 (white paper)

Guide to installing and configuring this solution for broadcasting Microsoft PowerPoint slide shows.

Using AAM URL redirection as part of the upgrade process (SharePoint Foundation 2010) (white paper)

Describes the planning activities that you need to successfully deploy and use the alternate access mapping (AAM) URL redirection feature in Microsoft SharePoint Foundation 2010 to help mitigate downtime during a server computer or server farm upgrade.

Technical library in compiled Help format

The entire technical library for SharePoint Foundation 2010 on TechNet is available in a downloadable compiled Help (CHM) version.


Product evaluation for SharePoint Foundation 2010

This section provides information that helps IT professionals provide a business case for choosing Microsoft SharePoint Foundation 2010. It contains an overview of product features, product comparison information, system requirements, product evaluation kit, news and reviews, case studies, information on how to buy, virtual labs, and product roadmap.

In this section:

  • What's new in SharePoint Foundation 2010

  • Changes from Windows SharePoint Services 3.0 to SharePoint Foundation 2010

  • Hardware and software requirements (SharePoint Foundation 2010)

  • Plan browser support (SharePoint Foundation 2010)

  • Overview of security features in SharePoint Foundation 2010


What's new in SharePoint Foundation 2010

Microsoft SharePoint Foundation 2010 is the essential solution for organizations that need a secure, manageable, Web-based collaboration platform. It helps teams stay connected and productive by providing easy access to the people, documents, and information that they need to make well-informed decisions and get work done. To see what's new in SharePoint Foundation 2010, review the following:

  • What's New in Microsoft SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=188355) The TechNet Resource Center page points to articles and other resources to introduce you to new features such as Windows PowerShell, the new command-line interface and scripting language; health monitoring, an integrated health analysis tool (SharePoint Maintenance Manager) that enables SharePoint to automatically check for potential configuration, performance, and usage problems; and sandboxed solutions, a restricted execution environment that enables programs to access only certain resources and keep problems that occur in the sandbox from affecting the rest of the server environment.

  • SharePoint Foundation 2010 home page (http://go.microsoft.com/fwlink/p/?LinkId=188906) This site gives an overview of SharePoint Foundation 2010 and includes videos that demonstrate key features that can improve productivity, provide flexible deployment, and create a scalable, unified infrastructure.


Changes from Windows SharePoint Services 3.0 to SharePoint Foundation 2010

This article describes the features that have been deprecated or removed from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010. Deprecated features are provided in SharePoint Foundation 2010 for compatibility with previous product versions. These features will be removed in subsequent versions.

In this article:

  • Deprecated features

  • Features removed from SharePoint Foundation 2010

Deprecated features

The following feature is shipped with SharePoint Foundation 2010 but will be removed from subsequent versions.

Stsadm command-line tool

Description: The Stsadm command-line tool has been deprecated.

Reason for change: The Stsadm command-line tool will be superseded by Windows PowerShell 2.0.

Migration path: The Stsadm command-line tool is included to support compatibility with previous product versions. You should use Windows PowerShell 2.0 when performing command-line administrative tasks.

Features removed from SharePoint Foundation 2010

The following features and functionality are no longer available in SharePoint Foundation 2010.

32-bit operating systems

Description: SharePoint Foundation 2010 requires a 64-bit operating system. Running SharePoint Foundation 2010 on 32-bit operating systems is no longer supported.

Reason for change: SharePoint Foundation 2010 has numerous features that benefit from the performance provided by 64-bit operating systems.

Migration path: Install SharePoint Foundation 2010 on 64-bit operating systems.

Side-by-side installation

Description: The ability to perform side-by-side installation of Windows SharePoint Services 3.0 and SharePoint Foundation 2010 on the same server is being removed. This change is related to the removal of support for Gradual upgrade.

Reason for change: Compatibility and performance issues prevent side-by-side installation.

Migration path: Perform upgrade-in-place installation on the same hardware, or perform database attach to a new farm. Use new hardware if both Windows SharePoint Services 3.0 and SharePoint Foundation 2010 versions of a farm must exist at the same time.

For more information, see Perform a database attach upgrade to SharePoint Foundation 2010.

Gradual upgrade

Description: Support for the gradual upgrade feature is being removed as part of the removal of Side-by-side installation.

Reason for change: Compatibility and performance issues prevent side-by-side installation.

Migration path: Use the read-only database capability of Windows SharePoint Services 3.0 with the database attach upgrade capability of SharePoint Foundation 2010 to minimize downtime.

For more information, see Perform a database attach upgrade to SharePoint Foundation 2010.

For long upgrade periods where you must maintain both Windows SharePoint Services 3.0 and SharePoint Foundation 2010 versions of a farm, you can use the alternate access mapping (AAM) URL redirection capability provided in SharePoint Foundation 2010. Upgrades that use AAM URL redirection are performed by using database attach upgrade command-line operations instead of timer job-based events that are scheduled from the user interface (UI).

For more information, see Using AAM URL redirection as part of the upgrade process (SharePoint Foundation 2010) (white paper).

Web discussions

Description: Web discussions enable users to add comments about documents and pages without modifying their actual content. SharePoint Foundation 2010 does not support Web discussions.

Reason for change: This feature was deprecated in Windows SharePoint Services 3.0 because of its low adoption rate. The feature has now been removed from the product.

Migration path: This functionality is no longer available.

SQL Server 2000 data sources

Description: SQL Server 2000 data sources are no longer supported in SharePoint Foundation 2010.

Reason for change: SQL Server 2000 does not fully support many of the newer data features available in SharePoint Foundation 2010.

Migration path: Use data sources that are on Microsoft SQL Server 2005 or Microsoft SQL Server 2008.

ODBC data sources

Description: ODBC data sources are no longer supported in SharePoint Foundation 2010.

Reason for change: Newer and more versatile database connection options have replaced the functionality of ODBC.

Migration path: ODBC is no longer listed as an option for connecting to a data source. Use another data connection type.

Version 3 themes

Description: A theme is a set of colors, fonts, and decorative elements that enable you to quickly change the appearance of a site. The functionality provided in the version 3 themes is not available in the newly designed version 4 themes.

Reason for change: Version 4 themes are redesigned to simplify the process of generating themes. The new architecture is not compatible with the architecture of version 3 themes.

Migration path: Version 3 themes are still supported if the UI mode is kept at version 3. Version 3 themes are not supported in version 4 UI mode.

Web bot software agents

Description: A Web bot software agent is a dynamic object on a Web page that is evaluated when the page is saved or, in some cases, when the page is opened in a Web browser. Search crawlers and indexers are examples of Web bots. Developers can no longer use Web bot entry points and users cannot add Web bots to SharePoint Foundation 2010 sites.

Reason for change: This functionality is replaced by Web Parts.

Migration path: Use Web Parts instead of Web bots.

E-mail enabled groups and Microsoft SharePoint Directory Management service (DMS)

Description: The Microsoft SharePoint Directory Management service (DMS) connects SharePoint sites to an organization's user directory to provide enhanced e-mail features. If a SharePoint farm is using DMS, users cannot enable SharePoint groups to use e-mail.

Reason for change: The type of authentication used in DMS is being replaced with claims authentication.

Migration path: This feature is not available in SharePoint Foundation 2010. Use claims authentication instead.

For more information, see Plan authentication methods (SharePoint Foundation 2010).

Permissions for sub-webs

Description: When you assign a permission level to a parent site, that permission level is inherited by all sub-webs of the parent site by default. In Windows SharePoint Services 3.0, if you wanted a sub-web to have different permissions from its parent, you could edit the inherited permission level definition at the sub-web scope. The result was that you would have two permission levels with the same name but different permissions, depending on their scope. For example, suppose you assigned the Design permission level to a parent site, but you want to change the permissions on a sub-web so that users will not be able to apply style sheets to pages in that sub-web. In Windows SharePoint Services 3.0, you could edit the Design permission level on the sub-web itself, remove the Apply Style Sheets permission, and save the permission level as Design. It would not be possible, just by looking at permission levels, to determine that the sub-web actually had a different set of permissions than its parent site.

Migration path: In SharePoint Foundation 2010, if you want to give different permissions to a sub-web, you must assign a separate permission level to the sub-web. Site collections that are upgraded from Windows SharePoint Services 3.0 and have these unique permission level structures will continue to work. However, the user interface in SharePoint Foundation 2010 does not have a way to edit an inherited permission level at the sub-web scope, so you cannot change them or create new permission level definitions of this type. If you have a specific business need for continuing to use the Windows SharePoint Services 3.0 process, use the SharePoint Foundation 2010 object model.

Internationalized domain names

Description: Although Windows SharePoint Services 3.0 supported internationalized domain names (IDNs), SharePoint Foundation 2010 does not.

Reason for change: Support of internationalized domain names (IDNs) has been deprecated.

Migration path: If you currently use IDNs with Windows SharePoint Services 3.0 and you plan to upgrade or migrate to SharePoint Foundation 2010, you must stop using IDNs, delete all IDN settings, and then set up an environment that does not use IDN before doing so.


Hardware and software requirements (SharePoint Foundation 2010)
See Also

Published: May 16, 2012

This article lists the minimum hardware and software requirements to install and run Microsoft SharePoint Foundation 2010.

Important:

If you contact Microsoft technical support about a production system that does not meet the minimum hardware specifications described in this document, support will be limited until the system is upgraded to the minimum requirements.

In this article:

  • Overview

  • Hardware requirements—Web servers, application servers, and single server installations

  • Hardware requirements—Database servers

  • Software requirements

  • Access to applicable software

Overview

Microsoft SharePoint Foundation 2010 provides for a number of installation scenarios. Currently, these installations include single server with built-in database installations and single-server or multiple-server farm installations.

Hardware requirements—Web servers, application servers, and single server installations

The requirements in the following table apply both to installations on a single server with a built-in database and to servers running SharePoint Foundation 2010 in a multiple server farm installation.

Component Minimum requirement

Processor

64-bit, four cores

RAM

  • 4 GB for developer or evaluation use

  • 8 GB for production use in a single server or multiple server farm

Hard disk

80 GB for system drive

You must have sufficient space for the base installation and sufficient space for diagnostics such as logging, debugging, creating memory dumps, and so on. For production use, you also need additional free disk space for day-to-day operations. Maintain twice as much free space as you have RAM for production environments. For more information, see Capacity management and sizing for SharePoint Server 2010.

Hardware requirements—Database servers

The requirements in the following table apply to database servers in production environments with multiple servers in the farm.

Note:

Our definitions of small and medium deployments are those described in the "Reference Architectures" section in Capacity management and sizing for SharePoint Server 2010.

Component Minimum requirement

Processor

  • 64-bit, four cores for small deployments

  • 64-bit, eight cores for medium deployments

RAM

  • 8 GB for small deployments

  • 16 GB for medium deployments

For large deployments, see the "Estimate memory requirements" section in Storage and SQL Server capacity planning and configuration (SharePoint Server 2010).

Note:

These values are higher than those recommended as the minimum values for SQL Server because of the distribution of data required for a SharePoint Products 2010 environment. For more information about SQL Server system requirements, see Hardware and Software Requirements for Installing SQL Server 2008 (http://go.microsoft.com/fwlink/p/?LinkId=129377).

Hard disk

80 GB for system drive

Hard disk space is dependent on the size of your SharePoint content. For information about estimating the size of content and other databases for your deployment, see Storage and SQL Server capacity planning and configuration (SharePoint Server 2010).

Software requirements

The requirements in the following tables apply to single server with built-in database installations and server farm installations that include a single server and multiple servers in the farm.

Important:

SharePoint Foundation 2010 does not support single label domain names. For more information, see Information about configuring Windows for domains with single-label DNS names.

The Microsoft SharePoint Products Preparation Tool — which you access from the SharePoint Foundation 2010 Start page — can assist you in the installation of the software prerequisites for SharePoint Foundation 2010. Ensure that you have an Internet connection, because some of these prerequisites are installed from the Internet. For more information, see Deploy a single server with SQL Server (SharePoint Foundation 2010), Deploy a single server with a built-in database (SharePoint Foundation 2010), and Multiple servers for a three-tier farm (SharePoint Foundation 2010).

Minimum requirements

Environment Minimum requirement

Database server in a farm

One of the following:

  • The 64-bit edition of Microsoft SQL Server 2012.

    Important:

    In order to use Microsoft SQL Server 2012, you must also be running SharePoint Foundation 2010 SP1 or a later version of SharePoint Foundation 2010.

  • The 64-bit edition of Microsoft SQL Server 2008 R2.

  • The 64-bit edition of Microsoft SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2. From the Cumulative update package 2 for SQL Server 2008 Service Pack 1 (http://go.microsoft.com/fwlink/p/?LinkId=165962) page, click the View and request hotfix downloads link and follow the instructions. On the Hotfix Request page, download the SQL_Server_2008_SP1_Cumulative_Update_2 file. When you install Microsoft SQL Server 2008 SP1 on Windows Server 2008 R2, you might receive a compatibility warning. You can disregard this warning and continue with your installation.

    Note:

    We do not recommend that you use CU3 or CU4, but instead CU2, CU5, or a later CU than CU5. For more information, see Cumulative update package 5 for SQL Server 2008 (http://go.microsoft.com/fwlink/p/?LinkId=196928). Download the SQL_Server_2008_RTM_CU5_SNAC file.

  • The 64-bit edition of Microsoft SQL Server 2005 with Service Pack 3 (SP3). From the Cumulative update package 3 for SQL Server 2005 Service Pack 3 (http://go.microsoft.com/fwlink/p/?LinkId=165748) page, click the View and request hotfix downloads link and follow the instructions. On the Hotfix Request page, download the SQL_Server_2005_SP3_Cumulative_Update_3 file.

For more information about choosing a version of SQL Server, see SQL Server 2008 R2 and SharePoint 2010 Products: Better Together (SharePoint Server 2010): white paper.

Single server with built-in database

  • The 64-bit edition of Windows Server 2008 Standard, Enterprise, Data Center, or Web Server with SP2; the 64-bit edition of Windows Server 2008 R2 Standard, Enterprise, Data Center, or Web Server; or the 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard, Enterprise, Data Center, or Web Server. If you are running Windows Server 2008 with SP1, the Microsoft SharePoint Products Preparation Tool installs Windows Server 2008 SP2 automatically.

    Note:

    You must download an update for Windows Server 2008 and Windows Server 2008 R2 before you run Setup. The update is a hotfix for the .NET Framework 3.5 SP1 that is installed by the Preparation tool. It provides a method to support token authentication without transport security or message encryption in WCF. For more information and links, see the "Access to Applicable Software" section later in this article.

  • KB979917 - QFE for Sharepoint issues - Perf Counter fix & User Impersonation (http://go.microsoft.com/fwlink/p/?LinkId=192577).

    • For Windows Server 2008 SP2, download the Windows6.0-KB979917-x64.msu (Vista) file.

    • For Windows Server 2008 R2, download the Windows6.1-KB979917-x64.msu (Win7) file.

    For information, see the related KB article Two issues occur when you deploy an ASP.NET 2.0-based application on a server that is running IIS 7.0 or IIS 7.5 in Integrated mode (http://go.microsoft.com/fwlink/p/?LinkId=192578).

The preparation tool installs the following prerequisites:

  • Web Server (IIS) role

  • Application Server role

  • Microsoft .NET Framework version 3.5 SP1

  • SQL Server 2008 Express with SP1

  • Microsoft Sync Framework Runtime v1.0 (x64)

  • Microsoft Filter Pack 2.0

  • Microsoft Chart Controls for the Microsoft .NET Framework 3.5

  • Windows PowerShell 2.0

  • SQL Server 2008 Native Client

  • Microsoft SQL Server 2008 Analysis Services ADOMD.NET

  • ADO.NET Data Services Update for .NET Framework 3.5 SP1

  • A hotfix for the .NET Framework 3.5 SP1 that provides a method to support token authentication without transport security or message encryption in WCF.

  • Windows Identity Foundation (WIF)

    Note:

    If you have Microsoft "Geneva" Framework installed, you must uninstall it before you install the Windows Identity Foundation (WIF).

Front-end Web servers and application servers in a farm

  • The 64-bit edition of Windows Server 2008 Standard, Enterprise, Data Center, or Web Server with SP2; the 64-bit edition of Windows Server 2008 R2 Standard, Enterprise, Data Center, or Web Server; or the 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard, Enterprise, Data Center, or Web Server. If you are running Windows Server 2008 with SP1, the Microsoft SharePoint Products Preparation Tool installs Windows Server 2008 SP2 automatically.

    Note:

    You must download an update for Windows Server 2008 and Windows Server 2008 R2 before you run Setup. The update is a hotfix for the .NET Framework 3.5 SP1 that is installed by the Preparation tool. It provides a method to support token authentication without transport security or message encryption in WCF. For more information and links, see the "Access to Applicable Software" section.

  • KB979917 - QFE for Sharepoint issues - Perf Counter fix & User Impersonation (http://go.microsoft.com/fwlink/p/?LinkId=192577)

    • For Windows Server 2008 SP2, download the Windows6.0-KB979917-x64.msu (Vista) file.

    • For Windows Server 2008 R2, download the Windows6.1-KB979917-x64.msu (Win7) file.

    For information, see the related KB article Two issues occur when you deploy an ASP.NET 2.0-based application on a server that is running IIS 7.0 or IIS 7.5 in Integrated mode (http://go.microsoft.com/fwlink/p/?LinkId=192578).

The preparation tool installs the following prerequisites:

  • Web Server (IIS) role

  • Application Server role

  • Microsoft .NET Framework version 3.5 SP1

  • Microsoft Sync Framework Runtime v1.0 (x64)

  • Microsoft Filter Pack 2.0

  • Microsoft Chart Controls for the Microsoft .NET Framework 3.5

  • Windows PowerShell 2.0

  • SQL Server 2008 Native Client

  • Microsoft SQL Server 2008 Analysis Services ADOMD.NET

  • ADO.NET Data Services Update for .NET Framework 3.5 SP1

  • A hotfix for the .NET Framework 3.5 SP1 that provides a method to support token authentication without transport security or message encryption in WCF.

  • Windows Identity Foundation (WIF)

    Note:

    If you have Microsoft "Geneva" Framework installed, you must uninstall it before you install the Windows Identity Foundation (WIF).

Client computer

  • A supported browser. For more information, see Plan browser support (SharePoint Foundation 2010).

Optional software

Environment Optional software

Single server with built-in database

  • Windows 7 or Windows Vista. For more information, see Setting Up the Development Environment for SharePoint Server (http://go.microsoft.com/fwlink/p/?LinkID=164557).

Client computer

  • Microsoft Office 2010 client. For more information, see Microsoft Office 2010 (http://go.microsoft.com/fwlink/p/?LinkId=195843).

  • Microsoft Silverlight 3.

Access to applicable software

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

In scenarios where installing prerequisites directly from the Internet is not possible or not feasible, you can install the prerequisites from a network share. For more information, see Install prerequisites from a network share (SharePoint Foundation 2010).

  • SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=197422)

  • Language Packs for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=197424)

  • Windows Server 2008 (http://go.microsoft.com/fwlink/p/?LinkId=197426)

  • Windows Server 2008 R2 (http://go.microsoft.com/fwlink/p/?LinkId=197428)

  • Windows Server 2008 R2 SP1 (http://go.microsoft.com/fwlink/p/?LinkId=214566)

  • SQL Server 2008 R2 (http://go.microsoft.com/fwlink/p/?LinkId=197429)

  • SQL Server 2008 (http://go.microsoft.com/fwlink/p/?LinkID=179611)

  • SQL Server 2005 (http://go.microsoft.com/fwlink/p/?LinkId=197431)

  • Microsoft SQL Server 2008 SP1 (http://go.microsoft.com/fwlink/p/?LinkId=166490)

  • Cumulative update package 2 for SQL Server 2008 Service Pack 1 (http://go.microsoft.com/fwlink/p/?LinkId=165962)

  • Cumulative update package 5 for SQL Server 2008 (http://go.microsoft.com/fwlink/p/?LinkId=197434). Download the SQL_Server_2008_RTM_CU5_SNAC file.

  • Microsoft SQL Server 2005 SP3 (http://go.microsoft.com/fwlink/p/?LinkId=166496)

  • Cumulative update package 3 for SQL Server 2005 Service Pack 3 (http://go.microsoft.com/fwlink/p/?LinkId=165748)

  • Microsoft Windows Server 2008 SP2 (http://go.microsoft.com/fwlink/p/?LinkId=166500)

  • 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 (http://go.microsoft.com/fwlink/p/?LinkID=160770)

  • 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 (http://go.microsoft.com/fwlink/p/?LinkID=166231)

  • Microsoft .NET Framework 3.5 Service Pack 1 (http://go.microsoft.com/fwlink/p/?LinkId=131037)

  • Microsoft SQL Server 2008 Express Edition Service Pack 1 (http://go.microsoft.com/fwlink/p/?LinkId=166503)

  • Windows Identity Foundation for Windows Server 2008 (http://go.microsoft.com/fwlink/p/?LinkID=160381)

  • Windows Identity Foundation for Windows Server 2008 R2 (http://go.microsoft.com/fwlink/p/?LinkID=166363)

  • Microsoft Sync Framework v1.0 (http://go.microsoft.com/fwlink/p/?LinkID=141237)

  • Microsoft Office 2010 Filter Packs (http://go.microsoft.com/fwlink/p/?LinkId=191851)

  • Microsoft Chart Controls for Microsoft .NET Framework 3.5 (http://go.microsoft.com/fwlink/p/?LinkID=141512)

  • Windows PowerShell 2.0 (http://go.microsoft.com/fwlink/p/?LinkId=161023)

  • Microsoft SQL Server 2008 Native Client (http://go.microsoft.com/fwlink/p/?LinkId=166505)

  • Microsoft SQL Server 2008 Analysis Services ADOMD.NET (http://go.microsoft.com/fwlink/p/?linkid=160390)

  • KB979917 - QFE for Sharepoint issues - Perf Counter fix & User Impersonation (http://go.microsoft.com/fwlink/p/?LinkId=192577)

    • For Windows Server 2008 SP2, download the Windows6.0-KB979917-x64.msu (Vista) file.

    • For Windows Server 2008 R2, download the Windows6.1-KB979917-x64.msu (Win7) file.

  • ADO.NET Data Services Update for .NET Framework 3.5 SP1 (http://go.microsoft.com/fwlink/p/?LinkId=163519) for Windows Server 2008 SP2

  • ADO.NET Data Services Update for .NET Framework 3.5 SP1 (http://go.microsoft.com/fwlink/p/?LinkId=163524) for Windows Server 2008 R2 or Windows 7

  • Microsoft Silverlight 3 (http://go.microsoft.com/fwlink/p/?LinkId=166506)

  • Microsoft Office 2010 (http://go.microsoft.com/fwlink/p/?LinkID=195843)

  • Office Communicator 2007 R2 (http://go.microsoft.com/fwlink/p/?LinkId=196930)

  • Microsoft SharePoint Designer 2010 (32-bit) (http://go.microsoft.com/fwlink/p/?LinkId=196931)

  • Microsoft SharePoint Designer 2010 (64-bit) (http://go.microsoft.com/fwlink/p/?LinkId=196932)

  • Microsoft SQL Server 2008 SP1 (http://go.microsoft.com/fwlink/p/?LinkId=166490)

  • Cumulative update package 2 for SQL Server 2008 Service Pack 1 (http://go.microsoft.com/fwlink/p/?LinkId=165962).

  • Microsoft SQL Server 2005 SP3 (http://go.microsoft.com/fwlink/p/?LinkId=166496)

  • Cumulative update package 3 for SQL Server 2005 Service Pack 3 (http://go.microsoft.com/fwlink/p/?LinkId=165748).

  • Microsoft Windows Server 2008 SP2 (http://go.microsoft.com/fwlink/p/?LinkId=166500)

  • 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 (http://go.microsoft.com/fwlink/p/?LinkID=160770).

  • 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 (http://go.microsoft.com/fwlink/p/?LinkID=166231).

  • Microsoft .NET Framework 3.5 Service Pack 1 (http://go.microsoft.com/fwlink/p/?LinkId=131037)

  • Microsoft SQL Server 2008 Express Edition Service Pack 1 (http://go.microsoft.com/fwlink/p/?LinkId=166503)

  • Windows Identity Framework for Windows Server 2008 (http://go.microsoft.com/fwlink/p/?LinkID=160381)

  • Windows Identity Framework for Windows Server 2008 R2 (http://go.microsoft.com/fwlink/p/?LinkID=166363)

  • Microsoft Sync Framework v1.0 (http://go.microsoft.com/fwlink/p/?LinkID=141237&clcid=0x409)

  • Microsoft Office 2010 Filter Packs (http://go.microsoft.com/fwlink/p/?LinkId=191851)

  • Microsoft Chart Controls for Microsoft .NET Framework 3.5 (http://go.microsoft.com/fwlink/p/?LinkID=141512)

  • Windows PowerShell 2.0 (http://go.microsoft.com/fwlink/p/?LinkId=161023)

  • Microsoft SQL Server 2008 Native Client (http://go.microsoft.com/fwlink/p/?LinkId=166505)

  • Microsoft SQL Server 2008 Analysis Services ADOMD.NET (http://go.microsoft.com/fwlink/p/?LinkId=130651)

  • KB979917 - QFE for Sharepoint issues - Perf Counter fix & User Impersonation (http://go.microsoft.com/fwlink/p/?LinkId=192577)

    • For Windows Server 2008 SP2, download the Windows6.0-KB979917-x64.msu (Vista) file.

    • For Windows Server 2008 R2, download the Windows6.1-KB979917-x64.msu (Win7) file.

    For information, see the related KB article Two issues occur when you deploy an ASP.NET 2.0-based application on a server that is running IIS 7.0 or IIS 7.5 in Integrated mode (http://go.microsoft.com/fwlink/p/?LinkId=192578).

  • Microsoft Office 2010 (http://go.microsoft.com/fwlink/p/?LinkID=195843)

  • Microsoft Silverlight 3 (http://go.microsoft.com/fwlink/p/?LinkId=166506)

  • ADO.NET Data Services Update for .NET Framework 3.5 SP1 (http://go.microsoft.com/fwlink/p/?LinkId=163519) for Windows Server 2008 SP2

  • ADO.NET Data Services Update for .NET Framework 3.5 SP1 (http://go.microsoft.com/fwlink/p/?LinkId=163524) for Windows Server 2008 R2 or Windows 7

See Also

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010


Plan browser support (SharePoint Foundation 2010)

Updated: August 20, 2013

Microsoft SharePoint Foundation 2010 supports several commonly used Web browsers. This article describes different levels of Web browser support, and how ActiveX controls affect features.

In this article:

  • About planning browser support

  • Key planning phase of browser support

  • Browser support matrix

  • Browser details

  • ActiveX controls

  • Mobile browser support

About planning browser support

SharePoint Foundation 2010 supports several commonly used Web browsers. However, certain Web browsers might cause some SharePoint Foundation 2010 functionality to be downgraded, limited, or available only through alternative steps. In some cases, functionality might be unavailable for noncritical administrative tasks.

As part of planning your deployment of SharePoint Foundation 2010, we recommend that you review the browsers used in your organization to ensure optimal performance with SharePoint Foundation 2010.

If you are upgrading from SharePoint Portal Server 2003 to SharePoint Foundation 2010, additional considerations for browser support exist. For information, see Upgrade from SharePoint Portal Server 2003 to SharePoint Server 2010.

Key planning phase of browser support

Browser support is an important part of your SharePoint Foundation 2010 implementation. Before you install SharePoint Foundation 2010, ensure that you know which browsers SharePoint Foundation 2010 supports. The information in this article describes browser support in the following sections:

  • Browser support matrix

  • Browser details

Browser support matrix

The following table summarizes the support levels of commonly used Web browsers.

Browser | Supported | Supported with limitations | Not supported
Internet Explorer 10 | 32-bit | 64-bit |
Internet Explorer 9 | 32-bit | 64-bit |
Internet Explorer 8 | 32-bit | 64-bit |
Internet Explorer 7 | 32-bit | 64-bit |
Internet Explorer 6 |  |  | X
Google Chrome (latest publically released version) | X |  |
Mozilla Firefox (latest publically released version) | X |  |
Apple Safari (latest publically released version) |  | X |

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 Foundation 2010 and according to your business needs.

Internet Explorer versions

The product group makes every effort to validate that SharePoint functionality works correctly with released versions of Internet Explorer. Customers who want a more deeply validated browser interaction experience should strongly consider Internet Explorer.

Internet Explorer 10

The following operating system support Internet Explorer 10:

  • Windows 8

  • Windows 7

Internet Explorer 8 and Internet Explorer 9

The following operating systems support Internet Explorer 8 and Internet Explorer 9n:

  • Windows Server 2008 R2

  • Windows Server 2008

  • Windows Server 2003

  • Windows 7

  • Windows Vista

  • Windows XP

Note:

Windows XP is in extended support until April 8, 2014. For more information about the support lifecycle, see Windows lifecycle

Internet Explorer 7

Internet Explorer 7 is supported on the following operating systems:

  • Windows Server 2008

  • Windows Server 2003

  • Windows Vista

  • Windows XP

Note:

Windows XP is in extended support until April 8, 2014. For more information about the support lifecycle, see Windows lifecycle

Internet Explorer 6

SharePoint Foundation 2010 does not support Internet Explorer 6.

Other browsers

Google Chrome (latest publicly released version)

The following operating systems support Google Chrome:

  • Windows 8

  • Windows Server 2008 R2

  • Windows Server 2008

  • Windows Server 2003

  • Windows 7

  • Windows Vista

  • Windows XP

Note:

Windows XP is in extended support until April 8, 2014. For more information about the support lifecycle, see Windows lifecycle

Mozilla Firefox (latest released version plus immediate previous version)

For example, if the latest released version is 10, then version 9 is also supported.

The following operating systems support Mozilla Firefox:

  • Windows 8

  • Windows Server 2008 R2

  • Windows Server 2008

  • Windows Server 2003

  • Windows 7

  • Windows Vista

  • Windows XP

Note:

Windows XP is in extended support until April 8, 2014. For more information about the support lifecycle, see Windows lifecycle

Apple Safari (latest publicly released version)

The following operating systems support Safari:

  • Windows 8

  • Mac OSX (Snow Leopard and Lion)

  • Windows 7

  • Windows Vista

  • Windows XP

Note:

Windows XP is in extended support until April 8, 2014. For more information about the support lifecycle, see Windows lifecycle

ActiveX controls

Some functionality in SharePoint Foundation 2010 requires the use of ActiveX controls. This produces limitations on browsers which do not support ActiveX. Currently only 32-bit versions of Internet Explorer support this functionality. All other browsers have the following limitations.

Feature Limitation

Connect to Outlook, Connect to Office, and Sync to SharePoint Workspace

Works with an ActiveX control and the stssync:// protocol. Therefore, functionality may be limited without an ActiveX control, such as the one that is included in Microsoft Office 2010. The feature also requires an application that is compatible with the stssync:// protocol, such as Microsoft Outlook.

Datasheet view

Microsoft Office 2010 does not provide a 64-bit version of this control.

Edit in Microsoft Office application

Microsoft Office 2010 does not provide a 64-bit version of this control.

File upload and copy

Microsoft Office 2010 does not provide a 64-bit version of this control.

Microsoft InfoPath 2010 integration

Microsoft Office 2010 does not provide a 64-bit version of this control.

Microsoft PowerPoint 2010 Picture Library integration

Requires a 64-bit ActiveX control, such as the one that is delivered in Microsoft Office 2010. Users can use the following workarounds when no control is installed:

  • If you want to upload multiple pictures in a picture library, you have to upload one picture at a time by using Upload.aspx.

  • If you want to edit a picture in a picture library, you have to download the picture, edit it, and then upload the picture to the picture library.

  • If you want to download more than one picture from a picture library, you have to download one picture at a time by clicking the picture link.

Microsoft Visio 2010 diagram creation

Microsoft Office 2010 does not provide a 64-bit version of this control.

New Document

Microsoft Office 2010 does not provide a 64-bit version of this control.

Although the New Document command may not work, you can use the Upload Document functionality. If you install and configure Office Web Applications on the server, the New Document command works, and you can create an Office document in your browser.

Send To

Microsoft Office 2010 does not provide a 64-bit version of this control.

Without the control, you cannot send files from one SharePoint farm to another SharePoint farm. However, you can still send files from one site to another site.

Signing forms (InfoPath Form Services)

Microsoft Office 2010 does not provide a 64-bit version of this control.

Spreadsheet and database integration

Microsoft Office 2010 does not provide a 64-bit version of this control. Users can use the following workarounds when no control is installed:

  • If you want to edit a document, you have to download the document, edit it, and then save it back to the server.

  • In a list that requires a document to be checked out for editing, you have to use the Edit menu to check out the document, edit it, and then check it in by using the Edit menu.

  • Export to spreadsheet. You can export a SharePoint list as a spreadsheet by clicking Export to Spreadsheet on the List tab on the ribbon.

For Microsoft Office 2010 (64-bit), only the following controls work with 64-bit browsers:

  • name.dll - Presence information

Mobile browser support

The following table summarizes the support levels of commonly used mobile browsers

Mobile device operating system | Minimum operating system Version | Browser
Windows Phone | 7.0 | Internet Explorer
Apple iOS | 4.0 | Safari
Google Android | 2.1 | Android Browser
Research in Motion (RIM) Blackberry | 4.0 | Blackberry Browser
Nokia Symbian | 3 | Nokia Browser

Change History

Date | Description
August 20, 2013 | Updated the statement about Firefox support.
May 12, 2010 | Initial publication


IP support (SharePoint Foundation 2010)
See Also

This article explains the support for Internet Protocol Version 4 (IPv4) and Internet Protocol Version 6 (IPv6) addressing in Microsoft SharePoint 2010 Products.

SharePoint 2010 Products support the following environments:

  • Pure IPv4 environment

  • Mixed IPv4 and IPv6 environment

  • Pure IPv6 environment

In a SharePoint environment, "mixed" can be defined as one of the following likely scenarios:

  • Both IPv4 and IPv6 protocols are running in your environment.

  • Some of your client computers are using IPv4 and some of them are using IPv6.

  • Your client computers are using IPv4, but the computer running Microsoft SQL Server is using IPv6.

By default, the IPv6 protocol and the IPv4 protocol are both installed and enabled in Windows Server 2008 and Windows Server 2008 R2. When both IPv4 and IPv6 are enabled, IPv6 is given preference over IPv4. Additionally, you can remove the IPv4 protocol so that the computer runs IPv6 exclusively.

To determine what version is being used, you can use the IPConfig.exe tool. For additional information, see IPConfig (http://go.microsoft.com/fwlink/p/?LinkId=122336&clcid=0x409).

The following list shows other important considerations regarding IPv6:

  • For any computer that is authenticated by using a domain controller and is only running IPv6 within a SharePoint 2010 Products environment, the domain controller must be running Windows Server 2008 or Windows Server 2008 R2. Ensure that you use the correct service pack and any additional software prerequisites. For more information, see Hardware and software requirements (SharePoint Foundation 2010).

  • All versions of Microsoft SQL Server supported for SharePoint 2010 Products also support IPv6. For more information about IPv6 support for SQL Server 2008, see Connecting Using IPv6 (http://go.microsoft.com/fwlink/p/?LinkId=183115). For more information about IPv6 support for SQL Server 2005, see Connecting Using IPv6 (http://go.microsoft.com/fwlink/p/?LinkId=183118).

  • In SharePoint 2010 Products, when using IPv6 protocol, all end-user Uniform Resource Locators (URLs) must be based on DNS names with AAAA records. Browsing to SharePoint URLs that use IPv6 literal addresses is not supported. An example of a literal address URL is http://[2001:db8:85a3:8d3:1319:8a2e:370:7344]. However, SharePoint 2010 Products support entering IPv6 literal addresses for certain farm administration functionality, such as entering the server name when creating or attaching databases. For server names that use a literal address format, you must enclose the literal address within square brackets. For more information about AAAA records, see Adding a Resource Record to a Forward Lookup Zone (http://go.microsoft.com/fwlink/p/?LinkId=181956).

For additional information about IPv6, see Internet Protocol Version 6 (IPv6) (http://go.microsoft.com/fwlink/p/?LinkId=120794&clcid=0x409) and IP Addressing (http://go.microsoft.com/fwlink/p/?LinkId=120795&clcid=0x409).

See Also

Other Resources

Internet Protocol, Version 6 (IPv6) Specification


Overview of security features in SharePoint Foundation 2010

Published: July 29, 2011

This article contains a brief overview of the new security features that are included in Microsoft SharePoint Foundation 2010. These include the following:

  • Authentication modes

  • Automatic password change and managed accounts

  • Effective Permissions

  • Migrating security settings

  • Browser file handling setting

  • Sandboxed solutions

  • Limited access permission level

  • Access control in SharePoint Designer

Authentication modes

SharePoint Foundation 2010 support two modes of authentication: Claims-based and Classic mode.

Claims-based authentication

Claims-based authentication is built on Windows Identity Foundation (WIF), which is a set of the .NET Framework classes that are used to implement claims-based identity.

For additional information about claims-based authentication, see Plan authentication methods (SharePoint Foundation 2010)

Classic mode authentication

This mode of authentication uses Windows authentication and SharePoint Foundation 2010 treats all user accounts as Active Directory Domain Services (AD DS) accounts. Internet Information Services (IIS) provides three built-in forms of authentication: Integrated Windows authentication, Digest authentication, and Basic authentication.

For additional information about classic mode authentication, see Plan authentication methods (SharePoint Foundation 2010)

Automatic password change and managed accounts

The automatic password change feature enables you to update and deploy passwords without having to perform manual password update tasks across multiple accounts, services, and Web applications. In earlier SharePoint versions, to change a farm password, you would have to locate each server in the farm and manually change the password. However in SharePoint Foundation 2010, a service account is mapped to a managed account from which all password updates are controlled.

Benefits of using a managed account are as follows:

  • Passwords of managed accounts can be updated from a single location and changes can be distributed to all servers in the farm that use that managed account.

  • Password changes can be scheduled to automatically occur, either according to a schedule, or based on the password expiry policy set in AD DS.

  • Managed accounts generate very long, cryptographically random passwords for all accounts.

Note:

The generated password is at least 32 characters in length, with a mix of alphanumeric in both cases and special characters, and is created by using built-in core .NET Framework password generation routines.

For additional information about automatic password change, see Plan automatic password change (SharePoint Foundation 2010) and Configure automatic password change (SharePoint Foundation 2010)

Effective Permissions

In previous SharePoint versions, administrators used the Permission Reporting tool in the SharePoint Administration Toolkit version 4.0 to determine the effective permission of a specific user and how the user gets the permission on a particular object. However, in SharePoint Foundation 2010, administrators can use the Check Permissions functionality to check effective permissions. It determines a user or group's permissions on all site collection resources. An administrator can also find a user's directly assigned permissions and the permissions assigned to any groups to which the user belongs. You can check permissions for a user or group on the Site Permissions page.

For additional information about site permissions, see Plan site permissions (SharePoint Foundation 2010)

Migrating security settings

For organizations that have migrated from Office SharePoint Server 2007 to SharePoint Foundation 2010 the following articles are available to help in the migration process:

  • Migrate from forms-based authentication to claims-based authentication (SharePoint Foundation 2010)

  • Migrate from classic-mode to claims-based authentication (SharePoint Foundation 2010)

Browser file handling setting

In SharePoint Products 2010, the method to download security header information to a client's Web browser is restrictive. The default setting is Strict which will not allow certain file types to run (for example, Adobe Flash or Adobe Portable Document Format (PDF) files).

For additional information about browser file handling, see Configure settings for a Web application (SharePoint Foundation 2010) or Microsoft.SharePoint.Administration.SPWebApplication.BrowserFileHandling

Sandboxed solutions

Sandboxed solutions in SharePoint Products 2010 let code run in a restricted execution environment. For additional information about sandboxed solution, see Sandboxed solutions overview (SharePoint Foundation 2010)

Limited access permission level

This permission level is used to give groups access to a specific list, library, folder, document, or item, without giving them access to the whole site. For additional information about the limited access permission level, see Determine permission levels and groups (SharePoint Foundation 2010). For a graphical representation of the limited access permission level, download Best practices for using fine-grained permissions (white paper) (SharePoint Foundation 2010)

Access control in SharePoint Designer

Built-in support controls who in an organization can use SharePoint Designer 2010 and how they can use it. For information about how to delegate access control in SharePoint Designer 2010, see Control where and how people use SharePoint Designer 2010 (http://go.microsoft.com/fwlink/p/?LinkId=224715) and Changes in SharePoint Designer 2010


Getting started with SharePoint Foundation 2010

This book provides basic information about the capabilities of and requirements for Microsoft SharePoint Foundation 2010. The audience for this book includes IT pros, solution architects, and technical decision makers who are just starting to learn about SharePoint Foundation 2010 and want a quick introduction plus installation steps.

This Getting Started guide for SharePoint Foundation 2010 covers what's new in SharePoint Foundation 2010, and includes some end-to-end deployment scenarios to get you started quickly with an evaluation environment for SharePoint Foundation 2010.

The content in this book is a copy of selected content in the SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkID=179205) technical library as of the publication date. For the most current content, see the technical library on the Web. Click the following link to open a Microsoft Word .doc file that you can download to your computer and print: Downloadable book: Getting started with SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=191145). The size of this document is approximately 0.5 MB.

For additional information to help you plan and deploy SharePoint Foundation 2010, see the articles in the Planning and architecture for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=189175) section in this library.


Getting started with enterprise search in SharePoint 2010 Products
See Also

Summary: Learn how to get started matching the features and capabilities in Microsoft SharePoint 2010 products with the search requirements of your organization or enterprise.

Applies to: Microsoft SharePoint Foundation 2010, Microsoft Search Server 2010 Express, Microsoft Search Server 2010, Microsoft SharePoint Server 2010, Microsoft FAST Search Server 2010 for SharePoint

Contents

  • Introduction

  • Capabilities Comparison

  • Feature Comparison

  • First Steps

  • Evaluation Guides and Further Reading

Introduction

Search connects people to the information that they must have to do their jobs. General productivity search solutions increase employee efficiency by connecting a broad set of people to a broad set of information. High-value search applications drive measurable returns on investment (ROI) by helping a specific set of people extract the most from a specific set of information. Until now, organizations have had to purchase multiple products to address both scenarios; no single search solution delivered the correct functionality at the correct price, which forced organizations to incur the following additional costs:

  • Software costs — for example, licenses, support, and maintenance costs for separate products.

  • Headcount costs — for example, dedicated positions required to design, deploy, and manage different search solutions.

  • Opportunity costs — for example, mediocre general productivity search and limited deployment of high-value search applications.

When you assess the enterprise search offerings from Microsoft, review the capabilities of the various products and match them to the needs of your organization. You will find a broad set of enterprise search capabilities that are based on SharePoint 2010 Products and that serve the enterprise as growth, maturity, and changing business needs redefine your organizational enterprise search requirements.

SharePoint Foundation 2010 and Search Server 2010 Express are free to use on licensed Windows servers. They are entry-level products that crawl and index content. They also have a user interface that you can use to execute queries against the catalog of crawled content.

SharePoint Server 2010 and Search Server 2010 have improved scalability, and options to index content from many different sources. They include the configurability, manageability, and reporting features that your organization requires. SharePoint Server 2010 has a great platform that you can use to create general productivity search applications.

FAST Search Server 2010 for SharePoint is new, and it delivers the power of FAST with the simplicity and total cost of ownership (TCO) benefits that are typically associated with Microsoft products. FAST Search Server 2010 for SharePoint delivers the best general productivity search on the market and makes it easy and economical to build high-value search applications. FAST Search Server 2010 for SharePoint further improves the crawling, content processing, user interface, and scale of SharePoint Server 2010.

Capabilities Comparison

The following table compares general enterprise search capabilities that were in Office SharePoint Server 2007 with the features that are in SharePoint Server 2010 and FAST Search Server 2010 for SharePoint.

Note:

The table uses the following values:

  • X = available in 2007

  • O = available in 2010

  • † = improved in 2010

Features and Capabilities Office SharePoint Server 2007 SharePoint Server 2010 FAST Search Server 2010 for SharePoint

People and expertise search

Capture knowledge not found in documents by searching for people and expertise using SharePoint products.

X

O†

O†

SharePoint 2010 connector framework

Securely connect to content in SharePoint sites and from sources across your enterprise.

Use the Business Data Catalog to easily create your own connectors that work exactly like those available out of the box.

X

O†

O†

100m content volume with sub-second query response time

Meet the scale and performance needs of your entire organization or the specialized needs of individual departments.

X

O†

O†

Search from Windows 7 & Windows Mobile

Search beyond the search center. Conduct searches from the Windows 7 desktop and on your Windows mobile device.

X

O†

O†

Taxonomy tag integration

Bring the power of taxonomy into search. Tag metadata is shown in results, and users can refine by taxonomy-based tags.

O

O

Metadata-driven refinement panel

With the new refinement panel in SharePoint Server 2010 and FAST Search Server 2010 for SharePoint, users can narrow the results of their searches and navigate to the correct content faster.

O

O

Relevance improves with social behavior

The click-through behavior of similar search queries affects the rank that documents receive.

The more users click a certain item, the higher its ranking for related queries.

O

O

Phonetic and nickname search

Confidently search for a person's name as it sounds - without worrying about the exact spelling.

O

O

Contextual search

Tailor different results and refinement options, depending on the profile of the user or audience.

O

Thumbnails and previews

Thumbnails and previews make the results of a search query visual, which enable users to recognize the correct content quickly.

O

> 500m content volume with sub-second query response time

Scale to extremes with FAST Search Server 2010 for SharePoint while maintaining sub-second query response times.

O

Advanced content processing with advanced linguistics

Extract and create metadata latent in documents to improve search results, sorting capabilities, and the refinement panel.

O

Search-driven applications

Meet all the search application needs you have across your business.

Common examples include 360° Customer Insight, Research and Development Innovation Portal, and Product Support.

O

Business Intelligence Indexing Connector

Crawl Microsoft Excel 2010 workbooks and Reporting Services Reports with improved results, descriptions, thumbnails, and refiners.

Discover your business intelligence (BI) assets quickly and easily, navigate not only the document, but also the data behind the scenes, and access the information that you need quickly and easily.

O

Feature Comparison

Use the following table to make quick comparisons of the enterprise search features that each SharePoint product provides.

Note:

The table uses the following values:

  • * Specifies NTLM environments

  • ** Specifies FAST Search Server 2010 for SharePoint provides enhanced capabilities in these areas

  • *** Specifies a subset of the supported languages

Feature | SharePoint Foundation 2010 | Search Server 2010 Express | Search Server 2010 | SharePoint Server 2010 | FAST Search Server 2010 for SharePoint
Basic site search | Y | Y | Y | Y | Y
Best Bets |  | Y | Y | Y | Y
Visual Best Bets |  |  |  |  | Y
Similar Results |  |  |  |  | Y
Duplicate Results | Y | Y | Y | Y | Y
Search Scopes |  | Y | Y | Y | Y
RSS Feeds for Search Results | Y | Y | Y | Y | Y
Alerts for Search Results | Y* | Y* | Y* | Y* |
Advanced Search Page |  | Y | Y | Y | Y
Search Enhancement based on User Contexts |  |  |  |  | Y
Crawled and Managed Properties |  | Y | Y | Y | Y**
Entity Extraction |  |  |  |  | Y
Query Federation |  | Y | Y | Y | Y
Query Suggestions |  | Y | Y | Y | Y
Sort Results on Managed Properties or Rank Profiles |  |  |  |  | Y
Relevancy Tuning by Document or Site Promotions |  | Y | Y | Y | Y**
Shallow Results Refinement |  | Y | Y | Y | Y
Deep Results Refinement |  |  |  |  | Y
Document Preview |  |  |  |  | Y
Windows 7 Federation |  | Y | Y | Y | Y
People Search |  |  |  | Y | Y
Phonetic Name Search*** |  |  |  | Y | Y
Nickname Search*** |  |  |  | Y | Y
Self Search |  |  |  | Y | Y
Social Search |  |  |  | Y | Y
Taxonomy Integration |  |  |  | Y | Y
Multi-Tenant Hosting |  |  |  | Y |
Rich Web Indexing Support |  |  |  |  | Y
Note:

For details about a specific feature, review the evaluation guides for the products.

First Steps

There are some general tasks that you must perform when you evaluate search products or implement enterprise search solutions that meet your organization's requirements. Use the following sections to get started.

Identify your content

Before you take any action, identify the content in your organization that you want to index. Content from SharePoint sites is automatically included in all of the SharePoint search products, but you can also index content from file shares, Microsoft Exchange public folders, external Web sites, Lotus Notes databases, and your line-of-business applications.

You can also use SharePoint Designer 2010 or Visual Studio 2010 to create Business Data Catalog applications that enable custom databases, Web services, and other custom solutions to be indexed.

Note:

SharePoint Foundation 2010 can index content in SharePoint sites only. All other enterprise search products from Microsoft can index content in the content repositories mentioned earlier by using the connector framework.

FAST Search Server 2010 for SharePoint also has improved capabilities that enable you to index business intelligence data. You can obtain the Business Intelligence Indexing Connector to provide better search and analysis for business intelligence assets.

Crawl your content

The next step is to crawl the content in the content repositories that you identified. You can implement both full and incremental crawl schedules to ensure that indexed data is as fresh as possible.

The new index partitioning capabilities in Search Server 2010, SharePoint Server 2010, and FAST Search Server 2010 for SharePoint enable you to balance the indexing load (and query load) across dedicated servers that provide search for large amounts of content.

Scale your search infrastructure

One of the design goals for Search Server 2010 and SharePoint Server 2010 is to provide sub-second query response times for up to 100 million indexed documents. FAST Search Server 2010 for SharePoint provides sub-second query response times for more than 1 billion indexed documents. To achieve sub-second query response times for your organization, you might have to scale out your server farm to include multiple query servers. Additionally, to make sure that that indexed data is as fresh as possible when you index many documents, you might have to include multiple crawl components. The highly componentized architecture of the enterprise search products enables you to do that. For example, you can implement multiple crawl components to meet crawling demands, and you can include multiple query components to balance the query processing load at search time.

Customize the user search experience

Optionally, you can provide a customized user interface that information workers can use to search for information and manipulate results in the most efficient way for your business. The Enterprise Search Center for SharePoint Server 2010 and the FAST Search Center are highly customizable, and do not require developer effort. For example, you can create search scopes, change properties of search Web Parts, apply XSLT styles, and apply themes to search centers with minimal effort by using the Web browser or by using SharePoint Designer 2010.

If you want to further customize the search experience, developers can create a completely customized user interface by creating new Web Parts that inherit functionality from the existing Search Web Parts. Also, the search API is completely open. Therefore, developers can create new paradigms and ways of working with search — for example, by creating new Web Parts or even Silverlight applications that run searches and then render results.

Customize the content processing pipeline

One of the key differentiators between FAST Search Server 2010 for SharePoint and other search products is the ease with which you can customize content processing at indexing time. FAST Search Server 2010 for SharePoint enables you to create your own metadata extractors to use in the content processing pipeline. This enables you to define how managed properties are populated from crawled content, and you can then use that metadata in deep refiners. That is, you can include these organization-specific vocabularies in the metadata refinement panel that enables you to provide search solutions in the terms and language of your business.

Evaluation Guides and Further Reading

For more information about enterprise search and SharePoint Products and Technologies, see the following:

  • Microsoft Enterprise Search Center

  • TechNet Enterprise Search Technical Center

  • Microsoft Enterprise Search Blog

  • Microsoft SharePoint Server 2010 Search TechCenter

  • Microsoft SharePoint Server 2010 Enterprise Search Evaluation Guide

  • Enterprise search administration (SharePoint Server 2010)

  • Manage search topology (SharePoint Server 2010)

  • Microsoft FAST Search Server 2010 for SharePoint TechCenter

  • Microsoft FAST Search Server 2010 for SharePoint Evaluation Guide

  • FAST Search Server 2010 for SharePoint in the TechNet library

See Also

Other Resources

Resource Center: Architecture Design for SharePoint Server 2010
Resource Center: Enterprise Search in SharePoint Server 2010


Planning and architecture for SharePoint Foundation 2010

IT pros can use the content in the planning and architecture guides to develop conceptual, logical, and physical designs for configuring Microsoft SharePoint Foundation 2010 features, servers, and topologies. This section also provides recommendations for system designs based on customer scenarios and includes information to help IT pros design a highly reliable, consistently available, and scalable system.

Downloadable resources

  • Technical diagrams

  • Planning worksheets

Planning articles

Site and solution planning Server and farm environment planning

  • Fundamental site components

  • Security for sites and content

  • Sandboxed solutions

  • Collaboration sites

  • Document management

  • Business data and processes

  • Quota management

  • System requirements

  • Authentication

  • Security hardening

  • Automatic password change

  • Business continuity management

  • Virtualization


Technical diagrams (SharePoint Foundation 2010)

Many of these resources are visual representations of recommended solutions. They include poster-sized documents available in formats including Microsoft Office Visio 2007 or Microsoft Visio 2010 files (.vsd), PDF files, and XPS files. You might need extra software to view these files. See the following table for information about opening these files.

File type Software

.vsd

Office Visio 2007, Microsoft Visio 2010, or the free Visio viewer (http://go.microsoft.com/fwlink/p/?LinkId=118761)

If you use the Visio viewer, right-click the VSD link, click Save Target As, save the file to your computer, and then open the file from your computer.

.pdf

Any PDF viewer, such as Adobe Reader (http://go.microsoft.com/fwlink/p/?LinkId=134751)

.xps

Windows 7, Windows Vista, Windows XP with .NET Framework 3.0, or XPS Essentials Pack (http://go.microsoft.com/fwlink/p/?LinkId=134750)

Models

Models are 34-by-44-inch posters that detail a specific technical area. These models are intended to be used with corresponding articles on TechNet. These models are created by using Office Visio 2007. You can modify the Visio files to illustrate how you plan to incorporate Microsoft SharePoint 2010 Products in your own environment.

Title Description

SharePoint 2010 Products Deployment

SharePoint 2010 Products Deployment

Visio (http://go.microsoft.com/fwlink/p/?LinkId=183024)

PDF (http://go.microsoft.com/fwlink/p/?LinkId=183025)

XPS (http://go.microsoft.com/fwlink/p/?LinkId=183026)

Presents such deployment-related information as the different deployment stages and environments, plus a flowchart that illustrates the steps for installing and configuring SharePoint 2010 Products.

Services in SharePoint 2010 Products

Services in SharePoint - 1 of 2

Visio (http://go.microsoft.com/fwlink/p/?LinkID=167090)

PDF (http://go.microsoft.com/fwlink/p/?LinkID=167092)

XPS (http://go.microsoft.com/fwlink/p/?LinkID=167091)

Describes and illustrates the services architecture, including and common ways to deploy services in your overall solution design.

Extranet Topologies for SharePoint 2010 Products

Extranet topologies for SharePoint 2010 Products

Visio (http://go.microsoft.com/fwlink/p/?LinkId=187987)

PDF (http://go.microsoft.com/fwlink/p/?LinkId=187988)

XPS (http://go.microsoft.com/fwlink/p/?LinkId=187986)

Illustrates the specific extranet topologies that have been tested with SharePoint 2010 Products. Provides a comparison of ISA Server, Forefront TMG, Forefront UAG when used as a firewall or gateway product with SharePoint 2010 Products.

Hosting Environments in SharePoint 2010 Products

Visio (http://go.microsoft.com/fwlink/p/?LinkID=167084)

PDF (http://go.microsoft.com/fwlink/p/?LinkID=167086)

XPS (http://go.microsoft.com/fwlink/p/?LinkID=167085)

Summarizes the support for hosting environments and illustrates common hosting architectures.

Search Technologies for SharePoint 2010 Products

Search Technologies - 1 of 4

Visio (http://go.microsoft.com/fwlink/p/?LinkID=167731)

PDF (http://go.microsoft.com/fwlink/p/?LinkID=167733)

XPS (http://go.microsoft.com/fwlink/p/?LinkID=167732)

Compares and contrasts the search technologies that work with SharePoint Products 2010:

  • SharePoint Foundation 2010

  • Search Server 2010 Express

  • Search Server 2010

  • SharePoint Server 2010

  • FAST Search Server 2010 for SharePoint

Databases That Support SharePoint 2010 Products

Databases that support SharePoint 2010 Products

Visio (http://go.microsoft.com/fwlink/p/?LinkId=187970)

PDF (http://go.microsoft.com/fwlink/p/?LinkId=187969)

XPS (http://go.microsoft.com/fwlink/p/?LinkId=187971)

Describes the Microsoft SQL Server databases on which SharePoint Foundation 2010 runs.

SharePoint 2010 Products: Virtualization Process

SharePoint 2010 Products: Virtualization Process

Visio (http://go.microsoft.com/fwlink/p/?LinkId=195021)

PDF (http://go.microsoft.com/fwlink/p/?LinkId=195022)

XPS (http://go.microsoft.com/fwlink/p/?LinkId=195023)

Provides guidance related to virtualization and the various stages of deployment, as well as requirements and examples.

Tips for printing posters

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

Print posters on smaller paper

  1. Open the poster in Visio.

  2. On the File menu, click Page Setup.

  3. On the Print Setup tab, in the Printer paper section, select the size of paper you want to print on.

  4. On the Print Setup tab, in the Print zoom section, click Fit to, and then enter 1 sheet across by 1 sheet down.

  5. On the Page Size tab, click Size to fit drawing contents, and then click OK.

  6. On the File menu, click Print.

If you want to create posters that use the same symbols as these posters, you can download Visio stencils for posters (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=88e03d22-8f42-4c9d-94ef-d8e48322d677).


Site and solution planning (SharePoint Foundation 2010)
See Also

This section contains articles that will help you plan your Microsoft SharePoint Foundation 2010 site and solution components.

  • Fundamental site planning (SharePoint Foundation 2010)

    The articles in this section will guide you in planning sites that use SharePoint Foundation 2010 features.

  • Security planning for sites and content (SharePoint Foundation 2010)

    The articles in this section will help you plan permissions that control access to your sites and content.

  • Sandboxed solutions planning (SharePoint Foundation 2010)

    The articles in this section will help you plan sandboxed solutions that run in restricted execution environments within your enterprise.

  • Plan for collaboration sites (SharePoint Foundation 2010)

    The articles in this section will guide you in planning solutions that implement collaboration capabilities in your enterprise.

  • Document management planning (SharePoint Foundation 2010)

    The articles in this section cover conceptual information about document management.

  • Business data and processes planning (SharePoint Foundation)

    The articles in this section will guide you in planning solutions that implement business processes on your organization's data.

    • Plan for Business Connectivity Services (SharePoint Foundation 2010)

      The articles in this section will help you plan solutions that connect your organization's external data to information workers who use SharePoint Web sites.

    • Plan workflows (SharePoint Foundation 2010)

      The articles in this section will help you plan and implement processes in your SharePoint solutions.

  • Plan site creation and maintenance (SharePoint Foundation 2010)

    The articles in this section contain guidance about how to create, maintain, and delete sites, as well as how to determine settings for quota templates and recycle bins.

  • Plan e-mail integration (SharePoint Foundation 2010)

    The articles in this section explain how to implement incoming e-mail and features that rely on outgoing e-mail.

  • Plan for mobile devices (SharePoint Foundation 2010)

    This article describes the features that enable users to work with SharePoint Foundation 2010 by using their mobile devices. It summarizes important questions to consider when you deploy these features.

See Also

Concepts

Server farm and environment planning (SharePoint Foundation 2010)


Fundamental site planning (SharePoint Foundation 2010)

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

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

In this section:

  • Sites and site collections overview (SharePoint Foundation 2010) describes site collections and sites, and it contains information about the site templates that are used to create sites in SharePoint Foundation 2010.

  • Plan sites and site collections (SharePoint Foundation 2010) describes the process and important considerations for planning SharePoint Foundation 2010 sites and site collections.

  • Site navigation overview (SharePoint Foundation 2010) provides an overview of the types of navigation that are available in a site.

  • Plan site navigation (SharePoint Foundation 2010) helps you design the navigation for your site.

  • Themes overview (SharePoint Foundation 2010) provides an overview of themes and how they work.

  • Plan for using themes (SharePoint Foundation 2010) discusses how to plan for using themes across your sites, and it includes important steps to plan how to use themes for your sites.

  • Plan for multilingual sites (SharePoint Foundation 2010) discusses how to plan for multilingual SharePoint Foundation 2010 sites.

  • Multilingual user interface overview (SharePoint Foundation 2010) describes the multilingual user interface in SharePoint Foundation 2010.

  • Plan for the multilingual user interface (SharePoint Foundation 2010) describes how to plan for using the multilingual user interface in your SharePoint Foundation 2010 site solution.


Sites and site collections overview (SharePoint Foundation 2010)
See Also

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

In this article:

  • Site collections overview

  • Sites overview

  • Site templates included in SharePoint Foundation 2010

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.

Sites overview

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

  • Templates You can make each site have a unique template. For more information, see Site templates included in SharePoint Foundation 2010.

  • Language If language packs have been installed on the Web server, you can select a language-specific site template when you create a new site. Text that appears on the site is displayed in the site template's language. For more information, see Deploy language packs (SharePoint Foundation 2010).

  • Security You can define unique user groups and permissions for each site. For more information, see SharePoint 2010 Governance Planning (white paper).

  • Navigation You can fine-tune your site's navigation experience by configuring unique navigation links in each part of your site's hierarchy. Site navigation reflects the relationships among the sites in a site collection. Therefore, planning navigation and planning sites structures are closely related activities. For more information, see Site navigation overview (SharePoint Foundation 2010).

  • 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. For more information, see Plan for using themes (SharePoint Foundation 2010).

  • Regional settings You can change the regional settings, such as locale, time zone, sort order, time format, and calendar type. For more information, see Regional settings (SharePoint Foundation 2010).

  • Search You can make each site have unique search settings. For example, you can specify that a particular site never appears in search results.

  • Content types You can make each site have unique content types and site columns. For more information, see Content type and workflow planning (SharePoint Foundation 2010).

  • Workflows You can make each site have unique workflows. For more information, see Plan workflows (SharePoint Foundation 2010).

Site templates included in SharePoint Foundation 2010

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

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

Template | Purpose | Category in Site Collection | Category in Site
< Select template later> | An empty site for which you can select a template later. | Custom | N/A
Basic Meeting Workspace | A site on which you can plan, organize, and capture the results of a meeting. It provides lists for managing the agenda, meeting attendees, and documents. | Meetings | Meetings
Blank Meeting Workspace | A blank meeting site that you can customize based on your requirements. | Meetings | Meetings
Blank Site | A blank site that you can customize based on your requirements. | Collaboration | Blank & Custom
Blog | A site on which a person or team can post ideas, observations, and expertise that site visitors can comment on. | Collaboration | Content
Decision Meeting Workspace | A site on which you can track status or make decisions at meetings. It provides lists to create tasks, store documents, and record decisions. | Meetings | Meetings
Document Workspace | A site on which colleagues can work together on a document. It provides a document library for storing the primary document and supporting files, a tasks list for assigning to-do items, and a links list to point to resources that are related to the document. | Collaboration | Collaboration, Content
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, document library and other basic lists. | Collaboration | Collaboration
Multipage Meeting Workspace | A site on which you can plan a meeting and capture decisions and other results from the meeting. It provides lists for managing the agenda and meeting attendees. It also provides two blank pages that you can customize based on your requirements. | Meetings | Meetings
Social Meeting Workspace | A site on which you can plan social occasions. It provides lists for tracking attendees, providing directions, and storing pictures of the event. | Meetings | Meetings
Team Site | A site on which a team can organize, author, and share information. It provides a document library, and lists for managing announcements, calendar items, tasks, and discussions. | Collaboration | Collaboration

See Also

Concepts

Plan sites and site collections (SharePoint Foundation 2010)
Site navigation overview (SharePoint Foundation 2010)
Plan site navigation (SharePoint Foundation 2010)


Plan sites and site collections (SharePoint Foundation 2010)
See Also

Microsoft SharePoint Foundation 2010 sites are made up of a site collection, which is a hierarchical structure that includes one top-level site and any sites below it. This article describes the process and important considerations for planning SharePoint Foundation 2010 sites and site collections, and it recommends a method for recording your site structure decisions. For information about sites and site collections, and the site templates that are used to create sites in SharePoint Foundation 2010, see Sites and site collections overview (SharePoint Foundation 2010).

In this article:

  • About planning sites and site collections

  • Determine types of sites

  • Determine site collections

  • Site planning data worksheet

About planning sites and site collections

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

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

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

Determine types of sites

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

Plan sites by organizational hierarchy

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

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

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

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

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

Plan application sites

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

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

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

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

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

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

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

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

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

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

Plan Internet presence sites

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

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

Plan other sites

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

For information about the kinds of sites you can create, see Sites and site collections overview (SharePoint Foundation 2010).

Determine site collections

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

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

  • Internet sites (staging)

  • Internet sites (production)

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

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

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

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

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

Site planning data worksheet

Download an Excel version of the Site planning data worksheet. Use this worksheet to record your site structure.

See Also

Concepts

Sites and site collections overview (SharePoint Foundation 2010)
Site navigation overview (SharePoint Foundation 2010)
Plan site navigation (SharePoint Foundation 2010)


Site navigation overview (SharePoint Foundation 2010)
See Also

Site navigation provides the primary interface for site users to move around on the sites and pages on your site. Microsoft SharePoint Foundation 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 Foundation 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.

In this article:

  • Navigation controls overview

  • Navigation controls on master pages

    • Top link bar navigation

    • Quick Launch navigation

    • Breadcrumb navigation

    • Tree view navigation

Navigation controls overview

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

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

  • Sites below the current site

  • A site's peer sites

  • Sites higher in the site structure

  • Web pages in a site

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

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

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

  • The site map provider.

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

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

Navigation controls on master pages

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

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

Top link bar navigation

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

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

Other top link bar configuration features include the following:

  • Linking to specified external sites.

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

  • Manually sorting the items on the top link bar.

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

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

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

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

Quick Launch navigation

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

Quick Launch navigation configuration features include the following:

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

  • Organizing links under headings.

  • Manually sorting the items in the Quick Launch navigation.

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

Breadcrumb navigation

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

Tree view navigation

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

By default, tree view navigation is turned off. Site administrators can add tree view navigation to a site by using the Tree View page. To enable tree view, in Site Actions click Site Settings, in the Look and Feel area, click Tree view, and then select the Enable Tree View check box.

See Also

Concepts

Plan site navigation (SharePoint Foundation 2010)
Sites and site collections overview (SharePoint Foundation 2010)
Plan sites and site collections (SharePoint Foundation 2010)


Plan site navigation (SharePoint Foundation 2010)
See Also

Site navigation provides the primary interface for site users to move around the sites and pages in your site. Microsoft SharePoint Foundation 2010 includes a set of navigation features that can be customized and extended to help orient the users of your site so they can move around its sites and pages. This article contains general guidance about how to plan site navigation for your SharePoint Foundation 2010 sites. This article does not describe the types of navigation controls that are available in SharePoint Foundation 2010, nor does it explain how to add navigation controls to Web pages, how to configure navigation controls, or how to create custom navigation controls. For more information about site navigation controls, see Site navigation overview (SharePoint Foundation 2010) and Navigation Controls.

In this article:

  • Create a site navigation diagram

  • Understanding inherited navigation

  • Determine which sites inherit the top link bar

  • Determine which additional links to add manually to the top link bar

  • Determine other site navigation options

  • Site planning data worksheet

Create a site navigation diagram

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

Site diagram for Margie's travel

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

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

Understanding inherited navigation

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

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

Home | Office Management | Convention Planning | Sales and Marketing

Note:

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

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

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

Determine which sites inherit the top link bar

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

Home | Office Management | Convention Planning | Sales and Marketing

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

Margie's Travel Home site: Home | Office Management

Convention Planning site: Convention Planning | Reports

Sales and Marketing site: Sales and Marketing

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

Note:

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

Determine which additional links to add manually to the top link bar

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

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

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

Determine other site navigation options

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

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

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

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

Site planning data worksheet

Download an Excel version of the Site planning data worksheet. Use this worksheet to help record your decisions about site navigation.

See Also

Concepts

Site navigation overview (SharePoint Foundation 2010)
Sites and site collections overview (SharePoint Foundation 2010)
Plan sites and site collections (SharePoint Foundation 2010)
Themes overview (SharePoint Foundation 2010)
Plan for using themes (SharePoint Foundation 2010)


Themes overview (SharePoint Foundation 2010)
See Also

Themes provide a quick and easy way to apply colors and fonts to sites in Microsoft SharePoint Foundation 2010. When a theme is applied to a site, the color of most page elements — such as background images, text, and hyperlinks — changes. The fonts used for some page elements, such as titles, also change. Themes can be used with the standard SharePoint Foundation 2010 site templates, or with custom master pages, and then themes can be created that site owners can apply to their sites.

This article includes an overview of themes and how they work. This article does not describe how to create custom themes by using Microsoft Office 2010 applications, or how to upload and manage themes in a theme library. It also does not discuss how to plan for the overall branding of sites by using master pages or cascading style sheets. For more information, see Building Block: Pages and User Interface.

In this article:

  • About using themes

  • Ways to use themes

About using themes

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

Note:

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

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

Note:

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

Ways to use themes

There are two ways to use themes on a site:

  • Use a preinstalled theme.

  • Upload a custom theme to the theme library.

Using a preinstalled theme

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

Uploading your own custom themes to the theme gallery

You can create custom themes by modifying styles in an Office 2010 application, such as Microsoft PowerPoint 2010, and saving the theme. This creates a .thmx file that you can upload to the theme gallery for a site collection. Customized themes in the theme gallery are available to all sites in that site collection. For more information about themes in Office 2010 applications, see What is a theme? (http://go.microsoft.com/fwlink/p/?LinkId=214620). For information about how to create and upload themes to SharePoint Foundation 2010, see Working with SharePoint 2010 Themes (http://go.microsoft.com/fwlink/p/?LinkId=214625).

See Also

Concepts

Plan for using themes (SharePoint Foundation 2010)


Plan for using themes (SharePoint Foundation 2010)
See Also

Themes provide a quick and easy way to apply colors and fonts to sites in Microsoft SharePoint Foundation 2010. When a theme is applied to a site, the color of most page elements — such as background images, text, and hyperlinks — changes. The fonts used for some page elements, such as titles, also change. Themes can be used with the standard SharePoint Foundation 2010 site templates, or with custom master pages, and then themes can be created that site owners can apply to their sites. For more information, see Themes overview (SharePoint Foundation 2010).

This article discusses how to plan for using themes across your SharePoint Foundation 2010 sites, and includes key steps in planning to use themes for your sites. This article does not describe how to create custom themes by using Microsoft Office 2010 applications, or how to upload and manage themes in a theme library. It also does not discuss how to plan for the overall branding of sites by using master pages or cascading style sheets. For more information, see Building Block: Pages and User Interface.

Before reading this article, be sure to read the article Plan sites and site collections (SharePoint Foundation 2010).

In this article:

  • About planning for using themes

  • Decide whether to use themes

  • Determine how many themes are needed

  • Decide who makes the themes

  • Site planning data worksheet

About planning for using themes

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

  • Decide whether to use themes.

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

  • Decide who will make the custom themes.

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

Decide whether to use themes

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

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

To | Use this
Allow site owners to change colors and fonts | Themes
Make changes to other design elements such as font size and spacing | Cascading style sheets
Completely change the page structure and design | Master Pages
Note:

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

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

Determine how many themes are needed

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

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

Decide who makes the themes

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

You must also decide who will be responsible for uploading the themes to the theme gallery. Will the person who creates the themes also be responsible for uploading the *.thmx files to the theme gallery, or will they save the theme files to a directory for a site collection administrator to upload? A user must have either administrator or designer privileges for the site collection that contains the theme gallery in order to upload *.thmx files to the gallery. For more information about themes in Office 2010 applications, see What is a theme? (http://go.microsoft.com/fwlink/p/?LinkID=214620). For information about how to create and upload themes to SharePoint Foundation 2010, see Working with SharePoint 2010 Themes (http://go.microsoft.com/fwlink/p/?LinkID=214625).

Site planning data worksheet

Download a Microsoft Excel version of the Site planning data worksheet (http://go.microsoft.com/fwlink/p/?LinkID=167838&clcid=0x409). Use this worksheet to help record your decisions about themes.

See Also

Concepts

Themes overview (SharePoint Foundation 2010)
Sites and site collections overview (SharePoint Foundation 2010)
Plan sites and site collections (SharePoint Foundation 2010)


Plan for multilingual sites (SharePoint Foundation 2010)
See Also

Microsoft SharePoint Foundation 2010 has several features that enable you to support users in different regions or users who speak different languages. You can use these features to create Web sites in different languages.

This article discusses how to plan for multilingual SharePoint Foundation 2010 sites. This article does not describe how to create multilingual sites or how to install language packs. For information about creating multilingual sites, see Create sites in different languages from the default language. For information about language packs, see Deploy language packs (SharePoint Foundation 2010).

In this article:

  • About planning multilingual sites

  • Determine language and locale requirements

  • Determine language pack requirements

  • Determine requirements for word breakers and stemmers

About planning multilingual sites

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

To determine your multilingual requirements, you must:

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

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

  • Language packs.

  • Word breaker support.

Note:

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

Determine language and locale requirements

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

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

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

Be sure to consult all potential site owners when you determine your language requirements, and be sure to list all languages that you might have to support in the future. It is easier to install language support during initial deployment instead of waiting to install language support when your servers are running in a full production environment. After a site has been created for a specific language, the default language of the site cannot be changed. However, a user who is logged on to the site can use the multilingual user interface to select an alternative language in which to display the site. This changes the way the site user interface is displayed to the user, but it does not change the site content. For example, if the site was provisioned in French, and the Spanish language pack has also been installed on the server, a site user can change the language to Spanish so that when they view the site, the user interface will be in Spanish. This changes the user interface for that user only and does not affect how the site is displayed to other users. Also, any content that was created in French will still be displayed in French. For more information about the multilingual user interface, see Multilingual user interface overview (SharePoint Foundation 2010).

Note:

If a user changes their personal site settings to display the site in an alternative language, some site elements, such as column names, might still be displayed in the default site language.

Do not assume that you have to create a Web site or a site collection in multiple languages only because a document library contains documents in multiple languages. A document library can contain documents in multiple languages without requiring you to create Web sites or site collections in multiple languages. For example, the document library for an English site collection can contain documents that are written in French and documents that are written in Japanese.

When you are planning multilingual sites, you should also consider what locales are necessary to support your sites. Locale is a regional setting that specifies the way numbers, dates and times are displayed on a site. However, locale does not change the language in which the site is displayed. For example, selecting the Thai locale changes the default sort order of list items and uses the Buddhist calendar instead of the default calendar. The locale is a setting that is configured independently of the language specified when a site is created, but unlike the language, the locale can be changed at any time. For more information about translation of the user interface, see Determine language pack requirements.

Determine language pack requirements

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

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

  • Ribbon elements

  • List and site column headers

  • Site settings interface

  • Templates for new lists, document libraries, and sites

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

Note:

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

The list of available languages that you can use to create a site or site collection, and which users can select in the multilingual user interface, is generated by the language packs that are installed on the front-end Web servers of your server farm. By default, sites and site collections are created in the language in which SharePoint Foundation 2010 was installed. For example, if you install the Spanish version of SharePoint Foundation 2010, the default language for sites, site collections, and Web pages is Spanish. If you have to create sites, site collections, or Web pages in a language other than the default SharePoint Foundation 2010 language, you must first install the language pack for that other language on the front-end Web servers before you can select another language in which to create a site. For example, if you are running the French version of SharePoint Foundation 2010 and you want to create sites in French, English, and Spanish, then you must install the English and Spanish language packs on the front-end Web servers before you can create the English and Spanish sites.

Language packs for SharePoint Foundation 2010 are not bundled or grouped into multilingual installation packages: you must install a specific language pack for each language that you want to support. Also, language packs must be installed on every front-end Web server in the server farm to ensure that each Web server can render content in the specified language. For information about what language packs are available, see Language packs (SharePoint Foundation 2010). For information about how to deploy language packs, see Deploy language packs (SharePoint Foundation 2010).

Even though you specify a language for a site, some user interface elements such as error messages, notifications, or dialog boxes might not appear in the language that you choose. This is because SharePoint Foundation 2010 relies on several supporting technologies — such as the .NET Framework, Microsoft Windows Workflow Foundation, ASP.NET, and Microsoft SQL Server — and some of these supporting technologies are localized into only a limited number of languages. If a user interface element is generated by one of the supporting technologies, and if the supporting technology is not localized into the language that the site administrator specified for the site, the user interface element appears in English.

In addition, some text might originate from the original installation language, which can create a mixed-language experience. This type of mixed-language experience is typically seen only by content creators or site administrators and is not seen by site users.

Note:

Error logs that SharePoint Foundation 2010 stores on the server are always in English.

For more information about installing language packs, see Deploy language packs (SharePoint Foundation 2010).

Determine requirements for word breakers and stemmers

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

If you install any language packs or supplemental language support, we recommend that you install the appropriate word breaker and stemmer for each of the languages that you have to support. Word breakers and stemmers must be installed on all servers that are running the Search service. For a list of the languages for which SharePoint Foundation 2010 provides word breakers and stemmers, see Languages for word breakers and stemmers (SharePoint Foundation 2010).

See Also

Concepts

Multilingual user interface overview (SharePoint Foundation 2010)
Plan for the multilingual user interface (SharePoint Foundation 2010)


Multilingual user interface overview (SharePoint Foundation 2010)
See Also

Published: July 8, 2010

This article discusses the new multilingual user interface feature in Microsoft SharePoint Foundation 2010. When language packs were installed on the server in Windows SharePoint Services 3.0 and you created a site collection or site, you could also select the language in which to display the site user interface. However, after the language for the user interface of a site was set, it could not be changed. The multilingual user interface feature introduces the concept of secondary, or preferred, languages. This feature is used to display the site user interface in a secondary language that the user prefers rather than the default, primary language that was selected when the site was created.

This article does not describe how to deploy the language packs that are required to use the multilingual user interface or how to configure site settings to enable users to set their preferred language. It also does not discuss how to plan for using the multilingual user interface in your site solution. For information about how to let individual users change the primary language that is used to display their site's user interface, see Make multiple languages available for your site's user interface on Office.com. For information about how to plan to use the multilingual user interface, see Plan for the multilingual user interface (SharePoint Foundation 2010).

In this article:

  • Use and benefits of the multilingual user interface

  • How the multilingual user interface works

  • What is supported by the multilingual user interface

  • Adding and modifying application content

  • Exporting and importing translated content

  • Limitations of the multilingual user interface

Use and benefits of the multilingual user interface

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

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

Note:

The multilingual user interface only displays site user interface elements in another language. It does not perform translation or display content such as documents or list items in another language. SharePoint Foundation 2010 provides three methods that you can use to translate certain application content, such as list or library titles and descriptions: by using the user interface, by exporting and importing translations for a site, and by using the object model.

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

How the multilingual user interface works

By default, when a new site is created, it is created in the default, primary language of the SharePoint Foundation 2010 installation on the server. A farm administrator must install language packs on the server before sites can be created in languages other than the default, primary language. For more information, see Deploy language packs (SharePoint Foundation 2010).

After language packs have been installed on the server, the Language Settings link is added to the Site Settings page. Site administrators use the Language Settings page to specify which secondary languages the site will support. After the site administrator has enabled secondary languages for a site, users can log on to the site and use the Select Display Language option on the user menu to change the language that is displayed when they browse to any page in the site collection. When a user changes the display language of a page, the new display language becomes the user's preferred language for the whole site collection.

SharePoint Foundation 2010 selects the language in which to display pages of a site collection by using the first rule that applies from the following list:

  1. Does the user have a preferred language for this site collection on this computer? If so, use the user's preferred language.

  2. Is the language preference that is specified in the Web browser one of the supported languages for the page? If so, use the preferred language of the browser.

  3. Otherwise, use the default, primary language for the site collection.

SharePoint Foundation 2010 provides three methods that you can use to modify certain application content, such as list or library titles and descriptions: by using the user interface, by exporting and importing translations for a site, and by using the SPUserResource class in the Microsoft.SharePoint namespace. Not all user interface elements can be changed directly in the user interface. For example, user actions and commands can be changed only by using the SPUserResource class. For more information, see SPUserResource class.

What is supported by the multilingual user interface

When a user views a site in a secondary, preferred language, certain elements of the user interface are displayed in the preferred language. Generally speaking, most user interface elements can be displayed in the secondary, preferred language, but user-created content cannot be. The following list includes examples of items that are supported by the multilingual user interface:

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

  • Help.

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

  • Developer content, such as features, and solutions.

However, not all user interface elements are displayed in the secondary, preferred language. The following list includes examples of items that are not supported by the multilingual user interface:

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

  • Global breadcrumbs.

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

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

  • The Blog template.

  • Any of the meeting workspace templates.

  • Any of the Web database templates.

For more detailed information about the user interface elements that are not supported by the multilingual user interface feature, see Limitations of the multilingual user interface, later in this article.

Adding and modifying application content

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

When a user views a site by using the primary language of the site, any new application content that is created is displayed in the primary language, even when the site is viewed in a secondary language. For example, if the primary language for a site is English, when a user views the site in the primary language and creates a new document library called "Team Documents," the library title is still displayed as "Team Documents" when a user views the site in any secondary language.

When a user views a site by using a secondary language, any new application content that the user creates is displayed in that language even when the site is viewed in the primary language or in any other secondary language. For example, if the primary language for a site is English, and a user views the site in German and adds a document library called "Mannschaftsdokumente," the library title is displayed as "Mannschaftsdokumente" even when the site is viewed in English. To translate application content such as a document library title into the primary language or into other secondary languages, the user must first configure the user preferences to display the site in the language for which he or she wants to make the change, and then make the change to the user interface.

The Language Settings page contains an Overwrite Translations option that affects how changes to existing application content are made to other languages for the site. If the Overwrite Translations option is enabled, any changes that are made to the user interface in the primary language overwrite any changes that have been made to those same user interface elements in secondary languages.

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

When a site is displayed in a user's secondary, preferred language, any changes that are made to existing application content are changed for that language only. The strings that are associated with specific application content in the primary language and other secondary languages remain unchanged. To translate application content such as a document library title into the primary language or into other secondary languages, the user must change the user preferences to display the site in the primary or secondary language and then make the change to the user interface.

Exporting and importing translated content

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

When the application content is exported, it is saved as a .resx file, which can be opened by using a text editor or any third-party tool that can open resource files. For more information, see Resources in .Resx File Format. After the resource strings have been translated, you use the Import Translations link on the Site Settings page to import the .resx file.

Limitations of the multilingual user interface

As mentioned previously, some user interface elements are not MUI-enabled — that is, they are not supported by the multilingual user interface. This section describes additional limitations that apply when you use the multilingual user interface with shared components and site templates.

Shared components

Shared components — such as Web Parts, lists, and permissions — appear across all site templates. Their functionality is centrally defined, and their behavior is consistent regardless of the site template in which they appear.

Web Parts

The titles and descriptions are MUI-enabled only for list-based Web Parts. For example, the title and description for Web Parts that display list and library data, such as Announcements and Shared Documents, are displayed in a user's preferred language. By contrast, the title and description for other Web Parts, such as the Content Editor and the Content Query Web Parts, are displayed only in the primary site language. The following properties and features of non-list-based Web Parts are not MUI-enabled. They are always displayed in the language in which they were created.

  • Titles This includes default Web Part titles and any titles that the user edited after the site was created.

  • Descriptions This includes default Web Part descriptions and any descriptions that the user edited after the site was created

  • Custom properties Any custom Web Part properties that are created or edited by the user remain in the language in which they were created.

  • Import error message The default value of this error message is always displayed in the primary site language. If a user has created a custom error message, that error message is always displayed in the language in which it was created.

Lists

List views and list items are not MUI-enabled. These user interface elements will continue to display the values that were entered when they were created, regardless of the preferred language selected by the user.

Links to list titles in the Quick Launch and the top link bar menu will continue to display the values that were entered when the lists were created. Although the Quick Launch and the top link bar menu are MUI-enabled, the list titles that they display are independent of the actual list titles. To work around this issue, the user must edit the list title for the Quick Launch and the top link bar menu. For information about how to edit the Quick Launch link item, see Edit, move, or delete a Quick Launch link (http://go.microsoft.com/fwlink/p/?LinkId=208207) in "Configure the Quick Launch for site navigation" on Office.com. For information about how to edit the top link bar, see Add, edit or remove a link from the top link bar (http://go.microsoft.com/fwlink/p/?LinkId=208208) in "Configure the top link bar for site navigation" on Office.com.

Permissions

The following properties and features of permissions are not MUI-enabled; they are always displayed in the primary site language or the language in which they were created:

  • Permission group names These include default permission group names and any custom permission groups that were created by a user.

  • Permission level names and descriptions These include default permissions levels and any custom permission levels that were created or changed by a user.

  • User information User information such as About Me, Title, and Department.

Site templates

This section describes the limitations of the multilingual user interface for site templates in SharePoint Foundation 2010. The majority of these limitations are caused by the limitations of their shared site components such as Web Parts, lists, and permissions. The following multilingual user interface limitations apply to specific templates, because of their specialized nature or custom layout.

Blogs

The Blog site template includes many Web Parts and user-generated content, which are not MUI-enabled. If additional display languages are enabled on the Blog site settings page, an error message will be displayed.

Meeting sites

Meeting site templates include many Web Parts and user-generated content, which are not MUI-enabled. If additional display languages are enabled on the site settings page for any meeting site template, an error message will be displayed.

See Also

Concepts

Plan for the multilingual user interface (SharePoint Foundation 2010)
Plan for multilingual sites (SharePoint Foundation 2010)


Plan for the multilingual user interface (SharePoint Foundation 2010)
See Also

Published: July 8, 2010

The new multilingual user interface feature in Microsoft SharePoint Foundation 2010 introduces the concept of a secondary language that the user can select. This feature displays the site user interface in a secondary language that the user selects and that is different from the primary language that was chosen when the site was created.

This article describes how to plan for using the multilingual user interface in your SharePoint Foundation 2010 site solution. This article does not describe how to deploy the language packs that are required to use the multilingual user interface or how to configure site settings to enable users to set their preferred language. For information about how to let individual users change the language that is used to display their site's user interface, see Make multiple languages available for your site's user interface. For more information about the multilingual user interface, see Multilingual user interface overview (SharePoint Foundation 2010).

In this article:

  • Determine language requirements for your sites

  • Plan for translating content

  • Plan for installing service packs

Determine language requirements for your sites

Before you can use the multilingual user interface in your SharePoint sites, the farm administrator must deploy language packs to the server so that they are available for use on sites. Decide which language packs are needed and when they will be deployed to the server. Site administrators must configure the language settings for individual sites to make specific languages available to site users. You should decide which languages are needed for each site and plan to have the site administrators enable specific languages for the sites they manage. For information about planning multilingual sites, see Plan for multilingual sites (SharePoint Foundation 2010). For information about deploying language packs, see Deploy language packs (SharePoint Foundation 2010).

Plan for translating content

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

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

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

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

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

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

Plan for installing service packs

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

See Also

Concepts

Multilingual user interface overview (SharePoint Foundation 2010)
Plan for multilingual sites (SharePoint Foundation 2010)


Security planning for sites and content (SharePoint Foundation 2010)

Some of the sites in your enterprise probably contain content that should not be available to all users. For example, proprietary technical information should be accessible only on a need-to-know basis. An intranet portal for employee benefits should be available only to full-time employees, whereas the home page of an Internet Web site is accessible by anonymous clients.

Permissions control access to your sites and site content. You can manage permissions by using Microsoft SharePoint Foundation 2010 groups, which control membership, and fine-grained permissions, which help to secure content at the item and document level. This section describes permissions for sites and site content and provides considerations for choosing permissions.

In this section:

  • Plan site permissions (SharePoint Foundation 2010) helps you understand how permissions are assigned and helps you choose the appropriate permissions to use in your site collection or subsite.

  • Determine permission levels and groups (SharePoint Foundation 2010) reviews the available permission levels and groups, and helps you determine whether you need additional permission levels or groups.

  • Choose security groups (SharePoint Foundation 2010) helps you determine which Microsoft Windows security groups and user accounts to use to grant access to sites, decide whether to use the Authenticated Users group, and decide whether to allow anonymous access.

  • Choose administrators and owners for the administration hierarchy (SharePoint Foundation 2010) defines the levels of administration from the server level to the subsite level and helps you choose administrators for each level.

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

    Provides guidance about how to use fine-grained permissions in Microsoft SharePoint 2010 Products.

  • Contribute permission level overview (SharePoint Foundation 2010)

    Provides information about the Contribute permission level and the tasks that you can complete if you have these permissions.

Security Note:

SharePoint Foundation 2010 does not currently comply with Federal Information Processing Standard (FIPS) 140-2 - Security Requirements for Cryptographic Modules. FIPS 140-2 defines security standards which the United States and Canadian governments use to validate security levels for products that implement cryptography.

For more information about FIPS 140-2, see the following references:

  • FIPS 140 Evaluation

  • FIPS Publications


Plan site permissions (SharePoint Foundation 2010)
See Also

This article helps you plan access control at the site collection, site, subsite, and site content (list or library, folder, item or document) levels. This article also describes the concepts about permission inheritance and fine-grained permissions.

This article does not address planning the security of your entire server or server farm. For more information about planning other aspects of security, such as authentication methods and authentication modes, see Plan authentication methods (SharePoint Foundation 2010).

In this article:

  • About site permissions

  • About permission inheritance

  • Plan for site permissions

  • Plan for permission inheritance

  • Worksheet

Introduction

You can control access to site and site content by assigning permissions to users or groups for a specific site or site content at the following levels within a site collection:

  • Site

  • Library or list

  • Folder

  • Document or item

Before developing your plan for site and content access, you should consider the following questions:

  • To what granularity do you want to control permissions for the site or site content? For example, you might want to control access at the site level, or you might need more restrictive security settings for a specific list, folder, or item.

  • How do you want to categorize and manage your users by using SharePoint groups? Groups do not have any permission until they are assigned a permission level for a specific site or for specific site content. When you assign permission levels to SharePoint groups at the site collection level, by default, all sites and site content inherit those permission levels.

For more information about using groups to help manage permissions, see Choose security groups (SharePoint Foundation 2010)).

About site permissions

You should understand the following concepts before designing your permissions plan.

  • Permissions Permissions grant a user the ability to perform specific actions. For example, the View Items permission allows a user to view items in a list or folder, but not to add or remove items. Permissions can be granted to individual users at site or site content levels.

    For information about available permissions, see User permissions and permission levels (SharePoint Foundation 2010).

  • Fine-grained permissions Fine-grained permissions are unique permissions on securable objects that are at a lower level in a site hierarchy, such as permissions on a list or library, folder, or item or document. Fine-grained permissions allow for greater granularity and customization of user permissions in a site collection.

  • Permission level Permission levels are collections of permissions that allow users to perform a set of related tasks. For example, the Read permission level includes the View Items, Open Items, View Pages, and View Versions permissions (among others), all of which are needed to view pages, documents, and items in a SharePoint site. Permissions can be included in more than one permission level.

    Permission levels are defined at the site collection level and can be customized by any user or group whose permission level includes the Manage Permissions permission. For more information about customizing permission levels, see Configure custom permissions (SharePoint Foundation 2010).

    The default permission levels are Limited Access, Read, Contribute, Design, and Full Control. For information about default permission levels and the permissions included in each level, see User permissions and permission levels (SharePoint Foundation 2010).

  • SharePoint group A SharePoint group is a group of users that are defined at site collection level for easy management of permissions. Each SharePoint group is assigned a default permission level. For example, the default SharePoint groups are Owners, Visitors, and Members, with Full Control, Read, and Contribute as their default permission levels respectively. Anyone with Full Control permission can create custom groups.

  • User A user can be a person with a user account from any authentication provider supported by the Web application. We recommend that you assign permissions to groups rather than users, although you can directly grant individual users permissions to a site or specific content. Because it is inefficient to maintain individual user accounts, you should assign permissions on a per-user basis only as an exception.

  • Securable object A securable object is a site, list, library, folder, document, or item for which permissions levels can be assigned to users or groups. By default, all lists and libraries within a site inherit permissions from the site. You can use list-level, folder-level, and item-level permissions to further control which users can view or interact with site content. You must first break the permission inheritance before you change or assign permissions for that securable object. You can resume inheriting permissions from the parent list or site at any time.

You can assign a user or group permissions for a specific securable object. Individual users or groups can have different permissions for different securable objects. The following diagram illustrates the relationships among permissions, users and groups, and securable objects.

Specific permission levels

About permission inheritance

Permissions on securable objects within a site are inherited from the parent object by default. You can break inheritance and use fine-grained permissions — unique permissions on the list or library, folder, or item or document level — to gain more control of the actions users can take on your site. For more information about the best practices for using fine-grained permissions, see Best practices for using fine-grained permissions

Stopping inheriting permissions copies the groups, users, and permission levels from the parent object to the child object, and then breaks the inheritance. When permission inheritance is broken, all permissions are explicit and any changes to parent object do not affect the child object. If you restore inherited permissions, the child object will inherit its users, groups, and permission levels from the parent again, and you will lose any users, groups, or permission levels that were unique to the child object.

For ease of management, use permission inheritance wherever possible.

Tip:

If you choose to break inheritance and use fine-grained permissions, you should use groups to avoid having to track individual users. Because people move in and out of teams and change responsibilities frequently, tracking those changes and updating the permissions for uniquely secured objects would be time-consuming and error-prone.

Plan for site permissions

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

Use the following guidelines to plan site permissions:

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

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

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

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

  3. Use permission levels rather than assign individual permissions.

Note:

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

  2. Microsoft SharePoint Foundation 2010 and SharePoint Server 2010 use Check Permissions to determine a user or group's permissions on all resources within a site collection. You can now find both the user's directly assigned permissions and the permissions assigned to any groups of which the user is a member by checking permissions for a specific site or site content.

Plan for permission inheritance

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

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

Securable object | Description | Unique or inherited permissions
SiteA | Group home page | Unique
SiteA/SubsiteA | Sensitive group | Unique
SiteA/SubsiteA/ListA | Sensitive data | Unique
SiteA/SubsiteA/LibraryA | Sensitive documents | Unique
SiteA/SubsiteB | Group shared project information | Inherited
SiteA/SubsiteB/ListB | Non-sensitive data | Inherited
SiteA/SubsiteB/LibraryB | Non-sensitive documents | Inherited

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

Securable object | Description | Unique or inherited permissions
SiteA | Group home page | Unique
SiteA/SubsiteA | Sensitive group | Unique
SiteA/SubsiteA/ListA | Non-sensitive data | Unique, but same permissions as SiteA
SiteA/SubsiteA/LibraryA | Non-sensitive documents, but with one or two sensitive documents | Inherited, with unique permissions at the document level
SiteA/SubsiteB | Group shared project information | Inherited
SiteA/SubsiteB/ListB | Non-sensitive data, but with one or two sensitive items | Inherited, with unique permissions at the item level
SiteA/SubsiteB/LibraryB | Non-sensitive documents, but with a special folder containing sensitive documents | Inherited, with unique permissions at the folder and document level

Worksheet

Use the following worksheet to fill in your site hierarchy, and then list the permissions needed at each level of the hierarchy and any permission inheritance:

  • Site and content security worksheet (http://go.microsoft.com/fwlink/p/?LinkID=213967&clcid=0x409)

See Also

Other Resources

Resource Center: Security and Authentication for SharePoint Foundation 2010


Determine permission levels and groups (SharePoint Foundation 2010)

A SharePoint group is a set of users that can be managed together. A permission level is a set of permissions that can be assigned to a specific group for a specific securable object. SharePoint groups and permission levels are defined at the site collection level and are inherited from the parent object by default. This article describes default groups and permission levels and helps you decide whether to use them as they are, customize them, or create different groups and permission levels.

In this article:

  • Review available default groups

  • Review available permission levels

  • Determine whether you need custom permission levels or groups

  • Worksheet

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

Review available default groups

SharePoint groups enable you to manage sets of users instead of individual users. These groups can contain many individual users, or they can include the contents of any corporate identity system, including Active Directory Domain Services (AD DS), LDAPv3-based directories, application-specific databases and new user-centric identity models, such as Windows Live ID. SharePoint groups do not confer specific rights to the site; they are a way to designate a set of users. You can organize your users into any number of groups, depending on the size and complexity of your organization or Web site. SharePoint groups cannot be nested.

The following table displays default groups that are created by using team site templates in SharePoint Foundation 2010. Each default group is assigned a default permission level.

Group name | Default permission level | Description
Visitors | Read | Use this group to grant people Read permissions to the SharePoint site.
Members | Contribute | Use this group to grant people Contribute permissions to the SharePoint site.
Owners | Full Control | Use this group to grant people Full Control permissions to the SharePoint site.

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

If the default groups do not map to the exact user groups in your organization, you can create custom groups. For more information about how to determine whether you need additional groups, see Determine whether you need custom permission levels or groups.

Besides the above SharePoint groups, there are also administrator groups for higher-level administration tasks. They are Windows administrators, SharePoint farm administrators, and site collection administrators.

For more information, see Choose administrators and owners for the administration hierarchy (SharePoint Foundation 2010).

Review available permission levels

The ability to view, change, or manage a site is determined by the permission level that you assign to a user or group. This permission level controls all permissions for the site and the child objects that inherit the site's permissions. Without the appropriate permission levels, your users might be unable to perform their tasks, or they might be able to perform tasks that you did not want them to perform.

By default, the following permission levels are available:

  • Limited Access Includes permissions that enable users to view specific lists, document libraries, list items, folders, or documents, without giving users access to all the elements of a site. You cannot edit this permission level directly.

    Note:

    If this permission level is removed, group members might be unable to navigate the site to access items, even if they have the correct permissions for an item within the site.

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

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

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

  • Full Control Includes all permissions.

For more information about permissions that are included in the default permission levels, see User permissions and permission levels (SharePoint Foundation 2010).

Determine whether you need custom permission levels or groups

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

Do you need custom groups?

The decision to create custom groups is fairly straightforward and has little effect on your site's security. You should create custom groups instead of using the default groups if either of the following situations applies:

  • You have more (or fewer) user roles within your organization than are apparent in the default groups. For example, if in addition to Designers, you have a set of people who are tasked with publishing content to the site, you might want to create a Publishers group.

  • There are well-known names for unique roles within your organization that perform very different tasks in the sites. For example, if you are creating a public site to sell your organization's products, you might want to create a Customers group that replaces Visitors or Viewers.

  • You want to preserve a one-to-one relationship between Windows security groups and the SharePoint groups. For example, if your organization has a security group called Web Site Managers, you might want to use that name as a group name for easy identification when managing the site.

  • You prefer other group names.

Do you need custom permission levels?

The decision to customize permission levels is less straightforward than the decision to customize SharePoint groups. If you customize the permissions assigned to a permission level, you must keep track of that change, verify that it works for all groups and sites affected by the change, and ensure that the change does not negatively affect your security or your server capacity or performance.

For example, if you customize the Contribute permission level to include the Create Subsites permission that is typically part of the Full Control permission level, Contributors can create and own subsites, and can potentially invite malicious users to their subsites or post unapproved content. If you change the Read permission level to include the Create Alerts permission that is typically part of the Contribute permission level, all members of the Visitors group can create alerts, which might cause performance issues.

You should customize the default permission levels if either of the following situations applies:

  • A default permission level includes all permissions except one that your users need to do their jobs, and you want to add that permission.

  • A default permission level includes a permission that your users do not need.

    Note:

    Do not customize the default permission levels if your organization has security or other concerns about a specific permission that is part of the permission level. If you want to make that permission unavailable for all users assigned to the permission level or levels that include that permission, turn off the permission for all Web applications in your server farm, rather than change all of the permission levels. To manage permissions for a Web application, see Manage permissions for a Web application (SharePoint Foundation 2010).

If you need to make several changes to a permission level, create a custom permission level that includes all of the permissions you need.

You might want to create additional permission levels if either of the following conditions applies:

  • You want to exclude several permissions from a specific permission level.

  • You want to define a unique set of permissions for a new permission level.

To create a permission level, you can create a permission level and then select the permissions that you want to include.

For more information about how to configure custom permissions, see Configure custom permissions (SharePoint Foundation 2010).

Note:

Some permissions depend on other permissions. If you clear a permission that another permission depends on, the other permission is also cleared.

Worksheet

Use the following worksheet to determine permission levels and groups to use:

  • Custom permission levels and groups worksheet (http://go.microsoft.com/fwlink/p/?LinkID=213966&clcid=0x409)


Choose security groups (SharePoint Foundation 2010)

This article describes the security and distribution groups that comprise the Active Directory® Domain Services (ADDS). This article also provides recommendations for using those groups to organize the users of your SharePoint sites.

In this article:

  • Decide whether to add security groups

  • Determine which security groups to use for granting access to sites

  • Decide whether to allow access for all authenticated users

  • Decide whether to allow access for anonymous users

  • Worksheet

Introduction

Managing users of SharePoint sites is easier if you assign permission levels to groups rather than to individual users. SharePoint group is a set of individual users and can also include Active Directory groups. In Active Directory Domain Services (ADDS), the following groups are commonly used to organize users:

  • Distribution group A group that is used only for e-mail distribution and that is not security-enabled. Distribution groups cannot be listed in discretionary access control lists (DACLs), which are used to define permissions on resources and objects.

  • Security group A group that can be listed in DACLs. A security group can also be used as an e-mail entity.

You can use security groups to control permissions for your site by adding security groups to SharePoint groups and granting permissions to the SharePoint groups. You cannot add distribution groups to SharePoint groups, but you can expand a distribution group and add the individual members to a SharePoint group. If you use this method, you must manually keep the SharePoint group synchronized with the distribution group. If you use security groups, you do not need to manage the individual users in the SharePoint application. Because you included the security group instead of the individual members of the group, ADDS manages the users for you.

Note:

For ease of security management, the following items are not recommended in managing Active Directory groups.

  • Assign permission levels directly to Active Directory groups.

  • Adding security groups that contain nested security groups, contacts, or distribution lists.

Decide whether to add security groups

Adding security groups to SharePoint groups provides centralized management of groups and security. The security group is the only place where you manage individual users. Once you add the security group to a SharePoint group, you do not have to manage security group members in that SharePoint group. If a user is removed from the security group, the user will be automatically removed from the SharePoint group.

However, using security groups in SharePoint sites does not provide full visibility of what is happening. For example, when a security group is added to a SharePoint group for a specific site, the site will not appear in the users' My Sites. The User Information List will not show individual users until they have contributed to the site. In addition, security groups with deep nested structure might break SharePoint sites.

Considering the previous advantages and disadvantages, here are the recommendations:

  • For intranet sites that are broadly accessed by your users, use security groups because you do not care about the individual users who accessed the intranet site home page.

  • For collaboration sites that are accessed by a small group of users, add users directly to SharePoint groups. In this case, there is more of a need to know who is a member so the group members know each other's e-mail addresses and how to contact each other.

Determine which security groups to use for granting access to sites

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

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

  • Small enough that you can assign appropriate permissions.

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

Decide whether to allow access for all authenticated users

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

Decide whether to allow access for anonymous users

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

If anonymous access is allowed for the Web application, site administrators can decide whether to grant anonymous access to a site or any of the content on that site.

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

  • Open sites for editing in Microsoft Office SharePoint Designer.

  • View sites in My Network Places.

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

    Important:

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

Permission policies provide a centralized way to configure and manage a set of permissions that applies to only a subset of users or groups in a Web application. You can manage permission policy for anonymous users by enabling or disabling anonymous access for a Web application. If you enable anonymous access for a Web application, site administrators can then grant or deny anonymous access at the site collection, site, or item level. If anonymous access is disabled for a Web application, no sites within that Web application can be accessed by anonymous users.

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

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

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

For more information about permission policies, see Manage permission policies for a Web application (SharePoint Foundation 2010).

Worksheet

Use the following worksheet to list the security groups that you will use and the permission levels that the groups will need at each level of your site hierarchy.

  • Site and content security worksheet (http://go.microsoft.com/fwlink/p/?LinkID=213967&clcid=0x409)


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

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

  • Windows server or SharePoint server farm

  • Shared services

  • Web application

  • Sites

  • Document library or list

  • Individual items

In this article:

  • Levels of administration

  • Worksheet

Levels of administration

Most levels of the server and site hierarchy have a corresponding administration group. The administration groups who have administrative permissions at different levels are described in the following list:

  • Windows 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. 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 by default. However, they can grant themselves access if need be.

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

      Note:

      Farm administrators and members of the local Administrators group can take ownership of specific site collections if necessary. For example, if a site administrator leaves the organization and a new administrator must be added, the farm administrator or a member of the local Administrators group can take ownership of the site collection to make the change. To take ownership, they can add themselves as the site collection administrator on the Application Management page.

  • Shared services level

    • Service application administrators These administrators are designated 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.

  • Web application level

    • The Web application level does not have a unique administrator group, but farm administrators have control over the Web applications within their scope. Members of the Farm Administrators group and members of the Administrators group on the local server can define a policy to grant individual users permissions at the Web application level. For more information about policy, see "Policy for Web applications" in the Logical architecture elements article.

  • Site level

    • Site collection administrators These administrators have the Full Control permission level on all Web sites within a site collection. They have Full Control access to all site content in that site collection, even if they do not have explicit permissions on that site. They can audit all site content and receive any administrative alert. A primary and a secondary site collection administrator can be specified during the creation of a site collection.

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

Worksheet

Use the following worksheet to choose administrators and owners for the administration hierarchy:

  • Administrators and owners worksheet (http://go.microsoft.com/fwlink/p/?LinkID=213965&clcid=0x409)


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

Published: September 16, 2010

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

Download the white paper from the following link: http://go.microsoft.com/fwlink/p/?LinkId=201596


Contribute permission level overview (SharePoint Foundation 2010)
See Also

Published: June 28, 2011

Permissions for the Contribute permission level in Windows SharePoint Services 3.0 and Microsoft SharePoint Foundation 2010 are the same. However, the Contribute permission level in SharePoint Foundation 2010 allows users to complete a more limited set of tasks.

For example, the default Contribute permissions in Windows SharePoint Services 3.0 allow users to edit scriptable Web files and Web Parts. Although the permissions are identical in SharePoint Foundation 2010, users who have the default Contribute permissions cannot edit scriptable Web files and Web Parts. The ability to edit scriptable Web files and Web Parts in SharePoint Foundation 2010 requires the Add and Customize Pages permission. The absence of this permission in the default Contribute permission level of SharePoint Foundation 2010 prevents users from editing scriptable Web files and Web Parts. Despite the absence of the same permission in the default Contribute permission level of Windows SharePoint Services 3.0, users who have the default Contribute permissions in Windows SharePoint Services 3.0 can edit scriptable Web files and Web Parts.

This article describes the Contribute permission level in SharePoint Foundation 2010 and does not describe how to enable users with the Contribute permission level to edit scriptable Web Parts. For more information, see Allow or prevent Contributors ability to edit scriptable Web Parts (SharePoint Foundation 2010).

In this article:

  • About updating Web files

  • About editing Web Parts

About updating Web files

Web files are a set of special files that provide a full range of customization of a Web page. These files can contain scripts (such as JavaScript) that can call Web services and interoperate with data on a site. Web files are stored as a modifiable list based on their file extensions. The default list of file extensions is as follows:

  • .ascx

  • .aspx

  • .asmx

  • .master

  • .jar

  • .swf

  • .xap

  • .xsf

  • .xsn

Note:

A member of the Farm Administrators group can use Windows PowerShell cmdlets to modify the above list.

Although users with the default Contribute permission level in Windows SharePoint Services 3.0 can complete the following tasks, users with the default Contribute permission level in SharePoint 2010 Products cannot complete these tasks:

  • Update the content of a Web file

  • Move a Web file

  • Upload a Web file

  • Rename a Web file

  • Publish, migrate, import and export a Web file

Note:

In SharePoint 2010 Products, a user must have the Add and Customize Pages permission to complete the above tasks.

Users with the default Contribute permission level in Windows SharePoint Services 3.0 and SharePoint 2010 Products can complete the following tasks:

  • Check in, check out, or revert a Web file

  • Revert a version from version history for a Web file

  • Delete a Web file

  • Recycle a deleted Web file

About editing Web Parts

Users who have the default Contribute permission level in Windows SharePoint Services 3.0 can add or edit Web Parts that developers have marked as unsafe for editing. However, users who have the default Contribute permission level in SharePoint 2010 Products cannot add or edit the same Web Parts.

Note:

To add or edit Web Parts that developers have marked as unsafe for editing, users in SharePoint 2010 Products must have the Add and Customize Pages permission.

The following Web Parts are marked as safe for editing by default and can be added or edited by users who have the default Contribute permission level:

  • Basic Chart Web Part

  • Image Web part

  • Page Viewer Web Part

  • Picture Slideshow Web Part

  • Relevant Documents Web Part

  • Site Users Web Part

  • Title Bar Web Part

  • User Tasks Web Part

A member of the Farm Administrators group can update permissions to allow users with the default Contribute permission level to add or edit Web Parts that are marked as unsafe for editing. For more information, see Allow or prevent Contributors ability to edit scriptable Web Parts (SharePoint Foundation 2010).

See Also

Concepts

Allow or prevent Contributors ability to edit scriptable Web Parts (SharePoint Foundation 2010)


Sandboxed solutions planning (SharePoint Foundation 2010)

Sandboxed solutions restrict access to network and local resources to provide greater security and stability. You can use sandboxed solutions for load balancing solutions, for solutions that have not been fully tested, and for deploying user solutions in a hosted environment. Sandboxed solutions run in a separate worker thread so that they cannot access resources that belong to other solutions, and they have limited access to local and network resources.

In this section

  • Sandboxed solutions overview (SharePoint Foundation 2010)

  • Plan sandboxed solutions (SharePoint Foundation 2010)


Sandboxed solutions overview (SharePoint Foundation 2010)
See Also

A Microsoft SharePoint Foundation 2010 solution is a deployable, reusable package that can contain features, site definitions, and other functionality. Solutions can be enabled or disabled individually. You can deploy a solution directly onto your SharePoint Foundation farm, or you can deploy the solution into a sandbox. A sandbox is a restricted execution environment that enables programs to access only certain resources, and that keeps problems that occur in the sandbox from affecting the rest of the server environment. Solutions that you deploy into a sandbox, which are known as sandboxed solutions, cannot use certain computer and network resources, and cannot access content outside the site collection they are deployed in. For more information about solutions, see Solutions Overview (http://go.microsoft.com/fwlink/p/?LinkID=156638).

Because sandboxed solutions cannot affect the whole server farm, they do not have to be deployed by a farm administrator. Sandboxed solutions can be deployed by a site collection administrator or, in certain situations, by a user who has the Full Control permission level at the root of the site collection. However, only a farm administrator can configure sandboxed solutions-related settings such as load balancing, tiers, quotas and resource points, and only a farm administrator can promote a sandboxed solution to run directly on the farm, outside the sandboxed environment.

This article introduces the concepts that are related to sandboxed solutions, describes the uses and benefits of sandboxed solutions, explains the differences between sandboxed solutions and solutions that are deployed on the farm, summarizes how sandboxed solutions are deployed, describes the sandboxed solution service, explains resource points and quotas, and describes the tasks associated with administering sandboxed solutions. This article does not contain detailed procedures about how to configure sandboxed solutions or to deploy sandboxed solutions. For information about how to perform specific tasks that are related to sandboxed solutions, see Sandboxed solutions administration (SharePoint Foundation 2010) and Installing, Uninstalling, and Upgrading Sandboxed Solutions (http://go.microsoft.com/fwlink/p/?LinkId=220252).

In this article:

  • Use and benefits of sandboxed solutions

  • Understanding sandboxed solutions

  • Deploying sandboxed solutions

  • Understanding the sandboxed solutions service

  • Understanding quotas and resource points

  • Administering sandboxed solutions

Use and benefits of sandboxed solutions

There are two common scenarios where it is appropriate to use sandboxed solutions:

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

  • When a hoster wants to let the owners of hosted SharePoint Foundation sites upload and run custom code.

The main benefits of using sandboxed solutions are as follows:

  • Sandboxed solutions can be added to a production SharePoint Foundation environment without the risk of affecting processes outside the sandbox.

  • Site collection administrators can deploy sandboxed solutions. This frees farm administrators from this task.

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

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

Understanding sandboxed solutions

Solutions are packaged as .wsp files that can contain features, site definitions, Web Parts, and assemblies. There are two kinds of solutions: farm and sandboxed. Farm solutions are deployed on front-end Web servers by a farm administrator, have full access to the server object model, and are not subject to any usage limits. By comparison, sandboxed solutions can be deployed by a site collection administrator — or by a user who has the Full Control permission level at the root of the site collection — into the solution gallery for a site collection. Sandboxed solutions have limited access to the server object model and run in a security restricted context that provides isolation and monitoring of the sandboxed solution's code. Farm administrators can enable or disable sandboxed solutions and set usage limits to protect servers in the farm from malicious code. For more information about solutions, see Building Blocks: Solutions (http://go.microsoft.com/fwlink/p/?LinkId=220253).

What sandboxed solutions cannot do

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

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

  • Connect to resources that are not located on the local farm.

  • Access a database.

  • Change the threading model.

  • Call unmanaged code.

  • Write to disk.

  • Access resources in a different site collection.

For more information about what a sandboxed solution can and cannot do, see What Can Be Implemented in a Sandboxed Solution (http://go.microsoft.com/fwlink/p/?LinkId=220254) and Restrictions on Sandboxed Solutions (http://go.microsoft.com/fwlink/p/?LinkId=220255).

Understanding load balancing for sandboxed solutions

SharePoint Foundation provides two load-balancing schemes that are used to determine which server to run a sandboxed solution on. Farm administrators can select one of the following load-balancing schemes to apply to sandboxed solutions across the farm:

  • Local load balancing The sandboxed solution runs on the same server that received the request.

  • Remote load balancing The server that the sandboxed solution runs on is selected based on solution affinity, and the sandboxed solution is run on a server where it is already loaded and has already been run. This saves time in servicing the request for the solution.

Regardless of which load-balancing scheme that you select, the sandboxed solutions service must be running on each server on which you want to run sandboxed solutions.

Note:

The sandboxed solutions service has different names, depending on where you access the service. In the SharePoint Central Administration Web site, the service is called the Microsoft SharePoint Foundation Sandboxed Code Service. In the Services console on the server, the service is called SharePoint User Code Host service. To avoid confusion, this article refers to the service as the "sandboxed solutions service."

You can increase the isolation of sandboxed solutions by using remote load balancing and by running the sandboxed solutions service only on specific servers. In a production environment, we recommend that you use remote load balancing and dedicate a separate server to running sandboxed solutions. For information about how to decide which load-balancing scheme to use, see Plan to load balance sandboxed solution code in Plan sandboxed solutions (SharePoint Foundation 2010).

Comparison of sandboxed and farm solutions

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

Aspect | Farm | Sandbox
Deployment process | Add the solution, and then deploy it to the farm. | Upload the solution to a site collection, and then activate it in the site collection.
Who can deploy | Farm administrator. | If the solution contains an assembly, only a site collection administrator can deploy it. If the solution does not contain an assembly, a user who has the Full Control permission level at the root of the site collection can deploy it.
Data access | Unrestricted. | The solution can only access content from the site collection in which it was deployed.
Process the solution runs in | Unrestricted IIS worker process, or whichever process the solution is deployed into. | Separate worker process that has restricted permissions.
Code access security | The solution developer can set the code access security policy when packaging the solution. | Restricted.
Monitoring | Not monitored. | Monitored, and limited by quotas set by the farm administrator.
Load balancing | Varies, based on the kind of solution. | Configurable separately from non-sandboxed solutions.
Solution functionality | Unrestricted. | Restricted, as described in What sandboxed solutions cannot do, earlier in this article.

Although sandboxed solutions are restricted in what code they can and cannot use, and what data that they can and cannot access, you can create a special kind of operation that runs in a full trust process and can be called from a sandboxed solution. This is known as a full-trust proxy. For more information about full-trust proxies, see Sandboxed Solutions in Partnership with Full-Trust Proxies (http://go.microsoft.com/fwlink/p/?LinkId=220256), and Chapter 4: Sandboxed Solutions (http://go.microsoft.com/fwlink/p/?LinkID=219528).

Deploying sandboxed solutions

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

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

  • Web Parts

  • Event receivers

  • Feature receivers

  • Custom Microsoft SharePoint Designer workflow activities

  • Microsoft InfoPath business logic

The following steps describe the tasks that are required to prepare for and deploy sandboxed solutions:

  1. A farm administrator performs the following tasks one time only:

    • Enables sandboxed solutions and starts the sandboxed solutions service on each server that will run sandboxed solutions. For information about how to enable the sandboxed solutions service, see Enable sandboxed solutions on the farm (SharePoint Foundation 2010).

    • Determines which load-balancing scheme to use. The load-balancing scheme applies to all sandboxed solutions in all site collections on the farm. For information about how to select a load-balancing scheme, see Configure load balancing for sandboxed solutions (SharePoint Foundation 2010).

    • Sets resource quotas that the combination of all sandboxed solutions in a site collection cannot exceed. For information about how to set resource quotas, see Configure resource points for sandboxed solutions (SharePoint Foundation 2010).

  2. A site collection administrator or a user who has the Full Control permission level at the root of the site collection uploads a solution to the site collection's solution gallery. For information about how to upload a solution to a solution gallery, see Installing, Uninstalling, and Upgrading Sandboxed Solutions (http://go.microsoft.com/fwlink/p/?LinkID=220252).

  3. A site collection administrator activates the solution. If the solution does not contain an assembly, a user who has the Full Control permission level at the root of the site collection can also activate the solution. Validation tools run against the solution. If the solution fails validation, it is not activated. For information about how to validate and activate a sandboxed solution, see Installing, Uninstalling, and Upgrading Sandboxed Solutions (http://go.microsoft.com/fwlink/p/?LinkID=220252).

Site collection administrators can monitor the resources that sandboxed solutions use and can deactivate sandboxed solutions in the site collection. If, after a sandboxed solution is deployed, it starts to use too many resources or causes problems in the sandboxed environment, a farm administrator can block a sandboxed solution from running on the farm. Optionally, a farm administrator can also remove the requirement that a sandboxed solution be run in a sandbox by reinstalling the solution as a farm solution. If the requirement to run in a sandbox is removed, when the solution next runs in any site collection in the farm, it will no longer run in a sandboxed environment. For information about how to block a sandboxed solution, see Block or unblock a sandboxed solution (SharePoint Foundation 2010). For information about how to install a farm solution, see Deploy solution packages (SharePoint Foundation 2010).

Understanding the sandboxed solutions service

The sandboxed solutions service manages the execution of sandboxed solutions throughout a farm. Two processes run within the sandboxed solution service: the worker process and the proxy process. Each sandboxed solution runs inside an application domain in the worker process. The worker process manages the sandboxed solutions by throttling the resources accessed by each solution and by stopping processes that take too long to execute. Each worker process is paired with a proxy process that handles calls to the SharePoint object model. For a detailed explanation of how the sandboxed solutions service works, see "How Does the Sandbox Execution Model Work?" in Sandboxed Solutions (http://go.microsoft.com/fwlink/p/?LinkId=220257).

Understanding tiers

Based on the average number of resources per request that sandboxed solutions use, they can be grouped into tiers within the sandboxed solutions service. As shown in the following illustration, a tier in the sandboxed solutions service contains one or more worker processes in which sandboxed solutions run. Each sandboxed solution runs in its own application domain, which is reused when the solution is invoked.

Tiers in the sandboxed solutions service

By default, all sandboxed solutions run in the sandboxed solutions service in one tier, which contains a single worker process. By default, that worker process can run up to 10 application domains. A farm administrator can configure additional tiers and worker processes within the sandboxed solutions service to separate sandboxed solutions for performance, security, and reliability. If a sandboxed solution in a particular worker process uses too many resources, that solution causes all the sandboxed solutions within that worker process to stop. Because sandboxed solutions are monitored for how much resources they use, they are automatically separated into additional tiers based on their resource usage from the previous day. Therefore, creating additional worker processes and tiers helps isolate sandboxed solutions and protects well-behaved solutions from poorly behaved solutions by forcing the poorly behaved solutions to run in different tiers.

Farm administrators can set the following properties for each tier:

  • ResourceMaxValue This property is a number that determines which sandboxed solutions will run in the tier. The default is 0, and it must be set to a larger value or the tier is never used.

  • MaximumWorkerProcesses This property represents the maximum number of worker processes that can run in the tier. The default is 1. Setting this property to more than 1 will cause an additional worker process to be created on the server that is handling the request.

  • MaximumAppDomainsPerProcess This property represents the maximum number of app domains that can run in a worker process in the tier. The default is 10.

  • MaximumConnectionsPerProcess This property represents the maximum number of allowed connections from the sandboxed solutions service to a worker process in the tier. The default is 1.

  • PriorityPerProcess This property represents the priority that the operating system has assigned to the worker processes in the tier.

For more information about tiers, see Using Execution Tiers to Protect Well-Behavied Sandboxed Solutions (http://go.microsoft.com/fwlink/p/?LinkId=220258) and Sandbox Tiers (http://go.microsoft.com/fwlink/p/?LinkId=217145). For information about how to configure tiers, see Configure sandboxed solutions service tiers (SharePoint Foundation 2010).

Understanding quotas and resource points

Sandboxed solutions are monitored for resource usage based on default quotas, which are monitored per site collection. When you set quotas for your site collections, you help prevent any sandboxed solution from using too many system resources. If one or more sandboxed solutions exceeds the quota that was set for the site collection, all sandboxed solutions in that site collection will automatically be stopped until the Solution Daily Resource Usage Update timer job runs, which typically occurs each night.

Quotas are managed through the SharePoint Central Administration Web site as a single number that controls the aggregate total of the resource points allowed per day for all sandboxed solutions in a site collection. Farm administrators can create a quota template that can be applied to any site collection in the farm. For information about how to plan quotas, see Plan quota management (SharePoint Foundation 2010). For information about how to create quota templates, see Create, edit, and delete quota templates (SharePoint Foundation 2010). For information about how to set the maximum resource quota for a specific site collection, see Change the storage limits for a site collection in Manage site collection storage limits (SharePoint Foundation 2010).

To restrict the resources that your sandboxed solutions consume, you define resource points. Resource points correspond to specific levels of resource usage that you can define for up to 15 resource measures (that is, system resources that you want to monitor), and are accrued for the whole site collection as sandboxed solutions run. When you view the resource measures inside a quota, you see the number of resources per point; these are the number of times that a particular resource can be used until a single resource point is accrued. For each resource measure, farm administrators can configure the following properties:

  • MinimumThreshold The minimum level of resource usage that must be reached before it is aggregated into the running total for the site collection quota.

  • AbosoluteLimit The maximum level of resource usage within a single request that can occur before the worker process is stopped.

  • ResourcesPerPoint The quantity or level of a specific resource that equals one resource point and is counted toward the total quota for the site collection.

When the resource usage reaches the limit specified by the ResourcesPerPoint property, the site collection accrues a resource point. If the cumulative number of resource points exceeds the quota for a site collection, all sandboxed solutions in the site collection will be disabled for the rest of the day.

The default resource point limits will probably be satisfactory for most scenarios. However, you can adjust individual resource point limits to allow increased limits where they are suitable. For more information about how to adjust individual resource point limits, see Configure resource points for sandboxed solutions (SharePoint Foundation 2010).

Farm administrators can fine-tune the resource point distribution by using Windows PowerShell in a script to configure the individual resource point distribution within the sandboxed solution quota for a site collection. For a list of the individual resource measures and the minimum threshold, absolute limit, and resources per point for each resource measure, see Resource Usage Limits on Sandboxed Solutions in SharePoint 2010(http://go.microsoft.com/fwlink/p/?LinkId=217149). For information about how to configure the settings for specific resource measures, see Configure resource points for sandboxed solutions (SharePoint Foundation 2010).

Note:

If you determine that a sandboxed solution is consistently misusing server resources, you can block that solution until the developer can correct the situation. For more information about how to block and unblock sandboxed solutions, see Block or unblock a sandboxed solution (SharePoint Foundation 2010).

Administering sandboxed solutions

As a farm administrator, you can do the following to administer sandboxed solutions and the sandboxed solutions service:

  • Enable the sandboxed solutions service on servers in the farm.

  • Change the load-balancing scheme for a farm.

  • Block or unblock a sandboxed solution on a farm.

  • Configure quotas for site collections on a farm.

  • Configure quota templates on a farm.

  • Use Windows PowerShell to do the following:

    • Display the quota settings for a site collection.

    • Display and configure resource points for specific resource measures.

    • Display and configure tiers for the sandboxed solutions service.

For more information about how to administer sandboxed solutions and the sandboxed solutions service, see Sandboxed solutions administration (SharePoint Foundation 2010).

Site collection administrators can do the following to administer sandboxed solutions:

  • Upload sandboxed solutions to the Solutions gallery in a site collection. For more information, see Installing, Uninstalling, and Upgrading Sandboxed Solutions in SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=220252).

  • Monitor the resource points used by individual sandboxed solutions. For more information, see "Using Site Collection Tools" in Chapter 4: Sandboxed Solutions (http://go.microsoft.com/fwlink/p/?LinkID=219528).

See Also

Concepts

Sandboxed solutions planning (SharePoint Foundation 2010)

Other Resources

Sandboxed solutions administration (SharePoint Foundation 2010)
Sandboxed Solutions Resource Center
Sandboxed solutions architecture (http://go.microsoft.com/fwlink/p/?LinkId=177368)
Sandboxed Solutions in SharePoint 2010
Installing, Uninstalling, and Upgrading Sandboxed Solutions in SharePoint 2010
Resource Center: Security and Authentication for SharePoint Foundation 2010
Resource Center: What's New in SharePoint Foundation 2010


Plan sandboxed solutions (SharePoint Foundation 2010)
See Also

Sandboxed solutions in Microsoft SharePoint Foundation 2010 restrict access to network and local resources to provide greater security and stability. You can use sandboxed solutions for load balancing solutions, for solutions that have not been fully tested, and to deploy user solutions in a hosted environment. Sandboxed solutions run in a separate worker process so that they cannot access resources that belong to other solutions, and they have limited access to local and network resources.

When you plan sandboxed solutions, decide first whether to use sandboxed solutions at all. You should determine whether your primary consideration is performance or security. A farm that uses sandboxed solutions generates more worker and proxy processes than a farm that does not use sandboxed solutions. Using sandboxed solutions provides more process isolation, which improves the security of your farm.

For more information about sandboxed solutions, see Sandboxed solutions overview (SharePoint Foundation 2010) and Sandboxed Solutions (http://go.microsoft.com/fwlink/p/?LinkId=220257).

In this article:

  • Determine when to use sandboxed solutions

  • Plan to load balance sandboxed solution code

  • Determine where to deploy sandboxed solutions

  • Determine who can deploy sandboxed solutions

  • Determine which site collections will run sandboxed solutions by using quotas

  • Plan resource usage quotas for sandboxed solutions

  • Plan sandboxed solutions service tiers

  • Plan sandboxed solutions governance

Determine when to use sandboxed solutions

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

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

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

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

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

When you use sandboxed solutions, you must start the sandboxed solutions service on each server on which you want to run the sandboxed solutions.

Plan to load balance sandboxed solution code

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

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

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

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

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

For more information, see Sandboxed solutions overview (SharePoint Foundation 2010).

Determine where to deploy sandboxed solutions

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

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

Determine who can deploy sandboxed solutions

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

You must be a member of the farm administrators group to perform administrative tasks such as enabling or disabling the sandboxed solutions service, blocking or unblocking a solution, and adjusting or resetting quotas and quota templates.

Note:

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

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

Determine which site collections will run sandboxed solutions by using quotas

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

To plan where you want to deploy sandboxed solutions, you should consider the following:

  • Which servers will run the sandboxed solutions service.

  • Which site collections will be able to run sandboxed solutions.

If you enable sandboxed solutions on some site collections, you should disable them on the remaining site collections by setting the quotas on those site collections to 0.

Plan resource usage quotas for sandboxed solutions

Sandboxed solutions are monitored for resource usage based on default quotas, which are monitored per site collection. If a sandboxed solution exceeds the cumulative total of the resource points, all sandboxed solutions in that site collection are disabled for the rest of the day. This helps administrators know when a particular sandboxed solution is making too many demands on shared resources or —in some cases — when a site collection that contains a resource-intensive sandboxed solution requires an increased quota.

Resource points are accrued for a whole site collection as sandboxed solutions run. When you view the resource measures in a quota you see the number of resources per point; these are the number of times that a particular resource can be used until a single resource point is accrued. When the resource usage reaches the limit that is specified by the ResourcePerPoint property, the site collection accrues a resource point. If the cumulative number of resource points exceeds the quota for a site collection, all sandboxed solutions in the site collection will be disabled for the rest of the day.

The default resource point limits are satisfactory for most scenarios. However, you can adjust individual resource point limits to permit increased limits where they are suitable. For more information about how to adjust individual resource point limits, see Configure resource points for sandboxed solutions (SharePoint Foundation 2010).

When you plan quotas for sandboxed solution, you should consider the following questions:

  • Will you adjust resources per point for any of the resource measure categories?

    You can define the resource limits for all sandboxed solutions. In some scenarios it might make sense to limit a particular resource that is more sensitive to misuse or over-consumption of resources, such as CPU cycles on a server where the processor is already taxed. You can adjust resource limits to restrict sandboxed solutions that might overuse resources. You should examine the list of resources that are monitored by the sandboxed solutions quotas and determine whether you have to make adjustments.

  • Will you adjust absolute limits for any of the resource categories?

    An absolute limit is the highest or lowest limit that a resource usage per request can reach before the request is stopped. If a particular resource category is overused and reaches the absolute limit, the sandboxed solution will be stopped. You should evaluate the resource categories to determine whether any of them require adjustment to an increased or lower absolute limit.

For a list of the individual resource measures and the minimum threshold, absolute limit, and resources per point for each resource, see Resource Usage Limits on Sandboxed Solutions in SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=217149). For information about how to configure the absolute limit and the resources per point for specific resource measures, see Configure resource points for sandboxed solutions (SharePoint Foundation 2010).

Plan sandboxed solutions service tiers

Based on the average number of resources that sandboxed solutions use, they can be grouped into tiers in the sandboxed solutions service. A tier in the sandboxed solutions service contains one or more worker processes in which sandboxed solutions run. Each sandboxed solution runs in its own application domain, which is reused when the solution is invoked. By default, all solutions run in the sandboxed solutions service in one tier. You can configure additional tiers and worker processes within the sandboxed solutions service to separate solutions for performance, security, and reliability. Sandboxed solutions automatically separate into additional tiers based on their resource usage. For more information about tiers, see Sandboxed solutions overview (SharePoint Foundation 2010) and Sandbox Tiers (http://go.microsoft.com/fwlink/p/?LinkId=217145).

You can configure as many tiers as necessary, and as many worker processes, connections, and application domains as you want. However, creating too many tiers adversely affects the performance of your SharePoint Foundation server. When you plan to configure the sandboxed solutions service, you should consider the following questions:

  • How many tiers are you going to create?

    Configuring multiple tiers enables you to separate "well-behaved" sandboxed solutions from "poorly behaved" sandboxed solutions, which frequently crash or use lots of resources. By running sandboxed solutions in separate tiers, you reduce the effect that poorly behaved sandboxed solutions have on well-behaved sandboxed solutions. This helps make the system more stable and responsive. In general, you should not have to have more than two or three tiers to achieve separation of sandboxed solutions.

  • For each tier, how many worker processes are you going to set?

    The largest number of sandboxed solutions that run at the same time in a particular tier can be calculated by using the following formula:

    Number of work processes in the tier × maximum connections per process = largest number of concurrently running sandboxed solutions in a single tier

    By configuring tiers to run more worker processes, you can run more sandboxed solutions concurrently in the farm. Adding more worker processes can increase throughput on a given server, but only up to a certain point. Because the overhead of additional worker processes can reduce the overall throughput of a server, you should configure fewer than 20 worker processes across all tiers on a single server.

  • How many connections per process must you have?

    The maximum number of connections per process should always be less than or equal to the number of application domains per process. If two sandboxed solutions are running in the same process at the same time and one of them crashes, the other will also crash. The larger the number of maximum connections per process, the larger the number of sandboxed solutions that can run in the same process at the same time, which makes it more likely that a sandboxed solution that crashes will affect other running requests. It is typically better to have smaller numbers of connections per process in tiers in which the ResourceMaxValue property is higher, where the sandboxed solutions are typically less reliable. More reliable sandboxed solutions run in tiers where the ResourceMaxValue property is lower. In general, you should increase the number of connections per process to increase throughput, which will reduce the effect caused by other sandboxed solutions that might crash in the same process.

  • How many application domains per process must you have?

    Only one sandboxed solution can run in each application domain at any time. Therefore, application domains represent the number of sandboxed solutions that can be loaded at the same time. You should plan to configure at least as many application domains as the number of connections per process.

For information about how to configure the tiers, see Configure sandboxed solutions service tiers (SharePoint Foundation 2010).

Plan sandboxed solutions governance

As long as you are still planning for sandboxed solutions, you should consider your processes for governance issues. This includes the following:

  • At what point will the farm administrator block or unblock a sandboxed solution? Identifying the administrative policy for blocking and unblocking sandboxed solutions can help eliminate confusion.

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

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

See Also

Concepts

Sandboxed solutions overview (SharePoint Foundation 2010)

Other Resources

Sandboxed solutions administration (SharePoint Foundation 2010)
Sandboxed Solutions Resource Center
Sandboxed solutions architecture (http://go.microsoft.com/fwlink/p/?LinkId=177368)
Sandboxed Solutions in SharePoint 2010
Installing, Uninstalling, and Upgrading Sandboxed Solutions in SharePoint 2010


Plan for collaboration sites (SharePoint Foundation 2010)

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

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

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

For more information about collaboration sites and architectural planning, see Design sample: collaboration sites (SharePoint Foundation 2010).

In this article:

  • Determine number of collaboration sites

  • Specific paths

  • Additional paths

Determine number of collaboration sites

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

Specific paths

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

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

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

    Note:

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

Additional paths

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

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

  • Create the site collection under the /sites path.

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

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

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

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

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

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

Integration with Microsoft SharePoint Workspace 2010

Microsoft SharePoint Workspace 2010 provides a rich client for Microsoft SharePoint Foundation 2010, which enables real-time synchronization of desktop content with SharePoint documents and lists. Microsoft SharePoint Workspace 2010 also provides options for creating ad hoc Groove collaboration workspaces and shared folder workspaces. Information can be easily synchronized both online and offline with a designated SharePoint site or with external partners and offsite team members via shared workspaces. Microsoft SharePoint Workspace 2010 is installed automatically with enterprise versions of Microsoft Office 2010 or it can be installed separately from the Microsoft Download Center (http://go.microsoft.com/fwlink/p/?LinkID=48516).

For more information, see Plan for SharePoint Workspace 2010.


Document management planning (SharePoint Foundation 2010)

These articles will guide you in planning the document management features of your solution that is based on Microsoft SharePoint Foundation.

SharePoint Foundation includes document management features that you can use to control the life cycle of documents in your organization — how they are created, reviewed, and published, and how they are ultimately disposed of or retained.

The articles in this chapter include the following:

  • Identify users and analyze document usage (SharePoint Foundation 2010) describes how to create a document management planning team. It also provides guidance on how to determine the kinds of documents used in your enterprise and how to analyze the stages in the life cycle of these documents.

  • Document library planning (SharePoint Foundation 2010) describes how to use document libraries to organize documents in your enterprise.

  • Content type and workflow planning (SharePoint Foundation 2010) describes how to plan content types, which are the SharePoint Foundation mechanism to define and share the attributes of documents, list items, and folders. This article also describes how to use the SharePoint Foundation workflow feature to design document-related processes.

  • Versioning, content approval, and check-out planning (SharePoint Foundation 2010) describes how to plan content governance by using versioning, check-in and check-out, and approval for publishing content.

  • Co-authoring overview (SharePoint Foundation 2010) describes the feature and provides administrators an understanding of the settings that can be used to manage co-authoring.


Document management overview (SharePoint Foundation 2010)

Published: May 26, 2011

This article provides a high-level description of the various elements of a document management solution that is based on Microsoft SharePoint Foundation 2010.

In this article:

  • The elements of a document management system

  • The planning process

Document management controls the life cycle of documents in your organization — how they are created, reviewed, and published, and how they are ultimately disposed of or retained. Although the term "management" implies that information is controlled from the top of the organization, an effective document management system should reflect the culture of the organization that uses it. The tools that you use for document management should be flexible enough to enable you to tightly control a document's life cycle, if that fits your enterprise's culture and goals, but also to let you implement a more loosely structured system, if that better suits your enterprise.

The elements of a document management system

An effective document management solution specifies the following:

  • What kinds of documents and other content can be created in an organization.

  • What template to use for each kind of document.

  • What metadata to provide for each kind of document.

  • Where to store a document at each stage of its life cycle.

  • How to control access to a document at each stage of its life cycle.

  • How to move documents within the organization as team members contribute to the documents' creation, review, approval, publication, and disposition.

SharePoint Foundation 2010 includes features that implement all these aspects of document management. To ensure that information workers can easily take advantage of these capabilities without having to depart from their day-to-day operations and familiar tools, applications in the Microsoft Office system — such as Microsoft Outlook and Microsoft Word — also include features that support each stage in a document's life cycle.

The planning process

The document management planning process consists of the following major steps:

  1. Identify document management roles Ensure that your plans incorporate the feedback of your organization's key stakeholders, you have the best team to implement the solution, and you know who will participate in document management processes.

  2. Analyze document usage After you identify who works on documents, determine the kinds of documents they work on and how they use them. For more information, see Identify users and analyze document usage (SharePoint Foundation 2010).

  3. Plan the organization of documents You can organize documents in site collections, sites, and libraries. SharePoint Foundation 2010 offers a range of features to help organize and store documents, from specialized sites to loosely structured document libraries for quick document creation and collaboration. Within a library, you can further organize content into folders and subfolders. For more information, see Document library planning (SharePoint Foundation 2010).

  4. Plan how content moves between locations It might be necessary to move or copy a document from one site or library to another at different stages of its life cycle. For example, the publishing process might include moving a document from a staging site to a public Internet site. For more information, see "Plan the flow of content" in Document library planning (SharePoint Foundation 2010).

  5. Plan content types Use content types to organize information about documents, such as metadata, document templates, and workflow processes. This is an important step to help you organize your documents and enforce consistency across your organization. For more information, see Content type and workflow planning (SharePoint Foundation 2010).

  6. Plan workflows When you plan workflows for your organization, you can control and track how documents move from one team member to another as each participant collaborates in a document's life cycle. SharePoint Foundation 2010 includes workflows for common team tasks such as reviewing and approving documents. SharePoint Foundation 2010 also supports creating and installing custom workflows. For more information, see Content type and workflow planning (SharePoint Foundation 2010).

  7. Plan content control You can plan the appropriate degree of control based on content type or storage location. For example, you might require that documents in a particular library be checked out before they can be edited. For more information, see Versioning, content approval, and check-out planning (SharePoint Foundation 2010).


Identify users and analyze document usage (SharePoint Foundation 2010)

Published: May 26, 2011

The first step to plan your document management solution is to identify users and analyze how documents are used. This article provides guidance to identify users and analyze document usage for your solution that is based on Microsoft SharePoint Foundation 2010.

In this article:

  • Identify users

  • Analyze document usage

  • Worksheets

Before reading this article, you should understand the document management planning process described in Document management overview (SharePoint Foundation 2010).

Identify users

To identify the stakeholders and participants in your document management solution, you can use a survey to collect this information. For example, your survey might contain the following questions:

  • Who in your organization creates documents?

  • What kinds of documents do they create?

  • What role does the user of the document have?

    • Who reviews documents?

    • Who edits documents?

    • Who uses documents?

    • Who approves the publication of documents?

    • Who designs Web sites used for hosting documents?

    • Who deploys and maintains the servers on which documents are stored?

Identifying content stakeholders can help you ensure that your document management solution is comprehensive and that you design sites and document libraries that suit your enterprise's content needs and processes.

Analyze document usage

After you identify your content stakeholders, collect information from them that will help you analyze how documents are used in your organization. This is an important part of the planning process because the analysis helps you determine the following:

  • How document libraries should be structured.

  • Which site templates to use.

  • How many sites you will need.

  • Which physical server topology you will need to implement your solution.

The information to collect includes:

  • Document type, such as equity research note, employee performance review, internal memo, or product specification.

  • The purpose of each document type, such as "provides customers with recommendations about equities along with supporting data."

  • The author of each document type (it is helpful to list the role of the author — such as "financial analyst or "product manager" — rather than individual names).

  • The users of each document type, such as "customers" or "team members."

  • The format of the document. If the document has to be converted from one format to another at any point in its life cycle, record that information.

  • Other roles that apply to the document's life cycle, such as "technical reviewer" or "copy editor."

  • Location of the document, such as "client computer," "Web server," or "file server." Note that this question could have multiple answers, for example when a document is authored on a client computer and then published to a Web server.

The following are examples of information that might be collected and recorded in the worksheet from two different organizations in an enterprise.

Type Purpose Author User Role Format Other Roles Location

Equity research note

Gives premium customers of a financial service guidance on whether to buy or sell one or more stocks

Financial analyst

Customer

DOCX (for authoring); PDF (for publishing)

Reviewer (technical); reviewer (legal); approver; copy editor; site administrator

  • Authoring site

  • Testing site

Analysis The separate authoring and publishing formats require a format conversion. The large number of reviewers requires one or more workflows (business processes implemented on the server). The two sites (authoring and testing) require mechanisms for moving the content from one site to another.

Type Purpose Author User Role Format Other Roles Location

Employee performance review

Evaluates the performance of an employee — including self-evaluation and manager's evaluation

Information worker; manager

Managers; human resources specialists

.DOC

Reviewer (human resources); reviewer (legal); approver (upper manager)

  • Client computer

  • E-mail server (as attachment)

  • Corporate Web server

Analysis Two authors and multiple reviewers require one or more workflows.

Worksheets

Use the following worksheets to record the information discussed in this article:

  • Document management participants worksheet (http://go.microsoft.com/fwlink/p/?LinkId=165871)

  • Analyze document usage worksheet for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=219646)


Document library planning (SharePoint Foundation 2010)
See Also

This article describes how to plan document libraries in your Microsoft SharePoint Foundation document management solution.

In this article:

  • Determine library type

  • Plan the flow of content

  • Plan Information Rights Management

Document libraries are collections of files on SharePoint Foundation 2010 that you share with other site users. Most document management features are delivered through document libraries. As part of document management planning, you should determine the kind of document libraries that best fit your organization's needs. If you plan document libraries for multiple sites, you might have to plan the flow of content from one site to another. If you plan to use document libraries as storage locations, you can customize the Microsoft Office Professional 2010Open dialog box and the Save dialog box to ensure that documents are stored in the preferred location.

Before reading this article, you should understand the document management process described in Document management overview (SharePoint Foundation 2010).

Determine library type

When you identify which document libraries best match your organization's needs, you might also determine that you need multiple sites or site collections. For example, if you are authoring content for publication to external customers, you might need one site in which to author and review content and a separate site, perhaps in a separate SharePoint Foundation 2010 installation, in which to publish your content.

When you plan document libraries for multiple sites, you might also have to plan how content flows from one site to another — by manual processes, workflows, or custom solutions. For more information, see Plan the flow of content, later in this article.

The following table lists typical uses of document libraries.

Library Purpose

Library in a team site

Collaboration; easy sharing of content among peers; content control, such as versioning; SharePoint Foundation 2010 search.

Library in a portal area

Content that is intended for a wider audience in the organization; similar to a library in a team site, but typically implemented by using a stricter review and approval process.

Slide library

Support for sharing, managing, and reusing Microsoft PowerPoint slides.

Note:

Do not create folders in a slide library if you know that content from this site will be deployed to another farm or site collection by using content deployment. Sites that contain slide libraries with folders cannot be imported or exported.

The following example shows how to use the analysis that you completed in the Analyze document usage section in Identify users and analyze document usage (SharePoint Foundation 2010) to help you plan document library organization for your enterprise. In this example, Contoso Ltd. delivers content to clients based on market research. The content is created primarily by consultants who operate remotely. This is performed in a cycle in which the following steps occur:

  1. A partner evaluates engagement ideas and requests for proposals.

  2. After a contract is established, a project manager assembles a team of consultants and creates an engagement-specific working site in which the results of the research are recorded and the project is completed.

  3. When the project is finished, the deliverable documents are published to a secured Internet site, where customers have access to them.

  4. The team writes best practices documents and case studies based on the project.

  5. Knowledge managers collect, organize, and archive the best practices and other documents.

  6. Deliverables, contracts, and other documents are retained as corporate records.

  7. By using the content maintained by the knowledge managers, partners evaluate opportunities and create new proposals.

The following table shows a document usage analysis for this scenario.

Documents | Purpose | Author | Users | Format
Engagement ideas and requests | Develop new customer engagements | Project leader | Sales manager; project leader | .docx
Proposals | Describe a proposed customer engagement | Project leader | Project managers; project team members; customers | .docx
Contracts | Commit to a consulting engagement | Lawyer | Project leader; project manager; sales manager; customers | .docx
Research results and project deliverable drafts | Generate documents related to the customer engagement | Project leader; project contributor; consultant | Editors; technical reviewers | .docx and other types
Deliverable documents | Generate final deliverables, probably converted from .docx format | Project leader | Customers | .pdf
Best practices and case study documents | Capture organizational knowledge | Project contributor; consultant; knowledge manager | All team members | Various types

This document usage analysis suggests the following requirements:

  • Project leaders need libraries in team sites for storing engagement ideas, engagement requests, and proposal drafts.

  • Lawyers need libraries in a portal or on a centralized document management site for storing contract templates and active contracts.

  • Project leaders and contributors need libraries in team sites for authoring research results, deliverables, and case studies.

  • Customers need libraries in an Internet site for viewing final deliverables.

Plan the flow of content

Content in a document management solution is often dynamic, moving from one site to another as needed to meet users' needs. When you plan document libraries, therefore, you often plan the flow of content from one library or site to another. SharePoint Foundation includes the following ways to move content, either manually or dynamically:

  • You can create custom workflows that copy or move content from one site or library to another. A workflow guides a document through a business process and assigns tasks to participants when their role in the document's life cycle becomes active. A workflow can be designed to move a document from one site or library to another. For information about how to plan workflows, see Content type and workflow planning (SharePoint Foundation 2010) and Plan workflows (SharePoint Foundation 2010).

  • Authors can copy a document to a library in any site in which they have authoring permissions. The relationship between the source and the destination document is maintained so that the copy can be refreshed as needed.

  • By using Web Folders or Network Places, an author can manually copy or move the content of a document library from one library or site to another.

  • By using the Copy command, an author can copy documents to the Document Center site.

  • By using a custom workflow, an author can copy documents to document libraries on the Internet site.

Plan Information Rights Management

Information Rights Management (IRM) enables content creators to control and protect their documents. The contents of rights-managed documents are encrypted and supplied with a publishing license that imposes restrictions on users. These restrictions vary depending on the level of users' permissions. Typical restrictions include making a document read-only, disabling copying of text, not allowing users to save a copy of the document, or preventing users from printing the document. Client applications that read IRM-supported file types use the issuance license inside an IRM-managed document to enforce the restrictions on users who access the document.

For more information about IRM as it is implemented by Rights Management Services (RMS), see RMS FAQ (http://go.microsoft.com/fwlink/p/?LinkId=230459).

Microsoft SharePoint Foundation 2010 supports using IRM on documents that are stored in document libraries. To add other file types, an administrator must install a protector for that file type, which is a program that controls the encryption and decryption of rights-managed documents for a type of file.

By using IRM in SharePoint Foundation 2010, you can centrally control which actions users can take on documents when the documents are opened from libraries in SharePoint Foundation 2010. This is in contrast to IRM applied to documents that are stored on client computers, where the owner of a document can choose which rights to assign to each user of the document. Use IRM on document libraries to control sensitive content that is stored on the server. For example, if you are making a document library available to preview upcoming products to other teams within your enterprise, you could use IRM to prevent the teams from publishing the content to audiences outside your organization.

When IRM is enabled on a document library and a document in an IRM-supported format is downloaded from the server to a client application, SharePoint Foundation 2010 encrypts the document and adds an issuance license. When the document is uploaded back to the server, SharePoint Foundation 2010 decrypts the file and stores it in the library in a form that is not encrypted. By only encrypting documents when they are downloaded and decrypting them when they are uploaded, SharePoint Foundation 2010 enables features such as search and indexing to operate as usual on the files in the IRM-protected document library. The IRM permissions that are applied to a document when users download it from a document library are based on each user's permissions to the content in the SharePoint Foundation 2010 security settings. The following table describes how SharePoint Foundation 2010 permissions are converted to IRM permissions.

SharePoint Foundation 2010 permissions | IRM permissions
Manage Permissions, Manage Web | Full control, as defined by the client. This generally allows a user to read, edit, copy, save, and modify or remove the permissions of rights-managed content.
Edit List Items, Manage List, Add and Customize Pages | Edit, copy, and save permissions. You can optionally enable users who have these permissions to print documents from the document library.
View List Item | Read permissions. A user can read the document, but cannot copy or update its content. You can optionally enable users who have view list item permissions to print documents from the document library.
Other | No other permissions map to IRM permissions.

See Also

Concepts

Content type and workflow planning (SharePoint Foundation 2010)
Plan workflows (SharePoint Foundation 2010)
Configure Information Rights Management (SharePoint Foundation 2010)


Content type and workflow planning (SharePoint Foundation 2010)
See Also

A content type is a reusable collection of metadata (columns), workflow, behavior, and other settings for a category of items or documents in a Microsoft SharePoint Foundation 2010 list or document library. Content types enable you to manage the settings for a category of information in a centralized, reusable way. A workflow lets you attach a business process to items in SharePoint Foundation 2010. This article describes content types and workflows and provides guidance about how to plan to integrate them into your SharePoint Foundation 2010 document management solution.

In this article:

  • Content type overview

  • Plan document content types

  • Plan list content types

  • Plan workflows

  • Worksheet

Before you use the Content type and workflow planning (http://go.microsoft.com/fwlink/p/?LinkId=219645) worksheet included with this article to plan your content types and workflows, ensure that you have read Identify users and analyze document usage (SharePoint Foundation 2010) and completed the "Analyze document usage" and the "Document participants" worksheets associated with that article.

Content type overview

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

  • Properties to associate with items of its type.

  • Workflows that can be started from items of its type.

  • Document templates (for document content types).

  • Custom features.

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

Note:

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

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

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

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

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

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

In sites that are based on SharePoint Foundation 2010, each default list item or library item, — such as Contact, Task, or Document, — has a corresponding core content type in the site's content type gallery. When you plan content types, you can use these core content type definitions as starting points and base new content types on existing ones as needed. Or, you can use core content types.

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

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

Properties integration with the Office 2010 release

In the Microsoft Office system, when a user edits a document from a SharePoint Foundation 2010 document management server, a Document Information Panel is shown at the top of the document. The Document Information Panel displays an editable form of the document's properties on the server.

SharePoint Foundation 2010 makes it easy to customize the property form for a content type. When you configure a content type, you can start Microsoft InfoPath 2010, which generates a default property form that is based on the properties of the content type. The default form includes the same controls, layout, and schema that InfoPath 2010 would use if no custom form were defined. You can then customize and deploy the form as you would any other InfoPath 2010 form. For example, you can add your company logo, fonts, and color scheme to a form; connect it to a custom data source; add conditional logic; and design form features that are available to users based on their roles.

Along with editing properties in the Document Information Panel, authors who use Microsoft Word 2010 can insert properties that are defined on the server into their documents. For example, if the document properties include a project manager name, this name can be inserted into the title page, the footer, or anywhere else the name is used in the document. If a new project manager is assigned to a project, the Project Manager property can be updated on the document management server. This updated project manager name will be reflected in every instance of this property that was inserted into a document.

Using metadata with content types

Metadata is information about a document that is used to categorize and classify your content. Metadata is associated with a content type as a column. Metadata can provide contextual information about your document by associating it with an author, subject, audience, language, and so on Unlike properties, metadata are stored as columns and can be indexed and searched on by the SharePoint Search engine.

Metadata added at the site collection level can be associated with content types. By using metadata with content types, all later content types can inherit some or all of their metadata from the parent content type at the site collection level. Additional metadata can then be added at a lower level, such as an individual document.

Column templates

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

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

Folder content types

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

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

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

Plan document content types

The first stage in planning document content types is to review each document type that is listed in your Analyze document usage (http://go.microsoft.com/fwlink/p/?LinkId=219646) worksheet to determine whether an existing content type will work for that kind of document. Each document content type should inherit its settings directly from the core Document content type or from a content type that is descended from the Document content type. This ensures that the basic columns for your document types, such as Title and Created By, are present and that you can associate a template with the content type. If a core content type (such as Document) is sufficient, enter the content type name in the Content Type column of the "Analyze document usage" worksheet.

For information about changing the core content types, download the white paper "Guidance for editing pre-defined content types and site columns" (http://go.microsoft.com/fwlink/p/?LinkId=260922.

Plan list content types

The elements of a list content type include the columns of metadata that are associated with the content type and workflows that can run on items of that content type. Use a list content type to define a kind of list item that is unique to your solution. For example, in a customer call center solution, in which support professionals investigate and resolve customers' technical issues, a list content type could be used to standardize the data for each support incident and to track the incident by using a workflow.

For information about changing the core content types, download the white paper "Guidance for editing pre-defined content types and site columns" (http://go.microsoft.com/fwlink/p/?LinkId=260922.

Plan workflows

Workflows implement business processes on documents, Web pages, forms, and list items inSharePoint Foundation 2010. They can be associated with libraries, lists, or content types.

In document management, use workflows to route documents from person to person so that they can each complete their document management tasks, such as reviewing documents, approving their publication, or managing their disposition. Also, use custom workflows to move documents from one site or library to another. For example, you can design a workflow to copy a document from one site to another when the document is scheduled to be archived.

SharePoint Foundation 2010 includes workflows that address the following document management needs:

  • Collect Feedback Sends a document for review.

  • Approval Sends a document for approval, often as a prerequisite to publishing it.

  • Disposition Manages document expiration and disposition.

  • Collect Signatures Routes a document for signatures.

  • Translation Management Manages the translation of a document into one or more languages.

  • Three-state Manages business processes that require organizations to track the status of an issue or item through three different states (phases).

Associate a workflow with a content type when you want to make that workflow available whenever that content type is being used. For example, a purchase order content type could require approval by a manager before the transaction can be completed. To ensure that the approval workflow is always available when a purchase order is initiated, create a Purchase Order content type and associate the approval workflow with it. Then add the Purchase Order content type to any document libraries in which purchase orders will be stored.

To plan workflows for your document management solution, analyze each document content type that you plan to implement and identify the business processes that have to be available to run on content of that type. Then identify the workflows you will have to make available for that content.

The following is a sample table that analyzes workflows for a contract content type.

Contract Process | Contract Workflow | New?
Review drafts. | Collect feedback | No
Get approval from the manager and the legal counsel. | Approval | No
Resolve open issues. | Issue tracking | No
Get signatures. | Collect signatures | No

For more information, see Plan workflows (SharePoint Foundation 2010).

Worksheet

Use the following worksheet to record the information discussed in this article:

  • Content type and workflow planning worksheet for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=219645)

See Also

Concepts

Identify users and analyze document usage (SharePoint Foundation 2010)
Plan workflows (SharePoint Foundation 2010)
Workflow deployment process (SharePoint Foundation 2010)


Versioning, content approval, and check-out planning (SharePoint Foundation 2010)

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

In this article:

  • About versioning, content approval, and check-outs

  • Plan versioning

  • Plan content approval

  • Plan check-out and check-in

Before reading this article, you should understand the document management planning process described in Document management overview (SharePoint Foundation 2010).

About versioning, content approval, and check-outs

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

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

  • Content approval is the method by which site members who have approver permissions control the publication of content.

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

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

Plan versioning

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

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

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

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

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

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

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

Note:

Regardless of the versioning control that you choose, it is important to remember that each version of a document stores a complete copy of the document in SQL Server and to consider what effect this might have on storage space. If you use co-authoring, see Co-authoring overview (SharePoint Foundation 2010).

Plan content approval

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

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

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

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

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

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

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

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

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

Plan check-out and check-in

You can require that users check out documents from a document library before they edit the documents. The benefits of requiring check-out and check-in include the following:

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

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

If your solution requires that users check in and check out documents to edit them, you can use features in Microsoft Office 2010 client applications that support these actions. Users can check out documents, undo check-outs, and check in documents from Office 2010 client applications.

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

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

Note:

You should not check out a document when you use the co-authoring functionality. For more information, see Co-authoring overview (SharePoint Foundation 2010).


Co-authoring overview (SharePoint Foundation 2010)
See Also

Published: August 12, 2010

In today's highly connected work environment, documents created by multiple authors, editors, and stakeholders are becoming the rule, instead of the exception. Organizations look to the communication and collaboration capabilities of Microsoft SharePoint Foundation 2010 to help them foster communication and collaboration between end-users while reducing administration required to support it. Microsoft Office 2010 continues this trend with co-authoring functionality for Microsoft PowerPoint 2010, Microsoft Word 2010, and Microsoft OneNote 2010 documents on SharePoint Foundation 2010.

Co-authoring removes barriers to server-based document collaboration and helps organizations to reduce the overhead associated with traditional document sharing through attachments. Co-authoring simplifies collaboration by enabling multiple users to work productively on the same document without intruding on one another's work or locking one another out. This functionality requires no additional server setup and is the default state for documents stored in SharePoint Foundation 2010. Co-authoring functionality is managed by using the same tools and technologies that are already used to manage SharePoint Foundation, helping to minimize the impact on administrators.

In this article:

  • Co-authoring functionality in SharePoint Foundation 2010

  • Understanding the end-user experience

  • Important considerations

  • OneNote Notebooks

  • Software Version Requirements

  • Co-authoring in a mixed Office environment

  • Performance and scalability

Co-authoring functionality in SharePoint Foundation 2010

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

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

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

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

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

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

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

Understanding the end-user experience

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

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

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

The Excel 2010 client application does not support co-authoring workbooks in SharePoint Foundation 2010. However, the Excel client application does support non-real-time co-authoring workbooks stored locally or on network (UNC) paths by using the Shared Workbook feature. Co-authoring workbooks in SharePoint Foundation is supported by using the Microsoft Excel Web App, included with Office Web Apps. Office Web Apps is available to users through Windows Live and to business customers with Microsoft Office 2010 volume licensing and document management solutions based on Microsoft SharePoint 2010 Products. For more information, see Office Web Apps (Installed on SharePoint 2010 Products).

Important considerations

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

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

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

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

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

  • Versioning period - The versioning period determines how often SharePoint Foundation will create a new version of a Word or PowerPoint document that is being co-authored. Setting this period to a low value will capture versions more often, for more detailed version tracking, but may require more server storage. The versioning period does not impact OneNote notebooks. This value can be altered by adjusting the coAuthoringVersionPeriod property on the server. For more information about adjusting this setting, see Configure the co-authoring versioning period (SharePoint Foundation 2010).

  • Check out - When a user checks out a document for editing, this locks the document for editing to only that user, which prevents co-authoring. Require Check Out should not be enabled in document libraries where co-authoring will be used. By default, Require Check Out is not enabled in SharePoint Foundation 2010. Users should not check out documents manually when co-authoring is being used.

OneNote Notebooks

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

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

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

Software Version Requirements

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

Note:

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

Co-authoring in a mixed Office environment

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

Mixed environment that has Microsoft Office PowerPoint and Word 2007

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

Mixed environment that has Microsoft Office OneNote 2007

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

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

Performance and scalability

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

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

See Also

Concepts

Co-authoring administration (SharePoint Foundation 2010)


Business data and processes planning (SharePoint Foundation)

The topics in this section will help you plan and build solutions that integrate business processes with your organization's data.

In this section:

  • Plan for Business Connectivity Services (SharePoint Foundation 2010)

  • Plan workflows (SharePoint Foundation 2010)


Plan for Business Connectivity Services (SharePoint Foundation 2010)

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

In this section:

  • Business Connectivity Services overview (SharePoint Foundation 2010)

  • Business Connectivity Services security overview (SharePoint Foundation 2010)

  • Diagnostic logging in Business Connectivity Services overview (SharePoint Foundation 2010)


Business Connectivity Services overview (SharePoint Foundation 2010)
See Also

Microsoft SharePoint Foundation 2010 includes Microsoft Business Connectivity Services, which are a set of services and features that provide a way to connect SharePoint solutions to sources of external data and to define external content types that are based on that external data. External content types resemble content types and allow the presentation of and interaction with external data in SharePoint lists (known as external lists) and Web Parts. External systems that Microsoft Business Connectivity Services can connect to include SQL Server databases, SAP applications, Web services (including Windows Communication Foundation Web services), custom applications, and Web sites based on SharePoint. By using Microsoft Business Connectivity Services, you can design and build solutions that extend SharePoint collaboration capabilities to include external business data and the processes that are associated with that data.

Microsoft Business Connectivity Services solutions use a set of standardized interfaces to provide access to business data. As a result, developers of solutions do not have to learn programming practices that apply to a specific system or adapter for each external data source. Microsoft Business Connectivity Services also provide the run-time environment in which solutions that include external data are loaded, integrated, and executed.

Typical solutions based on Business Connectivity Services

Information workers typically perform much of their work outside the formal processes of a business system. For example, they collaborate by telephone or e-mail messages, use documents and spreadsheets from multiple sources, and switch between being online and offline. Solutions that are based on Microsoft Business Connectivity Services can be designed to fit within these informal processes that information workers use:

  • They can be built by combining multiple services and features from external data systems to deliver solutions that are targeted to specific roles.

  • They support informal interactions and target activities and processes that occur mostly outside formal enterprise systems. Because they are built by using SharePoint 2010 Products, solutions that are based on Microsoft Business Connectivity Services promote collaboration.

  • They help users perform tasks within the familiar user interface of SharePoint 2010 products.

Here are some examples of solutions that are based on Microsoft Business Connectivity Services:

  • Help desk An enterprise implements its help desk, which provides internal technical support, as a solution that is based on Microsoft Business Connectivity Services. Support requests and the technical support knowledge base are stored in external databases and are integrated into the solution by using the Business Data Connectivity service. The solution displays both support requests and the knowledge base in the Web browser. Information workers can view their current requests and tech support specialists view the requests assigned to them. Workflows take support issues through each of their stages. Managers on the technical support team can view dashboards that display help desk reports. Typical reports indicate the number of support issues assigned to each support specialist, the most critical issues currently, and the number of support incidents that are handled by each support specialist during a given time period.

  • Sales Dashboard A sales dashboard application helps sales associates in an organization quickly find the information that they need and enter new data. Sales orders and customer information are managed in an external database and integrated into the solution by using Microsoft Business Connectivity Services. Depending on their roles, team members can view sales analytics information, individual team members' sales performance data, sales leads, and a customer's contact information and orders. Sales professionals can view their daily calendars, view tasks assigned to them by their managers, collaborate with team members, and read industry news.

Security Note:

We recommend that you use Secure Sockets Layer (SSL) on all channels between client computers and front end servers. Also we recommend using Secure Sockets Layer or Internet Protocol Security (IPSec) between servers running Microsoft SharePoint Foundation 2010 and external systems.

See Also

Other Resources

Resource Center: Security and Authentication for SharePoint Foundation 2010
Resource Center: What's New in SharePoint Foundation 2010


Business Connectivity Services security overview (SharePoint Foundation 2010)
See Also

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

In this article:

  • About this article

  • Business Connectivity Services security architecture

  • Business Connectivity Services authentication overview

  • Business Connectivity Service permissions overview

  • Securing Business Connectivity Services

About this article

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

Business Connectivity Services security architecture

This section describes the Microsoft Business Connectivity Services security architecture.

Security Note:

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

Accessing external data

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

BCS security architecture from a Web browser

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

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

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

    Important:

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

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

  5. Microsoft Business Connectivity Services can pass credentials to databases and Web services that are configured to use claims-based authentication. For an overview of claims-based authentication, see Plan authentication methods (SharePoint Foundation 2010).

Business Connectivity Services authentication overview

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

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

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

Configuring Business Connectivity Services for credentials authentication

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

  • Windows authentication:

    • Windows Challenge/Response (NTLM)

    • Microsoft Negotiate

  • Authentication other than Windows

    • Forms-based

    • Digest

    • Basic

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

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

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

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

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

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

Authentication mode Description

PassThrough

Passes the credentials of the logged-on user to the external system. This requires that the user's credentials are known to the external system.

Note:

If the Web application is not configured to authenticate with Windows credentials, the NT Authority/Anonymous Logon account is passed to the external system rather than the user's credentials.

This mode is called User's Identity in the Microsoft Business Connectivity Services administration pages and in SharePoint Designer 2010.

RevertToSelf

When the user is accessing external data from a Web browser, this mode ignores the user's credentials and sends the application pool identity account under which the BCS runtime is running on the Web server to the external system. When the user is accessing external data from an Office client application, this mode is equivalent to PassThrough mode, because Microsoft Business Connectivity Services running on the client will be running under the user's credentials.

This mode is called BDC Identity in the Microsoft Business Connectivity Services administration pages and in SharePoint Designer 2010.

Note:

By default, RevertToSelf mode is not enabled. You must use Windows PowerShell to enable RevertToSelf mode before you can create or import models that use RevertToSelf. For more information, see RevertToSelf authentication mode. RevertToSelf mode is not supported in hosted environments.

WindowsCredentials

For external Web services or databases, this mode uses a Secure Store Service to map the user's credentials to a set of Windows credentials on the external system.

This mode is called Impersonate Windows Identity in the Microsoft Business Connectivity Services administration pages and in SharePoint Designer 2010.

Credentials

For an external Web service, this mode uses a Secure Store Service to map the user's credentials to a set of credentials that are supplied by a source other than Windows and that are used to access external data. The Web service should use basic or digest authentication when this mode is used.

Important:

To help preserve security in this mode, we recommend that the connection between the Microsoft Business Connectivity Services and the external system should be secured by using Secure Sockets Layer (SSL) or Internet Protocol Security (IPSec).

This mode is called Impersonate Custom Identity in the Microsoft Business Connectivity Services administration pages and in Office SharePoint Designer.

RDBCredentials

For an external database, this mode uses a Secure Store Service to map the user's credentials to a set of credentials that are supplied by a source other than Windows. To help preserve security in this mode, we recommend that the connection between the Microsoft Business Connectivity Services and the external system should be secured by using Secure Sockets Layer (SSL) or IPSec.

This mode is called Impersonate Custom Identity in the Microsoft Business Connectivity Services administration pages and in Office SharePoint Designer.

DigestCredentials

For a WCF Web service, this mode uses a Secure Store Service to map the user's credentials to a set of credentials using Digest authentication.

This mode is called Impersonate Custom Identity - Digest in the Microsoft Business Connectivity Services administration pages and in SharePoint Designer 2010.

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

Business Connectivity Services authentication

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

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

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

Configuring Business Connectivity Services for claims-based authentication

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

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

Claims authentication in BCS

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

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

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

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

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

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

Business Connectivity Service permissions overview

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

Caution:

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

Note:

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

What can permissions be set on?

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

Metadata store hierarchy
Note:

In the previous hierarchy graphic, labels in parentheses are the names of objects as they are defined in the Microsoft Business Connectivity Services metadata schema. The labels that are not in parentheses are the names of each object as it appears in the user interface of the Business Data Connectivity service. For a full discussion of the Microsoft Business Connectivity Services metadata schema, along with walkthroughs of many development tasks, see the Microsoft SharePoint 2010 Software Development Kit (http://go.microsoft.com/fwlink/p/?LinkId=166117&clcid=0x409 ).

The hierarchy of objects in a metadata store determines which objects can propagate their permissions to other objects. In the illustration, each object on which permissions can be set, and optionally propagated, is shown with a solid line; each object that takes its permissions from its parent object is shown with a dotted line. For example, the illustration shows that an External System (LobSystem) can be secured by assigning permissions to it, but an Action cannot be assigned permissions directly. Objects that cannot be assigned permissions take the permissions of their parent object. For example, an Action takes the permissions of its parent External Content Type (Entity).

Security Note:

When the permissions on an object in a metadata store are propagated, permission settings to all children of that item are replaced by the permissions of the propagating object. For example, if permissions are propagated from an External Content Type, all Methods and Method Instances of that External Content Type receive the new permissions.

Four permission levels can be set on the metadata store and the objects it contains:

  • Edit

    Security Note:

    The Edit permission should be considered highly privileged. With the Edit permission, a malicious user can steal credentials or corrupt a server farm. We recommend that, in a production system, you give Edit permission only to users whom you trust to have administrator-level permissions.

  • Execute

  • Selectable in clients

  • Set permissions

The following table defines the meaning of these permissions on the various objects for which they can be set.

Object | Definition | Edit permissions | Execute permissions | Selectable in clients permissions | Set permissions permissions
Metadata store | The collection of XML files, stored in the Business Data Connectivity service, that each contain definitions of models, external content types, and external systems. | The user can create new external systems. | Although there is no "Execute" permission on the metadata store itself, this setting can be used to propagate Execute permissions to child objects in the metadata store. | Although there is no "Selectable in clients" permission on the metadata store itself, this setting can be used to propagate these permissions to child objects in the metadata store. | The user can set permissions on any object in the metadata store by propagating them from the metadata store.
Model | An XML file that contains sets of descriptions of one or more external content types, their related external systems, and information that is specific to the environment, such as authentication properties. | The user can edit the model file. | The "Execute" permission is not applicable to models. | The "Selectable in clients" permission is not applicable to models. | The user can set permissions on the model.
External system | The metadata definition of a supported source of data that can be modeled, such as a database, Web service, or .NET connectivity assembly. | The user can edit the external system. Setting this permission also makes the external system and any external system instances that it contains visible in SharePoint Designer. | Although there is no "Execute" permission on an external system itself, this setting can be used to propagate Execute permissions to child objects in the metadata store. | Although there is no "Selectable in clients" permission on an external system itself, this setting can be used to propagate these permissions to child objects in the metadata store. | The user can set permissions on the external system.
External content type | A reusable collection of metadata that defines a set of data from one or more external systems, the operations available on that data, and connectivity information related to that data. | Although there is no "Edit" permission on an external content type itself, this setting can be used to propagate these permissions to child objects in the metadata store. | The user can execute operations on the external content type. | The user can create external lists of the external content type. | The user can set permissions on the external content type.
Method | An operation related to an external content type. | The user can edit the method. | Although there is no "Execute" permission on a method itself, this setting can be used to propagate Execute permissions to child objects in the metadata store. | There is no "Selectable in clients" permission on a method. | The user can set permissions on the method.
Method instance | For a particular method, describes how to use a method by using a specific set of default values. | The user can edit the method instance. | The user can execute the method instance. | There is no "Selectable in clients" permission on a method instance. | The user can set permissions on the method instance.

Special permissions on the Business Data Connectivity service

Along with the general capabilities of setting permissions described earlier, there is a set of special permissions for the Business Data Connectivity service:

  • Farm administrators have full permissions to the Business Data Connectivity service. This is necessary, for example, to be able to maintain or repair an instance of the service. However, be aware that the farm administrator does not have execute permissions on any object in the metadata store and this right must be given explicitly by an administrator of an instance of the Business Data Connectivity service if it is required.

  • Windows PowerShell users are farm administrators and can run commands on the Business Data Connectivity service.

  • Application pool accounts on front end servers have the same permissions to the Business Data Connectivity service as farm administrators. This permission is necessary to generate deployment packages based on Microsoft Business Connectivity Services.

  • SharePoint Designer users should, in most cases, be given the following permissions on the whole metadata store: Edit, Execute, and Selectable in clients. SharePoint Designer users should not be given Set permissions permissions. If necessary, you can limit the permissions of the SharePoint Designer user to a subset of the metadata store.

    Caution:

    To help ensure a secure solution, SharePoint Designer should be used to create external content types in a test environment in which Edit permissions can be assigned freely. When deploying the tested solution to a production environment, remove the edit permissions to help protect the integrity of the external data.

Common tasks and their related permissions

This section describes common tasks in the Business Data Connectivity service and the required permissions to perform them.

Task | Permissions
Create a new object in the metadata store | To create a new metadata object, a user must have edit permissions on the parent metadata object. For example, to create a new method in an external content type, a user must have permissions on the external content type. See the illustration earlier in this article for child/parent relationships among objects in the metadata store.
Delete an object from the metadata store | To delete a metadata object, a user must have edit permissions on that object. To delete an object and all its child objects (such as deleting an external content type and all its methods) the edit permission is also required on all the child objects.
Adding an external content type to a model | To add an external content type to a model, a user must have edit permissions on the model.
Importing models | To import a model to the metadata store, a user must have edit permissions on the metadata store. If explicit permissions are not assigned on the model, the user who imported it will be given edit permissions on the model.
Exporting models | To export a model from the metadata store, a user must have edit permissions on the model and on all external systems contained in the model.
Generating a deployment package | Deployment packages are generated by the application pool account that is used by the front-end server. This account has full permissions to the metadata store so that it can perform this task.
Setting initial permissions on the metadata store. | When an instance of the Business Data Connectivity service is first created, its metadata store is empty. The farm administrator has full permissions to the store and can set initial permissions.

Securing Business Connectivity Services

This section discusses additional measures that can be used to help secure Business Connectivity Services

Service account

For security isolation, the Business Data Connectivity service application and the front-end server should not use the same service account.

Server to server communication

Securing the communication between the Business Data Connectivity service application and external systems helps ensure that sensitive data is not compromised. You need to use an encrypted communication channel to protect data that is sent between servers running SharePoint Foundation 2010 and external systems. Internet Protocol security (IPsec) is one method that can be used to help protect communication. The choice of which method to use depends on the specific communication channels you are securing and the benefits and tradeoffs that are most appropriate for your organization.

Applications that use FileBackedMetadataCatalog

For security reasons, RevertToSelf authentication mode is disabled on SharePoint Foundation 2010 by default. However, this does not prevent applications that use the FileBackedMetadataCatalog class from importing models and executing calls that use RevertToSelf authentication. This can result in elevating privileges for users by granting privileges to the application pool account. You should review all applications to ensure that they do not use FileBackedMetadataCatalog class and RevertToSelf authentication before installing them on a production system.

See Also

Other Resources

Resource Center: What's New in SharePoint Foundation 2010


Diagnostic logging in Business Connectivity Services overview (SharePoint Foundation 2010)
See Also

You can troubleshoot issues related to Microsoft Business Connectivity Services on servers that are running Microsoft SharePoint Foundation 2010 by using event logs and trace logs on either client or server. Also, each entry to the event log or trace log has an associated Activity ID that can be used to track a problem from the server to the external data source.

Note:

In addition to the logging methods discussed in this topic, you can use Microsoft System Center Operations Manager Management Pack to monitor a solution that is based on Microsoft Business Connectivity Services. For more information about how to configure System Center Operations Manager Management Pack, see the guide included in the management pack download at Microsoft SharePoint 2010 Products Management Pack (http://go.microsoft.com/fwlink/?LinkId=184971).

In this article:

  • Diagnostic logging in Business Connectivity Services

  • About Activity IDs

  • Diagnostic logging on servers

  • Example: using diagnostic logging

Diagnostic logging in Business Connectivity Services

For solutions that are based on Microsoft Business Connectivity Services, diagnostic logging occurs on servers that are running Microsoft SharePoint Foundation. There are two logs: the event log and the trace log. They both record diagnostic information that Microsoft Business Connectivity Services generate. Event logs record error messages. Trace logs contain more in-depth information, such as stack traces and informational messages. In general, trace logs provide more details than event logs.

Each logged item of information includes an Activity ID, which is a unique GUID value. Activity ID values can also be sent to external systems when a Create, Update, or Delete operation occurs on an item. By using Activity IDs, an action can be traced from the server or client to the external data source. For more information about Activity IDs, see About Activity IDs .

You can set the level of diagnostic logging for the event log and for the trace log. This will limit the types and amount of information that will be written to each log. The following tables define the levels of logging available for the event log and trace log:

Event log levels

Level | Definition
None | No logging occurs.
Critical | This message type indicates a serious error that has caused a major failure in the solution.
Error | This message type indicates an urgent condition. All error events should be investigated.
Warning | This message type indicates a potential problem or issue that might require attention. Warning messages should be reviewed and tracked for patterns over time.
Information | Information messages do not require any action, but they can provide valuable data for monitoring the state of your solution.
Verbose | This event log level corresponds to lengthy events or messages.

Trace log levels

Level | Definition
None | No trace logs are written.
Unexpected | This level is used to log messages about events that cause solutions to stop processing. When set to log at this level, the log will only include events at this level.
Monitorable | This level is used to log messages about any unrecoverable events that limit the solution's functionality but do not stop the application. When set to log at this level, the log will also include critical errors (Unexpected level).
High | This level is used to log any events that are unexpected but which do not stall the processing of a solution. When set to log at this level, the log will include warnings, errors (Monitorable level) and critical errors (Unexpected level).
Medium | When set to this level, the trace log includes everything except Verbose messages. This level is used to log all high-level information about operations that were performed. At this level, there is enough detail logged to construct the data flow and sequence of operations. This level of logging could be used by administrators or support professionals to troubleshoot issues.
Verbose | When set to log at this level, the log includes messages at all other levels. Almost all actions that are performed are logged when you use this level. Verbose tracing produces many log messages. This level is typically used only for debugging in a development environment.

Diagnostic logs are useful both in development and production environments, but requirements for the level of logging will probably differ depending on the kind of environment. When planning for diagnostic logging in Microsoft Business Connectivity Services, consider the business needs and the lifecycle stage of the environment before you set the logging level.

For example, during solution design, you might, for debugging purposes, set both logging levels to Verbose to capture all the messages that are generated about the state of the system. Conversely, in a production environment, you might want to capture only messages in the categories High, Monitorable, and Unexpected for trace logs and the categories Critical and Error for event logs. Doing this will save logging disk space and limit any negative performance effects of logging.

About Activity IDs

A unique GUID value called an Activity ID is generated for each Create, Update, or Delete operation on external data in a solution based on Microsoft Business Connectivity Services. Anything related to the operation that is logged in the trace log or event log includes its Activity ID value.

Important:

In the event logs and trace log files on the server, Activity ID values are labeled as "CorrelationId" values.

The Activity ID value generated for a Create, Update, or Delete operation is sent to the external system along with other information related to that operation. If the external system has a logging mechanism, this value can be captured and logged on that system. Therefore, if an operation causes entries to the SharePoint logs, the same operation can be traced to the external system by using its Activity ID value. This facilitates end-to-end troubleshooting of issues.

Often, an operation such as Create will cause multiple events to be written to the logs. When this happens, the same Activity ID value is used for all events that are logged for the operation. This is useful in troubleshooting issues because the recurring value of the Activity ID facilitates finding all events for a particular operation. Conversely, when the same type of operation occurs repeatedly, a unique Activity ID value is generated for each operation instance. For example, if an item of an external content type is updated twice, each update operation will be associated with a unique Activity ID value.

Tip:

In some circumstances, the Business Data Connectivity service will retry an operation if it failed to go through to the external system. In those cases, the same Activity ID will be used for the retried operation.

Diagnostic logging on servers

By default, Microsoft Business Connectivity Services logging is enabled on SharePoint Foundation servers. The default logging levels are:

  • For the event log: Critical and Error

  • For the trace log: Medium

Should diagnostic logging of Microsoft Business Connectivity Services become disabled, enable it by selecting Business Connectivity Services on the Diagnostic Logging page in SharePoint Foundation Central Administration. You can also use Windows PowerShell to configure event logs and trace logs on the server. For example, you can change the drive that logging writes to, and you can set the level of verbosity of logging.

For more information about logging in SharePoint Foundation 2010, such as how to set the location of the log files, see Configure diagnostic logging (SharePoint Foundation 2010).

You can use Windows PowerShell to view the event logs on the server by and you can export the logs, for example to a spreadsheet program. For more information, see View diagnostic logs (SharePoint Foundation 2010).

Microsoft Business Connectivity Services output two categories to the trace log on SharePoint Foundation front end Web servers: BDC_Shared_Services and SS_Shared_Service. You can use the Event Viewer to open the trace log, and you can filter on the relevant log entries by searching on "SPS_BusinessData" (for Microsoft Business Connectivity Services outputs) and "SPS_SecureStoreService".

Example: using diagnostic logging

This short, simplified scenario illustrates the use of diagnostic logging in a production environment. An enterprise has deployed a new time card submission solution based on Microsoft Business Connectivity Services. This solution uses an external system to store timecard information for employees, such as vacation time and sick leave, and to interact with employees and the payroll system when employees report absence from work. Employees use a Web Part to interact with the system.

On the server farm, the logging levels are set to the default values for Microsoft Business Connectivity Services:

  • For the event log: Critical and Error

  • For the trace log: Medium

In this scenario, an employee submits a value for the number of sick leave hours but neither the employee nor his manager receives a confirming email message reporting that the sick leave time was successfully submitted. The employee calls the internal technical support service and reports the issue.

The support technician recognizes that the time card application is based on Microsoft Business Connectivity Services. She checks the event log but finds no error associated with the identity of the user at the time the user submitted the time card request. She then checks the trace log, where she finds the evidence of the activity: an Update operation associated with the user at the appropriate time. The Update operation in the trace log includes an Activity ID value which the support technician notes.

The support technician knows that logging is also supported on the external system. Using the Activity ID, she locates the item logged on the external system and finds evidence of an error written to the log at the end of the Update operation: the update failed because the employee had used up all of his allotted sick leave time. She also notes that there is no log entry confirming that an email message was generated on the external system immediately at the end of the Update operation. The support technician concludes that there is an error in the logic of the time card application. Although the application properly did not allocate sick time pay when the employee exceeded his allotted amount of hours, it failed to generate an email message informing the employee of the issue. She reports the problem to the development team that created the application and the development team updates the application.

See Also

Concepts

Monitoring overview (SharePoint Foundation 2010)
Configure diagnostic logging (SharePoint Foundation 2010)
Business Connectivity Services overview (SharePoint Foundation 2010)


Plan workflows (SharePoint Foundation 2010)
See Also

Administrators plan workflows to ensure that processes follow a consistent sequence of actions during a business process.

A workflow is a feature of Microsoft SharePoint Foundation 2010 that moves documents or list items through a specific sequence of actions or tasks related to a business process. Workflows can be used to manage common business processes such as document review or approval.

In this section:

  • Workflows overview (SharePoint Foundation 2010)

    This article introduces the types of business processes that workflows can facilitate and describes the workflows included in SharePoint Foundation 2010.

  • Choose a workflow authoring tool (SharePoint Foundation 2010)

    This article describes the different Microsoft supported workflow authoring tools, how they can be used together for rapid workflow authoring.

  • Plan for workflow security and user management (SharePoint Foundation 2010)

    This article highlights some aspects of workflow behavior that relate to security and raises other issues for administrators and workflow developers to consider when they plan to configure and develop workflows.

  • Approval Workflow: A Scenario (SharePoint Foundation 2010)

    This article shows how an approval-type workflow that is created in Microsoft SharePoint Designer 2010 or Workflow Designer in Visual Studio 2010, and that is then hosted by using SharePoint Foundation 2010 might look.

See Also

Concepts

Workflow administration (SharePoint Foundation 2010)


Workflows overview (SharePoint Foundation 2010)

The workflow feature in Microsoft SharePoint Foundation 2010 enables solution architects, designers, and administrators to improve business processes. Fundamentally, a workflow consists of two things: the forms that a workflow uses to interact with its users and the logic that defines the workflow's behavior. Understanding how workflows are created requires knowledge about both.

In this article:

  • Workflow overview

  • Benefits of using workflows

  • Predefined workflows

  • Sample workflow scenario

  • Workflow types: Declarative and compiled

  • Workflow templates

  • Workflow associations

Workflow overview

Workflows in SharePoint Foundation 2010 enable enterprises to reduce the amount of unnecessary interactions between people as they perform business processes. For example, to reach a decision, groups typically follow a series of steps. The steps can be a formal, standard operating procedure, or an informal implicitly understood way to operate. Collectively, the steps represent a business process. The number of human interactions that occur in business processes can inhibit speed and the quality of decisions. Software that simplifies and manages this "human workflow" enables the automation of interactions among groups who participate in the process. This automation results in more speed, overall effectiveness of the interactions, and often a reduction in errors.

You can model business processes by using flow charts, such as those created using Microsoft Visio 2010 and can represent business processes by using workflow terminology. You can automate business processes, such as document approval, by associating a workflow with data in SharePoint Foundation 2010. For example, you can create a workflow to route a document for review, track an issue through its various stages of resolution, or guide a contract through an approval process.

One problem that many IT departments face when implementing business processes that require participation of information workers is that those processes do not integrate with the way people actually work. For a business process to be effective, it must be integrated with the familiar, everyday tools and applications used in the workplace so that it becomes part of the daily routine of information workers. In the electronic workplace, this includes integration with e-mail, calendars, task lists, and collaboration Web sites.

Benefits of using workflows

The primary benefits of using workflows are to facilitate business processes and improve collaboration.

Business processes that enterprises use depend on the flow of information or documents. These business processes require the active participation of information workers to complete tasks that contribute to their workgroup's decisions or deliverables. In SharePoint Foundation 2010, these types of business processes are implemented and managed by using workflows.

Examples of business processes that could be facilitated by workflows include:

  • Contract approval Guiding a proposed contract among members of an organization who must approve or reject it.

  • Expense reporting Managing the submission of an expense report and associated receipts, reviewing the report, approving it, and reimbursing the submitter.

  • Technical support Guiding the progress of a technical support incident as it is opened by a customer, investigated by a support engineer, routed to technical experts, resolved, and added to a knowledge base.

  • Interviewing Managing the process of interviewing a job candidate. This includes scheduling and tracking interview appointments, collecting interview feedback as it accumulates, making that feedback available to subsequent interviewers, and facilitating the hire/no-hire decision.

Automating business processes

Businesses depend on business processes. Although those processes often involve software, the most important processes in many organizations depend on people. Workflows can automate interactions among the people who participate in a process to improve how that process functions, increase its efficiency, and lower its error rate.

Many processes can benefit from automated support for human interactions. Examples include the following:

  • Approval A common aspect of human-oriented business processes is the requirement to get approval from multiple participants. What is being approved can vary widely, ranging from a Microsoft Word document that contains next year's marketing plan to an expense report from a trip to a conference. In every case, some number of people must review the information, perhaps appending comments, and then indicate approval or rejection.

  • Coordinating group efforts Whether it is preparing a response to a request for proposal (RFP), managing the translation of a document into one or more languages, or something else, many processes require people to work together in an organized way. By defining the steps of the process through an automated workflow, the group's work can be made more efficient and the process itself more predictable.

  • Issue tracking Many business processes generate a list of outstanding issues. An automated workflow can be used to maintain that list, assign issues to the people who can resolve them, and track the status of that resolution.

To support these kinds of automated business processes, SharePoint Foundation 2010 can run workflow applications. Based on Windows Workflow Foundation 3.5, these applications interact with people through a Web browser. For more information about Windows Workflow Foundation 3.5, see Windows Workflow Foundation (http://go.microsoft.com/fwlink/p/?LinkId=127778).

Workflows improve collaboration

Workflows help people collaborate on documents and manage project tasks by implementing business processes on documents and items on a SharePoint site or site collection. Workflows help organizations follow consistent business process practices. Workflows increase organizational efficiency and productivity through management of the tasks and steps involved in those business processes. Workflows speed up decision making by helping to ensure that the appropriate information is made available to the appropriate people at the time that they need it. Workflows also help ensure that individual workflow tasks are completed by the appropriate people and in the appropriate sequence. This enables the people who perform these tasks to concentrate on performing the work instead of on the work processes.

For example, on a SharePoint Foundation 2010 site, you can create a workflow to be used with a document library to route a document to a group of people for approval. When the author starts this workflow, the workflow creates document approval tasks, assigns these tasks to the workflow participants, and then sends e-mail alerts to the participants.

When the workflow is in progress, the workflow owner or the workflow participants can check progress on the Workflow Status page. When the workflow participants complete their workflow tasks, the workflow ends, and the workflow owner is automatically notified that the workflow has finished.

Predefined workflows

For sites and site collections created in Microsoft SharePoint Foundation 2010, a predefined Three-state workflow is included by default, and is the only predefined workflow available in SharePoint Foundation 2010. The Three-state workflow can be used to manage business processes that require organizations to track a high volume of issues or list items, such as customer support issues, sales leads, or project tasks.

The Three-state workflow is so named because it tracks the status of an issue or item through three different states, and through two transitions between the states. For example, when a Three-state workflow is initiated on an issue in an Issues list, SharePoint Foundation 2010 creates a task for the assigned user. When the user completes the task, the workflow changes from its initial state (Active) to its middle state (Resolved) and creates a task for the assigned user. When the user completes the task, the workflow changes from its middle state (Resolved) to its final state (Closed), and creates another task for the user the workflow is assigned to at that time. Note that when you associate the Three-state workflow with a list, you can choose to specify different state names, other than Active, Resolved, and Closed. Note that the Three-state workflow is not supported for use with libraries.

You can also make a copy of the predefined workflow to use as a starting point when creating a custom workflow.

Sample workflow scenario

Imagine that you work for Adventure Works, a sports store franchise that sells bicycles worldwide. This company has sales representatives that visit different countries to help new franchisees open new sports stores.

The scenario described in this section is one where an expense report is submitted for approval. If the expense report is for less than $5,000.00, a manager is required to approve, disapprove, or forward it. If the expense report is equal to, or more than, $5,000.00, a manager must review the expense report, comment on it, and then if the manager recommends approval, it is forwarded to a vice-president, who must approve or disapprove it.

In this scenario, the expense report form is an ASPX form displayed to the user on a SharePoint Web page. The workflow is a sequential type of workflow project created in Microsoft SharePoint Designer 2010, and is composed of both automated tasks and tasks that require human action. The workflow is running on SharePoint Foundation 2010.

  1. The sales representative — the first workflow participant — browses to an intranet self-service portal and selects the Expense Report form. A data entry page opens. The sales representative first fills out a simple expense report form that contains entries for the person's name, the expense purpose, the expense total, and the name and e-mail address of the person's direct manager. The sales representative then clicks Submit to submit the form.

    Upon submission of the form, the data is saved centrally, the workflow is initiated, and the review task is assigned to the approver (in this case, the sales representative's manager).

  2. The workflow notifies the sales representative's manager. The notification is an e-mail message that contains instructions for completing the task and provides a link to a Web site that displays the Expense Report form.

  3. The manager, the second workflow participant, goes to the Web site and reviews the expense report. The workflow task item provides three actions that the manager can perform: Approve, Disapprove or Forward.

    • If the expense report is less than $5,000.00, the manager sees options to Approve or Disapprove the expense report.

    • If the expense report is more than $5,000.00, the manager sees options to Forward the expense report to a company vice president, or to Disapprove the expense report at the manager's level.

  4. The manager takes action to approve, disapprove, or forward the expense report, and the workflow continues:

    • If the expenses are approved by the manager, the task completion sends a message to the workflow indicating that the task is completed, the workflow notifies the sales representative through an e-mail message, and then the workflow adds the expense data to the line-of-business (LOB) accounting system.

    • If the expenses are not approved by the manger, he types an explanation for his decision. The task completion sends a message to the workflow indicating that the task is completed, and then the workflow notifies the sales representative through an e-mail message.

    • If the manager selects the option to forward the expense report to a company vice president, the manager makes relevant comments in the form and then clicks Forward. The workflow then notifies the vice president through an e-mail message that contains instructions for completing the task and provides a link to a Web site that displays the Expense Report form.

  5. The vice president — the third workflow participant — is given the option to Approve or Disapprove the expense report. When the vice president acts to approve or disapprove the expense report, the workflow continues.

    • If the vice president approves the expenses, the expense data is added to the accounting system, the workflow notifies the sales representative and manager through e-mail, and then the workflow notifies SharePoint that the task is completed.

    • If the vice president does not approve the expenses, the vice president types an explanation for the decision into the form. The workflow notifies the sales representative and manager through e-mail, and then the workflow notifies SharePoint that the task is completed.

As you can imagine, there are many ways to expand the functionality of this workflow within the context of this scenario. For example, you can configure the workflow so that if the vice president disapproves the expense report, the report is returned to the sales representative's manager. The manager can further justify the expense and resubmit it for approval to the vice president, can pass along the disapproval to the sales representative, or take some other action.

In this sample expense report scenario, the business rules are always the same. This workflow solution defines the manager and vice president approvers, defines the business logic for the routing of the workflow, and predefines the content of the notifications. However, many real-world applications have complex business rules. Routing for approval can depend on many business variables. Notifications can also change, depending on other variables.

For example, imagine that in the same expense reporting solution, you have to route the expense report to as many as ten managers, depending on the expense purpose, the expense total, and the date of submission. Additionally, depending on the expense purpose, the content of the notifications sent by the workflow contain some small differences. This means that there can be multiple workflow solutions with different routing levels and notifications.

Microsoft SharePoint Foundation 2010 enables you to create and implement workflow solutions to meet the business needs of your organization. It does this by leveraging the workflow design and customization features of SharePoint Designer 2010 and Microsoft Visual Studio.

Workflow types: Declarative and compiled

An important distinction to understand about workflows is whether they are a declarative workflow, such as those created using Microsoft SharePoint Designer 2010 or a compiled workflow, such as those created using Visual Studio 2010. A declarative workflow is a workflow that is built from conditions and actions that are assembled into rules and steps, and that sets the parameters for the workflow without writing any code.

A compiled workflow, like declarative workflows, can also be built from conditions and actions without the workflow author actually writing code but also enable the workflow author to add custom code to the workflow. Regardless of whether a workflow author adds custom code to a code-centric workflow, the most important distinction to understand is the difference in the way that declarative and compiled workflows are run on the server. A compiled workflow is stored on a server running SharePoint Foundation 2010 as a precompiled dll file whereas a declarative workflow is deployed on a server running SharePoint Foundation 2010 as an Extensible Object Markup Language (XOML) file and compiled in the content database each time an instance of the workflow is started.

For more information about the Microsoft supported tools for authoring workflows, see Choose a workflow authoring tool (SharePoint Foundation 2010).

Workflow templates

When creating a custom workflow using SharePoint Designer 2010, you can choose to create a workflow that will only be used with a specific list, library, content type, or site. Alternatively, you can choose to create a reusable workflow template, which can be associated with multiple lists, libraries, content types, or sites.

Note:

SharePoint Designer 2010 does not support creating reusable workflows for sites. Instead, you can use Visual Studio 2010 to create them.

When authoring a workflow, you can also choose to make it global, which means that once it is activated on a site it will be active for all the sub-sites below that site as well. However, you cannot use SharePoint Designer 2010 to create a global workflow and then save the workflow as a WSP file.

Workflow associations

SharePoint Foundation 2010 takes advantage of the Workflow Foundation runtime. One or more workflow templates, each containing the code that defines a particular workflow, can be installed on a server. Once this is done, an association can be created between a specific template and a document library, list, content type, or site. This template can then be loaded and executed by the SharePoint Foundation 2010-hosted Workflow Foundation runtime, creating a workflow instance.

Like all Workflow Foundation workflows, those based on SharePoint Foundation 2010 rely on Workflow Foundation runtime services. The Workflow Foundation standard persistence service allows the state of a persisted workflow to be linked with the document or item, and allows for long-running business processes that can span days, months, or years.

SharePoint workflows can be associated with lists, libraries, and content types. Reusable workflows created using Visual Studio 2010 can also be associated with sites. The following table describes the minimum permissions required to associate a workflow.

Associate workflow with | Minimum permissions required
List or library | Full Control permission level on the list or library
List or library content type | Member of the Site Owners group on the SharePoint site
Site content type | Member of the Site Owners group on the SharePoint site
Site | Member of the Site Owners group on the SharePoint site

For more information about workflow associations, see Add a workflow association (SharePoint Foundation 2010).


Choose a workflow authoring tool (SharePoint Foundation 2010)

Developers of workflows can choose Microsoft Visual Studio 2010 or Microsoft SharePoint Designer 2010 as authoring tools.

What is a workflow? Fundamentally, it consists of two things: the forms a workflow uses to interact with its users and the logic that defines the workflow's behavior. Understanding how workflows are created requires knowing something about both.

Because it communicates with users through a Web browser, a workflow relies on ASP.NET to display its forms. Accordingly, those forms are defined as .aspx pages. A workflow can potentially display its own forms at four points in its lifecycle:

  • Association: When an administrator associates a workflow template with a particular document library or list, he might be able to set options that will apply to every workflow instance created from this association. If a workflow author chooses to allow this, she must provide a form that lets the administrator specify this information.

  • Initiation: The initiator of a workflow might be allowed to specify options when he starts a running instance. In the approval scenario just described, for instance, the options included specifying the list of workflow participants and defining how long each one had to complete his or her task. If a workflow allows this, its author must provide a form to allow the initiator to set these options.

  • Task Completion: The running workflow instance must display a form to the participants in the workflow to let them complete their task. This form is what allowed the approvers in the earlier scenario to make comments on the document and indicate their approval or rejection.

  • Modification: The creator of a workflow can allow it to be modified while it's running. For example, a workflow might allow adding new participants after it has begun executing or extending the due date for completing tasks. If this option is used, the workflow must display a form at this point to let a participant specify what changes should be made.

Workflows built solely on Microsoft SharePoint Foundation 2010 define their forms as .aspx pages. A workflow's logic is always defined as a group of activities, just as with any workflow based on the Windows Workflow Foundation (WF). To specify the logic and forms for a workflow, Microsoft provides two different tools, each targeting a different audience. Software developers can use the Workflow Designer feature of Windows Workflow Foundation. This tool runs inside Visual Studio 2010 Professional Edition and provides a graphical environment for organizing activities into workflows. Information workers, a less technical group, can use Microsoft SharePoint Designer 2010 to create workflows without writing code. The next two sections examine how workflows can be created by using each of these tools.

Authoring workflows with Visual Studio 2010 and WF Workflow Designer

In many ways, a workflow is like a flowchart. Given this, it makes sense to provide a graphical tool that lets developers specify a workflow's actions. This tool is SharePoint Workflow tools in Visual Studio 2010 Professional, which is a project type that uses the Windows Workflow Foundation (WF) Designer, and adds deployment and forms support for SharePoint Workflows. Developers can use WF Workflow Designer to define graphically a workflow's activities and the order in which those activities will be executed. The screen below shows a simple example of how this looks in Microsoft Visual Studio.

Collect Feedback Workflow

Windows SharePoint Services workflow example

The activities available for use appear in the Toolbox on the left side of the screen. A developer can drag these activities onto the design surface to define the steps in a workflow. The properties of each activity can then be set in the Properties window that appears in the lower right corner.

The Base Activity Library Windows Workflow Foundation provides a group of fundamental activities, as described earlier. Microsoft SharePoint Foundation also provides a set of activities designed expressly for creating workflows. Among the most important of these are the following:

  • OnWorkflowActivated: provides a standard starting point for a workflow. Among other things, this activity can accept information supplied by a SharePoint administrator by using the Association form when the workflow is associated with a document library, list, content type, or site. It can also accept information supplied by the Initiation form when the workflow is started. Every workflow must begin with this activity.

  • CreateTask: creates a task assigned to a particular user in a task list. For example, the approval workflow in the scenario described earlier used this activity to add a task to the task list used by each of the participants. This activity also has a SendEmailNotification property that, when set to true, automatically sends an e-mail message to the person for whom this task was created.

  • OnTaskChanged: accepts information from the Task Completion form. The approval workflow in the earlier scenario used this activity to accept the input of each participant when the document was approved.

  • CompleteTask: marks a task as completed.

  • DeleteTask: removes a task from a task list.

  • OnWorkflowModified: accepts information from the Modification form, which can then be used to change how this instance of the workflow behaves. If the workflow's creator chooses not to include any instances of this activity in the workflow, that workflow cannot be modified while it's running.

  • SendEmail: sends e-mail to a specified person or group of people.

  • LogToHistoryList: writes information about the workflow's execution to a history list. The information in this list is used to let users see where a workflow is in its execution, look at the workflow's history after it's completed, and more. To allow this kind of monitoring, the workflow's author must write information to a History list at appropriate points in the workflow's execution. Because it provides its own mechanism for tracking workflows, Microsoft SharePoint Foundation doesn't support WF's standard tracking service.

A typical pattern for a simple workflow begins with an OnWorkflowActivated activity, and then uses a CreateTask activity to assign a task to a participant in the workflow. The BAL's standard While activity might then be used to wait until the user completes the task. To learn when this has happened (perhaps the user makes multiple changes to the task, then checks a box on the Task Completion form when she's done), an OnTaskChanged activity executes within the While, extracting whatever information the user has entered on that form. When the user has completed the task, a CompleteTask activity might execute, followed by a DeleteTask. The workflow can then go on to the next participant, using CreateTask to assign a task to him, and so on. And of course, other things can occur, such as sending e-mail, logging information to the history list, or even including the BAL's Code activity, which allows running arbitrary code.

All of the activities provided by SharePoint Foundation are concerned with letting workflows operate within the SharePoint environment. The business logic a workflow implements is entirely up to the creator of that workflow. In fact, a developer authoring a workflow is free to create and use her own custom activities—she's not required to use only those provided by SharePoint Foundation and WF.

As described earlier, Windows Workflow Foundation supports sequential, parallel, and state machine workflows. A workflow created with the WF Workflow Designer can also use any of these options. To allow this, SharePoint Foundation adds project types to Visual Studio, one for each of these workflow styles.

Whatever style is chosen, the developer must define more than just the workflow's logic; he must also specify the .aspx form it should use. To do this, the developer relies on a file named element.xml. This file provides a template that the developer fills in to specify what form, if any, should be displayed at each of the four points at which a workflow is allowed to do this.

A developer must do some work to pass information between a workflow and the .aspx forms it uses. The Microsoft.Windows.SharePoint.Workflow namespace exposes an object model for developers. Using the types in this namespace, the creator of a workflow can pass information from an .aspx form to the workflow and vice-versa.

Once a workflow and its forms have been created, the developer must package them into what is referred to as a Feature. A SharePoint administrator must then install this Feature, which includes installing the workflow's assemblies to the target system's global assembly cache. The new workflow will now be visible to the administrator as a workflow template that can be associated with a document library, list, content type, or site.

For a software developer, creating a workflow by using Visual Studio and the WF Workflow Designer isn't especially hard. The developer needs to understand the specifics of working in this environment, but much of what he's doing will be familiar. Yet software developers aren't the only people who'd like to author workflows. As described next, people who aren't professional developers can also create workflows by using Microsoft SharePoint Designer 2010.

Authoring workflows with Microsoft SharePoint Designer 2010

Microsoft SharePoint Designer 2010 is a separate application that is available as a free download. Microsoft SharePoint Designer enables information workers and others to add application logic (implemented as a workflow) to SharePoint sites. This is certainly a useful goal, but Microsoft SharePoint Designer also addresses another important problem. If a developer creates a workflow by using Visual Studio, that workflow must be deployed on a server running SharePoint Foundation like any other feature. Yet many SharePoint administrators won't allow arbitrary code to be deployed on their servers, believing that the risk of destabilizing the system is too great. Being able to create straightforward business logic tied to documents and list items is very useful, however, and it's something that many SharePoint users need. Along with allowing less technical people to create workflows, Microsoft SharePoint Designer also addresses this problem by providing a safer way to define and deploy business logic on servers running SharePoint Foundation.

The workflow scenarios that Microsoft SharePoint Designer is intended to address are different in some ways from those addressed by Visual Studio and WF Workflow Designer. While it's certainly possible to create complex applications, the intent of Microsoft SharePoint Designer is to let users add business logic to SharePoint sites. For example, suppose that a site contains a list that allows its users to submit change requests. Microsoft SharePoint Designer could be used to create a workflow that automatically informs the submitter when her change request is accepted or rejected. Similarly, a custom workflow might inform a particular group of users whenever a new document is added to a particular document library. Performing this kind of custom notification isn't complicated—creating the workflows is easy—but it's challenging with earlier versions of SharePoint Foundation because of administrators' reluctance to install user-written code.

There's an obvious question here: why should logic created with Microsoft SharePoint Designer be treated any differently? What makes SharePoint administrators willing to allow workflows built with this tool to be deployed on the systems for which they're responsible? The answer is that workflows built with Microsoft SharePoint Designer can only use activities from an administrator-controlled list. In addition to the activities provided by SharePoint Foundation, a site administrator can choose whether to include custom activities created by a developer on this list. By defining exactly what workflows are allowed to do, a SharePoint administrator can have more confidence that deploying logic created by using Microsoft SharePoint Designer won't destabilize his system.

Both because it's intended for information workers rather than developers and because it emphasizes simpler scenarios, Microsoft SharePoint Designer uses a different model for creating workflows than the Visual Studio-hosted WF Workflow Designer. Instead of a graphical approach, Microsoft SharePoint Designer uses a rule-based approach. It's somewhat similar to the Rules Wizard in Microsoft Outlook, a tool that's familiar to many people. The screen below illustrates how a user of Microsoft SharePoint Designer defines a step in a workflow. Notice that this workflow runs some actions in parallel; some actions run serially. Earlier versions of SharePoint Foundation supported running actions only serially; actions only ran consecutively.

Process Order Workflow

Each step can have a condition and an action. The condition determines whether this step's action should be executed, as in the If statement shown above. The choices for actions include things such as assigning an entertainer to an event, collecting approval, and many more. Each of these actions is actually carried out by some SharePoint Foundation activity, and the activities used here are the same as with Visual Studio and WF Workflow Designer. The list of actions can also include any other activities allowed by the SharePoint administrator for this site, including custom activities created by developers.

Even though its user interface looks quite different from the graphical approach used with Visual Studio and WF Workflow Designer, Microsoft SharePoint Designer creates a standard WF workflow. What's actually produced is a workflow that is sequential, parallel, or combination of both with conditions expressed using the WF rules engine. Workflows created with this tool do have some limitations, however. For example, they can't be modified while they're running, unlike those built using Visual Studio and WF Workflow Designer, and only sequential and parallel workflows can be created—state machines aren't supported. Also, workflows built with this tool can be authored against a specific document library, list, or site when they're designed. Workflow authors can also create a general workflow template that can be later associated with any library, list, or content type. While this does place limits on how a workflow can be used, it also makes deploying the workflow much simpler. In fact, when a user finishes authoring a workflow with Microsoft SharePoint Designer, the tool provides a one-click deployment of the workflow to the target site, which includes activating the workflow. This is significantly less complicated than the multi-step deployment process required for workflows created using Visual Studio and WF Workflow Designer.

Workflows created by using Microsoft SharePoint Designer can also display customized forms. Rather than require workflow authors to create .aspx pages directly, however, the tool instead generates those pages. The author specifies details about how the generated pages should look, such as what fields they should contain, and Microsoft SharePoint Designer takes care of the rest. Of the four points in a workflow's lifecycle where forms can be used, however, only two are used with workflows created by using Microsoft SharePoint Designer: Initiation and Task Completion. Because every workflow created with this tool must be associated with a particular document library, list, content type, or site there's no need for an association step and hence no Association form. And since these workflows can't be modified while they're running, there's no need for a Modification form.

Microsoft SharePoint Designer also provides the ability to import workflows that were created using Microsoft Visio 2010. This enables business managers or workflow authors to create the workflow logic using a well known graphical environment. A workflow author can then import the workflow logic into Microsoft SharePoint Designer, modify it if necessary, and then publish it to a SharePoint site.

SharePoint Foundation provides a great deal of functionality for creating document-oriented workflows. Yet ultimately, it's a platform for development and execution. On its own, it provides no workflow functionality that's directly usable by end users. Workflows running on SharePoint Foundation also have other restrictions, such as the inability to interact with participants by using Office client applications.

Authoring tool comparison

The following table shows the important differences between the tools that Microsoft supports for creating workflows in SharePoint Foundation by using both SharePoint Designer and WF Workflow Designer in Visual Studio 2010 Professional Edition.

Capability/Requirement | SharePoint Designer | WF Workflow Designer in Visual Studio
Workflows can be created using only actions that are approved by site administrators? | Yes | No
Workflows are accessible in client applications (other than the browser)? | Yes | Yes
Can use Microsoft Visio Professional to create workflow logic? | Yes | No
Need to write code? | No | Yes
Additional activities (other than those provided by SharePoint Foundation) are provided? | No | Yes
Can create custom activities? | No | Yes
Workflow can be modified while it is running? | No | Yes
One-click publishing of workflows? | Yes | Yes
Workflows can be deployed remotely? | Yes | No
Can be made available across the farm? | No | Yes
Can be scoped to a site collection? | Yes | Yes


Plan for workflow security and user management (SharePoint Foundation 2010)

Administrators and workflow developers should plan for the aspects of workflow behavior that relate to security as they develop and configure workflows.

Before deploying workflows in Microsoft SharePoint Foundation 2010 to users, administrators might have concerns about security issues, such as information disclosure or elevation of privilege. This article highlights some aspects of workflow behavior that relate to security and raises other issues for administrators and workflow developers to consider when they plan to configure and develop workflows.

In this article:

  • List manager, administrator, and developer roles and responsibilities

  • Running workflows as an administrator

  • Workflow configuration settings

  • Information disclosure in task and workflow history lists

  • Spoofing and tampering attacks in the task and workflow history lists

  • User-Impersonation Step type for declarative workflows

List manager, administrator, and developer roles and responsibilities

The following are some common workflow actions and the related responsibilities, which explain the role of administrators and developers in running workflows.

Workflow developers

Develop workflow schedule and template Workflow developers are responsible for coding the assembly that contains the business logic that will run on a SharePoint item. This assembly is called a workflow schedule. They are also responsible for packaging the workflow forms and assembly into a workflow feature, or into a workflow template.

Site administrators

Manage Central Administration workflow settings Site administrators can control general workflow settings, such as task alert results and external participant settings on the SharePoint Central Administration Web site.

Deploy Workflow features Site administrators can install workflow features on a site collection to make them available for association.

List administrators (anyone with Manage List or Web Designer permissions)

Add workflows List administrators must associate (add) a workflow template to a list or content type, according to the business needs of the list or content type. This association makes the workflow template available to end users, who can then select default values and settings.

Remove workflows List administrators can remove workflow associations from a list or content type, or prevent new instances from running.

Terminate a workflow If a workflow instance fails, list administrators can stop a running workflow instance, such as when a workflow instance produces an error or does not start, by using the Terminate this workflow link on the Workflow Status page. This action is reserved for administrators.

Running workflows as an administrator

The most important security concept to be aware of is that workflows run as part of the system account in SharePoint Foundation 2010, through the identity application pool settings on the server computer and domain. This means that within SharePoint Foundation 2010, workflows have administrator permissions. On the server, workflows have the same permissions as the application pool, which frequently has administrator permissions. These permissions enable workflows to perform actions that ordinary users cannot perform, such as routing a document to a specific location or records center, or adding a user account to the system.

This setting, that workflows have administrator permissions, cannot be changed. It is up to the workflow schedule (that is, the workflow code) to detect user actions and, based on those actions, continue or roll back changes, or impersonate a user in order to mimic that user's permissions.

When they deploy workflows, administrators must understand the actions that the workflow will perform so that they can assess possible risks associated with elevation of permission in a workflow and help the workflow developer reduce any security concerns.

Workflow configuration settings

SharePoint Foundation 2010 has some configuration settings that administrators have to set according to their security needs.

Required permissions to start a workflow

In addition to preventing the elevation of permissions in the code, list administrators can restrict the permission level that is required to start a workflow during the association process. Administrators can select either of two permission levels to start a specific workflow association: Edit Item or Manage List.

The default setting for associating a workflow is to allow users with Edit Item permissions to manually start a workflow. This means that any authenticated SharePoint Foundation 2010 user on the list who has Edit Item permissions can start an instance of this workflow association. If during workflow creation the administrator selects the option to require that the user have Manage Lists permissions in order to start the workflow, only list administrators can start an instance of this association.

Because workflows are designed to be used by standard contributors, most workflows do not require the restriction to Manage Lists permissions. However, administrators can use this setting for workflows such as a document disposal workflow, where the administrator wants only certain people to execute the disposal actions.

Central Administration settings

The following settings can be found on the Central Administration page by clicking Application Management and, in the Web Applications section, clicking Manage web applications. On the Web applications page, select the Web application that you want to configure, and in the Manage group of the ribbon click General Settings, and then select Workflow. The Workflow Settings page opens, and the following settings are displayed:

  • User-Defined Workflows

  • Workflow Task Notifications

Enable user-defined workflows

By default, user-defined workflows are enabled for all sites on the Web application, as shown in the User-Defined Workflows section of the Workflow Settings page. When this option is selected, users can define workflows in a workflow editor such as the SharePoint Designer 2010 workflow editor. Users who define these workflows must have Manage List permissions on the site to which they are deploying the workflow.

Task notification for users without site access

On the Workflow Settings page, in the Workflow Task Notifications section, you can set options for sending notifications about pending workflow tasks to users who do not have access to the site.

  • Internal users

    In SharePoint Foundation 2010 it is possible to resolve the names of internal users in the directory service who are not members of the site or who do not have access to that task. In this case, an administrator can select the Alert internal users who do not have site access when they are assigned a workflow task option in the Workflow Task Notifications section to set whether such users receive a task notification by e-mail. This option means that users are alerted when they are assigned a workflow task. This option is enabled by default, and the e-mail message that users receive contains a link that they can click to request access to the site (administrators must still grant access). This e-mail message might also contain information about the document. This information can include the title of the document and instructions from the workflow owner. If there are information disclosure concerns associated with internal users who are not members of the site, administrators might want to disable the Alert internal users who do not have site access when they are assigned a workflow task setting.

  • External users

    External users who are not in the directory service but who are assigned a well-formed SMTP e-mail address can still be assigned workflow tasks. Because external users will find it difficult to access the document, SharePoint Foundation 2010 includes a setting, Allow external users to participate in workflow by sending them a copy of the document, which makes it possible to send external users a task notification by e-mail with the document attached. When this option is enabled, the task is assigned to the workflow owner, and the external user can complete the task by sending e-mail to the owner.

    By default, the option Allow external users to participate in workflow by sending them a copy of the document is disabled. But this setting can be useful in situations that require external participation, such as approval of business documents that involve external customers. Administrators who enable this setting (select Yes) must verify that the workflow schedule supports the external participant setting. For example, when a task is created for an external user, the custom workflow must specify the external e-mail address in the OnBehalfEmail property in the SPWorkflowTaskProperties object that was used to initialize the task). Several built-in workflows in SharePoint Foundation 2010 support this setting.

    Custom workflow developers who want to enable this functionality must work with administrators to determine whether there are information disclosure risks in attaching the actual document to an external e-mail message. Administrators must evaluate the benefits and risks when enabling this setting.

Information disclosure in task and workflow history lists

Because tasks and history list items can contain data about users and the actions they perform on documents, the items might disclose confidential information. For example, a promotion Approval workflow might collect feedback on its tasks that an organization wants only the workflow owner and each participant in the task to see.

Task and history lists are typical lists in a site. By default, therefore, all readers can view tasks and history items. Administrators and developers must determine the information that cannot be disclosed and decide whether to help secure task and history items that are created by the workflow.

Securing these items can be done in several ways. For example, administrators can set list-level permissions. If disclosure is to be private — that is, not publicly available but available to a specific group of people — administrators can create a new task or history list and set permissions for the list that are targeted to that group. If administrators do not want anyone to see history events on a workflow status page, they can remove view permissions to the workflow history list from which a status page pulls its information. Users who do not have permissions to view the history list itself, or any item on the list, will receive an Access Denied error when they open any status page that pulls data from that history list.

If finer restrictions are required, workflow developers can set per-item permissions when they create tasks or history items. The CreateTask activity has a SpecialPermissions property that gives only specified permissions to access the newly created task. The LogToHistoryList activity does not have such a property, so to set per-item permissions on history list items, administrators must use the object model (OM) in SharePoint Foundation 2010. Per-item permissions can affect performance negatively and should not be used unless they are necessary.

Tasks and history items do not have to be handled in the same manner. Administrators can mix and match list permissions and item-level permissions.

Spoofing and tampering attacks in the task and workflow history lists

Any contributor can modify tasks or history items if there are no restrictions on those lists. This means that malicious users can modify task descriptions to give participants incorrect instructions or to order participants to click malicious links. To change the perceived results of a process, malicious users also can add false or inaccurate history events or can modify history events to make them false or inaccurate.

As detailed earlier, task and history lists are normal lists in a site. By default, there are no permission restrictions on either task lists or history lists. To avoid spoofing and tampering attacks, administrators must determine the vulnerabilities that exist and either restrict access to columns in a list (for example, make vulnerable columns such as task descriptions read-only so that only the workflow can set them on item creation), set special permissions on the list, or set item-level permissions on the items in a list.

Security issues in the workflow history list

A key benefit of workflows is the ability to track process information to provide visibility into a process. The workflow history list is a repository for this information, where a workflow status page can search for data related to a workflow instance and can make this information available to users. Users can see all items to which they have access in the history list.

However, because the workflow history list tracks information, users might assume that it can be used as an audit trail for events. This is not the case: Workflow history is not a security feature. History lists are standard SharePoint lists that are used for storing events that are visible to any user and that have no special permissions associated with them. By default, users can modify and add events if they have edit and add permissions on the site. To audit events, use the SharePoint's Audit Log feature. Only administrators can access this log and the log does not require additional work to protect it from tampering attacks.

To better protect the history list, administrators can restrict edit and add permissions to the list, so that only system account administrators (for example, workflow administrators) and list administrators can add items. List administrators must have add permissions to log "Terminate this workflow" events. If edit and add permissions are restricted on the history list, users still must be granted view permissions in order to see status information.

User-Impersonation Step type for declarative workflows

The User-Impersonation Step type can be used to run sections of declarative workflows by the person who authored the workflow rather than by the workflow's initiator. Declarative means a model that you use to create the workflow and set the parameters for the workflow without writing any code.

In SharePoint Foundation 2010, declarative workflows always run in the user context of the workflow initiator unless an impersonation step is encountered. If an impersonation step is encountered, the declarative workflow is run in the context of the workflow associator. The default workflow tasks respect SharePoint permissions by impersonating the user who started a workflow when the workflow is run. This arrangement keeps things fairly safe in SharePoint Foundation 2010, but blocks many scenarios in which a workflow designer with high permission levels wants to author a powerful workflow that can be completed successfully by users who have lower permission levels.

Through a safe and scoped form of privilege elevation, site actions can be automated through workflow. This reduces the burden on a SharePoint site administrator. Automation of a high-security process is useful in publishing and approval scenarios in which existing actions are enabled to impersonate someone other than the workflow's initiator.

The following are sample scenarios that demonstrate the User-Impersonation Step type:

  • Publish to a secure list

    Jackie has locked down the Pages document library for the public face of her SharePoint site. She has set up an Approval workflow that, by using Microsoft SharePoint Designer 2010, submits content from site contributors for approval. Jackie puts her workflow actions in an impersonation step so that the workflow actions will always impersonate her, a site administrator, as the author of the workflow.

    When Connie (a contributor) posts a content draft to the Pages library of the site, and tries to publish her article, that action causes Jackie's Approval workflow to start so that the post can be reviewed and approved. Tasks are sent out to the approvers in the workflow on behalf of Connie. Upon review and approval by the approvers, the system sets the moderation status of the post to "Approved", even though Connie does not have permission to approve pages.

  • Granting permissions to users

    Joanne has set up a workflow in SharePoint Designer 2010 that uses a user-impersonation action "Add User to Group" to grant Design permissions to her site. Because the workflow uses an impersonation scope, the action of adding a user to the group will always be performed on Joanne's behalf.

    The rest of the workflow lets contributors visit the site and complete a form to log their access request to a list.

    For example, a separate user, Olivier, receives a task when Connie, a user, logs a request, and when he approves the task, Connie is added to the Designer group for the site even though neither Olivier nor Connie has Manage Lists permissions on Joanne's site.

  • Templates and taking ownership

    William created several workflows in SharePoint Designer 2010 and saved them as templates for reuse across the company, but he soon leaves the company. His account is removed, his administrator status is revoked, and now the SharePoint Designer 2010 workflows that William created fail to complete due to the loss of William's permissions.

    A parent SharePoint site administrator, John, can intervene for each workflow, without having to re-create the workflows in SharePoint Designer 2010. John takes ownership of the administrative symptoms in each broken template. After doing this, secure publishing and access granting now occur under John's name instead of William's — and nothing else has changed.

The following are workflow actions that can be impersonated:

  • Set Content Approval Status (as Owner)

  • Create List Item (as Owner)

  • Update List Item (as Owner)

  • Delete List Item (as Owner)

  • Add/Remove/Set/Inherit List Item Permissions (as Owner)

As a SharePoint administrator, you must consider the possible security effects of incorporating impersonation into workflows on the SharePoint site. This applies to new actions but also to existing actions such as updating list items.

For example, consider a model in which user-impersonation actions in the workflow could still run as the initiator. If a user has administrator permissions only over a site in the site collection, that user could maliciously create a workflow to gain rights to the parent Web of the site. All that the malicious user would have to do is to persuade the administrator to upload a file to a document library on the malicious user's site to begin the workflow's attack and compromise the whole parent Web of the site.

This risk prompted development of the restriction "user-impersonation actions always impersonate their associator" in SharePoint Designer 2010. The associator is the person who associates a workflow to a particular list or Web. In SharePoint Foundation 2010 declarative workflows, the associator is the same person as the workflow author; that is, the user who builds the workflow in SharePoint Designer 2010. However, the associator can also be anyone who associates a declarative workflow template. The concern now is that the author/associator is forced to accept responsibility for anything that occurs because of a User-Impersonation Step type, because the author/associator's credentials are being used in the elevation. This requires that the authors/associators understand the workflows they design or associate. Therefore, during workflow creation, SharePoint Designer 2010 provides a cautionary message on the workflow creation page to the author/associator about the User-Impersonation Step type.


Approval Workflow: A Scenario (SharePoint Foundation 2010)

This scenario illustrates how to create, deploy, and use an approval-type workflow.

The most common example of human workflow in most organizations is some variation of approval: A group of people must approve or reject some document, and perhaps add comments to explain their decisions. This article shows how an approval-type workflow that is created in SharePoint Designer 2010 or Workflow Designer in Visual Studio 2010, and that is then hosted by using SharePoint Foundation 2010 might look. Before reading this example, it is useful to define the roles that different people play.

  • Workflow author The developer or information worker who creates a workflow template.

  • SharePoint Foundation 2010 administrator The person who installs a workflow template and associates it with a document library or list.

  • Workflow initiator The person who starts a workflow, causing a workflow instance to be created from a particular workflow association.

  • Workflow participants The people who interact with a workflow instance to complete the business process that it supports.

As described in the following section, people in each of these roles play their own parts in creating, installing, starting, and using a workflow.

Authoring a workflow

Microsoft provides two options for creating workflows in SharePoint Foundation 2010. Developers use Visual Studio 2010 and Workflow Designer, whereas information workers use the rules-based approach that SharePoint Designer 2010 provides. In both cases, the result is a workflow template that must be deployed to a server that is running SharePoint Foundation 2010. This scenario assumes that a workflow template has already been created.

Associating a workflow

Before you can use a workflow, you must install a workflow template on a server that is running SharePoint Foundation 2010, and then you must associate the workflow with a particular document library, list, content type, or (in the case of a site workflow) site. You can then start the workflow from any document or item in that library or list. Although workflows cannot be explicitly started from content types, a workflow that is associated with a content type can be started from a document or list item to which that content type is attached. Because workflows operate in the same manner on items and documents, a workflow template can typically be attached to a list, library, or content type. You can also create a template that can be associated only with a particular list or library.

Both installation and association are performed automatically for workflows that are deployed by using SharePoint Designer 2010. However, when you use Visual Studio to deploy workflows, a server administrator must explicitly install the workflow template. In addition, a user must associate the template with a library, list, content type, or site. Whoever creates this association also assigns the association a unique name, which enables users to reference it. Optionally, the workflow author can let the person who creates the association set options for the workflow behavior, such as a default list of people who can always participate in the process. The same template can be associated with multiple libraries, lists, or content types, and each association can be customized as required. After the association is created and any available options are set, a workflow initiator can create a workflow instance from this association, as described in the following section.

Associating a workflow with a site

Site workflows are associated with the site itself. An item does not have to be started for the workflow to run.

You can use site workflows for processes that do not have a list item context. For example, you could create a workflow to request permissions for the site, a workflow to request and provision a new site, or a workflow that uses context that is stored outside the SharePoint site, without having to create a corresponding SharePoint list item from which to start the workflow.

Site workflows can be associated with a site through the site's settings and can be started on the site itself. SharePoint Designer 2010 can also deploy site workflows directly to a site.

Site workflows work in the same way as list items, as described earlier in this article, except that site workflows cannot be started from a document or item in a library or list.

For more information, see Add a workflow association (SharePoint Foundation 2010).

Starting a workflow

SharePoint Foundation 2010 provide three options to start an instance of a workflow. All three options run the workflow from the beginning every time. (If an instance of a workflow that is created from a particular association is already running on a particular document or list item, it is not possible to start another instance of the workflow on the same document or item.) The following are the options for starting a workflow:

  • A SharePoint Foundation 2010 user can manually start a workflow.

  • You can configure a workflow to run automatically when a user creates a document or item.

  • You can configure a workflow to run automatically when a user changes a document or item.

For example, a Microsoft Word user can upload a new document to a site's document library. This causes an instance of a workflow that is associated with that library to start.

This scenario uses the first of these three options: manually starting an Approval workflow for a document. To start a workflow instance from a document in a document library, a SharePoint Foundation 2010 user does the following:

  1. Points to the document and selects Workflows from the drop-down menu.

  2. Selects the workflow to start.

    This example assumes that a workflow that will route the document for approval has been created.

When a workflow is started (that is, when an instance of a workflow is created), it can also display a screen that enables a user to specify relevant information. For a workflow that routes a document for approval, this information can include the name of each person who must approve the document, an indication of when each approval is due, and a list of people to be notified. After this information is supplied, the user clicks Start. The workflow begins to execute and requests each participant to review the document in the order in which names were entered on this screen.

When a workflow is started, it can also optionally send an e-mail message to the person who started it. Similarly, a workflow can inform its creator by e-mail when it has finished. You can also configure the workflow to notify the participants in the workflow — in this example, the people who are approving the document—by e-mail that the workflow has something for them to do.

Interacting with a workflow

The concept of tasks models the interaction between a person and a running workflow. A task is a unit of work that is assigned to an individual. For example, each person on this workflow's approval list will be assigned a task that requests approval of the document. SharePoint Foundation 2010 can have a task list for every site, and a running workflow can add tasks to this list that specify the person or persons who are assigned to each task. Users of that site can see the work that is awaiting them by accessing their task list through a Web browser. Optionally, you can have a custom task list for just your workflow tasks.

To a SharePoint Foundation 2010 user, the list of waiting tasks is merely another list. In this example, the user browses to the team SharePoint site and selects the option to view the list of Tasks that are assigned to him. To work on a task, the user in this example clicks the task name.

Because the way that a workflow interacts with participants can vary, the workflow itself defines the screen that is displayed to the user. In this example, the workflow provides options to approve or reject the document and a text box in which participants can type comments.

Other available options let users reassign the task to another person or to request a change. Here, the user might type a comment, and then click Approve. The workflow then creates a task in the task list of the next person in its list of approvers. When every participant has responded, the workflow ends.

SharePoint Foundation 2010 workflows also provide other options, including the following:

  • The initiator of a workflow can check the status of the workflow.

    For example, in the scenario described here, the initiator might check the progress of the approval process.

  • A workflow can be modified while it is executing.

    The workflow's author determines the allowed modifications, if any. An Approval workflow, for example, could allow the addition of a new approver while the workflow is in progress. The ability to modify in-progress workflows is important because it reflects how people actually work. Because spontaneous change to business processes is a part of life within any business, SharePoint Foundation 2010 workflows were designed to let users handle this.

Summarizing the process

When a workflow template is installed on a site and associated with a document library, list, site, or content type, a site user can start an instance of a workflow.

  1. The process starts when the workflow initiator selects a document and starts an instance of a workflow.

  2. The initiator creates a workflow instance from this association.

  3. The user customizes this new instance and starts it.

  4. The running instance of the workflow adds a task to the task list of a participant.

    The approval workflow that is used in this scenario assigns these tasks sequentially. However, you can assign tasks to many participants at the same time, which allows tasks to be performed in parallel.

  5. Participants in the workflow can learn about tasks that the workflow has assigned to them by checking their task lists.

  6. Each participant interacts with the running instance of the workflow to complete assigned tasks.

    In the example described here, this interaction required approving a document, but the interaction could be anything that the workflow author wants.

It is worth noting that the document on which a workflow runs is not itself sent from person to person. Instead, the document remains on the site, and each workflow participant is given a link to it. In fact, there is no requirement that the workflow use the document or item with which it is associated. Another point worth emphasizing is that SharePoint Foundation 2010 itself defines what is displayed to the initiator of the workflow and the participants in the workflow in steps 1, 2, and 5. However, the workflow author defines and creates the ASPX Web pages that are used in step 3 and step 6. This allows the author to control how users customize and interact with the workflow.


Plan site creation and maintenance (SharePoint Foundation 2010)

Published: May 29, 2010

If you plan on having more than a few site collections in your Microsoft SharePoint Foundation 2010 environment, you need to be sure that you have a plan for site creation and maintenance. Without such a plan, it is difficult to control or track when SharePoint sites are created, whether sites are still active, and when you can safely remove inactive sites. Before you deploy and make sites available to users, you need to answer questions such as:

  • Do you want to tightly control site creation or to allow many users to create sites?

  • At which level in the site hierarchy should additional sites be created?

  • How do you find and remove unused sites in your environment?

Articles and worksheets help you design and record a plan for site creation and maintenance. This will help you prepare to manage growth in your environment.

In this section:

  • Plan process for creating sites (SharePoint Foundation 2010)

    Discusses how to determine which type of site creation process will fit your organization, and which method to use to implement that process.

  • Plan site maintenance and management (SharePoint Foundation 2010)

    Discusses how to plan for maintaining your SharePoint sites from the beginning to make sure that your sites stay current, useful, and usable.

  • Plan quota management (SharePoint Foundation 2010)

    Contains guidance about how to determine settings for quota templates and recycle bins, and how to decide whether or when to delete unused Web sites.


Plan process for creating sites (SharePoint Foundation 2010)

Published: May 29, 2010

Some organizations need to maintain tight control over who can create sites, or when sites are created. Other organizations can allow users more access and freedom to create sites when needed. This article helps you determine which type of site creation process will fit your organization, and which method to use to implement that process.

In this article:

  • Determine who can create sites and a method for site creation

  • Plan for Self-Service Site Management

  • Plan for custom site creation processes

  • Worksheet

Determine who can create sites and a method for site creation

By default, new site collections (and therefore new top-level Web sites) can only be created by using Central Administration, which means that they can only be created by members of the Farm Administrators group. This behavior might suit your organization if you want your environment to be tightly controlled and managed, with only a few people allowed to add top-level sites. However, the default top-level site creation method might not suit your organization if you have any of the following requirements:

  • You want users to be able to easily create informal, perhaps even disposable, top-level sites, such as for short-term projects.

  • You want to create an informal space for team, group, or community interaction.

  • You are hosting top-level sites (either internally or externally) and want the process for requesting and receiving a top-level site to be as quick and low cost as possible.

There are several ways to allow users to create their own sites, while still maintaining some control over your environment. Consider which of the following methods will work best for your organization.

  • Self-Service Site Management In Central Administration, you can turn on Self-Service Site Management to allow users to create site collections under the /sites path (or other path you specify) within a particular Web application. This method is best used when you want to allow groups or communities to create sites. This method also works well if you are hosting sites and want to allow users to create sites without waiting for a complicated process. The sign-up page for Self-Service Site Management can be customized or replaced with a page that includes all of the information you might need to integrate with a billing system or to track custom metadata about the site at creation time. This method does not work well when large numbers of users need access to multiple sites. Because Self-Service Site Management creates site collections, which have separate permissions, users need to be added uniquely to different site collections. If you use subsites instead, the users can be inherited from the parent site in the site collection. Search works within a specific site collection. Therefore, if you want users to be able to find content across multiple sites, make the sites into subsites within a site collection.

  • Subsites of existing sites Limit users to creating subsites of existing sites, rather than new site collections and top-level sites. Any user who has the Full Control or Manage Hierarchy permission level on an existing site can create a subsite. This method is the most limited, because you still control how many site collections there are. Because the sites are always subsites of other sites, they can either be easy to organize (if there are just a few) or very difficult to organize and browse (for example, if everyone in your organization wants a subsite and they create them at different levels in the site collection's hierarchy, the site collection can soon become very difficult to navigate).

    Note:

    If you do not want users to have this capability, you can remove the Create Subsites right from the Full Control and Manage Hierarchy permission levels, either at the site collection or Web application level.

Note:

Keep in mind that none of these methods can control how much space each site takes up in your content databases. To control site sizes, you should use quotas and set a size limit for site collections. You cannot set individual size limits for subsites. For more information, see Plan site maintenance and management (SharePoint Foundation 2010).

Plan for Self-Service Site Management

Self-Service Site Management allows users to create and manage their own top-level Web sites automatically. When you turn on Self-Service Site Management for a Web application, users can create their own top-level Web sites under a specific path (by default, the /sites path). When turned on, this capability advertises itself with an announcement added to the top-level site at the root path of the Web application, so any users who have permission to view that announcement can follow the link.

Note:

If you want to use a path other than /sites for Self-Service Site Management, you must add the path as a wildcard inclusion. For more information, see Plan for collaboration sites (SharePoint Foundation 2010).

This capability can obviously affect the security for your Web server. Self-Service Site Management is disabled by default — you must turn on the feature to use it. You enable Self-Service Site Management for a single Web application at a time. If you want to use it on all Web applications in your server farm, you must enable it for every Web application individually.

If you enable Self-Service Site Management, you should consider the following:

  • Generally, you should require a secondary site collection administrator. Administrative alerts, such as those for when quotas are exceeded, or checking for unused Web sites, go to the primary and secondary administrators. Having more than one contact reduces administrator involvement with these sites because the secondary contact can perform required tasks even if the primary contact is not available.

  • Define a storage quota and set it as the default quota for the Web application.

  • Review the number of sites allowed per content database. Combined with quotas, this will help you limit the size of the databases in your system.

  • Enable unused Web site notifications, so that sites that are forgotten or no longer of value can be identified.

Because Self-Service Site Management creates new top-level Web sites on an existing Web application, any new sites automatically conform to the Web application's default quota settings, unused Web site notification settings, and other administrative policies.

Plan for custom site creation processes

You can, of course, create your own process for site creation by using a custom form to request a site that integrates with a back-end billing system to charge a customer's credit card or a corporate cost center. If you have a complicated system or process that you want to include as part of site creation, you should create a custom application to call the site creation interface and perform any other tasks you require. However, if you simply want to add a few custom fields to the site creation page (for example, to track which department in your company is requesting a particular site), you should consider using Self-Service Site Management and customize the sign-up page to include the information that you need. You can customize the scsignup.aspx page in the site definition to include the metadata that you need without having to develop an entire application.

For more information about building custom applications or editing pages in a site definition, see the SharePoint 2010 developer portal on MSDN (http://go.microsoft.com/fwlink/p/?LinkId=178818).

Worksheet

Use the following worksheet to plan the process for creating sites:

  • Site Creation and Maintenance Worksheet (http://go.microsoft.com/fwlink/?LinkId=193521)


Plan site maintenance and management (SharePoint Foundation 2010)

Published: May 29, 2010

All Web sites, particularly sites that have more than one author, get cluttered. Periodic review and cleanup can help keep your site functioning well, whether your site is large or small. If you build a plan for maintaining your site or sites from the beginning, you can ensure that they stay current, useful, and usable.

In this article:

  • Plan for site maintenance

  • Plan for managing site collections

  • Worksheet

Plan for site maintenance

Your site maintenance plan will be different from that for any other environment, and it will contain different elements. Site maintenance is different for sites managed by an IT department than it is for user-created sites and managed sites. However, some best practices for a site maintenance plan include:

  • Ask users what they want in IT-managed sites. Perform periodic surveys to determine what your users need from the site.

  • Use usage logs and reports to find out which areas of the site are being used, and then correlate that with user surveys to find out what can be improved.

  • Archive obsolete content or sites. However, if you are going to archive or delete obsolete content or sites, be sure that users understand that plan and that you perform these actions only at predictable times. For example, publish a schedule of when you are going to archive content or delete unused sites.

  • Periodically review site permissions. For example, review the permissions quarterly to remove permissions for any users who have left the group or project.

  • Select a reasonable time interval for your maintenance activities. For example, if you plan to conduct periodic user surveys, do not conduct them more than twice a year (and preferably, no more than once a year).

  • Create a plan for regular backups of site content. Determine or discover how often backups will be made, and the process for restoring content when necessary. For more information about planning for backup and restore, see Plan for backup and recovery (SharePoint Foundation 2010).

Start now, during your planning process, to create a plan for site maintenance. Record your plan, including how often to tune up the site and archive content. Get your plan reviewed by members of your team and representatives of your user base. This way, you can identify any concerns that users might have now, determine how best to address these concerns, and have a plan for site maintenance in place by the time your site goes live.

You can record this information in the Site Creation and Maintenance Worksheet (http://go.microsoft.com/fwlink/?LinkId=193521).

Plan for managing site collections

One part of your site maintenance plan should be a plan for how to manage the size and number of site collections in your environment. This is most important if you are allowing Self-Service Site Management. Most organizations want to be able to predict and control how much growth they can expect from sites because of the impact that they can have on database resources. For example, if a particular content database contains 100 sites, and one of those sites is taking up more than 50 percent of the space, then that site might need to be in its own content database. This will ensure that you preserve some room for additional growth, while maintaining the ability to back up and restore the databases.

Two methods for managing site collections are:

  • Site collection quotas Use this method to control how large site collections can become.

  • Site use confirmation and deletion Use this method to monitor and remove unused site collections.

Plan site collection quotas

Use quotas to track and limit site storage. You can send a warning e-mail message to site collection administrators when site storage reaches a particular size (in megabytes), and then lock the site to further content when site storage reaches a maximum size. When you perform your database and server capacity planning, determine what size limits (if any) you want to enforce. The following list describes how to take the best advantage of quotas:

  • Create different quota templates for different site types. For example, you might want different quotas for different divisions, or for different customer types, or for different paths (perhaps sites under the /sites path only get 100 MB per site collection, whereas sites under the /vip path can take up to 300 MB per site collection). Whenever you create a site collection from Central Administration, you can specify on which quota template it is based. Note that sites created by using Self-Service Site Management use the default quota for the Web application. For more information, see Create, edit, and delete quota templates (SharePoint Foundation 2010).

  • Give enough room for reasonable growth in sites. Depending on what each site is used for, storage space needs can vary dramatically. Sites are designed to grow over time as they are used. A quota limit of 50 MB is unlikely to be enough storage space to start with for most sites, and is unlikely to be anywhere near enough for a site that has a long life.

  • Allow for reasonable notice between the warning e-mail message and locking the site for exceeding its quota. For example, do not set the warning limit to 80 MB and the site storage limit to 85 MB. If users are in the middle of uploading several large files, they will not be happy if blocked from completing that task with very little notice.

Plan site use confirmation and deletion

You need to plan how to handle sites that become inactive after a project has ended, or sites that users created just to test out some ideas, and then abandoned. Site use confirmation and deletion can help you keep your environment cleaner, by helping you identify when sites are no longer needed. This feature works by automatically sending an e-mail message to site owners to see if they consider their site active. If the owner does not respond to the e-mail message (after a specified number of messages over a specified length of time), the site can be deleted.

To plan for site use confirmation and deletion, decide the following:

  • How long you want to wait before checking to see if a site is inactive. The default length of time for team or project sites is 90 days after site creation, but you should probably give owners longer than that. For a test or personal site, 90 days is probably too long. Usually a site that was created, was actively used, and is now ready to be deleted or archived, took at least six months and probably a few years to complete that life cycle. Reminders every six months are valuable for those situations.

  • How often you want to send an e-mail message to site owners to see if their sites are inactive. After the first e-mail message, if the site administrator does not respond, you can continue with additional notices at daily, weekly, or monthly intervals.

  • Whether you want to automatically delete unused sites. If the site administrator does not respond to multiple e-mail messages, do you want to go ahead and delete the site automatically? We recommend that you make a backup first. You can do so by making sure that regular backups are performed. You can use the SharePoint 2010 developer portal on MSDN (http://go.microsoft.com/fwlink/p/?LinkId=178818) to customize this functionality so that it automatically makes a backup of the site before deletion, but this is not default behavior.

  • If you are going to automatically delete unused sites, how many e-mail messages will you send to site owners before you do so? By default, four weekly notices are sent before site deletion, but you can increase or decrease this number to suit your needs.

For more information, see Manage unused Web sites (SharePoint Foundation 2010).

Worksheet

Use the following worksheet to plan for site maintenance and management:

  • Site Creation and Maintenance Worksheet (http://go.microsoft.com/fwlink/p/?LinkId=193521)


Plan quota management (SharePoint Foundation 2010)

A quota specifies storage limit values for the maximum amount of data that can be stored in a site collection. Quotas also specify the storage size that, when reached, triggers an e-mail alert to the site collection administrator. Quota templates apply these settings to any site collection in a SharePoint farm.

By default, a quota contains 300 points. A point is a relative measurement of resource usage, for example, CPU cycles, memory, or page faults. Points enable comparisons between measurements of resource usage that could not be compared otherwise. For example, it takes millions of CPU cycles to make up one point, but each time a sandboxed solution stops working is counted as one point. For more information about sandboxed solutions, see Sandboxed solutions overview (SharePoint Foundation 2010).

Quotas are particularly useful when you are using Microsoft SharePoint Foundation 2010 in enterprise environments, such as a company-wide intranet or an Internet Service Provider (ISP). You should use quotas in these environments to ensure that one site collection cannot use so many resources that other site collections can no longer function. You can assign a quota template to a site collection when you create the site collection, or you can assign a quota template at a later time. You can also reverse a decision to use quotas at any place in the site collection hierarchy.

In this article:

  • About planning quota management

  • Determine quota template settings

  • Determine recycle bin settings

  • Delete unused Web sites

About planning quota management

The basic steps to plan quota management are the following:

  1. Determine quota template settings

  2. Determine recycle bin settings

  3. Delete unused Web sites

This article contains guidance about how to determine the quota settings for site collections in an enterprise. This article does not include prerequisite information such as how to configure outgoing e-mail, start the Disk Quota Warning timer job, or plan performance and capacity.

Determine quota template settings

There is no default quota template for site collections in a SharePoint Foundation 2010 environment. For example, a quota for a site collection might use the following settings as a starting point:

  1. Automated e-mail is sent to a site collection administrator when the size of the site reaches 450 megabytes (MB).

  2. Users are prevented from uploading additional documents when the size of a site collection reaches 500 MB.

You must evaluate the size and number of items that you expect users to store in their sites. You must also adjust these settings appropriately to ensure that the sites are used in accordance with an organization's best practices. For example, if a specific team or group in an organization has a business need to store a greater volume of content on its team site, you can adjust the quota limits for that site collection.

The size of the data reported by quotas does not necessarily match the size of the storage in the database. This is because the quota feature estimates storage figures for empty sites (that is, sites that contain no user content) and includes those figures in the quota, in addition to the actual storage from the database. The estimated size of an empty site includes the real size of the template pages for SharePoint Foundation 2010, for example, the forms pages and the pages in the _layouts directory.

If you change the values for a quota template, those changes apply only to new site collections to which you apply the template. SharePoint Foundation 2010 does not apply the changed quota values to existing sites collections unless you use the object model to update the quota values in the database.

Determine recycle bin settings

The recycle bin can help to prevent the permanent deletion of content. The recycle bin enables site owners to retrieve items that users have deleted, without requiring administrator intervention such as restoring files from backup tapes. Key planning considerations include whether to use the second-stage recycle bin and how much space to allocate.

The recycle bin is turned on and off at the Web application level. By default, the recycle bin is turned on in all the site collections in a Web application.

The recycle bin has two stages. When a user deletes an item, the item is automatically sent to the first-stage recycle bin. By default, when an item is deleted from the first-stage recycle bin, the item is sent to the second-stage recycle bin. The second-stage recycle bin stores items that users have deleted from their recycle bins. Only site collection administrators can restore items from the second-stage recycle bin. The size that is specified for the second-stage recycle bin increases the total size of the site. You must plan data capacity accordingly.

Consider allocating at least a small amount of space, for example, 10 percent, to the second-stage recycle bin to accommodate cases in which a user mistakenly deletes an important document, a folder in a document library, or a column in a list.

Items in both the first-stage and the second-stage recycle bins are automatically deleted when the time period specified for the deleted items expires (by default, 30 days). However, when the size limit of the second-stage recycle bin is reached, items are automatically deleted starting with the oldest items. Site collection administrators can also empty the second-stage recycle bin manually. For more information, see Configure Recycle Bin settings (SharePoint Foundation 2010).

Delete unused Web sites

You can delete a quota template if you change your quota structures. However deleting a quota template does not delete quota values from site collections to which a quota template has been applied. If you want to remove quotas from all site collections that use a specific quota template, you must use the object model or perform a SQL Server query.

Automatic deletion of unused Web sites can help you lessen the risk of deleting data that is critical to business operations. You should include the following tasks in your planning process:

  • Require a secondary contact for all sites. If the site owner is not available or leaves the organization, the secondary contact can confirm the usage of the site. If you do not have a secondary contact and you shorten the number of days or number of notices that are given before you delete an unused site, you might accidentally delete a site that is still required.

  • Archive sites before they are deleted automatically. You will be able to restore the sites that contain business-critical information or plan to store the content databases for a longer duration, so that a deleted site can be restored.

For more information, see Manage unused Web sites.


Plan e-mail integration (SharePoint Foundation 2010)

Published: June 17, 2010

Enabling communication is a critical component for creating Web applications in which group members can interact with each other and keep up with changes to information through the use of alerts. The site collection features that are dependent on communications being properly set up include:

  • Alerts that notify group members when things have changed.

  • Administrative messages related to requests for site access and other site administration issues.

  • Discussion groups.

To make the most effective use of the communications features, planning should include understanding the software requirements and maintenance considerations.

Plan communication by using the following articles:

  • Plan incoming e-mail (SharePoint Foundation 2010), which provides information on how to set up e-mail for discussion groups.

  • Plan outgoing e-mail (SharePoint Foundation 2010), which provides information on how to use alerts and administrative messages.


Plan incoming e-mail (SharePoint Foundation 2010)
See Also

Published: June 17, 2010

The incoming e-mail feature of Microsoft SharePoint Foundation 2010 enables SharePoint sites to receive and store e-mail messages and attachments in lists and libraries. This article helps server and farm administrators understand the choices they need to make before they deploy the incoming e-mail feature for their organization.

In this article:

  • About incoming e-mail

  • Key decisions for planning incoming e-mail

  • Configuration options and settings modes

About incoming e-mail

The incoming e-mail feature enables teams to store the e-mail that they send to other team members without opening the SharePoint site and uploading the content that was sent in e-mail. This is possible because most types of lists and libraries can be assigned a unique e-mail address.

Before configuring incoming e-mail, you must perform the following tasks:

  • If you are using the basic scenario, each SharePoint front-end Web server must be running the Simple Mail Transfer Protocol (SMTP) service and the Microsoft SharePoint Foundation Web Application service.

  • If you are using the advanced scenario, you can use one or more servers in the server farm to run the SMTP service and to have a valid SMTP server address. Alternatively, you must know the name of a server outside the farm that is running the SMTP service and the location of the e-mail drop folder.

For more information about installing the SMTP service, see Configure incoming e-mail (SharePoint Foundation 2010).

Key decisions for planning incoming e-mail

As you plan to implement incoming e-mail, you must decide whether to use a basic or and advanced scenario, as described below.

Using a basic scenario

You can enable a basic incoming e-mail scenario by installing the Simple Mail Transfer Protocol (SMTP) service on the server running SharePoint Foundation 2010 and enabling incoming e-mail by using the automatic settings mode with all default settings. In this scenario, e-mail is delivered directly to your SMTP server and SharePoint Foundation 2010 periodically checks for e-mail in the default e-mail drop folder that is automatically configured by the SMTP service.

Selecting the automatic settings mode and accepting all the default settings is the easiest way to enable incoming e-mail because all configuration settings are made for you and, therefore, little expertise is required. For most organizations, this configuration is all that is needed.

You enable a basic incoming e-mail scenario in the following steps:

  1. The server administrator uses the Add Features Wizard to install the SMTP Server feature on the server from which you want to receive incoming e-mail. This installs and starts the SMTP service on that server.

  2. The farm administrator enables incoming e-mail by using the automatic settings mode and accepting all the default values.

  3. The site collection administrator enables the incoming e-mail feature on the libraries and lists in which they want to store incoming e-mail and assigns each library and list a unique e-mail address in the form address@SMTPserveraddress, for example, sharedfiles@SMTPserver.contoso.com.

When users send e-mail to the address of a list or library, SharePoint Foundation 2010 detects that new e-mail has been delivered and sends it to the appropriate list or library based on the e-mail address.

Note:

You can also use the automatic settings option in an advanced scenario and select whether to use the Microsoft SharePoint Directory Management service, a safe e-mail server, and an incoming e-mail server display address. These options are all discussed in the "Using the advanced scenario" later in this article.

If this basic scenario meets your needs, you can skip the remainder of this article. For more information, see Configure incoming e-mail (SharePoint Foundation 2010).

Using an advanced scenario

For more advanced administrators, additional choices are available, some of which require more expertise to deploy than choosing the basic scenario with all default options. This section describes the following configuration options:

  • SharePoint Directory Management service

  • Incoming e-mail server display address

  • Safe e-mail server

  • E-mail drop folder

If you use the advanced scenario to configure incoming e-mail, you will need to perform additional procedures. For more information, see Configure incoming e-mail (SharePoint Foundation 2010).

SharePoint Directory Management service

The SharePoint Directory Management service connects SharePoint sites to your organization's user directory to provide enhanced e-mail features. The benefit of using this service is that it enables users to create and manage e-mail distribution groups from SharePoint sites. This service also creates contacts in your organization's user directory so people can find e-mail-enabled SharePoint lists in their address books. However, using SharePoint Directory Management service requires more management because it is communicating with Active Directory Domain Services (AD DS).

Note:

It is recommended that you use Microsoft Exchange Server together with SharePoint Directory Management service. If you do not, you must customize your own directory management service.

You can configure the SharePoint Directory Management service by using either the automatic or the advanced settings mode. You can choose to enable the SharePoint Directory Management service in your SharePoint server farm, or you can use the SharePoint Directory Management service of another farm. One advantage of using the service running on another farm is that Active Directory permissions are managed in a centralized place (that is, on the other farm).

To enable this service on a server or server farm runningSharePoint Foundation 2010, the SharePoint Central Administration application pool account used by SharePoint Foundation 2010 must have write access to the container that you specify in Active Directory. This requires an Active Directory administrator to set up the organizational unit (OU) and the permissions on the OU. The advantage of using the SharePoint Directory Management service on a remote farm is that you do not need the help of an Active Directory administrator to create and configure the OU if the OU already exists.

Note:

There are a number of procedures that you need to perform if you plan to use SharePoint Directory Management service. For more information, see Configure incoming e-mail (SharePoint Foundation 2010).

A typical directory management scenario proceeds in the following steps:

  1. A site collection administrator creates a new SharePoint group.

  2. The administrator chooses to create a distribution list to associate with that SharePoint group and assigns an e-mail address to that distribution list.

  3. Over time, the administrator adds users to and removes users from this SharePoint group. As users are added to and removed from the group, the SharePoint Directory Management service automatically adds and removes them from the distribution list, which is stored in the Active Directory directory service. Because distribution lists are associated with a particular SharePoint group, this distribution list is available to all members of that SharePoint group.

  4. By default, e-mail addresses are automatically generated for discussion boards and calendars on team sites and then added to the team distribution list. The e-mail addresses for these two lists will be in the following form, by default: GroupAddress.discussions and GroupAddress.calendar.

  5. By including e-mail addresses for discussion boards and calendars in the distribution list, all e-mail and meeting invitations sent to this distribution list will be archived in the team site.

For more information about SharePoint Directory Management Service, see Inside SharePoint: SharePoint Directory Integration (http://go.microsoft.com/fwlink/p/?LinkId=151766).

SharePoint Directory Management Service configuration options

When you configure the SharePoint Directory Management service to create distribution groups and contacts in Active Directory, you must provide the following information:

  • Name of the Active Directory container in which new distribution groups and contacts will be created. This must be provided in the following format:

    OU=ContainerName, DC=DomainName, DC=TopLevelDomainName

    Example

    OU=SharePointContacts,DC=Contoso,DC=com

  • Name of the SMTP server to use for incoming e-mail (or accept the default SMTP server if one exists). This must be provided in the following format:

    Server.subdomain.domain.top-level_domain

    For example, SharePointServer.support.contoso.com

  • Whether to accept messages from only authenticated users.

  • Whether to allow users to create distribution groups from SharePoint sites. If you choose yes for this option, you can also choose whether users can do any combination of the following actions:

    • Create a new distribution group.

    • Change a distribution group's e-mail address.

    • Change a distribution group's title and description.

    • Delete a distribution group.

When configuring the SharePoint Directory Management service to create distribution groups and contacts using a remote SharePoint Directory Management service, you must provide the following information:

  • The URL of the remote directory management service, for example, http://server:adminport/_vti_bin/SharePointEmailWS.asmx.

  • The name of the SMTP server to use for incoming e-mail.

  • Whether to accept messages from only authenticated users.

  • Whether to allow users to create distribution groups from SharePoint sites.

Incoming e-mail server display address

Administrators can specify the e-mail server address that will be displayed in Web pages when users create an incoming e-mail address for a site, list, or group. This setting is often used in conjunction with the SharePoint Directory Management service to provide a more friendly e-mail server address for users to type, for example, mylist@example.com.

Safe e-mail server

You can configure SharePoint Foundation 2010 to accept e-mail from any e-mail server or only e-mail that has been routed through a safe-e-mail server application.

You can derive the following benefits by routing e-mail through a safe e-mail server:

  • User authentication: The SMTP service cannot authenticate users who send e-mail to your site, but Exchange Server can. The server administrator can use the SharePoint Central Administration Web site to specify that the system accept e-mail from authenticated users only if the e-mail is sent through Exchange Server.

  • Spam filtering: Exchange Server provides spam filtering to eliminate unsolicited commercial e-mail before it is forwarded to its destination — in this case, the server running SharePoint Foundation 2010. Another technique that can reduce spam is to allow members of the team site to archive e-mail only in lists on which you have granted write permissions to members.

  • Virus protection: Exchange Server provides virus protection for e-mail routed through it.

Note:

Because this option is only available in automatic mode, you cannot specify one or more safe e-mail servers and also specify an e-mail drop folder.

E-mail drop folder

If the SMTP service is running on another server than on the SharePoint server, you must specify the location from which SharePoint Foundation 2010 retrieves incoming e-mail. You specify the e-mail drop folder so that SharePoint Foundation 2010 knows from where to retrieve incoming e-mail. However, if you specify a specific e-mail drop folder, SharePoint Foundation 2010 cannot detect configuration changes on the remote e-mail server that is delivering the e-mail to your drop folder. This means that if an administrator configures the e-mail server to no longer deliver e-mail to this folder, SharePoint Foundation 2010 cannot detect that the configuration has changed, and therefore will not be able to retrieve the files from the new location.

Note:

When incoming e-mail is set to advanced mode, you must ensure that you have the proper permissions on the e-mail drop folder. For more information, see Configure incoming e-mail (SharePoint Foundation 2010).

Note:

Because this option is only available in advanced mode, you cannot specify an e-mail drop folder and also specify one or more safe e-mail servers.

Configuration options and settings modes

As a farm administrator, you have two settings modes from which to choose when enabling incoming e-mail: automatic and advanced. As described in the "Using a basic scenario" section, you can choose the automatic settings mode with default settings. However, the automatic settings mode has additional options that you can choose.

The following table describes the configuration options and whether they are configured on the Configure Incoming E-Mail Settings page in Central Administration by using the automatic settings mode or the advanced settings mode.

Configuration option | Automatic settings mode | Advanced settings mode
Safe e-mail servers | Yes | No
E-mail drop folder | No | Yes
SharePoint Directory management service | Yes | Yes
Incoming e-mail server display address | Yes | Yes

The advanced and automatic settings modes are similar in that they both enable farm administrators to configure the SharePoint Directory Management service and the e-mail server address to display in Web pages. These settings modes differ in that the automatic settings mode replaces the ability to choose what e-mail servers to accept e-mail from with the ability to specify the folder to which e-mail is dropped. SharePoint Foundation 2010 uses this e-mail drop folder to detect new e-mail messages.

Note:

The e-mail drop folder setting is not available in automatic mode, because that mode automatically sets the e-mail drop folder to the folder that is specified by the SMTP service.

Plan incoming e-mail worksheet

Download a Word version of the Plan incoming e-mail worksheet (http://go.microsoft.com/fwlink/p/?LinkId=200542). Use this worksheet to plan incoming e-mail in order to enable SharePoint sites to receive and store e-mail messages and attachments in lists and libraries.

See Also

Concepts

Configure incoming e-mail (SharePoint Foundation 2010)
Plan outgoing e-mail (SharePoint Foundation 2010)
Configure outgoing e-mail (SharePoint Foundation 2010)


Plan outgoing e-mail (SharePoint Foundation 2010)
See Also

Published: June 10, 2010

This article helps site administrators understand both the uses for integrating outgoing e-mail and the requirements for integrating it into their site collections.

Outgoing e-mail is the foundation on which site administrators can implement several e-mail notification features. These features help end users track changes and updates to individual site collections and allow site administrators to deliver status messages.

In this article:

  • About outgoing e-mail

  • Key planning phases of outgoing e-mail

About outgoing e-mail

Properly configuring outgoing e-mail is a requirement for implementing e-mail alerts and notifications. The outgoing e-mail feature uses an outbound Simple Mail Transfer Protocol (SMTP) service to relay e-mail alerts and notifications. These e-mail features include the following:

  • Alerts

    In a large and growing site collection, users need an efficient way to keep up with updates to lists, libraries, and discussions. Setting up alerts provides an effective means to stay on top of changes. For example, if many users work on the same document, the owner of the document can set up alerts to be notified whenever there are changes to this document. Users can specify which areas of the site collection or which documents they want to track and decide how often they want to receive alerts.

    Note:

    Users must have at least View permissions to set up alerts.

  • Administrative messages

    Site administrators might want to receive notices when users request access to a site or when site owners have exceeded their specified storage space. Setting up outgoing e-mail enables site administrators to receive automatic notifications for site administration issues.

Outgoing e-mail support can be enabled at both the server farm level (available in the System Settings section of the Central Administration Web site) and at the Web application level (available in the Application Management section of the Central Administration Web site). Therefore, you can specify different settings for a specific Web application. Outgoing e-mail settings at the Web application level override those set up at the server farm level.

Key planning phases of outgoing e-mail

Before you configure outgoing e-mail, you must have an SMTP service to relay e-mail alerts and notifications.

The outgoing e-mail settings include several components that must be considered when planning for this feature:

  • An SMTP service to relay e-mail alerts and notifications. You will need the DNS name or IP address of the SMTP mail server to use.

  • An address to use in the header of an alert message that identifies the sender of the message.

  • A Reply-to address that is displayed in the To field of a message when a user replies to an alert or notification.

  • A character set to use in the body of alert messages.

Outbound SMTP server

The SMTP service is a component of Internet Information Services (IIS); however, it is not enabled by default with IIS. It can be enabled by using Add or Remove Programs in Control Panel.

After determining which SMTP server to use, the SMTP server must be configured to allow anonymous access and to allow e-mail messages to be relayed. Additionally, the SMTP server must have Internet access if you want the ability to send messages to external e-mail addresses.

For more information about installing, configuring, and managing the SMTP service, see Help for Internet Information Services (IIS) Manager (http://go.microsoft.com/fwlink/p/?LinkId=72343).

Note:

Only a member of the Farm Administrators group can configure an SMTP server. The user must also be a member of the local Administrators group on the server.

From and Reply-to addresses

When configuring outgoing e-mail, you can configure the following two addresses:

  • From address

    Alerts and notifications are sent from an administrative account on the server farm. This account is probably not the one you want to be displayed in the From field of an e-mail message. The address that you use does not need to correspond to an actual e-mail account; it can be a simple friendly address that is recognizable to an end user. For example, "Site administrator" might be an appropriate From address.

  • Reply-to address

    This is the address that will be displayed in the To field of a message if a user replies to an alert or notification. The Reply-to address should also be a monitored account to ensure that end users receive prompt feedback for issues they might have. For example, a help desk alias might be an appropriate Reply-to address.

Character set

When you configure outgoing e-mail, you will need to specify the character set to use in the body of e-mail messages. A character set is a mapping of characters to their identifying code values. The default character set for outgoing e-mail is Unicode UTF-8, which allows most combination of characters (including bidirectional text) to co-exist in a single document. In most cases, the default setting of UTF-8 works well, although East Asian languages are best rendered with their own character set.

Be aware that if you select a specific language code, the text is less likely to appear correctly in mail readers configured for other languages.

See Also

Concepts

Configure outgoing e-mail (SharePoint Foundation 2010)


Plan for mobile devices (SharePoint Foundation 2010)
See Also

Published: February 24, 2011

This article describes the mobile features in Microsoft SharePoint Foundation 2010 and important considerations for how to plan for mobile devices.

A complete discussion about Microsoft SharePoint Foundation Internet or extranet topology design is beyond the scope of this article.

In this article:

  • About mobile features

  • Configure mobile features

  • Plan for mobile device access

  • Security considerations

About mobile features

Mobile features enable users to work with SharePoint content from their mobile devices. SharePoint Foundation provides a lightweight interface for navigating and accessing SharePoint document libraries, lists, wikis, blogs, Web Part Pages, and back-end business data. The mobile features include the following:

  • Mobile views, which display a view of SharePoint sites that is optimized for mobile devices.

  • The ability to view Microsoft Office Word, Excel, and PowerPoint documents in mobile browsers. This feature requires that Office Web Apps be installed. For more information, see Office Web Apps (Installed on SharePoint 2010 Products).

  • Mobile alerts, which enable users to subscribe to Short Message Service (SMS) alerts. The alerts are sent to users' mobile devices when a SharePoint list or item is changed.

Configure mobile features

This section describes how to configure mobile features.

Mobile views

By default, mobile views are enabled for most lists or libraries that were created in SharePoint Foundation 2010. You must enable mobile views for custom lists, custom libraries, or for lists or libraries that were created in previous versions of SharePoint and have been upgraded to SharePoint Foundation 2010.

A browser definition file contains a list of the mobile browsers and devices that can access mobile views in SharePoint Foundation. SharePoint Foundation uses the file to determine whether to redirect a mobile browser to the mobile view of the site. For example, if a mobile browser or device is not listed in the browser definition file, a standard view of the site is displayed in the mobile browser. The browser definition file can be updated by product updates. You can also modify the file to change the redirect behavior of a mobile browser or to add a mobile browser or device to the list.

For more information about mobile views, see Configure mobile views (SharePoint Foundation 2010).

Mobile alerts

The mobile alert feature enables users to subscribe to alerts that are sent by using Short Message Service (SMS). The alerts are sent to users' mobile devices when changes are made to a SharePoint list or item. To take advantage of this feature, you must configure a mobile account that will be used to send the SMS alerts. For more information, see Configure a mobile account (SharePoint Foundation 2010).

Plan for mobile device access

Mobile device access is largely influenced by the decisions that you make in your server farm and environment planning. The following sections describe how design decisions you make for your server farm can affect mobile device access. We recommend that you include mobile device access planning in your overall server farm and environment planning.

For more information about server farm planning. See Server farm and environment planning (SharePoint Foundation 2010) and Plan authentication methods (SharePoint Foundation 2010).

Authentication

SharePoint Foundation supports multiple authentication methods and authentication modes. Not all mobile browsers and devices work with all the available authentication methods. When you plan for mobile device access, you must:

  • Determine the mobile devices that you must support. Then, learn the authentication methods that are supported by the mobile devices. This information varies by manufacturer.

  • Determine the sites that you want to make available to your mobile device users.

  • Determine whether you want to make SharePoint sites accessible for mobile devices when the devices are used outside the corporate firewall. If you do, the method that you use to enable external access can also affect mobile device authentication.

Consider the tradeoffs between selecting an authentication method that is supported by most mobile devices, implementing multiple authentication methods in your Web application, or deciding to support only a few mobile devices.

External access

Mobile device users can access a SharePoint site either by using a mobile browser or by using a rich client application such as Microsoft SharePoint Workspace Mobile 2010. This section summarizes how to make SharePoint sites accessible for mobile devices when the devices are used outside the corporate firewall. There are three methods for enabling external access:

  • Virtual private network server A virtual private network (VPN) server that supports Secure Sockets Layer (SSL), such as Microsoft Forefront Unified Access Gateway (UAG), enables you to publish SharePoint sites across the corporate firewall. The following steps summarize how to make a SharePoint site accessible from outside the corporate firewall when you use a VPN server:

    1. Set up the VPN server.

    2. Publish the SharePoint site on the VPN server.

    3. Configure an alternate access mapping for the SharePoint site.

    4. Add the SharePoint site to a zone that allows cross-firewall access.

    Note:

    Forefront UAG is the only VPN server that is supported by Microsoft Office Mobile 2010 on Windows Phone 7 and Windows Phone 6.5.

    For more information about Forefront UAG, see Forefront Unified Access Gateway (UAG) (http://go.microsoft.com/fwlink/p/?LinkID=196384), SharePoint publishing solution guide (http://go.microsoft.com/fwlink/p/?LinkId=206256), and Deploying Forefront UAG for mobile devices.

  • Mobile proxy server Mobile proxy servers, such as Microsoft System Center Mobile Device Center and Blackberry Enterprise Server, help mobile devices work within the IT infrastructure of a company. To access a SharePoint site from outside the corporate firewall, the mobile proxy server must pass the mobile browser's HTTP headers directly through to SharePoint Foundation.

  • Direct Internet access The SharePoint site can be placed on the extranet. This method supports only Basic authentication. We recommend that you use a combination of technology and policy safeguards, such as SSL, with any Internet-facing servers.

For more information about mobile devices and external access, see Configure external access for mobile devices (SharePoint Foundation 2010).

Plan for SharePoint Workspace Mobile and Windows Phone 7

Microsoft SharePoint Workspace Mobile 2010, which is part of Microsoft Office Mobile 2010, is available on Windows Phone 7 and Windows Phone 6.5. SharePoint Workspace Mobile 2010 enables users to connect to a SharePoint site by using the Office Hub instead of the mobile browser. The following list describes planning considerations for SharePoint Workspace Mobile and Windows Phone 7:

  • Forefront UAG is the only VPN that is supported by Windows Phone 7.

  • NTLM is the only authentication method that is supported by SharePoint Workspace Mobile for intranet sites.

  • SharePoint Workspace Mobile does not support directly connecting to sites in the Internet zone. To connect by using SharePoint Workspace Mobile requires the following:

    • The SharePoint site is published over SSL on the Forefront UAG server.

    • The SharePoint site is published for SharePoint Workspace Mobile on the Forefront UAG server.

    • Users have configured the Forefront UAG settings on their Windows Phone device.

      When a user connects to the published site, Forefront UAG identifies the user agent sent by SharePoint Workspace Mobile and responds with an HTTP 401 challenge. SharePoint Workspace Mobile uses the user credentials that are configured in the Forefront UAG settings of the mobile device to authenticate to Forefront UAG by using Basic authentication. Forefront UAG then authenticates the user to the SharePoint site.

    Note:

    A site that has a fully qualified domain name (for example, https://hrweb.contoso.com) is considered to be in the Internet zone by SharePoint Workspace Mobile.

  • By default, Windows Phone 7 users are redirected to the standard view of SharePoint sites. This is because the Windows Phone 7 user agent is not included in the SharePoint Foundation 2010 RTM version of the mobile definition file (compat.browser file). To see a mobile view of a site, users can append ?mobile=1 to the URL of the site. You can also add the Windows Phone 7 user agent to the compat.browser file. For more information about how to modify the compat.browser file, see Configure mobile views (SharePoint Foundation 2010).

    Tip:

    The compat.browser file can be updated when product updates to SharePoint Foundation are released to include newer devices.

  • By default, the Windows Phone 7 mobile browser cannot authenticate to a site that is configured to use Security Assertion Markup Language (SAML) token-based authentication. As a workaround, you can edit the compat.browser file, find the entry for the Office Mobile Web Access user agent, and change the isMobileDevice setting from true to false. This enables the mobile browser to redirect the user to the sign-in site for the SPTrustedIdentityTokenIssuer that is associated with the Web application. If the identity provider security token service (IP-STS) uses an authentication method that is not supported by the Windows Phone 7 device, such as two-factor authentication, the user will still be unable to authenticate to the site.

  • Documents that are protected by Information Rights Management (IRM) cannot be opened by Windows Phone 7.

For more information about Windows Phone 7 and SharePoint Workspace Mobile, see Windows Phone Help and how to (http://go.microsoft.com/fwlink/p/?LinkId=202166) and Use Microsoft SharePoint Workspace Mobile (http://go.microsoft.com/fwlink/p/?LinkId=192854).

Security considerations

This section discusses security considerations for mobile devices.

Mobile devices can contain sensitive data or documents. Because mobile devices can be lost or stolen, we recommend that you set policies around mobile devices to help protect sensitive data and documents. This can include securing the mobile device by using a PIN or lock, and ensuring that you can remotely wipe the data on the mobile device. Available programs and features vary by mobile device.

You can educate users about how they can help protect their user credentials. This can include signing out of sites when they are done, not enabling any option that keeps them signed in or remembers their password, and frequently deleting cookies in the mobile browser. This can help prevent others from using their user credentials to log on to a SharePoint site if their mobile device is lost or stolen.

We recommend that you enable SSL to secure communication between mobile browsers and SharePoint Foundation.

See Also

Concepts

Mobile administration (SharePoint Foundation 2010)


Server farm and environment planning (SharePoint Foundation 2010)

This section describes how to plan server farms and environments.

In this section:

  • System requirements (SharePoint Foundation 2010)

  • Logical architecture planning (SharePoint Foundation 2010)

  • Plan authentication (SharePoint Foundation 2010)

  • Security planning for server farms (SharePoint Foundation 2010)

  • Plan security hardening (SharePoint Foundation 2010)

  • Plan automatic password change (SharePoint Foundation 2010)

  • SQL Server and storage (SharePoint Foundation 2010)

  • Plan for business continuity management (SharePoint Foundation 2010)

  • Virtualization planning (SharePoint Foundation 2010)

  • Performance and capacity test results and recommendations (SharePoint Foundation 2010)


System requirements (SharePoint Foundation 2010)

Before you install Microsoft SharePoint Foundation 2010, you must ensure that you have installed all required hardware and software. To effectively plan your deployment, you must understand the level of support provided for the Web browsers that you will be using in your environment and how support for IP versions 4 and 6 is implemented in SharePoint Foundation 2010. You must also understand the URL and path length restrictions in SharePoint Foundation 2010.

The articles in this section help you prepare for the installation of SharePoint Foundation 2010 by providing information about the prerequisites that you need to run SharePoint Foundation 2010.

  • Hardware and software requirements (SharePoint Foundation 2010)

    This article describes the hardware and software requirements that you must meet to successfully install SharePoint Foundation 2010.

  • Plan browser support (SharePoint Foundation 2010)

    This article describes levels of support for Web browsers to use with SharePoint Foundation 2010.

  • URL path length restrictions (SharePoint Foundation 2010)

    This article discusses the specific URL path length and character restrictions in SharePoint Foundation 2010, Internet Explorer 7, and Internet Explorer 8 that you should be aware of when planning sites, navigation, and structure.

  • IP support (SharePoint Foundation 2010)

    This article describes SharePoint Foundation 2010 support for IP version 4 (IPv4) and IP version 6 (IPv6).


URL path length restrictions (SharePoint Foundation 2010)

Published: August 5, 2010

This article discusses the specific URL path length and character restrictions in Microsoft SharePoint Foundation 2010, Internet Explorer 7, and Internet Explorer 8 that you should be aware of when planning sites, navigation, and structure. This article does not discuss URL length limitations in other browsers. For this information, see the browser documentation.

In this article:

  • Understanding URL and path lengths

  • URL path length limitations

  • Resolving URL length problems

Understanding URL and path lengths

This section discusses URL composition, how SharePoint Foundation 2010 builds URLs, how URLs are encoded and lengthened, and passed as parameters in other URLs.

SharePoint URL composition

The total length of a SharePoint URL equals the length of the folder or file path, including the protocol and server name and the folder or file name, plus any parameters that are included as part of the URL. The formula is as follows:

  • URL = protocol + server name + folder or file path + folder or file name+ parameters

For example, the following is a typical URL path to a file stored in SharePoint Foundation 2010:

http://www.contoso.com/sites/marketing/documents/Shared%20Documents/Promotion/Some%20File.xlsx

Where the parts of the URL path are as listed in the following table.

URL part | Example
Protocol | http://
Server name | www.contoso.com/
Folder or file path | sites/marketing/documents/Shared%20Documents/Promotion/
File name | Some%20File.xlsx

URL Encoding

URL encoding ensures that all browsers will correctly transmit text in URL strings. Characters such as a question marks (?), ampersands (&), slash marks (/), and spaces might be truncated or corrupted by some browsers. SharePoint Foundation 2010 adheres to the standards for URL encoding that are defined in The Internet Engineering Task Force (IETF) RFC 3986 (http://go.microsoft.com/fwlink/p/?LinkId=195564&clcid=0x409).

If you have non-standard ASCII characters, such as high-ASCII or double-byte Unicode characters, in the SharePoint URL, each of those characters is URL-encoded into two or more ASCII characters when they are passed to the Web browser. Thus, a URL with many high-ASCII characters or double-byte Unicode characters can become longer than the original un-encoded URL. The list below gives examples of the multiplication factors:

  • High-ASCII characters — for example, (!, ", #, $, %, &, [Space]): multiplication factor = 3

  • Double byte Unicode characters — for example, Japanese, Chinese, Korean, Hindi: multiplication factor = 9

For example, when you translate the names of sites, library, folder, and file in the URL path http://www.contoso.com/sites/marketing/documents/Shared%20Documents/Promotion/Some%20File.xlsx into Japanese, the resulted encoded URL path will become something like the following:

http://www.contoso.com/sites/%E3%83%9E%E3%83%BC%E3%82%B1%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0/%E6%96%87%E6%9B%B8/DocLib/%E3%83%97%E3%83%AD%E3%83%A2%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB.xlsx. This path is 224 characters, whereas the original URL path is only 94 characters.

Important:

The following characters cannot be used in an un-encoded URL: (~, #, %, &, *, {}, \, :, <>, /, +, |, ").

URL parameters

URL parameters are data that are included as part of the URL that are processed. These parameters are also URL-encoded and can be encoded multiple times, producing very long URLs.

For example, if you browse to a list, the URL might be something like the following: http://www.contoso.com/sites/marketing/documents/Shared%20Documents/Forms/AllItemA.aspx?RootFolder=%2Fsites%2Fmarketing%2Fdocuments%2FShared%20Documents%2FPFPromoti&FolderCTID=0x012000F2A09653197F4F4F919923797C42ADEC&View={CD527605-9A7A-448D-9A35-67A33EF9F766}. This URL is 260 characters.

If you then click Create View on the Library tab, the entire URL is included in the resulting URL as the source parameter and it is encoded to be much longer — for example, http://www.contoso.com/sites/marketing/documents/_layouts/ViewType.aspx?List=%7BED6E21E0%2DDF28%2D4165%2DBC3E%2D5371987CC2D2%7D&Source=http%3A%2F%2Fwww%2Econtoso%2Ecom%2Fsites%2Fmarketing%2Fdocuments%2FShared%2520Documents%2FForms%2FAllItems%2Easpx%3FRootFolder%3D%252Fsites%252Fmarketing%252Fdocuments%252FShared%2520Documents%252FPromotion%26FolderCTID%3D0x012000F2A09653197F4F4F919923797C42ADEC%26View%3D%7BCD527605%2D9A7A%2D448D%2D9A35%2D67A33EF9F766%7D. This URL is 457 characters.

Important:

SharePoint Foundation 2010 truncates the URL source parameter if the total URL length to be passed to Internet Explorer is more than 1950 bytes. The source parameter is a reference to a previously visited page. The result of the truncation of the source parameter is that the user will be referred back to default location rather than the location specified in the source parameter.

Other parameters, such as sort orders, root folder parameters, and views are not truncated.

URL path length limitations

This section discusses the different URL length limitations in SharePoint Foundation 2010 and Internet Explorer, and how to plan for URL path lengths.

SharePoint URL path length limitations

The limitations In this section apply to the total length of the URL path to a folder or a file in SharePoint Foundation 2010 but not to the length of any parameters. Also, these limitations apply only to un-encoded URLs, not to encoded URLs. There is no limit to encoded URLs in SharePoint Foundation 2010. The limitations are the following:

  • 260 Unicode (UTF-16) code units - the characters in a full file path, not including a domain/server name.

  • 256 Unicode (UTF-16) code units - the characters in a full folder path, not including the file name and the domain/server name.

  • 128 Unicode (UTF-16) code units - characters in a path component, that is, a file or folder name.

  • 260 Unicode (UTF-16) code units - the characters in a full path, including a domain/server name for use with Office clients.

  • 256 Unicode (UTF-16) code units - the characters in a full path including the domain/server name, for use with Active X controls.

For more information, see Microsoft Knowledge Base article 894630, You receive a "The specified file or folder name is too long" error message (http://go.microsoft.com/fwlink/p/?LinkId=195567&clcid=0x409).

Note:

Understanding code units - In most cases, one UTF-16 character equals one UTF-16 code unit. However, characters that use Unicode code points greater than U+10000 will equal two UTF-16 code units. These characters include, but are not limited to, Japanese or Chinese surrogate pair characters. If your paths include these characters, the URL length will exceed the URL length limitation with fewer than 256 or 260 characters.

Internet Explorer URL length limitations

Internet Explorer also has limitations that are separate from those in SharePoint Foundation 2010. Even though you make the SharePoint Foundation 2010 URL path shorter than the limitations, you might experience an Internet Explorer URL length limitation because of added parameters and encoding of the URL. You must use the most restrictive limitation as a guideline for planning URL lengths.

Both Internet Explorer 7 and Internet Explorer 8 have a maximum URL length of 2,083 UTF-8 characters and a maximum path length of 2,048 UTF-8 characters. However, in Internet Explorer 7, under certain circumstances, the effective URL length limitation is 1024 UTF-8 characters, not 2083 UTF-8 characters. For more information about the URL length limits in Internet Explorer, see Microsoft Knowledge Base article 208427, Maximum URL length is 2,083 characters in Internet Explorer (http://go.microsoft.com/fwlink/p/?LinkId=195568&clcid=0x409).

Important:

Unless all of the browsers in the environment are Internet Explorer 8, use the effective limit of 1024 UTF-8 characters.

Resolving URL length problems

There are several ways that you can resolve or mitigate URL length problems in the SharePoint Foundation 2010 environment. The following list provides suggestions:

  • Upgrade all the end-user browsers to Internet Explorer 8, which has a longer URL length limit.

  • Use shorter names for sites, folders, and documents and control the depth of the site and folder structures to reduce the lengths of URLs.

  • If possible or allowed, use ASCII names for sites, folders, and documents. This will avoid situations where the URL will be lengthened by being encoded.

  • To reduce the risk that the SharePoint Foundation 2010 end-users will encounter problems because of URL length limitations, we recommend that you apply the following effective limits in the deployment:

    • 256 Unicode (UTF-16) Code units - the effective file path length limitation, including a domain/server name

    • 128 Unicode (UTF-16) Code units - the path component length limitation


Logical architecture planning (SharePoint Foundation 2010)

Published: May 26, 2011

This section contains articles to help you learn about and plan logical architectures for Microsoft SharePoint Foundation 2010.

In this section:

  • Logical architecture components (SharePoint Foundation 2010)

  • Design sample: collaboration sites (SharePoint Foundation 2010)

  • Services architecture planning (SharePoint Foundation 2010)

  • Plan for host-named site collections (SharePoint Foundation 2010)


Logical architecture components (SharePoint Foundation 2010)

Published: May 26, 2011

There are various ways that you can arrange the components in a logical architecture design. Each of the components presents different opportunities for sharing and isolation. Before you start a logical architecture design, do the following:

  • Know what your sharing and isolation goals are.

  • Evaluate the tradeoffs for each choice.

Each section in this article describes a particular logical architecture component and discusses the following considerations for that component: capacity, sharing and isolation, configurable items, administration, and planning recommendations.

In this article:

  • Server farms

  • Service applications

  • Application pools

  • Web applications

  • Zones

  • Policy for a Web application

  • Content databases

  • Site collections

  • Sites

  • Host-named site collections

Server farms

A server farm represents the top-level element of a design. Individual server farms provide physical isolation.

Several criteria that are determined by your organization might affect the number of server farms that are required. They include the following:

  • Heavy use of services, which might warrant one or more dedicated services farms.

  • Separate operational divisions of responsibility.

  • Dedicated funding sources.

  • Separate data center locations.

  • Industry requirements for physical isolation between sites.

However, you can satisfy many isolation requirements on a single server farm. For example, you can use different Internet Information Services (IIS) application pools with different process identities to achieve isolation at the process level for both sites and service applications.

In addition to isolation requirements that might require more than one server farm, an organization might implement multiple server farms to satisfy performance and scale goals, licensing requirements, or a publishing environment.

Service applications

A service application provides a resource that can be shared across sites within a farm or, in some cases, across multiple farms.

Microsoft SharePoint Foundation 2010 includes the infrastructure for hosting service applications, and the configuration of service offerings is flexible. Individual services can be configured independently and third parties can add services to the platform.

SharePoint Foundation 2010 includes a limited number of service applications. You can deploy only the services that are needed to a farm. The services infrastructure is extensible, and third-party companies can create additional service applications that can be used with SharePoint Foundation 2010.

Service applications are associated with Web applications. Each service application can be configured differently, as described in the following list:

  • Web applications can be configured to use only the services that are needed, instead of the complete set of services that are deployed.

  • You can deploy multiple instances of the same service in a farm and assign unique names to the resulting service applications.

  • You can share service applications across multiple Web applications within the same farm.

  • Some service applications can be shared across farms.

Capacity

There is no recommended limit for the number of service applications in a single farm.

Sharing and isolation

Service applications can be shared in the following ways:

  • Sharing the service application and the service data. This is the default behavior for services that are shared across Web applications. For example, search results are shared across Web applications that consume the same search application.

  • Sharing only the service application, but isolating the data by deploying the service in partitioned mode. In a hosted environment, you can deploy service applications in partitioned mode by using Windows PowerShell. Each tenant's data is stored in a separate partition in the database for the service. A tenant's subscription ID is used to map the tenant's service data to its sites. For example, if you deploy the search service in partitioned mode, each tenant will only see search results for its own content.

    Note:

    Not all service applications support partitioning.

Conversely, service applications can be isolated in the following ways:

  • Deploying multiple service applications in separate application pools to achieve process isolation of services and service data. For example, a finance team might warrant a separate and dedicated Business Data Connectivity application.

  • Deploying services in partitioned mode. This approach works well in hosted environments in which tenants will never share service data. However, it might not be practical in environments where there is a mixture of needs for shared and isolated service data.

If needed, you can also isolate service applications by deploying them to separate application pools to achieve process isolation. However, application pools are a limited resource and farm performance is affected if too many application pools are used. For more information, see Application pools in this article.

Configurable items

The following table displays configurable items that contribute to isolation and sharing.

Item

Description

Default group

By default, all service applications are included in the default group. You can add and remove service applications from the default group at any time, including when you create one.

When you create a Web application, you can select the default group or you can create a custom group of services. You create a custom group of services by selecting only the service applications that you want the Web application to use.

Connection (proxy)

When you create a service application, a connection for the service application is created at the same time. A connection is a virtual entity that connects Web applications to service applications. Some service applications store settings in the connections. In Windows PowerShell, connections are called proxies.

Service application permissions

You can delegate management of service applications to other users by granting them permissions to one or more of the service applications.

Administration

Configuration and management of service applications can be delegated to administrators who specialize in managing individual services, such as search, user profiles, and managed metadata.

In a hosted environment, tenants can manage some of the service settings for their organization.

Planning recommendations

Configure service applications either to share resources across multiple Web applications or isolate content. For example, you can share the Business Data Connectivity service across multiple Web applications or you can create separate instances of this service to dedicate to sites in a specific Web application. When you design a services strategy for an organization, consider the ways in which you can configure the individual services to increase overall content-sharing or isolation goals.

Application pools

In IIS, an application pool is a group of one or more URLs that are served by a worker process or set of worker processes.

When you create Web applications and services in SharePoint 2010 Products, you select an application pool to use or you can create a new application pool. Each application pool has its own worker process and can have a separate identity (security account) that prevents two processes from interacting.

Capacity

The memory overhead of an application pool is 30-50 MB plus any memory for the applications that run in the application pool process space. The various application demands usually quickly drive the memory usage of an application pool to 800 MB or larger. The limit for the number of application pools is influenced by the available memory on the system. That is, the number of application pools is dictated by the following two factors:

  • Available addressable memory.

  • The amount of memory consumed by applications that run in the application pool.

The general guideline for acceptable performance is to use eight or fewer application pools.

Sharing and isolation

IIS application pools enable multiple sites to run on the same server but still have their own worker processes and identity. This can help prevent an exploit on one site that enables the attacker to inject malicious code that can attack sites in different application pools. More importantly, this strategy isolates code that introduces memory issues or other issues so that the problematic code does not affect all applications.

Configurable items

Using a separate application pool identity for each application pool is recommended, if it is needed for security and reasons of isolation.

Administration

If separate identities are used for each application pool, each identity must be maintained.

Planning recommendations

Practically speaking, consider using a dedicated application pool for the following reasons:

  • To separate authenticated content from content that is primarily anonymous.

  • To isolate applications that store passwords for and interact with external business applications, such as Business Data Connectivity connections.

Web applications

A Web application is an IIS Web site that is created and used by SharePoint 2010 Products. A Web application can be extended up to four times to create four additional zones in SharePoint 2010 Products. This extension results in as many as five IIS Web sites that are associated with a single Web application. Each IIS Web site is associated with a different zone. You can assign each Web application a unique domain name. For more information, see Zones in this article.

Sharing and isolation

Each Web application has a unique domain name, which helps prevent cross-site scripting attacks.

Configurable items

The following table displays configurable items that contribute to isolation and sharing.

Item | Description
Service applications | Service applications are associated with Web applications. When you create a Web application, you can select the default proxy group (default set of service applications), or you can specify a custom set of service applications for the Web application. All sites in a Web application consume services from the same service applications. A service application can provide services for more than one Web application. This shares content and profile data across the Web applications.
Zones | Within a Web application, you can create as many as five zones. Use zones to enforce different access and policy conditions for large groups of users.
Policy for Web application | Create a policy to enforce permissions across one or more zones in a Web application. A policy can be created for a specific user or user group. For more information, see Policy for a Web application in this article.

Administration

Ongoing administration of Web applications is not significant.

Planning recommendations

Generally speaking, use dedicated Web applications to do the following:

  • Separate content available to anonymous users from content available to authenticated users.

  • Isolate users. For example, you can ensure that partners do not have access to intranet content by putting partner sites in a separate Web application.

  • Enforce permissions by using policies. For example, you can create a policy to explicitly deny write permissions to one or more groups of users. Policies for a Web application are enforced regardless of permissions configured on individual sites or documents within the Web application.

  • Optimize database performance. Applications achieve better performance if they are put in content databases with other applications that have similar data characteristics. For example, team sites typically consist of only a few very large sites. In contrast, personal sites might grow to be large in number but small in size. By putting these different kinds of sites in separate Web applications, the resulting databases are composed of data with similar characteristics, which optimizes database performance.

  • Optimize manageability. Because creating separate Web applications results in separate sites and databases, you can implement different limits for each site's Recycle Bin, expiration, and size, and negotiate different service-level agreements. For example, you might allow more time to restore sites that are not critical to your business.

Zones

Zones represent different logical paths (URLs) of gaining access to the same Web application. Within each Web application, you can create as many as five zones by using one of the available zone names: Default, Intranet, Internet, Custom, or Extranet. Each name can be selected only one time per Web application. Each zone is represented by a different Web site in IIS.

The Default zone is the zone that is first created when a Web application is created. The other zones are created by extending a Web application.

Capacity

You can create as many as five zones in a Web application. Typically, zones are coordinated across Web applications so that zones of the same name are configured for the same users.

Sharing and isolation

Zones enable you to share and isolate users in the following ways:

  • Authentication type Each zone can be configured to use a different authentication provider, which enables you to share the same content across partner companies.

  • Network zone Each zone can be configured to accommodate users who enter from a different network zone, such as an extranet or the Internet.

  • Policy permissions You can explicitly allow or deny read or write permissions to content per zone based on a user account or a group account.

Configurable items

The following table displays configurable items that contribute to isolation and sharing.

Item | Description
Authentication provider | Each zone can be configured to use a different authentication provider.
Anonymous access | Turn anonymous access on or off per zone.
Secure Sockets Layer (SSL) | Turn SSL on or off per zone.
Public URL and alternate access mapping | Specify the domain name users will type to access content in the Web application. Or, use alternate access mapping to map user-friendly or zone-appropriate URLs to the default URL (server name and port) for each zone. Alternate access mapping provides support for off-box termination of SSL. Off-box termination of SSL occurs when a proxy server terminates an SSL request and then forwards the request to a Web server by using HTTP. In this case, alternate access mappings can be configured to return these requests by using SSL. This maintains secure communication between the client and the proxy server.
Policy for Web application | Create a unique set of policies for each zone within the Web application. If you have a special group of users who require exceptions to your overall security policy, consider using a separate zone to accommodate these users.

Administration

If you use alternate access mapping, consider that all public URLs require Domain Name System (DNS) entries to map the public URLs to the IP address of the load balancer used for the farm.

Planning recommendations

When you design zones, several key decisions are important to the success of the deployment. These decisions include design and configuration decisions for the following zones:

  • The Default zone

  • Zones for external access

The following sections describe some planning recommendations and requirements for zones, including the Default zone.

  • Administrative e-mail is sent with links from the Default zone. This includes e-mail to owners of sites that are approaching quota limits. Consequently, users who receive administrative e-mail messages and alerts must be able to access links through the Default zone. This is especially important for site owners.

  • Host-named site collections are available only through the Default zone. All users who are intended to access host-named site collections must have access through the Default zone.

  • The Default zone must be the most secure zone. This is because when a user request cannot be associated with a zone, the authentication and policies of the Default zone are applied.

In an extranet environment, the design of zones is very important for the following two reasons:

  • User requests can be initiated from several different networks, such as the internal network, a partner company network, or the Internet.

  • Users consume content across multiple Web applications. For example, an intranet environment might include sites that are hosted in several different Web applications. Additionally, employees might have access to both the intranet content and to partner collaboration content.

In an extranet environment, ensure that the following design principles are followed:

  • Configure zones across multiple Web applications to mirror one another. The configuration of authentication and the intended users should be the same. However, the policies associated with zones can differ across Web applications. For example, ensure that the Intranet zone is used for the same employees across all Web applications. In other words, do not configure the Intranet zone for internal employees in one Web application and remote employees in another.

  • Configure alternate access mappings appropriately and accurately for each zone and each resource.

Policy for a Web application

A policy for a Web application enforces permissions on all content in a Web application, which enables you to set security policy for users at the Web application level. The permissions in a policy override all other security settings that are configured for sites and content.

You can configure policy based on users or user groups in Active Directory Domain Services (AD DS), but not SharePoint groups. A policy can be defined for the Web application generally or only for a specific zone.

Capacity

There are no capacity restrictions that apply to policies for Web applications.

Sharing and isolation

A policy for a Web application provides a method of setting permissions based on users and the zone through which they access content.

For example, by using a policy, you can do the following:

  • Allow Help desk staff access to all content.

  • Deny write permissions to partners or vendors.

  • Deny access to secure data to a group of users regardless of how site owners configure permissions.

  • Ensure that the crawl account has access to crawl all content.

Configurable items

The following table displays configurable items that contribute to isolation and sharing.

Item

Description

User policy

Create a policy that applies to users or user groups:

  • The policy can be applied to all zones or one zone.

  • You can enter user names, group names, or e-mail addresses.

  • Specify the permissions that you want to apply to the policy.

You can modify the default permission levels or create new permission levels by clicking Permission Policy when you create the policy in Central Administration.

Anonymous policy

If anonymous access is enabled for the Web application or one or more zones, then you can create a policy that applies to all anonymous users. The default policy settings are as follows:

  • None: No policy

  • Deny write: No write permissions

  • Deny all: No access

Anonymous user policy levels cannot be modified.

Permission policy

Edit the specific permissions associated with one of the default permission levels, or create a new permission policy level. Additionally, you can specify the particular permissions that are allowed or denied for site collections and sites.

After creating a new permission policy level, you can create a user policy that uses the permission policy.

Administration

Ongoing administration of policies for Web applications is not significant.

Planning recommendations

Because policies are managed centrally, consider using policies to manage large groups of users, instead of individual users.

Content databases

By default, all content for a Web application is stored in one content database. You can separate content into multiple content databases at the site collection level. A content database can include one or more site collections. A single site collection cannot span multiple databases. Backing up and restoring sites occurs at the content database level.

Capacity

The guideline for acceptable performance is to implement 100 or fewer content databases per Web application.

Sharing and isolation

Planning for databases enables you to either optimize for efficiency (multiple site collections sharing a database) or isolation (one database per site collection).

Achieve scale efficiency by managing databases to the maximum target size. In this case, you configure database settings to add new site collections to existing databases until the maximum number of site collections is reached. You calculate the maximum number of site collections by estimating the average or maximum size of site collections divided into the maximum target size for the database. This approach works well when you expect many small site collections.

Achieve isolation of content between teams or projects by limiting a database to one site collection. This approach enables you to independently manage the content of individual teams. For example, you can independently manage each team's database for backup, recovery, and migration. This approach provides the opportunity to implement different service-level agreements for different teams or projects. This approach also enables you to manage content to the life cycle of a project. For example, you can archive a database when a project is completed.

Configurable items

The following table displays configurable items that contribute to isolation and sharing.

Item | Description
Database server | Specify which Microsoft SQL Server computer a content database is created on.
Failover server | You can choose to associate a content database with a specific failover server that is used in conjunction with SQL Server database mirroring.
Capacity settings | You can specify the number of sites that can be created before a Warning event is generated and the maximum number of sites that can be created in each database.

Administration

A manageable database administration plan balances the number of databases with the resources required to manage the databases.

Administration of databases includes the following actions:

  • Creating new databases for new team sites or site collections that require dedicated databases.

  • Monitoring database sizes and creating new databases when target sizes are approached.

  • Backing up and restoring databases.

Planning recommendations

Choose one of the following two approaches:

  • Establish target sizes for content databases with appropriate size-warning thresholds. Create new databases when size-warning thresholds are reached. By using this approach, site collections are automatically added to the available database or databases, based on target sizes alone.

  • Associate site collections with specific content databases. This approach enables you to put one or more site collections in a dedicated database that can be managed independently from other databases.

If you want to associate site collections to specific content databases, you can use the following methods:

  • Use Windows PowerShell to create a site collection in a new database.

  • Apply the following database capacity settings on the Manage Content Database Settings page on the SharePoint Central Administration Web site:

    • Number of sites before a Warning event is generated = 0

    • Maximum number of sites that can be created in this database = 1

  • Add a group of site collections to a dedicated database by following these steps:

    1. Add a content database for the Web application and ensure that the database status is set to Ready.

    2. Set the status of all other databases to Offline. While content databases are offline, new site collections cannot be created. However, existing site collections in offline databases are still available for both read and write operations.

    3. Create the site collections. They are automatically added to the online database.

    4. Set the status of all other databases back to Ready.

Site collections

A site collection is a set of Web sites that have the same owner and share administration settings. Each site collection contains a top-level Web site and can contain one or more subsites.

Capacity

The recommended guideline for acceptable performance is to implement fewer than 50,000 site collections per content database. However, performance can be affected at about 10,000 site collections. Scaling out by distributing site collections across multiple database servers provides additional storage capacity and throughput.

Sharing and isolation

Site collections introduce several sharing and isolation opportunities that affect permissions, navigation, and feature deployment.

The following items can be shared within a site collection and cannot be shared across site collections (except items that are stored in a file system, such as features in the _layouts directory):

  • Master pages

  • Page layouts

  • Images

  • Site templates

Additionally, permissions and navigation are isolated at the site collection level in the following ways:

  • Subsites in a site collection can inherit permissions from the top-level site.

  • Site collections cannot inherit permissions from other site collections.

  • There is no built-in navigation from one site collection to another.

It is important to be aware that, although permissions are enforced on individual sites, the sites are still vulnerable to cross-site scripting attacks from other sites within the domain.

Configurable items

The following table displays configurable items that contribute to isolation and sharing.

Item

Description

Site collection administrator

You can specify one user to be the primary site collection administrator and one user to be the secondary site collection administrator. In Central Administration, you cannot enter more than one account for these roles, nor can you enter a group account for these roles.

Site template

A site template determines which lists and features will be available on the new site. Many aspects of a site can be customized after creation. However, the site template cannot be changed after the site is created.

Quota template

You can apply a quota template to limit resources that are used for a site collection. The following templates are provided:

  • Personal Site (100 MB)

  • Team Sites (2,000 MB)

The following table displays configurable items in a site collection that contribute to isolation and sharing. These settings are available after you create the site collection by using the settings in the previous table.

Item | Description
Site collection administrators | You can specify multiple user accounts to be site collection administrators. You cannot add group accounts.
Permission level | Add user and group accounts to site collections and specify permission levels for each.

Administration

Site collection creation does not require DNS entries (unless you are creating host-named site collections) and can be easily automated or delegated to users. You can create site collections for team sites centrally, or you can let users create their own site collections by using Self-Service Site Management.

Using a dedicated database for a site collection provides the ability to perform backup and recovery at the site collection level.

Planning recommendations

Site collections bridge logical architecture and information architecture. When you design site collections, consider the following two design tasks:

  • Design consistent URLs across the organization.

  • Create logical divisions of content.

Unless you are using host-named site collections, each Web application must have a single root-level site collection. This provides a single URL path into the sites that reside in the Web application. This is also a requirement if you are implementing multiple zones within a Web application. For more information, see Host-named site collections in this article.

Many organizations plan to implement multiple site collections within a Web application for use by different teams or divisions within the organization. Common design goals include the following:

  • Maintain a separate and independent site collection for each team.

  • Create a unique URL for each team.

  • Isolate content between teams.

To satisfy these goals, you can use managed paths to incorporate multiple top-level site collections within a Web application. By defining managed paths, you can specify which paths in the URL namespace of a Web application are used for site collections. You can specify that one site collection or more than one site collection exists at a distinct path under the root site. Without managed paths, all sites created under the root site collection are part of the root site collection.

You can create the following two kinds of managed paths:

  • Explicit inclusion A site collection with the explicit URL that you assign. An explicit inclusion is applied to only one site collection. You can associate each of these site collections with a different content database if you want to manage growth and to provide the opportunity to back up and restore these sites separately. An example URL for a site collection created by using this method is http://fabrikam/hr. The limit on site collections created with an explicit inclusion is approximately 100 site collections within a Web application. However, 20 is a good operational maximum. If the organization requires more site collections, use a wildcard inclusion instead.

  • Wildcard inclusion A path that is added to the URL. This path indicates that all sites that are specified directly after the path name are unique site collections. This option is typically used to support Self-Service Site Management. Example URLs for site collections created by using this method are http://partnerweb/sites/project1 and http://partnerweb/sites/project2. In these examples, "http://partnerweb" represents the root-level site collection and "/sites" represents the wildcard inclusion.

Sites

A site consists of one or more related Web pages and other items (such as lists, libraries, and documents) that are hosted inside a site collection.

Capacity

The guideline for acceptable performance is to implement fewer than 250,000 sites per site collection. You can create a very large total number of Web sites by nesting the subsites. However, many nested subsites can greatly affect the time that is required to upgrade sites. A good operational target is 5,000 sites within a site collection.

Sharing and isolation

Sites include built-in navigation from one subsite to another within a site collection. There is no built-in navigation from one site collection to another.

As with site collections, separate sites are vulnerable to cross-site scripting attacks from other sites within the domain.

Configurable elements

From within each site, you can add user or group accounts to the Owners group for that site.

Administration

You can use various tools to back up and restore individual sites.

Host-named site collections

Host-named site collections are an option if you want to create multiple root-level site collections within a Web application. For example, administrators for hosting organizations use host-named site collections to create multiple domain-named sites.

There is no special mode, such as host header mode, that is required to create host-named site collections. You create host-named site collections by using Windows PowerShell. Additionally, by using Windows PowerShell, you can use managed paths with host-named site collections (New-SPManagedPath -HostHeader).

Host-named site collections give you more control over URLs. However, host-named site collections are available only through the Default zone. User accounts that are configured to authenticate through other zones cannot access host-named site collections.

In SharePoint 2010 Products, host-named site collections support off-box SSL termination. However, only the protocol scheme can be changed off-box (http:// or https://). The reverse proxy server cannot change the host name or the port number (except to switch from the default SSL port to the default HTTP port).

Capacity

You can create up to 100,000 host-named site collections within a single IIS Web site.

Sharing and isolation

The independent domain names that result from host-named site collections help prevent cross-site scripting attacks between two sites.

Administration

Administrative tasks for host-named site collections include the following:

  • Add host-named site collections by using Windows PowerShell.

  • Create a separate DNS entry for each host-named site collection.


Design sample: collaboration sites (SharePoint Foundation 2010)

Published: May 26, 2011

This article describes a practical implementation of logical architecture components to achieve a workable design. This article is intended to be used together with the following design samples:

  • Design sample: collaboration sites with classic authentication

  • Design sample: collaboration sites with claims-based authentication

To download either of these models, see SharePoint Foundation 2010 design samples: collaboration with classic authentication or with claims-based authentication (http://go.microsoft.com/fwlink/p/?LinkId=219157).

In this article:

  • About the design samples

  • Overall design goals

  • Server farms

  • Users, zones, and authentication

  • Administration sites

  • Services

  • Application pools

  • Web applications

  • Site collections

  • Content databases

  • Zones and URLs

  • Zone policies

The design samples show a generic corporate deployment of SharePoint Foundation 2010. The design samples apply almost all of the logical architecture components and show how these are incorporated into the overall design. The two samples show the same services and sites, but incorporate different authentication methods, as follows:

  • Classic authentication: This design sample represents a path for upgrading sites from Windows SharePoint Services 3.0 to SharePoint Foundation 2010. This sample incorporates classic authentication, in which Windows authentication methods are used to access sites. A different zone for each authentication method is used. Although Windows authentication is used for SharePoint sites, a firewall or gateway product can be configured to use forms-based authentication to collect Windows credentials that are forwarded to SharePoint Foundation 2010. Partner employee accounts are added to the corporate directory.

  • Claims-based authentication: This design sample incorporates the new claims-based authentication model. Multiple authentication providers and authentication types are implemented in a single zone. Claims-based authentication supports forms-based authentication, SAML token-based authentication, and Windows authentication. This design example adds partner companies by using SAML token-based authentication to authenticate directly against partner directories. There are several provider options for partner employee accounts.

Use the design sample that best represents your requirements for authentication.

This article describes the design goals for the samples and explains how these goals are achieved by using the logical architecture components illustrated in the samples.

About the design samples

The design samples show a deployment for a fictitious company named Fabrikam, Inc. If you are planning a solution with one or more of the kinds of collaboration sites represented in this model, you can use the model as a basis for your own design.

The model shows a generic deployment of SharePoint Foundation 2010 and represents the three following kinds of collaboration sites:

  • Team sites

  • Self-service sites

  • Partner collaboration sites

The design samples apply almost all the logical architecture components and show how these components are incorporated into the overall design. This article describes the design goals for the samples and explains how these goals are achieved by using the logical architecture components illustrated in the model.

Each of the different kinds of collaboration sites:

  • Hosts data with different data characteristics.

  • Is subject to a different usage profile.

  • Requires a different permissions management strategy.

Consequently, the design choices in the model are intended to optimize the performance and security for each application.

Team sites

Team sites represent highly structured and managed collaboration sites that have the following characteristics:

  • There is a smaller number of top-level site collections, and these site collections are intended to include a large amount of data (compared to self-service sites).

  • Top-level URLs are meaningful for each team.

  • More consideration is given to site hierarchies, taxonomies, and customizations.

  • Each team's content is in a separate database and can be managed separately.

Self-service sites

Self-service sites provide an alternative to highly managed team sites. You can enable users and teams to create their own site collections by using Self-Service Site Management. You turn on Self-Service Site Management in Central Administration. This method is best used when you want to enable groups or communities to create sites. This method also works well if you are hosting sites and want to let users create sites without waiting for a detailed process.

The characteristics of self-service sites are typically different from highly managed sites. Characteristics might include the following:

  • Large number of top-level site collections

  • Small amount of data per site collection

  • URLs that are automatically generated but typically not meaningful

There are several tradeoffs to be aware of when planning to implement self-service sites. The tradeoffs in the following list will affect how you manage self-service sites:

  • Instead of implementing a thoughtful taxonomy, sites are created at will without an organizing principle across sites. Because each new site is a site collection, templates and navigation cannot be shared across self-service sites.

  • Because each site collection provides search only for content on that site collection, there is no aggregation of search results across site collections.

  • Site collections can vary greatly in size and use.

  • Sites can be easily abandoned.

Managing self-service sites can include managing content storage based on the target size of content databases and regularly deleting sites that are no longer used.

For more information about how to implement Self-Service Site Management, see Turn on or turn off self-service site creation (SharePoint Foundation 2010).

Partner collaboration sites

The partner Web application hosts externally available sites for secure collaboration with partner companies and individual partners. This application is intended for employees to easily create sites for secure collaboration. Partners are not able to access other kinds of content hosted on the server farm. The design for zones and service applications addresses this goal. Additionally, individual site owners manage permissions for their sites, inviting only necessary participants to collaborate.

Overall design goals

The model shows a practical implementation of SharePoint Foundation 2010 features within several different kinds of collaboration applications (team sites, self-service sites, and partner sites). The design implementations for each site application are discussed in this article. The key design goals for the model include the following:

  • Create a framework for designing an environment that can grow. Design decisions for individual collaboration applications do not prevent the addition of other applications. For example, an initial deployment might include only collaborative team sites or only partner sites. By using a similar logical architecture design, you can add the other kinds of collaboration sites to the solution without affecting the design of the initial collaboration sites. In other words, the design does not incorporate design choices that limit the use of the environment.

  • Provide access for several classes of users without compromising the security of the content within the different collaboration applications. Users from different network zones (both internal and external) with different authentication providers can participate in collaboration. Also, users can only access the content they are intended to access. By following a similar logical architecture design, you create the opportunity to provide access to users in multiple locations and with different objectives. For example, your initial design might be intended only for internal employee access. However, by using a similar design you can enable access to remote employees, partner employees, or even customers.

  • Ensure that the design can be used in an extranet environment. You can make deliberate design choices to ensure that the server farms can be securely deployed in a perimeter network or within any of the extranet topologies.

The rest of this article discusses each logical component that appears in the model (from top to bottom) and discusses the design choices that are applied to the model. The purpose of this approach is to demonstrate the different ways in which logical architecture components can be configured based on the application.

Server farms

The model shows a five-server farm. However, the model could be implemented on any size farm, including a single server. The server farm in the model is composed of five servers in the following topology:

  • Two front-end Web servers

  • One application server for the search server or service applications (optional)

  • Two database servers, either clustered or mirrored

The model shows the logical architecture of SharePoint Foundation 2010 by showing the following:

  • All sites are mirrored across front-end Web servers.

  • The Central Administration Web site is installed on an application server to protect it from direct user access.

In reality, the number of server computers and the topology of the server farm are not important to the logical architecture, except to increase capacity and performance, as needed. The logical architecture can be designed independent of the server-farm topology. The performance and capacity planning process will help you size the server farm to meet performance and capacity goals. For more information, see Performance and capacity test results and recommendations (SharePoint Foundation 2010).

Users, zones, and authentication

When you create a Web application in SharePoint Foundation 2010, you must select either claims-based authentication or classic-mode authentication. The authentication mode determines how accounts are used internally by SharePoint Foundation 2010. The following table summarizes the two approaches.

Type of authentication

Description

Recommendations

Classic-mode authentication

User accounts are treated by SharePoint Foundation 2010 as traditional Active Directory Domain Services (AD DS) accounts. The following authentication protocols are supported: Kerberos, NTLM, Basic, Digest, and Anonymous.

Forms-based authentication is not supported.

Only one authentication method can be configured on a zone.

Classic mode is recommended for upgrading environments from Windows SharePoint Services 3.0, in which forms-based authentication is not a requirement.

If you are upgrading, you do not need to run user migration if you select classic-mode authentication.

Claims-based authentication

User accounts are treated by SharePoint Foundation 2010 as claims identities. Windows accounts are automatically converted to claims identities. This mode additionally supports forms-based authentication and authentication against a trusted identity provider.

Multiple authentication types can be configured on a single zone.

Claims-based authentication is recommended for new SharePoint Foundation 2010 deployments. It is required for upgrading Windows SharePoint Services 3.0 solutions that require forms-based authentication.

The two design samples that are discussed in this article represent these two options. The following sections specifically discuss how authentication is incorporated into the two design samples.

Classic-mode authentication design sample

The design sample that uses classic-mode authentication incorporates the traditional one-zone-per-type of authentication approach that was used in the previous release. For this reason, this example provides a path for upgrading from Windows SharePoint Services 3.0 to SharePoint Foundation 2010.

The one issue is that forms-based authentication is not supported in classic mode. When you use classic-mode authentication, all authenticated accounts must reside within Active Directory Domain Services (AD DS). The recommendation for users who are accessing sites remotely is to use forms-based authentication on the firewall or gateway product to collect Windows credentials that are forwarded to the SharePoint farm.

The classic-mode sample shows three classes of users, each assigned to a different zone. Within each Web application, you can create as many as five zones that use one of the available zone names: Default, Intranet, Internet, Custom, or Extranet.

The following table shows the zones, users, and authentication types prescribed by the classic-mode design sample.

Zone | Users | Authentication
Intranet | Internal employees | NTLM or Kerberos
Default | Remote employees | NTLM or Kerberos (using forms-based authentication on the firewall or gateway product to collect and forward the credentials)
Extranet | Individual partners | NTLM or Kerberos (using forms-based authentication on the firewall or gateway product to collect and forward the credentials)

Claims-based authentication design sample

Claims-based authentication is recommended for all new deployments of SharePoint Foundation 2010 and is required for upgrading Windows SharePoint Services 3.0 solutions that require forms-based authentication. In addition to providing the standard Windows authentication methods, claims-based authentication enables you to authenticate against other directories, such as Windows Live ID, Active Directory Federation Services (AD FS) 2.0, or a third-party identity provider that supports SAML tokens and the WS Federation protocol.

In the claims-based authentication design sample, claims-based authentication is used on the collaborative farm. Claims-based authentication enables multiple kinds of authentication to be used in the same zone. The design sample uses the Default zone for all authentication types. The following table shows the zones, users, and authentication types that are prescribed by the sample for the collaborative farm.

Zone | Users | Authentication
Intranet | Internal and remote employees | AD DS (or LDAP store with forms-based authentication or SAML authentication)
Default | Individual partners | Windows Live with SAML authentication; or SQL Server database with forms-based authentication
Extranet | Partner companies | Trusted partner identity provider with SAML authentication

In the design sample, team sites and self-service sites are only available to employees, whether they are inside or outside the network. The design sample implements only one URL (which uses SSL) for each of these sites that can be used both internally and externally. AD DS accounts are used. If needed, LDAP can be used with either forms-based authentication or SAML, which requires additional configuration.

In the design sample, the partner Web application represents an extranet site that is available to partner employees and partner companies. Using claims-based authentication in this scenario requires that trust be configured to use one or more external secure token services (STS). This can be provided by using either of the following approaches:

  • The SharePoint farm can be configured to trust an external STS, such as the STS associated with Windows Live (for authenticating individual partners) or the STS that resides in a partner company (for authenticating directly against the partner directory).

  • The STS inside the corporate environment can be configured to trust an external STS. This relationship must be established explicitly by administrators in the two organizations. In this scenario, the SharePoint farm is configured to trust only the STS that resides in its own corporate environment. This internal STS verifies the token it receives from the external STS and then issues a token that allows the partner user to access the SharePoint farm. This is the recommended approach.

An alternative to implementing a claims-based environment to authenticate partners is to use forms-based authentication and manage these accounts by using a separate store, such as a database.

For more information about how to implement a claims-based authentication environment, see the following white paper: Claims-based Identity for Windows: An Introduction to Active Directory Federation Services 2.0, Windows CardSpace 2.0, and Windows Identity Foundation (http://go.microsoft.com/fwlink/p/?LinkId=196776).

Zones

When you design zones, several key decisions are important to the success of the deployment. These decisions include design and configuration decisions for the following zones:

  • The Default zone

  • Zones for external access

The following sections describe the decisions that are incorporate into the model.

Configuration requirements of the Default zone

The zone that involves the greatest consideration is the Default zone. SharePoint Foundation 2010 includes the following requirements on how the Default zone is configured:

  • When a user request cannot be associated with a zone, the authentication and policies of the Default zone are applied. Consequently, the Default zone must be the most secure zone.

  • Administrative e-mail is sent with links to the Default zone. These include e-mail messages to owners of sites that are approaching quota limits. Consequently, users who receive these kinds of messages and alerts must be able to access links through the Default zone. This is especially important for site owners.

  • Host-named site collections are available only through the Default zone. All users who are intended to access host-named site collections must have access through the Default zone.

Configuring zones for an extranet environment

In an extranet environment, the design of zones is very important for the following two reasons:

  • User requests can be initiated from several different networks. In the model, users initiate requests from the internal network, the Internet, and partner companies.

  • Users can participate in collaboration across multiple Web applications. For example, internal and remote employees can potentially contribute to and administer content across all of the Web applications: team sites, self-service sites, and partner Web.

In an extranet environment, ensure that the following design principles are followed:

  • Configure zones across multiple Web applications to mirror one another. The configuration of authentication and the intended users should be the same. However, the policies associated with zones can differ across Web applications. For example, ensure that the Intranet zone is used for the same employees across all Web applications. In other words, do not configure the Intranet zone for internal employees in one Web application and remote employees in another.

  • Configure alternate access mappings appropriately and accurately for each zone and each resource.

In the design samples, the Default zone for each Web application is configured identically. Additionally, other zones are configured identically across all Web applications, as needed.

Alternate access mappings are automatically created when you create the zone. However, if you use a proxy server or gateway product to make sites available from the Internet, you will have to add an additional alternate access mapping entry for each zone. This ensures that URLs that are returned to users outside the internal network are available to users according to the context of their zone.

If zones across Web applications do not mirror one another, and links to external resources are incorrect, the risks include the following:

  • Server names, Domain Name System (DNS) names, and IP addresses can potentially be exposed outside the internal network.

  • Users might be unable to access Web sites and other resources.

Administration sites

In the model, the Central Administration site is hosted on the application server. This protects the site from direct user contact. If a performance bottleneck or security compromise affects the availability of the front-end Web servers, the Central Administration site remains available. Additionally, the Central Administration site is hosted inside a dedicated application pool and Web application.

The load-balanced URLs for the administration sites are not articulated in the model or in this article. Recommendations include the following:

  • If port numbers are used in administrative URLs, use non-standard ports. By default, port numbers are included in URLs. Although port numbers are typically not used in customer-facing URLs, using port numbers for administration sites can increase security by limiting access to these sites to non-standard ports.

  • Create separate DNS entries for administration sites.

Services

The services architecture that is illustrated in the model only represents the two service applications that are included with SharePoint Foundation 2010. The two service groupings (represented by using a red box and a blue-dashed box) are not required in the given example because they include the same two service applications. However, consider which service applications are necessary for partner Web sites and configure the two service groups accordingly. Options to consider include the following:

  • Consider whether a separate instance of the Business Data Connectivity service application is necessary for partner Web sites. If it is necessary, consider deploying this service application for partner sites in partitioned mode. This ensures that partners do not have access to data across partner sites.

  • Third-party companies can develop service applications for SharePoint Foundation 2010. If you are using these, decide whether they are appropriate to use across all sites.

Application pools

Separate Internet Information Services (IIS)application pools are typically implemented to achieve process isolation between sites. Application pools enable multiple sites to run on the same server computer but still have their own worker processes and identity. This mitigates any possible security issues on one site that enable an attacker to inject code onto the server to attack other sites.

Practically speaking, consider using a dedicated application pool for the following scenarios:

  • To separate authenticated content from anonymous content.

  • To isolate sites that are primarily for collaboration with external partners or customers. This isolates external accounts to sites within one application pool.

  • To isolate sites where users have more freedom to create and administer sites and to collaborate on content.

The model uses application pools in the following way:

  • The administration site is hosted in a dedicated application pool. This is required by SharePoint Foundation 2010.

  • All service applications are deployed to a single application pool. Unless there is a compelling reason to deploy service applications to different application pools, this is the recommended configuration. Using one application pool for all service applications optimizes performance and reduces the number of application pools to manage.

  • The internal collaboration sites (team sites and self-service sites) are hosted in one application pool.

  • The partner Web application is hosted in a dedicated application pool.

Web applications

A Web application is an IIS Web site that is created and used by SharePoint 2010 Products. Each Web application is represented by a different Web site in IIS. You assign each Web application a unique domain name, which helps prevent cross-site scripting attacks.

Generally speaking, use dedicated Web applications to do the following:

  • Separate anonymous content from authenticated content.

  • Isolate users. In the model, partner Web is hosted in a dedicated Web application and application pool to ensure that partners do not have access to the internal collaboration content.

  • Enforce permissions. A dedicated Web application provides the opportunity to enforce permissions by using the Policy for Web Application page in Central Administration. For example, you can create a policy on the internal collaboration sites to explicitly deny access to partner accounts. Policies for a Web application are enforced regardless of permissions configured on individual sites or documents within the Web application.

  • Optimize performance. Sites achieve better performance if they are put in Web applications together with other applications of similar data characteristics. For example, the data characteristics of self-service sites include many small sites. In contrast, team sites typically consist of a smaller number of very large sites. By putting these two kinds of sites in separate Web applications, the resulting databases are composed of data with similar characteristics, which optimizes database performance. In the model, team sites and self-service sites do not have unique data isolation requirements; they share the same application pool. Nonetheless, team sites and self-service sites are put in separate Web applications to optimize performance.

  • Optimize manageability. Because creating separate Web applications results in separate sites and databases, you can implement different site limits (Recycle Bin, expiration, and size) and negotiate different service-level agreements. For example, you might allow more time to restore self-service sites if this is not the most important kind of content within your organization. This enables you to restore more important content before you restore these sites. In the model, self-service sites are put in a separate Web application to enable administrators to more aggressively manage growth compared to other applications.

Site collections

Site collections bridge logical architecture and information architecture. The design goals for site collections in the model are to satisfy requirements for URL design and to create logical divisions of content.

To satisfy the requirements for URL design, each Web application includes a single root-level site collection. Managed paths are used to incorporate a second tier of top-level site collections. For more information about URL requirements and using managed paths, see Zones and URLs later in this article. Beyond the second tier of site collections, each site is a subsite.

The following figure shows the site hierarchy of team sites.

Given the requirement for a root-level site collection, the design decisions revolve around the second tier of site collections. The model incorporates choices based on the nature of the application.

Self-service sites

In the model, the self-service sites incorporate a top-level site that has the URL of http://sites. A managed path is incorporated (by using wildcard inclusion), which allows an indefinite number of user-created sites. All sites under the managed path are independent site collections that inherit the site template that was used to create the top-level site.

For more information about self-service sites, see Plan process for creating sites (SharePoint Foundation 2010).

Team sites

When you design site collections within a team site application, we recommend that you create a finite number of site collections for the organization based on the way the organization operates. In this approach, site collections are created by a SharePoint Foundation 2010 administrator. After the site collection is created, teams can create sites within the site collection based on their needs.

This approach provides the opportunity to implement a thoughtful taxonomy that provides structure to the way team sites are managed and grow. There is also more opportunity to share templates and navigation between projects and teams that share a site collection. The challenge for information architects is to create a second tier of site collections that makes sense for the organization. The following table lists suggestions for different kinds of organizations.

Type of organization Suggested site collection taxonomies

Product development

  • Create a site collection for each product under development. Allow contributing teams to create sites within the site collection.

  • For each long-term development project, create a site collection for each large team that contributes to the product. For example, create one site collection for each of the following teams: designers, engineers, and content developers.

Research

  • Create a site collection for each long-term research project.

  • Create a site collection for each category of research projects.

Higher education institution

  • Create a site collection for each academic department.

State legislative office

  • Create a site collection for each political party. Government officials who share a party affiliation can share templates and navigation.

  • Create a site collection for each committee. Or, create one site collection for all committees.

Corporate law office

  • Create a site collection for each corporate client.

Manufacturing

  • Create a site collection for each line of products.

Partner Web

Partner Web is intended to be used for collaboration with external partners on projects that have finite scopes or finite durations. By design, sites within the partner Web application are not intended to be related. The requirements for partner Web include ensuring the following:

  • Project owners can easily create sites for partner collaboration.

  • Partners and other contributors have access to only the projects they work on.

  • Permissions are managed by site owners.

  • Search results from one project do not expose content from other projects.

  • Administrators can easily discover sites that are no longer used and delete these sites.

To satisfy these requirements, the model incorporates a site collection for each project, which provides the following benefits:

  • Individual site collections provide the appropriate level of isolation between projects.

  • Self-service site creation can be implemented.

Content databases

You can use two approaches to incorporate content databases into the design. The model incorporates both of the following approaches:

  • Establish target sizes for content databases with appropriate size warning thresholds. Create a new database when size warning thresholds are reached. With this approach, site collections are automatically added to the available database or databases, based on size targets alone.

  • Associate site collections to specific content databases. This approach enables you to put one or more site collections in a dedicated database that can be managed independently from the rest.

If you decide to associate site collections to specific content databases, you can use the following methods to do this:

  • Use Windows PowerShell to create a site collection in a specific database.

  • Dedicate a database to a single site collection by applying the following database capacity settings:

    • Number of sites before a Warning event is generated = 1

    • Maximum number of sites that can be created in this database = 1

  • Add a group of site collections to a dedicated database by following these steps:

    1. Within the Web application, create the database and set the database status to Ready.

    2. Set the status of all other databases to Offline. While content databases are offline, new site collections cannot be created. However, existing site collections in offline databases are still available for both read and write operations.

    3. Create the site collections. They are automatically added to the database.

    4. Set the status of all other databases back to Ready.

Team sites

The design sample incorporates a dedicated database for each team site collection. This approach enables you to manage each team's database independently for backup, restore, and migration. Also, when a project is complete, you can easily archive the database associated with the project. The design sample provides database settings based on a 30-GB limit for site collections. Choose a limit that is appropriate for team sites in your organization.

Self-service sites

For self-service sites, the model achieves scale efficiency by managing databases to the maximum target size. The following settings are configured to achieve this goal:

  • Limit site storage to a maximum of This setting, which you configure on the Quota Templates page in Central Administration, limits the size of a site.

  • Second stage Recycle Bin This setting, which you configure on the Web Application General Settings page, determines how much additional space is allocated to the second-stage Recycle Bin.

  • Maximum number of sites that can be created in this database This setting is configured when you create a database. Calculate the total allowable size of sites by using the numbers that you specify for the previous two values. Then, based on the size goal for each database, determine how many sites will fit into the database.

The design sample provides the following example size settings based on a target database size of 175 gigabytes (GB) and a target My Site size of 1 GB:

  • Site size limits per site = 1 GB

  • Target size of database = 175 GB

  • Reserved for second-stage Recycle Bin = 15 percent

  • Maximum number of sites = 180

  • Site level warning = 150

When the site level warning is reached, create a new database. After you create the new database, new self-service sites are added alternately to the new database and the existing database until the maximum number of sites for one of the databases is reached.

Partner Web

Similar to self-service sites, partner Web achieves scale efficiency by managing databases to the maximum target size.

Because partner Web is hosted in a dedicated Web application, you can create size limits that are appropriate to the kinds of sites that are created. The design sample provides the following example size settings:

  • Target size of database = 200 GB

  • Storage quota per site = 5 GB

  • Maximum number of sites = 40

Zones and URLs

The model shows how to coordinate URLs across multiple applications within a corporate deployment.

Design goals

The following goals influence design decisions for URLs:

  • URL conventions do not limit the zones through which content can be accessed.

  • The standard HTTP and HTTPS ports (80 and 443) can be used across all applications in the design sample.

  • Port numbers are not included in URLs. In practice, port numbers are typically not used in production environments.

Design principles

To achieve these design goals, the following design principles are applied:

  • Host-named site collections are not used. Note that host-named site collections differ from IIS host headers. Host-named site collections do not work with the alternate access mappings feature. The alternate access mappings feature is required to access the same content through multiple domain URLs. Consequently, when host-named sites are used, these sites are available only through the Default zone.

  • Each application incorporates a single root site collection. This is required for using alternate access mappings. If multiple root site collections are required within a Web application and you expect to use only the Default zone for user access, host-named site collections are a good option.

  • For the applications that include multiple high-level site collections, in which each site collection represents a top-level team or project (for example, team sites), the model incorporates managed paths. Managed paths provide more control over URLs for these kinds of sites.

Design tradeoffs

Meeting the design goals results in some tradeoffs, including the following:

  • URLs are longer.

  • Host-named site collections are not used.

Designing load-balanced URLs

When you create a Web application, you must select a load-balanced URL to assign to the application. Additionally, you must create a load-balanced URL for each zone that you create within a Web application. The load-balanced URL includes the protocol, scheme, host name, and port. The load-balanced URL must be unique across all Web applications and zones. Consequently, each application and each zone within each application requires a unique URL across the design sample.

Internal collaboration sites

The two kinds of internal collaboration sites each require a unique URL. In the design sample, the target audience for the intranet content is internal employees and remote employees. In the claims-based authentication design sample, employees use the same URLs for each of these applications regardless of whether they are on site or remote. While this approach adds a layer of security to the design (all traffic is SSL), this approach requires either routing internal traffic through the firewall or gateway product together with remote traffic or setting up a split DNS environment to resolve internal requests within the internal network.

For the classic authentication design sample, the URLs are different for internal and remote employees. The following table shows the URLs for internal and remote employees to access each application in the classic authentication design sample.

Application | Internal employee URL | Remote employee URL
Team sites | http://teams | https://teams.fabrikam.com
Self-service sites | http://sites | https://sites.fabrikam.com

Partner Web

In the design sample, the partner Web site is accessed by internal employees, remote employees, and partner employees. In the claims-based authentication design sample, each user enters the same URL, regardless of the authentication method. In the classic authentication design sample, each different kind of user enters a different URL. Although both remote employees and partner employees access the partner Web site externally by using SSL (HTTPS), each group requires a different URL to apply the benefits of using separate zones. Those benefits are different authentication methods and different zone policies. The following table shows the URLs that internal employees, remote employees, and partners use to access the partner Web site, as shown in the classic authentication design sample.

Zone | URL
Internal employee URL | http://partnerweb
Remote employee URL | https://remotepartnerweb.fabrikam.com
Partner URL | https://partnerweb.fabrikam.com

Using explicit and wildcard inclusions for URL paths

By defining managed paths, you can specify which paths in the URL namespace of a Web application are used for site collections. You can specify that one site collection or more than one site collection exists at a distinct path under the root site. Without managed paths, all sites that are created under the root site collection are part of the root site collection.

You can create the following two kinds of managed paths:

  • Explicit inclusion A site collection with the explicit URL that you assign. An explicit inclusion is applied to only one site collection. You can create many explicit inclusions under a root site collection. An example URL for a site collection that is created by using this method is http://team/team1. There is a performance impact for every explicit path that is added. Therefore, we recommend that you to limit the number of site collections that are created with an explicit inclusion to about 20.

  • Wildcard inclusion A path that is added to the URL. This path indicates that all sites that are specified directly after the path name are unique site collections. This option is typically used for applications that support self-site creation. An example URL for a site collection that is created by using this method is http://sites/selfservice/site1.

The design sample incorporates the use of both types as described in the following sections.

Explicit inclusions

The design sample does not currently incorporate the use of explicit inclusions. The following table provides an example set of URLs for a Fabrikam intranet site that uses classic authentication in which URLs are different for internal access and remote access of employees.

Internal employee (Intranet zone) | Remote employee (Default zone)
http://fabrikam | https://intranet.fabrikam.com
http://fabrikam/hr | https://intranet.fabrikam.com/hr
http://fabrikam/facilities | https://intranet.fabrikam.com/facilities
http://fabrikam/purchasing | https://intranet.fabrikam.com/purchasing

In this example, the root site collection, http://fabrikam, represents the default home page for the intranet. This site can host content for users. The next site in the path, for example, http://fabrikam/hr and http://fabrikam/facilities, is the explicit inclusion.

Wildcard inclusions: team sites, self-service sites, and partner Web

Team sites, self-service sites, and the partner Web application incorporate the use of a wildcard inclusion. Wildcard inclusions are ideal for applications that enable users to create their own site collections and for Web applications that include many site collections. A wildcard inclusion indicates that the next item after the wildcard is a root site of a site collection.

Team sites

Within the team sites application, wildcard inclusion is used for each team site collection. Good governance practices recommend that you keep the number of top-level team sites within a manageable number. Also, the taxonomy for team sites should be logical for the way your business operates.

In the classic authentication design sample, the use of wildcard inclusions results in the URLs shown in the following table.

Internal employee (Intranet zone) | Remote employee (Default zone)
http://teams/sites/team1 | https://teams.fabrikam.com/sites/team1
http://teams/sites/team2 | https://teams.fabrikam.com/sites/team2
http://teams/sites/team3 | https://teams.fabrikam.com/sites/team3

In this example, the root site collection, http://team, does not necessarily host content for users.

Self-service sites

In the model, self-service sites include a wildcard inclusion named /selfservice (http://sites/selfservice).

This results in URLs in the format listed in the following table.

Internal (Intranet zone) | Remote employee (Default zone)
http://sites/selfservice/site1 | https://sites.fabrikam.com/selfservice/site1
http://sites/selfservice/site2 | https://sites.fabrikam.com/selfservice/site2
http://sites/selfservice/site3 | https://sites.fabrikam.com/selfservice/site3

Partner Web

Partner Web is designed to enable employees to easily create sites for collaboration with external partners. To support this goal, self-service site creation is enabled.

In the classic authentication design sample, the partner Web application includes a wildcard inclusion named /sites (http://partnerweb/sites). This results in URLs in the format shown in the following table.

Internal employee (Intranet zone) | Remote employee (Default zone)
http://partnerweb/sites/project1 | https://remotepartnerweb.fabrikam.com/sites/project1
http://partnerweb/sites/project2 | https://remotepartnerweb.fabrikam.com/sites/project2
http://partnerweb/sites/project3 | https://remotepartnerweb.fabrikam.com/sites/project3

Partner contributors can access partner Web sites by using the URLs listed in the following table.

Partner (Extranet zone)

https://partnerweb.fabrikam.com/sites/project1

https://partnerweb.fabrikam.com/sites/project2

https://partnerweb.fabrikam.com/sites/project3

Coordinating URLs with AAM and DNS

Configure alternate access mappings for each site URL in the farm. This ensures that Web requests are mapped to the correct site, especially in environments that use load balancing or reverse proxy technologies.

The following table lists the necessary information for creating or modifying alternate access mappings based on the classic authentication version of the logical architecture design sample.

Site | Host header | Zone | Port | AAM public URL
Team sites | teams | Intranet | 80 | http://teams
 | teams.fabrikam.com | Default | 443 | https://teams.fabrikam.com
Self-service sites | sites | Intranet | 80 | http://sites
 | sites.fabrikam.com | Default | 443 | https://sites.fabrikam.com
Partner Web | partnerweb | Intranet | 80 | http://partnerweb
 | remotepartnerweb.fabrikam.com | Default | 443 | https://remotepartnerweb.fabrikam.com
 | partnerweb.fabrikam.com | Extranet | 443 | https://partnerweb.fabrikam.com

Single-name URLs, such as http://teams, can be configured for intranet access. These URLs are resolved by the client by appending the client's DNS suffix, such as fabrikam.com, and then issuing a DNS lookup for the name with the suffix. For example, when a client computer in the fabrikam.com domain requests http://teams, the computer sends a request to DNS for http://teams.fabrikam.com.

DNS must be configured to use an A record for each fully qualified domain name (FQDN). The A record points to the load-balanced IP address for the Web servers that are hosting a site. In a typical production deployment, servers are configured to use statically assigned IP addresses, in addition to statically assigned A records in DNS.

After receiving the virtual IP address of the load balancer, the client browser establishes communication with a front-end Web server in the farm, then sends an HTTP request with the original single-name URL, http://teams. IIS and SharePoint 2010 Products recognize this as a request for the Intranet zone, based on the settings configured in alternate access mappings (see the previous table). If the user had instead requested https://teams.fabrikam.com, the process would be the same except that IISand SharePoint 2010 Products would receive this FQDN instead, and therefore recognize this request for the Default zone.

In environments that have multiple domains, enter CNAME records for DNS in the domains that the sites do not reside in. For example, if the Fabrikam network environment includes a second domain named europe.fabrikam.com, CNAME records are entered for these sites in the Europe domain. For the team sites intranet site (http://teams), a CNAME record named teams is added to the europe.fabrikam.com domain that points to teams.fabrikam.com. Then, when a client's DNS suffix is appended to DNS lookup requests, a request for http://teams from the Europe domain will issue a DNS lookup of teams.europe.fabrikam.com, and be directed by the CNAME record to teams.fabrikam.com.

Note:

There is a known issue with some Kerberos clients and resolving CNAME records. For more information, see Kerberos configuration known issues (SharePoint Server 2010).

Zone policies

You can create a policy for a Web application to enforce permissions at the Web application level. A policy can be defined for the Web application generally or only for a specific zone. A policy enforces permissions on all content within the Web application or the zone. Policy permissions override all other security settings that are configured for sites and content. You can configure policy based on users or user groups, but not SharePoint groups.

Policies are not used in the claims-based authentication design sample for the collaborative farm where multiple kinds of authentication are enabled on a single zone. Policies are implemented in the classic authentication design sample and on the published farm of the claims-based authentication design sample where Windows authentication is prescribed. On the published farm, the use of policies adds an additional layer of security between anonymous users and users who have access to manage sites.

The design sample provides one example: denying partner accounts access to internal collaboration sites.


Services architecture planning (SharePoint Foundation 2010)

This article describes the services architecture for sharing service applications and provides example architectures for Microsoft SharePoint Foundation 2010.

In this article:

  • About service applications

  • Services infrastructure and design principles

  • Deploy service applications across farms

The following poster-size models are also available to use with this article. You can modify the diagrams within the models to represent your own organization plans.

Services in Microsoft SharePoint 2010 Products

Services in SharePoint - 1 of 2

  • Visio (http://go.microsoft.com/fwlink/p/?LinkID=167090)

  • PDF (http://go.microsoft.com/fwlink/p/?LinkID=167092)

  • XPS (http://go.microsoft.com/fwlink/p/?LinkID=167091)

Cross-farm services in SharePoint 2010 Products

Services in SharePoint - 2 of 2

  • Visio(http://go.microsoft.com/fwlink/p/?LinkID=167093)

  • PDF (http://go.microsoft.com/fwlink/p/?LinkID=167095)

  • XPS (http://go.microsoft.com/fwlink/p/?LinkID=167094)

About service applications

SharePoint Foundation 2010 includes a set of services that can be shared across Web applications. These services are called service applications. Some service applications can be shared across farms. Sharing service applications across Web applications and farms greatly reduces the resources required to provide these services across multiple sites.

The following service applications are provided with SharePoint Foundation 2010:

  • Business Data Connectivity service — Gives access to line-of-business data systems.

  • Usage and Health Data Collection service — Collects farm wide usage and health data, and provides the ability to view various usage and health reports.

  • Microsoft SharePoint Foundation Subscription Settings Service — Provides multi-tenant functionality for service applications. Tracks subscription IDs and settings for services that are deployed in partitioned mode. Deployed through Windows PowerShell only.

Some service applications are provided by other Microsoft products, including Microsoft Office Web Apps. Office Web Apps are online companions to Microsoft Word, Excel, PowerPoint, and OneNote, enabling people to access and do light editing or sharing of Office documents from virtually anywhere. Business customers licensed for Microsoft Office 2010 through a Volume Licensing program can run Office Web Apps on-premises on a server running SharePoint Foundation 2010.

The services infrastructure is extensible, and third party companies can create additional service applications that can be used with SharePoint Foundation 2010.

Service applications are different from the services that are started and stopped on specific servers and listed on the Services on Server page in the SharePoint Central Administration Web site. Some of the services listed on this page are associated with service applications, but service applications represent specific instances of services that can be configured and shared in specific ways.

Services infrastructure and design principles

SharePoint 2010 Products improves the services infrastructure that was introduced in the previous version. In SharePoint 2010 Products, the infrastructure for hosting services moves into SharePoint Foundation 2010 and the configuration of service offerings is much more flexible. Individual services can be configured independently, and third-party companies can add services to the platform.

Deploy services

You deploy service applications within a farm by using one of the following methods:

  • Selecting services when you run the SharePoint Products Configuration Wizard.

  • Adding services one by one on the Manage Service Applications page in the Central Administration site.

  • Using Windows PowerShell.

More granular configuration of services

The service application infrastructure gives you more control over which services are deployed and how service applications are shared:

  1. You can deploy only the service applications that are needed to a farm.

  2. Web applications can be configured to use only the service applications that are needed, instead of all the services that have been deployed.

  3. You can deploy multiple instances of the same service in a farm and assign unique names to the resulting service applications.

  4. You can share service applications across multiple Web applications within the same farm.

You can choose the service applications for a Web application when you create the Web application. You can also modify the service applications that are associated with a Web application later.

Service application groups

By default, all service applications are included in a default group, unless you change this setting for a service application when it is created. You can add and remove service applications from the default group at any time.

The following diagram shows a typical deployment with all service applications contained in the default service group.

Service applications in the default group

When you create a Web application, you can select the default group or you can create a custom group of service applications. You create a custom group of service applications by selecting only the service applications that you want the Web application to use.

Custom groups that are created in Central Administration are not reusable across multiple Web applications. Each time that you select custom when you create a Web application, you are selecting service applications only for the Web application that you are creating.

Logical architecture

Service applications are deployed within a single Internet Information Services (IIS) Web site. This is the default behavior and cannot be changed. However, you can customize the configuration of service application groups and the association of Web applications to service application groups.

The following diagram shows the logical architecture for a more complex deployment.

A more complex service application deployment

Notice the following characteristics of the farm in the diagram:

  • All service applications are contained within the same IIS Web site.

  • There are two groups of service applications: the default group and a custom group. Not all service applications have to be included in the default group. In the diagram, an additional instance of the Business Data Connectivity service is added to the farm but not included in the default group. It is used only by one Web application.

  • Web applications connect either to the default group or to a custom group of service applications. In the diagram, there is one custom group.

Service applications can be deployed to different application pools to achieve process isolation. However, if you want to optimize the performance of your farm, we recommend that you deploy service applications to one application pool.

To achieve physical isolation for a service application, choose or create a different application pool for the service application.

Connections for service applications

When you create a service application, a connection for the service application is created at the same time. A connection is a virtual entity that connects Web applications to service applications. In Windows PowerShell, these connections are called proxies. "Proxy" appears at the end of the type description for connections on the Manage Service Applications page in Central Administration.

Service application administration

Service applications are managed directly in Central Administration rather than through a separate administration site. If needed, service applications can be monitored and managed remotely. Service applications can also be managed and scripted by using Windows PowerShell.

Deploy service applications across farms

Some service applications can be shared across server farms. Other service applications can be shared only within a single server farm. In SharePoint Foundation 2010, the only in-box service application that can be shared across farms is Business Data Connectivity service.

Design guidance

The following guidance applies to sharing service applications across farms:

  • Any farm can consume a cross-farm service application as long as it is licensed to use the service application. For example, any SharePoint Foundation 2010 farm can consume the Business Data Connectivity service application from another farm. This includes consuming this service application from a SharePoint Server 2010 farm. However, a SharePoint Foundation 2010 farm cannot consume a cross-farm service that it is not licensed to use, such as the User Profile service application, from a SharePoint Server 2010 farm.

  • Each Web application can be configured to use service applications from different farms. For example, you can share the Business Data Connectivity service application across Web applications in several server farms. Web applications can consume this service application from one or more different farms while consuming service applications from the local farm.

  • Service applications that support sharing across farms can be run in a central farm and consumed from other farms. In large environments, computing-intensive service applications can be run in a central farm to minimize administrative overhead and to scale out easily and efficiently as requirements grow.

For more information about how to design architectures for cross-farm services, including example architectures, see the Cross-farm services in SharePoint 2010 Products model that is referenced at the beginning of this article.

Deploy cross-farm services

Sharing service applications across farms requires the following steps:

  1. Configure trusted farms.

    Ensure that farms have exchanged certificates to trust one another. Export the certificate to a file and back up the file before you connect to cross-farm services.

  2. Publish the service application.

    To share a service application across farms, you must first publish the service.

  3. Connect to a cross-farm service application.

    To consume a service that is published by a remote farm, create a connection to the service. This process prompts you to enter the URL of a published service, which is displayed during the publishing process. A connection on the local farm is created to connect to the service application on the remote farm.

For the Business Data Connectivity service application administration features to work from the consuming farm, the domain of the publishing farm must trust the domain of the consuming farm.

For more information about how to configure services for use across farms, see Share service applications across farms (SharePoint Foundation 2010).


Plan for host-named site collections (SharePoint Foundation 2010)

Published: June 17, 2010

In this article:

  • About host-named site collections

  • About host headers

  • Create a host-named site collection

  • Programmatically create a host-named site collection

  • Use managed paths with host-named site collections

  • Expose host-named sites over HTTP or SSL

  • Configure SSL for host-named site collections

  • Use host-named site collections with off-box SSL termination

Microsoft SharePoint Foundation 2010 supports both path-based and host-named site collections. The primary difference between path-based and host-named site collections is that all path-based site collections in a Web application share the same host name (DNS name), and each host-named site collection in a Web application is assigned a unique DNS name.

Path-based site collections provide a corporate hosting solution with all site collections sharing the same host name of the Web application. In a path-based deployment, you can have a single site collection at the root of the Web application and additional site collections under managed paths within the Web application.

Host-named site collections provide a scalable Web hosting solution with each site collection assigned to a unique DNS name. In a Web hosting deployment, each host-named site collection has its own vanity host name URL, such as http://customer1.contoso.com, http://customer2.contoso.com, or http://www.customer3.com.

SharePoint Foundation 2010 provides two significant improvements to host-named site collections: the ability to use managed paths with host-named site collections, and the ability to use off-box SSL termination with host-named site collections.

About host-named site collections

Web hosters provide customers with Web server space to host their own Web sites. In a path-based SharePoint Foundation 2010 environment, these sites would typically be assigned to http://www.contoso.com/sites/customer1, http://www.contoso.com/sites/customer2, and so on. However, Web hosting customers typically want to have their Web sites available at a vanity domain name, such as http://customer1.contoso.com, http://customer2.contoso.com, and so on.

One way to support this customer request is to provide each customer with their own Web application and assign the customer's unique DNS name to the Web application. However, SharePoint Foundation 2010 Web applications do not scale as well as SharePoint Foundation 2010 site collections. SharePoint Foundation 2010 supports host-named site collections as an alternative to creating individual Web applications for each customer. Host-named site collections can scale to thousands of site collections because they can all exist within a single Web application and still offer vanity naming capability.

Because host-named site collections have a single URL, they do not support alternate access mappings and are always considered to be in the Default zone. If you need to support site collections responding to multiple host-name URLs, consider using path-based site collections with alternate access mappings instead of host-named site collections.There are several additional configuration options to consider when provisioning a new SharePoint Foundation 2010 site. Specifying the appropriate site template during site creation will determine which preconfigured Web parts and other user interface elements are available on the new site. In a hosting scenario, you will probably want to select either a team site template (value of "STS#0" when creating the site) or a blank site with no Web parts or prebuilt lists (value of "STS#1"). Also consider specifying site quotas on each newly provisioned site collection.

About host headers

Host headers refer to the portion of the HTTP protocol that tells the Web server the DNS name of the site that the client is connecting to. You can apply host headers at two different levels in SharePoint Foundation 2010:

  • The Web application (IIS Web site) level

  • The site collection level

It's important to understand the distinction between these two levels. Host headers at the IIS Web site level are only intended for path-based site collections. Host headers at the site collection level are only intended for host-named site collections. In most cases, applying a host header binding at the IIS Web site level makes it impossible to access host-named site collections through the IIS Web site. This is because IIS will not respond to requests for host names that differ from the host header binding.

Path-based site collections and host-named site collections can co-exist in the same Web application and can exist in multiple Web applications. To ensure that both types of site collections are accessible to users, do not put host header bindings on the IIS Web site assigned to the Default zone of your Web application, if you have host-named site collections in that Web application. You can apply host header bindings to the IIS Web sites in the other zones of your Web application. This enables you to use the Default zone with host-named site collections while allowing you to use alternate access mapping functionality in the other zones for path-based site collections.

You can manually modify host header bindings on the IIS Web site from the IIS Manager, but this is not recommended. Any changes you make using the IIS Manager will not be recorded in SharePoint Foundation 2010. If SharePoint Foundation 2010 tries to provision an IIS Web site on another computer in the farm for the same Web application and zone, the original host header binding is used instead of the modified binding. If you want to modify an existing binding for an IIS Web site, remove the Web application from the zone and then re-extend the Web application into the zone with the binding you want to use.

Create a host-named site collection

You must use Windows PowerShell to create a host-named site collection. You cannot use the SharePoint Foundation 2010 Central Administration Web application to create a host-named site collection, but you can use Central Administration to manage the site collection after you have created it.

You can create a host-named site collection by using the Windows PowerShell New-SPSite cmdlet with the -HostHeaderWebApplication parameter, as shown in the following example:

  1. To create a host-named site collection using Windows PowerShell, 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:

Copy Code
New-SPSite http://host.header.site.url -OwnerAlias DOMAIN\username -
HostHeaderWebApplication http://servername

This creates a host-named site collection with the URL http://host.header.site.url in the SharePoint Foundation 2010 Web application with the URL http://servername.

Programmatically create a host-named site collection

In addition to using the Windows PowerShell to create host-named sites, you can use the SharePoint Foundation 2010 object model. The following code sample creates the host-named site collection with the URL http://host.header.site.url in the SharePoint Foundation 2010 Web application with the URL http://servername:

Copy Code
SPWebApplication webApp = SPWebApplication.Lookup(new
Uri("http://www.contoso.com"));
SPSiteCollection sites = webApp.Sites;
SPSite Site = null;
Site = sites.Add("http://hoster.contoso.com", "Site_Title",
"Site_Description", 1033, "STS#0", "contoso\owner",
"Owner_Display_Name", "Owner_Email", "contoso\secondaryowner,
"Secondary_Owner_Display_Name", "Secondary_Owner_Email", true);

SharePoint Foundation 2010 ships with a set of Web services for various user and administrative tasks. One of these administrative tasks is creating a new site collection. The CreateSite Web service method does not support the creation of host-named site collections. A workaround for this issue is to write a Web service that wraps the API sample code.

Use managed paths with host-named site collections

SharePoint Foundation 2010 adds support for managed paths with host-named site collections. Hosters can provide multiple site collections to the same customer with each site collection sharing the customer's unique host name but differentiated by the URL path after the host name.

Managed paths for host-named site collections are different from managed paths for path-based site collections. Managed paths for host-named site collections do not apply to path-based site collections; nor do managed paths for path-based site collections apply to host-named site collections. Managed paths created for host-named site collections are available to all host-named site collections within the farm regardless of which Web application the host-named site collection is in. You must create a root host-named site collection for a host name before you can create a managed path host-named site collection for that host name.

You can create a managed path for use with host-named site collections by using the Windows PowerShell New-SPManagedPath cmdlet with the -HostHeader parameter, as shown in the following example:

Copy Code
New-SPManagedPath pathname -HostHeader

A host-named site collection created at a managed path is shown in the following example:

Copy Code
New-SPSite http://host.header.site.url/pathname/sitename -OwnerAlias DOMAIN\username -HostHeaderWebApplication http://servername

Expose host-named sites over HTTP or SSL

Host-named site collections will use the same protocol scheme as the public URL in the Default zone of their Web application. If you wish to provide the host-named site collections in your Web application over HTTP, ensure that the public URL in the Default zone of your Web application is an HTTP-based URL. If you wish to provide host-named site collections in your Web application over SSL, ensure that the public URL in the Default zone of your Web application is an HTTPS-based URL.

Unlike an earlier version, SharePoint Foundation 2010 does not support a host-named site collection using both HTTP- and SSL-based URLs simultaneously. If some host-named site collections need to be available over HTTP while other host-named site collections need to be available over SSL, separate the host-named site collections into two different Web applications dedicated for that type of access. In this scenario, HTTP host-named site collections should be in a Web application dedicated for HTTP access and SSL host-named site collections should be in a Web application dedicated for SSL access.

Configure SSL for host-named site collections

In hosting scenarios, hosters can configure a single Web application with SSL and then create multiple host-named site collections within that Web application. To browse to a site over SSL, a server certificate has to be installed and assigned to the IIS Web site. Each host-named site collection in a Web application will share the single server certificate assigned to the IIS Web site.

Hosters need to acquire a wildcard certificate or subject alternate name certificate and then use a host-named site collection URL policy that matches that certificate. For example, if a hoster acquires a *.contoso.com wildcard certificate, the hoster has to generate host-named site collection URLs such as https://site1.contoso.com, https://site2.contoso.com, and so on, to enable these sites to pass browser SSL validation. However, if customers require unique second-level domain names for their sites, the hoster has to create multiple Web applications rather than multiple host-named site collections.

To configure SSL for host-named site collections, enable SSL when creating the Web application. This will create an IIS Web site with an SSL binding instead of an HTTP binding. After the Web application is created, open IIS Manager and assign a certificate to that SSL binding. You can then create site collections in that Web application.

Use host-named site collections with off-box SSL termination

Because SharePoint Foundation 2010 uses the public URL in the Default zone of the Web application to determine whether host-named site collections will be rendered as HTTP or SSL, you can now use host-named site collections with off-box SSL termination. There are 3 requirements to use SSL termination with host-named site collections:

  • The public URL in the Default zone of the Web application must be an HTTPS-based URL.

  • The SSL terminator or reverse proxy must preserve the original HTTP host header from the client.

  • If the client SSL request is sent to the default SSL port (443), then the SSL terminator or reverse proxy must forward the decrypted HTTP request to the front-end Web server on the default HTTP port (80). If the client SSL request is sent to a non-default SSL port, then the SSL terminator or reverse proxy must forward the decrypted HTTP request to the front-end Web server on the same non-default port.

To use host-named site collections with off-box SSL termination, configure your Web application as you normally would for SSL termination and ensure that it meets the requirements described above. In this scenario, SharePoint Foundation 2010 will render links of its host-named site collections in that Web application using HTTPS instead of HTTP.


Plan authentication (SharePoint Foundation 2010)

This section describes how to plan for authentication.

In this section:

  • Plan authentication methods (SharePoint Foundation 2010)

  • People Picker and claims provider planning (SharePoint Foundation 2010)

  • Plan for Kerberos authentication (SharePoint Foundation 2010)

  • Forefront UAG integration (SharePoint Foundation 2010)

  • Claims-based authentication with Microsoft UAG 2010 (SharePoint Foundation 2010)

  • Plan for claims-based authentication or classic-mode authentication (SharePoint Foundation 2010)


Plan authentication methods (SharePoint Foundation 2010)
See Also

This article describes the authentication methods and authentication modes that are supported by Microsoft SharePoint Foundation 2010.

Authentication is the process of validating a user's identity. An authentication method is a specific exchange of account credentials and other attributes that assert that identity. After a user's identity is validated, the authorization process determines which sites, content, and other features the user can access.

In this article:

  • Supported authentication methods

  • Authentication modes — classic or claims-based

  • Implementing Windows authentication methods

  • Implementing forms-based authentication

  • Implementing SAML token-based authentication

  • Choosing authentication for LDAP environments

  • Planning zones for Web applications

  • Architecture for SAML token-based providers

Supported authentication methods

SharePoint Foundation 2010 supports authentication methods that were included in previous versions and also introduces support for token-based authentication that is based on Security Assertion Markup Language (SAML). The following table lists the supported authentication methods.

Method category Authentication methods Notes

Windows authentication

  • NTLM

  • Kerberos

  • Anonymous

  • Basic

  • Digest

Forms-based authentication

  • Lightweight Directory Access Protocol (LDAP)

  • Microsoft SQL Server database or other database

  • Custom or third-party membership and role providers

SAML token-based authentication (new with SharePoint Foundation 2010)

  • Active Directory Federation Services (AD FS) 2.0

  • Third-party identity provider

  • Lightweight Directory Access Protocol (LDAP)

Supported only with SAML 1.1 that uses the WS-Federation Passive Requestor Profile (WS-F PRP).

Client certificate authentication is possible through integration with AD FS 2.0.

For additional information, see Configure Client Certificate Authentication (SharePoint Foundation 2010).

Authentication modes — classic or claims-based

Authentication modes determine how client computers authenticate with SharePoint Foundation 2010 resources. SharePoint Foundation 2010 introduces support for a claims-based authentication mode. You can use any of the supported authentication methods with the claims-based authentication mode or you can use classic mode authentication, which supports only Windows authentication.

User identity in Active Directory Domain Services (AD DS) is based on a user account. For successful authentication, the user provides the account name and proof of knowledge of the password. To determine access to resources, applications might need to query AD DS for account attributes and other information, such as group membership or role on the network. While this works well for Windows environments, it does not scale to third-party authentication protocols and directory providers and multi-vendor environments that support Internet, partner, or cloud-based computing models.

Claims-based identity is based on the user obtaining a security token that is digitally signed by a commonly trusted identity provider and contains a set of claims. Each claim represents a specific item of data about the user such as his or her name, group memberships, and role on the network. Claims-based authentication is user authentication that utilizes claims-based identity technologies and infrastructure. Applications that support claims-based authentication obtain the security token from the user and use the information within the claims to determine access to resources. No separate query to a directory service like AD DS is needed.

Claims-based authentication in Windows is built on Windows Identity Foundation (WIF), which is a set of .NET Framework classes that is used to implement claims-based identity. Claims-based authentication relies on standards such as WS-Federation, WS-Trust, and protocols such as SAML.

For more information about claims-based authentication, see the following resources:

  • Claims-based Identity for Windows (white paper) (http://go.microsoft.com/fwlink/p/?LinkId=198942)

  • Windows Identity Foundation home page (http://go.microsoft.com/fwlink/p/?LinkId=198943)

For new deployments of SharePoint Foundation 2010, we recommend claims-based authentication. If you use claims-based authentication, all supported authentication methods are available for your Web applications.

When you create a Web application, you select one of the two authentication modes to use with the Web application, either claims-based or classic-mode.

Claims-based or classic mode authentication

If you select Classic-Mode Authentication, you can configure the Web application to use Windows authentication and the user accounts are treated by SharePoint Foundation 2010 as Active Directory Domain Services (AD DS) accounts.

If you select Claims-Based Authentication, SharePoint Foundation 2010 automatically changes all user accounts to claims identities, resulting in a claims token for each user. The claims token contains the claims pertaining to the user. Windows accounts are converted into Windows claims. Forms-based membership users are transformed into forms-based authentication claims. Claims that are included in SAML-based tokens can be used by SharePoint Foundation 2010. Additionally, SharePoint developers and administrators can augment user tokens with additional claims. For example, Windows user accounts and forms-based accounts can be augmented with additional claims that are used by SharePoint Foundation 2010.

A SharePoint Foundation 2010 farm can include a mix of Web applications that use both modes. Some services do not differentiate between user accounts that are traditional Windows accounts and Windows claims accounts. For example, a user who belongs to sites that are configured to use a mix of authentication modes may receive search results that include results from all the sites that the user has access to, regardless of the authentication mode that is configured for Web applications. In this scenario, the user is not interpreted as multiple user accounts. This is because services and service applications use claims identities for inter-farm communication regardless of the mode that is selected for Web applications and users. However, users who belong to more than one user repository that is recognized by SharePoint Foundation Web applications are treated as separate user accounts, depending on which identity they use to log in.

You do not have to be a claims architect to use claims-based authentication in SharePoint Foundation 2010. However, implementing SAML token-based authentication requires coordination with administrators of your claims-based environment, as described in the "Implementing SAML token-based authentication" section of this article.

Implementing Windows authentication methods

The process of implementing Windows authentication methods is similar for both authentication modes (classic or claims-based). Choosing claims-based authentication for a Web application does not increase the complexity of implementing Windows authentication methods. This section summarizes the process for each method.

Kerberos and NTLM

Both the Kerberos protocol and NTLM are Integrated Windows authentication methods, which let users seamlessly authenticate without being prompted for credentials. Users who access SharePoint sites from Internet Explorer will authenticate by using the credentials the Internet Explorer process is running under. By default, these credentials are the credentials that the user used to log on to the computer. Services or applications that access SharePoint Server resources using Integrated Windows authentication methods will attempt to authenticate by using the credentials of the running thread, which by default is the identity of the process.

NTLM is the simplest form of Windows authentication to implement. Simply select this option when you are creating a Web application.

Kerberos is a secure protocol that supports ticketing authentication. Use of the Kerberos protocol requires additional configuration of the environment. To enable Kerberos authentication, the client and server computers must have a trusted connection to the domain Key Distribution Center (KDC). Configuring the Kerberos protocol involves setting up service principal names (SPNs) in AD DS before you install SharePoint Foundation 2010.

The following steps summarize the process of configuring Kerberos authentication:

  1. Configure Kerberos authentication for SQL Server communications by creating SPNs in AD DS for the SQL Server service account.

  2. Create SPNs for Web applications that will use Kerberos authentication.

  3. Install the SharePoint Foundation 2010 farm.

  4. Configure specific services within the farm to use specific accounts.

  5. Create the Web applications that will use Kerberos authentication.

For more information, see Plan for Kerberos authentication (SharePoint Foundation 2010).

Additionally, for claims-authentication Web applications, the Claims to Windows Token Service (C2WTS) must be configured for constrained delegation. Constrained delegation is required to convert claims to Windows tokens.

Note:

The C2WTS does not support crossing domain boundaries between forests.

Kerberos authentication allows delegation of client credentials to access back-end data systems, which requires additional configuration depending on the scenario. The following table provides examples.

Scenario | Additional configuration required
Delegating a client's identity to a back-end server. Displaying RSS feeds to authenticated content. | Configure Kerberos constrained delegation for computers and service accounts.
Identity delegation for Microsoft SQL Server Reporting Services (SSRS) | Configure SPNs for SQL Server Reporting Services accounts. Configure delegation for SQL Server Reporting Services.
Identity delegation for Excel Services in SharePoint | Configure constrained delegation for servers that run Excel Services. Configure constrained delegation for the Excel Services service account.

For more information about how to configure Kerberos authentication, including configuration steps for common scenarios, see Configuring Kerberos Authentication for Microsoft SharePoint 2010 Products and Technologies (white paper) (http://go.microsoft.com/fwlink/p/?LinkID=197178).

Digest and Basic

Implementing Digest and Basic authentication requires configuring these authentication methods directly in Internet Information Services (IIS).

Implementing forms-based authentication

Forms-based authentication is an identity management system that is based on ASP.NET membership and role provider authentication. In SharePoint Foundation 2010, forms-based authentication is available only when you use claims-based authentication.

Forms-based authentication can be used against credentials stored in AD DS, in a database such as a SQL Server database, or in an LDAP data store such as Novell eDirectory, Novell Directory Services (NDS), or Sun ONE. Forms-based authentication enables user authentication based on validation of credential input from a logon form. Unauthenticated requests are redirected to a logon page, where the user must provide valid credentials and submit the form. If the request can be authenticated, the system issues a cookie that contains a key for reestablishing the identity for subsequent requests.

To use forms-based authentication to authenticate users against an identity management system that is not based on Windows or that is external, you must register the membership provider and role manager in the Web.config file. Registering the role manager is a new requirement for SharePoint Foundation 2010. In the previous version, this was optional. SharePoint Foundation 2010 uses the standard ASP.NET role manager interface to gather group information about the current user. Each ASP.NET role is treated as a domain group by the authorization process in SharePoint Foundation 2010. You register role managers in the Web.config file the same way that you register membership providers for authentication.

If you want to manage membership users or roles from the SharePoint Central Administration Web site, you must register the membership provider and the role manager in the Web.config file for the Central Administration Web site. You must also register the membership provider and the role manager in the Web.config file for the Web application that hosts the content.

For detailed steps to configure forms-based authentication, see Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010)

For additional information about forms-based authentication, see the following resources:

  • MSDN blog article: Claims-based authentication "Cheat Sheet" Part 1 (http://go.microsoft.com/fwlink/p/?LinkId=198944)

  • MSDN article: Forms Authentication in SharePoint Products and Technologies (Part 2): Membership and Role Provider Samples (http://go.microsoft.com/fwlink/p/?LinkId=198945)

For information about features that do not work with forms-based authentication or features that require additional configuration in order to work with forms-based authentication, see Plan for claims-based authentication or classic-mode authentication (SharePoint Foundation 2010).

Implementing SAML token-based authentication

SAML token-based authentication requires coordination with administrators of a claims-based environment, whether it is your own internal environment or a partner environment. AD FS 2.0 is an example of a claims-based environment.

A claims-based environment includes an identity provider security token service (IP-STS). The IP-STS issues SAML tokens on behalf of users who are included in the associated user directory. Tokens can include any number of claims about a user, such as a user name and groups the user belongs to.

SharePoint Foundation 2010 takes advantage of claims that are included in tokens provided by an IP-STS to authorize users. In claims environments, an application that accepts SAML tokens is known as a relying party STS (RP-STS). A relying party application receives the SAML token and uses the claims inside to decide whether to grant the client access to the requested resource. In SharePoint Foundation 2010, each Web application that is configured to use a SAML provider is added to the IP-STS server as a separate RP-STS entry. A SharePoint farm can include multiple RP-STS entries.

Implementing SAML token-based authentication with SharePoint Foundation 2010 involves the following processes that require planning in advance:

  1. Export the token-signing certificate from the IP-STS. This certificate is known as the ImportTrustCertificate. Copy the certificate to a server in the SharePoint Foundation 2010 farm.

  2. Define the claim that will be used as the unique identifier of the user. This is known as the identity claim. Many examples of this process use the user e-mail name as the user identifier. Coordinate with the administrator of the IP-STS to determine the correct identifier because only the owner of the IP-STS knows the value in the token that will always be unique per user. Identifying the unique identifier for the user is part of the claims-mapping process. Claims mappings are created by using Windows PowerShell.

  3. Define additional claims mappings. Define the additional claims from the incoming token that will be used by the SharePoint Foundation 2010 farm. User roles are an example of a claim that can be used to assign permissions to resources in the SharePoint Foundation 2010 farm. All claims from an incoming token that do not have a mapping will be discarded.

  4. Create a new authentication provider by using Windows PowerShell to import the token-signing certificate. This process creates the SPTrustedIdentityTokenIssuer. During this process, you specify the identity claim and additional claims that you have mapped. You must also create and specify a realm that is associated with the first SharePoint Web applications that you are configuring for SAML token-based authentication. After the SPTrustedIdentityTokenIssuer is created, you can create and add more realms for additional SharePoint Web applications. This is how you configure multiple Web applications to use the same SPTrustedIdentityTokenIssuer.

  5. For each realm that is added to the SPTrustedIdentityTokenIssuer, you must create an RP-STS entry on the IP-STS. This can be done before the SharePoint Web application is created. Regardless, you must plan the URL before you create the Web applications.

  6. Create a new SharePoint Web application and configure it to use the newly created authentication provider. The authentication provider will appear as an option in Central Administration when claims mode is selected for the Web application.

You can configure multiple SAML token-based authentication providers. However, you can only use a token-signing certificate once in a farm. All providers that are configured will appear as options in Central Administration. Claims from different trusted STS environments will not conflict.

If you are implementing SAML token-based authentication with a partner company and your own environment includes an IP-STS, we recommend that you work with the administrator of your internal claims environment to establish a trust relationship from your internal IP-STS to the partner STS. This approach does not require adding an additional authentication provider to your SharePoint Foundation 2010 farm. It also allows your claims administrators to manage the whole claims environment.

Important:

You need to set network load balancing to single affinity when using claims-based authentication. If you use SAML token-based authentication with AD FS on a SharePoint Foundation 2010 farm that has multiple Web servers in a load-balanced configuration, there will be an effect on the performance and functionality of client Web-page views. When AD FS provides the authentication token to the client, that token is submitted to SharePoint Foundation 2010 for each permission-restricted page element. If the load-balanced solution is not using affinity, each secured element is authenticated to more than one SharePoint Foundation 2010 server, which will result in rejection of the token. After the token is rejected, SharePoint Foundation 2010 redirects the client to authenticate again back to the AD FS server. After this occurs, an AD FS server will reject multiple requests that are made in a short time period. This behavior is by design, to protect against a denial of service attack. If performance is adversely affected or pages do not load completely, set network load balancing to single affinity. This isolates the requests for SAML tokens to a single Web server.

For information about configuring Active Directory Federation Services (AD FS) 2.0 in SharePoint Foundation 2010, see How to configure AD FS v 2.0 in SharePoint Foundation 2010.

Note:

When a Web application is configured to use SAML token-based authentication, the SPTrustedClaimProvider class does not provide search functionality to the People Picker control. Any text entered in the People Picker control will automatically be displayed as if it had been resolved, regardless of whether it is a valid user, group, or claim. If your SharePoint Foundation solution will use SAML token-based authentication, you should plan to create a custom claims provider that implements custom search and name resolution.

For more information, see Custom claims providers for People Picker (SharePoint Foundation 2010).

For detailed steps to configure SAML token-based authentication, see Configure authentication using a SAML security token (SharePoint Foundation 2010).

For additional information about SAML token-based authentication, see the following resources:

  • MSDN blog article: Claims-based authentication "Cheat Sheet" Part 2 (http://go.microsoft.com/fwlink/p/?LinkId=198946)

  • TechNet blog article: Planning Considerations for Claims Based Authentication in SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=198947)

  • TechNet blog article: Creating both an Identity and Role Claim for a SharePoint 2010 Claims Auth Application (http://go.microsoft.com/fwlink/p/?LinkId=198948)

  • TechNet blog article: How to Create Multiple Claims Auth Web Apps in a Single SharePoint 2010 Farm (http://go.microsoft.com/fwlink/p/?LinkId=198949)

For information about features that do not work with SAML security tokens or features that require additional configuration in order to work with SAML security tokens, see Plan for claims-based authentication or classic-mode authentication (SharePoint Foundation 2010).

Choosing authentication for LDAP environments

LDAP environments can be implemented by using either forms-based authentication or SAML token-based authentication. We recommend that you use forms-based authentication because it is less complex. However, if the environment supports WS-Federation 1.1 and SAML Token 1.1, then SAML is recommended.

Planning zones for Web applications

Zones represent different logical paths for gaining access to the same sites in a Web application. Each Web application can include as many as five zones. When a Web application is created, the default zone is created. Additional zones are created by extending the Web application and selecting one of the remaining zone names: intranet, extranet, Internet, or custom.

In previous versions of SharePoint Foundation, zones are used to implement different types of authentication for users coming from different networks or authentication providers. In the current version, claims authentication allows multiple types of authentication to be implemented on the same zone.

Your plan for zones will depend on which of the following authentication modes you select for a Web application:

  • Classic mode — Similar to previous versions, only one type of authentication can be implemented per zone. However, in SharePoint Foundation 2010, only Windows authentication can be implemented when classic mode is selected. Consequently, multiple zones can be used only to implement multiple types of Windows authentication, or to implement the same type of Windows authentication against different Active Directory stores.

  • Claims-based authentication — Multiple authentication providers can be implemented on a single zone. Multiple zones can also be used.

Implementing more than one type of authentication on a single zone

If you are using claims authentication and implementing more than one authentication method, we recommend that you implement multiple authentication methods on the default zone. This results in the same URL for all users.

When you are implementing multiple authentication methods on the same zone, the following restrictions apply:

  • Only one instance of forms-based authentication can be implemented on a zone.

  • Central Administration allows you to use both an Integrated Windows method and Basic at the same time. Otherwise, more than one type of Windows authentication cannot be implemented on a zone.

If multiple SAML token-based authentication providers are configured for a farm, these will all appear as options when you create a Web application or a new zone. Multiple SAML providers can be configured on the same zone.

The following diagram illustrates multiple types of authentication implemented on the default zone for a partner collaboration site.

Multiple types of authentication on a zone

In the diagram, users from different directory stores access the partner Web site by using the same URL. A dashed box surrounding partner companies shows the relationship between the user directory and the authentication type that is configured in the default zone. For more information about this design example, see Design sample: Corporate deployment (SharePoint Server 2010).

Planning for crawling content

The crawl component requires access to content using NTLM. At least one zone must be configured to use NTLM authentication. If NTLM authentication is not configured on the default zone, the crawl component can use a different zone that is configured to use NTLM authentication.

Implementing more than one zone

If you plan to implement more than one zone for Web applications, use the following guidelines:

  • Use the default zone to implement your most secure authentication settings. If a request cannot be associated with a specific zone, the authentication settings and other security policies of the default zone are applied. The default zone is the zone that is created when you initially create a Web application. Typically, the most secure authentication settings are designed for end-user access. Consequently, end users are likely to access the default zone.

  • Use the minimum number of zones that are required to provide access to users. Each zone is associated with a new IIS site and domain for accessing the Web application. Only add new access points when these are required.

  • Ensure that at least one zone is configured to use NTLM authentication for the crawl component. Do not create a dedicated zone for the index component unless it is necessary.

The following diagram illustrates multiple zones that are implemented to accommodate different authentication types for a partner collaboration site.

One zone for each authentication type

In the diagram, the default zone is used for remote employees. Each zone has a different URL associated with it. Employees use a different zone depending on whether they are working in the office or are working remotely. For more information about this design example, see Design sample: Corporate deployment (SharePoint Server 2010).

Architecture for SAML token-based providers

The architecture for implementing SAML token-based providers includes the following components:

SharePoint security token service This service creates the SAML tokens that are used by the farm. The service is automatically created and started on all servers in a server farm. The service is used for inter-farm communication because all inter-farm communication uses claims authentication. This service is also used for authentication methods that are implemented for Web applications that use claims authentication, including Windows authentication, forms-based authentication, and SAML token-based authentication. You must configure the security token service during the deployment process.

For more information, see Configure the security token service (SharePoint Foundation 2010).

Token-signing certificate (ImportTrustCertificate) This is the certificate that is exported from an IP-STS. The certificate is copied to one server in the farm. Once you use this certificate to create an SPTrustedIdentityTokenIssuer, you cannot use it again to create another one. If you want to use the certificate to create a different SPTrustedIdentityTokenIssuer, you must delete the existing one first. Before you delete an existing one, you must disassociate it from any Web applications that may be using it.

Identity claim The identity claim is the claim from a SAML token that is the unique identifier of the user. Only the owner of the IP-STS knows which value in the token will always be unique for each user. The identity claim is created as a regular claims mapping during the process of mapping all desired claims. The claim that serves as the identity claim is declared when the SPTrustedIdentityTokenIssuer is created.

Other claims These claims consist of additional claims from a SAML ticket that describe users. These can include user roles, user groups, or other kinds of claims such as age. All claims mappings are created as objects that are replicated across the servers in a SharePoint Foundation farm.

Realm In the SharePoint claims architecture, the URI or URL that is associated with a SharePoint Web application that is configured to use a SAML token-based provider represents a realm. When you create a SAML-based authentication provider on the farm, you specify the realms, or Web application URLs, that you want the IP-STS to recognize, one at a time. The first realm is specified when you create the SPTrustedIdentityTokenIssuer. Additional realms can be added after the SPTrustedIdentityTokenIssuer is created. Realms are specified by using syntax similar to the following: $realm = "urn:sharepoint:mysites". After you add the realm to the SPTrustedIdentityTokenIssuer, you must create an RP-STS trust with the realm on the IP-STS server. This process involves specifying the URL for the Web application.

SPTrustedIdentityTokenIssuer This is the object that is created on the SharePoint farm that includes the values necessary to communicate with and receive tokens from the IP-STS. When you create the SPTrustedIdentityTokenIssuer, you specify which token-signing certificate to use, the first realm, the claim that represents the identity claim, and any additional claims. You can only associate a token-signing certificate from an STS with one SPTrustedIdentityTokenIssuer. However, after you create the SPTrustedIdentityTokenIssuer, you can add more realms for additional Web applications. After a realm is added to the SPTrustedIdentityTokenIssuer, it must also be added to the IP-STS as a relying party. The SPTrustedIdentityTokenIssuer object is replicated across servers in the SharePoint Foundation farm.

Relying party security token service (RP-STS) In SharePoint Foundation 2010, each Web application that is configured to use a SAML provider is added to the IP-STS server as an RP-STS entry. A SharePoint Foundation farm can include multiple RP-STS entries.

Identity provider security token service (IP-STS) This is the secure token service in the claims environment that issues SAML tokens on behalf of users who are included in the associated user directory.

The following diagram illustrates the SharePoint 2010 Products claims architecture.

SharePoint claims authentication components

The SPTrustedIdentityTokenIssuer object is created by using several parameters. The following diagram illustrates the key parameters.

As the diagram illustrates, an SPTrustedIdentityTokenIssuer can include only one identity claim, one SignInURL parameter, and one Wreply parameter. However, it can include multiple realms and multiple claims mappings. The SignInURL parameter specifies the URL to redirect a user request to in order to authenticate to the IP-STS. Some IP-STS servers require the Wreply parameter, which is set to either true or false and is false by default. Only use the Wreply parameter if it is required by the IP-STS.

See Also

Other Resources

Resource Center: Security and Authentication for SharePoint Foundation 2010


People Picker and claims provider planning (SharePoint Foundation 2010)
See Also

Published: February 3, 2011

People Picker is a Web control used to find and select users, groups, and claims to grant permission to items such as lists, libraries, or sites in Microsoft SharePoint Foundation 2010. When a Web application uses claims authentication mode, the People Picker control uses a claims provider to list, resolve, search, and determine the "friendly" display of users, groups, and claims. A claims provider in SharePoint Foundation 2010 issues claims, which SharePoint Foundation 2010 then packages into security tokens for users. Although People Picker is used by site, list, and library owners to assign permissions to sites and content in SharePoint Foundation 2010, its behavior is heavily dependent on how authentication has been configured for the whole Web application. It is important to plan for People Picker and claims providers when you plan authentication methods for your SharePoint Foundation 2010 solution.

The articles in this section are designed to help you understand and plan for using People Picker and custom claims providers in SharePoint Foundation 2010:

  • People Picker overview (SharePoint Foundation 2010)

    This article describes the People Picker control and how it works, its relationship to authentication and claims providers, and includes considerations for planning for People Picker.

  • Custom claims providers for People Picker (SharePoint Foundation 2010)

    This article describes the use and benefits of claims providers, their architecture, special considerations for custom claims providers, and considerations for planning for them.

See Also

Concepts

Plan authentication (SharePoint Foundation 2010)
Configure People Picker (SharePoint Foundation 2010)


People Picker overview (SharePoint Foundation 2010)
See Also

Published: February 3, 2011

The People Picker control is used to find and select people, groups, and claims when a site, list, or library owner assigns permissions in Microsoft SharePoint Foundation 2010. This article describes the People Picker control and how it works, its relationship to authentication and claims providers, and how to plan for People Picker. For information about how to configure People Picker, see Configure People Picker (SharePoint Foundation 2010).

Before reading this article, you should understand the concepts described in Plan authentication methods (SharePoint Foundation 2010)and in The Role of Claims (http://go.microsoft.com/fwlink/p/?LinkID=208326). For additional information about claims-based authentication, see SharePoint Claims-Based Identity (http://go.microsoft.com/fwlink/p/?LinkID=196647).

In this article:

  • Uses and benefits

  • Architecture

  • About the People Picker control

  • People Picker and authentication

  • People Picker and claims providers

  • Configuring People Picker

  • Using People Picker with multiple forests or domains

  • Considerations for People Picker

Uses and benefits

The People Picker control is used to select users, groups, and claims to grant permission to items such as lists, libraries, and sites. For example, your site has a document library that you want to restrict to a certain list of users. When you use the library permissions page to give users permission levels for the library, you use the People Picker control either to type user names and verify that the user accounts are valid, or to search for a name or partial string and return a list of users, groups, or claims that match the value you entered. For more information about permissions, see Plan site permissions (SharePoint Foundation 2010).

Architecture

The People Picker control is a central component of SharePoint Foundation 2010. The control provides basic functionality for finding and selecting users, groups, and claims to assign permissions in a site. The exact sources of those users, groups, and claims depend on the authentication method used by the Web application that contains the site collection. For more information about authentication methods, see People Picker and authentication later in this article.

People Picker is configured at the zone level for a farm by using the Stsadm setproperty operation. By configuring the settings for the control, you can filter and restrict the results that are displayed when a user searches for a user, group, or claim. Those settings will apply to every site within a specific site collection. For more information about configuring People Picker, see Configure People Picker (SharePoint Foundation 2010).

Note:

There are no Windows PowerShell commands to configure People Picker.

When a Web application is configured to use claims-based authentication, People Picker uses claims providers to resolve and display users, groups, and claims in the Select People and Groups dialog box. The information that is displayed in the Select People and Groups dialog box depends on the claims provider used by the authentication method that was configured for the Web application. For more information about claims providers, see Custom claims providers for People Picker (SharePoint Foundation 2010).

About the People Picker control

The People Picker control consists of a text box and two buttons: the Check Names button and the Browse button. The following illustration shows an example of the People Picker control.

People Picker editor

The user types a user name, group name, or claim (such as an e-mail address) into the text box, and then clicks the Check Names button to resolve the search item exactly as it was entered. If People Picker is able to resolve the search item, the name is replaced with a resolved identity. If the search item cannot be resolved exactly as entered, People Picker performs a search. If no match is found, or if more than one match is found, a red underline is displayed under the search item and the following error message appears: No exact match found. Click the item(s) that did not resolve for more options. When the item is clicked, a pop-up menu displays a list of available users, groups, or claims that match the query, if applicable. The menu also contains a Remove button to remove the resolved user, group, or claim from the text box, and a More Names button, which opens the Select People and Groups dialog box.

If the user clicks the Browse button, the Select People and Groups dialog box is displayed. The user types a full or partial user name, group name, or claim into the text box, and then presses Enter. The results of the query are displayed in the dialog box. The claims providers that People Picker interacts with determine the query results and the way those results are displayed in the dialog box. The user selects a resolved identity, clicks Add, and then clicks OK. The selected user, group, or claim is then added to the text box in the People Picker control.

When a Web application is configured to use Windows authentication, you can limit the results that are displayed to users in the Select People and Groups dialog box by using the Stsadm setproperty operation to change the settings for the People Picker control. For example, you can configure People Picker to return only users, groups, and claims that belong to a certain Active Directory domain or are members of a specific site collection. For more information about configuring the People Picker control, see Configure People Picker (SharePoint Foundation 2010).

People Picker and authentication

People Picker relies on the authentication method used by the Web application that contains the site collection from which it is queried to determine what results to display to a user. If the Web application is configured to use Windows authentication in classic mode, SharePoint Foundation 2010 treats user accounts as Active Directory Domain Services (AD DS) accounts. If the Web application is configured to use claims-based authentication, you can specify whether to use Windows authentication, forms-based authentication (FBA), or Security Assertion Markup Language (SAML) token-based authentication. In claims mode, People Picker searches and resolves queries based on the claims provider that is specified for the authentication method used by the Web application and zone. The following sections describe People Picker behavior for both classic-mode authentication and claims-based authentication. For more information about zones and authentication, see Plan authentication methods (SharePoint Foundation 2010).

Classic-mode authentication

When Windows classic-mode authentication is used, the People Picker control queries Active Directory to retrieve a list of users, groups, or claims that match the search item typed in the text box. You can configure People Picker to query Active Directory by using Lightweight Directory Access Protocol (LDAP) queries, which enables you to apply custom Active Directory filters, limit the scope of search queries, and search across forests and domains.

By default, when the Browse button is clicked, the Select People and Groups dialog box displays the following fields:

  • Display Name

  • Title

  • Department

  • E-mail

  • Mobile Number

  • Account Name

The following image shows the Select People and Groups dialog box when Windows authentication is used in classic mode for the Web application.

Select People and Groups - Classic Mode

For more information about classic-mode authentication, see Plan authentication methods (SharePoint Foundation 2010). For information about how to create a Web application that uses classic-mode authentication, see Create a Web application that uses Windows-classic authentication (SharePoint Foundation 2010).

Claims-based authentication

When claims-based authentication is used, People Picker uses the claims provider that is specified for the authentication method used by the Web application and zone to retrieve a list of users, groups, or claims that match the search item typed in the text box. For more information about claims mode authentication and zones, see Plan authentication methods (SharePoint Foundation 2010).

By default, when the Browse button is clicked, the Select People and Groups dialog box displays a tree view on the left that lists the claims providers that People Picker will query. The right side of the dialog box is where query results are displayed. When claims-based authentication is used, the results are displayed in one of two views: Detailed View or List View. By default, Detailed View is displayed.

The following illustration shows the Select People and Groups dialog box when Windows authentication is used in claims mode for a Web application.

Select People and Groups - Win Claims Mode

In Detailed View, the query results are grouped by the sources where the query results were found. For example, if a search item is found in a SharePoint group and in Active Directory, the results are organized into a list of SharePoint groups followed by a list of Active Directory users and groups.

In List View, the query results are returned in a list that contains the following fields:

  • Display Name

  • E-mail Address

  • Title

  • Department

  • Presence

  • Work Phone

  • Location

You can write a custom claims provider to control what information is displayed and what results are returned in response to a query from the People Picker control. When a custom claims provider is registered on the server, you can also configure it for use in a specific Web application and zone. This means that a custom claims provider that is configured for only one zone will only be displayed in the Select People and Groups dialog box for Web sites in that zone. For more information about custom claims providers, see Custom claims providers for People Picker (SharePoint Foundation 2010).

Note:

In the Central Administration Web site, People Picker will return users, groups, and claims from all claims providers used in all Web applications in the farm, regardless of the Web application or zone in which the claims providers are configured.

By default, when you use SAML token-based authentication, all queries entered in the text box are automatically displayed as if they had been resolved, regardless of whether they are valid users or groups. If your SharePoint Foundation 2010 solution will use SAML token-based authentication, you should plan to create a custom claims provider that will implement custom search, name resolution, and list features. For more information about custom claims providers, see Custom claims providers for People Picker (SharePoint Foundation 2010).

For information about how to create a Web application that uses claims-mode authentication, see Create a Web application that uses Windows-claims authentication (SharePoint Foundation 2010). For information about configuring claims-based authentication for Web applications, see Configure claims authentication (SharePoint Foundation 2010).

People Picker and claims providers

A claims provider lists, resolves, searches, and determines the "friendly" display of users, groups, and claims in the People Picker when claims-based authentication is used. If your Web application uses claims-based authentication, you must decide whether to use one of the default claims providers or create a custom claims provider that will meet the business needs of your organization.

For more information about how claims providers are related to the People Picker control, see Custom claims providers for People Picker (SharePoint Foundation 2010).

Configuring People Picker

The information in this section applies only to Web applications that use Windows authentication in either classic mode or claims mode.

You can configure People Picker to filter query results and to restrict the directories that People Picker uses as a source of those results by using property names for the Stsadm setproperty operation. To see what property settings have been configured, use the Stsadm getproperty operation. For more information, see Peoplepicker: Stsadm properties (Office SharePoint Server 2007). The settings for People Picker are applied to each URL zone for a Web application.

Note:

There are no Windows PowerShell commands to configure People Picker.

The following table describes the properties that can be used to configure People Picker.

Property name | Description
Peoplepicker-activedirectorysearchtimeout | Configures the timeout when a query is issued to Active Directory. The default timeout value is 30 seconds. For more information, see Peoplepicker-activedirectorysearchtimeout.
Peoplepicker-distributionlistsearchdomains | Restricts the search of a distribution list to a specific subset of domains. For more information, see Peoplepicker-distributionlistsearchdomains.
Peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode | Specifies not to search Active Directory when the current port is using forms-based authentication. For more information, see Peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode.
Peoplepicker-onlysearchwithinsitecollection | Displays only users who are members of the site collection when the Select People and Groups dialog box is used. For more information, see Peoplepicker-onlysearchwithinsitecollection.
Peoplepicker-peopleeditoronlyresolvewithinsitecollection | Displays only users who are members of the current site collection when the Check Names button is clicked. For more information, see. Peoplepicker-peopleeditoronlyresolvewithinsitecollection: Stsadm property (SharePoint Foundation 2010).
Peoplepicker-searchadcustomfilter | Enables a farm administrator to specify a unique search query. For more information, see Peoplepicker-searchadcustomfilter.
Peoplepicker-searchadcustomquery | Permits the administrator to set the custom query that is sent to Active Directory. For more information, see Peoplepicker-searchadcustomquery.
Peoplepicker-searchadforests | Permits a user to search from a second one-way trusted forest or domain. For more information, see Peoplepicker-searchadforests.
Peoplepicker-serviceaccountdirectorypaths | Enables a farm administrator to manage the site collection that has a specific organizational unit (OU) setting as defined in the Setsiteuseraccountdirectorypath setting. For more information, see Peoplepicker-serviceaccountdirectorypaths.

For more information about configuring People Picker, see Configure People Picker (SharePoint Foundation 2010).

Using People Picker with multiple forests or domains

By default, People Picker will only return users, groups, and claims from the domain on which SharePoint Foundation 2010 is installed. If you want People Picker to return query results from more than one forest or domain, you must either have a two-way trust between the forests or domains, or you must configure People Picker to use an encrypted account and password for a one-way trust between forests and domains. For more information about trusts, see Managing Trusts (http://go.microsoft.com/fwlink/p/?LinkId=207573).

To configure People Picker for a one-way trust, you must first use the Stsadm setapppassword operation to set the password for use on the trusted forest or domain, and then use the Peoplepicker-searchadforests property for the setproperty operation to specify the forest or domain to search. Remember that the settings for People Picker are configured per zone for a Web application, so if you have more than one forest or domain in your farm, you must combine the accounts and passwords into a single command for the setproperty operation. For more information, see Peoplepicker-searchadforests: Stsadm property (Office SharePoint Server).

Considerations for People Picker

Planning for People Picker largely depends on what forests and domains you want users to be able to query, and what users, groups, and claims you want to display in query results. As you plan for the forests and domains you want users to query, consider the following questions:

  • Do users need to query across a forest or a domain?

  • What is the DNS name for each forest or domain you want users to query?

  • Will your forest or domain have a one-way or two-way trust with other forests or domains?

  • If you will be using a one-way trust, what credentials will be used to query the other farms or domains

Planning for the users, groups, and claims you want to display in the query results in People Picker will help you determine how to configure People Picker to return and display results from claims providers. As you plan for the users, groups, and claims you want to display in query results, consider the following questions:

  • Are there certain LDAP filters you want to apply to query results?

  • Do you want to restrict the query results to users, groups, or claims in a specific site collection?

  • Do you want to restrict the query results to users, groups, or claims in a certain Active Directory organizational unit (OU)

See Also

Concepts

Plan authentication methods (SharePoint Foundation 2010)
Custom claims providers for People Picker (SharePoint Foundation 2010)
Configure People Picker (SharePoint Foundation 2010)

Other Resources

Resource Center: Security and Authentication for SharePoint Foundation 2010


Custom claims providers for People Picker (SharePoint Foundation 2010)
See Also

Published: February 3, 2011

A claim consists of information about the identity of a user, such as a name, e-mail address, or group membership. A claims provider in Microsoft SharePoint Foundation 2010 issues claims, which SharePoint Foundation 2010 then packages into security tokens for users. When a user signs in to SharePoint Foundation 2010, the user's token is validated and then used to sign in to SharePoint Foundation 2010. Claims providers are displayed in the user interface of the Select People and Groups dialog box in the People Picker control. They provide the functionality used to find and select users, groups, and claims when permissions are assigned to items such as lists, libraries, and sites in SharePoint Foundation 2010. For information about the People Picker control, see People Picker overview (SharePoint Foundation 2010).

This article describes the use and benefits of claims providers, their architecture, special considerations for custom claims providers, and how to plan for them. It does not explain how to create or configure custom claims providers. For information about how to create a custom claims provider, see Claims How Tos (http://go.microsoft.com/fwlink/p/?LinkId=207578) and Creating Custom Claims Providers in SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=211324).

Before reading this article, you should understand the concepts described in Plan authentication methods (SharePoint Foundation 2010) and The Role of Claims (http://go.microsoft.com/fwlink/p/?LinkID=208326). For additional information about claims-based authentication, see SharePoint Claims-Based Identity (http://go.microsoft.com/fwlink/p/?LinkID=196647) and A Guide to Claims-based Identity and Access Control (http://go.microsoft.com/fwlink/p/?LinkID=187911).

In this article:

  • Uses and benefits

  • Architecture

  • About custom claims providers

  • Deploying and configuring custom claims providers

  • Using custom claims on more than one farm

  • Considerations for custom claims providers

Uses and benefits

A claims provider in SharePoint Foundation 2010 is used primarily for two reasons:

  • To augment claims

  • To provide name resolution

In the augmentation role, a claims provider augments a user token with additional claims during sign-in. For more information about claims augmentation, see Claims Provider (http://go.microsoft.com/fwlink/p/?LinkID=207579).

In the picking role, a claims provider lists, resolves, searches, and determines the "friendly" display of users, groups, and claims in the People Picker. Claims picking enables an application to surface claims in the People Picker, for example when configuring the security of a SharePoint site or SharePoint service. For more information about People Picker, see People Picker overview (SharePoint Foundation 2010).

You can use the claims providers that are included with SharePoint Foundation 2010, or you can create your own custom claims providers to provide additional claims in the security token for a user or to connect to additional sources of claims. For example, if you have a CRM application that contains roles that are not found in the user repository in Active Directory, you can create a custom claims provider to connect to that database and add CRM role data to a user's original claims token. For more information about claims provider usage scenarios, see Claims Provider (http://go.microsoft.com/fwlink/p/?LinkID=207579).

Architecture

When a Web application is configured to use claims-based authentication, SharePoint Foundation 2010 automatically uses two default claims providers:

  • The SPSystemClaimProvider (http://go.microsoft.com/fwlink/p/?LinkId=210011) class provides claims information related to the server farm where SharePoint Foundation 2010 is installed.

  • The SPAllUserClaimProvider (http://go.microsoft.com/fwlink/p/?LinkId=210012) class provides an All Users claim that is displayed in the Select People and Groups dialog box for People Picker.

Depending on the authentication method selected for a zone of a Web application, SharePoint Foundation 2010 also uses one or more of the default claims providers listed in the following table.

Authentication method | Claims provider
Windows authentication | SPActiveDirectoryClaimProvider (http://go.microsoft.com/fwlink/p/?LinkID=208325)
Forms-based authentication | SPFormsClaimProvider (http://go.microsoft.com/fwlink/p/?LinkId=210013)
Security Assertion Markup Language (SAML) token-based authentication | SPTrustedClaimProvider (http://go.microsoft.com/fwlink/p/?LinkId=210014)

These claims providers are displayed in the Select People and Groups dialog box for People Picker. You can see a list of claims providers for a farm by using the Get-SPClaimProviderWindows PowerShell cmdlet.

Note:

When a Web application is configured to use SAML token-based authentication, the SPTrustedClaimProvider class does not provide search functionality to the People Picker control. Any text entered in the People Picker control will automatically be displayed as if it had been resolved, regardless of whether it is a valid user, group, or claim. If your SharePoint Foundation 2010 solution will use SAML token-based authentication, you should plan to create a custom claims provider to implement custom search and name resolution.

Claims providers are registered on a server farm as features that are deployed to the farm. They are scoped at the farm level. Each claims provider object uses the SPClaimProviderDefinition class to include information about the claims provider, such as display name, description, assembly, and type. Two important properties of the SPClaimProviderDefinition class are IsEnabled and IsUsedByDefault. These properties determine whether a registered claims provider is enabled for use in the farm, and whether the claims provider is used by default in a particular zone. By default, all claims providers are enabled when they are deployed to a server farm. For information about the SPClaimProviderDefinition class, see SPClaimProviderDefinition Class (http://go.microsoft.com/fwlink/p/?LinkId=207595).

For more information about zones and authentication, see Plan authentication methods (SharePoint Foundation 2010).

For information about how to write a custom claims provider, see Creating Custom Claims Providers in SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkID=211324) and Claims Walkthrough: Writing Claims Providers for SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=207589). For information about how to override the default claims provider, see How to Override the Default Name Resolution and Claims Provider for SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=207591).

About custom claims providers

By default, the information that is resolved in People Picker when a query is performed depends on the information supplied by the claims provider. You cannot change what information is supplied and how it is displayed when you use an out-of-box claims provider. To do this, you must have a developer create a custom claims provider that will meet the needs of your solution for finding and selecting users, groups, and claims when a user assigns permissions to items such as a site, list, or library.

For example, if your Web application uses SAML authentication and you also want to resolve users from Active Directory, you will need to create a custom claims provider. For additional examples of claims provider use scenarios, see Claims Provider (http://go.microsoft.com/fwlink/p/?LinkID=207579).

When you create a custom claims provider, you can control what information is displayed and what results are returned in response to a query from the People Picker control. By default, you configure the Web application to use claims authentication, and then register the claims provider on the server.

Note:

You cannot control the order in which claims providers are displayed in the Select People and Groups dialog box in People Picker.

For information about how to write a custom claims provider, see How to: Create a Claims Provider (http://go.microsoft.com/fwlink/p/?LinkId=207588) and Claims Walkthrough: Writing Claims Providers for SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=207589). For information about how to override the default claims provider, see How to Override the Default Name Resolution and Claims Provider for SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=207591).

Deploying and configuring custom claims providers

By default, when you register a custom claims provider on the farm, the IsEnabled and IsUsedByDefault properties are both set to True. Unless the IsUsedByDefault property is set to False, the custom claims provider is displayed in the Select People and Groups dialog box in People Picker for all zones. Depending on the number of zones needed for your SharePoint Foundation 2010 solution, the authentication methods used by each zone, and the users for each zone, you may want to limit the zones in which your custom claims provider is displayed in People Picker.

Because claims providers are scoped at the farm level and enabled at the zone level, you must carefully plan the zones in which you want the custom claims provider to be displayed. In general, you should make sure that the IsUsedByDefault property is set to False, and then configure the SPIisSettings class for each zone in which you want to use the custom claims provider. To configure a custom claims provider for select zones, you can create a Windows PowerShell script that sets the claims provider for a zone by using the SPIisSettings.ClaimsProviders property, or you can create a custom application to allow you to enable a custom claims provider for select zones. For information about the SPIisSettings.ClaimsProvider property, see SPIisSettings.ClaimsProvider Property (http://go.microsoft.com/fwlink/p/?LinkId=207597). For information about how to create a custom application to configure claims providers for select zones, see the TechNet blog post, Configuring a Custom Claims Provider to be Used only on Select Zones in SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=207592).

For example, consider a scenario where there are two Web applications: The first Web application, PartnerWeb, has two zones — one intranet that uses Windows claims-based authentication and one extranet that uses forms-based authentication — and is used for collaboration among employees and partners. The second Web application, PublishingWeb, has only one zone that uses forms-based authentication and is an Internet publishing site for employees, business partners, and customer partners. Now, suppose that for the extranet zone on PartnerWeb, you want employees to be able to collaborate with business partners but not customer partners. To do this, you write a custom claims provider that determines whether the current user is a business partner or customer partner, based on the user's identity. In this example, users from fabrikam.com are business partners, while users from contoso.com are customer partners. When a user who is a business partner is authenticated in the PartnerWeb Web application, a claim for a role called BusinessPartner is added to the claim token; when a customer partner is authenticated, a claim for a role called CustomerPartner is added to the claim token. To make sure that customer partners are never added to the extranet collaboration site, you add a Web application policy on the PartnerWeb Web application for the extranet zone that explicitly denies access to any user who has a claim for a role called CustomerPartner. The custom claims provider would also need to implement search and type-in support for the Web application policy to resolve the CustomerPartner role claim so it can be added to the Web application policy. Finally, to enable this functionality on the extranet zone, you configure the SPIisSettings class for that zone to use the custom claims provider. The following diagram illustrates the authentication methods and claims provider settings for each Web application and zone.

Note:

On the Central Administration Web site, all claims providers are displayed in the Select People and Groups dialog box in People Picker, regardless of whether the IsUsedByDefault property is set to True.

You can set the IsUsedByDefault property by configuring it in a feature receiver that you create for your custom claims provider. For information about how to use a feature receiver to deploy a custom claims provider, see Sample: Feature Receiver to Deploy a Claims Provider (http://go.microsoft.com/fwlink/p/?LinkId=207590).

You can also override the settings of the IsEnabled and IsUsedByDefault properties by using the Set-SPClaimProviderWindows PowerShell cmdlet.

Important:

Changing the IsEnabled property to False will disable the claims provider for the entire server farm. This can be useful if you need to troubleshoot issues that might be caused by a custom claims provider. However, in general, the IsEnabled property should be set to True.

Using custom claims on more than one farm

Claim values are a combination of the claim itself, the claims provider name, and the order in which the claims provider was installed on the server. Therefore, if you want to use a claim across multiple farms or environments, you must install the claims providers in the same order on each farm in which you want to use the claim. Use the following steps when you have installed a custom claims provider on a farm and you want to use the same claim on additional farms.

  1. Register the claims providers on the additional farms in the same order that they were registered on the first farm.

  2. Perform a backup of the first farm. For information about how to back up a farm, see Back up a farm (SharePoint Foundation 2010).

  3. Use the back up from the first farm to restore the other farms. For information about how to restore a farm, see Restore a farm (SharePoint Foundation 2010).

Considerations for custom claims providers

As you plan custom claims providers for use with People Picker in your SharePoint solution, consider the following questions:

  • What zones does your Web application have, and what authentication methods are used in each zone?

  • Are there any custom claims that should be added to users to enable more advanced security scenarios?

  • Will you be using SAML authentication with a trusted identity provider?

  • What will be the source of the values for the users and roles that will be displayed in People Picker query results?

  • What claim data do you want to resolve in the Select People and Groups dialog box?

The SharePoint Foundation 2010 Content Publishing team would like to thank Steve Peschka for contributing to this article. His blog can be found here (http://go.microsoft.com/fwlink/p/?LinkId=210274).

See Also

Concepts

Plan authentication methods (SharePoint Foundation 2010)


Plan for Kerberos authentication (SharePoint Foundation 2010)

Microsoft SharePoint Foundation 2010 supports several methods of authentication. Deployments that require secure authentication, client identity delegation, and low network traffic can choose Kerberos authentication. For more information, see Plan authentication methods (SharePoint Foundation 2010).

In this article:

  • Kerberos authentication and Microsoft SharePoint Foundation 2010

  • Kerberos authentication and claims-based authentication

Kerberos authentication and Microsoft SharePoint Foundation 2010

Why you should consider Kerberos authentication | Why Kerberos authentication might not be appropriate for a deployment scenario
Kerberos is the most secure Integrated Windows authentication protocol, and supports advanced security features including Advanced Encryption Standard (AES) encryption and mutual authentication. | Kerberos authentication requires additional configuration of infrastructure and environment to function properly. In many cases, domain administrator permission is required to configure Kerberos. Kerberos authentication can be difficult to set up and manage. Misconfiguring Kerberos can prevent successful authentication to your sites.
Kerberos enables delegation of client credentials. | Kerberos authentication requires client computer connectivity to a Key Distribution Center (KDC), and client computer connectivity to an Active Directory Domain Services (AD DS) domain controller. In a Windows deployment, the KDC is an AD DS domain controller. While this is a common network configuration in a corporate environment, Internet-facing deployments are typically not configured this way.
Kerberos supports mutual authentication of clients and servers. |
Of the available secure authentication methods, Kerberos requires the least amount of network traffic to domain controllers. Kerberos can reduce page latency in certain scenarios, or increase the number of pages that a front-end Web server can serve in certain scenarios. Kerberos can also reduce the load on domain controllers. |
Kerberos is an open protocol that is supported by many platforms and vendors. |

Kerberos is a secure protocol that supports an authentication method that uses tickets provided by a trusted source. Kerberos tickets represent the network credentials of a user who is associated with a client computer. The Kerberos protocol defines the way in which users interact with a network authentication service to gain access to network resources. The Kerberos KDC issues a ticket to a client computer on behalf of a user. After a client computer establishes a network connection to a server, the client computer requests network access by presenting the Kerberos authentication ticket to the server. If the request contains acceptable user credentials, the KDC grants the request. For service applications, the authentication ticket must also contain an acceptable Service Principal Name (SPN). To enable Kerberos authentication, the client and server computers must already have a trusted connection to the KDC. The client and server computers must also be able to access Active Directory Domain Services (AD DS).

Kerberos delegation

Kerberos authentication supports the delegation of client identity. This means that a service can impersonate an authenticated client's identity. Impersonation enables a service to pass the authenticated identity to other network services on behalf of the client. Claims-based authentication can also be used to delegate client credentials, but it requires the backend application to be claims-aware. Several important services are not currently claims-aware.

Used in conjunction with Microsoft SharePoint Foundation 2010, Kerberos delegation enables a front-end service to authenticate a client and then use the client's identity to authenticate to a backend system. The backend system then performs its own authentication. When a client uses Kerberos authentication to authenticate with a front-end service, Kerberos delegation can be used to pass a client's identity to a backend system. The Kerberos protocol supports two types of delegation:

  • Basic Kerberos delegation (unconstrained)

  • Kerberos constrained delegation

Basic Kerberos delegation and Kerberos constrained delegation

Although basic Kerberos delegation can cross domain boundaries within the same forest, basic Kerberos delegation cannot cross a forest boundary. Kerberos constrained delegation cannot cross domain boundaries or forest boundaries. Depending on the service applications that are part of a SharePoint Foundation 2010 deployment, implementing Kerberos authentications with SharePoint Foundation 2010 can require the use of Kerberos constrained delegation. Therefore, to deploy Kerberos authentication with any of the following service applications, SharePoint Foundation 2010 and all external data sources must reside in the same Windows domain:

  • Excel Services

  • PerformancePoint Services

  • InfoPath Forms Services

  • Visio Services

To deploy Kerberos authentication with any of the following service applications, SharePoint Foundation 2010 can use either basic Kerberos delegation or Kerberos constrained delegation:

  • Business Data Connectivity service and Microsoft Business Connectivity Services

  • Access Services

  • Microsoft SQL Server Reporting Services (SSRS)

  • Microsoft Project Server 2010

Services that are enabled for Kerberos authentication can delegate identity multiple times. As an identity travels from service to service, the delegation method can change from basic Kerberos to Kerberos constrained. However, the reverse is not possible. The delegation method cannot change from Kerberos constrained to basic Kerberos. Therefore, it is important to anticipate and plan for whether or not a backend service will require basic Kerberos delegation. This can impact the planning and design of domain boundaries.

A Kerberos enabled service can use protocol transition to convert a non-Kerberos identity to a Kerberos identity that can be delegated to other Kerberos enabled services. This capability can be used, for example, to delegate a non-Kerberos identity from a front-end service to a Kerberos identity on a backend service.

Important:

Protocol transition requires Kerberos constrained delegation. Therefore, protocol transitioned identities cannot cross domain boundaries.

Claims-based authentication can be used as an alternative to Kerberos delegation. Claims-based authentication enables a client's authentication claim to be passed between two different services if the services meet all of the following criteria:

  • There must be a trust relationship between the services.

  • Both services must be claims-aware.

For more information about Kerberos authentication, see the following resources:

  • How the Kerberos Version 5 Authentication Protocol Works (http://go.microsoft.com/fwlink/p/?LinkID=196644)

  • Microsoft Kerberos (http://go.microsoft.com/fwlink/p/?LinkID=125740)

  • Kerberos Explained

Kerberos authentication and claims-based authentication

SharePoint Foundation 2010 supports claims-based authentication. Claims-based authentication is built on Windows Identity Foundation (WIF), which is a set of .NET Framework classes that are used to implement claims-based identity. Claims-based authentication relies on standards such as WS-Federation and WS-Trust. For more information about claims-based authentication, see the following resources:

  • Claims-based Identity for Windows: An Introduction to Active Directory Federation Services 2.0, Windows CardSpace 2.0, and Windows Identity Foundation (white paper) (http://go.microsoft.com/fwlink/p/?LinkId=198942)

  • Windows Identity Foundation home page (http://go.microsoft.com/fwlink/p/?LinkId=198943)

  • An Introduction to Claims (http://go.microsoft.com/fwlink/p/?LinkId=217399)

  • SharePoint Claims-Based Identity (http://go.microsoft.com/fwlink/p/?LinkID=196647)

When you create a SharePoint Foundation 2010 Web application, you have the option of selecting either of two authentication modes: claims-based or classic-mode. For new implementations of SharePoint Foundation 2010, you should consider using claims-based authentication. By using claims-based authentication, all supported authentication types are available for your Web applications.

The following service applications require the translation of claims-based credentials to Windows credentials. This process of translation uses the Claims to Windows Token Service (C2WTS):

  • Excel Services

  • PerformancePoint Services

  • InfoPath Forms Services

  • Visio Services

The service applications that require the C2WTS must use Kerberos constrained delegation. This is because the C2WTS requires protocol transition, and protocol transition is only supported by Kerberos constrained delegation. For the service applications in the preceding list, the C2WTS translates claims within the farm to Windows credentials for outbound authentication. It is important to understand that these service applications can leverage the C2WTS only if the incoming authentication method is either claims-based or classic-mode. Service applications that are accessed through Web applications and that use SAML claims or forms-based authentication claims do not use the C2WTS, and, therefore, cannot translate claims to Windows credentials.

For comprehensive guidance for configuring Kerberos in nine specific scenarios, including core deployment, three Microsoft SQL Server solutions, and scenarios that use Excel Services, PowerPivot for SharePoint, Visio Services, PerformancePoint Services, and Business Connectivity Services, see Configuring Kerberos authentication for SharePoint 2010 Products (http://go.microsoft.com/fwlink/p/?LinkId=197178).


Forefront UAG integration (SharePoint Foundation 2010)

Published: February 3, 2011

Information technology (IT) professionals who manage websites that use Microsoft SharePoint Foundation 2010 may want to make them available to users who are outside of their corporate network. This concept is referred to as publishing, and this is made possible by using edge protection software such as Microsoft Forefront Unified Access Gateway 2010 (UAG).

Publishing SharePoint Sites with UAG

The following articles contain procedures that are required to publish SharePoint websites through Forefront UAG.

  • SharePoint publishing solution guide (http://go.microsoft.com/fwlink/p/?LinkId=206256)

    Intended for system administrators who are responsible for publishing SharePoint websites for extranet users.

  • Publishing SharePoint Workspace Mobile on Forefront UAG (http://go.microsoft.com/fwlink/p/?LinkId=206257)

    Describes how to publish the SharePoint 2010 mobile workspace for extranet users.


Claims-based authentication with Microsoft UAG 2010 (SharePoint Foundation 2010)
See Also

Published: June 28, 2011

Microsoft Unified Access Gateway (UAG) 2010 with Service Pack 1 (SP1) adds support for Active Directory Federated Services Version 2.0 (ADFS 2.0), and UAG is a claims-aware relying party that now supports publishing Microsoft SharePoint Foundation 2010 applications with claims-based authentication. (Partner access using single sign-on to applications or to servers running SharePoint Foundation 2010 and that are not claims-aware is still supported.)

The following steps detail the process flow for authenticating users from a partner organization through a server that is running UAG to a server that is running SharePoint Foundation 2010:

  1. The partner users attempt to access the published SharePoint Foundation application using claims-based authentication in one of two ways: by accessing the Forefront UAG portal and then clicking the published SharePoint Foundation application or by accessing the published SharePoint Foundation application directly using the SharePoint Foundation alternate access mapping name.

  2. Forefront UAG redirects the web browser request to the Resource Federation server to authenticate the user.

  3. The Resource Federation server shows the home realm discovery page to users on which they must choose the organization to which they belong; in this case, the partner organization.

  4. The Resource Federation server redirects the web browser to the Account Federation server where users authenticate using their own credentials, after which they receive a security token. Some authentication schemes prompt for credentials.

  5. Users are silently redirected several times and automatically authenticated using the security token created by the Account Federation server to the Resource Federation server and then to Forefront UAG. If they attempted to access the published SharePoint Foundation application directly, they are silently redirected to the SharePoint Foundation site, after which the SharePoint Foundation site appears. If they first accessed the Forefront UAG portal, they must click the SharePoint Foundation application to view the SharePoint Foundation site.

  6. After the first successful connection to the SharePoint Foundation site, the Resource Federation server stores a cookie on the user's computer. The cookie is stored by default for 30 days; the duration is configurable in the web.config file on the Resource Federation server. During this time, users are not required to answer identification questions on the home realm discovery page; that is, choosing the organization to which they belong.

Warning:

Office integration will fail in this scenario if a remote client's session expires on the UAG server.

Note:

For more information about remote user access using claims and Microsoft UAG, see Plan employee access using claims.

UAG with SP1 also adds claims-based authorization. For example: If a user has a role claim, UAG can allow or deny the user's access based on the value of the claim. These rules are set through policy in UAG and are mapped to roles in ADFS.

Note:

These claims-based authorization rules can only be used when UAG is a relying party of ADFS.

UAG with SP1 also adds single sign-out functionality; users who sign out are also signed out from all applications that rely on the authenticating federation server. There are a few ways that a client can sign out (or be signed out):

  • A user can sign out from the UAG portal.

  • A timed interval of inactivity can sign out a user.

  • Scheduled sign-out times of UAG can sign out a user.

For more information about single sign-out, see Overview of AD FS 2.0 with Forefront UAG (http://go.microsoft.com/fwlink/p/?LinkId=207207).

UAG can still provide single sign-on (SSO) access if an application uses NTLM or Kerberos authentication, and UAG performs Kerberos translation for clients. For more information, see Configuring single sign-on with Kerberos constrained delegation to non-claims-aware applications (http://go.microsoft.com/fwlink/p/?LinkId=207208).

See Also

Other Resources

Plan employee access using claims
Overview of AD FS 2.0 with Forefront UAG (http://go.microsoft.com/fwlink/p/?LinkId=207207)
Configuring single sign-on with Kerberos constrained delegation to non-claims-aware applications (http://go.microsoft.com/fwlink/p/?LinkId=207208)


Plan for claims-based authentication or classic-mode authentication (SharePoint Foundation 2010)

Published: December 13, 2011

In Microsoft SharePoint Foundation 2010, you can choose between claims-based authentication and classic-mode authentication when you create a Web application.

For more information about these two authentication modes, see Plan authentication methods (SharePoint Foundation 2010).

Choosing classic-mode or claims-based authentication

Choosing between classic-mode and claims-based authentication should be based on business needs. For example, if you need to support user accounts in identity providers that are not based on Active Directory Domain Services (AD DS), and you implement forms-based authentication, you must use forms-based authentication with claims-based authentication in SharePoint Foundation 2010. We recommend that you use claims-based authentication whenever possible.

The following chart summarizes the support for authentication types by each authentication mode.

Type Classic-mode authentication Claims-based authentication

Windows authentication methods

  • NTLM

  • Kerberos

  • Anonymous

  • Basic

  • Digest

Yes

Yes

Forms-based authentication methods

  • LDAP

  • SQL Server database or other database

  • Custom or third-party membership and role providers

No

Yes

SAML token-based authentication methods

  • AD FS 2.0

  • Third-party identity provider

  • LDAP

N/A

Yes

Upgrading to SharePoint Foundation 2010

If you are upgrading from Windows SharePoint Services 3.0 to SharePoint Foundation 2010, you should consider the following information:

  • If you are upgrading an earlier version solution to SharePoint Foundation 2010 and the solution includes only Windows accounts, you can use either mode of Windows authentication: Windows Claims or Windows Classic. We recommend that you use claims-based authentication whenever possible. For more information about using claims-based authentication, see Implementing Claims-Based Authentication with SharePoint Server 2010 (whitepaper).

  • If you are upgrading a solution that requires forms-based authentication, the only option is to upgrade to claims-based authentication.

  • Custom code that uses Windows identities might have to be updated. If you have custom code that uses Windows identities, you can use classic-mode authentication until your code is updated and tested. For example, if you wrote a custom Web part for Windows SharePoint Services 3.0 that retrieved the current user identity and you are upgrading to SharePoint Foundation 2010, you should use SPWeb.CurrentUser() instead of HttpContext.Current.User.Identity() in order to retrieve the identity.

  • The migration time will vary, depending on the number of users that are listed in the UserInfo table in the content database. When you change a Web application from Windows classic mode to Windows claims, you must use Windows PowerShell to convert Windows identities to Windows claims identities. Be sure to allow for enough time during the upgrade process to complete this task.

  • You can search and list names in people picker when you are using SAML token-based authentication, but they cannot be checked for validity unless you write a custom claims provider.

    For more information about how to write a customer claim provider, see Custom claims providers for People Picker (SharePoint Foundation 2010).

  • If you are using the Outlook social connector, you must use either Windows classic-mode authentication or Windows claims authentication.

The following table illustrates several compatibility considerations when you migrate from Windows SharePoint Services 3.0 to SharePoint Foundation 2010.

 | To SharePoint Foundation 2010 Windows classic mode authentication | To SharePoint Foundation 2010 Windows claims authentication methods | To SharePoint Foundation 2010 forms-based authentication methods | To SharePoint Foundation 2010 SAML token-based authentication methods
From Windows SharePoint Services 3.0 Windows authentication methods | Supported | Supported | Not supported | Not supported
From Windows SharePoint Services 3.0 forms-based authentication methods | Not supported | Not supported | Supported1 | Supported2
From Windows SharePoint Services 3.0 Web single sign-on | Not supported | Not supported | Not supported3 | Not supported3

Notes for the previous table of compatibility considerations:

  1. This upgrade path is supported by migrating to claims authentication.

  2. This upgrade path is supported, but it requires additional configuration in order to complete the migration.

  3. This upgrade path is not supported, but the same level of functionality is provided through SAML token-based authentication.

For additional information about migrating, see the following topics:

  • Upgrading to SharePoint Foundation 2010

  • Migrate from forms-based authentication to claims-based authentication (SharePoint Foundation 2010)

  • Migrate from classic-mode to claims-based authentication (SharePoint Foundation 2010)

Features that do not work with forms-based authentication or SAML security tokens

The following SharePoint Foundation 2010 features do not work when you switch to a claims-based Web application that uses forms-based authentication or Security Assertion Markup Language (SAML) security tokens. These features do not work because claims-based authentication does not generate a Windows security token, which is necessary for these features.

  • Search Alerts

  • SharePoint Foundation 2010 Explorer View

  • Claims to Windows Token Service (C2WTS)

  • InfoPath Forms Services

  • Search crawling

    Note:

    If you are using forms-based authentication or SAML token-based authentication, you will still need a separate zone that supports Windows authentication to enable Microsoft Search Server 2010 to crawl your content.

  • Certificate Authentication

    Note:

    Certificate authentication is not supported in SharePoint Foundation 2010, but you can configure Unified Access Gateway (UAG) as a front-end to SharePoint Foundation 2010 to enable certificate authentication by integrating with Active Directory Federated Services (AD FS) and SAML token-based authentication.

    For more information about configuring SharePoint Foundation 2010 with UAG, see Forefront UAG integration (SharePoint Foundation 2010).

Features that require additional configuration in order to work with forms-based authentication or SAML security tokens

There are several SharePoint Foundation 2010 features that require additional configuration to work with forms-based authentication or SAML security tokens.

  • Business Intelligence (BI)

    BI clients must either use Windows Claims authentication, Windows Classic authentication, or the Secure Store Service. When you are using the Secure Store Service, SAML claims are not translated to Windows tokens, so other services will not detect the SAML identity; the identity will be the service account, an anonymous account, or an unattended account.

  • Information Rights Management (IRM)

    A hotfix that enables basic IRM functionality with claims and SAML is available from Microsoft. For more information, see Microsoft Knowledge Base article Description of the SharePoint Foundation 2010 hotfix package: June 30, 2011(http://go.microsoft.com/fwlink/?LinkId=236873).


Security planning for server farms (SharePoint Foundation 2010)

Published: July 16, 2012

This section contains security articles designed to help you to plan server farms environments and configurations.

In this section:

  • Plan administrative tasks in a least-privilege environment (SharePoint Foundation 2010)

  • Plan for administrative and service accounts (SharePoint Foundation 2010)


Plan administrative tasks in a least-privilege environment (SharePoint Foundation 2010)

Published: August 11, 2011

This article describes how to configure and maintain a Microsoft SharePoint Foundation 2010 farm by using least-privileged administration.

Overview

The concept of least-privileged administration assigns users the minimum permissions that are required for users to complete authorized tasks. The goal of least-privileged administration is to configure and help maintain secure control of an environment. The result is that each service is granted access to only the resources that are absolutely necessary. Implementing least-privileged administration can result in increased operational costs because additional resources might be required to maintain this level of administration. Moreover, the ability to troubleshoot security problems can also be diminished.

Security Note:

Organizations implement least-privileged administration to achieve better security than would be typically recommended. Only a small percentage of organizations require this heightened level of security because of the resource costs of maintaining least-privileged administration. However, some deployments that might require this heightened level of security include governmental agencies, security organizations, and organizations in the financial services industry. The implementation of a least-privileged environment should not be confused with best practices. In a least-privileged environment, administrators implement best practices together with additional heightened levels of security is performed.

Least-privileged environment for accounts and services

To plan for least-privileged administration, you must consider several accounts, roles, and services. Some apply to SQL Server and some apply to SharePoint 2010 Products. As administrators lock down additional accounts and services, daily operational costs are likely to increase.

Microsoft SQL Server roles

In a least-privileged administration environment, we recommend that you remove the following two SQL Server server-level roles from accounts that are not SharePoint service accounts, but are used for SharePoint administration:

  • dbcreator- Members of the dbcreator fixed server role can create, alter, drop, and restore any database.

  • securityadmin- Members of the securityadmin fixed server role manage logins and their properties. They can GRANT, DENY, and REVOKE server-level permissions. They can also GRANT, DENY, and REVOKE database-level permissions if they have access to a database. Additionally, they can reset passwords for SQL Server logins.

    Security Note:

    The ability to grant access to the Database Engine and to configure user permissions allows the security admin to assign most server permissions. The securityadmin role should be treated as equal to the sysadmin role.

For additional information about SQL Server server-level roles, see Server Level Roles (http://go.microsoft.com/fwlink/p/?LinkId=213450)

The removal of one or more of these SQL Server roles might cause "Unexpected" error messages that will be displayed in the Central Administration Web site. In addition, you may receive the following message in the Unified Logging Service (ULS) log file:

System.Data.SqlClient.SqlException… <operation type> permission denied in database <database>. Table <table>

Along with an error message that may be displayed, the user may be unable to perform any of the following tasks:

  • Restore a backup of a farm due to the inability to write to a database

  • Provision a service instance or Web application

  • Configure managed accounts

  • Change managed accounts for Web applications

  • Any database, managed account, or services operation that requires the use of the Central Administration Web site

In certain situations, database administrators (DBAs) may want to operate independently from SharePoint administrators and create and manage all the databases. For information about how DBAs create and manage all databases, see Deploy by using DBA-created databases (SharePoint Foundation 2010).

SharePoint Foundation 2010 roles and services

In general, the ability to create new databases should be removed from SharePoint service accounts. No SharePoint service account should have the sysadmin role on the Microsoft SQL Serverinstance and no SharePoint service account should be a local Administrator on the server that runs Microsoft SQL Server.

However, you could lock down several other SharePoint Foundation 2010 services and accounts:

  • SharePoint_Shell_Access role

    When this Microsoft SQL Server role is removed, the ability to write entries to the configuration and content database is removed. For additional information about this role, see Add-SPShellAdmin.

  • SharePoint Timer service (SPTimerV4)

    By default, this service is installed and maintains configuration cache information. If the service type is set to disabled the following behavior may occur:

    • No timer jobs will run

    • Health analyzer rules will not run

    • Maintenance and farm configuration will be out of date

  • SharePoint Administration service (SPAdminV4)

    This service performs automated changes that require local administrator permission on the server. When the service is not running, you must manually process server-level administrative changes. If the service type is set to disabled, the following behavior may occur:

    • Administrative timer jobs will not run

    • Web configuration files will not be updated

    • Security and local groups will not be updated

    • Registry values and keys will not be written

    • Services may be unable to be started or restarted

    • Provisioning of services may be unable to be completed

  • SPUserCodeV4 Service

    This service lets a site collection administrator upload sandboxed solutions to the Solutions gallery. For additional information about sandboxed solutions, see Sandboxed solutions overview (SharePoint Foundation 2010).

For more information services, see SharePoint Administration service is disabled (SharePoint 2010 Products).

Depending on an organization's business requirements, if any SharePoint Foundation 2010 services or roles are implemented, the behavior to the following features may occur:

  • Backup and restore

    The ability to perform a restore from a backup may fail if database permissions have been removed.

  • Upgrade

    The upgrade process will start correctly, but then fail as you do not have suitable permissions to databases. If your organization is already in a least-privileged environment, the workaround is move to a best practices environment to complete the upgrade, and then move back to a least-privileged environment.

  • Update

    The ability to apply a software update to a farm will succeed for the schema of the configuration database, but fail on the content database and services.

Additional requirements to consider

In addition to the preceding considerations, you might have to consider more operations. The following list is not complete. Selectively use the items at your own discretion:

  • Setup user administrator account- This account is used to set up each server in a farm. The account must be a member of the Administrators group on each server in the Microsoft SharePoint Server 2010 farm. For additional information about this account, see Administrative accounts

  • My Site host application pool account- This is the account under which the My Site application pool runs. To configure this account, you need to be a member in the Farms Administrators group.

  • Built-in user group- Removing the built-in user security group or changing the permissions may have unanticipated consequences.

  • Group permissions-By default the WSS_ADMIN_WPG SharePoint group has read and write access to local resources. The following WSS_ADMIN_WPG file system locations, %WINDIR%\System32\drivers\etc\HOSTS and %WINDIR%\Tasks are needed for Microsoft SharePoint Foundation to work properly. If other services or applications are running on a server, you may consider how they access the Tasks or HOSTS folder locations. For additional information about account settings, see Account permissions and security settings (SharePoint Server 2010)

  • Change permission of a service- A change of a permission of a service may have unanticipated consequences. For example, if the following registry key, HKLM\System\CurrentControlSet\Services\PerfProc\Performance\Disable Performance Counters, has the value of 0, the User Code Host service would be disabled which would cause sandboxed solutions to stop working. For additional information about the User Code service not working, see The SharePoint 2010 User Code Host service fails to start (http://go.microsoft.com/fwlink/p/?LinkId=225642)


Plan for administrative and service accounts (SharePoint Foundation 2010)

Published: September 7, 2011

This article describes the accounts that that you must plan for and describes the deployment scenarios that affect account requirements.

In this article:

  • About administrative and service accounts

  • Single server standard requirements

  • Server farm requirements

Use this article with the following deployment article: Initial deployment administrative and service accounts (SharePoint Foundation 2010)

The initial deployment administrative and service accounts article describes the specific account and permissions that you need to grant prior to running Setup.

This article does not describe security roles and permissions required to administer in Microsoft SharePoint Foundation 2010.

About administrative and service accounts

This section lists and describes the accounts that you must plan for. The accounts are grouped according to scope.

After you complete installation and configuration of accounts, ensure that you do not use the Local System account to perform administration tasks or to browse sites.

Server farm-level accounts

The following table describes the accounts that are used to configure Microsoft SQL Server database software and to install SharePoint Foundation 2010.

Account Purpose

SQL Server service account

SQL Server prompts for this account during SQL Server Setup. This account is used as the service account for the following SQL Server services:

  • MSSQLSERVER

  • SQLSERVERAGENT

If you are not using the default instance, these services will be shown as:

  • MSSQL$InstanceName

  • SQLAgent$InstanceName

Setup user account

The user account that is used to run:

If you run Windows PowerShell cmdlets that affect a database, this account must be a member of the db_owner fixed database role for the database.

  • Setup on each server computer

  • SharePoint Products Configuration Wizard

  • The Psconfig command-line tool

  • The Stsadm command-line tool

Server farm account

This account is also referred to as the database access account.

This account is:

  • The application pool identity for the SharePoint Central Administration Web site.

  • The process account for the Windows SharePoint Services Timer service.

Service application accounts

The following table describes the accounts that are used to set up and configure a service application. Plan one set of an application pool and proxy group for each service application you plan to implement.

For additional information about service application endpoints, see Using Service Endpoints (http://go.microsoft.com/fwlink/p/?LinkId=227293).

Account | Service | Purpose | Requirements
Service Application Endpoint | Business Data Connectivity Service Search Service Usage and Health Data Collection Service | Used as the identity for the service application endpoint application pool. Unless there are specific isolation requirements, the application pool can be used to host multiple service application endpoints. | Must be a member of the Farm Administrators group.
 | Application Discovery and Load Balancer Service Application | Used as the identity for the service application endpoint application pool. This account must be the Farm Account and the application pool is created automatically by the SharePoint Products Configuration Wizard. | Must be a member of the Farm Administrators group.
Default Content Access | Search Service | The default account when crawling content. Note that additional accounts can be specified per crawl rule. | Must have Read Access to the content being crawled. Full Read permissions must be granted explicitly to content that is outside the local farm. Full Read permissions are automatically configured for content databases in the local farm.
Search Service | Search Service | This is the Windows Service account for the SharePoint Server Search Service. This setting affects all Search service applications in the farm. | Must be a domain user account.

Microsoft SharePoint Foundation 2010 search service accounts

The following table describes the accounts that are used for the SharePoint Foundation 2010 search service account.

SharePoint Foundation 2010 uses these accounts only for searching Help content in response to user search queries. There is only one instance of the SharePoint Foundation 2010 Search service in a farm.

Account Purpose

SharePoint Foundation 2010 Search Service

Used as the service account for the SharePoint Foundation 2010 Search Service. This account cannot be a built-in account, such as Local Service or Network Service.

SharePoint Foundation 2010 Search Content Access

Used to crawl Help content. For proper search functionality and information security, do not use an administrator account or an account that can modify content.

Used to crawl Help content. For proper search functionality and information security, do not use an administrator account or an account that can modify content.

Additional application pool identity accounts

If you create additional application pools to host sites, plan for additional application pool identity accounts. The following table describes the application pool identity account. Plan one application pool account for each application pool you plan to implement.

Account | Purpose
Application pool identity | The user account that the worker processes that service the application pool use as their process identity. This account is used to access content databases associated with the Web applications that reside in the application pool.

Single server standard requirements

If you are deploying to a single server computer, account requirements are greatly reduced. In an evaluation environment, you can use a single account for all of the account purposes. In a production environment, ensure that the accounts you create have the appropriate permissions for their purposes.

For a list of account permissions for single server environments, see Initial deployment administrative and service accounts (SharePoint Foundation 2010).

Server farm requirements

If you are deploying to more than one server computer, use the server farm standard requirements to ensure that accounts have the appropriate permissions to perform their processes across multiple computers. The server farm standard requirements detail the minimum configuration that is necessary to operate in a server farm environment.

For a more secure environment, see Plan administrative tasks in a least-privilege environment (SharePoint Foundation 2010)

For a list of standard requirements for server farm environments see the requirements listed in the Technical reference: Account requirements by scenario section of this article.

For some accounts, additional permissions or access to databases are configured when you run Setup. These are noted in the accounts planning tool. An important configuration for database administrators to be aware of is the addition of the WSS_Content_Application_Pools database role. Setup adds this role to the following databases:

  • SharePoint_Config database (configuration database)

  • SharePoint_AdminContent database

Members of the WSS_Content_Application_Pools database role are granted the Execute permission to a subset of the stored procedures for the database. Additionally, members of this role are granted the Select permission to the Versions table (dbo.Versions) in the SharePoint_AdminContent database.

For other databases, the accounts planning tool indicates that access to read from these databases is automatically configured. In some cases, limited access to write to a database is also automatically configured. To provide this access, permissions to stored procedures are configured. For the SharePoint_Config database, for example, access to the following stored procedures is automatically configured:

  • proc_dropEmailEnabledList

  • proc_dropEmailEnabledListsByWeb

  • proc_dropSiteMap

  • proc_markForDeletionEmailEnabledList

  • proc_markForDeletionEmailEnabledListsBySite

  • proc_markForDeletionEmailEnabledListsByWeb

  • proc_putDistributionListToDelete

  • proc_putEmailEnabledList

  • proc_putSiteMap

Technical reference: Account requirements by scenario

This section lists account requirements by scenario:

  • Single server standard requirements

  • Server farm standard requirements

Single server standard requirements

Server farm-level accounts

Account | Requirements
SQL Server service | Local System account (default)
Setup user | Member of the Administrators group on the local computer
Server farm | Network Service (default) No manual configuration is necessary.

Microsoft SharePoint Foundation 2010 Search service accounts

Account | Requirements
SharePoint Foundation 2010 Search Service | Must not be a built-in account, such as Local Service or Network Service.
SharePoint Foundation 2010 Search Service Content Access | For proper search functionality and information security, do not use an administrator account or an account that can modify content. This account is automatically added to the Full Read policy, giving it read-only access to all Help content.

Additional application pool identity accounts

Account | Requirements
Application pool identity | No manual configuration is necessary. The Network Service account is used for the default Web site that is created during Setup and configuration.

Server farm standard requirements

Server farm-level accounts

Account Requirements

SQL Server service account

Use either a Local System account or a domain user account.

If a domain user account is used, this account uses Kerberos authentication by default, which requires additional configuration in your network environment. If SQL Server uses a service principal name (SPN) that is not valid (that is, that does not exist in the Active Directory service environment), Kerberos authentication fails, and then NTLM is used. If SQL Server uses an SPN that is valid but is not assigned to the appropriate container in Active Directory, authentication fails. Authentication will always try to use the first SPN it finds, so ensure that there are no SPNs assigned to inappropriate containers in Active Directory.

If you plan to back up to or restore from an external resource, permissions to the external resource must be granted to the appropriate account. If you use a domain user account for the SQL Server service account, grant permissions to that domain user account. However, if you use the Network Service or the Local System account, grant permissions to the external resource to the machine account (domain_name\SQL_hostname$).

Setup user account

  • Domain user account.

  • Member of the Administrators group on each server on which Setup is run.

  • SQL Server login on the computer running SQL Server.

  • Member of the following SQL Server security roles:

    • securityadmin fixed server role

    • dbcreator fixed server role

If you run Stsadm commands that affect a database, this account must be a member of the db_owner fixed database role for the database.

Server farm account

  • Domain user account.

  • If the server farm is a child farm with Web applications that consume shared services from a parent farm, this account must be a member of the db_owner fixed database role on the configuration database of the parent farm.

Additional permissions are automatically granted for this account on Web servers and application servers that are joined to a server farm.

This account is automatically added as a SQL Server login on the computer running SQL Server and added to the following SQL Server security roles:

  • dbcreator fixed server role

  • securityadmin fixed server role

  • db_owner fixed database role for all databases in the server farm

Note if you configure the Secure Store Service, the server farm account will not automatically be given db_owner access to the Secure Store Service database.

Microsoft SharePoint Foundation 2010 Search accounts

Account Requirements

Microsoft SharePoint Foundation 2010 Search service account

  • Must be a domain user account.

  • Must not be a member of the Farm Administrators group.

The following are automatically configured:

  • Access to read from the configuration database and the SharePoint_Admin content database.

  • Membership in the db_owner role for the WSS_ Search database.

Microsoft SharePoint Foundation 2010 Search content access account

  • Same requirements as the SharePoint Foundation Search Service account.

  • Automatically added to the Web application Full Read policy for the farm.

Additional application pool identity accounts

Account Requirements

Application pool identity

No manual configuration is necessary.

The following are automatically configured:

  • Membership in the db_owner role for content databases and search databases associated with the Web application.

  • Membership in specific application pool roles for the configuration and the SharePoint_AdminContent databases.

  • Additional permissions for this account to front-end Web servers and application servers are automatically granted.


Plan security hardening (SharePoint Foundation 2010)
See Also

This article describes security hardening for Microsoft SharePoint Foundation 2010 Web server, application server, and database server roles, and gives detailed guidance about the specific hardening requirements for ports, protocols, and services in Microsoft SharePoint 2010 Products.

In this article:

  • Secure server snapshots

  • Specific port, protocol, and service guidance

Secure server snapshots

In a server farm environment, individual servers play specific roles. Security hardening recommendations for these servers depend on the role each server plays. This article contains secure snapshots for two categories of server roles:

  • Web server and application server roles

  • Database server role

The snapshots are divided into common configuration categories. The characteristics defined for each category represent the optimal hardened state for Microsoft SharePoint 2010 Products. This article does not include hardening guidance for other software in the environment.

Web server and application server roles

This section identifies hardening characteristics for Web servers and application servers. Some of the guidance applies to specific service applications; in these cases, the corresponding characteristics need to be applied only on the servers that are running the services associated with the specified service applications.

Category Characteristic

Services listed in the Services MMC snap-in

Enable the following services:

  • File and Printer Sharing

  • World Wide Web Publishing Service

Ensure that these services are not disabled:

  • Claims to Windows Token Service

  • SharePoint 2010 Administration

  • SharePoint 2010 Timer

  • SharePoint 2010 Tracing

  • SharePoint 2010 VSS Writer

Ensure that these services are not disabled on the servers that host the corresponding roles:

  • SharePoint 2010 User Code Host

  • SharePoint Foundation Search V4

Ports and protocols

  • TCP 80, TCP 443 (SSL)

  • File and Printer Sharing service —either of the following, used by search roles:

    • Direct-hosted SMB (TCP/UDP 445) — this is the recommended port

    • NetBIOS over TCP/IP (NetBT) (TCP/UDP ports 137, 138, 139) — disable this port if you do not use it

  • Ports required for communication between Web servers and service applications (the default is HTTP):

    • HTTP binding: 32843

    • HTTPS binding: 32844

    • net.tcp binding: 32845 (only if a third party has implemented this option for a service application)

  • UDP port 1434 and TCP port 1433 — default ports for SQL Server communication. If these ports are blocked on the SQL Server computer (recommended) and databases are installed on a named instance, configure a SQL Server client alias for connecting to the named instance.

  • TCP/IP 32846 for the Microsoft SharePoint Foundation User Code Service (for sandbox solutions) — This port must be open for outbound connections on all Web servers. This port must be open for inbound connections on Web servers or application servers where this service is turned on.

  • Ensure that ports remain open for Web applications that are accessible to users.

  • Block external access to the port that is used for the Central Administration site.

  • TCP/25 (SMTP for e-mail integration)

Registry

No additional guidance

Auditing and logging

If log files are relocated, ensure that the log file locations are updated to match. Update directory access control lists (ACLs) also.

Code access security

Ensure that you have a minimal set of code access security permissions enabled for your Web application. The <trust> element in the Web.config file for each Web application should be set to WSS_Minimal (where WSS_Minimal has its low defaults as defined in 14\config\wss_minimaltrust.config or by your own custom policy file, which is minimally set.)

Web.config

Follow these recommendations for each Web.config file that is created after you run Setup:

  • Do not allow compilation or scripting of database pages via the PageParserPaths elements.

  • Ensure <SafeMode> CallStack=""false"" and AllowPageLevelTrace=""false"".

  • Ensure that the Web Part limits around maximum controls per zone is set low.

  • Ensure that the SafeControls list is set to the minimum set of controls needed for your sites.

  • Ensure that your Workflow SafeTypes list is set to the minimum level of SafeTypes needed.

  • Ensure that customErrors is turned on (<customErrors mode=""On""/>).

  • Consider your Web proxy settings as needed (<system.net>/<defaultProxy>).

  • Set the Upload.aspx limit to the highest size you reasonably expect users to upload (default is 2 GB). Performance can be affected by uploads that exceed 100 MB.

Database server role

The primary recommendation forSharePoint 2010 Products is to secure inter-farm communication by blocking the default ports used for Microsoft SQL Server communication and establishing custom ports for this communication instead. For more information about how to configure ports for SQL Server communication, see Blocking the standard SQL Server ports, later in this article.

Category Characteristic

Ports

  • Block UDP port 1434.

  • Consider blocking TCP port 1433.

This article does not describe how to secure SQL Server. For more information about how to secure SQL Server, see Securing SQL Server (http://go.microsoft.com/fwlink/p/?LinkId=186828).

Specific port, protocol, and service guidance

The rest of this article describes in greater detail the specific hardening requirements for SharePoint 2010 Products.

In this section:

  • Blocking the standard SQL Server ports

  • Service application communication

  • File and Printer Sharing service requirements

  • Service requirements for e-mail integration

  • SharePoint 2010 Products services

  • Web.config file

Blocking the standard SQL Server ports

The specific ports used to connect to SQL Server are affected by whether databases are installed on a default instance of SQL Server or a named instance of SQL Server. The default instance of SQL Server listens for client requests on TCP port 1433. A named instance of SQL Server listens on a randomly assigned port number. Additionally, the port number for a named instance can be reassigned if the instance is restarted (depending on whether the previously assigned port number is available).

By default, client computers that connect to SQL Server first connect by using TCP port 1433. If this communication is unsuccessful, the client computers query the SQL Server Resolution Service that is listening on UDP port 1434 to determine the port on which the database instance is listening.

The default port-communication behavior of SQL Server introduces several issues that affect server hardening. First, the ports used by SQL Server are well-publicized ports and the SQL Server Resolution Service has been the target of buffer overrun attacks and denial-of-service attacks, including the "Slammer" worm virus. Even if SQL Server is updated to mitigate security issues in the SQL Server Resolution Service, the well-publicized ports remain a target. Second, if databases are installed on a named instance of SQL Server, the corresponding communication port is randomly assigned and can change. This behavior can potentially prevent server-to-server communication in a hardened environment. The ability to control which TCP ports are open or blocked is essential to securing your environment.

Consequently, the recommendation for a server farm is to assign static port numbers to named instances of SQL Server and to block UDP port 1434 to prevent potential attackers from accessing the SQL Server Resolution Service. Additionally, consider reassigning the port used by the default instance and blocking TCP port 1433.

There are several methods you can use to block ports. You can block these ports by using a firewall. However, unless you can be sure that there are no other routes into the network segment and that there are no malicious users that have access to the network segment, the recommendation is to block these ports directly on the server that hosts SQL Server. This can be accomplished by using Windows Firewall in Control Panel.

Configuring SQL Server database instances to listen on a nonstandard port

SQL Server provides the ability to reassign the ports that are used by the default instance and any named instances. In SQL Server 2005 and SQL Server 2008, you reassign ports by using SQL Server Configuration Manager.

Configuring SQL Server client aliases

In a server farm, all front-end Web servers and application servers are SQL Server client computers. If you block UDP port 1434 on the SQL Server computer, or you change the default port for the default instance, you must configure a SQL Server client alias on all servers that connect to the SQL Server computer.

To connect to an instance of SQL Server 2005 or SQL Server 2008, you install SQL Server client components on the target computer and then configure the SQL Server client alias by using SQL Server Configuration Manager. To install SQL Server client components, run Setup and select only the following client components to install:

  • Connectivity Components

  • Management Tools (includes SQL Server Configuration Manager)

For specific hardening steps for blocking the standard SQL ports, see Harden SQL Server for SharePoint environments (SharePoint Foundation 2010).

Service application communication

By default, communication between Web servers and service applications within a farm takes place by using HTTP with a binding to port 32843. When you publish a service application, you can select either HTTP or HTTPS with the following bindings:

  • HTTP binding: port 32843

  • HTTPS binding: port 32844

Additionally, third parties that develop service applications can implement a third choice:

  • net.tcp binding: port 32845

You can change the protocol and port binding for each service application. On the Service Applications page in Central Administration, select the service application, and then click Publish.

Communication between service applications and SQL Server takes place over the standard SQL Server ports or the ports that you configure for SQL Server communication.

File and Printer Sharing service requirements

Several core features depend on the File and Printer Sharing service and the corresponding protocols and ports. These include, but are not limited to, the following:

  • Search queries All search queries require the File and Printer Sharing service.

  • Crawling and indexing content To crawl content, servers that include crawl components send requests through the front-end Web server. The front-end Web server communicates with content databases directly and sends results back to the servers that include crawl components. This communication requires the File and Printer Sharing service.

The File and Printer Sharing service requires the use of named pipes. Named pipes can communicate by using either direct-hosted SMB or NetBT protocols. For a secure environment, direct-hosted SMB is recommended instead of NetBT. The hardening recommendations provided in this article assume that SMB is used.

The following table describes the hardening requirements that are introduced by the dependency on the File and Printer Sharing service.

Category Requirements Notes

Services

File and Printer Sharing

Requires the use of named pipes.

Protocols

Named pipes that use direct-hosted SMB

Disable NetBT

Named pipes can use NetBT instead of direct-hosted SMB. However, NetBT is not considered as secure as direct-hosted SMB.

Ports

Either of the following:

  • Direct-hosted SMB (TCP/UDP 445) — recommended

  • NetBT (TCP/UDP ports 137, 138, 139)

Disable NetBT (ports 137, 138, and 139) if it is not being used

For more information about how to disable NetBT, see the Microsoft Knowledge Base article 204279, Direct hosting of SMB over TCP/IP (http://go.microsoft.com/fwlink/p/?LinkId=76143).

Service requirements for e-mail integration

E-mail integration requires the use of two services:

  • SMTP service

  • Microsoft SharePoint Directory Management service

SMTP service

E-mail integration requires the use of the Simple Mail Transfer Protocol (SMTP) service on at least one of the front-end Web servers in the server farm. The SMTP service is required for incoming e-mail. For outgoing e-mail, you can either use the SMTP service or route outgoing email through a dedicated e-mail server in your organization, such as a Microsoft Exchange Server computer.

Microsoft SharePoint Directory Management service

SharePoint 2010 Products include an internal service, the Microsoft SharePoint Directory Management Service, for creating e-mail distribution groups. When you configure e-mail integration, you have the option to enable the Directory Management Service feature, which lets users create distribution lists. When users create a SharePoint group and they select the option to create a distribution list, the Microsoft SharePoint Directory Management Service creates the corresponding Active Directory distribution list in the Active Directory environment.

In security-hardened environments, the recommendation is to restrict access to the Microsoft SharePoint Directory Management Service by securing the file associated with this service, which is SharePointEmailws.asmx. For example, you might allow access to this file by the server farm account only.

Additionally, this service requires permissions in the Active Directory environment to create Active Directory distribution list objects. The recommendation is to set up a separate organizational unit (OU) in Active Directory for SharePoint 2010 Products objects. Only this OU should allow write access to the account that is used by the Microsoft SharePoint Directory Management Service.

SharePoint 2010 Products services

Do not disable services that are installed by SharePoint 2010 Products (listed in the snapshot previously).

If your environment disallows services that run as a local system, you can consider disabling the SharePoint 2010 Administration service only if you are aware of the consequences and can work around them. This service is a Win32 service that runs as a local system.

This service is used by the SharePoint 2010 Timer service to perform actions that require administrative permissions on the server, such as creating Internet Information Services (IIS) Web sites, deploying code, and stopping and starting services. If you disable this service, you cannot complete deployment-related tasks from the Central Administration site. You must use Windows PowerShell to run the Start-SPAdminJob cmdlet (or use the Stsadm.exe command-line tool to run the execadmsvcjobs operation) to complete multiple-server deployments for SharePoint 2010 Products and to run other deployment-related tasks.

Web.config file

The .NET Framework, and ASP.NET in particular, use XML-formatted configuration files to configure applications. The .NET Framework relies on configuration files to define configuration options. The configuration files are text-based XML files. Multiple configuration files can, and typically do, exist on a single system.

System-wide configuration settings for the .NET Framework are defined in the Machine.config file. The Machine.config file is located in the %SystemRoot%\Microsoft.NET\Framework\%VersionNumber%\CONFIG\ folder. The default settings that are contained in the Machine.config file can be modified to affect the behavior of applications that use the .NET Framework on the whole system.

You can change the ASP.NET configuration settings for a single application if you create a Web.config file in the root folder of the application. When you do this, the settings in the Web.config file override the settings in the Machine.config file.

When you extend a Web application by using Central Administration, SharePoint 2010 Products automatically create a Web.config file for the Web application.

The Web server and application server snapshot presented earlier in this article lists recommendations for configuring Web.config files. These recommendations are intended to be applied to each Web.config file that is created, including the Web.config file for the Central Administration site.

For more information about ASP.NET configuration files and editing a Web.config file, see ASP.NET Configuration (http://go.microsoft.com/fwlink/p/?LinkID=73257).

See Also

Other Resources

Resource Center: Security and Authentication for SharePoint Foundation 2010


Plan automatic password change (SharePoint Foundation 2010)
See Also

To simplify password management, the automatic password change feature enables you to update and deploy passwords without having to perform manual password update tasks across multiple accounts, services, and Web applications. You can configure the automatic password change feature to determine if a password is about to expire and reset the password using a long, cryptographically-strong random string. To implement the automatic password change feature, you have to configure managed accounts.

In this article:

  • Configuring managed accounts

  • Resetting passwords automatically on a schedule

  • Detecting password expiration

  • Resetting the account password immediately

  • Synchronizing SharePoint Foundation account passwords with Active Directory Domain Services

  • Resetting all passwords immediately

  • Credential change process

Configuring managed accounts

Microsoft SharePoint Foundation 2010 supports the creation of managed accounts to improve security and ensure application isolation. Using managed accounts, you can configure the automatic password change feature to deploy passwords across all services in the farm. You can configure SharePoint Web applications and services, running on application servers in a SharePoint farm, to use different domain accounts. You can create multiple accounts in Active Directory Domain Services (AD DS), and then register each of these accounts in SharePoint Foundation 2010. You can map managed accounts to various services and Web applications in the farm.

Resetting passwords automatically on a schedule

Prior to the implementation of the automatic password change feature, updating passwords required resetting each account password in AD DS and then manually updating account passwords on all of the services running on all the computers in the farm. To do this, you had to run the Stsadm command-line tool or use the SharePoint Central Administration Web application. Using the automatic password change feature, you can now register managed accounts and enable SharePoint Foundation 2010 to control account passwords. Users have to be notified about planned password changes and related service interruptions, but the accounts used by a SharePoint farm, Web applications, and various services can be automatically reset and deployed within the farm as necessary, based on individually configured password reset schedules.

Detecting password expiration

IT departments typically impose a policy requiring that all domain account passwords be reset on a regular basis, for example, every 60 days. SharePoint Foundation 2010 can be configured to detect imminent password expiration, and send an e-mail notification to a designated administrator. Even without administrator intervention, SharePoint Foundation 2010 can be configured to generate and reset passwords automatically. The automatic password reset schedule is also configurable to ensure that the impact of possible service interruptions during a password reset will be minimal.

Resetting the account password immediately

You can always override any automatic password reset schedule and force an immediate service account password reset, using a specific password value. In this scenario, the password for the service account can also be changed in AD DS by SharePoint Foundation 2010. The new password is then immediately propagated to other servers in the farm.

Synchronizing SharePoint Foundation account passwords with Active Directory Domain Services

If AD DS and SharePoint Foundation 2010 account passwords are not synchronized, services in the SharePoint farm will not start. If an Active Directory administrator changes an Active Directory account password without coordinating the password change with a SharePoint administrator, there is a risk of service interruptions. In this scenario, a SharePoint administrator can immediately reset the password from the Account Management page using the password value that was changed in AD DS. The password is updated and immediately propagated to the other servers in the SharePoint farm.

Resetting all passwords immediately

If an administrator suddenly leaves your organization, or if the service account passwords need to be immediately reset for any other reason, you can quickly create a Windows PowerShell script that calls the password change cmdlets. You can use the script to generate new random passwords and deploy the new passwords immediately.

Credential change process

When SharePoint Foundation 2010 changes the credentials for a managed account, the credential change process will occur on one server in the farm. Each server in the farm will be notified that the credentials are about to change and servers can perform critical pre-change actions, if necessary. If the account password has not yet been changed, then SharePoint Foundation 2010 will attempt to change the password using either a manually entered password, or a long, cryptographically-strong random string. The complexity settings will be queried from the appropriate policy (network or local), and the generated password will be equivalent to the detected settings. SharePoint Foundation 2010 will attempt to commit a password change. If it is unable to commit the password change, it will retry, using a new sequence, for a specified number of times. If the account password update process succeeds, it will proceed to the next dependent service, where it will again attempt to commit a password change. If it does not ultimately succeed, each dependent service will be notified that they can resume normal activity. Either success in committing a password change or failure to commit will result in the generation of an automated password change status notification that will be sent by e-mail to farm administrators.

See Also

Concepts

Configure automatic password change (SharePoint Foundation 2010)

Other Resources

Resource Center: Security and Authentication for SharePoint Foundation 2010


SQL Server and storage (SharePoint Foundation 2010)

This section describes how to plan for Microsoft SQL Server and storage configuration for Microsoft SharePoint Foundation 2010.

In this section:

  • Overview of SQL Server in a SharePoint environment (SharePoint Foundation 2010)

    This article describes the relationship between SharePoint Foundation 2010 and supported versions of SQL Server. It also describes how you can interact with the databases, and introduces ways of using the reporting and business intelligence (BI) features of SQL Server with SharePoint Foundation 2010.

  • Overview of RBS (SharePoint Foundation 2010)

    This article describes how SharePoint Foundation 2010 works with remote BLOB storage.

  • Plan for RBS (SharePoint Foundation 2010)

    This article describes the factors to consider when moving to a remote BLOB storage solution.

  • Remote BLOB Storage in SharePoint Foundation 2010 (video)

    This video, presented by Bill Baer, explains the basic concepts of Remote BLOB Storage (RBS) in SharePoint Foundation 2010.


Overview of SQL Server in a SharePoint environment (SharePoint Foundation 2010)

Published: August 27, 2010

This article describes the relationship between Microsoft SharePoint Foundation 2010 and supported versions of Microsoft SQL Server. It also describes how you can interact with the databases, and it introduces ways of using the reporting and business intelligence (BI) features of SQL Server with SharePoint Foundation 2010.

For more information about the supported versions of SQL Server, see Hardware and software requirements (SharePoint Foundation 2010).

In this article:

  • SharePoint 2010 Products and the SQL Server database engine

  • SQL Server as a data platform for business intelligence in SharePoint 2010 Products

SharePoint 2010 Products and the SQL Server database engine

SharePoint Foundation 2010 is an application that is built on the SQL Server database engine. Most content and settings in SharePoint Foundation 2010 are stored in relational databases. SharePoint Foundation 2010 uses the following kinds of databases:

  • Configuration The Configuration database and Central Administration content database are called configuration databases. They contain data about farm settings such as the databases used, Internet Information Services (IIS) Web sites or web applications, solutions, Web Part packages, site templates, default quota, and blocked file types. A farm can only have one set of configuration databases.

  • Content Content databases store all site content: site documents, such as files in document libraries, list data; Web Part properties; and user names and rights. All the data for a specific site resides in one content database. Each Web application can contain many content databases. Each site collection can be associated with only one content database, although a content database can be associated with many site collections.

  • Service application Service application databases store data for use by a service application. The databases for service applications vary significantly in what they are used for.

For a full list of all of the databases that support SharePoint Foundation 2010, see Database types and descriptions (SharePoint Server 2010) Database types and descriptions (SharePoint Foundation 2010).

Working with the SQL Server databases that support SharePoint 2010 Products

The SQL Server databases that support SharePoint Foundation 2010 can be created either by SharePoint Foundation 2010, or by a database administrator. For more information, see Deploy by using DBA-created databases (SharePoint Foundation 2010).

Microsoft does not support directly querying or modifying the databases that support SharePoint Foundation 2010, except for the Usage and Health Data Collection service application database, which can be queried directly and can have its schema added to.

The SQL Server databases that support SharePoint Foundation 2010 are subject to sizing limitations and to configuration recommendations that are not standard for SQL Server.

SQL Server as a data platform for business intelligence in SharePoint 2010 Products

SharePoint Foundation 2010 can be used with SQL Server BI tools to analyze and display BI data in meaningful ways. SQL Server provides the primary data infrastructure and business intelligence platform that gives report authors and business users trusted, scalable, and secure data.

The following sections describe the technologies and features in SQL Server that support business intelligence functionality and features in SharePoint Foundation 2010.

SQL Server database engine

The SQL Server database engine is the core service for storing, processing, and securing data. BI data can be collected from the SQL Server database engine. For more information, see SQL Server Database Engine (http://go.microsoft.com/fwlink/p/?LinkId=199540).

SQL Server Analysis Services (SSAS): multi-dimensional data

Microsoft SQL Server Analysis Services (SSAS) multidimensional data enables you to design, create, and manage multidimensional structures that contain detail and aggregated data from multiple data sources. A cube wizard is available in SQL Server 2008 R2 that simplifies how you can create cubes. Dimensional data or cube data is a prototypical data source for the types of analysis that can be done by using the business intelligence-related service applications in SharePoint Foundation 2010. For more information, see SQL Server Analysis Services - Multidimensional Data (http://go.microsoft.com/fwlink/p/?LinkId=199541).

SQL Server Analysis Services: data mining

SQL Server Analysis Services data mining tools provide a set of industry-standard data mining algorithms and other tools that help you discover trends and patterns in your data. The following Excel add-ins help you perform predictive analysis:

  • Table Analysis Tools for Excel provide easy-to-use tools that take advantage of Analysis Services Data Mining to perform powerful analytics on spreadsheet data. For more information, see SQL Server Analysis Services - Data Mining (http://go.microsoft.com/fwlink/p/?LinkId=199543).

  • Data Mining Client for Excel lets users build, test, and query data mining models within Microsoft Office Excel 2007 by using either worksheet data or external data available through Analysis Services.

Note:

To enable add-ins, you must have a connection to the server.

SQL Server Reporting Services (SSRS)

Microsoft SQL Server Reporting Services (SSRS) and SharePoint Foundation 2010 are easily integrated. SQL Server Reporting Services has a full range of tools with which you can create, deploy, and manage reports for your organization. It also has features that enable you to extend and customize your reporting functionality.

The available functionality includes:

  • Creating reports with Report Builder 3, one of the SQL Server Reporting Services authoring tools, which you can launch directly from SharePoint Foundation 2010.

  • Publishing SSRS reports in SharePoint Foundation 2010.

    You can publish report server content types to a SharePoint library and then view and manage those documents from a SharePoint site.

For more information about SSRS, see SQL Server Reporting Services (http://go.microsoft.com/fwlink/p/?LinkId=199545). For more information about how to install the different integration modes, see Overview of SQL Server Reporting Services reports in SharePoint.

SQL Server Integration Services (SSIS)

Microsoft SQL Server Integration Services (SSIS) provides rich data integration and data transformation solutions. You can create a repeatable extract, transform, and load (ETL) process to automate moving data from sources such as XML data files, flat files, or relational data sources to one or more destinations. If data comes from disparate sources and is not mined or cleansed for the benefits that are provided in BI applications, SQL Server Integration Services helps prepare the data. For more information, see SQL Server Integration Services (http://go.microsoft.com/fwlink/p/?LinkId=199546).

Business Intelligence Development Studio (BIDS)

Microsoft Business Intelligence Development Studio (BIDS) provides intuitive wizards for building integration, reporting, and analytic solutions in a unified environment. BIDS supports the complete development life cycle of developing, testing, and deploying solutions and reports. BIDS is based on the Visual Studio 2005 development environment but customizes it with the SQL Server services-specific extensions and project types for reports, ETL data flows, OLAP cubes, and data mining structure.

PowerPivot for Excel and PowerPivot for SharePoint

PowerPivot is an add-in that enables users to create self-service BI solutions. It also facilitates sharing and collaboration on those solutions in a SharePoint Foundation 2010 environment. PowerPivot also enables IT organizations to increase operational efficiencies through Microsoft SQL Server 2008 management tools. Components of PowerPivot include the following:

  • PowerPivot for Excel 2010 is a data analysis add-in that delivers computational power directly to Microsoft Excel 2010. PowerPivot for Excel (formerly known as "Gemini") lets users analyze large quantities of data, and its integration with SharePoint Foundation 2010 helps IT departments monitor and manage how users collaborate. The add-in removes the one-million-row limit for worksheets and provides rapid calculations for large data sets. For more information, see PowerPivot Overview (http://go.microsoft.com/fwlink/p/?LinkId=199547).

  • PowerPivot for SharePoint 2010 extends SharePoint Foundation 2010 and Excel Services to add server-side processing, collaboration, and document management support for the PowerPivot workbooks that you publish to SharePoint sites. For more information, see PowerPivot for SharePoint (http://go.microsoft.com/fwlink/p/?LinkId=199547).

Master Data Services

SQL Server Master Data Services lets you centrally manage important data assets companywide and across diverse systems to provide more trusted data to your BI applications. Master Data Services helps you create a master data hub that includes a thin-client data management application for a data steward. The application can also apply workflow to assigned owners, apply extensible business rules to safeguard data quality, and apply hierarchy and attribute management strategies. For more information, see Master Data Services (http://go.microsoft.com/fwlink/p/?LinkId=199548).

StreamInsight and complex event processing

Microsoft StreamInsight is a new feature in SQL Server 2008 R2 that provides a powerful platform for developing and deploying complex event processing (CEP) applications. CEP is a technology for processing streams of events with high-throughput and low-latency. StreamInsight lets you analyze data without first storing it, and helps you monitor data from multiple sources to detect patterns, trends, and exceptions almost instantly. The ability to monitor, analyze, and act on data in motion in an event-driven manner provides significant opportunity to make more rapid, informed business decisions. For more information, see Microsoft StreamInsight (http://go.microsoft.com/fwlink/p/?LinkId=199549).

Related content

Resource center | Business Continuity Management for SharePoint Server 2010 Business Intelligence in SharePoint Server 2010 (http://go.microsoft.com/fwlink/p/?LinkId=199757) Microsoft Business Intelligence (http://go.microsoft.com/fwlink/p/?LinkId=199758) SQL Server Tech Center (http://go.microsoft.com/fwlink/p/?LinkId=199760) SQL Server Analysis Services Multidimensional Data (SSAS) (http://go.microsoft.com/fwlink/p/?LinkId=199761) SQL Server Analysis Services (SSAS) Data Mining (http://go.microsoft.com/fwlink/p/?LinkId=199762)
Developer content | SharePoint Developer Center (http://go.microsoft.com/fwlink/p/?LinkID=159918) SQL Server Developer Center (http://go.microsoft.com/fwlink/p/?LinkId=199764) SQL Server Database Engine (http://go.microsoft.com/fwlink/p/?LinkId=199765) SQL Server Reporting Services (SSRS) (http://go.microsoft.com/fwlink/p/?LinkId=199766) SQL Server StreamInsight (http://go.microsoft.com/fwlink/p/?LinkId=199767)


Overview of RBS (SharePoint Foundation 2010)
See Also

This article describes how to use Microsoft SharePoint Foundation 2010 together with Remote BLOB Storage (RBS) and Microsoft SQL Server to optimize database storage resources.

Before you implement RBS, we highly recommend that you evaluate its potential costs and benefits. For more information and recommendations about how to use RBS in a SharePoint Foundation 2010 installation, see Plan for RBS (SharePoint Foundation 2010).

Note:

Unless otherwise specified, the information in this article is specific to RBS using the FILESTREAM provider. For guidance specific to another provider, contact the provider manufacturer.

In this article:

  • Introduction to RBS

  • RBS providers

  • Using RBS together with SharePoint 2010 Products

Introduction to RBS

In SharePoint Foundation 2010, a binary large object (BLOB) is a large block of data stored in a database that is known by its size and location instead of by its structure — for example a Microsoft Office 2010 document or a video file. By default, these BLOBs, also known as unstructured data, are stored directly in the SharePoint content database along with the associated metadata, or structured data. Because these BLOBs can be very large, it might be better to store BLOBs outside the content database. BLOBs are immutable. Accordingly, a new copy of the BLOB must be stored for each version of that BLOB. Because of this, as a database's usage increases, the total size of its BLOB data can expand quickly and grow larger than the total size of the document metadata and other structured data that is stored in the database. BLOB data can consume lots of space and uses server resources that are optimized for database access patterns. Therefore, it can be helpful to move BLOB data out of the SQL Server database, and onto commodity or content addressable storage. To do this, you can use RBS.

RBS is a Microsoft SQL Server library API set that is incorporated as an add-on feature pack for Microsoft SQL Server 2008 R2, SQL Server 2008 or Microsoft SQL Server 2008 R2 Express. The RBS feature enables applications, such as SharePoint Foundation 2010, to store BLOBs in a location outside the content databases. Storing the BLOBs externally can reduce how much SQL Server database storage space is required. The metadata for each BLOB is stored in the SQL Server database and the BLOB is stored in the RBS store.

SharePoint Foundation 2010 uses the RBS feature to store BLOBs outside of the content database. SQL Server and SharePoint Foundation 2010 jointly manage the data integrity between the database records and contents of the RBS external store on a per-database basis.

RBS is composed of the following components:

  • RBS client library

    An RBS client library consists of a managed library that coordinates the BLOB storage with Microsoft SharePoint Foundation, SQL Server 2008 Express, and RBS provider components.

  • Remote BLOB Storage provider

    An RBS provider consists of a managed library and, optionally, a set of native libraries that communicate with the BLOB store.

    An example of an RBS provider is the SQL FILESTREAM provider. The SQL FILESTREAM provider is a feature of SQL Server 2008 Express that enables storage of and efficient access to BLOB data by using a combination of SQL Server 2008 Express and the NTFS file system. For more information about FILESTREAM, see FILESTREAM Overview (http://go.microsoft.com/fwlink/p/?LinkID=166020&clcid=0x409) and FILESTREAM Storage in SQL Server 2008 (http://go.microsoft.com/fwlink/p/?LinkID=165746&clcid=0x409).

  • BLOB store

    A BLOB store is an entity that is used to store BLOB data. This can be a content-addressable storage (CAS) solution, a file server that supports Server Message Block (SMB), or a SQL Server database.

RBS providers

RBS uses a provider to connect to any dedicated BLOB store that uses the RBS APIs. SharePoint Foundation 2010 supports a BLOB storage implementation that accesses BLOB data by using the RBS APIs through such a provider. There are two kinds of RBS providers, local and remote.

The location in which an RBS provider stores the BLOB data depends on the provider that you use. In the case of the FILESTREAM provider, the data is not stored in the .mdf file. Instead, it is stored in another folder that is associated with the database.

Local RBS provider

A local provider stores the BLOBS outside the database but on the same server that is running SQL Server. You can conserve resources by using the local RBS FILESTREAM provider to put the extracted BLOB data on a different (that is, less resource-intensive) local disk. Because the BLOBs are stored in the same Filegroup as the metadata, SharePoint Server 2010 features, such as backup and restore in Central Administration, can be used.

The RBS FILESTREAM provider is available through the SQL Server Remote BLOB Store installation package from the Feature Pack for Microsoft SQL Server 2008 R2. The RBS FILESTREAM provider uses the SQL Server FILESTREAM feature to store BLOBs in an additional resource that is attached to the same database and stored locally on the server. The FILESTREAM feature manages BLOBs in an SQL database by using the underlying NTFS file system.

Important:

The local FILESTREAM provider is supported only when it is used on local hard disk drives or an attached Internet Small Computer System Interface (iSCSI) device. You cannot use the local RBS FILESTREAM provider on remote storage devices such as network attached storage (NAS).

Remote RBS provider

A remote RBS provider stores the BLOBs on a separate server. This is typically on a separate volume on the same network as the database server.

Because the BLOBs are not stored in the same Filegroup with the metadata, some SharePoint Foundation 2010 features — for example, backup and restore in Central Administration — cannot be used with remote RBS providers. The metadata and the BLOBs must be managed separately. For more information about what features can be used with the provider, contact the provider manufacturer.

Using RBS together with SharePoint 2010 Products

SharePoint Foundation 2010 supports the FILESTREAM provider that is included in the SQL Server Remote BLOB Store installation package from the Feature Pack for SQL Server Remote BLOB Store installation package from the Feature Pack for SQL Server 2008 R2. This version of RBS is available at Microsoft® SQL Server® 2008 R2 Feature Pack (http://go.microsoft.com/fwlink/p/?LinkID=177388). Be aware that this is the only version of RBS that is supported by SharePoint Foundation 2010. Earlier versions are not supported. Third-party RBS providers can also be used with the RBS APIs to create a BLOB storage solution that is compatible with SharePoint Foundation 2010.

In SharePoint Foundation 2010, site collection backup and restore and site import or export will download the file contents and upload them back to the server regardless of which RBS provider is being used. This process is known as a deep copy. However, the FILESTREAM provider is the only provider that is currently supported for SharePoint 2010 Products farm database backup and restore operations.

To use RBS, you must install an RBS provider on each server where SharePoint Foundation 2010 is installed and on each database server in the topology. The provider includes a set of DLLs that implement methods for the RBS APIs and perform the actual operation of externalizing the BLOBs.

To run RBS on a remote server, you must be running SQL Server 2008 R2 Enterprise on the server that is running SQL Server where the metadata is stored in the database.

If you plan to store BLOB data in an RBS store that differs from your SharePoint Foundation 2010 content databases, you must run SQL Server 2008 with SP1 and Cumulative Update 2. This is true for all RBS providers.

The FILESTREAM provider that is recommended for upgrading from stand-alone installations of Windows SharePoint Services 3.0 that have content databases that are over 4 gigabytes (GB) to SharePoint Foundation 2010 associates data locally with the current content database, and does not require SQL Server Enterprise.

Important:

Although RBS can be used to store BLOB data externally, accessing or modifying those BLOBs is not supported using any tool or product other than Microsoft SharePoint 2010 Products. All access must occur by using SharePoint 2010 Products only.

In a stand-alone installation of Windows SharePoint Services 3.0, content databases are stored in Windows Internal Database and have no size limitations. Conversely, in SharePoint Foundation 2010, the content databases are stored in SQL Server 2008 Express and have a maximum size of 4 GB per database.

SQL Server 2008 R2 Express supports databases that are as large as 10 GB. If your installation includes databases that are larger than 4 GB but smaller than 10 GB, we recommend that you upgrade to SQL Server 2008 R2 Express for content database storage. SQL Server 2008 R2 Express is a free upgrade that you can download and install from Microsoft® SQL Server® 2008 R2 Feature Pack (http://go.microsoft.com/fwlink/p/?LinkID=177388).

If you are upgrading from Windows SharePoint Services 3.0 and have content databases that are 10 GB or larger, you must implement RBS. Or, you can use Microsoft SQL Server 2008 Standard or Microsoft SQL Server 2008 Enterprise.

For additional guidance about how to upgrade from Windows SharePoint Services 3.0 to SharePoint Foundation 2010 together with RBS, see Upgrading from a stand-alone installation of Windows SharePoint Services 3.0 to SharePoint Foundation 2010 when content databases exceed 4 GB (RBS).

See Also

Other Resources

FILESTREAM Overview
FILESTREAM Storage in SQL Server 2008
Remote BLOB Store Provider Library Implementation Specification


Plan for RBS (SharePoint Foundation 2010)
See Also

This article provides information to help you decide whether to use Remote BLOB Storage (RBS) in a Microsoft SharePoint Foundation 2010 environment, and if you use RBS, how to plan the RBS deployment.

In SharePoint Foundation 2010, a binary large object (BLOB) is a file, such as a Microsoft Office 2010 document or a video file. By default, these BLOBs, also named unstructured data, are stored inline in the SharePoint content database together with the metadata, or structured data. Because BLOBs can be very large, it can be helpful to move BLOB data out of the SQL Server database, and onto commodity or content addressable storage. To do this, you can use RBS.

Note:

Unless otherwise specified, the information in this article is specific to RBS using the FILESTREAM provider. For guidance specific to another provider, contact the provider manufacturer.

For more information about RBS including information about RBS providers, we highly recommend that you see Overview of RBS (SharePoint Foundation 2010).

In this article:

  • Implications of using RBS over the IT life cycle

  • Implications of using RBS in different site scenarios

  • Limitations of RBS

  • Benefits and costs of using RBS

  • Benefits and costs of using RBS with the FILESTREAM provider

  • Most optimal use of RBS

  • Least optimal use of RBS

  • Evaluate provider options

Implications of using RBS over the IT life cycle

You should evaluate the implications of using RBS for the whole life cycle of the environment. What might be a good idea for normal operations, such as having large BLOB stores, might present challenges during backup and restore or during an upgrade. By evaluating the effects of using RBS and BLOB store size on the whole life cycle, you can avoid potential problems later.

For example, using a remote RBS provider will require increased IT operations complexity and some cost increases. This is because the content database and the BLOB store must be backed up in synchronization to maintain references consistency.

Another example is that in some cases upgrade operations will enumerate and possibly change each BLOB regardless of where the BLOBs are stored.

Setup

Using RBS can add some complexity to setup because you must install and configure the RBS provider on all Web servers in the farm. For more information about how to set up RBS, see Install and configure RBS (SharePoint Foundation 2010).

Normal operations

You should consider the average file size and the kind of file access during normal operations. Although using RBS with files larger than 1 MB can improve I/O and processor performance, using RBS with files smaller than 256 KB might decrease overall performance. Storing the BLOBs inline in the content database is more efficient with smaller files. For more information about performance of RBS, see Managing Unstructured Data with SQL Server 2008 (http://go.microsoft.com/fwlink/p/?LinkId=223909).

You should also consider how BLOB content will be used. If users will most frequently read the content but not revise it, RBS can provide performance gains. However, if users will frequently revise the content, using RBS will decrease performance. This is because extensive versioning will cause significant growth in both the metadata in the content database and the size of the BLOB store.

You should weigh any storage cost benefits against potential operational cost increases.

Monitoring and optimization

Using RBS also adds some operations overhead because there are several performance counters that are added to monitor RBS. Several options are available to tune RBS performance. For more information, see Maintain RBS (SharePoint Foundation 2010).

Database maintenance

You can achieve better efficiency and speed in database index defragmentation and statistics operations when you use RBS. Also regular consistency checks, such as DBCC checks, are also significantly faster when you use RBS.

However, regular database maintenance will become more complex because you must configure and use the RBS Maintainer to maintain link-level consistency between the metadata and the BLOB store and to perform cleanup of orphaned BLOBs. For more information, see Maintain RBS (SharePoint Foundation 2010).

Backup and restore

If you use the local FILESTREAM provider with RBS, you can use built-in SharePoint tools to back up and restore. These operations back up and restore both the metadata and the BLOB store. If you use the remote RBS provider, you must carefully coordinate the backup and restore processes. This is because the backup and restore processes involve both the metadata and the BLOB store. You should take this into account when planning the RBS configuration. Not all RBS providers support backup and restore of BLOB data. You must check with the manufacturer of the provider to confirm support.

You cannot use Microsoft System Center Data Protection Manager to back up and restore content that is stored in the RBS stores.

Upgrade and update

Under some circumstances, an upgrade, or even applying software updates, can enumerate and iterate through each object to include BLOB data regardless of where that data is stored. Therefore, upgrade operations will be similar in duration whether inline or remote BLOBs are used.

Implications of using RBS in different site scenarios

You should evaluate the implications of using RBS in different site scenarios. Because RBS was created to solve specific problems, RBS might not perform equally well in all scenarios. The scenarios in the following sections are examples.

Team sites

If you are considering using RBS with team sites or other highly-collaborative sites, and the sites typically contain documents smaller than 256 KB, you will not see significant gains by using RBS. Moreover, by using versioning, you can cause the content database to grow very quickly if documents are being revised frequently.

Important:

The use of RBS-enabled content databases larger than 4TB with collaboration sites is not supported. You cannot upload any document larger than 2GB to an RBS-enabled content database. For more information about RBS limits, see the "Content databases" section is SharePoint Server 2010 capacity management: Software boundaries and limits.

Record centers

RBS works well for record centers and other archive sites. Because these sites are mostly read-only and do not use versioning, you can store lots of data in the RBS store.

Limitations of RBS

Each RBS provider will have different capabilities and limitations. The FILESTREAM provider has the following limitations:

  • RBS has specific content database size limitations for specific scenarios. For more information about these limitations, see the "Content database limits" section in SharePoint Server 2010 capacity management: Software boundaries and limits.

  • Encryption is not supported on BLOBs, even if Transparent Data Encryption is enabled.

  • RBS does not support using data compression.

  • Support for database mirroring and log shipping is altered. For more information, see Evaluate provider options later in this article.

To determine the capabilities and limitations of third-party providers, contact the provider manufacturer.

Benefits and costs of using RBS

This section discusses the benefits and costs of using RBS. These benefits and costs usually apply regardless of which provider you use. For more detailed information about how to use the FILESTREAM RBS provider, see Benefits and costs of using RBS with the FILESTREAM provider later in this article. For more detailed information about how to use third-party RBS providers, contact the provider manufacturer.

Benefits

RBS was designed to move the storage of BLOBs from databases on database servers to directories on commodity storage solutions. Therefore, under the specific environments that RBS was intended to be used in, you can experience performance or cost benefits. By using lower-priced storage instead of more expensive storage on a databases server, you can save on costs. RBS saves storage resources when there are fewer large BLOBs. When there are many smaller files, there is no benefit.

Costs

RBS will increase operational costs because the IT staff must perform additional tasks when they back up or restore the content. Large RBS stores can slow down tasks such as backup or restore, updating the environment, upgrading to a newer version of SharePoint Foundation, or migrating the SharePoint sites to another environment. These costs should be considered when you evaluate whether to use RBS.

Benefits and costs of using RBS with the FILESTREAM provider

This section discusses the benefits and costs of using the FILESTREAM provider. These benefits and costs might not be relevant for another provider. For information about how to use third-party RBS providers, contact the provider manufacturer.

Benefits

Microsoft currently supports only the FILESTREAM RBS provider with SharePoint Server 2010. When you use this provider, the backup and restore features in SharePoint Server 2010 also back up and restore the BLOBs and the structured data in the content database without requiring you to do additional work. The FILESTREAM provider also supports Internet Small Computer System Interface (iSCSI) connected storage devices.

In the case of SharePoint Foundation 2010, consider implementing RBS if you want to remain on a free version of Microsoft SQL Server, and you estimate that the databases will be larger than 4 GB. If you do not expect that the content databases will grow larger than 4 GB, we do not recommend that you implement RBS.

Note:

If you are upgrading from Windows SharePoint Services 3.0 to SharePoint Foundation 2010, see the following article for additional upgrade advice: Upgrading from a stand-alone installation of Windows SharePoint Services 3.0 to SharePoint Foundation 2010 when content databases exceed 4 GB (RBS).

By default, Microsoft SharePoint Foundation 2010 is installed together with Microsoft SQL Server 2008 Express. SQL Server 2008 Express has a 4 GB size limit for any database. You can immediately extend the supported size of the content databases by installing Microsoft SQL Server 2008 R2 Express, which supports databases up to 10 GB. SQL Server 2008 R2 Express is a free download that is available at http://go.microsoft.com/fwlink/p/?LinkID=189418.

The remainder of this section assumes that you will install SQL Server 2008 R2 Express to support SharePoint Foundation 2010 databases. In this case, if you expect that the content databases will be 10 GB or larger, consider the following options:

  • If the content databases will be up to 16 GB and you do not expect that they contain more than 10 GB of metadata, you should implement RBS. In this case, RBS lets you continue to use a free version of SQL Server. In making this recommendation, we assume that when you migrate a 16 GB content database to RBS, the metadata does not exceed 10 GB.

  • If the content databases are larger than 16 GB, you must purchase Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, or SQL Server 2005 with SP3 and Cumulative Update 3 to support the databases instead of remaining on a free version of SQL Server.

Costs

Using the FILESTREAM provider might increase operational costs because the IT staff must perform additional tasks. Large RBS stores can slow down tasks such as backup or restore, updating the environment, upgrading to a newer version of SharePoint Foundation, or migrating the SharePoint sites to another environment. These costs should be considered when you evaluate whether to use RBS.

Most optimal use of RBS

Because RBS is a solution created for a specific set of conditions, there is an optimal use of RBS in which the benefits outweigh the costs. The optimal environment for using RBS is an environment where the following is true:

  • You want to store fewer large BLOBs (256 KB or larger) for read-intensive or read-only access.

  • The resources on the computer that is running SQL Server might become a performance bottleneck.

  • The expense of high-cost drive space is greater than the expense of increased IT operations complexity that might be introduced by using RBS.

Least optimal use of RBS

RBS is not a good solution for all environments. The costs will outweigh the benefits most of the time. The least optimal environment for using RBS would be an environment where the following is true:

  • You want to store many small BLOBs (256 KB or less) for write-intensive access.

  • The resources on the computer that is running SQL Server are not a performance bottleneck.

  • The expense of increased IT operations complexity that might be introduced by using RBS is greater than high-cost drive space.

Under these conditions, even a content database less than 200 GB will produce a noticeable performance bottleneck as the small BLOBs are frequently accessed for writing. This occurs because the database contains the metadata for the BLOBs. As the metadata is changed, new rows are added to the table in the database. This can cause the table to quickly grow very large. Large tables can decrease performance.

Although the presence of many small BLOBs can decrease performance, the cost of storage is usually the most important consideration when you evaluate RBS. The predicted decrease in performance is usually an acceptable trade-off for the cost savings in storage hardware.

Evaluate provider options

RBS requires a provider that connects the RBS APIs and SQL Server. Microsoft SQL Server 2008 Express and Microsoft SQL Server 2008 R2 Express include the FILESTREAM provider.

Important:

RBS can be run on the local computer that is running Microsoft SQL Server 2008 R2, SQL Server 2008 or SQL Server 2008 R2 Express. To run RBS on a remote server, you must be running SQL Server 2008 R2 Enterprise. SharePoint Foundation 2010 requires you to use the version of RBS that is included with the SQL Server Remote BLOB Store installation package from the Feature Pack for Microsoft SQL Server 2008 R2. Earlier versions of RBS will not work with SharePoint Foundation 2010. In addition, RBS is not supported in SQL Server 2005.

BLOBs can be kept on commodity storage such as direct-attached storage (DAS) or network attached storage (NAS), as supported by the provider. The FILESTREAM provider is supported by SharePoint Foundation 2010 when it is used on local hard disk drives or iSCSI drives only. You cannot use RBS with FILESTREAM on remote storage devices, such as NAS.

The following table summarizes FILESTREAM benefits and limitations.

Operational requirement | With the FILESTREAM provider | Without the FILESTREAM provider
SQL Server integrated backup and recovery of the BLOB Store | Yes | Maybe 1
System Center Data Protection Manager (DPM) 2010 integrated backup and recovery of the BLOB Store | No | Maybe 1
Scripted migration to BLOBs | Yes | Yes
Supports mirroring | No | Yes
Log shipping | Yes | Yes, with provider implementation
Database snapshots | No2 | No2
Geo replication | Yes | No
Encryption | NTFS only | No
Local drives supported | Yes | Yes, with provider implementation
Network Attached Storage (NAS) | Only supported by SharePoint 2010 Products with iSCSI and if TTFB is less than 20ms. | Yes, with provider implementation
Direct Attached Storage (DAS) | Not supported by SharePoint 2010 Products | Yes, with provider implementation
iSCSI Drives supported | Yes | Yes, with provider implementation

1Only if the RBS provider that you are using does it.

2If the RBS provider that you are using does not support snapshots, you cannot use snapshots for content deployment or backup. The FILESTREAM provider does not support snapshots.

If the FILESTREAM provider is not practical for the environment, you can purchase a supported third-party provider. In this case, you should use the following criteria when you evaluate a provider:

  • Backup and restore capability

  • Tested disaster recovery

  • Deployment and data migration

  • Performance impact

  • Long-term administrative costs

Important:

We do not recommend that you develop a provider unless you are an independent software vendor (ISV) that has significant development experience in designing storage solutions.

See Also

Other Resources

Resource Center: SQL Server and SharePoint Server 2010 Databases


Remote BLOB Storage in SharePoint Foundation 2010 (video)
See Also

Published: June 28, 2011

This video explains the basic concepts of Remote BLOB Storage (RBS) in SharePoint 2010 Products. Presenter Bill Baer discusses the following topics:

  • Difference between unstructured and structured data

  • RBS storage considerations

  • RBS deployment considerations

  • Migration considerations

  • External BLOB migration considerations

  • Comparison of external BLOB storage and Remote BLOB storage technologies

Remote BLOB Storage in SharePoint Products 2010

Running time: 20:40

Play video Watch the "Remote BLOB storage with SharePoint 2010" video

Download video For an optimal viewing experience, download the "Remote BLOB storage with SharePoint 2010" video

Right-click the link, and then click Save Target As to download a copy. Clicking the link will open a .wmv file in the default video viewer for full-resolution viewing.

Related resources

Resource | Description
Install and configure RBS (SharePoint Foundation 2010) | This article describes how to install and configure Remote BLOB Storage (RBS) for a Microsoft SQL Server 2008 R2 Express database server that supports a Microsoft SharePoint Foundation 2010 farm.
Overview of RBS (SharePoint Foundation 2010) | This article describes how to use Microsoft SharePoint Foundation 2010 together with Remote BLOB Storage (RBS) and Microsoft SQL Server to optimize database storage resources.
Plan for RBS (SharePoint Foundation 2010) | This article provides information to help you decide whether to use Remote BLOB Storage (RBS) in a Microsoft SharePoint Foundation 2010 environment, and if you use RBS, how to plan the RBS deployment.
SharePoint Products Tech Center (http://technet.microsoft.com/en-us/sharepoint/default.aspx) | Find details about related technologies, downloads, and additional resources.

See Also

Other Resources

Video demos and training for SharePoint Server 2010


Plan for business continuity management (SharePoint Foundation 2010)

Business continuity management consists of the business decisions, processes, and tools you put in place in advance to handle crises. A crisis might affect your business only, or be part of a local, regional, or national event.

Features of Microsoft SharePoint Foundation 2010 are likely to be part of your business continuity management strategy, but your overall plan should be much more comprehensive and include the following elements:

  • Clearly documented procedures.

  • Offsite storage of key business records.

  • Clearly designated contacts.

  • Ongoing staff training, including practices and drills.

  • Offsite recovery mechanisms.

In this article:

  • Business continuity management capabilities

  • Service level agreements

Business continuity management capabilities

Microsoft SharePoint Foundation 2010 includes the following capabilities that support business continuity management.

  • Versioning Users can lose data by overwriting a document. With versioning, users can keep multiple versions of the same document in a document library. In the event of an unwanted change, an overwritten document, or document corruption, the previous version can easily be restored by the user. When versioning is enabled, users can recover their data themselves.

    For more information, see Plan to protect content by using recycle bins and versioning (SharePoint Foundation 2010).

  • Recycle Bin SharePoint Foundation 2010 includes a two-stage Recycle Bin. Users who have the appropriate permissions can use the first-stage Recycle Bin to recover documents, list items, lists, and document libraries that have been deleted from a site. Site collection administrators can use the second-stage Recycle Bin, also called the Site Collection Recycle Bin, to recover items that have been deleted from the first-stage Recycle Bin. When the first-stage Recycle Bin is enabled, users can recover their data themselves.

    For more information, see Plan to protect content by using recycle bins and versioning (SharePoint Foundation 2010).

  • Backup and recovery You can use Windows PowerShell cmdlets or the SharePoint Central Administration Web site to back up and recover farms, databases, Web applications, and site collections. There are also many external and third-party tools that you can use to back up and recover data. For more information, see Plan for backup and recovery (SharePoint Foundation 2010).

  • Availability No single feature provides availability within a SharePoint Foundation 2010 environment. You can choose among many approaches to improve availability, including the following:

    • Fault tolerance of components and the network.

    • Redundancy of server roles and servers within a farm.

    For more information about availability, see Plan for availability (SharePoint Foundation 2010).

  • Disaster recovery No single feature provides disaster recovery within a SharePoint Foundation 2010 environment. You can choose among many approaches to improve availability when a data center goes offline, including the following:

    • Offsite storage of backups, both within and outside your region.

    • Shipping images of servers to offsite locations.

    • Running multiple data centers, but serving data only through one, keeping the others available on standby.

    For more information about disaster recovery, see Plan for disaster recovery (SharePoint Foundation 2010).

Service level agreements

Business continuity management is a key area in which IT groups offer service level agreements (SLAs) to set expectations with customer groups. Many IT organizations offer various SLAs that are associated with different chargeback levels.

The following list describes common features of business continuity management SLAs:

  • Versioning

    • Whether offered.

    • Amount of space allocated.

  • Recycle Bins

    • Whether offered.

    • Amount of space allocated for the first-stage Recycle Bin and second-stage Recycle Bin.

    • Length of time that items are held before they are permanently deleted in each Recycle Bin.

    • Additional charges for recovering items that have been permanently deleted from the second-stage Recycle Bin.

  • Backup and recovery

    Backup and recovery SLAs usually identify objects and services that can be backed up and recovered, and the recovery time objective, recovery point objective, and recovery level objective for each. The SLA may also identify the available backup window for each object. For more information about backup and recovery SLAs, see Plan for backup and recovery (SharePoint Foundation 2010).

    • Recovery time objective (RTO) is the objective for the maximum time a data recovery process will take. It is determined by the amount of time the business can afford for the site or service to be unavailable.

    • Recovery point objective (RPO) is the objective for the maximum amount of time between the last available backup and any potential failure point. It is determined by how much data the business can afford to lose in the event of a failure.

    • Recovery level objective (RLO) is the objective that defines the granularity with which you must be able to recover data — whether you must be able to recover the entire farm, Web application, site collection, site, list or library, or item.

  • Availability

    For each component within a farm that is covered by an availability plan, an availability SLA may identify availability as a percentage of uptime, often expressed as the number of nines — that is, the percentage of time that a given system is active and working. For example, a system with a 99.999 uptime percentage is said to have five nines of availability.

    Note:

    When calculating availability, most organizations specifically exempt or add hours for planned maintenance activities.

    For more information, see Plan for availability (SharePoint Foundation 2010).

  • Disaster recovery

    For each component within a farm that is covered by a disaster recovery plan, an SLA may identify the recovery point objective and recovery time objective. Different recovery time objectives are often set for different circumstances, for example a local emergency versus a regional emergency.

    For more information, see Plan for disaster recovery (SharePoint Foundation 2010).

Related content

Resource center | Business Continuity Management for SharePoint Foundation 2010(http://go.microsoft.com/fwlink/p/?LinkId=201997)
IT Pro content | Plan for backup and recovery (SharePoint Foundation 2010) Backup and recovery overview (SharePoint Foundation 2010) Backup and recovery (SharePoint Foundation 2010) Plan to protect content by using recycle bins and versioning (SharePoint Foundation 2010) Plan for availability (SharePoint Foundation 2010) Availability configuration (SharePoint Foundation 2010) Plan for disaster recovery (SharePoint Foundation 2010)
Developer content | Data Protection and Recovery (http://go.microsoft.com/fwlink/p/?LinkId=199237)


Plan to protect content by using recycle bins and versioning (SharePoint Foundation 2010)
See Also

Plan to use recycle bins and versioning in an environment to help users protect and recover their data. Recycle bins and versioning are key components of a business continuity strategy.

Recycle bins Users can use recycle bins to retrieve deleted objects. Microsoft SharePoint Foundation 2010 supports two stages of recycle bins, the first-stage Recycle Bin and the Site Collection — also called the second-stage — Recycle Bin. When Recycle Bins are enabled, users can restore items that are in them, including deleted files, documents, list items, lists, and document libraries.

Versioning Users can use versioning to help prevent data loss that is caused by overwriting a document. When a site owner turns on versioning in a document library or a list, the library or list keeps multiple copies of a document, item, or file. In the event of an unwanted change, an overwritten file, or document corruption, the previous version can be easily restored by the user.

In this article:

  • Protecting content by using recycle bins

  • Protecting content by using versioning

Protecting content by using recycle bins

SharePoint Foundation 2010 supports two stages of recycle bins, the first-stage Recycle Bin and the Site Collection, or second-stage, Recycle Bin. The recycle bins are enabled and configured at the Web application level. The recycle bins collect deleted documents and list items. When a list item is deleted, any attachments to the item are also deleted and can be restored from the Recycle Bin.

The Recycle Bins can contain multiple copies of a document that each have the same file name and source. These documents cannot be restored over an existing copy of a document. The Recycle Bins cannot be used to recover previous versions or accidental overwrites of documents — you must use versioning to enable this functionality.

The following table describes how an item is deleted and recovered from the first-stage Recycle Bin and the second-stage Recycle Bin.

When a user does this | The item is | The item can be restored by
Deletes an item | Held in the first-stage Recycle Bin until the item is deleted from the Recycle Bin or the item has been in the Recycle Bin longer than the time limit configured for an item to be held in the Recycle Bin. | Users or site collection administrators
Deletes an item from the Recycle Bin | Held in the second-stage Recycle Bin | Site collection administrators

Turning off the Recycle Bin for a Web application empties all Recycle Bins and permanently deletes all items in them.

First-stage Recycle Bin

The first-stage Recycle Bin is located at the site level and is available to users who have Contribute, Design, or Full Control permissions on a site.When a user deletes an item from a Web site, the item is sent to the site's first-stage Recycle Bin. Items located in the first-stage Recycle Bin count toward the site quota.Items remain in one of the first-stage Recycle Bins in the site until a specified time period has been reached (the default setting is 30 days).

When an item is deleted from the Recycle Bin, the item is sent to the second-stage Recycle Bin.

Note:

The time limit for the Recycle Bins applies to the total time after the item was first deleted — not the time spent in either Recycle Bin stage.

Second stage (Site Collection) Recycle Bin

The second-stage Recycle Bin is located at the site collection administrator level. The second-stage Recycle Bin is organized into two views: objects in the first-stage Recycle Bins of all sites in the site collection, and objects in the second-stage Recycle Bin. When an item is deleted from the first-stage Recycle Bin, it can be recovered only by a site collection administrator from the second-stage Recycle Bin.

Items remain in the second-stage Recycle Bin until a specified time period has been reached (the default setting is 30 days) or until the second-stage Recycle Bin reaches its size limit, at which time the oldest items are deleted. The time limit for the Recycle Bins applies to the total time after the item was initially deleted — not the time spent in either Recycle Bin stage.

When a second-stage Recycle Bin is enabled for a Web application, we recommend that you designate how much disk space is available to the second-stage Recycle Bin as a percentage of the quota allotted to the Web application. Items stored in the second-stage Recycle Bin do not count toward the site quota; however, the size that is specified for the second-stage Recycle Bin increases the total size of the site and the content database that hosts it. If no site quota has been set, there is no limit on the size of the second-stage Recycle Bin.

For example, if you have allotted 100 megabytes (MB) of space for the Web application, allotting a 50 percent quota for the second-stage Recycle Bin allots 50 MB for the second-stage Recycle Bin and 150 MB for the Web application as a whole. You can allot up to 100 percent for the second-stage Recycle Bin quota.

For more information about setting quotas, see

  • Plan for site maintenance and management (SharePoint Foundation 2010)

  • Create quota templates (SharePoint Foundation 2010)

For more information about how users can use the Recycle Bin in SharePoint Foundation 2010, see View, restore, or delete items in the Recycle Bin (http://go.microsoft.com/fwlink/p/?LinkId=90917&clcid=0x409)

For information about configuring the Recycle Bins, see Configure the Recycle Bin (SharePoint Foundation 2010).

Protecting content by using versioning

Versioning addresses the issue of losing data by overwriting a document. It allows the document library to keep multiple copies of the same document. In the event of an unwanted change, an overwrite, or a document corruption, the previous version can easily be restored by the user. Versioning can be enabled at the library or list level. Items and files can be versioned.

Before configuring versioning, be sure to read Plan for site maintenance and management (SharePoint Foundation 2010) .

For more information about configuring versioning, see Enable and configure versioning (SharePoint Foundation 2010) .

Administrators must closely manage versioning, because if sites have many versions of files and documents, the sites can become quite large. If you do not restrict the size of sites, your sites can surpass your storage capacity. Farm administrators can manage this issue by establishing service level agreements with site owners and by setting size quotas on sites. For more information about managing versioning, see Manage versioning by using quotas (SharePoint Foundation 2010).

See Also

Other Resources

Resource Center: Business Continuity Management for SharePoint Foundation 2010


Plan for backup and recovery (SharePoint Foundation 2010)
See Also

This article describes the stages involved in planning for backup and recovery, which include determining backup and recovery strategies for a Microsoft SharePoint Foundation environment and deciding which tools to use. The stages do not have to be done in the order listed, and the process may be iterative.

When you plan for how you will use backup and recovery for disaster recovery, consider common events, failures, and errors; local emergencies; and regional emergencies.

Important:

The SharePoint 2010 Service Pack 1 (SP1) upgrade process alters the schema of some of the farm databases and all content databases. Because of these changes, you might need to take additional steps to restore a backup that you made before the farm was upgraded to SP1 to the farm after it is upgraded to SP1. For more information about doing this, see Restore pre-SP1 backups to an SP1 farm (SharePoint Foundation 2010).

For detailed information about Microsoft SharePoint Foundation backup and recovery, see Backup and recovery overview (SharePoint Foundation 2010).

In this article:

  • Define business requirements

  • Choose what to protect and recover in your environment

  • Choose tools

  • Determine strategies

  • Plan for enhanced backup and recovery performance

Define business requirements

To define business requirements, determine the following for each farm and service in the environment:

  • Recovery point objective (RPO) is the objective for the maximum time period between the last available backup and any potential failure point. It is determined by how much data that the business can afford to lose if a failure were to occur.

  • Recovery time objective (RTO) is the objective for the maximum time that a data recovery process will take. It is determined by the time the business can afford for the site or service to be unavailable.

  • Recovery level objective (RLO) is the objective that defines the granularity with which you must be able to recover data — whether you must be able to recover the whole farm, Web application, site collection, site, list or library, or item.

Shorter RPO and RTO, and finer granularity of RLO, all typically cost more.

A worksheet to help you plan your strategies for backup and recovery for your SharePoint Foundation 2010 environment can be downloaded from SharePoint 2010 Products backup and recovery planning workbook (http://go.microsoft.com/fwlink/p/?LinkID=184385).

Choose what to protect and recover in your environment

Your business requirements will help you determine which components of the environment that you must protect, and the granularity with which you have to be able to recover them.

The following table lists components of a SharePoint environment that you might decide to protect, and the tools that can be used to back up and recover each component.

Component | SharePoint backup | Microsoft SQL Server 2008 R2 Express | System Center Data Protection Manager (DPM) 2010 | File system backup
Farm | Yes |  | Yes6 |
Service applications | Yes |  |  |
Web application | Yes |  |  |
Content databases | Yes | Yes | Yes |
Site collection | Yes1, 2 | Yes1, 2 | Yes1, 2 |
Site | Yes2 | Yes2 | Yes |
Document library or list | Yes2 | Yes2 | Yes |
List item or document |  |  | Yes |
Content stored in remote BLOB stores | Yes3 | Yes3 | No3 |
Customizations deployed as solution packages | Yes7 | Yes7 | Yes6, 7 |
Changes to Web.config made by using Central Administration or an API | Yes | Yes | Yes4 |
Configuration settings (SharePoint) | Yes2, 8 | Yes2, 8 | Yes 2, 9 |
Customizations not deployed as solution packages |  |  | Yes. Files can be recovered if protected as files.4, 5 | Yes
Changes to Web.config not made by using Central administration or an API |  |  | Yes4 | Yes
IIS configurations not set through SharePoint |  |  | Yes5 | Yes
SQL Server Reporting Services databases |  | Yes | Yes |

1Farm-level and database-level backup and restore can be used for site collection recovery if a single site collection is stored in a database.

2Farm-level and database-level backups can be used with SharePoint Foundation unattached database recovery to restore site collections, sites, lists, and configurations.

3Content stored in remote BLOB stores cannot be restored by using DPM.

4Changes to Web.config can be backed up by using file system backup from DPM 2010.

5IIS configurations can be recovered by using a bare metal backup from DPM 2010.

6 DPM 2010 can recover this item by using a combination of a bare metal backup and SharePoint Foundation backup. It cannot be backed up and recovered as an object.

7Fully-trusted solution packages are stored in the configuration database, and sandboxed solutions are stored in content databases. They can be recovered as part of farm or content database recovery.

8Configuration settings can be recovered from farm-level backups. For more information, see Restore a farm (SharePoint Foundation 2010).

9The Central Administration content database and the configuration database for a SharePoint Foundation 2010 farm can be recovered but only as part of a full-farm recovery to the same farm, with the same computers.

Note:

You can register SharePoint Foundation 2010 with Windows Server Backup by using the stsadm.exe -o -registerwsswriter operation to configure the Volume Shadow Copy Service (VSS) writer for SharePoint Foundation. Windows Server Backup then includes SharePoint Foundation 2010 in server-wide backups. When you restore from a Windows Server backup, you can select Microsoft SharePoint Foundation (regardless of which version of SharePoint 2010 Products is installed), and all components reported by the VSS writer for SharePoint Foundation 2010 on that server at the time of the backup will be restored.

Windows Server Backup is recommended only for use with for single-server deployments.

Choose what to recover from within SharePoint content databases

From within a content database, you can recover site collections, sites, lists and libraries.

Backup and recovery tools provide different levels of recovery for content within a content database. Recovering an object from within a content database is always more complex than recovering the whole content database.

Protecting customizations

Customizations to SharePoint sites can include the following:

  • Master pages, page layouts and cascading style sheets. These objects are stored in the content database for a Web application.

  • Web Parts, site or list definitions, custom columns, new content types, custom fields, custom actions, coded workflows, or workflow activities and conditions.

  • Third-party solutions and their associated binary files and registry keys, such as IFilters.

  • Changes to standard XML files.

  • Custom site definitions (Webtemp.xml).

  • Changes to the Web.config file.

How customizations are deployed, and how changes are made to the Web.config file, have a significant effect on which tools can be used to back up and recover customizations. To provide the greatest opportunity for recovery, we recommend that you deploy customizations by using solution packages and configure the Web.config file by using Central Administration or the SharePoint APIs and object model.

Protecting workflows

Workflows are a special case of customizations that you can back up and recover. Make sure that your backup and recovery plan addresses any of the following scenarios that apply to your environment:

  • Declarative workflows, such as those that you created in Microsoft SharePoint Designer 2010, are stored in the content database for the site collection to which they are deployed. Backing up the content database protects these workflows.

  • Custom declarative workflow actions have components in the following three locations:

    1. The Visual Studio assemblies for the Activities are stored in the global assembly catalog (GAC).

    2. The XML definition files (.ACTIONS files) are stored in the 14\TEMPLATE\{LCID}\Workflow directory.

    3. An XML entry to mark the activity as an authorized type is stored in the Web.config file for the Web applications in which it is used.

    If your farm workflows use custom actions, you should use a file backup system to protect these files and XML entries. Similar to SharePoint Foundation features such as Web Parts and event receivers, these files should be reapplied to the farm as needed after recovery.

  • Workflows that depend on custom code, such as those that are created by using Visual Studio, are stored in two locations. The Visual Studio assemblies for the workflow are stored in the global assembly catalog (GAC), and the XML definition files are stored in the Features directory. This is the same as other kinds of SharePoint Foundation features such as Web Parts and event receivers. If the workflow was installed as part of a solution package, backing up the content database protects these workflows.

  • If you create a custom workflow that interacts with a site collection other than the one where the workflow is deployed, you must back up both site collections to protect the workflow. This includes workflows that write to a history list or other custom list in another site collection. Performing a farm backup is sufficient to back up all site collections in the farm and all workflows that are associated with them.

  • Workflows that are not yet deployed must be backed up and restored separately like any other data file. When you are developing a new workflow but have not yet deployed it to the SharePoint Foundation farm, make sure that you back up the folder where you store your workflow project files by using Windows Backup or another file system backup application.

Protecting service applications

Service applications in a SharePoint Foundation environment can be made up of both service settings and one or more databases, or only service settings. You cannot restore a complete service application by restoring the database only. However, you can restore the databases for a service application and then provision the service application. For more information, see Restore a service application (SharePoint Foundation 2010).

Protecting SQL Server Reporting Services databases

SharePoint Foundation backup and recovery does not include SQL Server Reporting Services databases. You must use SQL Server 2008 R2 Express tools. For more information, see Backup and Restore Operations for a Reporting Services Installation (http://go.microsoft.com/fwlink/p/?LinkId=186642).

Choose tools

To select the correct tools for backup and recovery, you must determine whether you can meet the continuity requirements that you have set for your business within your budget for time and resources.

Key things to consider when you select tools include the following:

  • Speed of backup: Can the tool perform within the maintenance window for your databases? You should test any backup system to ensure that it meets your needs on your hardware.

  • Completeness of recovery.

  • Granularity of objects that can be recovered.

  • Backup type supported (full, differential, or incremental).

  • Complexity of managing the tool.

The following table compares the kind of backup and size of farm that can be backed up in a six-hour window for backup and recovery tools available from Microsoft.

Tool | Backup type | Size of backup completed in six hours1
SharePoint farm backup and recovery | Full, differential | 600 GB
SQL Server | Full, differential | 600 GB
System Center Data Protection Manager | Incremental | Terabytes

1Backup size was determined by backing up a system that totals the specified size on the test hardware listed in the following section.

Note:

The SharePoint Foundation and SQL Server 2008 R2 Express backups were performed with backup compression turned on.

Test hardware

The following table lists the hardware that was used in the tests that determined the size of backup that could be completed in a six-hour window.

Component | Description
Processor | 64-bit dual processor, 3 GHz
RAM | 8 GB
Disk | 2 terabyte NTFS file system-formatted partition
Network | 100 megabits per second (Mbps) or faster connection between client computers and server
Network share | Network share with 1.25 terabytes free space

Note:

The upper size limit for performing SharePoint Foundation 2010 site collection backups is 100 GB.

For detailed information about the backup and recovery systems that can be used with Microsoft SharePoint Foundation, see the following resources:

  • Backup and recovery overview (SharePoint Foundation 2010)

  • Backing Up and Restoring Databases in SQL Server (http://go.microsoft.com/fwlink/p/?LinkID=186643)

  • Data Protection Manager 2010 Overview (http://go.microsoft.com/fwlink/p/?LinkID=186655)

Determine strategies

Based on your business requirements, recovery needs, and the tools that you have selected, determine and document the backup and recovery strategies for your environment.

It is common for IT departments that support SharePoint Foundation environments to decide to use more than one tool to protect the environment, as they determine the strategies that they will use.

For example, in an environment that has databases that are managed by DBAs, the strategies in the following list might be employed:

  • All databases are backed up by SQL Server 2008 R2 Express. The backup interval that is set is based on the following:

    • The importance of the content or service.

    • The effect on performance that the backup has on the environment.

  • Small, quickly changing, very high-business-affect content databases are additionally protected by SQL Server 2008 R2 Express database snapshots that are stored on a separate physical disk. Only one snapshot is stored per database, and snapshots are discarded regularly so that the effect on performance is minimized. The snapshot interval that is set for each database is based on the following:

    • The importance of the content or service.

    • The standard rate of change for the database.

    • The effect on performance that the snapshot has on the environment.

    • The amount of space that is required to store the snapshot.

    Recovering from a snapshot is faster than standard recovery because a snapshot, and its underlying database, can be treated by SharePoint Foundation as an unattached database. However, creating snapshots can decrease the performance of the underlying database. We recommend that the effect that snapshots have on the performance of the system be tested before they are implemented, and that snapshots be discarded regularly to reduce the space that is required.

    Note:

    If you are using RBS, and the RBS provider that you are using does not support snapshots, you cannot use snapshots for backup. For example, the FILESTREAM provider does not support snapshots.

  • SharePoint Foundation backup is used to protect service applications. The backup interval is based on the following:

    • The importance of the service.

    • The standard rate of change for the database.

    • The effect on performance that the backup has on the database.

  • All restore operations are performed through SharePoint Foundation. The choice of which restore system to use is determined by the kind of backup that is available and the object being restored.

Other tools should be part of your business continuity strategy. Consider how you will use Recycle Bins and versioning in site collections throughout the environment. For more information, see Plan for business continuity management (SharePoint Foundation 2010).

Plan for enhanced backup and recovery performance

As you plan your backup and recovery strategy, consider the following recommendations to help you decrease the effect of backup and recovery on system performance.

By design, most backup jobs consume as many I/O resources as they can to finish the job in the available time for maintenance. Therefore, you might see disk queuing and you might see that all I/O requests come back more slowly than usual. This is typical and should not be considered a problem.

Follow recommendations for configuring SQL Server and storage

Follow the general recommendations for configuring SQL Server 2008 R2 Express and storage for a SharePoint Foundation environment. For more information, see SQL Server and storage (SharePoint Foundation 2010).

Minimize latency between SQL Server and the backup location

In general, it is best to use a local disk, not a network drive, for backups. If you are backing up multiple servers, you may want to have a directly connected computer that both servers can write to. Network drives that have 1 millisecond or less latency between them and the computers that are running SQL Server 2008 R2 Express will perform well. If your farm has multiple servers in it (including the computer that is running SQL Server 2008 R2 Express), you must use UNC network paths for the SharePoint farm backup location.

Avoid processing conflicts

Do not run backup jobs during times in which users must have access to the system.

To avoid I/O bottlenecks, perform the main backup to a separate disk, and only then copy to tape.

Consider staggering backups so that not all databases are backed up at the same time.

SharePoint Foundation backups use SQL Server 2008 R2 Express backups. When using compression with your backups, be mindful not to overwhelm SQL Server 2008 R2 Express. For example, some third-party backup tools compress data during backup, which can disrupt SQL Server performance. There are tools available to throttle the compression processes and control the effect on SQL Server.

Follow SQL Server backup and restore optimization recommendations

If you are running SQL Server 2008 Enterprise, we recommend that you use backup compression. For more information, see Backup Compression (SQL Server) (http://go.microsoft.com/fwlink/p/?LinkId=179525).

If you are using SQL Server 2008 R2 Express backups, use a combination of full, differential, and transaction log backups for the full recovery model to minimize recovery time. Differential database backups are usually faster to create than full database backups, and they reduce the amount of transaction log required to recover the database.

If you are using the full recovery model in SQL Server 2008, we recommend that you use the truncate option during backup to avoid maintenance issues.

For detailed recommendations about how to optimize SQL Server 2008 R2 Express backup and restore performance, see Optimizing Backup and Restore Performance in SQL Server (http://go.microsoft.com/fwlink/p/?LinkId=126630).

Ensure sufficient write performance on the backup drive

Carefully consider whether to use redundant array of independent disks (RAID) on your disk backup device. For example, RAID 5 has low write performance, approximately the same speed as for a single disk. (This is because RAID 5 maintains parity information.) Using RAID 10 for a backup device may provide faster backups. For more information about how to use RAID with backups, see Configure RAID for maximum SQL Server I/O throughput (http://go.microsoft.com/fwlink/p/?LinkId=126632).

Related content

Resource center | Business Continuity Management for SharePoint Foundation 2010(http://technet.microsoft.com/en-us/sharepoint/ff601869.aspx)
IT Pro content | Backup and recovery overview (SharePoint Foundation 2010) Backup and recovery (SharePoint Foundation 2010) Plan for availability (SharePoint Foundation 2010) Availability configuration (SharePoint Foundation 2010) Plan for disaster recovery (SharePoint Foundation 2010)
Developer content | Data Protection and Recovery (http://go.microsoft.com/fwlink/p/?LinkID=199237)

See Also

Other Resources

Resource Center: Architecture Design for SharePoint Server 2010


Backup and recovery overview (SharePoint Foundation 2010)
See Also

This article describes the backup architecture and recovery processes that are available in Microsoft SharePoint Foundation 2010, including farm and granular backup and recovery, and recovery from an unattached content database. Backup and recovery operations can be performed through the user interface or through Windows PowerShell cmdlets. Built-in backup and recovery tools may not meet all the needs of your organization.

In this article:

  • Backup and recovery scenarios

  • Backup architecture

  • Recovery processes

Backup and recovery scenarios

Backing up and recovering data supports many business scenarios, including the following:

  • Recovering unintentionally deleted content that is not protected by the Recycle Bin or versioning.

  • Moving data between installations as part of a hardware or software upgrade.

  • Recovering from an unexpected failure.

Backup architecture

SharePoint Foundation 2010 provides two backup systems: farm and granular.

Farm backup architecture

The farm backup architecture in SharePoint Foundation 2010 starts a Microsoft SQL Server database backup of content and service application databases and also writes configuration content to files.

The following illustration shows the farm backup system.

Backup architecture (SharePoint Foundation)

Both full and differential backups are supported. Full backups create a new backup of the complete system. Differential backups create a backup of all the data that is stored in databases that has changed since the last full backup.

The farm backup system is organized hierarchically. The components in a farm that can be selected for backup include the following:

  • Farm The farm is the highest-level object. You can select from the following options when you perform a farm backup:

    • Content and configuration data (default)

      The whole server farm is backed up. This includes settings from the configuration database.

    • Configuration only

      Configuration database settings are backed up so that you can apply configurations across farms. For more information, see Configuration-only backup use and benefits later in this article.

  • Web application Within a Web application, you can select one or more of the content databases to back up.

    A Web application backup includes the following:

    • Application pool name and application pool account

    • Authentication settings

    • General Web application settings such as alerts and managed paths

    • Internet Information Services (IIS) binding information, such as the protocol type, host header, and port number

    • Changes to the Web.config file that have been made through the object model or Central Administration

      Note:

      Changes to the Web.config file that have been made to support claims-based application that uses forms-based authentication are not included in backups, because those changes are made manually. For more information, see Considerations for using farm backups later in this article.

    • Sandboxed solutions

    For recommendations about how to protect these settings, see Plan for backup and recovery (SharePoint Foundation 2010).

  • Important:

    Backups of service applications do not include the related proxy. To back up both the service application and the service application proxy, you must either back up the farm or perform two consecutive backups, selecting the service application in one backup, and selecting the associated service application proxy in the second backup.

    Many service application databases cannot be backed up individually from SharePoint Foundation 2010. To back up service application databases only, you must use SQL Server backup.

  • Proxies for service applications that are not shared.

  • Shared Services Shared services require both a service application and a service application proxy to run. If you select the Shared Services node, all of the service applications and the related service application proxies on the farm will be backed up.

    Note:

    The backup hierarchy enables you to select individual service applications and service application proxies to back up. However, when you select one or all service applications, or one or all proxies, the related objects are not backed up by default. To back up both parts of a specific service, you must either select the Shared Services node or perform two consecutive backups, selecting the service application in one backup, and selecting the associated service application proxy in the second backup.

Note:

Some settings in the SharePoint Foundation environment are not included in a farm backup. They include the following settings that are stored on Web servers:

  • Application pool account passwords

  • HTTP compression settings

  • Time-out settings

  • Custom Internet Server Application Programming Interface (ISAPI) filters

  • Computer domain membership

  • Internet Protocol security (IPsec) settings

  • Network Load Balancing settings

  • Secure Sockets Layer (SSL) certificates

  • Dedicated IP address settings

Configuration-only backup use and benefits

A configuration-only backup extracts and backs up the configuration settings from a configuration database. By using built-in tools, you can back up the configuration of any configuration database, whether it is currently attached to a farm or not. For detailed information about how to back up a configuration, see Back up a farm configuration (SharePoint Foundation 2010).

A configuration backup can be restored to the same — or any other — server farm. When a configuration is restored, it will overwrite any settings present in the farm that have values that are set in the configuration backup. If any settings present in the farm are not contained in the configuration backup, they will not be changed. For detailed information about how to restore a farm configuration, see Restore a farm configuration (SharePoint Foundation 2010).

Note:

Web application and service application settings are not included in a configuration backup. You can use Windows PowerShell cmdlets to document and copy settings for service applications. For more information, see Document farm configuration settings (SharePoint Foundation 2010) and Copy configuration settings from one farm to another (SharePoint Foundation 2010).

Situations in which you might want to restore a configuration from one farm to another farm include the following:

  • Replicating a standardized farm configuration to be used throughout an environment.

  • Moving configurations from a development or test environment to a production environment.

  • Moving configurations from a stand-alone installation to a farm environment.

  • Configuring a farm to serve as part of a standby environment.

SharePoint Foundation stores the following kinds of settings in the configuration-only backup:

  • Antivirus

  • Information rights management (IRM)

  • Outbound e-mail settings (only restored when you perform an overwrite).

  • Customizations deployed as trusted solutions

  • Diagnostic logging

Considerations for using farm backups

Consider the following before you use farm backups:

  • There is no built-in scheduling system for backups. To schedule a backup, we recommend that you create a backup script by using Windows PowerShell, and then use Windows Task Scheduler to run the backup script on a regular basis.

  • We do not recommend that you use IIS metabase backup to protect IIS settings. Instead, document all IIS configurations for each Web server by using a tool that provides the configuration monitoring you want, such asMicrosoft System Center Configuration Manager 2007.

  • SharePoint Foundation 2010 backup and recovery can be run together with SQL Server Enterprise features such as backup compression and transparent data encryption.

    If you are running SQL Server Enterprise, we strongly recommend that you use backup compression. For more information about backup compression, see Backup Compression (SQL Server) http://go.microsoft.com/fwlink/p/?LinkID=129381).

    If you decide to run databases with transparent data encryption, you must manually back up the key and restore the key — SharePoint Foundation 2010 backup and restore will not remind you about the key. For more information about transparent data encryption, see Understanding Transparent Data Encryption (TDE) (http://go.microsoft.com/fwlink/p/?LinkID=129384).

  • If a content database is set to use the SQL FILESTREAM remote BLOB storage (RBS) provider, the RBS provider must be installed both on the database server that is being backed up and on the database server that is being recovered to.

  • SharePoint Foundation 2010 backup does not protect:

    • Changes to the Web.config file on Web servers that are not made through Central Administration or the object model.

    • Customizations to a site that are not deployed as part of a trusted or sandboxed solution.

  • If you are sharing service applications across farms, be aware that trust certificates that have been exchanged are not included in farm backups. You must back up the certificate store separately or keep the certificates in a separate location. When you restore a farm that shares a service application, you must import and redeploy the certificates and then re-establish any inter-farm trusts.

    For more information, see Exchange trust certificates between farms (SharePoint Foundation 2010).

  • When you restore a farm or Web application that is configured to use any kind of claims-based authentication, duplicate or additional providers may appear to be enabled. If duplicates appear, you must manually save each Web application zone to remove them.

  • Additional steps are required when you restore a farm that contains a Web application that is configured to use forms-based authentication. You must re-register the membership and role providers in the Web.config file, and then redeploy the providers. You must perform these steps whether you are restoring at the Web application level or at the farm level.

    For more information, see Back up a Web application (SharePoint Foundation 2010), Plan authentication methods (SharePoint Foundation 2010) and Configure claims authentication (SharePoint Foundation 2010).

Granular backup and export architecture

The granular backup and export architecture uses Transact-SQL queries and export calls. Granular backup and export is a more read-intensive and processing-intensive operation than farm backup.

From the granular backup system, a user can back up a site collection, or export a site or list.

Note:

Workflows are not included in exports of sites or lists.

If you are running SQL Server Enterprise, the granular backup system can optionally use SQL Server database snapshots to ensure that data remains consistent while the backup or export is in progress. When a snapshot is requested, a SQL Server database snapshot of the appropriate content database is taken, SharePoint Foundation uses it to create the backup or export package, and then the snapshot is deleted. Database snapshots are linked to the source database where they originated. If the source database goes offline for any reason, the snapshot will be unavailable. For more information about database snapshots, see Database Snapshots (http://go.microsoft.com/fwlink/p/?LinkId=166158).

Benefits of backing up a site collection by using a snapshot include the following:

  • The snapshot ensures that the data that is being read remains consistent while the operation is being performed.

  • Users can continue to interact with the site collection while it is being backed up from the database snapshot. This includes adding, editing, and deleting content. However, the changes that users make to the live site will not be included in the site collection backup because the backup is based on the database snapshot.

However, database snapshots can adversely affect performance. For more information about database snapshots and performance, see Limitations and Requirements of Database Snapshots (http://go.microsoft.com/fwlink/p/?LinkId=166159).

You can use granular backup and export for content that is stored in a database that is configured to use the SQL FILESTREAM RBS provider.

Note:

If the RBS provider that you are using does not support snapshots, you cannot use snapshots for content deployment or backup. For example, the SQL FILESTREAM provider does not support snapshots.

Note:

We do not recommend that you use SharePoint Foundation 2010 site collection backup for site collections larger than 85 GB.

The following illustration shows the granular backup and export system.

Granular backup/export process

Recovery processes

SharePoint Foundation 2010 supports the following primary, built-in recovery options:

  • Restore from a farm backup that was created by using built-in tools, or restore from the backup of a component taken by using the farm backup system.

  • Restore from a site collection backup.

  • Connect to a content database by using the unattached content database feature, back up or export data from it, and then restore or import the data.

Restoring from a farm backup

Items that can be recovered from a farm backup include the following:

  • Farm

    • Content and configuration data (default)

      The whole server farm is restored. This includes settings from the configuration database, and trusted solution packages.

    • Configuration only

      Only the configuration data is restored. This overwrites any settings in the farm that have values that are set within the configuration-only backup.

  • Web applications

    Restores Web applications.

  • Service applications

    Restores service applications. Service application recovery can be complex because SharePoint Foundation 2010 cannot fully reconfigure service application proxies during the restore process. Service application proxies are restored, but are not put in proxy groups. Therefore, they are not associated with any Web applications. For specific information about the operations involved in restoring specific service applications, see Restore a service application (SharePoint Foundation 2010).

  • Content databases

    When content databases are restored, the sandboxed solutions associated with the related site collections are also restored.

Restoring as new versus restoring as overwrite

By default, SharePoint Foundation 2010 recovery restores any object as a new instance of the object, instead of overwriting any existing instances with the same name.

When you restore a farm or object as new, the following objects will not work without adjustments, because all GUIDs for objects are assigned new values:

  • Farm. When you restore a farm as new, you must do the following:

    • Re-create alternate access mapping settings. SharePoint Foundation 2010 recovery only restores the Default zone of the Web application.

    • Re-associate service application proxies with proxy groups because service application proxies are not assigned to proxy groups when restored. All Web applications will be associated with the default proxy group. You must associate Web applications with other proxy groups if you want to do that.

  • Web application.

    • If the Web application name and URL that you provide match a Web application name and URL that already exist in the farm, SharePoint Foundation 2010 recovery combines them.

    • If you do not want to combine Web applications, you must rename the Web application when you restore it as new.

    • When you restore a Web application as new in the same environment but do not combine Web applications, many other parameters and objects must also be changed. For example, you may have to provide different database file paths and different database names.

  • Service applications and service application proxies

    • If you recover a service application and also recover the related service application proxy, you must associate the service application proxy with a proxy group.

    • If you recover a service application and do not also recover the related service application proxy, you must re-create the service application proxy.

    Note:

    You cannot restore a service application as new in the same farm. You can restore a service application as new in another farm.

When you restore an object and overwrite the existing object, no changes are necessary.

Restoring from a site collection backup

Only site collections can be recovered from a site collection backup.

Recovering from an unattached content database

SharePoint Foundation 2010 provides the ability to connect to, and back up from, a content database that is attached to an instance of SQL Server but is not associated with a local SharePoint Web application. Unattached databases that you can connect to include read-only content databases that have been restored from any supported backup technology and SQL Server database snapshots of content databases.

Recovery is the following two-stage process:

  1. Back up or export the object from the unattached content database.

  2. Restore or import the output of the prior step into SharePoint Foundation 2010.

The following items can be backed up or exported from an unattached database by using granular backup and export, and then restored:

  • Site collection

    Back up by using site collection backup, and then recover by using a site collection restore.

  • Site

    Export, and then import.

  • Lists and libraries

    Export, and then import.

You can use import to recover content that you backed up from a database configured to use the SQL FILESTREAM RBS provider. The recovered content will be stored by SharePoint Foundation 2010 using the currently defined storage provider for that content database — that is, if the content database is not set to use RBS, the data will be stored in the content database; if the content database is set to use RBS, the data will be stored in RBS.

Related content

Resource center | Business Continuity Management for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkID=201997)
IT pro content | Plan for backup and recovery (SharePoint Foundation 2010) Backup and recovery (SharePoint Foundation 2010)
Developer content | Data Protection and Recovery (http://go.microsoft.com/fwlink/p/?LinkID=199237)

See Also

Other Resources

Resource Center: Business Continuity Management for SharePoint Foundation 2010


Plan for availability (SharePoint Foundation 2010)
See Also

This article describes key decisions in choosing availability strategies for a Microsoft SharePoint Foundation 2010 environment.

As you carefully review your availability requirements, be aware that the higher the level of availability and the more systems that you protect, the more complex and costly your availability solution is likely to be.

Not all solutions in an organization are likely to require the same level of availability. You can offer different levels of availability for different sites, different services, or different farms.

In this article:

  • Availability overview

  • Choosing an availability strategy and level

  • Redundancy and failover between closely located data centers configured as a single farm ("stretched" farm)

Availability overview

Availability is the degree to which a SharePoint Foundation environment is perceived by users to be available. An available system is a system that is resilient — that is, incidents that affect service occur infrequently, and timely and effective action is taken when they do occur.

Availability is part of business continuity management (BCM), and is related to backup and recovery and disaster recovery. For more information about these related processes, see Plan for backup and recovery (SharePoint Foundation 2010) and Plan for disaster recovery (SharePoint Foundation 2010).

Note:

When calculating availability, most organizations specifically exempt or add hours for planned maintenance activities.

One of the most common measures of availability is percentage of uptime expressed as number of nines — that is, the percentage of time that a given system is active and working. For example, a system with a 99.999 uptime percentage is said to have five nines of availability.

The following table correlates uptime percentage with calendar time equivalents.

Acceptable uptime percentage | Downtime per day | Downtime per month | Downtime per year
95 | 72.00 minutes | 36 hours | 18.26 days
99 (two nines) | 14.40 minutes | 7 hours | 3.65 days
99.9 (three nines) | 86.40 seconds | 43 minutes | 8.77 hours
99.99 (four nines) | 8.64 seconds | 4 minutes | 52.60 minutes
99.999 (five nines) | 0.86 seconds | 26 seconds | 5.26 minutes

If you can make an educated guess about the number of total hours downtime you are likely to have per year, you can use the following formulas to calculate the uptime percentage for a year, a month, or a week:

% uptime/year = 100 - (8760 - number of total hours downtime per year)/8760

% uptime/month = 100 - ((24 × number of days in the month) - number of total hours downtime in that calendar month)/(24 × number of days in the month)

% uptime/week = 100 - (168 - number of total hours downtime in that week)/168

Costs of availability

Availability is one of the more expensive requirements for a system. The higher the level of availability and the more systems that you protect, the more complex and costly an availability solution is likely to be. When you invest in availability, costs include the following:

  • Additional hardware and software, which can increase the complexity of interactions among software applications and settings.

  • Additional operational complexity.

The costs of improving availability should be evaluated in conjunction with your business needs — not all solutions in an organization are likely to require the same level of availability. You can offer different levels of availability for different sites, different services, or different farms.

Availability is a key area in which information technology (IT) groups offer service level agreements (SLAs) to set expectations with customer groups. Many IT organizations offer various SLAs that are associated with different chargeback levels.

Determining availability requirements

To gauge your organization's tolerance of downtime for a site, service, or farm, answer the following questions:

  • If the site, service, or farm becomes unavailable, will employees be unable to perform their expected job responsibilities?

  • If the site, service, or farm becomes unavailable, will business and customer transactions be stopped, leading to loss of business and customers?

If you answered yes to either of these questions, you should invest in an availability solution.

Choosing an availability strategy and level

You can choose among many approaches to improve availability in a SharePoint Foundation environment, including the following:

  • Improve the fault tolerance of server hardware components.

  • Increase the redundancy of server roles within a farm.

Hardware component fault tolerance

Hardware component fault tolerance is the redundancy of hardware components and infrastructure systems such as power supplies at the server level. When planning for hardware component fault tolerance, consider the following:

  • Complete redundancy of every component within a server may be impossible or impractical. Use additional servers for additional redundancy.

  • Ensure that servers have multiple power supplies connected to different power sources for maximum redundancy.

In any system, we recommend that you work with hardware vendors to obtain fault-tolerant hardware that is appropriate for the system, including redundant array of independent disks (RAID) arrays.

Redundancy within a farm

SharePoint Foundation 2010 supports running server roles on redundant computers (that is, scaling out) within a farm to increase capacity and to provide basic availability.

The capacity that you require determines both the number of servers and the size of the servers in a farm. After you have met your base capacity requirements, you may want to add more servers to increase overall availability. The following illustration shows how you can provide redundancy for each server role.

Availability within a server farm

Single farm availability

The following table describes the server roles in a SharePoint Foundation 2010 environment and the redundancy strategies that can be used for each within a farm.

Server role | Preferred redundancy strategy within a farm
Front-end Web server | Deploy multiple front-end Web servers within a farm, and use Network Load Balancing (NLB).
Application server | Deploy multiple application servers within a farm.
Database server | Deploy database servers by using clustering or high-availability database mirroring.

Database availability strategies

You can use Microsoft SQL Server failover clustering or SQL Server high-availability database mirroring to support availability of databases in a SharePoint Foundation environment.

SQL Server failover clustering

Failover clustering can provide availability support for an instance of SQL Server. A failover cluster is a combination of one or more nodes or servers, and two or more shared disks. A failover cluster instance appears as a single computer, but has functionality that provides failover from one node to another if the current node becomes unavailable. SharePoint Foundation can run on any combination of active and passive nodes in a cluster that is supported by SQL Server.

SharePoint Foundation references the cluster as a whole; therefore, failover is automatic and seamless from the perspective of SharePoint Foundation.

For detailed information about failover clustering, see Getting Started with SQL Server 2008 Failover Clustering (http://go.microsoft.com/fwlink/p/?LinkID=102837&clcid=0x409) and Configure availability by using SQL Server clustering (SharePoint Foundation 2010).

SQL Server high-availability mirroring

Database mirroring is a SQL Server technology that can deliver database redundancy on a per-database basis. In database mirroring, transactions are sent directly from a principal database and server to a mirror database and server when the transaction log buffer of the principal database is written to disk. This technique can keep the mirror database almost up to date with the principal database. SQL Server Enterprise Edition provides additional functionality that improves database mirroring performance.

For mirroring within a SharePoint Foundation farm, you must use high-availability mirroring, also known as high-safety mode with automatic failover. High-availability database mirroring involves three server instances: a principal, a mirror, and a witness. The witness server enables SQL Server to automatically fail over from the principal server to the mirror server. Failover from the principal database to the mirror database typically takes several seconds.

A change from previous versions is that SharePoint Foundation is mirroring-aware. After you have configured a database mirror instance of SQL Server, you then use SharePoint Central Administration or Windows PowerShell cmdlets to identify the failover (mirror) database server location for a configuration database, content database, or service application database. Setting a failover database location adds a parameter to the connection string that SharePoint Foundation uses to connect to SQL Server. In the event of a SQL Server time-out event, the following occurs:

  1. The witness server that is configured for SQL Server mirroring automatically swaps the roles of the primary and mirror databases.

  2. SharePoint Foundation automatically attempts to contact the server that is specified as the failover database.

For information about how to configure database mirroring, see Configure availability by using SQL Server database mirroring (SharePoint Foundation 2010).

For general information about database mirroring, see Database Mirroring (http://go.microsoft.com/fwlink/p/?LinkID=180597).

Note:

Databases that have been configured to use the SQL Server FILESTREAM remote BLOB store provider cannot be mirrored.

Comparison of database availability strategies for a single farm: SQL Server failover clustering vs. SQL Server high-availability mirroring

The following table compares failover clustering to synchronous SQL Server high-availability mirroring.

 | SQL Server failover clustering | SQL Server high-availability mirroring
Time to failover | Cluster member takes over immediately upon failure. | Mirror takes over immediately upon failure.
Transactional consistency? | Yes | Yes
Transactional concurrency? | Yes | Yes
Time to recovery | Shorter time to recovery (milliseconds) | Slightly longer time to recovery (milliseconds).
Steps required for failover? | Failure is automatically detected by database nodes; SharePoint Foundation 2010 references the cluster so that failover is seamless and automatic. | Failure is automatically detected by the database; SharePoint Foundation 2010 is aware of the mirror location, if it has been configured correctly, so that failover is automatic.
Protection against failed storage? | Does not protect against failed storage, because storage is shared between nodes in the cluster. | Protects against failed storage because both the principal and mirror database servers write to local disks.
Storage types supported | Shared storage (more expensive). | Can use less-expensive direct-attached storage (DAS).
Location requirements | Members of the cluster must be on the same subnet. | Principal, mirror, and witness servers must be on the same LAN (up to 1 millisecond latency roundtrip).
Recovery model | SQL Server full recovery model recommended. You can use the SQL Server simple recovery model, but the only available recovery point if the cluster is lost will be the last full backup. | Requires SQL Server full recovery model.
Performance overhead | Some decrease in performance may occur while a failover is occurring. | High-availability mirroring introduces transactional latency because it is synchronous. It also requires additional memory and processor overhead.
Operational burden | Set up and maintained at the server level. | The operational burden is larger than clustering. Must be set up and maintained for all databases. Reconfiguring after failover is manual.

Service application redundancy strategies

The redundancy strategy you follow for protecting service applications that run in a farm varies, depending on where the service application stores data.

Service applications that store data in databases

To help protect service applications that store data in databases, you must follow these steps:

  1. Install the service on multiple application servers to provide redundancy within the environment.

  2. Configure SQL Server clustering or mirroring to protect the data.

The following service applications store data in databases:

  • Business Data Connectivity service application

  • Application Registry service application

    We do not recommend mirroring the Application Registry database, because it is only used when upgrading Windows SharePoint Services 3.0 Business Data Catolog information to SharePoint Foundation 2010.

  • Usage and Health Data Collection service application

    Note:

    We recommend that you do not mirror the Usage and Health Data Collection service application Logging database.

  • Microsoft SharePoint Foundation Subscription Settings service

Redundancy and failover between closely located data centers configured as a single farm ("stretched" farm)

Some enterprises have data centers that are located close to one another with high-bandwidth connections so that they can be configured as a single farm. This is called a "stretched" farm. For a stretched farm to work, there must be less than 1 millisecond latency between SQL Server and the front-end Web servers in one direction, and at least 1 gigabit per second bandwidth.

In this scenario, you can provide fault tolerance by following the standard guidance for making databases and service applications redundant.

The following illustration shows a stretched farm.

Stretched farm

See Also

Other Resources

Resource Center: Business Continuity Management for SharePoint Foundation 2010


Plan for disaster recovery (SharePoint Foundation 2010)
See Also

This article describes key decisions in choosing disaster recovery strategies for a Microsoft SharePoint Foundation 2010 environment.

In this article:

  • Disaster recovery overview

  • Choose a disaster recovery strategy

  • Planning for cold standby

  • Planning for warm standby

  • Planning for hot standby data centers

  • System requirements for disaster recovery

Disaster recovery overview

For the purposes of this article, we define disaster recovery as the ability to recover from a situation in which a data center that hosts SharePoint Foundation becomes unavailable.

The disaster recovery strategy that you use for SharePoint Foundation must be coordinated with the disaster recovery strategy for the related infrastructure, including Active Directory domains, Exchange Server, and Microsoft SQL Server. Work with the administrators of the infrastructure that you rely on to design a coordinated disaster recovery strategy and plan.

The time and immediate effort to get another farm up and running in a different location is often referred to as a hot, warm, or cold standby. Our definitions for these terms are as follows:

Hot standby A second data center that can provide availability within seconds or minutes.

Warm standby A second data center that can provide availability within minutes or hours.

Cold standby A second data center that can provide availability within hours or days.

Disaster recovery can be one of the more expensive requirements for a system. The shorter the interval between failure and availability and the more systems you protect, the more complex and costly a disaster recovery solution is likely to be. When you invest in hot or warm standby data centers, costs include:

  • Additional hardware and software, which often increase the complexity of operations between software applications, such as custom scripts for failover and recovery.

  • Additional operational complexity.

The costs of maintaining hot or warm standby data centers should be evaluated based on your business needs. Not all solutions within an organization are likely to require the same level of availability after a disaster. You can offer different levels of disaster recovery for different content, services, or farms — for example, content that has high impact on your business, or search services, or an Internet publishing farm.

Disaster recovery is a key area in which information technology (IT) groups offer service level agreements (SLAs) to set expectations with customer groups. Many IT organizations offer a variety of SLAs that are associated with different chargeback levels.

When you implement failover between server farms, we recommend that you first deploy and tune the core solution within a farm, and then implement and test disaster recovery.

Choose a disaster recovery strategy

You can choose among many approaches to provide disaster recovery for a SharePoint Foundation environment, depending on your business needs. The following examples show why companies might choose cold, warm, or hot standby disaster recovery strategies.

  • Cold standby disaster recovery strategy: A business ships backups to support bare metal recovery to local and regional offsite storage on a regular basis, and has contracts in place for emergency server rentals in another region.

    Pros:

    • Often the cheapest option to maintain, operationally.

    • Often an expensive option to recover, because it requires that physical servers be configured correctly after a disaster has occurred.

    Cons: The slowest option to recover.

  • Warm standby disaster recovery strategy: A business ships virtual server images to local and regional disaster recovery farms.

    Pros: Often relatively inexpensive to recover, because a virtual server farm can require little configuration upon recovery.

    Cons: Can be very expensive and time consuming to maintain.

  • Hot standby disaster recovery strategy: A business runs multiple data centers, but serves content and services through only one data center.

    Pros: Often relatively fast to recover.

    Cons: Can be quite expensive to configure and maintain.

Important:

No matter which disaster recovery solution you decide to implement for your environment, you are likely to incur some data loss.

Planning for cold standby data centers

In a cold standby disaster recovery scenario, you can recover by setting up a new farm in a new location, (preferably by using a scripted deployment), and restoring backups. Or, you can recover by restoring a farm from a backup solution such as Microsoft System Center Data Protection Manager 2007 that protects your data at the computer level and lets you restore each server individually. This article does not contain detailed instructions for how to create and recover in cold standby scenarios. For more information, see:

  • Restore a farm (SharePoint Foundation 2010)

  • Restore customizations (SharePoint Foundation 2010)

Planning for warm standby data centers

In a warm standby disaster recovery scenario, you can create a warm standby solution by making sure that you consistently and frequently create virtual images of the servers in your farm that you ship to a secondary location. At the secondary location, you must have an environment available in which you can easily configure and connect the images to re-create your farm environment.

This article does not contain detailed instructions for creating warm standby solutions. For more information about how to plan to deploy farms by using virtual solutions, see Plan for virtualization (SharePoint Foundation 2010).

Planning for hot standby data centers

In a hot standby disaster recovery scenario, you can set up a failover farm to provide disaster recovery in a separate data center from the primary farm. An environment that has a separate failover farm has the following characteristics:

  • A separate configuration database and Central Administration content database must be maintained on the failover farm.

  • All customizations must be deployed on both farms.

    Note:

    We recommend that you use scripted deployment to create the primary and failover farm by using the same configuration settings and customizations.

  • Updates must be applied to both farms, individually.

  • SharePoint Foundation content databases can be successfully asynchronously mirrored or log-shipped to the failover farm.

    Note:

    SQL Server mirroring can only be used to copy databases to a single mirror server, but you can log-ship to multiple secondary servers.

  • Service applications vary in whether they can be log-shipped to a farm. For more information, see Service application redundancy across data centers later in this article.

This topology can be repeated across many data centers, if you configure SQL Server log shipping to one or more additional data centers.

Consult with your SAN vendor to determine whether you can use SAN replication or another supported mechanism to provide availability across data centers.

The following illustration shows primary and failover farms before failover.

Primary and failover farms before failover

Primary and failover farms before failover

Service application redundancy across data centers

To provide availability across data centers for service applications, we recommend that for the services that can be run cross-farm, you run a separate services farm that can be accessed from both the primary and the secondary data centers.

For services that cannot be run cross-farm, and to provide availability for the services farm itself, the strategy for providing redundancy across data centers for a service application varies. The strategy employed depends on whether:

  • There is business value in running the service application in the disaster recovery farm when it is not in use.

  • The databases associated with the service application can be log-shipped or asynchronously mirrored.

  • The service application can run against read-only databases.

The following sections describe the disaster recovery strategies that we recommend for each service application. The service applications are grouped by strategy.

Databases that can be log-shipped or asynchronously mirrored

After a service application has been initially deployed on a secondary farm, the databases that support the following service applications can be asynchronously mirrored or log-shipped across farms:

  • Usage and Health Data Collection service application

    Databases: Logging

    Note:

    It is possible to log-ship or mirror the Logging database. However, we recommend that you do not run the Usage and Health Data Collection service on the disaster recovery farm, and that you do not mirror nor log-ship the Logging database.

Service applications and databases that cannot be log-shipped or asynchronously mirrored

The following service applications must be deployed on both the primary and failover farms, and cannot be log-shipped or asynchronously mirrored. For most of these service applications, we recommend that you deploy them and then verify that the failover farm has the same configuration settings as the primary farm. If configuration changes that affect the service are made on the primary farm, you must update the failover farm.

  • Application Registry service application

    Databases: Application Registry service

    Log-shipping the Application Registry service database is not supported.

  • Business Data Connectivity service application

    Databases: Business Data Connectivity

  • Microsoft SharePoint Foundation Subscription Settings service application

    Database: Subscription Settings

    Note:

    Log-shipping the Subscription Settings database is not supported.

System requirements for disaster recovery

In an ideal scenario, the failover components and systems match the primary components and systems in all ways: platform, hardware, and number of servers. At a minimum, the failover environment must be able to handle the traffic that you expect during a failover. Keep in mind that only a subset of users may be served by the failover site. The systems must match in at least the following:

  • Operating system version and all updates

  • SQL Server versions and all updates

  • SharePoint 2010 Products versions and all updates

Although this article primarily discusses the availability of SharePoint 2010 Products, the system uptime will also be affected by the other components in the system. In particular, make sure that you do the following:

  • Ensure that infrastructure dependencies such as power, cooling, network, directory, and SMTP are fully redundant.

  • Choose a switching mechanism, whether DNS or hardware load balancing, that meets your needs.

See Also

Other Resources

Resource Center: Business Continuity Management for SharePoint Foundation 2010


Virtualization planning (SharePoint Foundation 2010)

This section contains articles that are designed to help you plan and implement a server virtualization solution for Microsoft SharePoint Foundation 2010 server farms.

In this section:

  • Virtualization support and licensing (SharePoint Foundation 2010)

  • Hyper-V virtualization requirements (SharePoint Foundation 2010)

  • Plan for virtualization (SharePoint Foundation 2010)

  • Hyper-V performance tests (SharePoint Foundation 2010)


Virtualization support and licensing (SharePoint Foundation 2010)
See Also

This article provides support and licensing information for using server virtualization technologies to deploy Microsoft SharePoint 2010 Products in a virtual environment.

Support

Microsoft SharePoint Foundation 2010 supports virtualization that includes any required technologies, such as Microsoft SQL Server, when the products and technologies are deployed in a Windows Server 2008 Hyper-V technology or Microsoft Hyper-V Server 2008 environment or any virtualization solution that is validated under the Server Virtualization Validation Program (http://go.microsoft.com/fwlink/p/?LinkId=125649).

SharePoint Foundation 2010 is not supported on virtualization environments that are not explicitly referenced under the Server Virtualization Validation Program.

Licensing

You must ensure that your virtualization solution meets all the licensing requirements.

Microsoft SharePoint 2010 Products

Every element of a Microsoft SharePoint Foundation farm that is installed on a virtual machine must comply with the licensing requirements for SharePoint Foundation 2010 and related and supporting technologies. For more information about licensing SharePoint Foundation 2010, see Microsoft SharePoint 2010 Licensing Q&A (http://go.microsoft.com/fwlink/p/?LinkId=210179).

For information about licensing other Microsoft Server products in a virtual environment, see LICENSING MICROSOFT SERVER PRODUCTS IN VIRTUAL ENVIRONMENTS (http://go.microsoft.com/fwlink/p/?LinkId=212535).

See Also

Other Resources

Resource Center: Virtualization for SharePoint Foundation 2010


Support and licensing for Windows Azure (SharePoint Foundation 2010)
See Also

Published: June 12, 2012

This article provides support and licensing information for deploying Microsoft SharePoint Foundation 2010 on the Windows Azure platform.

Support

SharePoint Foundation 2010 supports the hosted virtualization solution of Microsoft, as well as required technologies, such as Microsoft SQL Server, when these products and technologies are deployed on the Windows Azure platform.

Important:

We do not support Microsoft FAST Search Server 2010 for SharePoint deployments on Windows Azure.

Licensing

You must ensure that your virtualization solution meets all the licensing requirements. For information about License Mobility, see License Mobility Through Software Assurance

Microsoft SharePoint 2010 Products

Every element of a Microsoft SharePoint Foundation farm that is installed on a virtual machine must comply with the licensing requirements for SharePoint Foundation 2010 and related and supporting technologies. For more information about licensing SharePoint Foundation 2010, see Microsoft SharePoint 2010 Licensing Q&A (http://go.microsoft.com/fwlink/p/?LinkId=210179).

Windows Azure and other Microsoft Server Products

For more information about Windows Azure licensing and costs, go to the Windows Azure site.

For information about licensing other Microsoft Server products in a virtual environment, see LICENSING MICROSOFT SERVER PRODUCTS IN VIRTUAL ENVIRONMENTS (http://go.microsoft.com/fwlink/p/?LinkId=212535).

See Also

Other Resources

Resource Center: Installation and Deployment for SharePoint 2010


Hyper-V virtualization requirements (SharePoint Foundation 2010)
See Also

This article provides hardware and software requirements for using hardware-based virtualization. Although Windows Server 2008 Hyper-V technology is the focal point of this document, the basic hardware requirements for enabling hardware-based virtualization also apply to third-party virtualization technologies that are certified by Microsoft.

Hardware

The requirements for hardware-based virtualization are as follows:

  • Hardware-assisted virtualization, which is available in processors that include a virtualization option—specifically processors with Intel Virtualization Technology (Intel VT) or AMD Virtualization (AMD-V) technology.

  • Hardware-enforced Data Execution Prevention (DEP) is available and enabled.

You can use one of the following tools to determine if the processor on an existing server supports Hyper-V:

  • AMD Hyper-V Compatibility Check Utility (.zip file) (http://go.microsoft.com/fwlink/p/?LinkId=150561)

  • Intel Processor Identification Utility (Windows Version) (http://go.microsoft.com/fwlink/p/?LinkId=150562)

Software

One of the following Microsoft products is required for Hyper-V:

  • Windows Server 2008 (all editions of Windows Server 2008, except for Windows Server 2008 for Itanium-Based Systems, Windows Web Server 2008, and Windows Server 2008 Foundation)

  • Microsoft Hyper-V Server 2008

  • Windows Server 2008 R2 (all editions of Windows Server 2008 R2, except for Windows Server 2008 R2 for Itanium-Based Systems, Windows Web Server 2008 R2, and Windows Server 2008 R2 Foundation)

  • Hyper-V Server R2

We recommend Windows Server 2008 R2 for virtualization servers because of the many improvements introduced for Hyper-V, such as:

  • Live migration to move a running virtual machine from one cluster node to another

  • Significant gains in performance and scalability

  • Enhanced processor support

  • Enhanced virtual machine storage

  • Enhanced networking support

For more information, see What's New in Hyper-V in Windows Server 2008 R2 (http://go.microsoft.com/fwlink/p/?LinkID=155234).

See Also

Concepts

Virtualization support and licensing (SharePoint Foundation 2010)

Other Resources

Resource Center: Virtualization for SharePoint Foundation 2010


Plan for virtualization (SharePoint Foundation 2010)
See Also

This article describes the planning process to follow in order to successfully deploy Microsoft SharePoint Foundation 2010 in a virtual environment. Each step in the planning process includes links to the appropriate documentation. It is assumed that you have determined the SharePoint Foundation 2010 solution that you want to deploy in a virtual environment. On the surface, deploying a SharePoint Foundation 2010 farm on virtual machines is the same as deploying a farm on physical servers. However, deploying in a virtual environment involves a different level of planning that takes into account the characteristics of Windows Server 2008 Hyper-V technology as well as how virtual machines, the virtual network adapters, and virtual hard disks are implemented on a virtualization server.

Before you start developing your virtualization plan, we recommend that you read the Hyper-V Planning and Deployment Guide (http://go.microsoft.com/fwlink/p/?LinkId=187964).

Detailed information about the following subjects is out-of-scope for this article, but is provided in other articles:

  • Capacity management

  • Security requirements

  • Health and performance monitoring

  • Backup and recovery

A virtual environment consists of two interrelated layers, one physical and one virtual. A configuration change in either layer effects servers in the other layer. This interrelationship becomes evident when you plan for, deploy, and use SharePoint Foundation 2010 in a virtual environment.

Create a plan for deploying SharePoint Foundation 2010 in a virtual environment

You should approach planning for a virtual farm the same way as you would plan for a physical farm. Most, if not all, of the issues and requirements for deploying SharePoint Foundation 2010 on physical servers apply equally to virtual machines. Any decisions that you make, such as minimum processor or memory requirements, have a direct bearing on number of virtualization hosts required, as well as their ability to adequately support the virtual machines that you identify for the farm.

After you finish planning a physical farm, you have all the information you need to design virtualization architecture. Ideally, this architecture is as close as possible to the final virtualization solution that you intend to put into production. Realistically, the architecture is likely to change as you move through the deployment phase of the system lifecycle. In fact, you may determine that some farm server roles are not good candidates for virtualization.

The key planning steps, tasks, and references are summarized in following the procedure.

To create a virtualization plan

  1. Determine virtualization scope

    Determining the scope of farm virtualization is a key contributing factor to successfully implementing, managing, and evaluating your virtualization project. When determining scope, you have to decide whether you will virtualize some or the entire supporting virtual machine infrastructure.

    Use the following list of tasks to determine the scope of virtualization.

    • Task 1: Identify all the farms that are required to implement your solution. Take into consideration the fact that most solutions have several farm components. For example, an Internet-facing Web portal typically has a publishing farm, an authoring farm, and a testing or quality assurance farm.

    • Task 2: For each farm, determine the number of servers that are required as well as the role that each server will have in the farm.

    • Task 3: Identify which farms you want to deploy in in a virtual environment.

    Refining the scope of a solution also refines the scope of a deployment, which makes it easier to implement and manage. For more information, see Site and solution planning (SharePoint Foundation 2010). In many cases, solutions share common elements; however, each solution may have its own requirements. For more information, see Fundamental site planning (SharePoint Foundation 2010). The article shows one of the popular solutions.

    Note:

    Expect to refine the scope of your solution as you move through the phases of deploying your farm in a production environment.

  2. Identify servers to virtualize

    Identify servers that are good candidates for virtualization. From a technical and Microsoft support perspective, all SharePoint servers can be virtualized. The decision to virtualize a particular farm server should be based on:

    • Corporate compliance policies (for example, legal and technical)

    • Benefits derived from server consolidation, such as reduced power consumption and physical space requirements. For more information, see Server virtualization (http://go.microsoft.com/fwlink/p/?LinkId=187965).

    • Capacity requirements (see next planning step)

  3. Identify capacity requirements for each farm server

    Determine the resource requirements for each farm server as if it was a physical server. Take into account specialized server roles, such as hosting Enterprise Search components. You need to specify the amount of resources needed for each of the following server components:

    • Memory

    • Number of processors and minimum clock speed

    • Number and size of hard disks

    • Number of network adapters and their required throughput speed

  4. Determine if virtual machine can meet physical requirements.

    You have to determine whether each virtual machine that you identified in Step 3 can meet the capacity requirements of a corresponding physical server. At a minimum, complete the following tasks:

    • Task 1: Assess the memory requirement in the context of available virtualization host capacity.

    • Task 2: Assess the processor requirement. Hyper-V has a hard limit of four virtual processors per virtual machine. If a physical farm server requires eight processors, determine whether this requirement can be met by scaling out the number of virtual machines in a farm.

    • Task 3: Assess the virtual machine storage requirement in the context of local physical storage or SAN.

  5. Determine virtualization host requirements

    Determine the minimum host requirements (memory, number of cores, number and size of local hard drives, number of network adapters)Also consider and plan for the following:

    • Scalability: Determine if you can add more CPUs, more memory, more hard disks, and more network adapters to the host computer.

      Important:

      Depending on the manufacturer and computer model, you may not be able to increase capacity. You need to have this information before you use or purchase a server.

    • Extra host capacity: Determine whether or not the host has the capacity to scale up existing virtual machines, or to add additional virtual machines. This is very important if you plan to use Hyper-V failover clustering, quick migration, or live migration.

    Important:

    Plan for peak load and determine how short term spikes in load will be handled.

  6. Design virtualization architecture

    A well-designed architecture is required for a successful solution. For SharePoint Foundation 2010, a basic three-tier topology provides the foundation for all the solutions. The following elements form a good design that is based on the recommended foundation topology:

    • Good overall performance

    • Ease of maintenance and upgrade

    • Flexibility

    • Scalability

    • High availability

    A virtualization architecture model consists of the virtualization hosts and the virtual machines that make up the farm topology. This model enables you to visualize the virtual environment that you plan to deploy.

    Note:

    Be prepared to refine the architecture as you move through the planning process. The following steps may dictate changes to the architecture.

  7. Identify storage requirements

    Determine how much local physical storage or SAN storage is required for Hyper-V-related storage such as configuration files, Virtual Hard Disks (VHDs), and snapshots.

  8. Identify backup and recovery requirements

    In addition to the farm servers, you have to plan backup and recovery for all or part of a farm. For more information, see Backup and recovery (SharePoint Foundation 2010).

  9. Determine high availability requirements and design a solution

    Identify approaches for achieving high availability for Web servers, application servers, and databases. Typical strategies include the following:

    • Redundant hardware and servers

    • Hot-swappable components

    • Failover clustering for virtual and physical servers. For more information, see Hyper-V: Using Hyper-V and Failover Clustering (http://go.microsoft.com/fwlink/p/?LinkId=187967).

    • Clustering or mirroring for database servers. For more information, see Plan for availability (SharePoint Foundation 2010).

  10. Identify health and capacity indicators for monitoring the virtual environment.

    Combine the key indicators that you derived in the previous steps with the planning you did for SharePoint Foundation 2010. For more information, see Server farm and environment planning (SharePoint Foundation 2010) . You have to determine all the health and capacity indicators in order to collect measurements from the following objects in the virtual environment:

    • Virtual machines with SharePoint Foundation 2010 installed

    • Virtual machines that are not part of the farm, such as a firewall server

    • Virtualization hosts

    • Network components

    After you start to collect data from the virtual environment, you can create a baseline, which can be used to assess and tune the virtual environment during deployment and after the farm goes into production.

  11. Create a deployment plan for the deployment phase of the system lifecycle.

    For more information, see the SharePoint 2010 Products Deployment model, available in the Technical diagrams (SharePoint Foundation 2010) article.

  12. Create a maintenance plan

    Create a maintenance plan that enables you to implement password changes and apply software updates, service packs, and hotfixes. This plan should include the virtual machines and the virtualization hosts.

See Also

Other Resources

Resource Center: Virtualization for SharePoint Foundation 2010


Hyper-V performance tests (SharePoint Foundation 2010)

Published: November 18, 2010

This article describes the results of Microsoft SharePoint Foundation 2010 performance testing in a virtualized computing environment that uses Windows Server 2008 Hyper-V technology.

In this article:

  • Test goals and description

  • Hardware platform

  • Software platform

  • Test farm topology

  • Test methodology

  • Results of tests

  • Conclusions and recommendations

Test goals and description

In addition to the broad goal of determining how Microsoft SharePoint Foundation performs when virtualized in a Hyper-V environment, we wanted to identify the following issues:

  • Performance bottlenecks.

  • Performance gains when servers that are running SharePoint Foundation are virtualized on host servers that support new technologies such as hyper-threading (HT) and Second Level Address Translation (SLAT).

  • Issues or limitations that have to be considered when virtualizing SharePoint Foundation 2010.

The following four groups of tests, which are documented in this article, are designed to meet the test goals:

  • Comparison of virtual machine and physical computer performance

    These tests show the performance results when the same load is applied to a physical computer and a virtual machine configuration.

  • Virtual machine memory scale up

    These tests show how performance is affected by increasing the memory allocation on a virtual machine (VM).

  • Single host scale out

    These tests show how performance is affected when the number of VMs that are deployed on a single host is increased.

  • Virtual machine scale out

    These tests show how performance is affected when the number of virtual machines that are deployed on one or more hosts is increased.

Important:

When you interpret the results of the previous tests and apply them to your own environment, remember that our tests were conducted on specific hardware that used a specific farm topology and a specific workload.

Hardware platform

Most groups of tests used the following two sets of Hewlett Packard (HP) hardware to host our virtual machines:

  • HP BL680c-G5 (blade server)

  • HP ProLiant SE326M1 (Mach 1 server)

Blade server tests were run for the benefit of customers who are considering repurposing existing server technology for hosting VMs instead of buying new servers.

The Mach 1 server was used to show the performance characteristics of an Intel chipset that supports hyper-threading (Intel Hyper-Threading (HT)). The Mach 1 chipset also supports Intel VT Extended Page Tables (NPT) technology, which Windows Server 2008 R2 Hyper-V can use to implement Second Level Address Translation (SLAT). For more information, see What's New in Hyper-V in Windows Server 2008 R2 (http://go.microsoft.com/fwlink/p/?LinkId=155234).

HP blade servers

The following table provides a summary of the hardware which tested SharePoint Foundation on HP blade servers.

Quantity | Manufacturer and model | Role | CPU | Memory | Network adapter | Storage
4 | HP BL680c-G5 | SQL Server database server, Hyper-V host, physical server | Intel X7450 with 24 cores, 2.24 GHz CPU | 128 GB | Dual GbE | SAN
8 | Dell PE R710 | Workload controller, workload client, virtual domain controller | Intel X5550 with 8 cores, 2.66 GHz CPU | 72 GB | Dual GbE | SAS (multiple RAID levels)
1 | F5 BigIP 6800 | Load balancing |  |  |  |

HP Mach 1 servers

The following table provides a summary of the hardware which tested SharePoint Foundation on HP Mach 1 servers.

Quantity | Manufacturer and model | Role | CPU | Memory | Network adapter | Storage
5 | HP ProLiant SE326M1 | SQL Server database server, Hyper-V host, virtual domain controller, physical server | Intel L5520 with 8 cores, 2.26 GHz CPU, HT capable | 48 GB | Dual GbE | SAS (RAID 10)
5 | HP ProLiant DL 380 G5 | Workload controller, workload client | Intel 5150 with 4 cores, 2.66 GHz CPU | 32 GB | Dual GbE | SAS (RAID 10)
1 | F5 BigIP | Load balancing |  |  |  |

Software platform

The 64-bit versions of the following products were used for the performance tests:

  • Windows Server 2008 R2 Enterprise

  • SQL Server 2008 R2 Enterprise

  • Microsoft SharePoint Foundation 2010

  • Microsoft Visual Studio 2008 Team System (VSTS)

  • Microsoft Visual Studio Team System 2008 Test Edition

Test farm topology

The same three-tier farm topology was used on both sets of HP server hardware. This topology was selected because it supports the following general Microsoft SharePoint Foundation roles: front-end Web servers, an application server, and a database server.

Note:

The database was hosted on a physical server for all the tests.

Test methodology

The test mix, which is derived from the usage pattern identified on Microsoft internal SharePoint Foundation servers, consisted of the following tasks:

  • Create, use, update, and delete

  • Page views such as list views and document libraries

  • Browser-based views of Word, Excel, and PowerPoint by using Microsoft Office Web Apps

  • Simulated traffic between the server and rich clients such as Microsoft Word 2010, Microsoft Excel 2010, and Microsoft PowerPoint 2010 as an application.

The previous tasks were tested by using 84 separate actions that ranged from .02% of the test mix to 80% of the test mix. Loads were stepped (1 to 10) for different groups of tests and the number of simulated users ranged from 1 to 1000 within a connection-per-user model.

After a warm-up time of 10 minutes, the tests ran for 10 minutes and collected data every 10 seconds.

Two key performance indicators were used for each of the four groups of tests: maximum passed request per second (Max. passed RPS) and the time taken for each request, expressed as milliseconds.

Results of tests

The results of our testing are specific to the hardware and workload that was described previously, and results are not indicative of product performance in all cases. The test results show the potential tradeoffs when you are deciding to virtualize a SharePoint Foundation 2010 configuration with a particular usage pattern. It is very important to interpret our test results in the context of your infrastructure and your implementation of SharePoint Foundation.

Comparison of virtual machine and physical computer performance

These tests show the performance results when the same load is applied to a physical computer and a range of virtual machines.

This group of tests had the following goals:

  • To determine the decrease in performance or gain when virtualizing a physical server

  • To determine the virtual configuration that is required to achieve the same performance level as a physical computer

  • To determine the amount of resource overhead or degree of decreased performance when the workload that is applied to a physical server is tested on a virtual machine.

HP blade server

The physical server is used as a front-end Web server that has 24 cores and 24,576 MB of memory. For the virtual environment, six VMs are used as Web servers on two hosts. Each VM has four virtual processors and 15,000 MB of memory.

Virtual machine and physical server performance

Notice that the following results on the previous graph:

  • The Max. passed RPS is approximately 20% higher on the physical computer.

  • The Avg. response time (ms) is approximately 15% lower on the physical computer.

  • The Web server CPU usage (%) for the virtual machines is approximately 9% lower than on the physical server.

HP Mach 1 server

The physical server is used as a front-end Web server that has eight cores and 49,152 MB of memory. For the virtual environment, four VMs are used as Web servers on two hosts. Each VM has the configuration shown in the following list.

  • Four virtual processors

  • 8,192 MB of memory

  • Two volumes using fixed size VHD files

The following graph shows performance results for VMs with hyper-threading enabled (HT on), VMs with hyper-threading disabled (HT off), and a physical computer.

VM and physical server performance

Notice that the following results on the previous graph:

  • When hyper-threading is enabled (HT on):

    • The Max. passed RPS is approximately 18% higher on the physical computer

    • The Avg. response time (ms) is approximately 15% lower on the physical computer.

    • The Web server CPU usage (%) is approximately 46% lower than a VM with hyper-threading disabled, and approximately 36% lower than the physical computer.

  • When hyper-threading is disabled (HT off):

    • The Max. passed RPS is approximately 29% higher on the physical computer.

    • The Avg. response time (ms) is approximately 20% lower on the physical computer.

Virtual machine memory scale up

In this group of tests, the front-end Web servers are configured to use different amounts of memory to determine how scaling up memory on the VMs affects performance. The test uses four front-end Web servers on two host servers (HP blade server). Each VM is configured to use four virtual processors and two volumes using pass-through disks.

The following graph shows the average response time and requests per second (RPS) for VMs that have a starting configuration of 2,048 megabytes (MB) of RAM and are scaled up to 15,000 MB of RAM.

VM scale up performance results on blade servers

The previous graph shows that there is very little variation in CPU usage for the hosts, SQL Server, and the VSTS agent.

From a scale-up perspective, there is a minimal performance gain when scaling from 2 GB of memory to 4 GB of memory. Beyond the 4 GB memory allocation on the virtual machines there is no significant performance gain for the test workload.

Single host scale out

These tests show how performance is affected when the number of VMs is increased on a single host. The tests also show the effect on performance when the host cores are oversubscribed.

HP blade server

This test uses up to eight VMs and each VM has the configuration shown in the following list.

  • Four virtual processors

  • 15,000 MB of memory

  • Two volumes using pass-through disks

The following graph shows that optimal throughput is achieved by using six front-end Web servers, which is a 1:1 mapping of logical processors to virtual processors. When more VMs are added, performance decreases. The only observed bottleneck is CPU contention when the CPU is oversubscribed.

Single host scale out performance results

The test mix used on the HP blade servers was then run two times on the Mach 1 servers. On the first run hyper-threading was enabled, and on the second run hyper-threading was disabled.

HP Mach 1 server

The test uses up to four VMs and each VM has the configuration shown in the following list.

  • Four virtual processors

  • 8,192 MB of memory

  • Two volumes using fixed size VHD files

The following graph shows performance results when hyper-threading is enabled on the host.

Scale out performance results for single host

The following graph shows performance results when hyper-threading is disabled.

Scale out performance results for single host

The two previous graphs indicate that there is no need to oversubscribe the host CPU because there is no significant performance gain or loss.

Another key outcome of these tests is the increase in compute headroom, which is indicated by "Web server host logical CPU usage". By comparing this value in both graphs you can see that the increase in compute capacity ranges from 10% to 25% depending on the level of CPU oversubscription.

Virtual machine scale out

This group of tests shows the effect on performance when the number of virtual machines is scaled out across hosts and bottlenecks are identified. In addition, virtual machine roles are mixed to determine the effect on performance.

Virtual machine scale out performance results

The test uses a range of host servers (2-3) and a range of virtual machines (6-12) deployed across the hosts. Each VM has the configuration shown in the following list.

  • Two virtual processors

  • 15,000 MB of memory

  • Two volumes using pass-through disks

The following graph shows performance when virtual machines are scaled out.

Virtual machine scale out performanc results

Notice that the following results on the previous graphs:

  • With dedicated roles for the virtual machines, the performance gain is noticeable when the number of hosts and the number of VMs is scaled up to three hosts with 12 VMs. Using Max. passed RPS as a benchmark, performance is approximately 2.5 times better. However, the average response time per request degrades as indicated by the approximately 26% increase in response time.

  • With mixed roles for the virtual machines and using the number of hosts and the same number of VMs, Max. passed RPS improves by approximately 31%. Additionally, the Avg. response time (ms) is improved, as indicated by the drop of approximately 25%. Typically there is a lower duty cycle on an application server, which enables Hyper-V to use the additional resources for other VMs that are running on the host.

An additional performance observation is that there was a significant increase in SQL Server CPU usage when the tests were run with mixed virtual machine roles. This increase was approximately 35%.

HP Mach 1 server

The test uses a range of host servers (2-4) and a range of virtual machines (3-9) deployed across the hosts. Each VM has the configuration shown in the following list.

  • Four virtual processors

  • 8,192 MB of memory

  • Two volumes using fixed size VHD files

The following graph shows performance with hyper-threading enabled on the host.

Virtual machine scale out performanc results

Notice the following results on the previous graph:

  • With dedicated virtual machine roles, the performance gain is noticeable when the number of hosts and the number of VMs are scaled up to three hosts with six VMs. Using Max. passed RPS as a benchmark, performance is approximately 42% better and the average response time per request decreases by approximately 21%.

  • When the number of hosts and number of virtual machines is scaled up again to four hosts and nine virtual machines, Max. passed RPS improves by approximately 57% compared to the three host and six VM configuration. Compared to the HP blade servers the Avg. response time (ms) only increases by approximately 4%.

  • SQL Server CPU usage (%) follows the same pattern as on the HP blade servers, increasing linearly to 41%.

Conclusions and recommendations

The following table summarizes the conclusions drawn from our tests which are based on a specific workload, the hardware that was used, and the virtual machines used.

Group of tests | Host hardware | Conclusions
Comparison of virtual machine and physical computer performance | HP blade server | The performance gain on a physical computer is 15% (RPS) and 42% (response time per request).
 | HP Mach 1 server | The performance gain on a physical computer is approximately 15% (RPS) and 18% (response time per request).
Virtual machine memory scale up | HP blade server | There is no benefit to additional memory allocation beyond 4 GB for a virtual machine.
Single host scale out | HP blade server | A 1:1 ratio of logical processors to virtual processors produces the maximum throughput. Oversubscribing the CPU deteriorates performance.
 | HP Mach 1 server | This hardware can support oversubscribing the CPU without a significant performance penalty. The amount of compute headroom is determined by the level of CPU oversubscription.
Virtual machine scale out | HP blade server | Microsoft SharePoint Foundation 2010 scales linearly to at least three hosts and 12 virtual front-end Web servers. Maximum throughput is achieved by mixing Microsoft SharePoint Foundation roles on each host.
 | HP Mach 1 server | Microsoft SharePoint Foundation 2010 scales linearly to at least four hosts and nine virtual front-end Web servers.

In our test environment we observed a decline in performance when SharePoint Foundation roles are virtualized. This is the result of Hyper-V overhead as well as operating system overhead on each virtual machine.

The amount of virtualization overhead and reduced performance (relative to a similarly configured physical computer) depends on the size (for example, the amount of memory, and the number of cores) as well as the features of the host hardware chipset (for example, support for Second Level Address Translation and hyper-threading.)

We recommend that you clearly understand what you hope to gain by virtualizing all or some of a SharePoint farm. After the decision to virtualize is made, thorough planning and testing is required to fully understand all performance options and implications.

You can use the results of tests in this article as a guide. However, results are not definitive and the results are for a specific workload in a specific physical environment.


Performance and capacity test results and recommendations (SharePoint Foundation 2010)
See Also

Published: February 3, 2011

This section contains an article that describes the performance and capacity impact of Microsoft SharePoint Foundation 2010 search. This article includes information about the performance and capacity characteristics of the search and how it was tested by Microsoft, including:

  • Test farm characteristics

  • Test results

  • Recommendations

  • Troubleshooting performance and scalability

The following table describes the available article.

Title | Description
Estimate performance and capacity requirements for SharePoint Foundation 2010 Search | Provides guidance on how to plan for search in SharePoint Foundation 2010. View the article at Estimate performance and capacity requirements for SharePoint Foundation 2010 Search.

See Also

Other Resources

Capacity management and sizing for SharePoint Server 2010


Estimate performance and capacity requirements for SharePoint Foundation 2010 Search

Published: July 1, 2010

This article discusses capacity planning information for a deployment of Microsoft SharePoint Foundation 2010 search.

In this article:

  • Introduction

  • Test farm characteristics

  • Health and performance data

  • Test results

  • Recommendations

  • Troubleshooting performance and scalability

Introduction

This article describes a specific deployment of SharePoint Foundation 2010 and includes the following specifications that were used during the performance and capacity testing of SharePoint Foundation 2010 :

  • Test environment specifications, such as hardware, farm topology, and configuration

  • The workload used for data generation that includes the number and class of users, and farm usage characteristics

  • Test farm dataset, which includes database contents, search indexes, and external data sources

  • Health and performance data that is specific to the tested environment

This article also contains common test data and recommendations for how to determine the hardware, topology, and configuration that you need to deploy a similar environment, and how to optimize the environment for appropriate capacity and performance characteristics.

SharePoint Foundation 2010 Search provides basic search functionality for local SharePoint Foundation content. If you need more advanced search functionality, such as indexing local shared folders and remote SharePoint Foundation or HTTP content, use Microsoft Search Server Express 2010 or Microsoft SharePoint Server 2010 search.

This article describes how to do the following:

  • Define performance and capacity targets for the environment.

  • Plan the hardware that is required to support the number of users and the features that you intend to deploy.

  • Design the physical and logical topology for optimal reliability and efficiency.

  • Test, validate, and scale up or scale out the environment to achieve performance and capacity targets. To increase the capacity and performance of one of the starting-point topologies, you can do one of two things. You can either scale up by increasing the capacity of the existing servers or scale out by adding additional servers to the topology.

  • Monitor the environment for key indicators.

Test farm characteristics

This section describes the scenario of the test; the dataset that was used during the testing; the workloads that were put on SharePoint Foundation during performance gathering; the hardware that was used during the testing; and the topology for how that hardware was deployed.

This SharePoint Foundation Search scenario describes a typical search deployment, with the following characteristics:

  • Search is provided for the SharePoint Foundation content in the farm. No external content can be added to the index (for example, intranet Web sites or file systems).

  • Search can be run on only one server in the farm at a time. Scaling out is not supported.

  • Limited system administration is available for search.

Dataset

This section describes the test farm dataset, which includes database contents and sizes, search indexes, and external data sources.

Search index size (number of items) | 5677481
Size of search database | 54 GB
Size of search log file | 2 GB
Size of content database | 161 GB
Size of content database log file | 10.6 GB
Size of index partition | 23.7 GB
Total number of search databases | 8
Other databases that were used during performance and capacity testing of SharePoint Foundation 2010 | SharePoint_Config; SharePoint_AdminContent; State_Service; Bdc_Service_db; WSS_UsageApplication; WSS_Content

Hardware settings and topology

This section describes the kinds of computer hardware that we used in our lab and the farm configuration topology that we used in our tests.

Lab hardware and topology

This section describes the hardware that was used for testing.

Important:

Because the farm was running pre-release versions of SharePoint Foundation 2010, the hardware that was used has more capacity than is required under more typical circumstances.

Application server and content server

Server | Combined
Processors | 1px4c@ 3 GHz
RAM | 16 GB
Operating system | Windows Server 2008 R2, 64-bit
Storage | 6 x 450 GB serial attached SCSI (SAS)
Number of network adapters | 2
Network adapter speed | 1 gigabit
Authentication | NTLM
Load balancer type | None
Software version | SharePoint Foundation 2010 (pre-release version)
Services running locally | Microsoft SharePoint Foundation Workflow Timer Service; SharePoint Foundation Search
Object cache settings | Default (100-MB maximum); cache for 60 seconds; clmq multi: 3

Microsoft SQL Server computer

Server | Combined
Processors | 2px4c@ 3 GHz
RAM | 16 GB
Operating system | Windows Server 2008 R2, 64-bit
Storage | 6 x 450 GB SAS
Number of network adapters | 2
Network adapter speed | 1 gigabit
Authentication | NTLM
Load balancer type | None
Software version | SQL Server 2008 Enterprise
Services running locally | SQL Server Service
Usage database location | Shared drive with other databases

Topology

The test farm is a two-server farm. One server is the Web and application server, and the second server is the database server.

Topology of the test farm

Workload

This section describes the workload used for data generation. Workload characteristics include the number of users and farm usage characteristics.

Workload characteristics | Value
High-level description of workload (collaboration, Web content management, social) | Search farm and content farm
Average queries per minute | Not applicable
Average concurrent users | Not applicable
Total number of queries per day | Not applicable
Timer job load | Timer jobs: Immediate Alerts, SharePoint Foundation Search Refresh, Health Analysis Job

Health and performance data

This section provides health and performance data that is specific to the test environment.

Query performance data

The following measurements were taken with 140,000 items in the search index. The columns give the measurements taken during the specific test. The results are at the bottom of the table. The CPU memory and IOPs were read directly from the Perfmon counters. The latency was measured by using a Microsoft Visual Studio Team System 2008 Database Edition project, which executed a set of approximately 2,000 queries on a team site.

Metric category | Scorecard metric | Query test
CPU | Average SQL Server CPU | 21.83
Performance counters | Average front-end Web server, query server, indexer CPU | 95.84
 | ASP.NET requests queued (average of all front-end Web servers) | Not applicable
 | SQL Server locks: average wait time (ms) | 0.342
 | SQL Server locks: lock wait time (ms) | 0.171
 | SQL Server locks: deadlocks/sec | 0
 | SQL Server latches: average wait time (ms) | 0.147
 | SQL Server compilations/sec | 191.75
 | SQL Server statistics: SQL Server recompilations/sec | 0.075
 | Average disk queue length (query server) | 0.007
 | Disk queue length: reads (query server) | Not applicable
Test results | Disk queue length: writes (query server) | 0.007
 | Disk reads/sec (query server) | 0.188
 | Disk writes/sec (query server) | 125.676
 | Average disk queue length (indexer, front-end Web server, query server) | 0.006
 | Disk queue length: reads (indexer, front-end Web server, query server) | Not applicable
 | Disk queue length: writes (indexer, front-end Web server, query server) | 0.003
 | Disk reads/sec (indexer, front-end Web server, query server) | 0.706
 | Disk writes/sec (indexer, front-end Web server, query server) | 11.79
 | Average memory used (indexer, front-end Web server, query server) | 14.129
 | Maximum memory used (indexer, front-end Web server, query server) | 14.331
 | Cache hit ratio (SQL Server) | 100
Test results | Query UI latency (75th percentile) (sec) | 0.128
 | Query UI latency (95th percentile) (sec) | 0.151
 | Query throughput (80 user load) (requests/sec) | 60.86

Crawl performance data

The following measurements were taken during full crawls of the given content source. (Content source size is given in millions of items.) The columns show the measurements taken during the specific crawl, and the results are at the bottom of the table.

Metric category | Scorecard metric | Crawl test to reach 140,000 index size
CPU | Average SQL Server CPU | 9.48
Performance counters | Average front-end Web server, query server, indexer CPU | 87.32
 | ASP.NET requests queued (average of all front-end Web servers) | Not applicable
 | SQL Server locks: average wait time (ms) | 13.45
 | SQL Server locks: lock wait time (ms) | 11.39
 | SQL Server locks: deadlocks/sec | 0
 | SQL Server latches: average wait time (ms) | 3.03
 | SQL Server compilations/sec | 27.8
 | SQL Server statistics: SQL Server recompilations/sec | 1.048
 | Average disk queue length (SQL Server) | 4.524
 | Disk queue length: reads (SQL Server) | Not applicable
Test results | Disk queue length: writes (SQL Server) | 3.918
 | Disk reads/sec (SQL Server) | 71.76
 | Disk writes/sec (SQL Server) | 349.485
 | Average disk queue length (indexer, front-end Web server, query server) | 0.058
 | Disk queue length: reads (indexer, front-end Web server, query server) | Not applicable
 | Disk queue length: writes (indexer, front-end Web server, query server) | 0.049
 | Disk reads/sec (indexer, front-end Web server, query server) | 3.295
 | Disk writes/sec (indexer, front-end Web server, query server) | 138.83
 | Average memory used (indexer, front-end Web server, query server) | 15.28%
 | Maximum memory used (indexer, front-end Web server, query server) | 15.84%
 | Cache hit ratio (SQL Server) | 99.865
Test results | Total crawl speed (items/sec) | 171.73
 | Number of successes | 138590
 | Number of errors | 12

Test results

This section provides test data that show how the farm performed under load at different index sizes.

Query latency

The following graph displays the query latency percentiles for this farm as user load increases. A query percentile of 95 percent means that 95 percent of the query latencies measured were less than that value.

Graph of query latency compared against number of

From this graph, you can see that increasing the size of the content crawled by this farm will affect query latency as the user load exceeds 20 concurrent users.

With approximately 5 million items in the index, the query latencies are very high, as shown in the following graph.

Graph of query latency as user load increases

Query throughput

The following graph displays the query throughput for this farm as user load increases.

Graph of query throughput as user load increases

This graph shows that increasing the size of the content crawled by this farm will affect query throughput significantly, increasing it as the load exceeds about 10 concurrent users.

With approximately 5 million items in index, query throughput may be severely decreased as shown in the following graph.

Graph of query throughput compared against number

Crawl rate

The following graph displays the crawl rate for this farm during the index acquisition stage at different existing index sizes. Notice that the crawl speed decreases as the index grows larger.

Graph of crawl rate during index acquisition

Recommendations

This section describes specific actions that you can take to optimize the environment for appropriate capacity and performance characteristics.

Hardware recommendations

For specific information about minimum and recommended system requirements, see Hardware and software requirements (SharePoint Foundation 2010).

Scaled-up and scaled-out topologies

The search subsystem for SharePoint Foundation 2010 cannot be scaled out. In general, we recommend that if there are more than 1 million items to be indexed, you should use Microsoft Search Server 2010 or SharePoint Server 2010 Search.

Some of the problems with low query throughput and high latency can be avoided by scaling up the CPU, RAM, and IOPS on the application servers and SQL Server computers.

Troubleshooting performance and scalability

To help you determine when you should scale up or scale out the system, use performance counters to monitor the health of the system.

Performance monitoring

Use the information in the following tables to determine which performance counters to monitor, and to which process the performance counters should be applied.

Web and application servers

The following table shows performance counters and processes to monitor for Web servers in the farm.

Performance counter | Apply to object | Notes
Processor time | Total | Shows the percentage of elapsed time that this thread used the processor to execute instructions.
Memory utilization | Application pool (W3wp.exe) | Shows the average utilization of system memory for the application pool. You must specify the correct application pool (instance of W3wp.exe) to monitor. The guideline is to determine peak memory utilization for a given Web application, and assign that number plus 10 to the associated application pool.

Database servers

The following table shows performance counters and processes to monitor for database servers in the farm.

Performance counter Apply to object Notes

Average disk queue length

Hard disk that contains SharedServices.mdf

Average values larger than 1.5 per spindle indicate that the write times for that hard disk are insufficient.

Average disc sec/transfer

Hard disk that contains SharedServices.mdf

The average time used to transfer data to and from the disc.

  • Less than 20 ms is excellent.

  • 20-40 ms is good.

  • More than 50 ms means that it needs optimization by adding IOPS.

Processor time

SQL Server process

Average values larger than 80% indicate that processor capacity on the database server is insufficient.

Memory utilization

Total

Shows the average utilization of system memory.

Buffer cache hit ratio

SQL Server Buffer Manager

Buffer cache hit ratio less than 96% indicates a memory bottleneck. Add more RAM to resolve the problem. This ratio should ideally be more than 98%.

About the author

Brion Stone is a Senior Program Manager for SharePoint Server search at Microsoft.


Planning worksheets for SharePoint Foundation 2010

In this article:

  • Planning worksheets by task

  • Planning worksheets by title

This article provides links to worksheets that you can use to record information that you gather and decisions that you make as you plan your deployment of Microsoft SharePoint Foundation 2010. Use these worksheets in conjunction with — not as a substitute for — Planning and architecture for SharePoint Foundation 2010.

Planning worksheets by task

For this task | Use this worksheet | To do this
Plan sites and site collections (SharePoint Foundation 2010) | Site planning data worksheet (http://go.microsoft.com/fwlink/p/?LinkID=167838) | Plan top-level site collections and sites, and record decisions about site themes and navigation.
Plan site navigation (SharePoint Foundation 2010) | Site planning data worksheet (http://go.microsoft.com/fwlink/p/?LinkID=167838) | Plan top-level site collections and sites, and record decisions about site themes and navigation.
Plan for using themes (SharePoint Foundation 2010) | Site planning data worksheet (http://go.microsoft.com/fwlink/p/?LinkID=167838) | Plan top-level site collections and sites, and record decisions about site themes and navigation.
Plan incoming e-mail (SharePoint Foundation 2010) | Plan incoming e-mail worksheet (http://go.microsoft.com/fwlink/p/?LinkId=200542) | Plan incoming e-mail to enable SharePoint sites to receive and store e-mail messages and attachments in lists and libraries.
Plan for backup and recovery (SharePoint Foundation 2010) | Backup and recovery planning workbook (http://go.microsoft.com/fwlink/p/?LinkID=184385) | Help you plan strategies for backup and recovery for a SharePoint Foundation 2010 environment.
Plan and prepare for upgrade (SharePoint Foundation 2010) | Upgrade worksheet (http://go.microsoft.com/fwlink/p/?LinkId=179928) | Record information about your environment while you prepare for upgrade.
Document management planning (SharePoint Foundation 2010) | Document management participation worksheet (http://go.microsoft.com/fwlink/p/?LinkId=165871) | Identify document management planning stakeholders and record document management practices.
Content type and workflow planning (SharePoint Foundation 2010) | Content type and workflow planning worksheet (http://go.microsoft.com/fwlink/p/?LinkId=219645) | Plan how to integrate content types and workflows into your document management solution.
Document management planning (SharePoint Foundation 2010) | Analyze document usage worksheet for Microsoft SharePoint Foundation 2010 | Record information gathered when analyzing document usage.

Planning worksheets by title

Use this worksheet | For this task | To do this
Analyze document usage worksheet for Microsoft SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=219646) | Document management planning (SharePoint Foundation 2010) | Record information gathered when analyzing document usage.
Backup and recovery planning workbook (http://go.microsoft.com/fwlink/p/?LinkID=184385) | Plan for backup and recovery (SharePoint Foundation 2010) | Help you plan strategies for backup and recovery for SharePoint Foundation 2010 environment.
Content type and workflow planning worksheet (http://go.microsoft.com/fwlink/p/?LinkId=219645) | Content type and workflow planning (SharePoint Foundation 2010) | Plan how to integrate content types and workflows.
Document management participants worksheet (http://go.microsoft.com/fwlink/p/?LinkId=165871) | Document management planning (SharePoint Foundation 2010) | Identify document management planning stakeholders and record document management practices.
Plan incoming e-mail worksheet (http://go.microsoft.com/fwlink/p/?LinkId=200542) | Plan incoming e-mail (SharePoint Foundation 2010) | Plan incoming e-mail to enable SharePoint sites to receive and store e-mail messages and attachments in lists and libraries.
Site planning data worksheet (http://go.microsoft.com/fwlink/p/?LinkID=167838) | Plan sites and site collections (SharePoint Foundation 2010) Plan site navigation (SharePoint Foundation 2010) Plan for using themes (SharePoint Foundation 2010) | Plan top-level site collections and sites, and record decisions about site themes and navigation.
Upgrade worksheet (http://go.microsoft.com/fwlink/p/?LinkId=179928) | Plan and prepare for upgrade (SharePoint Foundation 2010) | Record information about your environment while you prepare for upgrade.


Development for SharePoint Foundation 2010

This article provides links to developer-related content in the MSDN Developer Center.

See the Developers' Center for Microsoft SharePoint Foundation 2010 at http://go.microsoft.com/fwlink/p/?LinkId=159918.


Deployment for SharePoint Foundation 2010

Welcome to the deployment guide for Microsoft SharePoint Foundation 2010. The articles in this guide help you prepare to install, install, and configure SharePoint Foundation 2010. The deployment guide includes information about deployment scenarios, step-by-step installation instructions, and post-installation configuration steps. It also describes how to upgrade to SharePoint Foundation 2010.

Before installing SharePoint Foundation 2010, be sure you have reviewed the information in Planning and architecture for SharePoint Foundation 2010.

For a graphical overview of the deployment process, download the SharePoint 2010 Products Deployment model from the Technical diagrams (SharePoint Foundation 2010) article.

In this section:

  • Deployment overview (SharePoint Foundation 2010)

    This article provides information about deploying SharePoint Foundation 2010. The goal of this article is to provide information that can help you and your teams make fundamental decisions about deploying SharePoint Foundation 2010-based solutions in your organization.

  • Install prerequisites from a network share (SharePoint Foundation 2010)

    This article explains how to use PrerequisiteInstaller.exe to install prerequisites from a network share. Doing so can result in a more consistent deployment.

  • Prepare for deployment (SharePoint Foundation 2010)

    This section provides essential steps to take before you deploy Microsoft SharePoint Foundation 2010.

  • Deployment scenarios (SharePoint Foundation 2010)

    Follow the steps in this section to deploy a single server or server farm with SharePoint Foundation 2010, or to deploy the Office Web Apps for use with SharePoint Foundation 2010.

  • Initial configuration (SharePoint Foundation 2010)

    Follow the steps in this section to install language packs, configure farm settings and services, and create site collections.

  • Deploy customizations - overview (SharePoint Foundation 2010)

    The articles in this section describe how to deploy site elements that have been customized by developers or Web designers in a SharePoint Foundation 2010 environment.

  • Deploy software updates for SharePoint Foundation 2010

    Microsoft periodically releases software updates for SharePoint Foundation 2010. Follow the steps in this section to apply these updates to your servers running SharePoint Foundation.

  • Upgrading to SharePoint Foundation 2010

    Follow the steps in the upgrade guide to plan, prepare, and perform an upgrade to SharePoint Foundation 2010.

Note:

If you plan to use Office Web Apps, you must install and configure them to work with SharePoint 2010 Products. For more information, see Deploy Office Web Apps (Installed on SharePoint 2010 Products).


Deployment overview (SharePoint Foundation 2010)
See Also

This article contains an overview of a Microsoft SharePoint Foundation 2010 farm deployment. Although Microsoft SharePoint Foundation farms vary in complexity and size, a combination of careful planning and a phased deployment that includes ongoing testing and evaluation significantly reduces the risk of unexpected outcomes.

Note:

For information about site and solution planning, which is not in scope for this article, see Site and solution planning (SharePoint Foundation 2010).

For a visual representation of the information in this article, see the SharePoint 2010 Products Deployment model in the Technical diagrams (SharePoint Foundation 2010) topic.

In this article:

  • Concepts

  • Physical architecture

  • Installation and configuration

  • Deployment stages

Concepts

The logical result of SharePoint Foundation's flexibility and richness can be a high degree of complexity around installing and configuring SharePoint Foundation correctly. A fundamental understanding of the following key structural elements in a SharePoint Foundation environment is required in order to correctly deploy and support SharePoint Foundation 2010 products:

  • Server farm: The top-level element of a logical architecture design for SharePoint Foundation.

  • Web application: An IIS Web site that is created and used by SharePoint Foundation 2010.

  • Content database: Provides storage Web application content. You can separate content into multiple content databases at the site collection level.

  • Site collection: A set of Web sites that have the same owner and share administration settings.

  • Site: One or more related Web pages and other items (such as lists, libraries, and documents) that are hosted inside a site collection.

In addition to understanding the elements of a SharePoint Foundation environment and how they have to be configured for your solution, you must consider the following additional factors: physical architecture, installation and configuration, and the various stages of deployment.

Physical architecture

The physical architecture, which consists of one or more servers and the network infrastructure, enables you to implement the logical architecture for a SharePoint Foundation solution. The physical architecture is typically described in two ways: by its size and by its topology. Size, which can be measured in several ways, such as the number of users or the number of documents, is used to categorize a farm as small, medium, or large. Topology uses the idea of tiers or server groups to define a logical arrangement of farm servers.

Size

Size uses the number of users and number of content items as a fundamental measure to indicate whether a server farm is small, medium, and large, as follows:

  • A small server farm typically consists of at least two Web servers and a database server. One of the Web servers hosts the Central Administration site and the other handles additional farm-related tasks, such as serving content to users.

    The small farm can be scaled out to three tiers using a dedicated application server in response to the number of users, the number of content items, and the number of services that are required.

  • A medium server farm typically consists of two or more Web servers, two application servers, and more than one database servers. We recommend that you start with the preceding configuration and then scale out to accommodate the workload placed on the servers.

    In scenarios where services are known to use a disproportionate amount of resources, you can scale out the application tier. Performance data will indicate which services you should consider off-loading to a dedicated server.

  • A large server farm can be the logical result of scaling out a medium farm to meet capacity and performance requirements or by design before a SharePoint Foundation solution is implemented. A three-tier topology environment typically uses dedicated servers on all the tiers. Additionally, these servers are often grouped according to their role in the farm. For example, all client-related services can be grouped onto one or two servers and then scaled out by adding servers to this group as needed in response to user demand for these services.

    Note:

    The recommendation for scaling out a farm is to group services or databases with similar performance characteristics onto dedicated servers and then scale out the servers as a group. In large environments, the specific groups that evolve for a farm depend on the specific demands for each service in a farm.

For specific numbers related to small, medium, and large farms, see Performance and capacity management (SharePoint Server 2010).

Topology

Topology uses tiers as a model for logically arranging farm servers according to the components that they host or their roles in a server farm. A SharePoint Foundation farm is deployed on one, two, or three tiers, as follows:

  • In a single-tier deployment, SharePoint Foundation and the database server are installed on one computer.

  • In a two-tier deployment, SharePoint Foundation components and the database are installed on separate servers. This kind of deployment maps to what is called a small farm. The front-end Web servers are on the first tier and the database server is located on the second tier. In the computer industry, the first tier is known as the Web tier. The database server is known as the database tier or database back-end.

  • In a three-tier deployment, the front-end Web servers are on the first tier, the application servers are on the second tier, which is known as the application tier, and the database server is located on the third tier. A three-tier deployment is used for medium and large farms.

Installation and configuration

After you finish planning your SharePoint Foundation solution you can create a SharePoint Foundation farm to host the solution. The first step is to install SharePoint Foundation 2010 and create the farm that is required for the solution. The process of preparing your environment consists of the following phases:

  1. Prepare the servers

  2. Create the farm

  3. Configure settings, services, solutions, and sites

Note:

The farm that you create and deploy will undergo significant changes in size, topology, and complexity as you move through the different deployment stages illustrated in the SharePoint 2010 Products Deployment model. This is typical and the expected result of a phased deployment. This is why we recommend that you follow all of the stages described in the "Deployment stages" section of this article.

Prepare the servers

In this phase, you get your servers ready to host the product. This includes the supporting servers and the servers that will have SharePoint Foundation installed. The following servers must be configured to support and host a farm:

  • Domain controller: The required farm accounts have to be configured for the domain and directory synchronization must be configured.

    Important:

    SharePoint Foundation 2010 does not support single label domain (SLD) names or single label forests, in either the domain of the SharePoint service accounts or the SharePoint end user's domain. Because the use of SLD names is not a recommended practice, SharePoint 2010 Products are not tested in this scenario. Therefore, there may be incompatibility issues when SharePoint 2010 Products are implemented in a single label domain environment. For more information, see Information about configuring Windows for domains with single-label DNS names (http://go.microsoft.com/fwlink/p/?LinkID=193849) and the DNS Namespace Planning Solution Center (http://go.microsoft.com/fwlink/p/?LinkId=198010).

    For information about required accounts, see:

    • Initial deployment administrative and service accounts (SharePoint Foundation 2010)

    • About Directory Synchronization (http://go.microsoft.com/fwlink/p/?LinkId=193169)

  • Database server: The required version of SQL Server, including service packs and cumulative updates must be installed on the database server. The installation must include any additional features, such as SQL Analysis Services, and the appropriate SharePoint Foundation logins have to be added and configured. The database server must be hardened and, if it is required, databases must be created by the DBA. For more information, see:

    • Hardware and software requirements (SharePoint Foundation 2010)

    • Harden SQL Server for SharePoint environments (SharePoint Foundation 2010)

    • Deploy by using DBA-created databases (SharePoint Foundation 2010)

  • Application servers and front-end Web servers: The farm servers that will have SharePoint Foundation installed must be prepared as follows: verify that they meet the hardware requirements, have the operating system hardened, have the required networking and security protocols configured, have the SharePoint Foundation 2010 software prerequisites installed and hardened, and have the required authentication configured. For more information, see:

    • System requirements (SharePoint Foundation 2010)

    • "Installing software prerequisites" in Hardware and software requirements (SharePoint Foundation 2010)

    • Plan security hardening (SharePoint Foundation 2010)

    • Plan authentication (SharePoint Foundation 2010)

Create the farm

In this phase, you install the product and configure each server to support its role in the farm. You also create the configuration database and the SharePoint Central Administration Web site. The following servers are required for a SharePoint Foundation farm:

  • Database server: Unless you plan to use DBA-created databases, the configuration database, content database, and other required databases are created when you run the SharePoint Products Configuration Wizard.

  • Application server: After you prepare the application server, install any additional components that are required to support functions such as Information Rights Management (IRM) and decision support. Install SharePoint Foundation on the server that will host SharePoint Central Administration Web site and then run the SharePoint Products Configuration Wizard to create and configure the farm.

  • Front-end Web server: Install SharePoint Foundation on each Web server, install language packs, and then run the SharePoint Products Configuration Wizard to add the Web servers to the farm.

    Note:

    After you add and configure all the front-end Web servers, you can add any additional application servers that are part of your topology design to the farm.

For more information about supported deployment scenarios, see Deployment scenarios (SharePoint Foundation 2010).

Configure settings, services, solutions, and sites

In this phase, you prepare the farm to host your site content by completing the following tasks:

  • Configure global settings. For more information, see Configure farm settings (SharePoint Foundation 2010)

  • Configure services. For more information, see Configure services (SharePoint Foundation 2010)

  • Deploy solutions and customizations. For more information, see Deploy customizations - overview (SharePoint Foundation 2010)

  • Create and populate the sites. For more information, see Prepare to host sites (SharePoint Foundation 2010)

Note:

Farm configuration steps are not isolated to a specific tier in the server infrastructure.

Deployment stages

By deploying a SharePoint Foundation 2010 solution in stages, you gain the benefits that are provided by a systematic approach, such as collecting performance and usage data that you can use to evaluate your solution. Additional benefits include verifying your capacity management assumptions and identifying issues before the farm is put into production.

We recommend that you deploy your farm in the following stages:

  • Planning

  • Development

  • Proof of concept (POC)

  • Pilot

  • User acceptance test (UAT)

  • Production

Planning

Before you can deploy a farm, you must plan the solution that you want to deploy and determine the infrastructure requirements, such as server resources and farm topology. When you finish the planning stage, you should have documented the following:

  • An infrastructure design to support your solution

  • A detailed description of how you will implement the farm and the solution

  • A plan for testing and validating the solution

  • A site and solution architecture

  • An understanding of the monitoring and sustained engineering requirements to support the solution

  • A record of how the solution will be governed

  • An understanding of how the solution will be messaged to the user to drive adoption of the solution

We recommend that you use the planning resources and articles described in Planning and architecture for SharePoint Foundation 2010.

Important:

Resource and time issues may pressure you to be less rigorous during the planning stage. We recommend that you try to be as diligent as possible because missed or lightly touched planning elements can resurface as significant issues after you are in production. These issues can create much additional work, consume unbudgeted resources, and potentially take away from the success of your SharePoint Foundation.

After the planning stage, you move through the following deployment stages, updating and revising your plans, configurations, and topologies as you test.

Development

During the development stage you will deploy SharePoint Foundation on a single server or on multiple servers to develop, test, evaluate, and refine the solution that you intend to implement. This environment is scaled according to your needs during solution development and can be retained as a scaled down environment for future development and testing. This is not a stable environment and there are no service-level agreements.

Proof of concept (POC)

During the proof of concept stage, the objective is two-fold: to understand SharePoint Foundation and to evaluate SharePoint Foundation in the context of how it can address your business needs. The first level of product evaluation can be done by installing all of the product components on a single server. You do a more extensive product evaluation by a proof-of-concept deployment.

A proof-of-concept deployment on a single server or on a small farm enables you to expand the scope of your evaluation. In this deployment, non-IT staff is added to the evaluation team, which provides a broader view of how SharePoint Foundation features might be actually be used in the organization. The benefit of a proof-of-concept deployment is that you can collect data that can be used to refine your original plan. This data—such as page views, user behavior patterns, and server resource consumption—also enables you to start to build a benchmark for sizing your farm. A proof of concept is also good when you evaluate service applications and determining what feature sets that you will offer your end users.

It is important during the proof-of-concept stage that you understand the unique characteristics and functionality of these features because this understanding will help you define your overall topology. Be aware that a proof-of-concept deployment requires additional resources and extends the time required to put SharePoint Foundation into production.

Tip:

Virtualization provides a good platform for evaluating SharePoint Foundation because a virtual environment provides flexibility, rapid deployment capability, and the ability to roll back virtual machines to previous states.

Pilot

A pilot is used to test your solution on a small scale. There are two approaches to using a pilot deployment. In the first approach, the focus is on functional testing without using real data. By using the second approach you test for production characteristics by using real data and have your pilot users test different kinds of tasks. We recommend the second approach because of the broader scope and real-world data that you can collect and use to refine your solution design.

A pilot deployment provides many benefits. It enables you to collect data that you can use to validate the following aspects of your farm design:

  • Infrastructure design

  • Capacity management assumptions

  • Site and solution architecture

  • Solution usage assumptions

The pilot stage also enables you to determine additional data that should be collected to increase the breadth and depth of your benchmarks. This is important if you want to assess the potential effect of additional features or services that you want to add to the farm before the user acceptance test.

At the conclusion of the pilot deployment, you can use the data that you collect to adjust the various components of the solution and its supporting infrastructure.

User acceptance test (UAT)

A user acceptance test deployment—also known as a pre-production environment—is used by organizations as a transitional step from the pilot deployment to a production deployment. An organization's business processes determine the scope, scale, and duration of user accept testing.

The topology of the pre-production environment should be the same as, or very similar to the planned production topology. During user acceptance testing, the SharePoint Foundation solution is tested against a subset or a complete copy of production data. This deployment stage provides a final opportunity for performance tuning and validating operational procedures such as backups and restores.

Production

The final stage is rolling your farm into a production environment. At this stage, you will have incorporated the necessary solution and infrastructure adjustments that were identified during the user acceptance test stage.

Putting the farm into production requires you to complete the following tasks:

  • Deploy the farm.

  • Deploy the solution.

  • Implement the operations plan.

  • If required, deploy additional environments such as authoring and staging farms, and services farms.

See Also

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010


Install prerequisites from a network share (SharePoint Foundation 2010)

This article describes how to install Microsoft SharePoint Foundation 2010 prerequisites from an offline shared network location using the prerequisite installer (PrerequisiteInstaller.exe) tool.

Installing prerequisites from an offline location is typically required when the servers on which you want to install Microsoft SharePoint Foundation are isolated from the Internet. Even if this is not the case, installing prerequisites from an offline central location enables you to ensure farm server consistency by installing a well-known and controlled set of images.

Note:

The Microsoft SharePoint Products Preparation Tool is a user interface built on PrerequisiteInstaller.exe. The Microsoft SharePoint Products Preparation Tool accepts no user input.

In this article:

  • Installer switches and arguments

  • Download and consolidate the prerequisites on a file share

  • Install the prerequisites from the command line

  • Install the prerequisites using an arguments file

  • Known issues

Installer switches and arguments

By using PrerequisiteInstaller.exe with switches and arguments, you have control over which versions of the required software are installed and the location from where they are installed.

PrequisiteInstaller.exe accepts single or multiple switch and argument pairs. A switch identifies the prerequisite and the argument specifies the action and the location of the prerequisite.

A switch and argument pair uses the following format:

/switch: <path>

Where:

  • /switch is a valid switch to identify a prerequisite. For example, /NETFX35SP1: is the switch for .NET Framework 3.5 Service Pack 1.

  • <path> is expressed as the path to a local file or the path to a file share, for example, "C:\foldername\dotnetfx35.exe " or "\\<servername>\<sharename>\dotnetfx35.exe".

Each switch and its argument are separated by a colon and a space. The argument is enclosed in quotes.

The switch and argument pairs can be passed to PrerequisiteInstaller.exe at the command prompt or read from an arguments text file.

Download and consolidate the prerequisites on a file share

The process for downloading and consolidating prerequisites consists of the steps described in the following procedures.

To identify prerequisites

  1. Refer to the Hardware and software requirements (SharePoint Foundation 2010) article, which contains a list of all the required and optional software for SharePoint Foundation 2010. Additionally, this document provides the download location for each prerequisite that is available for download on the Internet.

  2. From the command prompt, navigate to the root of the SharePoint Foundation 2010 installation media or folder location.

  3. At the command prompt, type PrerequisiteInstaller.exe /?. This displays a list of the command-line options and switches and their corresponding arguments for installing a prerequisite from the command-line.

    Tip:

    To copy the contents of the active About window to the Clipboard, press CTRL+C.

  4. Verify that you have an accurate list of the required software. Compare the output from the prerequisite installer to the list of prerequisites in Step 1.

  5. Download the prerequisites to a computer that has Internet access.

Next, use the following procedure to create a central location that you can use for installing SharePoint Foundation prerequisites on all the farm servers.

To consolidate prerequisites

  1. Create a shared folder on a computer that can be accessed by the servers on which the prerequisites will be installed.

  2. Copy the files that you downloaded from the Internet to the shared folder.

After you finish creating an accessible network location for the prerequisites, use the procedure in the following section to install SharePoint Foundation 2010 prerequisites on a server.

Install the prerequisites from the command line

You can install one or all of the prerequisites from the command line using the following procedure.

To install from the command line

  1. From the Start menu, open the Command Prompt window using the Run as administrator option.

  2. Navigate to the SharePoint Foundation source directory.

  3. Type the prerequisite program switch and corresponding argument for the program that you want to install, and then press ENTER, for example:

    PrerequisiteInstaller.exe /SQLNCli: "\\o14-sf-admin\SP_prereqs\sqlncli.msi"

    Note:

    To install more than one prerequisite, type in each switch and argument pair, taking care to separate each pair by a space, for example:

    PrerequisiteInstaller.exe /SQLNCli: "\\o14-sf-admin\SP_prereqs\sqlncli.msi" /ChartControl: "\\o14-sf-admin\SP_prereqs\MSChart.exe" /W2K8SP2: "\\o14-sf-admin\SP_prereqs\Windows6.0-KB948465-X64.exe" /NETFX35SP1: "\\o14-sf-admin\SP_prereqs\dotnetfx35setup.exe"

Install the prerequisites using an arguments file

You can install the prerequisites from the file share using an arguments file that consists of switches and corresponding path statements to the programs that need to be installed.

When you run PrerequisiteInstaller.exe with an arguments file, the following happens:

  1. PrerequisiteInstaller.exe reads the argument file to verify that each switch is valid and that the program identified in the path statement exists.

    Note:

    If you specify an argument, PrerequisiteInstaller.exe ignores the arguments file and only processes the command-line argument.

  2. PrerequisiteInstaller.exe scans the local system to determine if any of the prerequisites are already installed.

  3. PrerequisiteInstaller.exe installs the programs in the argument file and returns one of the following exit codes:

    • 0 - Success

    • 1 - Another instance of this application is already running

    • 2 - Invalid command line parameter

    • 1001 - A pending restart blocks installation

    • 3010 - A restart is needed

  4. If a prerequisite requires a restart, a 3010 code is generated and you are prompted to click Finish to restart the system. The behavior of the installer after a 3010 code is different depending on which of the following conditions exist on the computer:

    • If Windows Server 2008 Service Pack 2 (SP2) is already installed on the system, the 3010 code is generated and the remaining prerequisites are installed. After the last prerequisite is installed you are prompted to restart the system.

    • If Windows Server 2008 SP2 is installed on the system by PrerequisiteInstaller.exe, the installer generates the 3010 code, and the installation of the remaining prerequisites is skipped. You are prompted to restart the system.

      After the system restarts, PrerequisiteInstaller.exe starts running again because the startup file that is created before the restart contains a /continue flag.

      After a restart, PrerequisiteInstaller.exe ignores the arguments file and attempts to download and install the remaining prerequisites from the Internet. For more information, see Known issues.

Use the following procedure to create an arguments file.

To create an arguments file

  1. Using a text editor, create a new text document named PrerequisiteInstaller.Arguments.txt. Save this file to the same location as PrerequisiteInstaller.exe. This file will contain the switches and arguments that are used when you run the Microsoft SharePoint Products Preparation Tool.

  2. Using a text editor, edit PrerequisiteInstaller.Arguments.txt and provide file paths to the installation source for each prerequisite switch, using the following syntax:

    /switch: <path>

    Where /switch is a valid switch and <path> is a path to the installation source.

    The following example shows a complete arguments file that uses a file share as a common installation point.

    /SQLNCli: "\\o14-sf-admin\SP_prereqs\sqlncli.msi"
    /ChartControl: "\\o14-sf-admin\SP_prereqs\MSChart.exe"
    /W2K8SP2: "\\o14-sf-admin\SP_prereqs\Windows6.0-KB948465-X64.exe"
    /NETFX35SP1: "\\o14-sf-admin\SP_prereqs\dotnetfx35setup.exe"
    /PowerShell: "\\o14-sf-admin\SP_prereqs\Windows6.0-KB968930-x64.msu"
    /KB976394: "\\o14-sf-admin\SP_prereqs\Windows6.0-KB976394-x64.msu"
    /KB976462: "\\o14-sf-admin\SP_prereqs\Windows6.1-KB976462-v2-x64.msu"
    /IDFX: "\\o14-sf-admin\SP_prereqs\Windows6.0-KB974405-x64.msu"
    /Sync: "\\o14-sf-admin\SP_prereqs\Synchronization.msi"
    /FilterPack: "\\o14-sf-admin\SP_prereqs\FilterPackx64.exe"
    /ADOMD: "\\o14-sf-admin\SP_prereqs\SQLSERVER2008_ASADOMD10.msi"
    /ReportingServices: "\\o14-sf-admin\SP_prereqs\rsSharePoint.msi"
    /Speech: "\\o14-sf-admin\SP_prereqs\SpeechPlatformRuntime.msi"
    /SpeechLPK: "\\o14-sf-admin\SP_prereqs\MSSpeech_SR_en-US_TELE.msi"

    Important:

    For readability, the switches and path statements in the preceding example are displayed on separate lines. When you actually create a PrerequisitesInstaller.Arguments.txt file do not use line breaks, but separate each switch and path statement by a space. For more information, see Known issues.

  3. After you finish editing PrerequisiteInstaller.Arguments.txt, save your edits, and verify that this file is in the same directory as PrerequisiteInstaller.exe.

Use the following procedure to install the prerequisites.

To install the prerequisites using an arguments file

  1. Run PrerequisiteInstaller.exe from the command prompt to install the prerequisites.

    Caution:

    If you are prompted to click Finish to restart the system, do not do so. Click Cancel. For more information, see Known issues before proceeding to the next step.

  2. Restart the system manually.

  3. Run PrerequisiteInstaller.exe from the command prompt.

Known issues

There are two known issues that affect the use of an arguments file:

  • Using line breaks in the arguments file

    If you create an arguments file and use line breaks to put each switch and argument on a separate line, the prerequisite installer fails. The workaround is to enter all the switch and argument pairs on a single line.

  • After a computer restart, the arguments file is not used

    After a restart, PrerequisiteInstaller.exe executes the startup command file, which contains a /continue flag. The /continue flag forces the installer to ignore the arguments file.

    You must prevent a restart by deleting the startup task in this command file using one of the following options:

    Option 1

    1. Run PrerequisiteInstaller.exe by double-clicking it. The program will display the first screen with the list of prerequisites.

    2. Click Cancel. PrerequisiteInstaller.exe deletes the startup task.

    Option 2

    1. From the Start menu, choose Run and then type regedit to open the registry.

    2. Open the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders.

    3. Check the value for "Common Startup". This shows the directory where the startup tasks are listed.

    4. Close the registry editor without making any changes.

    5. Navigate to the startup directory, which is usually <systemdir>\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup.

    6. Delete the startup task by deleting "SharePointServerPreparationToolStartup_0FF1CE14-0000-0000-0000-000000000000.cmd".


Prepare for deployment (SharePoint Foundation 2010)
See Also

This section provides essential steps to take before you deploy Microsoft SharePoint Foundation 2010.

In this section:

  • Hardware and software requirements (SharePoint Foundation 2010)

    This article provides the minimum hardware and software requirements necessary to install SharePoint Foundation 2010.

  • Initial deployment administrative and service accounts (SharePoint Foundation 2010)

    This article provides information about the administrative and service accounts that are required for an initial SharePoint Foundation 2010 deployment. Additional accounts and permissions are required to fully implement all aspects of a production farm.

  • Harden SQL Server for SharePoint environments (SharePoint Foundation 2010)

    This article describes how to harden Microsoft SQL Server for SharePoint Foundation 2010 environments.

See Also

Concepts

Deployment overview (SharePoint Foundation 2010)
Deployment scenarios (SharePoint Foundation 2010)


Initial deployment administrative and service accounts (SharePoint Foundation 2010)
See Also

This article provides information about the administrative and service accounts that are required for an initial Microsoft SharePoint Foundation 2010 deployment. Additional accounts and permissions are required to fully implement all aspects of a production farm.

Required permissions

To deploy SharePoint Foundation 2010 on a server farm, you must provide credentials for several different accounts.

The following table describes the accounts that are used to install and configure SharePoint Foundation 2010.

Account Purpose Requirements

SQL Server service account

The SQL Server service account is used to run SQL Server. It is the service account for the following SQL Server services:

  • MSSQLSERVER

  • SQLSERVERAGENT

If you do not use the default SQL Server instance, in the Windows Services console, these services will be shown as the following:

  • MSSQL$InstanceName

  • SQLAgent$InstanceName

Use either a Local System account or a domain user account.

If you plan to back up to or restore from an external resource, permissions to the external resource must be granted to the appropriate account. If you use a domain user account for the SQL Server service account, grant permissions to that domain user account. However, if you use the Network Service or the Local System account, grant permissions to the external resource to the machine account (domain_name\SQL_hostname$).

The instance name is arbitrary and was created when Microsoft SQL Server was installed.

Setup user account

The Setup user account is used to run the following:

  • Setup

  • SharePoint Products Configuration Wizard

  • Domain user account.

  • Member of the Administrators group on each server on which Setup is run.

  • SQL Server login on the computer that runs SQL Server.

  • Member of the following SQL Server security roles:

    • securityadmin fixed server role

    • dbcreator fixed server role

If you run Windows PowerShell cmdlets that affect a database, this account must be a member of the db_owner fixed database role for the database.

Server farm account or database access account

The server farm account is used to perform the following tasks:

  • Configure and manage the server farm.

  • Act as the application pool identity for the SharePoint Central Administration Web site.

  • Run the Microsoft SharePoint Foundation Workflow Timer Service.

  • Domain user account.

Additional permissions are automatically granted for the server farm account on Web servers and application servers that are joined to a server farm.

The server farm account is automatically added as a SQL Server login on the computer that runs SQL Server. The account is added to the following SQL Server security roles:

  • dbcreator fixed server role

  • securityadmin fixed server role

  • db_owner fixed database role for all SharePoint databases in the server farm

See Also

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010
Resource Center: Security and Authentication for SharePoint Foundation 2010


Harden SQL Server for SharePoint environments (SharePoint Foundation 2010)

This article describes how to harden Microsoft SQL Server for Microsoft SharePoint 2010 Products environments.

In this article:

  • Summary of hardening recommendations

  • Configure a SQL Server instance to listen on a non-default port

  • Block default SQL Server listening ports

  • Configure Windows Firewall to open manually assigned ports

  • Configure a SQL Server alias

  • Test the SQL Server client alias

Summary of hardening recommendations

For secure server farm environments, the recommendation is to do the following:

  • Block UDP port 1434.

  • Configure named instances of SQL Server to listen on a nonstandard port (other than TCP port 1433 or UDP port 1434).

  • For additional security, block TCP port 1433 and reassign the port that is used by the default instance to a different port.

  • Configure SQL Server client aliases on all front-end Web servers and application servers in the server farm. After you block TCP port 1433 or UDP port 1434, SQL Server client aliases are necessary on all computers that communicate with the computer running SQL Server.

For more information about these recommendations, see Plan security hardening (SharePoint Foundation 2010).

Configure a SQL Server instance to listen on a non-default port

Use SQL Server Configuration Manager to change the TCP port that is used by an instance of SQL Server.

  1. On the computer running SQL Server, open SQL Server Configuration Manager.

  2. In the left pane, expand SQL Server Network Configuration.

  3. Click the corresponding entry for the instance that you are configuring. The default instance is listed as Protocols for MSSQLSERVER. Named instances will appear as Protocols for named_instance.

  4. In the right pane, right-click TCP/IP, and then click Properties.

  5. Click the IP Addresses tab. For every IP address that is assigned to the computer running SQL Server, there is a corresponding entry on this tab. By default, SQL Server listens on all IP addresses that are assigned to the computer.

  6. To globally change the port that the default instance is listening on, follow these steps:

    1. For each IP address except IPAll, clear all values for both TCP dynamic ports and TCP Port.

    2. For IPAll, clear the value for TCP dynamic ports. In the TCP Port field, enter the port that you want the instance of SQL Server to listen on. For example, enter 40000.

  7. To globally change the port that a named instance is listening on, perform the following steps:

    1. For each IP address including IPAll, clear all values for TCP dynamic ports. A value of 0 for this field indicates that SQL Server uses a dynamic TCP port for the IP address. A blank entry for this value means that SQL Server will not use a dynamic TCP port for the IP address.

    2. For each IP address except IPAll, clear all values for TCP Port.

    3. For IPAll, clear the value for TCP dynamic ports. In the TCP Port field, enter the port that you want the instance of SQL Server to listen on. For example, enter 40000.

  8. Click OK. You will receive a message indicating that the change will not take effect until the SQL Server service is restarted. Click OK.

  9. Close SQL Server Configuration Manager.

  10. Restart the SQL Server service and confirm that the computer running SQL Server is listening on the port that you selected. You can confirm this by looking in the event viewer log after restarting the SQL Server service. Look for an information event similar to the following event:

    Event Type:Information

    Event Source:MSSQL$MSSQLSERVER

    Event Category:(2)

    Event ID:26022

    Date:3/6/2008

    Time:1:46:11 PM

    User:N/A

    Computer:computer_name

    Description:

    Server is listening on [ 'any' <ipv4>50000]

Block default SQL Server listening ports

Windows Firewall with Advanced Security uses Inbound Rules and Outbound Rules to secure incoming and outgoing network traffic. Because Windows Firewall blocks all incoming unsolicited network traffic by default, you do not have to explicitly block the default SQL Server listening ports. For more information, see Windows Firewall with Advanced Security (http://go.microsoft.com/fwlink/p/?LinkId=214109) and Configuring the Windows Firewall to Allow SQL Server Access (http://go.microsoft.com/fwlink/p/?LinkId=210584)

Configure Windows Firewall to open manually assigned ports

  1. In Control Panel, open System and Security.

  2. Click Windows Firewall, and then click Advanced Settings to open the Windows Firewall with Advanced Security dialog box.

  3. In the navigation pane, click Inbound Rules to display the available options in the Actions pane.

  4. Click New Rule to open the New Inbound Rule Wizard.

  5. Use the wizard to complete the steps that are required to allow access to the port that you defined in Configure a SQL Server instance to listen on a non-default port.

Note:

You can configure the Internet Protocol security (IPsec) to help secure communication to and from your computer that is running SQL Server by configuring the Windows firewall. You do this by selecting Connection Security Rules in the navigation pane of the Windows Firewall with Advanced Security dialog box.

Configure a SQL Server alias

If you block UDP port 1434 or TCP port 1433 on the computer running SQL Server, you must create a SQL Server client alias on all other computers in the server farm. You can use SQL Server client components to create a SQL Server client alias for computers that connect to SQL Server.

  1. Run Setup for SQL Server on the target computer, and select the following client components to install:

    1. Connectivity Components

    2. Management Tools

  2. Open SQL Server Configuration Manager.

  3. In the left pane, click SQL Native Client Configuration.

  4. In the right pane, right-click Aliases, and select New Alias.

  5. In the Alias dialog box, enter a name for the alias and then enter the port number for the database instance. For example, enter SharePoint_alias.

  6. In the Port No field, enter the port number for the database instance. For example, enter 40000. Ensure that the protocol is set to TCP/IP.

  7. In the Server field, enter the name of the computer running SQL Server.

  8. Click Apply, and then click OK.

Test the SQL Server client alias

Test connectivity to the computer running SQL Server by using Microsoft SQL Server Management Studio, which is available by installing SQL Server client components.

  1. Open SQL Server Management Studio.

  2. When you are prompted to enter a server name, enter the name of the alias that you created, and then click Connect. If the connection is successful, SQL Server Management Studio is populated with objects that correspond to the remote database.

    Note:

    To check connectivity to additional database instances from within SQL Server Management Studio, click Connect, and then click Database Engine.


Deployment scenarios (SharePoint Foundation 2010)

Testing and implementing Microsoft SharePoint Foundation 2010 solutions at different stages of the deployment life cycle requires deployments on various topologies.

This section describes how to deploy Microsoft SharePoint Foundation 2010 on one or more servers to create different topologies that you can use for testing and implementing Microsoft SharePoint Foundation 2010 solutions at different stages of the deployment life cycle.

In this section:

  • Deploy a single server with SQL Server (SharePoint Foundation 2010)

    This article describes how to install SharePoint Foundation 2010 on a single server. This deployment uses Microsoft SQL Server and can easily be scaled out to create two- and three-tier farm topologies.

  • Deploy a single server with a built-in database (SharePoint Foundation 2010)

    This article describes how to install SharePoint Foundation 2010 on a single server. This deployment uses SQL Server Express and is typically used for evaluating SharePoint Foundation 2010.

  • Multiple servers for a three-tier farm (SharePoint Foundation 2010)

    This article describes how to install SharePoint Foundation 2010 on multiple servers. This deployment uses Microsoft SQL Server and the resulting three-tier topology provides the foundation for implementing any solution.

  • Quick start: Deploy single server in an isolated Hyper-V environment (SharePoint Foundation 2010)

    This article describes how to use Windows PowerShell to install SharePoint Foundation 2010 on a single server that uses either SQL Server Express or Microsoft SQL Server. Use the included Windows PowerShell code to quickly install SharePoint Foundation 2010 in an isolated Hyper-V environment that you can use for to evaluate SharePoint Foundation 2010.

  • Deploy by using DBA-created databases (SharePoint Foundation 2010)

    This article describes how to deploy Microsoft SharePoint Foundation 2010 in a farm environment that uses DBA-created databases.

  • Deploy in a virtual environment (SharePoint Foundation 2010)

    This article describes guidance for deploying a virtual environment.


Deploy a single server with SQL Server (SharePoint Foundation 2010)
See Also

This article describes how to perform a clean installation of Microsoft SharePoint Foundation 2010 on a single server farm.

In this article:

  • Overview

  • Before you begin

  • Install SharePoint Foundation 2010

  • Post-installation steps

Overview

When you install SharePoint Foundation 2010 on a single server farm, you can configure SharePoint Foundation 2010 to meet your specific needs. After Setup and the SharePoint Products Configuration Wizard have been completed, you will have installed binaries, configured security permissions, registry settings, the configuration database, and the content database, and installed the SharePoint Central Administration Web site. Next, you can choose to run the Farm Configuration Wizard to configure the farm, select the services that you want to use in the farm, and create the first site collection, or you can manually perform the farm configuration at your own pace.

A single server farm typically consists of one server that runs both Microsoft SQL Server and SharePoint Foundation 2010. You can deploy SharePoint Foundation 2010 in a single server farm environment if you are hosting only a few sites for a limited number of users. This configuration is also useful if you want to configure a farm to meet your needs first, and then add servers to the farm at a later stage.

Note:

This guide does not explain how to install SharePoint Foundation 2010 in a multiple server farm environment or how to upgrade from previous releases of SharePoint Foundation. For more information, see Multiple servers for a three-tier farm (SharePoint Foundation 2010). For more information about upgrade, see Upgrading to SharePoint Foundation 2010.

Before you begin

Before you begin deployment, do the following:

  • Ensure that you are familiar with the operating-system guidelines described in Performance Tuning Guidelines for Windows Server 2008 and Performance Tuning Guidelines for Windows Server 2008 R2.

  • Ensure that you have met all hardware and software requirements. For more information, see Hardware and software requirements (SharePoint Foundation 2010).

  • Ensure that you perform a clean installation of SharePoint Foundation 2010. You cannot install the RTM version of SharePoint Foundation 2010 without first removing the beta version of SharePoint Foundation 2010.

  • Ensure that you are prepared to set up the required accounts with appropriate permissions, as described in Initial deployment administrative and service accounts (SharePoint Foundation 2010).

    Note:

    As a security best practice, we recommend that you install SharePoint Foundation 2010 by using least-privilege administration.

  • Ensure that you have decided which services to use for your Web application, as described in Configure services (SharePoint Foundation 2010).

Install SharePoint Foundation 2010

To install and configure SharePoint Foundation 2010, follow these steps:

  1. Run the Microsoft SharePoint Products Preparation Tool, which installs all required prerequisites to use SharePoint Foundation 2010.

  2. Run Setup, which installs binaries, configures security permissions, and sets registry settings for Microsoft SharePoint Foundation.

  3. Run SharePoint Products Configuration Wizard, which installs and configures the configuration database, the content database, and installs the SharePoint Central Administration Web site.

  4. Configure browser settings.

  5. Run the Farm Configuration Wizard, which configures the farm, creates the first site collection, and selects the services that you want to use in the farm.

  6. Perform post-installation steps.

Important:

To complete the following procedures, you must be a member of the Administrators group on the local computer.

Run the Microsoft SharePoint Products Preparation Tool

Use the following procedure to install software prerequisites for SharePoint Foundation 2010.

To run the Microsoft SharePoint Products Preparation Tool

  1. Insert your SharePoint Foundation 2010 installation disc.

  2. On the SharePoint Foundation 2010 Start page, click Install software prerequisites.

    Note:

    Because the preparation tool downloads components from the Microsoft Download Center, you must have Internet access on the computer on which you are installing Microsoft SharePoint Foundation.

  3. On the Welcome to the Microsoft SharePoint Products Preparation Tool page, click Next.

  4. On the License Terms for software product page, review the terms, select the I accept the terms of the License Agreement(s) check box, and then click Next.

  5. On the Installation Complete page, click Finish.

Run Setup

The following procedure installs binaries, configures security permissions, and sets registry settings for SharePoint Foundation 2010.

To run Setup

  1. On the SharePoint Foundation 2010 Start page, click Install SharePoint Foundation.

  2. On the Read the Microsoft Software License Terms page, review the terms, select the I accept the terms of this agreement check box, and then click Continue.

  3. On the Choose the installation you want page, click Server farm.

  4. On the Server Type tab, click Complete.

  5. Optional: To install SharePoint Foundation 2010 at a custom location, click the Data Location tab, and then either type the location or click Browse to find the location.

  6. Click Install Now.

  7. When Setup finishes, click Close.

Note:

If Setup fails, check the TEMP folder of the user who ran Setup. Ensure that you are logged in as the user who ran Setup, and then type %temp% in the location bar in Windows Explorer. If the path %temp% resolves to a location that ends in a "1" or "2", you will need to navigate up one level to view the log files. The log file name is Microsoft SharePoint Foundation 2010 Setup (<timestamp>).

Tip:

To access the SharePoint Products Configuration Wizard, click Start, point to All Programs, and then click Microsoft SharePoint 2010 Products. If the User Account Control dialog box appears, click Continue.

Run the SharePoint Products Configuration Wizard

The following procedure installs and configures the configuration database, the content database, and installs the SharePoint Central Administration Web site.

To run the SharePoint Products Configuration Wizard

  1. On the Welcome to SharePoint Products page, click Next.

  2. In the dialog box that notifies you that some services might need to be restarted during configuration, click Yes.

  3. On the Connect to a server farm page, click Create a new server farm, and then click Next.

  4. On the Specify Configuration Database Settings page, do the following:

    1. In the Database server box, type the name of the computer that is running SQL Server.

    2. In the Database name box, type a name for your configuration database, or use the default database name. The default name is SharePoint_Config.

    3. In the Username box, type the user name of the server farm account. Ensure that you type the user name in the format DOMAIN\user name.

      Important:

      The server farm account is used to create and access your configuration database. It also acts as the application pool identity account for the SharePoint Central Administration application pool, and it is the account under which the Microsoft SharePoint Foundation Workflow Timer service runs. The SharePoint Products Configuration Wizard adds this account to the SQL Server Login accounts, the SQL Server dbcreator server role, and the SQL Server securityadmin server role. The user account that you specify as the service account must be a domain user account, but it does not need to be a member of any specific security group on your front-end Web servers or your database servers. We recommend that you follow the principle of least privilege and specify a user account that is not a member of the Administrators group on your front-end Web servers or your database servers.

    4. In the Password box, type the user password.

  5. Click Next.

  6. On the Specify Farm Security Settings page, type a passphrase, and then click Next.

    Ensure that the passphrase meets the following criteria:

    • Contains at least eight characters

    • Contains at least three of the following four character groups:

      • English uppercase characters (from A through Z)

      • English lowercase characters (from a through z)

      • Numerals (from 0 through 9)

      • Nonalphabetic characters (such as !, $, #, %)

      Note:

      Although a passphrase is similar to a password, it is usually longer to enhance security. It is used to encrypt credentials of accounts that are registered in Microsoft SharePoint Foundation; for example, the Microsoft SharePoint Foundation system account that you provide when you run the SharePoint Products Configuration Wizard. Ensure that you remember the passphrase, because you must use it each time you add a server to the farm.

  7. On the Configure SharePoint Central Administration Web Application page, do the following:

    1. Either select the Specify port number check box and type the port number you want the SharePoint Central Administration Web application to use, or leave the Specify port number check box cleared if you want to use the default port number.

    2. Click either NTLM or Negotiate (Kerberos).

  8. Click Next.

  9. On the Completing the SharePoint Products Configuration Wizard page, review your configuration settings to verify that they are correct, and then click Next.

    Note:

    If you want to automatically create unique accounts for users in Active Directory Domain Services (AD DS), click Advanced Settings, and enable Active Directory account creation.

  10. On the Configuration Successful page, click Finish.

    Note:

    If the SharePoint Products Configuration Wizard fails, check the PSCDiagnostics log files, which are located on the drive on which SharePoint Foundation is installed, in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14\LOGS folder.

    Note:

    If you are prompted for your user name and password, you might need to add the SharePoint Central Administration Web site to the list of trusted sites and configure user authentication settings in Internet Explorer. You might also want to disable the Internet Explorer Enhanced Security settings. Instructions for how to configure or disable these settings are provided in the following section.

    Note:

    If you see a proxy server error message, you might need to configure your proxy server settings so that local addresses bypass the proxy server. Instructions for configuring proxy server settings are provided later in the following section.

Configure browser settings

After you run the SharePoint Products Configuration Wizard, you should ensure that SharePoint Foundation 2010 works properly for local administrators in your environment by configuring additional settings in Internet Explorer.

Note:

If local administrators are not using Internet Explorer, you might need to configure additional settings. For information about supported browsers, see Plan browser support (SharePoint Foundation 2010).

If you are prompted for your user name and password, perform the following procedures:

  • Add the SharePoint Central Administration Web site to the list of trusted sites

  • Disable Internet Explorer Enhanced Security settings

If you receive a proxy server error message, perform the following procedure:

  • Configure proxy server settings to bypass the proxy server for local addresses

For more information, see Getting Started with IEAK 8 (http://go.microsoft.com/fwlink/p/?LinkId=151359).

To add the SharePoint Central Administration Web site to the list of trusted sites

  1. In Internet Explorer, on the Tools menu, click Internet Options.

  2. On the Security tab, in the Select a zone to view or change security settings area, click Trusted Sites, and then click Sites.

  3. Clear the Require server verification (https:) for all sites in this zone check box.

  4. In the Add this Web site to the zone box, type the URL to your site, and then click Add.

  5. Click Close to close the Trusted Sites dialog box.

  6. Click OK to close the Internet Options dialog box.

To disable Internet Explorer Enhanced Security settings

  1. Click Start, point to All Programs, point to Administrative Tools, and then click Server Manager.

  2. In Server Manager, select the root of Server Manager.

  3. In the Security Information section, click Configure IE ESC.

    The Internet Explorer Enhanced Security Configuration dialog box opens.

  4. In the Administrators section, click Off to disable the Internet Explorer Enhanced Security settings, and then click OK.

To configure proxy server settings to bypass the proxy server for local addresses

  1. In Internet Explorer, on the Tools menu, click Internet Options.

  2. On the Connections tab, in the Local Area Network (LAN) settings area, click LAN Settings.

  3. In the Automatic configuration area, clear the Automatically detect settings check box.

  4. In the Proxy Server area, select the Use a proxy server for your LAN check box.

  5. Type the address of the proxy server in the Address box.

  6. Type the port number of the proxy server in the Port box.

  7. Select the Bypass proxy server for local addresses check box.

  8. Click OK to close the Local Area Network (LAN) Settings dialog box.

  9. Click OK to close the Internet Options dialog box.

Run the Farm Configuration Wizard

You have now completed Setup and the initial configuration of SharePoint Foundation 2010. You have created the SharePoint Central Administration Web site. You can now create your farm and sites, and you can select services by using the Farm Configuration Wizard.

To run the Farm Configuration Wizard

  1. On the SharePoint Central Administration Web site, on the Configuration Wizards page, click Launch the Farm Configuration Wizard.

  2. On the Help Make SharePoint Better page, click one of the following options, and then click OK:

    • Yes, I am willing to participate (Recommended.)

    • No, I don't want to participate.

  3. On the Configure your SharePoint farm page, click Walk me through the settings using this wizard, and then click Next.

  4. In the Service Account section, click a service account that you want to use to configure your services.

    Note:

    For security reasons, we recommend that you use a different account from the farm administrator account to configure services in the farm.

    If you decide to use an existing managed account — that is, an account that SharePoint Foundation is aware of — ensure that you click that option before you continue.

  5. Select the services that you want to use in the farm, and then click Next.

    Note:

    For more information, see Configure services (SharePoint Foundation 2010). If you are using Microsoft Office Web Apps, see Office Web Apps (Installed on SharePoint 2010 Products).

  6. On the Create Site Collection page, do the following:

    1. In the Title and Description section, in the Title box, type the name of your new site.

    2. Optional: In the Description box, type a description of what the site contains.

    3. In the Web Site Address section, select a URL path for the site.

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

      Note:

      To view a template or a description of a template, click any template in the Select a template list.

  7. Click OK.

  8. On the Configure your SharePoint farm page, review the summary of the farm configuration, and then click Finish.

Post-installation steps

After you install and configure SharePoint Foundation 2010, your browser window opens to the Central Administration Web site of your new SharePoint site. Although you can start adding content to the site or customizing the site, we recommend that you first perform the following administrative tasks by using the SharePoint Central Administration Web site.

  • Configure usage and health data collection You can configure usage and health data collection in your server farm. The system writes usage and health data to the logging folder and to the logging database. For more information, see Configure usage and health data collection (SharePoint Foundation 2010).

  • Configure diagnostic logging You can configure diagnostic logging that might be required after initial deployment or upgrade. The default settings are sufficient for most situations, but depending upon the business needs and lifecycle of the farm, you might want to change these settings. For more information, see Configure diagnostic logging (SharePoint Foundation 2010).

  • Configure incoming e-mail You can configure incoming e-mail so that SharePoint sites accept and archive incoming e-mail. You can also configure incoming e-mail so that SharePoint sites can archive e-mail discussions as they happen, save e-mailed documents, and show e-mailed meetings on site calendars. In addition, you can configure the SharePoint Directory Management Service to provide support for e-mail distribution list creation and management. For more information, see Configure incoming e-mail (SharePoint Foundation 2010).

  • Configure outgoing e-mail You can configure outgoing e-mail so that your Simple Mail Transfer Protocol (SMTP) server sends e-mail alerts to site users and notifications to site administrators. You can configure both the "From" e-mail address and the "Reply" e-mail address that appear in outgoing alerts. For more information, see Configure outgoing e-mail (SharePoint Foundation 2010).

  • Configure a mobile account You can configure a mobile account so that SharePoint sends text message (SMS) alerts to your, or site users', mobile phones. For more information, see Configure a mobile account (SharePoint Foundation 2010).

  • Install and configure Remote BLOB Storage You can install and configure Remote BLOB Storage (RBS) for an instance of SQL Server 2008 that supports a SharePoint farm. For more information, see Install and configure RBS (SharePoint Foundation 2010).

    ***BEGIN MOSS ONLY***

See Also

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010


Deploy a single server with a built-in database (SharePoint Foundation 2010)
See Also

This article describes how to perform a clean installation of Microsoft SharePoint Foundation 2010 on a single server with a built-in database.

In this article:

  • Overview

  • Before you begin

  • Install SharePoint Foundation 2010

  • Post-installation steps

  • Configure Windows Server Backup

Overview

You can quickly publish a SharePoint site by deploying SharePoint Foundation 2010 on a single server with a built-in database. This configuration is useful if you want to evaluate SharePoint Foundation 2010 features and capabilities, such as collaboration, document management, and search. This configuration is also useful if you are deploying a small number of Web sites and you want to minimize administrative overhead. When you deploy SharePoint Foundation 2010 on a single server with a built-in database by using the default settings, Setup installs Microsoft SQL Server 2008 Express and the SharePoint product, and then the SharePoint Products Configuration Wizard creates the configuration database and content database for your SharePoint sites. Additionally, the SharePoint Products Configuration Wizard installs the SharePoint Central Administration Web site and creates your first SharePoint site collection.

Note:

This article does not describe how to install SharePoint Foundation 2010 in a farm environment, or how to upgrade from previous releases of SharePoint Foundation. For more information about installing SharePoint Foundation 2010 on a single server farm, see Deploy a single server with SQL Server (SharePoint Foundation 2010). For more information about installing SharePoint Foundation 2010 on a multiple server farm, see Multiple servers for a three-tier farm (SharePoint Foundation 2010). For more information about upgrade, see Upgrading to SharePoint Foundation 2010.

Consider the following restrictions of this method of installation:

  • You cannot install the single server with built-in database version of SharePoint Foundation on a domain controller.

  • A SQL Server 2008 Express database cannot be larger than 4 GB.

Before you begin

Before you begin deployment, ensure that you have met all hardware and software requirements. For more information, see Hardware and software requirements (SharePoint Foundation 2010). Also, ensure that you perform a clean installation of SharePoint Foundation 2010. You cannot install the RTM version of SharePoint Foundation 2010 without first removing the beta version of SharePoint Foundation 2010

Install SharePoint Foundation 2010

To install and configure SharePoint Foundation 2010, follow these steps:

  1. Run the Microsoft SharePoint Products Preparation Tool, which installs all prerequisites to use SharePoint Foundation 2010.

  2. Run Setup, which installs SQL Server 2008 Express and the SharePoint product.

  3. Run SharePoint Products Configuration Wizard, which installs the SharePoint Central Administration Web site and creates your first SharePoint site collection.

  4. Configure browser settings.

  5. Perform post-installation steps.

Important:

To complete the following procedures, you must be a member of the Administrators group on the local computer.

Run the Microsoft SharePoint Products Preparation Tool

Use the following procedure to install software prerequisites for SharePoint Foundation 2010.

To run the Microsoft SharePoint Products Preparation Tool

  1. Insert your SharePoint Foundation 2010 installation disc.

  2. On the SharePoint Foundation 2010 Start page, click Install software prerequisites.

    Note:

    Because the preparation tool downloads components from the Microsoft Download Center, you must have Internet access on the computer on which you are installing SharePoint Foundation.

  3. On the Welcome to the Microsoft SharePoint Products Preparation Tool page, click Next.

  4. On the Installation Complete page, click Finish.

Run Setup

The following procedure installs SQL Server 2008 Express and the SharePoint product. At the end of Setup, you can choose to start the SharePoint Products Configuration Wizard, which is described later in this section.

To run Setup

  1. On the SharePoint Foundation 2010 Start page, click Install SharePoint Foundation.

  2. On the Read the Microsoft Software License Terms page, review the terms, select the I accept the terms of this agreement check box, and then click Continue.

  3. On the Choose the installation you want page, click Standalone.

  4. When Setup finishes, a dialog box prompts you to complete the configuration of your server. Ensure that the Run the SharePoint Products Configuration Wizard now check box is selected.

  5. Click Close to start the configuration wizard.

Note:

If Setup fails, check the TEMP folder of the user who ran Setup. Ensure that you are logged in as the user who ran Setup, and then type %temp% in the location bar in Windows Explorer. If the path %temp% resolves to a location that ends in a "1" or "2", you will need to navigate up one level to view the log files. The log file name is Microsoft SharePoint Foundation 2010 Setup (<timestamp>).

Tip:

To access the SharePoint Products Configuration Wizard, click Start, point to All Programs, and then click Microsoft SharePoint 2010 Products. If the User Account Control dialog box appears, click Continue.

Run the SharePoint Products Configuration Wizard

The following procedure installs and configures the configuration database, the content database, and installs the SharePoint Central Administration Web site. It also creates your first SharePoint site collection.

To run the SharePoint Products Configuration Wizard

  1. On the Welcome to SharePoint Products page, click Next.

  2. In the dialog box that notifies you that some services might need to be restarted during configuration, click Yes.

  3. On the Configuration Successful page, click Finish.

    Note:

    If the SharePoint Products Configuration Wizard fails, check the PSCDiagnostics log files, which are located on the drive on which SharePoint Foundation is installed, in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14\LOGS folder.

    Note:

    If you are prompted for your user name and password, you might need to add the SharePoint Central Administration Web site to the list of trusted sites and configure user authentication settings in Internet Explorer. You might also want to disable the Internet Explorer Enhanced Security settings. Instructions for how to configure or disable these settings are provided in the following section.

    Note:

    If you see a proxy server error message, you might need to configure your proxy server settings so that local addresses bypass the proxy server. Instructions for configuring proxy server settings are provided later in the following section.

Configure browser settings

After you run the SharePoint Products Configuration Wizard, you should ensure that SharePoint Foundation works properly for local administrators in your environment by configuring additional settings in Internet Explorer.

Note:

If local administrators are not using Internet Explorer, you might need to configure additional settings. For information about supported browsers, see Plan browser support (SharePoint Foundation 2010).

If you are prompted for your user name and password, perform the following procedures:

  • Add the SharePoint Central Administration Web site to the list of trusted sites

  • Disable Internet Explorer Enhanced Security settings

If you receive a proxy server error message, perform the following procedure:

  • Configure proxy server settings to bypass the proxy server for local addresses

For more information, see Getting Started with IEAK 8 (http://go.microsoft.com/fwlink/p/?LinkId=151359).

To add the SharePoint Central Administration Web site to the list of trusted sites

  1. In Internet Explorer, on the Tools menu, click Internet Options.

  2. On the Security tab, in the Select a zone to view or change security settings area, click Trusted Sites, and then click Sites.

  3. Clear the Require server verification (https:) for all sites in this zone check box.

  4. In the Add this Web site to the zone box, type the URL to your site, and then click Add.

  5. Click Close to close the Trusted Sites dialog box.

  6. Click OK to close the Internet Options dialog box.

    If you are using a proxy server in your organization, use the following steps to configure Internet Explorer to bypass the proxy server for local addresses.

To disable Internet Explorer Enhanced Security settings

  1. Click Start, point to All Programs, point to Administrative Tools, and then click Server Manager.

  2. In Server Manager, select the root of Server Manager.

  3. In the Security Information section, click Configure IE ESC.

    The Internet Explorer Enhanced Security Configuration dialog box opens.

  4. In the Administrators section, click Off to disable the Internet Explorer Enhanced Security settings, and then click OK.

To configure proxy server settings to bypass the proxy server for local addresses

  1. In Internet Explorer, on the Tools menu, click Internet Options.

  2. On the Connections tab, in the Local Area Network (LAN) settings area, click LAN Settings.

  3. In the Automatic configuration area, clear the Automatically detect settings check box.

  4. In the Proxy Server area, select the Use a proxy server for your LAN check box.

  5. Type the address of the proxy server in the Address box.

  6. Type the port number of the proxy server in the Port box.

  7. Select the Bypass proxy server for local addresses check box.

  8. Click OK to close the Local Area Network (LAN) Settings dialog box.

  9. Click OK to close the Internet Options dialog box.

Post-installation steps

After you install SharePoint Foundation 2010, your browser window opens to the Central Administration Web site of your new SharePoint site. Although you can start adding content to the site or you can start customizing the site, we recommend that you first perform the following administrative tasks by using the SharePoint Central Administration Web site:

  • Configure usage and health data collection You can configure usage and health data collection in your server farm. The system writes usage and health data to the logging folder and to the logging database. For more information, see Configure usage and health data collection (SharePoint Foundation 2010).

  • Configure diagnostic logging You can configure diagnostic logging that might be required after initial deployment or upgrade. The default settings are sufficient for most situations, but depending upon the business needs and lifecycle of the farm, you might want to change these settings. For more information, see Configure diagnostic logging (SharePoint Foundation 2010).

  • Configure incoming e-mail You can configure incoming e-mail so that SharePoint sites accept and archive incoming e-mail. You can also configure incoming e-mail so that SharePoint sites can archive e-mail discussions as they happen, save e-mailed documents, and show e-mailed meetings on site calendars. In addition, you can configure the SharePoint Directory Management Service to provide support for e-mail distribution list creation and management. For more information, see Configure incoming e-mail (SharePoint Foundation 2010).

  • Configure outgoing e-mail You can configure outgoing e-mail so that your Simple Mail Transfer Protocol (SMTP) server sends e-mail alerts to site users and notifications to site administrators. You can configure both the "From" e-mail address and the "Reply" e-mail address that appear in outgoing alerts. For more information, see Configure outgoing e-mail (SharePoint Foundation 2010).

  • Configure a mobile account You can configure a mobile account so that SharePoint sends text message (SMS) alerts to your, or site users', mobile phones. For more information, see Configure a mobile account (SharePoint Foundation 2010).

  • Install and configure Remote BLOB Storage You can install and configure Remote BLOB Storage (RBS) for an instance of SQL Server 2008 that supports a SharePoint server farm. For more information, see Install and configure RBS (SharePoint Foundation 2010).

Configure Windows Server Backup

If you want to use Windows Server Backup with SharePoint Foundation 2010, you must register the SharePoint 2010 VSS Writer with Windows Server Backup by running the stsadm -o registerwsswriter command. For more information, see Registerwsswriter: Stsadm operation (Windows SharePoint Services).

See Also

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010


Multiple servers for a three-tier farm (SharePoint Foundation 2010)
See Also

You can install Microsoft SharePoint Foundation 2010 on multiple servers to create a Microsoft SharePoint Foundation farm that is deployed across three tiers.

The farm consists of two front-end Web servers, an application server, and a database server. The deployment sequence and configurations that are described in this article are based on recommended best practices. The resulting farm configuration is not complex, but provides a fundamental infrastructure for implementing a SharePoint Foundation solution on similar — or more complex — farms.

The farm is provisioned with SharePoint Foundation Search; Search is configured to crawl the content that is created as part of this deployment.

In this article:

  • Overview

  • Prepare the farm servers

  • Install SharePoint Foundation 2010 on the farm servers

  • Create and configure the farm

  • Add Web servers to the farm

  • Configure diagnostic logging and usage and health data collection

  • Configure SharePoint Foundation Search

  • Create a site

  • Post-installation steps

Overview

The basic steps in this deployment are as follows:

  • Ensure that you are familiar with the concept of a three-tier topology.

  • Ensure that you have done all the planning and preparatory work, such as verifying hardware and software requirements.

  • Install the required software updates on all servers that will be part of the farm.

  • Install the SharePoint Foundation prerequisites on servers in the application and Web tiers.

  • Install SharePoint Foundation on the application server and the Web servers.

  • Create and configure the SharePoint farm.

  • Provision services.

  • Complete post-deployment tasks as required.

Topology overview

This topology is typically used for the medium and large farms described in Deployment overview (SharePoint Foundation 2010). In terms of performance, capacity, and scalability, a three-tier topology is recommended over a two-tier topology. A three-tier topology provides the most efficient physical and logical layout to support scaling out or scaling up, and provides better distribution of services across the member servers of the farm. The following illustration shows the three-tier deployment that is described in this article.

SharePoint Foundation 2010: three tier farm

Referring to the preceding illustration, note the following:

  • You can add Web servers to the Web tier. These servers are be configured as conventional Web servers to handle user requests.

  • You can add farm servers to the application tier and configure them as dedicated servers that will host the Central Administration Web site or other services on the farm that require dedicated resources or isolation from the Web tier — for example, timer jobs and sandbox services.

  • You can add database servers to the database tier to implement a stand-alone instance, database mirroring, or a failover cluster. If you are configuring the farm for high availability, database mirroring or a failover cluster is required on the database tier.

Before you begin

Before you begin deployment, do the following:

  • Ensure that you are familiar with the operating-system guidelines described in Performance Tuning Guidelines for Windows Server 2008 and Performance Tuning Guidelines for Windows Server 2008 R2.

  • Ensure that you have met all hardware and software requirements. For more information, see Hardware and software requirements (SharePoint Foundation 2010).

  • Ensure that you are prepared to set up the required accounts with appropriate permissions, as described in Initial deployment administrative and service accounts (SharePoint Foundation 2010).

    Note:

    As a security best practice, we recommend that you install SharePoint Foundation by using least-privilege administration.

Using the Microsoft SharePoint 2010 Products Preparation Tool

The Microsoft SharePoint Products Preparation Tool checks for the presence of prerequisites, and installs and configures any programs that are required. The Microsoft SharePoint Products Preparation Tool requires an Internet connection to download and configure SharePoint Foundation prerequisites. If you do not have an Internet connection for the farm servers, you will have to obtain installable images for the required software. For installation locations, see "Installing software prerequisites" in Hardware and software requirements (SharePoint Foundation 2010).

If you decide to obtain installable images, we recommend that you create an installation point that you can use for storing the images. You can use this installation point for installing future software updates.

Database server

Ensure that SQL Server 2005 or SQL Server 2008 is updated to the required level and configured as follows:

  • SQL Server 2005: Local and remote connections are enabled and are configured to use the TCP/IP protocol.

  • SQL Server 2008: The TCP/IP protocol is enabled for the network configuration.

In organizations whose database administrators operate independently from SharePoint administrators, you will need to ensure that the correct version of SQL Server is available and updated to the required level. In addition, you will have to request a DBA-created database that is configured for your farm.

Note:

The procedures in this article do not use a DBA-created database; these procedures will be different in a DBA-created database deployment. For more information, see Deploy by using DBA-created databases (SharePoint Foundation 2010).

Public updates and hotfix packages

Ensure that public updates and the required hotfix packages are installed for the operating system, SQL Server, and SharePoint Foundation. We recommend that all servers be updated to the same software version before you apply the public updates. The following hotfixes must be applied for this release of SharePoint Foundation:

  • SQL Server 2008: Install this update before deploying the farm. Cumulative update package 2 for SQL Server 2008 Service Pack 1

  • After you install the prerequisites on each farm server, you will need to install Error message when you use the "IMSAdminBase::CopyKey" method as a part of the IIS 6.0 Compatibility components in IIS 7.0: "Exception from HRESULT: 0x80070003" on the application server first, and then on the two Web servers.

Prepare the farm servers

Before you install SharePoint Foundation, you must check for and install all the prerequisites on the application server and the Web servers by using the Microsoft SharePoint Products Preparation Tool.

Tip:

If you decide to install prerequisites manually, you can still run the Microsoft SharePoint Products Preparation Tool to verify which prerequisites are required on each server.

Use the following procedure to install prerequisites on each of the farm servers.

To run the preparation tool

  1. Download SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=168781) from the product installation location, and then double-click the appropriate executable file.

  2. If you install from a bootable image, click Install software prerequisites on the splash screen.

    Note:

    You can download all of the prerequisites and install them from a network share. For more information, see Install prerequisites from a network share (SharePoint Server 2010).

  3. On the Welcome to the Microsoft SharePoint Products Preparation Tool page, click Next.

    Note:

    The preparation tool may have to restart the local server to complete the installation of some of the prerequisites. The installer will continue to run after the server is restarted, and no manual intervention is required. However, you will have to log back on to the server.

  4. On the Installation Complete page, click Finish.

    Note:

    After you complete the Microsoft SharePoint Products Preparation Tool, you must install KB 949516 (http://go.microsoft.com/fwlink/p/?LinkId=148917) and KB 971831 (http://support.microsoft.com/kb/971831). You might also need to restart the server after installing this hotfix.

    Note:

    If the error message "Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)" is displayed when you start the IIS worker process (w3wp.exe), another service, or a managed application on a server that is also running SharePoint Foundation 2010, you must install KB963676 (http://go.microsoft.com/fwlink/p/?LinkId=151358). You must restart the computer after you apply this hotfix.

Install SharePoint Foundation 2010 on the farm servers

After the prerequisites are installed, use the following procedure to install SharePoint Foundation on each of the farm servers.

To run Setup

  1. On the Start page, click Install SharePoint Foundation.

  2. On the Read the Microsoft Software License Terms page, review the terms, select the I accept the terms of this agreement check box, and then click Continue.

  3. On the Choose the installation you want page, click Server Farm.

  4. On the Server Type tab, click Complete.

  5. On the File Location tab, accept the default location or change the installation path, and then click Install Now.

    Note:

    As a best practice, we recommend that you install SharePoint Foundation on a non-system drive.

  6. When Setup finishes, a dialog box prompts you to complete the configuration of your server. Clear the Run the SharePoint Products and Technologies Configuration Wizard now check box.

    Note:

    For consistency of approach, we recommend that you do not run the configuration wizard until SharePoint Foundation has been installed on all application and front-end Web servers that will participate in the server farm.

  7. Click Close to finish Setup.

Create and configure the farm

To create and configure the farm, you run the SharePoint Products Configuration Wizard. This wizard automates several configuration tasks, including creating the configuration database, installing services, and creating the Central Administration Web site. It is recommended that you run the SharePoint Products Configuration Wizard on the server that will host the Central Administration Web site before you run the wizard on the other servers in the farm.

To run the configuration wizard and configure the farm

  1. On the server that will host Central Administration (the application server), click Start, point to All Programs, and then click Microsoft SharePoint 2010 Products.

  2. In the list of available options, click SharePoint Products and Technologies Configuration Wizard.

  3. On the Welcome to SharePoint Products page, click Next.

  4. In the dialog box that notifies you that some services might need to be restarted during configuration, click Yes.

  5. On the Connect to a server farm page, click Create a new server farm, and then click Next.

  6. On the Specify Configuration Database Settings page, do the following:

    1. In the Database server box, type the name of the computer that is running SQL Server.

    2. In the Database name box, type a name for your configuration database, or use the default database name. The default name is SharePoint_Config.

    3. In the Username box, type the user name of the server farm account in DOMAIN\username format.

      Important:

      The server farm account is used to create and access your configuration database. It also acts as the application pool identity account for the SharePoint Central Administration application pool, and it is the account under which the Windows SharePoint Services Timer service runs. The SharePoint Products Configuration Wizard adds this account to the SQL Server Login accounts, the SQL Server dbcreator server role, and the SQL Server securityadmin server role. The user account that you specify as the service account must be a domain user account, but it does not need to be a member of any specific security group on your Web servers or your database servers. We recommend that you follow the principle of least privilege, and specify a user account that is not a member of the Administrators group on your Web servers or your database servers.

    4. In the Password box, type the user password.

  7. Click Next.

  8. On the Specify Farm Security Settings page, type a passphrase, and then click Next.

    Ensure that the passphrase meets the following criteria:

    • Contains at least eight characters

    • Contains at least three of the following four character groups:

      • English uppercase characters (from A through Z)

      • English lowercase characters (from a through z)

      • Numerals (from 0 through 9)

      • Nonalphabetic characters (such as !, $, #, %)

      Note:

      Although a passphrase is similar to a password, it is usually longer to enhance security. It is used to encrypt credentials of accounts that are registered in SharePoint Foundation 2010. For example, the SharePoint Foundation 2010 system account that you provide when you run the SharePoint Products Configuration Wizard wizard. Ensure that you remember the passphrase, because you must use it each time you add a server to the farm.

  9. On the Configure SharePoint Central Administration Web Application page, do the following:

    1. Either select the Specify port number check box and type a port number if you want the SharePoint Central Administration Web application to use a specific port number, or leave the Specify port number check box cleared if you want to use the default port number.

      Note:

      If you want to access the SharePoint Central Administration Web site from a remote computer, ensure that you allow access to the port number that you configure in this step. You do this by configuring the inbound rule for SharePoint Central Administration v4 in Windows Firewall with Advanced Security.

    2. Click either NTLM or Negotiate (Kerberos).

  10. Click Next.

  11. On the Configuration Successful page, click Finish.

    Note:

    If the SharePoint Products Configuration Wizard fails, check the log files on the drive on which SharePoint Foundation 2010 is installed, which are located in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14\LOGS folder.

  12. The Central Administration Web site will open in a new browser window.

    On the Help Make SharePoint Better page, click one of the following options and then click OK.

    1. Yes, I am willing to participate (Recommended).

    2. No, I don't wish to participate.

  13. On the Configure your SharePoint farm page, you have the option to use a wizard to configure services or you can decide to configure services manually. For the purpose of this article, we use the manual option. Click Cancel.

    The choice you make here is a matter of personal preference. The Farm Configuration Wizard will configure some services automatically when it is run; however, if you configure services manually you have greater flexibility in designing your logical architecture.

    For information about using the wizard to configure services, see Configure services (SharePoint Foundation 2010). If you are using Microsoft Office Web Apps, see Office Web Apps (Installed on SharePoint 2010 Products).

    Important:

    If you are using a DBA-created database you cannot use the Farm Configuration Wizard, you must use SharePoint Products Configuration Wizard.

Add Web servers to the farm

After you create the farm on the application server, you can add the servers for the Web tier by following the same process described earlier in this topic for installing SharePoint Foundation on the server that hosts Central Administration. The only difference is that during Setup, you will be prompted to join and existing farm. Follow the wizard steps to join the farm.

For additional information about adding servers to a farm, see Add a Web or application server to the farm (SharePoint Foundation 2010). This article also provides detailed information for the steps in the following procedure.

Configure diagnostic logging and usage and health data collection

After you add the front-end Web servers, configure initial diagnostic logging and usage and health data collection for the farm.

Diagnostic logging can help identify and isolate issues as they occur in your server farm. Accept the default settings when you configure diagnostic logging on new installations. Then, when issues occur in your server farm, you can revisit these settings and adjust the levels accordingly. This will help to identify the cause and isolate the issues. Usage and health reporting can be used to show where diagnostic logging settings deviate from the default values.

For more information about diagnostic and health usage, see:

  • Configure diagnostic logging (SharePoint Foundation 2010)

  • Configure usage and health data collection (SharePoint Foundation 2010)

Use the following procedures to complete the initial configuration of diagnostic logging and usage and health data collection.

Note:

Because this is an initial farm deployment without any benchmark data, default settings are accepted unless otherwise noted.

To configure diagnostic logging

  1. On the Central Administration Home page, click Monitoring.

  2. In the Reporting section, click Configure diagnostic logging.

  3. On the Diagnostic Logging page, verify that Enable Event Log Flood Protection is selected. If not, click the corresponding check box to enable this feature.

  4. The default location for the Trace Log is on the drive where you installed SharePoint Foundation. As a best practice, we recommend that the trace log be stored on a non-system drive.

    Important:

    If you change the trace log path to a non-system drive, this location must exist on all the servers in the farm. Existing or new servers cannot log data if the location does not exist. In addition, you will not be able to add new servers unless the path you specify exists on the new server. You cannot use a network share for logging purposes.

  5. Click OK to save your changes.

After you finish configuring diagnostic logging, configure usage and health data collection.

To configure usage and health data collection

  • On the Central Administration Monitoring page, click Configure usage and health data collection.

  • Click the check box to enable Usage Data Collection.

  • Click the check box to enable Health Data Collection.

  • Click OK.

Configure SharePoint Foundation Search

SharePoint Foundation Search is automatically installed when you install SharePoint Foundation. However, the search service is not started and some configuration is required.

Use the following procedure to configure and start search for the SharePoint Foundation farm.

To configure SharePoint Foundation Search

  1. On the Central Administration home page, click Manage services on server.

  2. On the Services on Server page, click SharePoint Foundation Search. This action opens the Configure Microsoft SharePoint Foundation Search Service Settings page, where you configure the following settings.

  3. In the Service Account section, type in a User name and Password.

  4. In the Content Access Account section, type in a User name and Password for an account that will have read-only access to all the content.

    Security Note:

    Do not use a highly privileged account or one that can modify content.

  5. Click OK to save your configuration changes.

  6. On the Services on Server page, click Start to start SharePoint Foundation Search.

Create a site

To create a site during this phase of the deployment, you must create a Web application and a site collection. Use the procedures in the following articles to create a Web application by using Central Administration, and then create a top-level Web site that is associated with the Web application.

  • Create a Web application

    Important:

    When creating a new Web application or extending the existing Web application into a new zone initially, ensure that the public URL is the URL that end users will use to browse to the Web application. If you are using reverse proxy servers or load balancers, you may also have to add internal URLs for alternate access mapping (AAM). We recommend that you configure AAM before creating a site collection.

  • Create a site collection (SharePoint Foundation 2010)

Post-installation steps

After you install and configure SharePoint Foundation 2010, your browser window opens to the Central Administration Web site of your new SharePoint site. Although you can start adding content to the site or customizing the site, we recommend that you first perform the following administrative tasks by using the SharePoint Central Administration Web site.

  • Configure outgoing e-mail You can configure outgoing e-mail so that your Simple Mail Transfer Protocol (SMTP) server sends e-mail alerts to site users and notifications to site administrators. You can configure both the "From" e-mail address and the "Reply" e-mail address that appear in outgoing alerts. For more information, see Configure outgoing e-mail (SharePoint Foundation 2010).

    Note:

    You can configure incoming e-mail so that SharePoint sites accept and archive incoming e-mail. However, we recommend that you undertake this task after you complete the initial farm deployment and configuration. For more information, see Configure incoming e-mail (SharePoint Foundation 2010).

  • Configure a mobile account You can configure a mobile account so that SharePoint sends text message (SMS) alerts to your, or site users', mobile phones. For more information, see Configure a mobile account (SharePoint Foundation 2010).

See Also

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010


Quick start: Deploy single server in an isolated Hyper-V environment (SharePoint Foundation 2010)
See Also

You can use an isolated and secure Hyper-V virtual machine to test the features and behavior of SharePoint Foundation 2010. This approach uses minimal hardware resources and enables you to isolate the SharePoint Foundation 2010 test system from a production environment. This isolation is recommended in order to eliminate potential security threats to a corporate network and server environment.

By using the manual steps or the Windows PowerShell 2.0 commands that are provided in this article, you can quickly deploy SharePoint Foundation 2010 on a single server that uses one of the following databases:

  • The built-in SQL Server 2008 Express database that is provided with SharePoint Foundation

  • Microsoft SQL Server 2005 with Service Pack 3 (SP3) and Cumulative Update 3 installed

  • Microsoft SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2

Important:

The single-server SharePoint Foundation deployment described in this article is only intended to be used for evaluation and testing purposes, and should not be used in a production environment.

In this article:

  • Requirements and recommendations

  • Required permissions

  • Pre-deployment tasks

  • Deploy SharePoint Foundation 2010 manually

  • Deploy SharePoint Foundation 2010 by using Windows PowerShell scripts

Requirements and recommendations

The following requirements and recommendations for the Hyper-V virtualization server, virtual machine, and the deployment environment only apply to the single-server deployment scenario described in this article.

Virtualization server and virtual machine configuration

The following table provides the minimum and recommended configurations for the virtualization server and the virtual machines. These configurations will support the database options that are available for a single server deployment.

Resource Minimum Recommended

CPU

Dual processor, 2 gigahertz (GHz)

Dual processor, 2 GHz

Memory

4 gigabytes (GB)

8 GB

Hard drive

Fixed-size virtual hard disk that has a capacity of 40 GB

Tip:

To speed up the creation of a fixed-size virtual hard disk, initially configure the hard disk as dynamically expanding. After you install all the required software (including SharePoint Foundation), convert the virtual hard disk to a fixed-size hard disk.

Fixed-size virtual hard disk that has a capacity of 80 GB

Network adapter type

Synthetic

Synthetic

Network type

Internal to ensure virtual machine isolation and enable virtualization server-virtual machine communications

Tip:

For ease of access to—and installation of—required and recommended software, use an External network. When you are ready to install SharePoint Foundation, configure the virtual machines to use an Internal network.

Internal to ensure virtual machine isolation and enable virtualization server-virtual machine communications

The following configuration guidance is provided for the virtualization server:

  • The logical-to-virtual processor (core) ratio should be as low as possible, with 1:1 being optimal.

  • Using the 1:1 logical-to-virtual processor ratio, you should configure the virtualization server so the total number of processors on the virtual machines is less than the total number of physical cores. For example, if you are using a four-core virtualization server, the best practice is to create three virtual machines that use a single processor, or one virtual machine that has two processors and one virtual machine that uses one processor. Either of these configurations would leave one core free for virtualization server processes.

In addition to the preceding requirements for the virtual environment, review the Hardware and software requirements (SharePoint Foundation 2010) article before you start deploying SharePoint Foundation 2010 on the virtual machine.

Deployment environment

A domain is required to deploy SharePoint Foundation 2010.

If you do not have an isolated virtual domain available to deploy SharePoint Foundation 2010, you must create a virtual domain on a Hyper-V that is configured to use the following:

  • A domain controller with Active Directory Domain Services (AD DS)

  • A domain controller with a DNS server

You can deploy SharePoint Foundation on a domain controller. However, some configuration is required. Start Windows PowerShell with the Run as administrator option and run the following commands to enable deployment on a domain controller:

Copy Code
$acl = Get-Acl HKLM:\System\CurrentControlSet\Control\ComputerName
$person = [System.Security.Principal.NTAccount]"Users"
$access = [System.Security.AccessControl.RegistryRights]::FullControl
$inheritance = [System.Security.AccessControl.InheritanceFlags]"ContainerInherit, ObjectInherit"
$propagation = [System.Security.AccessControl.PropagationFlags]::None
$type = [System.Security.AccessControl.AccessControlType]::Allow
$rule = New-Object System.Security.AccessControl.RegistryAccessRule($person, $access, $inheritance, $propagation, $type)
$acl.AddAccessRule($rule)
Set-Acl HKLM:\System\CurrentControlSet\Control\ComputerName $acl

Required permissions

In order to install SharePoint Foundation 2010, the logon account that you are using on the virtual machine must be a member of:

  • The local Administrators group on the virtual machine

  • The SQL Server dbcreator fixed server role

  • The SQL Server securityadmin server role

For more information, see Initial deployment administrative and service accounts (SharePoint Foundation 2010).

Pre-deployment tasks

Complete the following tasks before you deploy SharePoint Foundation 2010:

  • On the virtualization server, create an installation point that contains the SharePoint Foundation software or provide media, such as an ISO image, that can be accessed from the virtual machine.

  • Create a virtual machine that meets the minimum requirements described in the "Requirements and recommendations" section earlier in this article.

  • On the virtual machine:

    • Install the operating system and the mandatory and recommended security updates.

    • Install the edition of SQL Server that you want to use if you are not using the built-in version that is provided with SharePoint Foundation.

    • Install the mandatory and recommended updates for the edition of SQL Server that you install.

    • Configure the Windows Server firewall to enable SQL Server access. For more information, see Configuring the Windows Firewall to Allow SQL Server Access (http://go.microsoft.com/fwlink/p/?LinkID=134724).

    • Review the Hardware and software requirements (SharePoint Foundation 2010)article to determine the programs and hotfixes that must be obtained and installed before you install SharePoint Foundation 2010.

Deploy SharePoint Foundation 2010 manually

For information about how to manually deploy SharePoint Foundation 2010 on a single server, see Deploy a single server with a built-in database (SharePoint Foundation 2010) or Deploy a single server with SQL Server (SharePoint Foundation 2010).

Deploy SharePoint Foundation 2010 by using Windows PowerShell scripts

You can use Windows PowerShell scripts to deploy SharePoint Foundation 2010 on a single server.

Security Note:

As a best practice, you should not run unsigned scripts.

For more information about signing Windows PowerShell scripts, see Windows PowerShell: Sign Here Please (http://go.microsoft.com/fwlink/p/?linkid=160357) in TechNet Magazine. For more information about code signing in general, see Introduction to Code Signing (http://go.microsoft.com/fwlink/p/?linkid=59273) on MSDN. For more information about setting up your own certification authority (CA), see Active Directory Certificate Services (http://go.microsoft.com/fwlink/p/?linkid=136444) in the TechNet Library.

Create and use one of the following Windows PowerShell script files to deploy SharePoint Foundation on a single server.

  • simplesingleserver.ps1: Installs SharePoint Foundation 2010 using the built-in database to store configuration information and documents.

  • simplefarm.ps1: Installs SharePoint Foundation 2010 using either SQL Server 2005 or SQL Server 2008 to store configuration information and documents.

simplesingleserver.ps1

This script deploys SharePoint Foundation 2010 on a single server that uses the built-in database.

Copy the following code to a text editor and save it as simplesingleserver.ps1 in the directory of your choice:

Copy Code

$SetupPath         = Read-Host -Prompt "Please specify the path to the install media (D:)"

## Here is the script to install SharePoint Foundation 2010 with SQL Express and create Central Admin ##
& $SetupPath\PrerequisiteInstaller.exe /unattended | Write-Host
if( $lastexitcode -eq 0 ) {
    & $SetupPath\setup.exe /config $SetupPath\Files\SetupSilent\config.xml | Write-Host
    if( $lastexitcode -eq 0 ) {
        Write-Host "Install successful..."
    } else { Write-Error "ERROR: $lastexitcode" }
} else { Write-Error "ERROR: $lastexitcode" }

To run simplesingleserver.ps1

  1. Start Windows PowerShell 2.0 using the Run as administrator option.

  2. Navigate to the directory where you saved simplesingleserver.ps1.

  3. Run .\simplesingleserver.ps1 from the Windows PowerShell command prompt.

simplefarm.ps1

This script deploys SharePoint Foundation 2010 on a single server that uses a SQL Server database. Copy the following code to a text editor and save it as simplefarm.ps1 in the directory of your choice:

Copy Code

## Settings you may want to change ##
$err = $null
$SetupPath         = Read-Host -Prompt "Please specify the path to the install media (D:)"
Write-Host "Please specify the Farm Administrator credentials"
$FarmCredential    = Get-Credential "DOMAIN\<Farm Admin>"
$DBServer          = Read-Host -Prompt "Please enter the name of your database server"
$Passphrase        = Read-Host -Prompt "Please enter the farm passphrase (optional)" -AsSecureString
$FarmName          = Read-Host -Prompt "Please enter a farm name (optional)"
$CAPort            = Read-Host -Prompt "Please enter the Central Administration port number (optional)"

if ([String]::IsNullOrEmpty($SetupPath))
{
    Write-Error "You must enter the install media path"
    return
}
if ([String]::IsNullOrEmpty($FarmCredential))
{
    Write-Error "You must enter a Farm Administrator's user name and password"
    return
}
if ([String]::IsNullOrEmpty($DBServer))
{
    Write-Error "You must enter a database server"
    return
}
if ($Passphrase.Length -eq 0)
{
    Write-Warning "You didn't enter a farm passphrase, using the Farm Administrator's password instead"
    $Passphrase = $FarmCredential.Password
}
if ([String]::IsNullOrEmpty($FarmName))
{
    Write-Warning "You didn't enter a farm name, using the machine name instead"
    $FarmName = $env:COMPUTERNAME
}
if ([String]::IsNullOrEmpty($CAPort))
{
    Write-Warning "You didn't enter a Central Administration port number, using 5000 instead"
    $CAPort = 5000
}

## Here is the script to install SharePoint Foundation 2010 and create Central Admin ##
Write-Host "[1/15] Running prerequisite installer..."
& $SetupPath\PrerequisiteInstaller.exe /unattended | Write-Host
if( $lastexitcode -eq 0 ) {
    Write-Host "[2/15] Running silent farm binary installation... (this will take some time)"
    & $SetupPath\setup.exe /config $SetupPath\Files\SetupFarmSilent\config.xml | Write-Host
    Write-Host "[3/15] Completed silent farm binary installation."
    if( $lastexitcode -eq 0 ) {
        Add-PSSnapin Microsoft.SharePoint.PowerShell -erroraction SilentlyContinue
        Write-Host "[4/15] Creating new configuration database..."
        New-SPConfigurationDatabase -DatabaseName ("{0}_SharePoint_Configuration_DB" -f $FarmName) -DatabaseServer $DBServer -AdministrationContentDatabaseName ("{0}_AdminContent_DB" -f $FarmName) -FarmCredentials $FarmCredential -Passphrase $Passphrase -ErrorVariable err
        Write-Host "[5/15] Verifying farm creation..."
        $spfarm = get-spfarm
            if ($spfarm -ne $null) {
            Write-Host "[6/15] ACLing SharePoint Resources..."
            Initialize-SPResourceSecurity -ErrorVariable err
            if ([String]::IsNullOrEmpty($err) -eq $true) {
                Write-Host "[7/15] Installing Services..."
                Install-SPService -ErrorVariable err
                    if ([String]::IsNullOrEmpty($err) -eq $true) {
                    Write-Host "[8/15] Installing Features..."
                    Install-SPFeature -AllExistingFeatures -ErrorVariable err
                    if ([String]::IsNullOrEmpty($err) -eq $true) {
                        Write-Host "[9/15] Provisioning Central Administration..."
                        New-SPCentralAdministration -Port $CAPort -WindowsAuthProvider "NTLM" -ErrorVariable err
                        if ([String]::IsNullOrEmpty($err) -eq $true) {
                            Write-Host "[10/15] Installing Help..."
                            Install-SPHelpCollection -All -ErrorVariable err
                            if ([String]::IsNullOrEmpty($err) -eq $true) {
                                Write-Host "[11/15] Installing Application Content..."
                                Install-SPApplicationContent -ErrorVariable err
                                if ([String]::IsNullOrEmpty($err) -eq $true) {
                                    Write-Host "[12/15] Basic configuration completed."
                                    $SPManagedAccount = Get-SPManagedAccount $FarmCredential.UserName
                                    Write-Host "[13/15] Creating Web Application and Application Pool..."
                                    $webApp = New-SPWebApplication -Name "SharePoint - 80" -ApplicationPool "SharePoint - 80" -ApplicationPoolAccount $SPManagedAccount -DatabaseServer $DBServer -DatabaseName ("{0}_Content_DB" -f $FarmName) -Url "http://localhost" -ErrorVariable err
                                    if ([String]::IsNullOrEmpty($err) -eq $true) {
                                        Write-Host "[14/15] Creating site collection..."
                                        $SPSite = New-SPSite -url "http://localhost" -OwnerAlias $FarmCredential.UserName -ErrorVariable err
                                        if ([String]::IsNullOrEmpty($err) -eq $true) {
                                            Write-Host "[15/15] Port 80 Web application and site collect created.  Browse to http://localhost to pick a template for the Web..."
                                        } else { Write-Error "ERROR: $err" }
                                    } else { Write-Error "ERROR: $err" }
                                } else { Write-Error "ERROR: $err" }
                            } else { Write-Error "ERROR: $err" }
                        } else { Write-Error "ERROR: $err" }
                    } else { Write-Error "ERROR: $err" }
                } else { Write-Error "ERROR: $err" }
            } else { Write-Error "ERROR: $err" }
        } else { Write-Error "ERROR: $err" }
    } else { Write-Error "ERROR: $lastexitcode" }
} else { Write-Error "ERROR: $lastexitcode" }

$exitprompt = Read-Host -Prompt "Press Enter to exit..."

To run simplefarm.ps1

  1. Start Windows PowerShell 2.0 using the Run as administrator option.

  2. Navigate to the directory where you saved simplefarm.ps1.

  3. Run .\simplefarm.ps1 from the Windows PowerShell command prompt.

See Also

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010
Resource Center: Virtualization for SharePoint Foundation 2010


Deploy by using DBA-created databases (SharePoint Foundation 2010)

This article describes how to deploy Microsoft SharePoint Foundation 2010 in a farm environment that uses DBA-created databases. In organizations where database administrators (DBAs) operate independently from SharePoint administrators, the DBAs create and manage all the databases. This is typical in IT environments where security requirements and company policies require a separation of administrator roles. The farm administrator provides Microsoft SharePoint Foundation 2010 database requirements to the database administrator, who in turn, creates the necessary Microsoft SharePoint Foundation databases and sets up the logins that are required for the farm.

In this article:

  • Before you begin

  • About configuring DBA-created databases

  • Create and configure databases for Central Administration

  • Create and configure additional databases

Before you begin

Before you start this deployment, ensure that you have all the information that you require in order to successfully deploy and configure SharePoint Foundation on all of the farm servers. The following sections provide the information that you will need to ensure a successful SharePoint Foundation deployment.

Farm server requirements

Ensure that all the farm servers and the database server meet the requirements that are documented in the following articles.

  • Hardware and software requirements: Hardware and software requirements (SharePoint Foundation 2010)

  • Administrative and service accounts: Initial deployment administrative and service accounts (SharePoint Foundation 2010)

Database requirements

Deploying SharePoint Foundation 2010 on DBA-created databases involves working with the DBA to ensure that all the SharePoint Foundation databases that you need are created and correctly configured before you create and configure the farm.

The following list shows some, but not necessarily all, of the information that a DBA needs in order to create databases for the farm. Additional information may be required by the DBA in your organization:

  • SQL Server version information as well as service pack and cumulative update level. For more information, see Hardware and software requirements (SharePoint Foundation 2010).

  • The required login accounts with associated roles and permissions. For more information, see Initial deployment administrative and service accounts (SharePoint Foundation 2010).

  • The number of databases that are required as well as SharePoint configuration specifics. This information can be obtained by deploying SharePoint Foundation.

  • SharePoint data storage requirements, such as data type, data volume, type of database activity (read or write) and Input/Output operations per second (IOPS).

  • The DBA must configure surface area settings so that local and remote connections use TCP/IP or named pipes.

  • All of the databases required by SharePoint Foundation use the Latin1_General_CI_AS_KS_WS collation.

  • All of the SharePoint Foundation databases require that the farm Setup user account is assigned to them as the database owner (dbo).

  • SharePoint user Service Level Agreement considerations.

About configuring DBA-created databases

Use the procedures in this article as a guide for deploying a farm that uses DBA-created databases. This deployment includes all the databases that are required for the farm.

Note:

This article only applies to the SQL Server database versions supported by SharePoint Foundation 2010.

For each procedure you must use Windows PowerShell 2.0 or SharePoint Foundation command-line tools to configure the farm.

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.

Note:

Psconfig is located in the following folder: Program Files\Common Files\Microsoft Shared\web server extensions\14\BIN.

In order to use Windows PowerShell to configure the farm:

  1. Verify that the user account has access to one of the servers on which Windows PowerShell 2.0 is running, and that the user account is a Farm Administrator and is a member of the SharePoint_Shell_Access role for the SQL Server-based source content database, the administration content database, the destination content database, and the configuration database.

  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 prompt, type the appropriate command, and then press ENTER.

For the purpose of illustrating the required procedures, the basic farm that needs to be configured consists of:

  1. Central Administration

  2. A Web portal

  3. Diagnostic logging and usage and health data collection

  4. Search

The following databases are required and are typically used by the farm administrator in the following sequence as the farm is created. The databases in the following list use the default names that are provided when you use the SharePoint Products Configuration Wizard to set up a farm. You can, of course, use database names that you choose.

  • The configuration database (SharePoint_Config)

  • The Central Administration content database (SharePoint_AdminContent_GUID)

  • The Web site content database, which is created automatically by the SharePoint Foundation Setup program (WSS_Content_GUID)

  • The diagnostic logging database (WSS_Logging_GUID)

  • The search database (WSS_SEARCH_localhost machine name)

Create and configure databases for Central Administration

Use the procedures in this section to create the required databases and give the accounts membership in the database Users security group and database roles.

The procedures require action by the DBA and the Setup user account. The labels [DBA] or [Setup] respectively are used for each step to indicate which role performs the action.

The following procedure only has to be performed once for the farm, on the server that you want to run the Central Administration Web site. The farm has one configuration database and one content database for Central Administration.

To create and configure the configuration database, the Central Administration content database, and the Central Administration Web application

  1. [DBA] Create the configuration database and the Central Administration content database using the LATIN1_General_CI_AS_KS_WS collation sequence and set the database owner (dbo) to be the Setup user account.

  2. [Setup] Run Setup on each server computer in the farm. You must run Setup on at least one of these computers by using the Complete installation option. The steps for this option are described in Deploy a single server with SQL Server (SharePoint Foundation 2010).

  3. [Setup] Do not run the SharePoint Products Configuration Wizard after Setup finishes.

    From the SharePoint 2010 Management Shell, use the New-SPConfigurationDatabase command to create a new configuration database, for example:

    Copy Code
    New-SPConfigurationDatabase -DatabaseName "SharePointConfigDB1" -DatabaseServer "SQL-01" -Passphrase (ConvertTo-SecureString "MyPassword" -AsPlainText -force) -FarmCredentials (Get-Credential)

    For more information, see New-SPConfigurationDatabase.

  4. [Setup] After the command has finished, run the SharePoint Products Configuration Wizard and complete the rest of the configuration for the server. This creates the Central Administration Web application and performs other setup and configuration tasks.

  5. [DBA] After the SharePoint Products Configuration Wizard has finished, perform the following actions for both the configuration database and the Central Administration content database:

    • Add the SharePoint Foundation search account, default content access account, and the services account to the Users group.

    • Add the SharePoint Foundation search service account, default content access account, and the services account to the WSS_Content_Application_Pools role.

  6. [Setup] To confirm that the databases were created and configured correctly, verify that the home page of the Central Administration Web site can be accessed. However, do not configure anything by using Central Administration at this point. If the Central Administration page does not render, verify the accounts that are used in this procedure and ensure that they are properly assigned.

The rest of the farm servers will be configured after the procedures in the article are finished and the farm is established. You will run the SharePoint Products Configuration Wizard on these servers by selecting the Yes, I want to connect to an existing server farm option, instead of by using the commands that are used in this procedure.

The following procedure will only have to be performed once for the farm. The farm has only one SharePoint Foundation search database.

Create and configure the SharePoint Foundation search database and start the search service

  1. [DBA] Create the SharePoint Foundation search database using the LATIN1_General_CI_AS_KS_WS collation sequence and set the database owner (dbo) to be the Setup user account.

  2. [Setup] Open the command line, and then use the Get-SPSearchService, Set-SPSearchService, Get-SPSearchServiceInstance, and Set-SPSearchServiceInstance cmdlets to configure the database and start the search service. Use the following example as a guide.

    Copy Code
    $searchService = Get-SPSearchService
Set-SPSearchService -MaxBackupDuration 120
Get-SPSearchServiceInstance -Local
Get-SPSearchServiceInstance -Local | Set-SPSearchServiceInstance -ProxyType proxy

    For more information, see the following topics:

    • Get-SPSearchService

    • Set-SPSearchService

    • Get-SPSearchServiceInstance

    • Set-SPSearchServiceInstance

Create and configure additional databases

After you finish configuring the databases required for Central administration, complete your farm deployment by creating and configuring the databases that are required for Web content and any service applications that you want to use.

The following procedure will have to be performed once for each portal site in the farm.

Create and configure the portal site Web application and content database

  1. [DBA] Create the portal site Web application content database using the LATIN1_General_CI_AS_KS_WS collation sequence and set the database owner (dbo) to be the Setup user account.

  2. [DBA] Using Microsoft SQL ServerManagement Studio, add the application pool process account to the Users group and the db_owner role for the Web application content database.

  3. [Setup] Open the command line, and then run the New-SPWebApplication and Get-SPWebApplication cmdlets to configure the portal site Web application content database. Use the following example as a guide.

    Copy Code
    New-SPWebApplication -Name "Contoso Internet Site" -Port 80 -URL "https://www.contoso.com" -ApplicationPool "ContosoAppPool" -ApplicationPoolAccount (Get-SPManagedAccount "DOMAIN\jdoe")
Get-SPWebApplication http://sitename | New-SPWebApplicationExtension -Name "ExtranetSite" -SecureSocketsLayer -Zone "Extranet"

    For more information, see New-SPWebApplication and Get-SPWebApplication.

    Important:

    The Get-SPWebApplication cmdlet must be run on the computer that is running the Web application. The host name and port combination must not describe a Web application that already exists or an error results and the Web application is not created.

Use the following procedure to create and configure the portal site Web application and its content database.

To create and configure the portal site Web application

  1. [DBA] Create the portal site Web application content database using the LATIN1_General_CI_AS_KS_WS collation sequence and set the database owner (dbo) to be the Setup user account.

  2. [DBA] Using SQL ServerManagement Studio, add the service application service account to the Users group and then to the db_owner role for the portal site Web application content database.

  3. [Setup] From the SharePoint 2010 Management Shell, use the New-SPWebApplication and Get-SPWebApplication cmdlets to configure the portal site Web application content database. Use the following example as a guide.

    Copy Code
    New-SPWebApplication -Name "Contoso Internet Site" -Port 80 -HostHeader "http://sharepoint.contoso.com" -URL "https://www.contoso.com" -ApplicationPool "ContosoAppPool" -ApplicationPoolAccount (Get-SPManagedAccount "DOMAIN\jdoe")
Get-SPWebApplication http://somesite | Set-SPWebApplication -Zone "Extranet" -HostHeader "http://www.contoso.com" - AllowAnonymousAccess

    For more information, see New-SPWebApplication and Get-SPWebApplication.

    Important:

    This command must be run on the same computer that is running the Web application. The host name and port combination must not describe a Web application that already exists or an error results and the Web application is not created.

  4. [Setup] From a command prompt, run the following command to restart IIS: iisreset /noforce


Deploy in a virtual environment (SharePoint Foundation 2010)
See Also

This section contains articles that provide guidance for configuring virtual machines for Microsoft SharePoint Foundation 2010 servers in a virtual environment.

In this section:

  • Virtual machine guidance (SharePoint Foundation 2010)

See Also

Other Resources

Resource Center: Virtualization for SharePoint Foundation 2010


Virtual machine guidance (SharePoint Foundation 2010)
See Also

This article provides guidance for configuring a virtual machine (VM) that uses Windows Server 2008 Hyper-V technology and that is used in a Microsoft SharePoint Foundation 2010 farm. This includes farm servers on the Web server tier, application server tier, and database server tier. Before you configure a virtual machine for a SharePoint farm, we recommend that you read the Hyper-V Getting Started Guide (http://go.microsoft.com/fwlink/p/?LinkId=187754). Because every configuration decision you make for a virtual machine or its infrastructure has an impact on performance or functionality (SharePoint Foundation 2010 and Hyper-V)—understanding each configuration option is important.

In a Hyper-V environment, you have the option of specifying the configuration of virtual networking and the configuration for each virtual machine. Additionally, you can configure how the VM interacts with the virtualization host, as well as VM stop and restart behavior if the running state of the virtual machine is interrupted.

In this article:

  • Networking

  • Network adapters

  • Virtual machine configuration

  • Integration services

  • Using snapshots

Networking

You can configure Hyper-V networking before you create any virtual machines or after you create one or more VMs. You can also create more than one virtual network for a Hyper-V host.

Using Virtual Network Manager (accessed from Hyper-V Manager), you have three different types of virtual networks to choose from. The following table provides a summary of the network types and their characteristics.

Type | Description
External | Use this type when you want to allow VMs to communicate with externally located servers and the management operating system (sometimes referred to as the parent partition). This type also allows VMs on the same physical server to communicate with each other.
Internal | Use this type when you want to allow communication between VMs on the same physical server and VMs and the management operating system. An internal virtual network is a virtual network that is not bound to a physical network adapter. It is commonly used to build a test environment where you need to connect to the VMs from the management operating system.
Private | Use this type when you want to allow communication only between VMs on the same physical server. A private virtual network is a virtual network without a virtual network adapter in the management operating system. Private virtual networks are commonly used when you want to isolate VMs from network traffic in the management operating system and in the external networks.

Use SharePoint Foundation farm requirements to determine which of the three networking configurations that you want to use on a virtualization host. For example, in the Quick start: Deploy single server in an isolated Hyper-V environment (SharePoint Foundation 2010) article, we used an Internal network to isolate the test environment from a production environment.

After determining the type of network that you want to use, you can specify the range of media access control (MAC) addresses that are automatically assigned to virtual adapters. The R2 release of Microsoft Hyper-V Server 2008 enables you to provide static MAC addresses to an adapter in order to avoid collisions on a network.

From a networking performance perspective, the ability to create virtual local area networks (VLANs) can provide performance gains. Virtual machines on the same VLAN can communicate through the virtual switch, which means that network traffic is faster because it does not have to use the physical network adapter. Another benefit of a VLAN configuration is the fact that is software-based, computers can easily be moved and still maintain their network configurations.

The following links provide more information about virtual networking concepts and how to configure virtual networks.

  • How does basic networking work in Hyper-V? (http://go.microsoft.com/fwlink/p/?LinkId=128228)

  • Hyper-V: What are the uses for different types of virtual networks? (http://go.microsoft.com/fwlink/p/?LinkId=128085)

  • Understanding Hyper-V VLANs (http://go.microsoft.com/fwlink/p/?LinkId=180709)

  • Hyper-V VLANs Part II (http://go.microsoft.com/fwlink/p/?LinkId=18775)

  • Configuring Virtual Networks (http://go.microsoft.com/fwlink/p/?LinkId=158767)

Network adapters

Two types of network adapters can be attached to a virtual machine: a network adapter and a legacy adapter. A network adapter provides better performance than the legacy network adapter. The legacy adapter emulates an Intel 21140-based PCI Fast Ethernet Adapter, which results in a lower data transfer than the network adapter. A legacy network adapter also supports network-based installations because it includes the ability to boot to the Pre-Boot Execution Environment (PXE).

Unless you need to use a legacy adapter until you can install the virtual machine driver, or need to do a network boot, we recommend that you configure the VM with a network adapter.

Note:

You can use the legacy adapter initially to do a network boot, and when that is no longer required, add a network adapter and delete the legacy adapter.

As is the case with physical servers, you can install multiple adapters on a virtual machine.

Virtual machine configuration

Hyper-V provides numerous options for configuring a virtual machine. These options can be changed after you have started the virtual machine and installed Microsoft SharePoint Foundation. You will have to shut the virtual machine down in order to the change the configuration. Configure the following for each virtual machine:

  • The boot sequence (legacy network adapter, CD, IDE, or floppy disk)

  • The amount of memory

  • The number of virtual processors, up to a limit of four

  • The type and number of controllers

  • The type and number of disks

  • The type and number of network adapters

In addition to the preceding configurations, you also have the option to configure COM ports and to configure a virtual floppy disk.

From a SharePoint Foundation perspective, the primary configuration considerations are memory, processor, and the type and number of controllers and hard disks.

Memory

After factoring in a 2 GB RAM reserve for the virtualization host, you can configure a virtual machine to have any amount of the remaining memory. You will, of course have to take into account the amount of memory that you provide to other virtual machines running on the same virtualization host.

Note:

The 2 GB of RAM reserved for the virtualization host is used as a guide and not a required or enforced amount of memory. Typically the actual amount of RAM committed to the physical server is less.

The actual memory overhead on Hyper-V is fairly small. This is well-illustrated if you download the Hyper-V RAM Calculator.xls (http://go.microsoft.com/fwlink/p/?LinkId=187756) and use it to calculate RAM use on a host of a given size with a several virtual machines.

Processor

You can configure multiple virtual processors for a virtual machine, up to a limit of four processors. You cannot configure more processors per VM that there are logical (cores) processors on the virtualization host. For example, given a dual core physical server, you are limited to configuring two virtual processors for a VM. Although Hyper-V supports up to eight virtual processors per core, a configuration that uses this ratio (1 logical: 8 virtual) is referred to as being oversubscribed. For any virtual machine used in a SharePoint farm, we recommend a ratio of 1:1. Oversubscribing the CPU on the virtualization host will work, but performance will degrade depending on the amount of oversubscription.

Controller and hard disk

You can select either integrated device electronics (IDE) or SCSI devices on virtual machines, as follows:

  • IDE devices: Hyper-V uses emulated devices with IDE controllers. You can have up to two IDE controllers with two disks on each controller. The startup disk (sometimes referred to as the boot disk) must be attached to one of the IDE devices. The startup disk can be either a virtual hard disk or a physical disk. Although a virtual machine must use an IDE device as the startup disk to start the guest operating system, you have many options to choose from when selecting the physical device that will provide the storage for the IDE device.

  • SCSI devices: Each virtual machine supports up to 256 SCSI disks (four SCSI controllers with each controller supporting up to 64 disks). SCSI controllers use a type of device developed specifically for use with virtual machines and use the virtual machine bus to communicate. The virtual machine bus must be available when the guest operating system is started. Therefore, virtual hard disks attached to SCSI controllers cannot be used as startup disks.

    Note:

    Although the I/O performance of physical SCSI and IDE devices can differ significantly, this is not true for the virtualized SCSI and IDE devices in Hyper-V. IDE and SCSI devices both offer equally fast I/O performance when integration services are installed in the guest operating system. Support for hot swappable hard drives, which is supported by the Hyper-V implementation of SCSI, is a better reason for selecting SCSI drives than performance gains.

The version of Hyper-V released with Windows Server 2008 R2 provides dramatic improvements in virtual hard disk performance. For more information, see Virtual Hard Disk Performance: Windows Server 2008 / Windows Server 2008 R2 / Windows 7 (http://go.microsoft.com/fwlink/p/?LinkId=186519). For a summary of virtual machine drive options, see the "How to choose your Hyper-V and VHD Storage Container Format" section of this white paper. Also, heed the authors' advice: When choosing the right VHD for your environment, consider both the access performance and storage needs. When using Windows Server 2008 R2, the choice has less to do with the access speed and more to do with the amount of memory used due to advanced caching.

Important:

There is not a generic storage solution for every virtual environment. Selecting the optimal virtual machine drive option for your SharePoint Foundation servers requires research and extensive testing to implement the best storage solution for your virtual environment.

Integration services

Hyper-V includes a software package for supported guest operating systems that improves integration between the physical computer and the virtual machine. This package is referred to as integration services. You should verify that the management operating system (which runs the Hyper-V role) and virtual machines are running the same version of integration services. For more information, see Version Compatibility for Integration Services (http://go.microsoft.com/fwlink/p/?LinkId=188011).

For each virtual machine you can configure the following integration items between the VM and the virtualization host:

  • Operating system shutdown

  • Time synchronization

  • Data exchange

  • Heartbeat

  • Backup (volume snapshot)

Important:

Disable the time synchronization for each SharePoint Foundation virtual machine. SharePoint Foundation 2010 implements timer jobs extensively and the latency during time synchronization will cause unpredictable results in the SharePoint Foundation environment.

Automatic stop and start

For each virtual machine you can configure automatic stop and start behavior if a physical machine shuts down. The options for stop are:

  • Save the virtual machine state. The current state of the virtual machine is saved and when the VM is started, Hyper-V attempts to restore the VM to the state it was in.

  • Turn off the virtual machine. This is the equivalent of pulling the power plug on a server.

  • Shut down the guest (virtual machine) operating system. This is the equivalent of shutting down the machine using the Windows Shut down option.

For a SharePoint Foundation virtual machine, do not configure the virtual machine to save state. Virtual machines that come up from saved state will be out of synchronization with the other servers in the farm. We recommend that you configure the virtual machine to use a shutdown because it provides the cleanest method to minimize virtual machine corruption. When a shutdown occurs any timer jobs that are running are allowed to finish and there will not be any synchronization issues when the VM restarts.

The opposite of an automatic stop is an automatic start. Hyper-V provides the following startup options when the physical server restarts:

  • Do nothing. You will have to start the VM manually regardless of its state when the physical server shut down.

  • Automatically start if the machine was running when the service stopped.

  • Always start this virtual machine automatically. Hyper-V will start the machine regardless of its state when the physical server shut down.

We recommend that you either of the first two options. Either option is valid, but the decision is ultimately up to the IT team that is managing and maintaining the virtual environment.

In addition to the preceding start options, you can configure a startup time delay for a virtual machine. We recommend that you do so in order to reduce resource contention on a virtualization host. However, if your start option is to do nothing, this is not an issue.

Using snapshots

Snapshots provide a very useful tool for capturing the current state of a running, paused, or stopped virtual machine. The snapshot feature enables you to quickly and easily revert to a previous virtual machine configuration. This capability is particularly well-suited to a development or test environment.

As a best practice, we recommend that you do not use the snapshot feature on virtual machines in a production environment for the following reasons:

  • Clock synchronization: When you take a snapshot of a running virtual machine, there is latency between the time the snapshot is started and the time the snapshot is finished. This latency affects SharePoint Foundation timer jobs and, as a result, time synchronization between farm servers.

    Important:

    If you choose to take a snapshot of a virtual machine, shut down the machine to allow running jobs to finish before taking the snapshot. We recommend that you closely monitor the virtual machine and other farm servers after the virtual machine is restarted to ensure that there are no time synchronization issues.

  • Performance: When you create a snapshot for a virtual machine you have, in effect, created a differencing disk. There is a continuous exchange of configuration data between the virtual machine and the snapshot, which affects performance.

See Also

Other Resources

Resource Center: Virtualization for SharePoint Foundation 2010


Install SharePoint Foundation 2010 by using Windows PowerShell

This article discusses how to do a clean installation of Microsoft SharePoint Foundation 2010 on a stand-alone server or on a server farm by using Windows PowerShell.

In this article:

  • Farm server requirements

  • Prepare SPModule

  • Install SharePoint Foundation 2010 by running Install-SharePoint

  • Configure the farm by using New-SharePointFarm

  • Create a Web Application by using Windows PowerShell

  • Deploy services by using the SharePoint 2010 Farm Configuration Wizard

  • Create a site collection by using Windows PowerShell

  • Perform additional configuration tasks

  • Add servers to the farm by using Join-SharePointFarm

  • Configure the trace log

You can streamline deployment by using Windows PowerShell to install Microsoft SharePoint Foundation 2010 in combination with other administrator tools to automate unattended installations and configure the farm.

Farm server requirements

Before you install SharePoint Foundation 2010, review the following information about permissions, hardware requirements, and software requirements and steps to perform before beginning the process:

  1. Ensure that you have met all hardware and software requirements. You must have a 64-bit version of Windows Server 2008 or Windows Server 2008 R2. For server farms, you must also have a 64-bit version of SQL Server 2005 or SQL Server 2008. For more information about these requirements (such as specific updates that you must install), see Determine hardware and software requirements (SharePoint Foundation 2010).

  2. Ensure that you are prepared to set up the required accounts by using appropriate permissions. For detailed information, see Administrative and service accounts required for initial deployment (SharePoint Foundation 2010).

Prepare SPModule

The SPModule.zip file is a Windows PowerShell module written by members of the SharePoint Product Group that will install a SharePoint farm.

To use the SPModule.zip file, follow the steps below:

  1. Download the SPModule.zip and text file from the following Download Center page (http://go.microsoft.com/fwlink/p/?LinkId=187924).

  2. Extract the files to a folder named SPModule and then add that folder to your environment path. The PSModulePath environment variable is used to store paths to the locations of the modules that are installed on disk. To view paths specified in the PSModulePath variable, from a Windows PowerShell command prompt, type $env:PSModulePath. For more information, see PSModule Environment Variable (http://go.microsoft.com/fwlink/p/?LinkId=187757). After extraction, the SPModule folder should contain two files: SPModule.misc and SPModule.setup.

    Note:

    If the SPModule folder is not added to the PSModulePath variable, you must specify a full path to load the SPModule.

  3. Decide on the type of signing to provide.

    Note:

    The downloaded files are unsigned. To provide self-signed scripts, see AllSigned: Signing Your PowerShell Scripts (http://go.microsoft.com/fwlink/p/?LinkId=187758).

    By default, Windows PowerShell execution policy is set to Restricted so that no scripts can be run. To change an execution policy, run the Set-ExecutionPolicy cmdlet. For additional information about execution polices, see About_Signing (http://go.microsoft.com/fwlink/p/?LinkId=187759).

  4. Load the SPModule.misc and SPModule.setup files into Windows PowerShell.

    1. Click Start, point to All Programs, and then click Windows PowerShell V2. After the Windows PowerShell Command Prompt window opens, the first thing we need to do is add the path to the module to your Windows PowerShell module path (presuming you created a folder called "SPModule" on your server):

    2. Right-click Windows PowerShell V2, and then click Run as administrator.

      Note:

      If you already have Microsoft SharePoint Foundation 2010 installed, you could open the SharePoint 2010 Management Shell instead.

    3. After the Command Prompt window is displayed, we need to import the module into the current Windows PowerShell session and add it to a path by typing the following syntax from a Windows PowerShell command prompt:

      Copy Code
      Import-Module SPModule.misc
      Copy Code
      Import-Module SPModule.setup

When you import the SPModule.misc module, you will invoke an update check. In version 1.0, this will check a text file to see if there is a newer version available. If you are notified that there is, you can go and download the newer version. After the Import-Module commands have been completed successfully, you are ready to use SPModule.

Important:

The following commands should only be used in the context of the SPModule and the process in this article:

  1. Install-SharePoint: Installs all of the binary files for SharePoint Foundation 2010. For more information, see, Scripted deployment reference (SharePoint Foundation 2010)

  2. New-SharePointFarm: Creates a SharePoint farm and performs the following related tasks:

    • Configures security

    • Creates a shared service Web application that you can populate with service applications.

    • Creates and configures the Central Administration Web site.

    • Installs all of the product Help files.

    • Installs all farm features.

  3. Join-SharePointFarm: Adds servers to the farm, and then configures them. . For more information, see Scripted deployment reference (SharePoint Foundation 2010)

After Windows PowerShell version 2.0 is installed, you can use a new feature of Windows PowerShell called Remoting. By using the remoting feature and a couple lines of Windows PowerShell code, an administrator can remotely install multiple servers in a farm. For information about Remoting and SPModule, see Remote Install with SPModule (http://go.microsoft.com/fwlink/p/?LinkId=187923).

Install SharePoint Foundation 2010 by running Install-SharePoint

After you have determined the required accounts for the installation, you can install SharePoint Foundation 2010. The product DVD contains examples of configuration (Config.xml) files. These example files are stored under the \Files folder in the root directory of the DVD, in folders that correspond to different scenarios. These example files are described in the following table.

Configuration file | Description
Setup\Config.xml | Stand-alone server installation, using Microsoft SQL Server 2005 Express Edition
SetupFarm\Config.xml | Server farm installation
SetupFarmSilent\Config.xml | Server farm installation in silent mode
SetupFarmUpgrade\Config.xml | In-place upgrade of an existing farm
SetupSilent\Config.xml | Stand-alone server installation, using SQL Server 2005 Express Edition, in silent mode
SetupSingleUpgrade\Config.xml | In-place upgrade of an existing single-server installation

To run Install-SharePoint with a Config.xml file at a Windows PowerShell command prompt

  1. On the drive on which the SharePoint Foundation 2010 product DVD is located, change to the root directory to locate the setup.exe file.

  2. Run SPModule.Setup Install-SharePoint with the selected Config.xml file, as follows:

    Install-SharePoint -SetupExePath<path and file name>-ConfigXml<path and file name>

    Note:

    You can select one of the example files, or customize your own configuration file.

  3. Press ENTER.

Setup is now finished.

The following example shows the configuration file for setting up a single server in silent mode (SetupSilent).

Copy Code
<Configuration><Package Id="sts">  <Setting Id="LAUNCHEDFROMSETUPSTS" Value="Yes" />  </Package><Package Id="spswfe">  <Setting Id="SETUPCALLED" Value="1" />  </Package>  <Logging Type="verbose" Path="%temp%" Template="SharePoint Server Setup(*).log" />- <!--<PIDKEY Value="Enter Product Key Here" />  -->  <Display Level="none" CompletionNotice="no" />  <Setting Id="SERVERROLE" Value="APPLICATION" />  <Setting Id="USINGUIINSTALLMODE" Value="0" />  <Setting Id="SETUP_REBOOT" Value="Never" />  <Setting Id="SETUPTYPE" Value="CLEAN_INSTALL" />  </Configuration>

You can also customize your own configuration file. To control the installation, first edit the Config.xml file in a text editor to include the elements that you want with the appropriate settings for those elements. Next, run Install-SharePoint -SetupExePath -ConfigXML to specify that Setup runs and uses the options that you set in the Config.xml file.

Some typical configuration options include the following:

  • Bypassing the prompt for the product key by providing the key as a value, <PIDKEY Value="Enter PID Key Here" />, in the Config.xml file.

  • Adding a location for a log file, <Logging Type="off" | "standard"(default) | "verbose" Path="path" Template="file name.log"/>, which you can view if command-line installation fails.

Important:

Use a text editor, such as Notepad, to edit Config.xml. Do not use a general-purpose XML editor, such as Microsoft Office Word 2007. To validate that your XML file is well-formed, use any supported browser.

Run Install-SharePoint by using a PID key

To run Setup in silent mode without using a configuration XML file, type one of the following commands at a Windows PowerShell command prompt:

  • For stand-alone server: Install-SharePoint -SetupExePath "<drive letter>:\SharePoint 2010\Setup\setup.exe" -ServerRole "SINGLESERVER"

  • For a farm deployment: Install-SharePoint -SetupExePath "<drive letter>:\SharePoint 2010\Setup\setup.exe"

To run Setup in silent mode using a configuration XML file, type one of the following commands at a Windows PowerShell command prompt:

  • For a stand-alone server: Install-SharePoint -SetupExePath "G:\SharePoint 2010\Setup\setup.exe" -ConfigXML "G:\SharePoint 2010\Setup\Config\singleserver_config.xml" -ServerRole "SINGLESERVER"

  • For a farm deployment: Install-SharePoint -SetupExePath "G:\SharePoint 2010\Setup\setup.exe" -ConfigXML "G:\SharePoint 2010\Setup\Config\appserver_config.xml"

Note:

For Microsoft SharePoint Foundation 2010, the PIDKey parameter does not need to be specified.

Configure the farm by using New-SharePointFarm

You use the New-SharePointFarm command to configure SharePoint Foundation 2010 after the Install-SharePoint command has finished. The configuration options are different depending on whether you install SharePoint Foundation 2010 on a stand-alone server or on a server farm.

Configure SharePoint Foundation 2010 on a stand-alone server

In stand-alone server deployments, you can run New-SharePointFarm. After you have logged on by using the Setup user account that you previously created and configured, you configure SharePoint Foundation 2010.

To configure SharePoint Foundation 2010 on a stand-alone server by using New-SharePointFarm

  • At the Windows PowerShell command prompt, type the following command:

    Copy Code
    New-SharePointFarm -DatabaseServer <String> -DatabaseAccessAccount <(Get-Credential domain\account)> -FarmName <string>

    Where:

    • <String> is the name of the database server. For example, "SQL01"

    • <PSCredential> is the DOMAIN\password of the user account that is performing the installation.

    • <String> is the name of the farm. For example, "Farm1"

The New-SharePointFarm command describes the configuration steps as they occur, and notes the successful completion of configuration. For a stand-alone server installation, this is the final step in a command-line installation.

We strongly recommend that you install and configure SharePoint Foundation 2010 on all of the farm servers before you create sites.

Caution:

Do not run the New-SharePointFarm and Join-SharePointFarm commands simultaneously on multiple computers because contention issues and unpredictable behavior can occur.

Note:

If any of these commands fail, look in the post-setup configuration log files. The log files are available at %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\14\Logs, and can be identified by a file name that begins with PowerShell_ConfigurationDiagnostics and the .log file name extension.

Note:

The Windows PowerShell cmdlets mentioned in this section must be run from the SharePoint 2010 Management Shell.

To connect to an existing configuration database and join the server to an existing server farm, the Connect-SPConfigurationDatabase cmdlet must be run along with the following Windows PowerShell cmdlets, in this order:

  • Install-SPHelpCollection

  • Initialize-SPResourceSecurity

  • Install-SPService

  • Install-SPFeature -AllExistingFeatures

  • Install-SPApplicationContent

Create a Web Application by using Windows PowerShell

Use the New-SPWebApplication cmdlet to create the Web application and a new content database.

To create a Web application

  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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    New-SPWebApplication -ApplicationPool <String> -Name
<InternetSite>
 -ApplicationPoolAccount (Get-SPManagedAccount
<DOMAIN\UserName>

    Where:

    • <String> is the name of the application pool. For example, "SharePoint -80".

    • <InternetSite> is name of the Web application.

    • Domain\UserName is the name of the application pool account.

For more information, see New-SPWebApplication.

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.

Deploy services by using the SharePoint 2010 Farm Configuration Wizard

Use the SharePoint Products Configuration Wizard to deploy services on your installation. For information about services and service applications, see Service application and service management (SharePoint Foundation 2010).

Create a site collection by using Windows PowerShell

You create the top-level site collection by using the New-SPSite cmdlet. The New-SPSite cmdlets creates a site collection at a specific URL with a specified user as a site owner.

To create a site collection

  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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    New-SPSite
<SiteURL>
 -OwnerAlias
<DOMAIN\UserName>

    Where:

    • <SiteURL> is the URL of the new site.

    • <DOMAIN\UserName> is the user login name of the site owner.

For more information, see New-SPSite.

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.

If you do not specify the site template to use, site owners can choose the site template when they first browse to the site. You can use the Get-SPWebTemplate cmdlet to display a list of templates.

For a complete list of common templates in SharePoint Foundation 2010, see Scripted deployment reference (SharePoint Foundation 2010)

If you want to create additional site collections by using Windows PowerShell, you can use the New-SPSite cmdlet.

Note:

If you want to create a new content database with the new site, use the New-SPContentDatabase cmdlet or the New-SPSite with the ContentDatabase parameter.

After creating sites, you might want to configure alternate access mappings. Alternate access mappings direct users to the correct URLs during their interaction with SharePoint Foundation 2010 (while browsing to the home page of a SharePoint site, for example). Alternate access mappings enable SharePoint Foundation 2010 to map Web requests to the correct Web applications and sites, and they enable SharePoint Foundation 2010 to serve the correct content back to the user. For more information, see Set-SPAlternateUrl.

Perform additional configuration tasks

After you have installedSharePoint Foundation 2010, we recommend that you perform the following administrative tasks:

  • Configure outgoing e-mail settings.

  • Configure workflow settings.

  • Configure diagnostic logging settings.

  • Configure antivirus settings.

Add servers to the farm by using Join-SharePointFarm

You must run the Join-SharePointFarm command on all servers you want to add to the farm. To connect to an existing configuration database and join the server to an existing server farm, type the following command on the server (after installing SharePoint Foundation 2010):

Copy Code
Join-SharePointFarm -DatabaseServer
<String>
 -ConfigurationDatabaseName
<String>
 -Passphrase
<SecureString>

Where:

  • <String> is the name of the database server, for example, SQL01.

  • <SecureString> is the password of the user account in the form DOMAIN\password.

Configure the trace log

The trace log can be useful for analyzing problems that might occur. You can use events that are written to the trace log to determine what configuration changes were made in SharePoint Foundation 2010 before the problem occurred.

By default, SharePoint Foundation 2010 saves 14 days of events in the trace log files. This means that trace log files that contain events that are older than 14 days are deleted. You can use the Set-SPLogLevel cmdlet to configure all diagnostic logging.

You can use the Diagnostic Logging page in Central Administration to configure the maximum number of trace log files to maintain, and how long (in minutes) to capture events to each log file.

You can also specify where the log files are written or accept the default path by using the Set-SPLogLevel cmdlet.

Trace log files can help you troubleshoot issues related to configuration changes to the Microsoft SharePoint Foundation Search service. Because problems related to configuration changes are not always immediately discovered, we recommend that you save all trace log files that the system creates on any day that you make any configuration changes. Store these log files for some time in a safe location that will not be overwritten. We recommend that you store log files on a hard disk drive partition that is used to store log files only.

For additional information about diagnostic logging, see Configure diagnostic logging (SharePoint Foundation 2010)


Initial configuration (SharePoint Foundation 2010)

After the installation of Microsoft SharePoint Foundation 2010, you must perform an initial configuration. If you are using different languages in the server farm, ensure that you install the correct language packs on your Web servers. Next, you can start to configure server farm settings. The configuration of additional settings is optional, but many key features are not available unless these settings are configured. When you have created a Web application and configured the services that you want to use for this Web application, you can start to create site collections.

The articles in this section help you perform the initial configuration of SharePoint Foundation 2010.

  • Deploy language packs (SharePoint Foundation 2010)

    Language packs enable site owners and site collection administrators to create SharePoint sites and site collections in multiple languages without requiring separate installations of SharePoint Foundation 2010. This article describes how you install language packs on Web servers.

  • Configure farm settings (SharePoint Foundation 2010)

    This article describes how to configure additional settings in the server farm, for example outgoing and incoming e-mail, mobile account, and diagnostic logging.

  • Configure services (SharePoint Foundation 2010)

    Individual services can be configured independently, and you can implement only the services that your organization needs. Services that are deployed are named service applications. A service application provides a resource that can be shared across sites within a farm or sometimes across multiple farms, and can be accessed by users through a hosting Web application. This article covers how to start, stop, and configure services, and how to manage and publish service applications.

  • Prepare to host sites (SharePoint Foundation 2010)

    After you have installed SharePoint Foundation 2010 and performed the initial configuration, you can begin to create SharePoint sites. This article describes how you create a Web application and a site collection which are the basis for creating SharePoint sites.


Deploy language packs (SharePoint Foundation 2010)
See Also

Published: May 16, 2012

In this article:

  • About language IDs and language packs

  • Downloading language packs

  • Installing language packs on the web and application servers

  • Uninstalling language packs

Language packs enable site owners and site collection administrators to create SharePoint sites and site collections in multiple languages without requiring separate installations of Microsoft SharePoint Foundation 2010. You install language packs, which contain language-specific site templates, on web and application servers. When an administrator creates a site or a site collection that is based on a language-specific site template, the text that appears on the site or the site collection is displayed in the site template's language. Language packs are typically used in multinational deployments where a single server farm supports people in different locations, or when sites and web pages must be duplicated in one or more languages.

Note:

You cannot change an existing site, site collection, or web page from one language to another by applying different language-specific site templates. After you use a language-specific site template for a site or a site collection, the site or site collection will always display content in the language of the original site template.

Word breakers and stemmers enable you to efficiently and effectively search across content on SharePoint sites and site collections in multiple languages without requiring separate installations of SharePoint Foundation 2010. Word breakers and stemmers are automatically installed on web servers by Setup.

Important:

If you are uninstalling SharePoint Foundation 2010, you must uninstall all language packs before you uninstall SharePoint Foundation 2010.

About language IDs and language packs

When site owners or site collection administrators create sites or site collections, they can select a language for each site or site collection.

The language that they select has a language identifier (ID). The language ID determines the language that is used to display and interpret text that is put on the site or site collection. For example, when a site owner creates a site in French, the site's toolbars, navigation bars, lists, and column headings appear in French. Similarly, if a site owner creates a site in Arabic, the site's toolbars, navigation bars, lists, and column headings appear in Arabic. In addition, the default left-to-right orientation of the site changes to a right-to-left orientation to correctly display Arabic text.

The list of available languages that people can use to create a site or site collection is generated by the language packs that are installed on the web and application servers. By default, sites and site collections are created in the language in which SharePoint Foundation 2010 was installed. For example, if you install the Spanish version of SharePoint Foundation 2010, the default language for sites, site collections, and web pages is Spanish. If someone has to create sites, site collections, or web pages in a language other than the default SharePoint Foundation 2010 language, you must install the language pack for that language on the web and application servers. For example, if you are running the French version of SharePoint Foundation 2010, and a site owner wants to create sites in French, English, and Spanish, you must install the English and Spanish language packs on the web and application servers.

Note:

By default, when a site owner creates a new web page in a site, the site displays text in the language that is specified by the language ID.

Language packs are not bundled into multilingual installation packages. You must install a specific language pack for each language that you want to support. Also, language packs must be installed on each web and application server to ensure that each web and application server can display content in the specified language.

Important:

You cannot change an existing site, site collection, or web page from one language to another by applying different language-specific site templates. After you use a language-specific site template for a site or a site collection, the site or site collection will always display content in the language of the original site template.

For a list of all the language packs available, see Language packs (SharePoint Foundation 2010)

Although a site owner specifies a language ID for a site, some user interface elements such as error messages, notifications, and dialog boxes do not display in the language that was specified. This is because SharePoint Foundation 2010 relies on several supporting technologies — for example, the Microsoft .NET Framework, Microsoft Windows Workflow Foundation, Microsoft ASP.NET, and Microsoft SQL Server 2005 — some of which are localized into only a limited number of languages. If a user interface element is generated by any of the supporting technologies that is not localized into the language that the site owner specified for the site, the user interface element appears in English. For example, if a site owner creates a site in Hebrew, and the .NET Framework component displays a notification message, the notification message will not display in Hebrew because the .NET Framework is not localized into Hebrew. This situation can occur when sites are created in any language except the following: Chinese, French, German, Italian, Japanese, Korean, and Spanish.

Important:

Each language pack that you install creates a folder at %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14\LAYOUTS\Locale_ID that contains culture-specific data. In each locale_ID folder, you must have only one HTML error file that contains the error information that is used when a file cannot be found. Anytime a file cannot be found for any site in that culture, this file will be used. You can specify which file to use by setting the SPWebApplication.FileNotFoundPage property for each web application. For more information see, SPWebApplication.FileNotFoundPage Property. (http://go.microsoft.com/fwlink/p/?LinkId=169319)

In some cases, some text might originate from the original installation language, which can create a mixed-language experience. This kind of mixed-language experience is typically seen only by content creators or site owners and is not seen by site users.

Downloading language packs

You must follow these steps for each language that you want to support. If you decide to download more than one language, please be aware that a unique file that has a common name is downloaded for each language. Therefore, make sure that you download each language pack to a separate folder on the hard disk so that you do not overwrite a language pack of a different language.

Important:

By default, the Windows PowerShell 2.0 Help files are installed in English (en-us). To view these files in the same language as the operating system, you must install the language pack for the same language that the operating system was installed in.

You can download language packs at 2010 Server Language Packs for SharePoint Server 2010, Project Server 2010, Search Server 2010, and Office Web Apps 2010 Language Packs for SharePoint Foundation 2010.

Important:

If you are upgrading from an earlier version of Microsoft SharePoint Foundation and you are using the Group Approval (eApproval) features, you must install all the following language packs before you run the SharePoint Products Configuration Wizard:

  • Chinese (Simplified) - 2025

  • Chinese (Traditional) - 1028

  • Japanese - 1041

  • Korean - 1042

After installing the language packs, run the following command in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14 folder:

psconfig.exe -cmd upgrade -inplace v2v

Download the language pack

  1. Download the 64-bit version of the language pack by using one of the download links.

  2. On the download page, select the language that you want from the Change Language list, and then click Change.

  3. Click Download on the web page.

  4. In the dialog box that appears, click Save to download a copy of the file to the local computer.

Note:

If you are uninstalling SharePoint Foundation 2010, you must uninstall all language packs before you uninstall SharePoint Foundation 2010.

Installing language packs on the web and application servers

After you install the necessary language files on the web and application servers, you can install the language packs. Language packs are available as individual downloads (one download for each supported language). If you have a server farm environment and you are installing language packs to support multiple languages, you must install the language packs on each of the web and application servers.

Important:

The language pack is installed in its native language. For example, the Russian language pack executable file is in Russian. The procedure that follows is for the English language pack.

Install a language pack

  1. Run setup.exe.

  2. On the Read the Microsoft Software License Terms page, review the terms, select the I accept the terms of this agreement check box, and then click Continue.

  3. The Setup wizard runs and installs the language pack.

  4. Rerun the SharePoint Products Configuration Wizard by using the default settings. If you do not run the SharePoint Products Configuration Wizard after you install a language pack, the language pack will not be installed correctly.

Rerun the SharePoint 2010 Products Configuration Wizard

  1. Click Start, point to All Programs, click Microsoft SharePoint 2010 Products, and then click SharePoint 2010 Products Configuration Wizard.

  2. On the Welcome to SharePoint Products page, click Next.

  3. Click Yes in the dialog box that alerts you that some services might have to be restarted during configuration.

  4. On the Modify Server Farm Settings page, click Do not disconnect from this server farm, and then click Next.

  5. If the Modify SharePoint Central Administration Web Administration Settings page appears, do not change any of the default settings, and then click Next.

  6. On the Completing the SharePoint Products and Technologies Configuration Wizard page, click Next.

  7. On the Configuration Successful page, click Finish.

When you install language packs, the language-specific site templates are installed in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LanguageID directory, where LanguageID is the Language ID number for the language that you are installing. For example, the United States English language pack installs to the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14\TEMPLATE\1033 directory. After you install a language pack, site owners and site collection administrators can create sites and site collections based on the language-specific site templates by specifying a language when they are creating a new SharePoint site or site collection.

Important:

After you install a new language pack, you must deactivate and then reactivate any language-specific features before you use the new language pack.

Uninstalling language packs

If you no longer have to support a language for which you have installed a language pack, you can remove the language pack by using the Control Panel. Removing a language pack removes the language-specific site templates from the computer. All sites that were created that have those language-specific site templates will no longer work (the URL will produce a HTTP 500 - Internal server error page). Reinstalling the language pack will make the site functional.

Note:

You cannot remove the language pack for the version of SharePoint Foundation 2010 that you have installed on the server. For example, if you are running the Japanese version of SharePoint Foundation 2010, you cannot uninstall the Japanese language support for SharePoint Foundation 2010.

See Also

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010


Configure farm settings (SharePoint Foundation 2010)

After the initial installation of Microsoft SharePoint Foundation 2010, you can configure several additional settings. Some of these settings include configuring usage and health data collection to ensure that you collect relevant data to analyze, configuring several diagnostic logging settings to help with troubleshooting, and configuring a mobile account so that users can receive alerts by means of Short Message Service (SMS) when changes have been made in a SharePoint list or item. The configuration of additional settings is optional, but many key features are not available unless these settings are configured.

The articles in this section describe how you configure the server farm.

  • Configure usage and health data collection (SharePoint Foundation 2010)

    This article describes how to configure usage and health data collection in SharePoint Foundation 2010.

  • Configure diagnostic logging (SharePoint Foundation 2010)

    This article describes how to configure diagnostic logging that might be required after initial deployment or upgrade and possibly throughout the system's life cycle.

  • E-mail integration (SharePoint Foundation 2010)

    This article describes how to configure incoming and outgoing e-mail in the server farm.

  • Configure a mobile account (SharePoint Foundation 2010)

    This article discusses how to configure and manage a mobile account for SharePoint Foundation 2010 to enable users to subscribe to alerts that are sent by using Short Message Service (SMS).

  • Install and configure RBS (SharePoint Foundation 2010)

    This article describes how to install and configure Remote BLOB Storage (RBS) for a Microsoft SQL Server 2008 database server that supports a Microsoft SharePoint Foundation 2010 farm.


Configure usage and health data collection (SharePoint Foundation 2010)
See Also

This article provides information about configuring usage and health data collection in Microsoft SharePoint Foundation 2010.

The system writes usage and health data to the logging folder and to the logging database. To configure settings for the logging database, you must use Windows PowerShell.

In this article:

  • Configure usage and health data collection by using Central Administration

  • Configure usage data collection by using Windows PowerShell

  • To configure usage data collection for a specific event type by using Windows PowerShell

  • Log usage data in a different logging database by using Windows PowerShell

Note:

You cannot configure health data collection settings by using Windows PowerShell.

Configure usage and health data collection by using Central Administration

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.

    Note:

    The usage and health data settings are farm-wide and cannot be set for individual servers in the farm.

  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.

    Note:

    Logging uses system resources and can affect performance and disk usage. Only log those events for which you want regular reports. For ad hoc reports or investigations, enable logging for specific events, and then disable logging for the events after the report or investigation is complete.

  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.

    Note:

    These settings are applied to all events. To set event collection settings for individual event types, you must use Windows PowerShell.

  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.

    Note:

    To change the Database Server and Database Name values, you must use Windows PowerShell.

Configure usage data collection by using Windows PowerShell

Note:

You can configure usage data collection by using Windows PowerShell, but you cannot configure health data collection by using Windows PowerShell.

To configure usage data 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. 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.

For more information, see Set-SPUsageService.

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: See Add-SPShellAdmin.

  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.

For more information, see Set-SPUsageDefinition.

Log usage data in a different logging database by using Windows PowerShell

Note:

You can use only Windows PowerShell to change this setting.

To log usage data in a different logging database 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. 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.

For more information, see Set-SPUsageApplication.

See Also

Concepts

Monitoring overview (SharePoint Foundation 2010)

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010


Configure diagnostic logging (SharePoint Foundation 2010)
See Also

This article provides information about configuring diagnostic logging in Microsoft SharePoint Foundation 2010.

In this article:

  • Best practices

  • Configure diagnostic logging by using Central Administration

  • Configure diagnostic logging by using Windows PowerShell

Best practices

The SharePoint Foundation 2010 environment might require configuration of the diagnostic loggings settings after initial deployment or upgrade and possibly throughout the system's life cycle. The guidelines in the following list can help you form best practices for the specific environment.

  • Change the drive that logging writes to. By default, diagnostic logging is configured to write logs to the same drive and partition that SharePoint Foundation 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 Foundation 2010 was installed. You should also consider the connection speed to the drive that logs are written to. If verbose-level logging is configured, lots of log data is recorded. Therefore, a slow connection might result in poor log performance.

  • Restrict log disk space usage. By default, the amount of disk space that diagnostic logging can use is not limited. Therefore, limit the disk space that logging uses to make sure that the disk does not fill up, especially if you configure logging to write verbose-level events. When the disk restriction is used up, the oldest logs are removed and new logging data information is recorded.

  • Use the Verbose setting sparingly. You can configure diagnostic logging to record verbose-level events. This means that the system will log every action that SharePoint Foundation 2010 takes. Verbose-level logging can quickly use drive space and affect drive and server performance. You can use verbose-level logging to record a greater level of detail when you are making critical changes and then re-configure logging to record only higher-level events after you make the change.

  • Regularly back up logs. The diagnostic logs contain important data. Therefore, back them up regularly to make sure that this data is preserved. When you restrict log drive space usage, or if you keep logs for only a few days, log files are automatically deleted, starting with the oldest files first, when the threshold is met.

  • Enable event log flooding protection. Enabling this setting configures the system to detect repeating events in the Windows event log. When the same event is logged repeatedly, the repeating events are detected and suppressed until conditions return to a typical state.

You can set the level of diagnostic logging for the event log and for the trace log. This will limit the types and amount of information that will be written to each log. The following tables define the levels of logging available for the event log and trace log:

Event log levels

Level | Definition
None | No logging occurs.
Critical | This message type indicates a serious error that has caused a major failure in the solution.
Error | This message type indicates an urgent condition. All error events should be investigated.
Warning | This message type indicates a potential problem or issue that might require attention. Warning messages should be reviewed and tracked for patterns over time.
Information | Information messages do not require any action, but they can provide valuable data for monitoring the state of your solution.
Verbose | This event log level corresponds to lengthy events or messages.

Trace log levels

Level | Definition
None | No trace logs are written.
Unexpected | This level is used to log messages about events that cause solutions to stop processing. When set to log at this level, the log will only include events at this level.
Monitorable | This level is used to log messages about any unrecoverable events that limit the solution's functionality but do not stop the application. When set to log at this level, the log will also include critical errors (Unexpected level).
High | This level is used to log any events that are unexpected but which do not stall the processing of a solution. When set to log at this level, the log will include warnings, errors (Monitorable level) and critical errors (Unexpected level).
Medium | When set to this level, the trace log includes everything except Verbose messages. This level is used to log all high-level information about operations that were performed. At this level, there is enough detail logged to construct the data flow and sequence of operations. This level of logging could be used by administrators or support professionals to troubleshoot issues.
Verbose | When set to log at this level, the log includes messages at all other levels. Almost all actions that are performed are logged when you use this level. Verbose tracing produces many log messages. This level is typically used only for debugging in a development environment.

Configure diagnostic logging by using Central Administration

You can use Central Administration to configure diagnostic logging.

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:

    1. Select the All Categories check box.

    2. Select the event log level from the Least critical event to report to the event log list.

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

    1. Select the check boxes next to the categories that you want.

    2. Select the event log level from the Least critical event to report to the event log list.

    3. 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):

    1. Click (+) next to the category to expand the category.

    2. Select the check box next to the sub-category.

    3. Select the event log level from the Least critical event to report to the event log list.

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

    1. Select the All Categories check box.

    2. Select Reset to default from the Least critical event to report to the event log list.

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

Configure diagnostic logging by using Windows PowerShell

You can use Windows PowerShell to configure diagnostic logging.

To configure diagnostic logging 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. 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.

For more information, see Set-SPLogLevel.

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.

See Also

Concepts

Monitoring overview (SharePoint Foundation 2010)

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010


E-mail integration (SharePoint Foundation 2010)

After the initial installation of Microsoft SharePoint Foundation 2010, you can configure incoming and outgoing e-mail. These additional settings are optional, but might be useful if you want to work with e-mail in the server farm.

  • Configure incoming e-mail (SharePoint Foundation 2010)

    This article describes how to configure incoming e-mail so that SharePoint sites accept and archive incoming e-mail. It also describes how to configure incoming e-mail so that SharePoint sites can archive e-mail discussions as they happen, save e-mailed documents, and show e-mailed meetings on site calendars. In addition, this article describes how to configure the SharePoint Directory Management Service to provide support for e-mail distribution list creation and management.

  • Configure outgoing e-mail (SharePoint Foundation 2010)

    This article describes how to configure outgoing e-mail so that your Simple Mail Transfer Protocol (SMTP) server sends e-mail alerts to site users and notifications to site administrators.


Configure incoming e-mail (SharePoint Foundation 2010)
See Also

This article describes how to configure incoming e-mail for a server farm for Microsoft SharePoint Foundation 2010. This article also describes how to install and configure the SMTP service that you must use to enable incoming e-mail.

In this article:

  • Overview

  • Install and configure the SMTP service

  • Configure incoming e-mail in a basic scenario

  • Configure incoming e-mail in an advanced scenario

  • Prepare your environment for incoming e-mail in an advanced scenario

  • Are attachments missing from e-mail messages that are sent to a SharePoint document library?

Overview

When incoming e-mail is enabled, SharePoint sites can receive and store e-mail messages and attachments in lists and libraries. This article describes two scenarios, one basic and one advanced. The basic scenario applies to a single-server farm environment and is recommended if you want to use default settings, whereas the advanced scenario applies to a single-server farm or a multiple-server farm and contains several advanced options from which to choose. For more information, see Plan incoming e-mail (SharePoint Foundation 2010).

Before you perform these procedures, confirm that:

  • Your system is running SharePoint Foundation 2010.

  • You have read Plan incoming e-mail (SharePoint Foundation 2010).

  • If you are using the basic scenario, each SharePoint front-end Web server must be running the Simple Mail Transfer Protocol (SMTP) service and the Microsoft SharePoint Foundation Web Application service.

  • If you are using the advanced scenario, you can use one or more servers in the server farm to run the SMTP service and to have a valid SMTP server address. Alternatively, you must know the name of a server outside the farm that is running the SMTP service and the location of the e-mail drop folder.

If you have not installed and configured the SMTP service and do not choose to use an e-mail drop folder, you must perform the following procedures before you configure incoming e-mail:

  • Install and configure the SMTP service.

Install and configure the SMTP service

Incoming e-mail for SharePoint Foundation 2010 uses the SMTP service. You can use the SMTP service in one of two ways. You can install the SMTP service on one or more servers in the farm, or administrators can provide an e-mail drop folder for e-mail that is forwarded from the service on another server. For more information about the e-mail drop folder option, see Plan incoming e-mail (SharePoint Foundation 2010).

Install the SMTP service

If you are not using a drop folder for e-mail, the SMTP service must be installed on every front-end Web server in the farm that you want to configure for incoming e-mail. To install the SMTP service, use the Add Features Wizard in Server Manager. After the procedure is complete, a default SMTP configuration has been created. You can customize this default SMTP configuration to meet the requirements of your environment.

To install the SMTP service

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Administrators group on the local computer.

  2. Click Start, point to Administrative Tools, and then click Server Manager.

  3. In Server Manager, click Features.

  4. In Features Summary, click Add Features to open the Add Features Wizard.

  5. On the Select Features page, select SMTP Server.

  6. In the Add Features Wizard dialog box, click Add Required Features, and then click Next.

  7. On the Confirm Installation Selections page, click Install.

  8. On the Installation Results page, ensure that the installation finished successfully, and then click Close.

Install IIS 6.0 Management tools

To manage the SMTP service on Windows Server 2008 and Windows Server 2008 R2, you must use Internet Information Services (IIS) 6.0 Manager.

To install IIS 6.0 Manager

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Administrators group on the local computer.

  2. Click Start, point to Administrative Tools, and then click Server Manager.

  3. In Server Manager, click Roles.

  4. In Role Services, click Add Role Services.

  5. On the Select Role Services page, select Management Tools and IIS 6 Management compatibility, and then click Install.

Configure the SMTP service

After you install the SMTP service, you configure it to accept e-mail from the mail server for the domain. You can decide to accept relayed e-mail from all servers except those that you specifically exclude. Alternatively, you can block e-mail from all servers except those that you specifically include. You can include servers individually, or in groups by subnet or domain.

After you configure the service, set it to start automatically.

To configure the SMTP service

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Administrators group on the local computer.

  2. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) 6.0 Manager.

  3. In IIS Manager, expand the server name that contains the SMTP server that you want to configure.

  4. Right-click the SMTP virtual server that you want to configure, and then click Start.

  5. Right-click the SMTP virtual server that you want to configure, and then click Properties.

  6. On the Access tab, in the Access control area, click Authentication.

  7. In the Authentication dialog box, verify that Anonymous access is selected.

  8. Click OK.

  9. On the Access tab, in the Relay restrictions area, click Relay.

  10. To enable relaying from any server, click All except the list below.

  11. To accept relaying from one or more specific servers, follow these steps:

    1. Click Only the list below.

    2. Click Add, and then add servers one at a time by IP address, or in groups by using a subnet or domain.

    3. Click OK to close the Computer dialog box.

  12. Click OK to close the Relay Restrictions dialog box.

  13. Click OK to close the Properties dialog box.

To set the SMTP service to start automatically

  1. Click Start, point to Administrative Tools, and then click Services.

  2. In Services, right-click Simple Mail Transfer Protocol (SMTP), and then select Properties.

  3. In the Simple Mail Transfer Protocol (SMTP) Properties dialog box, on the General tab, in the Startup type list, select Automatic.

  4. Click OK.

Configure incoming e-mail in a basic scenario

You can use the following procedure to configure incoming e-mail in a basic scenario by selecting the Automatic settings mode and using the default settings. After the procedure is complete, users can send e-mail to lists and libraries.

To configure incoming e-mail in a basic scenario

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Administrators group on the computer that is running the SharePoint Central Administration Web site.

  2. In Central Administration, click System Settings.

  3. On the System Settings page, in the E-Mail and Text Messages (SMS) section, click Configure incoming e-mail settings.

  4. If you want to enable sites on this server to receive e-mail, on the Configure Incoming E-Mail Settings page, in the Enable Incoming E-Mail section, click Yes.

  5. Select the Automatic settings mode.

  6. In the Incoming E-Mail Server Display Address section, in the E-mail server display address box, type a display name for the e-mail server, for example, mail.fabrikam.com.

  7. Use the default settings for all other sections, and then click OK.

After you configure incoming e-mail, users who have Manage Lists permissions can configure e-mail-enabled lists and document libraries.

Configure incoming e-mail in an advanced scenario

You can use the following procedure to configure incoming e-mail in an advanced scenario by selecting the Advanced settings mode and additional options that you want to use for your incoming e-mail environment. After the procedure is complete, users can send e-mail to lists and libraries.

Note:

You can also use the Automatic settings mode in an advanced scenario. The main difference is that in the Automatic settings mode, you can select to receive e-mail that has been routed through a safe-e-mail server application, whereas in the Advanced settings mode, you can instead specify a drop folder. For more information, see Plan incoming e-mail (SharePoint Foundation 2010).

Several of these steps mention pre-requisite procedures that are documented in the Configure incoming e-mail in an advanced scenario section of this article.

To configure incoming e-mail in an advanced scenario

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Administrators group on the computer that is running the SharePoint Central Administration Web site.

  2. In Central Administration, click System Settings.

  3. On the System Settings page, in the E-Mail and Text Messages (SMS) section, click Configure incoming e-mail settings.

  4. If you want to enable sites on this server to receive e-mail, on the Configure Incoming E-mail Settings page, in the Enable Incoming E-Mail section, click Yes.

  5. Select the Advanced settings mode.

    If you select Advanced, you can specify a drop folder instead of using an SMTP server.

    Note:

    You can also select the Automatic settings mode and select whether to use Directory Management Service and whether to accept e-mail from all e-mail servers or from several specified e-mail servers. For more information, see Plan incoming e-mail (SharePoint Foundation 2010).

  6. If you want to connect to Directory Management Service, in the Directory Management Service section, click Yes.

    If you select this option, you must first configure Active Directory Domain Services (AD DS). If you use Exchange Server, you must also configure the DNS Manager and add an SMTP connector. For more information, see the "Configure AD DS to be used with Directory Management Service", "Configure DNS Manager", and "Add an SMTP connector in Exchange Server 2010" sections later in this article.

    1. In the Active Directory container where new distribution groups and contacts will be created box, type the name of the container in the format OU=ContainerName, DC=domain, DC=com, where ContainerName is the name of the OU in AD DS, domain is the second-level domain, and com is the top-level domain.

      Note:

      The application pool identity account for Central Administration must be delegated the Create, delete, and manage user accounts task for the container. Access is configured in the properties for the OU in AD DS.

    2. In the SMTP mail server for incoming mail box, type the name of the SMTP mail server. The server name must match the FQDN in the A resource record entry for the mail server in DNS Manager.

    3. To accept only messages from authenticated users, click Yes for Accept messages from authenticated users only. Otherwise, click No.

    4. To enable users to create distribution groups from SharePoint sites, click Yes for Allow creation of distribution groups from SharePoint sites. Otherwise, click No.

    5. Under Distribution group request approval settings, select the actions that will require approval. Actions include the following:

      • Create new distribution group

      • Change distribution group e-mail address

      • Change distribution group title and description

      • Delete distribution group

  7. If you want to use a remote Directory Management Service, select Use remote.

    If you select this option and you are using Exchange Server, you must configure the DNS Manager and add an SMTP connector. For more information, see the "Configure DNS Manager" and "Add an SMTP connector in Exchange Server 2010" sections later in this article. The AD DS has most likely already been configured, so you do not need to do this.

    1. In the Directory Management Service URL box, type the URL of the Directory Management Service that you want to use. The URL is typically in the following format: http://server:adminport/_vti_bin/SharePointEmailWS.asmx.

    2. In the SMTP mail server for incoming mail box, type the name of the SMTP mail server. The server name must match the FQDN in the A resource record entry for the mail server in DNS Manager on the domain server.

    3. To accept messages from authenticated users only, click Yes for Accept messages from authenticated users only. Otherwise, click No.

    4. To allow creation of distribution groups from SharePoint sites, click Yes for Allow creation of distribution groups from SharePoint sites. Otherwise, click No.

  8. If you do not want to use Directory Management Service, click No.

  9. In the Incoming E-Mail Server Display Address section, in the E-mail server display address box, type a display name for the e-mail server (for example, mail.fabrikam.com). You typically use this option together with the Directory Management Service.

    Tip:

    You can specify the e-mail server address that is displayed when users create an incoming e-mail address for a list or group. Use this setting together with Directory Management Service to provide an e-mail server address that is easy to remember.

  10. In the E-Mail Drop Folder section, in the E-mail drop folder box, type the name of the folder from which SharePoint 2010 Timer service retrieves incoming e-mail from the SMTP service. If you select this option, ensure that you configure the necessary permissions to the e-mail drop folder. For more information, see the "Configure permissions to the e-mail drop folder" section later in this article.

    It is useful to have a dedicated e-mail drop folder if the default e-mail drop folder is full or almost full.

    Ensure that the logon account for the SharePoint 2010 Timer service has Modify permissions on the e-mail drop folder. For more information, see "To configure e-mail drop folder permissions for the logon account for the SharePoint 2010 Timer service" procedure later in this article.

    Note:

    This option is available only if you selected Advanced settings mode.

  11. In the Safe E-Mail Servers section, select whether you want to accept e-mail from all e-mail servers or from several specified e-mail servers.

    Note:

    This option is available only if you selected Automatic settings mode.

  12. Click OK.

After you configure incoming e-mail, site administrators can configure e-mail-enabled lists and document libraries.

If you selected Directory Management Service, contact addresses that are created for document libraries appear automatically in Active Directory Users and Computers. The addresses are displayed in the OU of AD DS for SharePoint Foundation 2010 and must be managed by the administrator of AD DS. The AD DS administrator can add more e-mail addresses for each contact. For more information about AD DS, see Using Active Directory Service (http://go.microsoft.com/fwlink/p/?LinkId=151348).

Alternatively, the Exchange Server computer can be configured by adding a new Exchange Server Global recipient policy. The policy automatically adds external addresses that use the second-level domain name and not the subdomain or host name for SharePoint Foundation 2010. For more information about how to manage Exchange Server, see Recipient Configuration Node (http://go.microsoft.com/fwlink/p/?LinkId=195326).

Prepare your environment for incoming e-mail in an advanced scenario

Before you configure incoming e-mail in an advanced scenario, you need to perform additional procedures depending on how you want your incoming e-mail environment to work.

If you want to use Directory Management Service, you must first configure AD DS, and if you use Exchange Server, you must also configure the DNS Manager and add an SMTP connector.

If you want to use a specific e-mail drop folder, ensure that you configure the necessary permissions to the e-mail drop folder.

In this section:

  • Configure AD DS to be used with Directory Management Service

  • Configure DNS Manager

  • Add an SMTP connector in Microsoft Exchange Server 2010

  • Configure permissions to the e-mail drop folder

Configure AD DS to be used with Directory Management Service

If you plan to use Directory Management Service you should first create an organizational unit (OU) and make the necessary configurations in AD DS.

To use Directory Management Service on a SharePoint farm or on a remote server farm, you must configure the application pool identity account for the SharePoint Central Administration Web site to have the Create, delete, and manage user accounts user right to the container that you specify in AD DS. The preferred way to do this is by assigning the right to the application pool identity account for the SharePoint Central Administration Web site. An AD DS administrator must set up the OU and assign the Create, delete, and manage user accounts right to the container. The advantage of using Directory Management Service on a remote server farm is that you do not have to assign rights to the OU for multiple farm service accounts.

The following procedures are performed on a domain controller that runs Windows Server 2008 with DNS Manager. In some deployments, these applications might run on multiple servers in the same domain.

To create an OU in AD DS

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Domain Administrators group or a delegated authority for domain administration on the domain controller that is running DNS Manager.

  2. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.

  3. In Active Directory Users and Computers, right-click the folder for the second-level domain that contains your server farm, point to New, and then click Organizational Unit.

  4. Type the name of the OU, and then click OK.

    After you create the OU, you must delegate the Create, delete, and manage user accounts right to the container of the OU to manage the user accounts.

To delegate the right to the application pool identity account for Central Administration

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Domain Administrators group or the Enterprise Administrators group in AD DS, or a delegated authority for domain administration.

  2. In Active Directory Users and Computers, find the OU that you created.

  3. Right-click the OU, and then click Delegate control.

  4. On the Welcome page of the Delegation of Control Wizard, click Next.

  5. On the Users and Groups page, click Add, and then type the name of the application pool identity account that the Central Administration uses.

  6. In the Select Users, Computers, and Groups dialog box, click OK.

  7. On the Users or Groups page of the Delegation of Control Wizard, click Next.

  8. On the Tasks to Delegate page of the Delegation of Control Wizard, select the Create, delete, and manage user accounts check box, and then click Next.

  9. On the last page of the Delegation of Control Wizard, click Finish to exit the wizard.

To create and delete child objects, you must also delegate Create all Child Objects and Delete all Child Objects control of the OU to the application pool identity account for Central Administration. After this procedure is complete, the application pool identity account for Central Administration has Create all Child Objects and Delete all Child Objects control on the OU, and you can enable incoming e-mail.

To delegate Create all Child Objects and Delete all Child Objects control of the OU to the application pool identity account for Central Administration

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Domain Administrators group or the Enterprise Administrators group in AD DS, or a delegated authority for domain administration.

  2. Right-click the OU, and then click Delegate control.

  3. In the Delegation of Control Wizard, click Next.

  4. Click Add, and then type the name of the application pool identity account for Central Administration.

  5. Click OK.

  6. Click Next.

  7. On the Tasks to Delegate page of the Delegation of Control Wizard, select Create a custom task to delegate, and then click Next.

  8. Click This folder, existing objects in this folder, and creation of new objects in this folder, and then click Next.

  9. In the Permissions section, select Create all Child Objects and Delete all Child Objects.

  10. Click Next.

  11. On the last page of the Delegation of Control Wizard, click Finish to exit the wizard.

Delegating Create all Child Objects and Delete all Child Objects control of the OU to the application pool identity account for Central Administration enables administrators to enable e-mail for a list. After these controls have been delegated, administrators cannot disable e-mail for the list or document library because the Central Administration account tries to delete the contact from the whole OU instead of from the list.

To avoid this problem, you must add Delete Subtree permissions for the application pool identity account for Central Administration. Use the following procedure to add these permissions. After this procedure is complete, you can disable incoming e-mail for a list.

To add Delete Subtree permissions for the application pool identity account for Central Administration

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Domain Administrators group or the Enterprise Administrators group in AD DS, or a delegated authority for domain administration.

  2. In Active Directory Users and Computers, click the View menu, and then click Advanced Features.

  3. Right-click the OU, and then click Properties.

  4. In the Properties dialog box, click the Security tab, and then click Advanced.

  5. In the Permission Entries area, double-click the application pool identity account for Central Administration.

    Note:

    If the application pool identity account is listed more than once, select the first one.

  6. In the Permissions area, select Allow, for Delete Subtree.

  7. Click OK to close the Permissions dialog box.

  8. Click OK to close the Properties dialog box.

  9. Click OK to close Active Directory Users and Computers.

After you add these permissions, you must restart Internet Information Services (IIS) for the farm.

For more information, see Active Directory Users, Computers, and Groups (http://go.microsoft.com/fwlink/p/?LinkId=151331).

Configure DNS Manager

If you are using Exchange Server and are routing e-mail internally in your organization, you must create a host (A) resource record in DNS Manager to associate DNS domain names of computers (or hosts) to their IP addresses. Your organization might have already configured DNS Manager and created an A resource record. If not, then use the following procedure.

To create an A resource record for a subdomain

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Administrators group on the local computer.

  2. In DNS Manager, select the forward lookup zone for the domain that contains the subdomain for SharePoint Foundation 2010.

  3. Right-click the zone, and then click New Host (A or AAAA).

  4. In the New Host dialog box, in the Name text box, type the host or subdomain name for SharePoint Foundation 2010.

  5. In the Fully qualified domain name (FQDN) text box, type the FQDN for the server that is running SharePoint Foundation 2010. This is typically in the format subdomain.domain.com.

    Note:

    Ensure that the domains that are listed under the SMTP server in IIS match the FQDN of the server that receives e-mail. If they do not match, you must create a local domain, which is described in the following procedure.

  6. In the IP address text box, type the IP address to which you want the FQDN to resolve.

  7. Click Add Host.

  8. In the message that confirms the creation of the host record, click OK.

  9. In the New Host dialog box, click Done.

    The A resource record now appears in DNS Manager.

If you use the E-mail server display address option and if the e-mail address to which you are sending e-mails is not the same as your machine name, you must create a local domain.

To create a local domain

  1. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) 6.0 Manager.

  2. In IIS Manager, expand the SMTP server.

  3. Right-click Domains, and on the Action menu, point to New, and then click Domain.

  4. In the New SMTP Domain Wizard dialog box, select Alias, and then click Next.

  5. In the Domain Name area, in the Name box, type the address of the mail that is to be received by this domain.

    This address must be the same as the one that you specified in step 4 in the "To Create an A Resource Record for the Subdomain" procedure, and in step 6b in the "To Configure Incoming E-Mail in an Advanced Scenario" procedure.

  6. Click Finish.

  7. In the message that confirms the creation of the host record, click OK.

Note:

Restart the SMTP server so that any e-mail messages that are still in the Queue folder move to the Drop folder. The messages are then sent by the SharePoint 2010 Timer service to their destination list or library.

Note:

If you are routing e-mail from outside your organization to an SMTP server, you must use an MX record. For more information, see Add a mail exchanger (MX) resource record to a zone (http://go.microsoft.com/fwlink/p/?LinkId=150827).

Add an SMTP connector in Microsoft Exchange Server 2010

An SMTP connector gives you more control over the message flow in your organization. Other reasons to use an SMTP connector are to set delivery restrictions or to specify a specific address space. If you use Exchange Server to route incoming e-mail to SharePoint lists and libraries, you must have an SMTP connector so that all mail that is sent to the SharePoint Foundation 2010 domain uses the SharePoint Foundation 2010 servers that are running the SMTP service.

Use the following procedure to add an SMTP connector in Exchange Server. After the procedure is complete, the SMTP connector ensures that incoming e-mail messages are sent to the correct list and library in the farm.

To add an SMTP connector in Exchange Server

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Administrators group on the computer that is running Exchange Server.

  2. In Exchange Management Console, expand the Organization Configuration group, right-click Hub Transport, point to New Send Connector.

    The New Send Connector wizard appears.

  3. On the Introduction page, do the following and then click Next:

    1. In the Name box, type a name for the SMTP connector.

    2. In the Select the intended use for this Send connector box, select the Custom usage type for the connector.

  4. On the Address Space page, click Add, and then click SMTP Address Space.

  5. In the SMTP Address Space dialog box, do the following:

    1. In the Address box, type an e-mail domain for the connector.

    2. In the Cost box, assign an appropriate cost. By default, the cost is 1.

  6. Click OK to return to the Address Space page, and then click Next.

  7. On the Network settings page, select Use domain name system (DNS) "MX" records to route mail automatically, and then click Next.

  8. On the Source Server page, click Next.

    The Source server page only appears on Hub Transport servers. By default, the Hub Transport server that you are currently working on is listed as a source server.

  9. On the New Connector page, review your options and then click New to create the new send connector.

  10. On the Completion page, ensure that the send connector was created, and then click Finish.

    In the Hub Transport pane, you can see that the send connector has been enabled automatically.

For more in-depth information, see Create an SMTP Send Connector (http://go.microsoft.com/fwlink/p/?LinkId=195321).

Configure permissions to the e-mail drop folder

You can specify a particular e-mail drop folder, which enables SharePoint Foundation 2010 to retrieve incoming e-mail from a network share on another server. You can use this option if you do not want to use an SMTP service. However, the drawback of using this option is that SharePoint Foundation 2010 cannot detect configuration changes on the remote e-mail server that is delivering e-mail to the drop folder. The result is that SharePoint Foundation 2010 cannot retrieve e-mail if the location of the e-mail messages has changed. However, this feature is useful if the default e-mail drop folder is full or almost full.

If you specified an e-mail drop folder, you must ensure that the application pool identity accounts for Central Administration and for the Web application have the required permissions to the e-mail drop folder.

Configure e-mail drop folder permissions for the application pool identity account for a Web application

If your deployment uses different application pool identity accounts for Central Administration and for one or more Web applications, each application pool identity account must have permissions to the e-mail drop folder. If the application pool identity account for the Web application does not have the required permissions, e-mail will not be delivered to document libraries on that Web application.

In most cases, when you configure incoming e-mail and select an e-mail drop folder, permissions are added for the following worker process groups:

  • WSS_Admin_WPG, which includes the application pool identity account for Central Administration and the logon account for the SharePoint 2010 Timer service, and has Full Control permissions.

  • WSS_WPG, which includes the application pool accounts for Web applications, and has Read & Execute, List Folder Contents, and Read permissions.

In some cases, these groups might not be configured automatically for the e-mail drop folder. For example, if Central Administration is running as the Network Service account, the groups or accounts that are needed for incoming e-mail will not be added when the e-mail drop folder is created. Check to find out whether these groups have been added automatically to the e-mail drop folder. If the groups have not been added automatically, you can add them or add the specific accounts that are required.

To configure e-mail drop folder permissions for the application pool identity account for a Web application

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Administrators group on the computer that contains the e-mail drop folder.

  2. In Windows Explorer, right-click the drop folder, click Properties, and then click the Security tab.

  3. On the Security tab, under the Group or user names box, click the Edit button.

  4. In the Permissions for Windows Explorer dialog box, click the Add button.

  5. In the Select Users, Computers, or Groups dialog box, in the Enter the object names to select box, type the name of the worker process group or application pool identity account for the Web application, and then click OK.

    Note:

    This account is listed on the Identity tab of the Properties dialog box for the application pool in IIS.

  6. In the Permissions for User or Group box, next to Modify, select Allow.

  7. Click OK.

Configure e-mail drop folder permissions for the logon account for the SharePoint 2010 Timer service

Ensure that the logon account for the SharePoint 2010 Timer service has Modify permissions on the e-mail drop folder. If the logon account for the service does not have Modify permissions, e-mail-enabled document libraries will receive duplicate e-mail messages.

To configure e-mail drop folder permissions for the logon account for the SharePoint 2010 Timer service

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Administrators group on the computer that contains the e-mail drop folder.

  2. In Windows Explorer, right-click the drop folder, click Properties, and then click the Security tab.

  3. On the Security tab, under the Group or user names box, click the Edit button.

  4. In the Permissions for Windows Explorer dialog box, click the Add button.

  5. In the Select Users, Computers, or Groups dialog box, in the Enter the object names to select box, type the name of the logon account for the SharePoint 2010 Timer service, and then click OK.

    Note:

    This account is listed on the Log On tab of the Properties dialog box for the service in the Services console.

  6. In the Permissions for User or Group box, next to Modify, select Allow.

  7. Click OK.

Are attachments missing from e-mail messages that are sent to a SharePoint document library?

If attachments are missing from e-mail messages that are sent to a SharePoint Foundation 2010 document library, it might be because you associated the document library with an e-mail address. When you do this, Directory Management Service may not add the following two attributes:

  • internet Encoding = 1310720

  • mAPIRecipient = false

You must use Active Directory Service Interfaces (ADSI) to manually add these two missing attributes.

Note:

On servers that are running Windows Server 2008 or Windows Server 2008 R2, ADSI Edit is installed when you install the AD DS role to make a server a domain controller. You can also install Windows Server 2008 Remote Server Administration Tools (RSAT) on domain member servers or stand-alone servers. For more information, see Installing or Removing the Remote Server Administration Tools Pack (http://go.microsoft.com/fwlink/p/?LinkId=143345).

To add attributes by using ADSI Edit

  1. Click Start, and then click Run.

  2. In the Run dialog box, type Adsiedit.msc, and then click OK.

  3. In the ADSI Edit window, expand ADSI Edit, expand Domain [DomainName], expand DC=DomainName, DC=com, and then expand CN=Users.

  4. Right-click the user name to which you want to add the missing attributes, and then click Properties.

  5. In the Properties dialog box, double-click internet Encoding on the Attribute Editor tab.

  6. In the Integer Attribute Editor dialog box, type 1310720 in the Value box, and then click OK.

  7. In the Properties dialog box, double-click mAPIRecipient on the Attribute Editor tab.

  8. In the Boolean Attribute Editor dialog box, click False, and then click OK two times.

See Also

Concepts

Plan incoming e-mail (SharePoint Foundation 2010)

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010


Configure outgoing e-mail (SharePoint Foundation 2010)
See Also

This article describes how to configure outgoing e-mail for a farm or for a specific Web application for Microsoft SharePoint Foundation 2010. This article also describes how to install and configure the SMTP service that you must use to enable outgoing e-mail.

In this article:

  • To install the SMTP service

  • To install IIS 6.0 Management tools

  • To configure the SMTP service

  • To set the SMTP service to start automatically

  • To configure outgoing e-mail for a farm by using Central Administration

  • To configure outgoing e-mail for a farm by using the Stsadm command-line tool

  • To configure outgoing e-mail for a specific Web application by using Central Administration

  • To configure outgoing e-mail for a specific Web application by using the Stsadm command-line tool

After you have installed SharePoint Foundation 2010 and performed the initial configuration of your server farm, you can configure outgoing e-mail. Doing so enables users to create alerts to track such site items as lists, libraries, and documents. In addition, site administrators can receive administrative messages about site administrator issues, such as the information that site owners have exceeded their specified storage space. For more information, see Plan outgoing e-mail (SharePoint Foundation 2010).

If you want to configure outgoing e-mail for a specific Web application, you must first configure the default outgoing e-mail for all Web applications in the farm. If you configure the outgoing e-mail for a specific Web application, that configuration will override the default configuration for all Web applications in the farm.

Note:

You cannot configure outgoing e-mail by using Windows PowerShell.

Before you perform these procedures, confirm that:

  • Your system is running SharePoint Foundation 2010.

  • One or more servers in the server farm are running the Simple Mail Transfer Protocol (SMTP) service and have a valid SMTP server address. Alternatively, you must know the name of a server outside the farm that is running the SMTP service.

If you have not installed and configured the SMTP service, you must perform the following procedures before you configure outgoing e-mail:

  • Install and configure the SMTP service.

Install and configure the SMTP service

Before you can enable outgoing e-mail, you must determine which SMTP server to use. This SMTP server must be configured to allow anonymous SMTP e-mail submissions. The SMTP server can be a server in the farm or outside the farm.

Note:

If your organization does not allow anonymous SMTP e-mail messages to be sent by using Microsoft Exchange Server, you can use a local SMTP server in the SharePoint farm that accepts anonymous e-mail messages. The local SMTP server automatically authenticates the messages and then forwards them to the Exchange Server computer.

Install the SMTP service

To install the SMTP service, use the Add Features Wizard in Server Manager. After the wizard finishes, a default SMTP configuration has been created. You can customize this default SMTP configuration to meet the requirements of your organization.

Note:

If you already have the SMTP service installed on a server, you can skip the following procedure.

To install the SMTP service

  1. Verify that you have the following administrative credentials: You must be a member of the Administrators group on the local computer

  2. Click Start, point to Administrative Tools, and then click Server Manager.

  3. In Server Manager, click Features.

  4. In Features Summary, click Add Features to open the Add Features Wizard.

  5. On the Select Features page, select SMTP Server.

  6. In the Add Features Wizard dialog box, click Add Required Features, and then click Next.

  7. On the Confirm Installation Selections page, click Install.

  8. On the Installation Results page, ensure that the installation is complete, and then click Close.

Configure the SMTP service

After you install the SMTP service, you must configure the service to accept e-mail messages from servers in the farm.

You can decide to accept relayed e-mail messages from all servers except those that you specifically exclude. Alternatively, you can block messages from all servers except those that you specifically include. You can include servers individually or in groups by subnet or domain.

If you enable anonymous access and relayed e-mail messages, you increase the possibility that the SMTP server will be used to relay unsolicited commercial e-mail messages (spam). It is important to limit this possibility by carefully configuring mail servers to help protect against spam. One way that you can do this is by limiting relayed e-mail messages to a list of specific servers or to a domain, and by preventing relayed e-mail messages from all other servers.

Note:

To manage the SMTP service on Windows Server 2008, you must use Internet Information Services (IIS) 6.0 Manager. Ensure that you install IIS 6.0 Management tools in Server Manager.

To install IIS 6.0 Management tools

  1. Verify that you have the following administrative credentials: You must be a member of the Administrators group on the local computer.

  2. Click Start, point to Administrative Tools, and then click Server Manager.

  3. In Server Manager, click Roles.

  4. In the Role Services section, click Add Role Services.

  5. On the Select Role Services page, select Management Tools and IIS 6 Management compatibility, and then click Install.

To configure the SMTP service

  1. Verify that you have the following administrative credentials: You must be a member of the Administrators group on the local computer.

  2. Click Start, point to Administrative Tools, and then click Internet Information Services (IIS) 6.0 Manager.

  3. In IIS Manager, expand the server name that contains the SMTP server that you want to configure.

  4. Right-click the SMTP virtual server that you want to configure, and then click Start.

  5. Right-click the SMTP virtual server that you want to configure, and then click Properties.

  6. On the Access tab, in the Access control area, click Authentication.

  7. In the Authentication dialog box, verify that Anonymous access is selected.

  8. Click OK.

  9. On the Access tab, in the Relay restrictions area, click Relay.

  10. To enable relayed e-mail messages from any server, click All except the list below.

  11. To accept relayed e-mail messages from one or more specific servers, follow these steps:

    1. Click Only the list below.

    2. Click Add, and then add servers one at a time by IP address, or in groups by using a subnet or domain.

    3. Click OK to close the Computer dialog box.

  12. Click OK to close the Relay Restrictions dialog box.

  13. Click OK to close the Properties dialog box.

Note:

Ensure that the SMTP service is running and set to start automatically. To do this, use the following procedure.

To set the SMTP service to start automatically

  1. Click Start, point to Administrative Tools, and then click Services.

  2. In Services, right-click Simple Mail Transfer Protocol (SMTP), and then select Properties.

  3. In the Simple Mail Transfer Protocol (SMTP) Properties dialog box, on the General tab, in the Startup type list, select Automatic.

  4. Click OK.

Configure outgoing e-mail for a farm

You can configure outgoing e-mail for a farm by using the SharePoint Central Administration Web site or by using the Stsadm command-line tool. Use the following procedures to configure outgoing e-mail. After you complete the procedures, end users can track changes and updates to individual site collections. In addition, site administrators can, for example, receive notices when users request access to a site.

To configure outgoing e-mail for a farm by using Central Administration

  1. Verify that you have the following administrative credentials: You must be a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.

  2. In Central Administration, click System Settings.

  3. On the System Settings page, in the E-Mail and Text Messages (SMS) section, click Configure outgoing e-mail settings.

  4. On the Outgoing E-Mail Settings page, in the Mail Settings section, type the SMTP server name for outgoing e-mail (for example, mail.example.com) in the Outbound SMTP server box.

  5. In the From address box, type the e-mail address as you want it to be displayed to e-mail recipients.

  6. In the Reply-to address box, type the e-mail address to which you want e-mail recipients to reply.

  7. In the Character set list, select the character set that is appropriate for your language.

  8. Click OK.

To configure outgoing e-mail for a farm by using the Stsadm command-line tool

  1. Verify that you have the following administrative credentials: You must be a member of the Administrators group on the local computer.

  2. On the drive on which SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\14\Bin.

  3. Type the following command, and then press ENTER:

    stsadm -o email

    -outsmtpserver <SMTP server name>

    -fromaddress <valid e-mail address>

    -replytoaddress <valid e-mail address>

    -codepage <valid code page>

Example

stsadm -o email -outsmtpserver mail.example.com -fromaddress someone@example.com -replytoaddress someone@example.com -codepage 65001

For more information, see Email: Stsadm operation (Windows SharePoint Services) (http://go.microsoft.com/fwlink/p/?LinkId=150046).

Configure outgoing e-mail for a specific Web application

You can configure outgoing e-mail for a specific Web application by using the Central Administration Web site or by using the Stsadm command-line tool. Use the following procedures to configure outgoing e-mail. After you complete the procedures, end users can track changes and updates to individual site collections. In addition, site administrators can, for example, receive notices when users request access to a site.

Note:

If you want to configure outgoing e-mail for a specific Web application, you must first configure the default outgoing e-mail for all Web applications in the farm. If you configure the outgoing e-mail for a specific Web application, that configuration will override the default configuration for all Web applications in the farm.

To configure outgoing e-mail for a specific Web application by using Central Administration

  1. Verify that you have the following administrative credentials: You must be a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.

  2. In Central Administration, in the Application Management section, click Manage web applications.

  3. On the Web Applications Management page, select a Web application, and then in the General Settings group on the Ribbon, click Outgoing E-mail.

  4. On the Web Application Outgoing E-Mail Settings page, in the Mail Settings section, type the SMTP server name for outgoing e-mail (for example, mail.fabrikam.com) in the Outbound SMTP server box.

  5. In the From address box, type the e-mail address (for example, the site administrator alias) as you want it to be displayed to e-mail recipients.

  6. In the Reply-to address box, type the e-mail address (for example, a help desk alias) to which you want e-mail recipients to reply.

  7. In the Character set list, click the character set that is appropriate for your language.

  8. Click OK.

To configure outgoing e-mail for a specific Web application by using the Stsadm command-line tool

  1. Verify that you have the following administrative credentials: You must be a member of the Administrators group on the local computer.

  2. On the drive on which SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\14\Bin.

  3. Type the following command, and then press ENTER:

    stsadm -o email

    -outsmtpserver <SMTP server name>

    -fromaddress <valid e-mail address>

    -replytoaddress <valid e-mail address>

    -codepage <valid code page>

    [-url <URL name>]

Example

stsadm -o email -outsmtpserver mail.example.com -fromaddress someone@example.com -replytoaddress someone@example.com -codepage 65001 -url http://server_name

For more information, see Email: Stsadm operation (Windows SharePoint Services) (http://go.microsoft.com/fwlink/p/?LinkId=150046).

See Also

Concepts

Plan outgoing e-mail (SharePoint Foundation 2010)
Configure alert settings for a Web application (SharePoint Foundation 2010)

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010


Configure a mobile account (SharePoint Foundation 2010)
See Also

This article discusses how to configure and manage a mobile account for Microsoft SharePoint Foundation 2010 to enable users to subscribe to alerts that are sent by using Short Message Service (SMS). The alerts are sent to users' mobile phones when changes are made to a SharePoint list or item.

The mobile alert feature resembles a feature that already exists in SharePoint Foundation 2010 that enables outgoing e-mail alerts. However, instead of receiving alerts via e-mail when changes are made in a SharePoint list or item, users receive the alerts on their mobile phones. For more information about e-mail alerts, see Configure outgoing e-mail (SharePoint Foundation 2010).

A SharePoint site is usually located on an intranet. As a result, access to the SharePoint site can be difficult when users are away from the office — for example, when they are traveling or attending a business dinner. The mobile alert feature enables users to react quickly when they receive an SMS alert that an item in a SharePoint list has changed.

You can configure one mobile account for all Web applications in a server farm, or you can configure the mobile account for a specific Web application; however, you can only configure one mobile account in the farm. The scale of your implementation might determine whether you configure the mobile account for the farm or for a specific Web application. If you configure the mobile account for a server farm, everyone in the organization can subscribe to alerts. This is useful, for example, in a small organization in which management wants all users to receive certain alerts. If you have several Web applications that divide your organization into groups, you might want to configure a mobile account for only one of those groups; for example, you want to configure a mobile account to enable everyone in the sales group to subscribe to alerts.

Before you perform these procedures, confirm that:

  • The Server farm account has permission to access the Internet for sending alerts.

  • You have obtained the root certificate for the service provider's HTTPS Web address. You can obtain the root certificate from your service provider or by using your Web browser.

Procedures in this article:

  • Import a root certificate and create a trusted root authority

  • Configure a mobile account

  • Retrieve mobile account information

  • Delete a mobile account

Import a root certificate and create a trusted root authority

Before you configure a mobile account, you must import the root certificate of the service provider's HTTPS Web address, and then create a trusted root authority. This step can only be performed manually by using Windows PowerShell.

To import a root certificate and create a trusted root authority by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. Additionally, you must be a member of the Farm Administrators group and a member of the local Administrators group on the computer running Windows PowerShell.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. To get the root certificate, at the Windows PowerShell command prompt, type the following command:

    Copy Code
    $cert = Get-PfxCertificate <ObtainedCertificatePath>

    To create a trusted root authority, at the Windows PowerShell command prompt, type the following command:

    Copy Code
    New-SPTrustedRootAuthority -Name <Name> -Certificate $cert

    Where:

    • <Name> is the name of the trusted root authority that you want to create.

    • <ObtainedCertificatePath> is the location of the root certificate file.

    Note:

    In the Certificate window, on the Certification Path tab, ensure that you use only the root certificate, and not the other certificates listed. The SharePoint Trusted Root Authorities list should only list root certificates.

For more information, see New-SPTrustedRootAuthority.

Configure a mobile account

You can configure a mobile account for a server farm or for a specific Web application, either by using Central Administration or Windows PowerShell.

Note:

If you cannot configure a mobile account, you may have the wrong certificate file. In that case, contact your service provider.

To configure or edit a mobile account for a server farm by using Central Administration

  1. Verify that you have the following administrative credentials:

    • To configure a mobile account for a server farm, you must be a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.

  2. On the Central Administration Home page, click System Settings.

  3. On the System Settings page, in the E-Mail and Text Messages (SMS) section, click Configure mobile account.

  4. On the Mobile Account Settings page, in the Text Message (SMS) Service Settings section, click the Microsoft Office Online link to access a list of service providers.

  5. On the Find an Office 2010 Mobile Service Provider page, in the Choose your wireless service provider's country/region list, select the country or region in which your wireless service provider is located.

  6. On the Find an Office 2010 Mobile Service Provider page, in the Choose your current wireless service provider list, select the wireless service provider that you want to use.

    After you make this selection, you are directed to the Web site of the service provider that you selected. On the Web site, you apply for the SMS service. When you receive the required information from the service provider, return to the Mobile Accounts Settings page.

  7. In the The URL of Text Message (SMS) Service box, type the URL of the SMS service.

    Note:

    Ensure that the service URL you enter is an HTTPS URL.

  8. In the User Name box and Password box, type the user name and password that you received from the SMS service provider.

  9. To confirm that the URL and user credentials are correct, click Test Service.

  10. Click OK.

To configure or edit a mobile account for a server farm by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. Additionally, you must be a member of the Farm Administrators group and a member of the local Administrators group on the computer running Windows PowerShell.

  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:

    Copy Code
    Set-SPMobileMessagingAccount -Identity sms -WebApplication <WebApplicationUrl> [-ServiceUrl <ServiceUrl>] [-UserId <UserId>] [-Password <Password>]

    Where:

    • <WebApplicationUrl> is the Central Administration URL.

    • <ServiceUrl> is the URL to server where the SMS service is located.

    • <UserId> is the user name that you received from the SMS service provider.

    • <Password> is the user password that you received from the SMS service provider.

    Example:

    Copy Code
    Set-SPMobileMessagingAccount -Identity sms -WebApplication http://myserver:8080 -ServiceUrl https://www.example.com/omsservice.asmx -UserId someone@example.com -Password password1

    Or, if you use the pipeline operator, type the following command:

    Copy Code
    Get-SPWebApplication -Identity http://myserver:8080 | Set-SPMobileMessagingAccount -Identity sms -ServiceUrl https://www.example.com/omsservice.asmx -UserId someone@example.com -Password password1
    Note:

    Ensure that the service URL you enter is an HTTPS URL.

For more information, see Set-SPMobileMessagingAccount and Get-SPWebApplication.

To configure or edit a mobile account for a Web application by using Central Administration

  1. Verify that you have the following administrative credentials:

    • To configure a mobile account for a server farm, you must be a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.

  2. On the Central Administration Home page, in the Application Management section, click Manage web applications.

  3. On the Web Applications page, select the Web application for which you want to configure a mobile account. In General Settings on the ribbon, click Mobile Account.

  4. On the Web Application Text Message (SMS) Service Settings page, in the Text Message (SMS) Service Settings section, click the Microsoft Office Online link to access a list of service providers.

  5. On the Find an Office 2010 Mobile Service Provider page, in the Choose your wireless service provider's country/region list, select the country or region in which your wireless service provider is located.

  6. On the Find an Office 2010 Mobile Service Provider page, in the Choose your current wireless service provider list, select the wireless service provider that you want to use.

    After you make this selection, you are directed to the Web site of the service provider that you selected. On the Web site, you apply for the SMS service. When you receive the required information from the service provider, return to the Mobile Accounts Settings page and type in the information.

  7. In the The URL of Text Message (SMS) Service box, type the URL of the SMS service.

    Note:

    Ensure that the service URL you enter is an HTTPS URL.

  8. In the User Name box and Password box, type the user name and password that you received from the SMS service provider.

  9. To confirm that the URL and user credentials are correct, click Test Service.

  10. Click OK.

To configure or edit a mobile account for a Web application by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. Additionally, you must be a member of the Farm Administrators group and a member of the local Administrators group on the computer running Windows PowerShell.

  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:

    Copy Code
    Set-SPMobileMessagingAccount -Identity sms -WebApplication <WebApplicationUrl> [-ServiceUrl <ServiceUrl>] [-UserId <UserId>] [-Password <Password>]

    Where:

    • <WebApplicationUrl> is the Web application URL.

    • <ServiceUrl> is the URL to server where the SMS service is located.

    • <UserId> is the user name that you received from the SMS service provider.

    • <Password> is the user password that you received from the SMS service provider.

    Example:

    Copy Code
    Set-SPMobileMessagingAccount -Identity sms -WebApplication http://localhost -ServiceUrl https://www.example.com/omsservice.asmx -UserId someone@example.com -Password password1

    Or, if you use the pipeline operator, type the following command:

    Copy Code
    Get-SPWebapplication -Identity http://localhost | Set-SPMobileMessagingAccount -Identity sms -ServiceUrl https://www.example.com/omsservice.asmx -UserId someone@example.com -Password password1
    Note:

    Ensure that the service URL you enter is an HTTPS URL.

For more information, see Set-SPMobileMessagingAccount and Get-SPWebApplication.

Retrieve mobile account information

You can retrieve mobile account information for a server farm or for a Web application by using Windows PowerShell. You might want to do this to view the mobile account information or, for example, verify that the set cmdlet works correctly.

To retrieve mobile account information for a server farm by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. Additionally, you must be a member of the Farm Administrators group and a member of the local Administrators group on the computer running Windows PowerShell.

  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:

    Copy Code
    Get-SPMobileMessagingAccount -WebApplication <WebApplicationUrl>

    Where <WebApplicationUrl> is the Central Administration URL.

    Example

    Copy Code
    Get-SPMobileMessagingAccount -WebApplication http://myserver

    Or, if you use the pipeline operator, type the following command:

    Copy Code
    Get-SPWebApplication -Identity http://myserver | Get-SPMobileMessagingAccount -AccountType sms

For more information, see Get-SPMobileMessagingAccount and Get-SPWebApplication.

To retrieve mobile account information for a Web application by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. Additionally, you must be a member of the Farm Administrators group and a member of the local Administrators group on the computer running Windows PowerShell.

  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:

    Copy Code
    Get-SPMobileMessagingAccount -WebApplication <WebApplicationUrl>

    Where <WebApplicationUrl> is the Web application URL.

    Example

    Copy Code
    Get-SPMobileMessagingAccount -WebApplication http://localhost

    Or, if you use the pipeline operator, type the following command:

    Copy Code
    Get-SPWebApplication -Identity http://localhost | Get-SPMobileMessagingAccount -AccountType sms

For more information, see Get-SPMobileMessagingAccount and Get-SPWebApplication.

Delete a mobile account

You can delete a mobile account for a server farm or for a Web application. This makes the account unavailable so users can no longer subscribe to SMS alerts, but it does not delete the account that you set up with the service provider. You might want to delete a mobile account if, for example, the organization decides that there is no business value in sending out SMS alerts to users.

Note:

There is no equivalent Windows PowerShell functionality.

To delete a mobile account for a server farm

  1. Verify that you have the following administrative credentials:

    • To delete a mobile account for a server farm, you must be a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.

  2. On the Central Administration Home page, click System Settings.

  3. On the System Settings page, in the E-mail and Text Messages (SMS) section, click Configure mobile account.

  4. On the Mobile Account Settings page, clear entries from all the boxes, and then click OK.

To delete a mobile account for a Web application

  1. Verify that you have the following administrative credentials:

    • To delete a mobile account for a server farm, you must be a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.

  2. On the Central Administration Home page, in the Application Management section, click Manage web applications.

  3. In General Settings on the ribbon, click Mobile Account.

  4. On the Web application Text Message (SMS) Service Settings page, delete entries from all the boxes, and then click OK.

See Also

Concepts

Configure outgoing e-mail (SharePoint Foundation 2010)

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010


Install and configure RBS (SharePoint Foundation 2010)
See Also

This article describes how to install and configure Remote BLOB Storage (RBS) for a Microsoft SQL Server 2008 R2 Express database server that supports a Microsoft SharePoint Foundation 2010 farm.

Important:

SQL Server 2008 R2 Express supports databases that are as large as 10 GB. If your installation includes databases that are larger than 4 GB but smaller than 10 GB, we recommend that you upgrade to SQL Server 2008 R2 Express for content database storage. SQL Server 2008 R2 Express is a free upgrade that you can download and install from Microsoft® SQL Server® 2008 R2 Feature Pack (http://go.microsoft.com/fwlink/p/?LinkID=177388).

Tip:

This solution uses the FILESTREAM RBS provider that is included with SQL Server 2008 R2 Express.

To use RBS, you must do the following:

  • Enable FILESTREAM on the database server - By default, FILESTREAM components are installed but are not enabled.

  • Provision a BLOB store for each content database- BLOB stores are folders where the BLOB data is stored on the file system. You must provision a BLOB store for each content database for which you want to use RBS.

  • Install the RBS client library on each Web server - The RBS client library stores the BLOB data on the file system, enable fidelity checks, and perform other tasks.

  • Enable RBS for each content database - You must enable RBS for each content database for which you want to use RBS.

  • Test the RBS installation

The user account that you use to perform the procedures that are described in this article must have the following memberships:

  • Administrators group on the Web servers and application servers.

  • SQL Server dbcreator and securityadmin fixed server roles on the computer that is running SQL Server 2008 R2 Express.

Enable FILESTREAM on the database server

By default, the FILESTREAM feature is installed when you install SQL Server 2008 Express, but it is not enabled. You must enable and configure FILESTREAM on the computer that is running SQL Server 2008 R2 Express that hosts the SharePoint Foundation 2010 databases. To enable and configure FILESTREAM, follow the instructions in How to: Enable FILESTREAM (http://go.microsoft.com/fwlink/p/?LinkID=166110&clcid=0x409). You only have to enable FILESTREAM one time for each database server where you want to use RBS.

Provision a BLOB store for each content database

After you have enabled and configured FILESTREAM, provision a BLOB store on the file system as described in the following procedure. You must provision a BLOB store for each content database.

To provision a BLOB store

  1. Click Start, click All Programs, click Microsoft SQL Server 2008, and then click SQL Server Management Studio.

  2. Connect to the instance of SQL Server that hosts the content database.

  3. Expand Databases.

  4. Click the content database for which you want to create a BLOB store, and then click New Query.

  5. Paste the following SQL queries in Query pane, and then execute them in the sequence listed. In each case, replace [WSS_Content] with the content database name, and replace c:\BlobStore with the volume\directory in which you want the BLOB store created. The provisioning process creates a folder in the location that you specify. Be aware that you can provision a BLOB store only one time. If you attempt to provision the same BLOB store multiple times, you will receive an error.

    Tip:

    For best performance, simplified troubleshooting, and as a general best practice, we recommend that you create the BLOB store on a volume that does not contain the operating system, paging files, database data, log files, or the tempdb file.

    Copy Code
    use [WSS_Content]
if not exists
(select * from sys.symmetric_keys
where name = N'##MS_DatabaseMasterKey##')
create master key encryption by password = N'Admin Key Password !2#4'
    Copy Code
    use [WSS_Content]
if not exists
(select groupname from sysfilegroups
where groupname=N'RBSFilestreamProvider')
alter database [WSS_Content]
add filegroup RBSFilestreamProvider contains filestream
    Copy Code
    use [WSS_Content]
alter database [WSS_Content]
 add file (name = RBSFilestreamFile, filename =
'c:\Blobstore')
to filegroup RBSFilestreamProvider

Install the RBS client library on each Web server

You must install RBS client library on all Web servers in the SharePoint farm. The RBS client library is installed only once per Web server, but RBS is configured separately for each associated content database. The client library consists of a client-side dynamic link library (DLL) that is linked into a user application, and a set of stored procedures that are installed on SQL Server.

Warning:

Do not install the RBS client library by running the RBS.msi file and starting the Install SQL Remote BLOB Storage wizard. The wizard sets certain default values that are not recommended for SharePoint Foundation 2010.

To install the RBS client library on the on the first Web server

  1. On any Web server, browse to http://go.microsoft.com/fwlink/?LinkID=188395&clcid=0x409 and download the RBS.msi file.

  2. Click Start, click Run, type cmd into the Run text box, and then click OK.

  3. Copy and paste the following command into the Command Prompt window. Replace WSS_Content with the database name, and replace DBInstanceName with the SQL Server instance name. You should run this command by using the specific database name and SQL Server instance name only one time. The operation should finish within approximately one minute.

    Copy Code
    msiexec /qn /lvx* rbs_install_log.txt /i RBS.msi TRUSTSERVERCERTIFICATE=true FILEGROUP=PRIMARY DBNAME="WSS_Content" DBINSTANCE="DBInstanceName" FILESTREAMFILEGROUP=RBSFilestreamProvider FILESTREAMSTORENAME=FilestreamProvider_1

To install the RBS client library on all additional Web and application servers

  1. On a Web server, download the RBS.msi at http://go.microsoft.com/fwlink/?LinkID=188395&clcid=0x409.

  2. Click Start, click Run, type cmd into the Run text box, and then click OK.

  3. Copy and paste the following command into the Command Prompt window. Replace WSS_Content with the database name, and replace DBInstanceName with the name of the SQL Server instance. The operation should finish within approximately one minute.

    Copy Code
    msiexec /qn /lvx* rbs_install_log.txt /i RBS.msi DBNAME="WSS_Content" DBINSTANCE="DBInstanceName" ADDLOCAL=Client,Docs,Maintainer,ServerScript,FilestreamClient,FilestreamServer

  4. Repeat this procedure for all Web servers and application servers in the SharePoint farm.

To confirm the RBS client library installation

  1. The rbs_install_log.txt log file is created in the same location as the RBS.msi file. Open the rbs_install_log.txt log file by using a text editor and scroll toward the bottom of the file. Within the last 20 lines of the end of the file, an entry should read as follows: Product: SQL Remote Blob Storage - Installation completed successfully.

  2. On the computer that is running SQL Server 2008 Express, verify that the RBS tables were created in the content database. Several tables should be listed under the content database that have names that are preceded by the letters "mssqlrbs".

Enable RBS for each content database

You must enable RBS on one Web server in the SharePoint farm. It is not important which Web server that you select for this activity, as long as RBS was installed on it by using the previous procedure. You must perform this procedure once for each content database.

Note:

You can only enable RBS by using Windows PowerShell.

To enable RBS 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    $cdb = Get-SPContentDatabase <ContentDatabaseName>
$rbss = $cdb.RemoteBlobStorageSettings
$rbss.Installed()
$rbss.Enable()
$rbss.SetActiveProviderName($rbss.GetProviderNames()[0])
$rbss

    Where:

    • <ContentDatabaseName> is the name of the content database.

For more information, see Get-SPContentDatabase.

Test the RBS installation

You should test the RBS installation on one Web server in the SharePoint farm to ensure that the system works correctly.

To test the RBS data store

  1. On the computer that contains the RBS data store, click Start, and then click Computer.

  2. Browse to the RBS data store directory.

  3. Confirm that the folder is empty.

  4. On the SharePoint farm, upload a file that is at least 100 kilobytes (KB) to a document library.

  5. On the computer that contains the RBS data store, click Start, and then click Computer.

  6. Browse to the RBS data store directory.

  7. Browse to the file list and open the file that has the most recent modified date. This should be the file that you uploaded.

See Also

Concepts

Overview of RBS (SharePoint Foundation 2010)
Plan for RBS (SharePoint Foundation 2010)

Other Resources

How to: Enable FILESTREAM
Resource Center: Installation and Deployment for SharePoint Foundation 2010


Configure services (SharePoint Foundation 2010)
See Also

In Microsoft SharePoint Foundation 2010, individual services can be configured independently, and you can implement only the services that your organization needs. For information about how to start, stop, and configure services, see Manage services on the server (SharePoint Foundation 2010).

Services that are deployed are named service applications. A service application provides a resource that can be shared across sites within a farm or sometimes across multiple farms, and can be accessed by users through a hosting Web application. Service applications are associated to Web applications by service application connections. For more information about managing and publishing service applications, see Service application and service management (SharePoint Foundation 2010).

For more information about service applications and services, see Technical diagrams (SharePoint Foundation 2010).

Note:

If you plan to use Office Web Apps, you must install and configure them to work with SharePoint 2010 Products. For more information, see Office Web Apps (Installed on SharePoint 2010 Products).

This section contains the following articles:

  • Service application and service management (SharePoint Foundation 2010)

    This article discusses the structures of service applications and services in Microsoft SharePoint Foundation 2010, and explains how service applications and services can be managed.

  • Configure the security token service (SharePoint Foundation 2010)

    This article provides guidance to help you to configure the Microsoft SharePoint Foundation 2010 security token service (STS). An STS is a specialized Web service that is designed to respond to requests for security tokens and provide identity management.

See Also

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010


Service application and service management (SharePoint Foundation 2010)
See Also

Articles in this section discuss the structures of service applications and services in Microsoft SharePoint Foundation 2010, and explain how service applications and services can be managed. These articles are for farm administrators and service application administrators who will operate SharePoint Foundation 2010.

In This Section

  • About service applications and services (SharePoint Foundation 2010)

    Provides an introduction to the logical infrastructure of service applications and services.

  • Service application and service management (SharePoint Foundation 2010)

    Describes how to manage, create, configure, and share service applications.

  • Manage services on the server (SharePoint Foundation 2010)

    Describes how services can be started, stopped, and configured.

See Also

Concepts

Web applications management (SharePoint Foundation 2010)
Technical diagrams (SharePoint Foundation 2010)


Configure the security token service (SharePoint Foundation 2010)
See Also

This article provides guidance to enable you to configure the Microsoft SharePoint Foundation 2010 security token service (STS). An STS is a specialized Web service that is designed to respond to requests for security tokens and provide identity management. The core functionality of every STS is the same, but the nature of the tasks that each STS performs depends on the role the STS plays in relation to the other STS Web services in your design.

In this article:

  • How Web applications that use an STS work

  • Configure a SharePoint claims-based Web application by using Windows PowerShell

  • Edit bindings

  • Configure a Web application that uses an STS

How Web applications that use an STS work

Web applications that use a security token service handle requests to issue, manage, and validate security tokens. Security tokens consist of a collection of identity claims (such as a user's name, role, or an anonymous identifier). Tokens can be issued in different formats, such as Security Assertion Markup Language (SAML) tokens. Security tokens can be protected with an X.509 certificate to protect the token's contents in transit and to enable validation of trusted issuers. For additional information about the Security Token Service, see Plan authentication methods (SharePoint Foundation 2010).

An Identity Provider-STS (IP-STS) is a Web service that handles requests for trusted identity claims. An IP-STS uses a database called an identity store to store and manage identities and their associated attributes. The identity store for an identity provider may be a simple, such as a SQL database table. An IP-STS may also use a complex identity store, such as Active Directory Domain Services (AD DS) or Active Directory Lightweight Directory Service (AD LDS).

An IP-STS is available to clients who want to create and manage identities, and to relying party applications that must validate identities presented to them by clients. Each IP-STS has a federated trust relationship with, and issues tokens to, federation partner Relying Party STS Web applications, each of which are referred to as an RP-STS. Clients can create or provision managed Information Cards (using a card selector such as CardSpace) that represent identities registered with the IP-STS. Clients interact with the IP-STS when they request security tokens that represent an identity that is contained in the identity store of the IP-STS. After authentication, the IP-STS issues a trusted security token that the client can present to a relying party application. Relying party applications can establish trust relationships with an IP-STS. This enables them to validate the security tokens issued by an IP-STS. After the trust relationship is established, relying party applications can examine security tokens presented by clients and determine the validity of the identity claims they contain.

A relying party STS (RP-STS) is an STS that receives security tokens from a trusted federation partner IP-STS. In turn, the RP-STS issues new security tokens to be consumed by a local relying party application. The use of RP-STS Web applications in federation with IP-STS Web applications enables organizations to offer Web single-sign-on (SSO) to users from partner organizations. Each organization continues to manage its own identity stores.

Configure a SharePoint claims-based Web application by using Windows PowerShell

Perform the following procedures to use Windows PowerShell to configure a SharePoint claims-based Web application.

To configure a SharePoint claims-based Web application 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:\>), create an x509Certificate2 object, as shown in the following example:

    Copy Code
    $cert = New-Object
System.Security.Cryptography.X509Certificates.X509Certificate2("path to cert file")

  6. Create a claim type mapping to use in your trusted authentication provider, as shown in the following example:

    Copy Code
    New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
-IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

  7. Create a trusted login provider by first creating a value for the realm parameter, as shown in the following example:

    Copy Code
    $realm = "urn:" + $env:ComputerName + ":domain-int"

  8. Create a value for the signinurl parameter that points to the Security Token Service Web application, as shown in the following example:

    Copy Code
    $signinurl = "https://test-2/FederationPassive/"

  9. Create the trusted login provider, using the same IdentifierClaim value as in a claim mapping ($map1.InputClaimType), as shown in the following example:

    Copy Code
    $ap = New-SPTrustedIdentityTokenIssuer -Name
"WIF" -Description "Windows® Identity Foundation" -Realm
$realm -ImportTrustCertificate $cert
-ClaimsMappings $map1[,$map2..] -SignInUrl
$signinurl -IdentifierClaim $map1.InputClaimType

  10. Create a Web application by first creating a value for the application pool account (for the current user), as shown in the following example:

    Copy Code
    $account = "DOMAIN\" + $env:UserName
    Note:

    The application pool account must be a managed account. To create a managed account, use New-SPManagedAccount.

  11. Create a value for the Web application URL ($webappurl = "https://" + $env:ComputerName), as shown in the following example:

    Copy Code
    $wa = New-SPWebApplication -name "Claims WIF"
-SecureSocketsLayer -ApplicationPool "SharePoint SSL"
-ApplicationPoolAccount $account -Url $webappurl -Port 443
-AuthenticationProvider $ap

  12. Create a site by first creating a claim object, as shown in the following example:

    Copy Code
    $claim = New-SPClaimsPrincipal
-TrustedIdentityTokenIssuerr $ap -Identity
$env:UserName

  13. Create a site, as shown in the following example:

    Copy Code
    $site = New-SPSite $webappurl -OwnerAlias
$claim.ToEncodedString() -template "STS#0"

Edit bindings

After you have configured a SharePoint claims-based Web application, edit the bindings.

To edit bindings

  1. Start IIS Manager by typing INETMGR at a command prompt.

  2. Go to the Claims Web Application site in IIS.

  3. In the left pane, right-click Claims Web Application, and select Edit Bindings.

  4. Select https and click Edit.

  5. Under SSL Certificate, select any listed certificate.

Configure a Web application that uses an STS

After you have configured a SharePoint Foundation 2010 claims-based Web application, edited the bindings and configured the Web.Config file, you can use the procedure in this section to configure a Security Token Service Web application.

To configure a Web application that uses an STS

  1. Open the Active Directory Federation Services (AD FS) s2.0Management console.

  2. In the left pane, expand Policy, and select Relying Parties.

  3. In the right pane, click Add Relying Party. This opens the Active Directory Federation Services (AD FS) 2.0 configuration wizard.

  4. On the first page of the wizard, click Start.

  5. Select Enter relying party configuration manually, and click Next.

  6. Type a relying party name and click Next.

  7. Make sure Active Directory Federation Services (AD FS) 2.0 Server Profile is selected, and click Next.

  8. If you are not planning to use an encryption certificate, click Next.

  9. Select Enable support for Web-browser-based identity federation.

  10. Type the name of the Web application URL, and append /_trust/ (for example: https://servername/_trust/). Click Next.

  11. Type an identifier, and click Add. Click Next.

  12. On the Summary page, click Next and then click Close. This opens the Rules Editor Management console. Use this console to configure the mapping of claims from an LDAP Web application to SharePoint.

  13. In the left pane, expand New Rule, and select Predefined Rule.

  14. Select Create Claims from LDAP Attribute Store.

  15. In the right pane, from the Attribute Store drop-down list, select Enterprise Active Directory User Account Store.

  16. Under LDAP Attribute, select sAMAccountName.

  17. Under Outgoing Claim Type, select E-Mail Address.

  18. In the left pane, click Save.

See Also

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010
Resource Center: Security and Authentication for SharePoint Foundation 2010


Prepare to host sites (SharePoint Foundation 2010)

After you have installed Microsoft SharePoint Foundation 2010 and performed the initial configuration, you can begin to create SharePoint sites. Before you create a site collection, you must first create a Web application in which to create the site collection. If you want to use Kerberos authentication or claims-based authentication, you must also configure Web application authentication.

The articles in this section help you determine the hierarchy of your SharePoint sites.

  • Create a Web application (SharePoint Foundation 2010)

    SharePoint sites are hosted by Web applications, so you must create one or more Web applications before you can create any sites. This article covers how to create a Web application from the Central Administration Web site or by using Windows PowerShell 2.0.

  • Configure claims authentication (SharePoint Foundation 2010)

    This article describes how to configure a SharePoint Foundation 2010 claims-based Web application that will provide a claims-based sign-in and services infrastructure for your farm. The article also describes how to configure anonymous access for your claims-based Web application and how to configure your Web application zones for forms-based authentication or Web SSO authentication, as appropriate.

  • Create a site collection (SharePoint Foundation 2010)

    After you have created a Web application, you can create a site collection. This article helps you create a site collection from the Central Administration Web site or by using Windows PowerShell 2.0. If you want to enable users to create their own sites, you need to configure self-service site management for the Web application.


Create a Web application (SharePoint Foundation 2010)
See Also

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

SharePoint Foundation 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. For more information, see Create a Web application that uses Windows-classic authentication (SharePoint Foundation 2010).

  • 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, see Create a Web application that uses Windows-claims authentication (SharePoint Foundation 2010).

  • Although digest authentication provides the same functionality as basic authentication, digest authentication encrypts user credentials to increase security. User credentials are sent as an MD5 message digest in which the original user name and password cannot be deciphered. For more information about Digest authentication, see Configure Digest authentication for a classic-mode Web application (SharePoint Foundation 2010)

  • Zones represent different logical paths for gaining access to the network services that are available within the same Web application. In some instances, you might want to configure Basic authentication for one or more zones within a Microsoft SharePoint Foundation 2010 classic-mode Web application. For more information, see Configure Basic authentication for a classic-mode Web application (SharePoint Foundation 2010).

For more information about both types of authentication, see Plan authentication methods (SharePoint Foundation 2010).

SharePoint Foundation 2010 provides a set of services applications that are available for each Web application. You can select which service applications you want to use for each Web application that you create. For more information, see Technical diagrams (SharePoint Foundation 2010), Define managed paths (SharePoint Foundation 2010), and Service application and service management (SharePoint Foundation 2010).

In this section:

  • Create a Web application that uses Windows-classic authentication (SharePoint Foundation 2010)

  • Create a Web application that uses Windows-claims authentication (SharePoint Foundation 2010)

See Also

Concepts

Extend a Web application (SharePoint Foundation 2010)
Create a site collection (SharePoint Foundation 2010)

Other Resources

Configure Web Server Security (IIS 7)
Resource Center: Installation and Deployment for SharePoint Foundation 2010
Resource Center: Security and Authentication for SharePoint Foundation 2010


Create a Web application that uses Windows-classic authentication (SharePoint Foundation 2010)
See Also

Published: October 7, 2010

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 Foundation 2010).

Before you perform this procedure, confirm that:

  • Your system is running Microsoft SharePoint Foundation 2010.

  • You have your logical architecture design in place.

  • You have planned authentication for your Web application. For more information, see Plan authentication methods (SharePoint Foundation 2010), Plan for Kerberos authentication (SharePoint Foundation 2010) and Choose security groups (SharePoint Foundation 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 Foundation 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/p/?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.

    1. In the Authentication Provider section, click Negotiate (Kerberos) or NTLM.

      Note:

      To enable Kerberos authentication, you must perform additional configuration. For more information, see Plan for Kerberos authentication (SharePoint Foundation 2010).

    2. In the Allow Anonymous section, click Yes or No. If you choose to allow anonymous access, this enables anonymous access to the Web site by using the computer-specific anonymous access account (that is, IIS_IUSRS).

      Note:

      If you want users to be able to access any site content anonymously, you must enable anonymous access for the entire Web application zone before you enable anonymous access at the SharePoint site level; later, site owners can configure how anonymous access is used within their sites. If you do not enable anonymous access at the Web application level, you cannot enable anonymous access later, at the site level. For more information, see Choose security groups (SharePoint Foundation 2010).

    3. 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/p/?LinkId=187887).

  10. 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 Foundation 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 Foundation 2010).

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

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

  13. In the Database Name and Authentication section, choose the database server, database name, and authentication method for your new Web application, as described in the following table.

    Item Action

    Database Server

    Type the name of the database server and Microsoft SQL Server instance you want to use in the format <SERVERNAME\instance>. You can also use the default entry.

    Database Name

    Type the name of the database, or use the default entry.

    Database Authentication

    Select the database authentication to use by doing one of the following:

    • If you want to use Windows authentication, leave this option selected. We recommend this option because Windows authentication automatically encrypts the password when it connects to SQL Server.

    • If you want to use SQL authentication, click SQL authentication. In the Account box, type the name of the account you want the Web application to use to authenticate to the SQL Server database, and then type the password in the Password box.

      Note:

      SQL authentication sends the SQL authentication password to the SQL Server unencrypted. We recommend that you only use SQL authentication if you force protocol encryption to the SQL Server of encrypt your network traffic by using IPsec.

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

  15. In the Search Server section, under Select Microsoft SharePoint Foundation search server, you associate a content database with a server that is running the Microsoft SharePoint Foundation Search service.

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

  17. In the Customer Experience Improvement Program section, click Yes or No.

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

    Copy Code
    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

      Copy Code
      New-SPWebApplication -Name "Contoso Internet Site" -ApplicationPool "ContosoAppPool" -ApplicationPoolAccount (Get-SPManagedAccount "DOMAIN\jdoe") -Port 80 -URL "http://www.contoso.com"

For more information, see New-SPWebApplication.

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.

See Also

Concepts

Extend a Web application (SharePoint Foundation 2010)
Create a site collection (SharePoint Foundation 2010)
Create a Web application that uses Windows-claims authentication (SharePoint Foundation 2010)

Other Resources

Configure Web Server Security (IIS 7)


Create a Web application that uses Windows-claims authentication (SharePoint Foundation 2010)
See Also

This article describes how to create a Web application that uses Windows-claims authentication.

Tip:

If you want to use Windows-classic authentication instead, see Create a Web application that uses Windows-classic authentication (SharePoint Foundation 2010).

Before you perform this procedure, confirm that:

  • Your system is running Microsoft SharePoint Foundation 2010.

  • You have your logical architecture design in place.

  • You have planned authentication for your Web application. For more information, see Plan authentication methods (SharePoint Foundation 2010), Plan for Kerberos authentication (SharePoint Foundation 2010) and Choose security groups (SharePoint Foundation 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 Foundation 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/p/?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).

    1. Under Allow Anonymous, click Yes or No. If you choose to allow anonymous access, this enables anonymous access to the Web site by using the computer-specific anonymous access account (that is, IIS_IUSRS).

      Note:

      If you want users to be able to access any site content anonymously, you must enable anonymous access for the entire Web application zone before you enable anonymous access at the SharePoint site level; later, site owners can configure how anonymous access is used within their sites. If you do not enable anonymous access at the Web application level, you cannot enable anonymous access later, at the site level. For more information, see Choose security groups (SharePoint Foundation 2010).

    2. 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/p/?LinkId=187887).

  10. In the Claims Authentication Types section, select the authentication that you want to use for the Web application.

    1. 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 Plan for Kerberos authentication (SharePoint Foundation 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 Foundation 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.

    2. 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 Foundation 2010).

      Note:

      If you select this option, ensure that SSL is enabled; otherwise, the credentials can be intercepted by a malicious user.

    3. 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 Foundation 2010).

    You can use one or more claims authentication types. For more information, see Plan authentication methods (SharePoint Foundation 2010).

  11. In the Sign In Page URL section, choose one of the following options to sign into SharePoint Foundation 2010:

    • Select Default Sign In Page URL if you want users to be redirected to a default sign-in Web site for claims-based authentication.

    • Select Custom Sign In page URL and then type the sign-in URL if you want users to be redirected to a customized sign-in Web site for claims-based authentication.

  12. 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 Foundation 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 Foundation 2010).

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

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

  15. In the Database Name and Authentication section, choose the database server, database name, and authentication method for your new Web application as described in the following table.

    Item Action

    Database Server

    Type the name of the database server and Microsoft SQL Server instance you want to use in the format <SERVERNAME\instance>. You can also use the default entry.

    Database Name

    Type the name of the database, or use the default entry.

    Database Authentication

    Select the database authentication to use by doing one of the following:

    • If you want to use Windows authentication, leave this option selected. We recommend this option because Windows authentication automatically encrypts the password when it connects to SQL Server.

    • If you want to use SQL authentication, click SQL authentication. In the Account box, type the name of the account you want the Web application to use to authenticate to the SQL Server database, and then type the password in the Password box.

      Note:

      SQL authentication sends the SQL authentication password to the SQL Server unencrypted. We recommend that you only use SQL authentication if you force protocol encryption to the SQL Server of encrypt your network traffic by using IPsec.

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

  17. In the Search Server section, under Select SharePoint Foundation search server, you associate a content database with a server that is running the Microsoft SharePoint Foundation Search service.

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

  19. In the Customer Experience Improvement Program section, click Yes or No.

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

    Copy Code
    $ap = New-SPAuthenticationProvider

    To create a Web application that uses Windows-claims authentication, at the Windows PowerShell command prompt, type the following command:

    Copy Code
    $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

      Copy Code
      $ap = New-SPAuthenticationProvider
      Copy Code
      $wa = New-SPWebApplication -Name "Contoso Internet Site" -ApplicationPool "ContosoAppPool" -ApplicationPoolAccount (Get-SPManagedAccount "DOMAIN\jdoe") -URL "http://www.contoso.com" -Port 80 -AuthenticationProvider $ap

For more information, see New-SPWebApplication and New-SPAuthenticationProvider.

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.

See Also

Concepts

Extend a Web application (SharePoint Foundation 2010)
Create a site collection (SharePoint Foundation 2010)
Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010)
Configure authentication using a SAML security token (SharePoint Foundation 2010)
Create a Web application that uses Windows-classic authentication (SharePoint Foundation 2010)

Other Resources

Configure Web Server Security (IIS 7)


Configure Digest authentication for a classic-mode Web application (SharePoint Foundation 2010)
See Also

Published: January 20, 2011

This article describes how to configure digest authentication for one or more zones within a Microsoft SharePoint Foundation 2010 classic-mode Web application. A Web application is an IIS Web site that SharePoint Foundation 2010 creates and uses. Zones represent different logical paths for gaining access to the same Web application. Within each Web application, you can create up to five zones. A different Web site in IIS represents each zone. Use zones to enforce different access and policy conditions for large groups of users. To configure digest authentication for one or more zones in a SharePoint Foundation 2010 Web application, use the IIS Management Console to directly configure IIS.

Although digest authentication provides the same functionality as basic authentication, digest authentication encrypts user credentials to increase security. User credentials are sent as an MD5 message digest in which the original user name and password cannot be deciphered. Digest authentication uses a challenge/response protocol that requires the authentication requestor to present valid credentials in response to a challenge from the server. To authenticate against the server, the client has to supply an MD5 message digest in a response that contains a shared secret password string. The MD5 Message-Digest Algorithm is described in detail in RFC 1321. For access to RFC 1321, see The Internet Engineering Task Force (http://go.microsoft.com/fwlink/p/?LinkId=159913).

To use digest authentication, note the following requirements:

  • The user and IIS server must be members of, or trusted by, the same domain.

  • Users must have a valid Windows user account stored in Active Directory Domain Services (AD DS) on the domain controller.

  • The domain must use a Microsoft Windows Server 2008 domain controller.

Configure IIS to enable digest authentication

Use the IIS Management Console to configure IIS to enable digest authentication for one or more of the following zones for a classic-mode Web application:

Note:

The Default zone is the zone that is first created when a Web application is created. The other zones are created by extending a Web application.

  • Default

  • Intranet

  • Extranet

To configure IIS to enable digest authentication

  1. Verify that you have one of the following administrative credentials:

    • You must be a member of the Administrators group on the server on which you are configuring IIS.

  2. On the Start menu, point to All Programs, click Administrative Tools, and then click Internet Information Services (IIS) Manager to start the IIS Management Console.

  3. Expand Sites on the console tree, right-click the IIS Web site that corresponds to the Web application zone on which you want to configure digest authentication.

  4. In Features View, double-click Authentication.

  5. On the Authentication page, select Digest Authentication.

  6. In the Actions pane, click Enable to use Digest authentication with the default settings.

  7. In the Actions pane, click Edit to enter a realm name.

  8. In the Edit Digest Authentication Settings dialog box, in the Realm text box, type the appropriate realm and click OK.

At this point, the Web site is configured to use digest authentication.

See Also

Other Resources

What is Digest Authentication? (http://go.microsoft.com/fwlink/p/?LinkId=209085)


Configure Basic authentication for a classic-mode Web application (SharePoint Foundation 2010)
See Also

Published: January 27, 2011

This article describes how to configure Basic authentication for one or more zones within a Microsoft SharePoint Foundation 2010 classic-mode Web application. A Web application is an Internet Information Services (IIS) Web site that SharePoint Foundation 2010 creates and uses. Zones represent different logical paths for gaining access to the network services that are available within the same Web application. Within each Web application, you can create up to five zones. A different Web site in IIS represents each zone. Use zones to enforce different access and policy conditions for large groups of users. To configure Basic authentication for one or more zones in a SharePoint Foundation 2010 Web application, use the IIS Management Console to directly configure IIS.

Basic authentication requires previously assigned Windows account credentials for user access. Basic authentication enables a Web browser to provide credentials when the browser makes a request during an HTTP transaction. Because user credentials are not encrypted for network transmission but are sent over the network in plaintext, we recommend that you do not use Basic authentication over an unsecured HTTP connection. To use Basic authentication, you should enable Secure Sockets Layer (SSL) encryption.

Configure IIS to enable Basic authentication

Use the IIS Management Console to configure IIS to enable Basic authentication for one or more of the following zones for a claims-based Web application:

Note:

The Default zone is the zone that is first created when a Web application is created. The other zones are created by extending a Web application.

  • Default

  • Intranet

  • Extranet

To configure IIS to enable Basic authentication

  1. Verify that you have one of the following administrative credentials:

    • You must be a member of the Administrators group on the server on which you are configuring IIS.

  2. On the Start menu, point to All Programs, click Administrative Tools , and then click Internet Information Services (IIS) Manager to start the IIS Management Console.

  3. Expand Sites on the console tree, right-click the IIS Web site that corresponds to the Web application zone on which you want to configure Basic authentication.

  4. In Features View, double-click Authentication.

  5. On the Authentication page, select Basic Authentication.

  6. In the Actions pane, click Enable to use Basic authentication with the default settings.

  7. In the Actions pane, click Edit to enter a realm name.

  8. In the Edit Basic Authentication Settings dialog box, in the Realm text box, type the appropriate realm and click OK.

At this point, the Web site is configured to use Basic authentication.

Download this book

This topic is included in the following downloadable book for easier reading and printing:

  • Deployment for SharePoint Foundation 2010

See the full list of available books at Downloadable books for SharePoint Foundation 2010.

See Also

Concepts

Create a Web application that uses Windows-classic authentication (SharePoint Foundation 2010)


Configure claims authentication (SharePoint Foundation 2010)
See Also

In this section:

  • Create a Web application that uses Windows-claims authentication (SharePoint Foundation 2010)

  • Configure anonymous access for a claims-based Web application (SharePoint Foundation 2010)

  • Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010)

  • Configure Kerberos authentication for the claims to Windows token service (SharePoint Foundation 2010)

  • Configure authentication using a SAML security token (SharePoint Foundation 2010)

  • Configure claims authentication (SharePoint Foundation 2010)

  • Configure Digest authentication for a claims-based Web application (SharePoint Foundation 2010)

  • Configure Basic authentication for a claims-based Web application (SharePoint Foundation 2010)

  • Configure Client Certificate Authentication (SharePoint Foundation 2010)

See Also

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010


Configure anonymous access for a claims-based Web application (SharePoint Foundation 2010)
See Also

Administrators can configure anonymous access, which is not enabled by default, for a claims-based Web application.

This article is obsolete.

For information about how to configure anonymous access for a claims-based Web application, see Create a Web application that uses Windows-claims authentication (SharePoint Foundation 2010).

See Also

Concepts

Plan authentication methods (SharePoint Foundation 2010)
Choose security groups (SharePoint Foundation 2010)


Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010)
See Also

Procedures in this article illustrate how to configure a forms-based Web application to use an LDAP provider.

The procedures in this article provide guidance to enable you to configure forms-based authentication for a Microsoft SharePoint Foundation 2010 claims-based Web application. If you need to migrate an existing Windows SharePoint Services 3.0 Web application from forms-based authentication to claims-based authentication in SharePoint Foundation 2010, see Migrate from forms-based authentication to claims-based authentication (SharePoint Foundation 2010).

  • Configure a forms-based Web application to use an LDAP provider by using Central Administration

  • Configure the LDAP Web.Config files

  • Configure a forms-based Web application to use an LDAP provider by using Windows PowerShell

Configure a forms-based Web application to use an LDAP provider by using Central Administration

Perform the steps in the following procedure to use Central Administration to configure forms-based authentication for a claims-based Web application.

To configure forms-based authentication for a claims-based Web application by using Central Administration

  1. Verify that the user account that is performing this procedure is a site collection administrator.

  2. In Central Administration, in the Application Management section, click Manage web applications.

  3. In the Contribute group of the ribbon, click New.

  4. In the Authentication section of the Create New Web Application dialog box, click Claims Based Authentication.

  5. In the Claims Authentication Types section, select Enable Forms Based Authentication (FBA).

  6. Type a membership provider name and a role manager name. In the example Web.Config file depicted in this article, the name of the membership provider is membership, and the name of the role manager is rolemanager.

  7. Click OK to create the Web application.

Configure the LDAP Web.Config files

After you have successfully created the Web application (described in the preceding procedure), modify the following Web.Config files:

  • The Central Administration Web application Web.Config file

  • The Security Token Service Web.Config file

  • The forms-based authentication claims-based Web application Web.Config file

To configure the Central Administration Web.Config file

  1. Start IIS Manager by typing INETMGR at a command prompt.

  2. Go to the SharePoint Central Administration site in IIS.

  3. Right-click SharePoint Central Administration and then click Explore.

  4. Open the Web.Config file.

  5. Find the <Configuration> <system.web> section and add the following entry:

Note:

The following example uses the SharePoint Server 2010 LDAP membership provider because SharePoint Foundation 2010 does not ship with an LDAP membership provider.

Copy Code
<membership defaultProvider="AspNetSqlMembershipProvider">
      <providers>
        <add name="membership"
             type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
             server="yourserver.com"
             port="389"
             useSSL="false"
             userDNAttribute="distinguishedName"
             userNameAttribute="sAMAccountName"
             userContainer="OU=UserAccounts,DC=internal,DC=yourcompany,DC= distinguishedName (of your userContainer)"
             userObjectClass="person"
             userFilter="(ObjectClass=person)"
             scope="Subtree"
             otherRequiredUserAttributes="sn,givenname,cn" />
      </providers>
    </membership>
    <roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider" >
      <providers>
        <add name="roleManager"
             type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
             server="yourserver.com"
             port="389"
             useSSL="false"
             groupContainer="DC=internal,DC=yourcompany,DC= distinguishedName (of your groupContainer)"
             groupNameAttribute="cn"
             groupNameAlternateSearchAttribute="samAccountName"
             groupMemberAttribute="member"
             userNameAttribute="sAMAccountName"
             dnAttribute="distinguishedName"
             groupFilter="((ObjectClass=group)"
             userFilter="((ObjectClass=person)"
             scope="Subtree" />
      </providers>
 </roleManager>
Important:

After you have added the preceding entry, save and close the Web.Config file.

To configure the Security Token Service Web.Config file

  1. Start IIS Manager by typing INETMGR at a command prompt.

  2. Go to the SharePoint Web Services site.

  3. Go to the SecurityTokenServiceApplication sub-site.

  4. Right-click SecurityTokenServiceApplication and then click Explore.

  5. Open the Web.Config file.

  6. Find the <Configuration> <system.web> section and add the following entry:

Copy Code
<membership>
      <providers>
        <add name="membership"
             type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
             server="yourserver.com"
             port="389"
             useSSL="false"
             userDNAttribute="distinguishedName"
             userNameAttribute="sAMAccountName"
             userContainer="OU=UserAccounts,DC=internal,DC=yourcompany,DC=com"
             userObjectClass="person"
             userFilter="(&amp;(ObjectClass=person))"
             scope="Subtree"
             otherRequiredUserAttributes="sn,givenname,cn" />
      </providers>
    </membership>
    <roleManager enabled="true" >
      <providers>
        <add name="rolemanager"
             type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
             server="yourserver.com"
             port="389"
             useSSL="false"
             groupContainer="DC=internal,DC=yourcompany,DC=com"
             groupNameAttribute="cn"
             groupNameAlternateSearchAttribute="samAccountName"
             groupMemberAttribute="member"
             userNameAttribute="sAMAccountName"
             dnAttribute="distinguishedName"
             groupFilter="(&amp;(ObjectClass=group))"
             userFilter="(&amp;(ObjectClass=person))"
             scope="Subtree" />
      </providers>
    </roleManager>
Important:

After you have added the preceding entry, save and close the Web.Config file.

To configure the forms-based authentication claims-based Web application Web.Config file

  1. Start IIS Manager by typing INETMGR at a command prompt.

  2. Go to the Claims Forms site.

  3. Right-click Claims Forms and then click Explore.

  4. Open the Web.Config file.

  5. Find the <Configuration> <system.web> section.

  6. Find the <membership defaultProvider="i"> section and add the following entry:

Copy Code
<add name="membership"
             type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
             server="yourserver.com"
             port="389"
             useSSL="false"
             userDNAttribute="distinguishedName"
             userNameAttribute="sAMAccountName"
             userContainer="OU=UserAccounts,DC=internal, DC=yourcompany,DC=com"
             userObjectClass="person"
             userFilter="(&amp;(ObjectClass=person))"
             scope="Subtree"
             otherRequiredUserAttributes="sn,givenname,cn" />

Find the <roleManager defaultProvider="c" enabled="true" cacheRolesInCookie="false"> section and add the following entry:

Copy Code
<add name="roleManager"
             type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
             server="yourserver.com"
             port="389"
             useSSL="false"
             groupContainer="DC=internal,DC=yourcompany,DC=com"
             groupNameAttribute="cn"
             groupNameAlternateSearchAttribute="samAccountName"
             groupMemberAttribute="member"
             userNameAttribute="sAMAccountName"
             dnAttribute="distinguishedName"
             groupFilter="(&amp;(ObjectClass=group))"
             userFilter="(&amp;(ObjectClass=person))"
             scope="Subtree" />
Important:

After you have added the preceding entry, save and close the Web.Config file.

Warning:

Do not overwrite any existing entries in this Web.Config file.

Configure a forms-based Web application to use an LDAP provider by using Windows PowerShell

Perform the steps in the following procedure to use Windows PowerShell to configure forms-based authentication for a claims-based Web application.

To configure a forms-based Web application to use an LDAP provider 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, type the following:

    Copy Code
    $ap = New-SPAuthenticationProvider -Name "ClaimsForms" -ASPNETMembershipProvider "membership" -ASPNETRoleProviderName "rolemanager"
$wa = New-SPWebApplication -Name "Claims Windows Web App" -ApplicationPool "Claims App Pool" -ApplicationPoolAccount "internal\appool"
  -Url http://servername -Port 80 -AuthenticationProvider $ap
    Note:

    The value of the ApplicationPoolAccount parameter must be a managed account on the farm.

  6. After you have successfully created an authentication provider and a Web application, modify the following Web.Config files by using the sample entries provided in the Configure the LDAP Web.Config files section of this article:

    • To configure the Central Administration Web.Config file

    • To configure the Security Token Service Web.Config file

    • To configure the forms-based authentication claims-based Web application Web.Config file

  7. After you have modified the Web.Config files, create a SPClaimsPrincipal and a site collection, as shown in the following example:

    Copy Code
    $cp = New-SPClaimsPrincipal -Identity "membership:SiteOwner" -IdentityType FormsUser
$sp = New-SPSite http://servername:port -OwnerAlias $cp.Encode() -Template "STS#0"

    For more information, see New-SPClaimsPrincipal.

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.

See Also

Concepts

Migrate from forms-based authentication to claims-based authentication (SharePoint Foundation 2010)

Other Resources

Resource Center: Security and Authentication for SharePoint Foundation 2010


Configure Kerberos authentication for the claims to Windows token service (SharePoint Foundation 2010)
See Also

The document also shows you how to configure Kerberos authentication end-to-end within your environment, including scenarios which use various service applications in Microsoft SharePoint Foundation 2010.

This article is obsolete.

For information about how to configure Kerberos authentication, see Configuring Kerberos Authentication for Microsoft SharePoint 2010 Products and Technologies (white paper). (http://go.microsoft.com/fwlink/p/?LinkID=197178) white paper.

See Also

Concepts

Plan authentication methods (SharePoint Foundation 2010)


Configure authentication using a SAML security token (SharePoint Foundation 2010)
See Also

The procedures in this article explain how to configure authentication using a Security Assertion Markup Language (SAML) security token for a Microsoft SharePoint Foundation 2010 claims-based Web application.

SAML sign-in is typically used in enterprise federation scenarios, for example, to provide access to a business partner. SAML sign-in is also deployed to provide access to internal users whose accounts reside in a domain that is not part of the forest that contains SharePoint Foundation 2010.

Before you configure authentication using a SAML security token for a SharePoint Foundation 2010 claims-based Web application, you must configure an identity provider that supports WS-Federation, such as Active Directory Federation Services (AD FS) 2.0. For information about configuring a server to run AD FS 2.0, see the AD FS 2.0 Deployment Guide (http://go.microsoft.com/fwlink/p/?LinkId=191723).

In this article:

  • Configure an Identity Provider STS (IP-STS) Web application by using Windows PowerShell

  • Configure a Relying Party STS (RP-STS) Web application

  • Establish a trust relationship with an Identity Provider STS (IP-STS) by using Windows PowerShell

  • Export the trusted IP-STS certificate by using Windows PowerShell

  • Define a unique identifier for claims mapping by using Windows PowerShell

  • Create a new SharePoint Web application and configure it to use SAML sign-in

Configure an Identity Provider STS (IP-STS) Web application by using Windows PowerShell

Perform the following procedures to use Windows PowerShell to configure a SharePoint claims-based Web application.

To configure an Identity Provider STS (IP-STS) Web application 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, create an x509Certificate2 object, as shown in the following example:

    Copy Code
    $cert = New-Object
System.Security.Cryptography.X509Certificates.X509Certificate2("path to cert file")

  6. Create a claim type mapping to use in your trusted authentication provider, as shown in the following example:

    Copy Code
    New-SPClaimTypeMapping "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
-IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

  7. Create a trusted login provider by first creating a value for the realm parameter, as shown in the following example:

    Copy Code
    $realm = "urn:" + $env:ComputerName + ":domain-int"

  8. Create a value for the signinurl parameter that points to the Security Token Service Web application, as shown in the following example:

    Copy Code
    $signinurl = "https://test-2/FederationPassive/"

  9. Create the trusted login provider, using the same IdentifierClaim value as in a claim mapping ($map1.InputClaimType), as shown in the following example:

    Copy Code
    $ap = New-SPTrustedIdentityTokenIssuer -Name
"WIF" -Description "Windows® Identity Foundation" -Realm
$realm -ImportTrustCertificate $cert
-ClaimsMappings $map1[,$map2..] -SignInUrl
$signinurl -IdentifierClaim $map1.InputClaimType

  10. Create a Web application by first creating a value for the application pool account (for the current user), as shown in the following example:

    Copy Code
    $account = "DOMAIN\" + $env:UserName
    Note:

    The application pool account must be a managed account. To create a managed account, use New-SPManagedAccount.

  11. Create a value for the Web application URL ($webappurl = "https://" + $env:ComputerName), as shown in the following example:

    Copy Code
    $wa = New-SPWebApplication -name "Claims WIF"
-SecureSocketsLayer -ApplicationPool "SharePoint SSL"
-ApplicationPoolAccount $account -Url $webappurl -Port 443
-AuthenticationProvider $ap

  12. Create a site by first creating a claim object, as shown in the following example:

    Copy Code
    $claim = New-SPClaimsPrincipal
-TrustedIdentityTokenIssuerr $ap -Identity
$env:UserName

  13. Create a site, as shown in the following example:

    Copy Code
    $site = New-SPSite $webappurl -OwnerAlias
$claim.ToEncodedString() -template "STS#0"

Configure a Relying Party STS (RP-STS) Web application

Use the procedure in this section to configure a relying-party STS Web application.

To configure a Relying Party STS (RP-STS) Web application

  1. Open the Active Directory Federation Services (AD FS) 2.0 Management console.

  2. In the left pane, expand Policy, and select Relying Parties.

  3. In the right pane, click Add Relying Party. This opens the Active Directory Federation Services (AD FS) 2.0 configuration wizard.

  4. On the first page of the wizard, click Start.

  5. Select Enter relying party configuration manually, and click Next.

  6. Type a relying party name and click Next.

  7. Make sure Active Directory Federation Services (AD FS) 2.0 Server Profile is selected, and click Next.

  8. Do not use an encryption certificate. Click Next.

  9. Select Enable support for Web-browser-based identity federation.

  10. Type the name of the Web application URL, and append /_trust/ (for example: https://servername/_trust/). Click Next.

  11. Type the name of an identifier (for example: urn:COMPUTERNAME:Geneva), and click Add. Click Next.

  12. On the Summary page, click Next and then click Close. This opens the Rules Editor Management console. Use this console to configure the mapping of claims from an LDAP Web application to SharePoint.

  13. In the left pane, expand New Rule, and select Predefined Rule.

  14. Select Create Claims from LDAP Attribute Store.

  15. In the right pane, from the Attribute Store drop-down list, select Enterprise Active Directory User Account Store.

  16. Under LDAP Attribute, select sAMAccountName.

  17. Under Outgoing Claim Type, select E-Mail Address.

  18. In the left pane, click Save.

Establish a trust relationship with an Identity Provider STS (IP-STS) by using Windows PowerShell

Use the procedure in this section to establish a trust relationship with an IP-STS.

To establish a trust relationship with an IP-STS 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, establish a trust relationship, as shown in the following example:

    Copy Code
    $waurl = "https://" + $env:ComputerName
$title = "SAML-Claims"

Export the trusted IP-STS certificate by using Windows PowerShell

Use the procedure in this section to export the certificate of the IP-STS with which you want to establish a trust relationship, and then copy the certificate to a location that Microsoft SharePoint Foundation 2010 can access.

To export the trusted IP-STS certificate 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, export the trusted IP-STS certificate, as shown in the following example:

    Copy Code
    $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\geneva.cer")

Define a unique identifier for claims mapping by using Windows PowerShell

Use the procedure in this section to define an e-mail address that will serve as a unique identifier for claims mapping. Typically, the administrator of the trusted STS will have to provide this information because only the owner of the STS knows which value in the token will be always unique for each user. Note that the administrator of the trusted STS can create a URI to represent the e-mail address.

To define a unique identifier for claims mapping 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, create a mapping, as shown in the following example:

    Copy Code
    $map = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

Create a new authentication provider

Use the procedure in this section to create a new authentication provider that the Web application will use.

To create a new authentication provider 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, create a new authentication provider, as shown in the following example. Note that the realm is the parameter used by the trusted STS to identify a specific SharePoint farm.

    Copy Code
    $realm = "urn:" + $env:ComputerName + ":Geneva"
$ap = New-SPTrustedIdentityTokenIssuer -Name "Geneva" -Description "Geneva" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map -SignInUrl "https://test-2/FederationPassive/" -IdentifierClaim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

Create a new SharePoint Web application and configure it to use SAML sign-in

In this step, you create and configure the Web application.

To create a new SharePoint Web application and configure it to use SAML sign-in 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, create a new SharePoint Web application and configure it to use SAML sign-in. Note that you must replace "WebAppUrl" and "domain\admin" with the valid values.

    Copy Code
    $wa = New-SPWebApplication -Name "SAML Sign-In" -SecureSocketsLayer -ApplicationPool "SAML Sign-In" -ApplicationPoolAccount "domain\admin" -
Url "WebAppUrl" -Port 443 -AuthenticationProvider $ap
    Note:

    You are enabling SSL, because with SAML sign-in, cookies are used as the single sign-on ticket for the user. This allows administrators to grant access to the SharePoint resources for the duration of the token without the need of re-authenticate the user. Without SSL, these cookies can be easily hijacked by a malicious user and be used to impersonate the original user.

When you have completed these procedures, create a SharePoint site and assign an owner. For information about creating a SharePoint site, see Create a site collection (SharePoint Foundation 2010).

See Also

Other Resources

Resource Center: Security and Authentication for SharePoint Foundation 2010


Configure claims-based authentication using Windows Live ID (SharePoint Foundation 2010)
See Also

Published: September 9, 2010

Claims-based authentication in Microsoft SharePoint Foundation 2010 can delegate authentication to the Windows Live ID Security Token Service (STS). This is important if you want to implement a scenario in which you use Windows Live ID for password management. The Windows Live ID service is configured as the identity provider for SharePoint Foundation 2010. A one-way, certificate-based trust relationship is established between SharePoint Foundation 2010 and the Windows Live ID service. When a user provides Windows Live ID credentials, the Windows Live ID service returns a Passport Unique Identity (PUID) and e-mail information encapsulated in a Security Assertion Markup Language (SAML) version 1.1 claims token. The Windows Live ID public key, which is part of Windows Live ID Metadata XML, encrypts this claims token.

For more information about Windows Live ID, refer to the following resources:

  • Introduction to Windows Live ID (http://go.microsoft.com/fwlink/?LinkId=201477)

  • Microsoft Federation Gateway (http://go.microsoft.com/fwlink/?LinkId=150843)

  • Windows Live Developer Center (http://go.microsoft.com/fwlink/?LinkId=191075)

The Windows Live ID cookie is cached on the client computer and sent to SharePoint Foundation 2010 by way of a POST response to a successful authentication request. SharePoint Foundation 2010 converts the Windows Live ID SAML token to a SharePoint Foundation 2010 SAML token. The PUID for the user is generated based on the user principal name (UPN) claim returned in the SAML token. This value is used throughout SharePoint Foundation 2010 to uniquely identify the user and perform access control. SharePoint Foundation 2010 can augment user tokens with additional claims by using a custom claims provider, which is configured in the SharePoint Foundation 2010 Web application. The SharePoint Foundation 2010 cookie is also returned to the client computer and cached for subsequent requests. When the Windows Live ID or SharePoint Foundation 2010 cookie expires, the user is redirected to a Windows Live ID server.

In this article:

  • Configure the Windows Live ID Security Token Service

  • Configure SharePoint for Windows Live ID authentication

  • Convert a Windows Live ID internal environment to a production environment

  • Create different types of SharePoint claims-based Web applications

  • Grant permissions to all Windows Live ID authenticated users

Configure the Windows Live ID Security Token Service

The WS-Federation protocol is implemented by the Windows Live ID service, and provides the infrastructure of the Live ID STS that is designated as a trusted identity provider. You can extract a Windows Live ID public certificate from a metadata XML X509Certificate node and save it to an Internet security certificate with a .cer file extension. If the metadata XML contains multiple X509Certificate nodes, you can use any of them. Provide read access to the SharePoint Foundation 2010 farm application pool account in Internet security certificate (.cer file).

Configure the Microsoft Services Manager (MSM) using the following values:

Value | Description
Domain Name | The domain name for which authentication requests to the Live ID STS will be generated. Use a Fully Qualified Domain Name (FQDN).
Default Return URL | The URL that the Windows Live ID STS will redirect a user to after successful authentication, for example: https://username.global.corp.contoso.com/_trust/default.aspx.
DNS Name | The unique identifier provided in an authentication request to the Windows Live ID STS. This unique identifier enables look-up functionality for the Default Return URL. The DNS Name must correspond to the realm value specified in Windows Live ID authentication request.
WRealm Parameter | The WRealm parameter must match the DNS field in the MSM Site configuration. The WRealm parameter must be created by using one of the following formats: sub.domain.top or Urn:domain:name.
Override Authentication Policy | Configure the Override Authentication Policy by using the following value: MBI_FED_SSL.

Configure SharePoint for Windows Live ID authentication

Use the procedures in this section to configure SharePoint Foundation 2010 for Windows Live ID authentication.

To configure SharePoint for Windows Live ID authentication 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:\>), define the realm value to match the DNS Name value specified in the Microsoft Services Manager. The realm value in Windows Live ID integration should correspond to the correct DNS name, as shown in the following example:

    Copy Code
    $realm = "urn:" + $env:ComputerName + ":ServerName"

  6. Get the PUID value of the account that you will use as the Farm Administrator account by first signing in to following Web site: Windows Live ID(https://accountservices.passport-int.net/?ru=https://accountservices.passport-int.net/Credentials.srf%3Fvv%3D750%26mkt%3DEN-US%26lc%3D1033&vv=750&mkt=EN-US&lc=1033&id=10), and then locating the Unique ID field on the Credentials page.

  7. Specify the PUID value using the following format: PUID@live.com.

  8. Locate one of the <X509Certificate> nodes in the following source: Metadata XML URL (https://nexus.passport-int.com/federationmetadata2/2007-06/federationmetadata.xml).

  9. Copy the contents of either of the two X509Certificate nodes, as shown in the following example:

    Copy Code
    MIICWzCCAcSgAwIBAgIJAJEzHoaEodSoMA0GCSqGSIb3DQEBBQUAMCkxJzAlBgNV
BAMTHkxpdmUgSUQgU1RTIFNpZ25pbmcgUHVibGljIEtleTAeFw0wODEwMzAyMjA5
MjNaFw0xMzEwMjkyMjA5MjNaMCkxJzAlBgNVBAMTHkxpdmUgSUQgU1RTIFNpZ25p
bmcgUHVibGljIEtleTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArz97XPae
GNAC4UnKl5zReyhgk3Bzf08U+CgD0R9+GZOahmpakJXFpI213gQWiHrUGaMN9nsK
4kzSfDPiquAMsV6vBYyWuPLZ0XrMzTAOV/WHSK3bCsYWWQZeH9Xn8G1Hkz+gQSC/
92lBbq9oBCZfLv3OlkobOmT8d+ldRKGU4pUCAwEAAaOBijCBhzAdBgNVHQ4EFgQU
VbJyIcGL0AjB4/Wm4DqUZux6uUkwWQYDVR0jBFIwUIAUVbJyIcGL0AjB4/Wm4DqU
Zux6uUmhLaQrMCkxJzAlBgNVBAMTHkxpdmUgSUQgU1RTIFNpZ25pbmcgUHVibGlj
IEtleYIJAJEzHoaEodSoMAsGA1UdDwQEAwIBxjANBgkqhkiG9w0BAQUFAAOBgQAO
/5vGfu+Vg1TKBuxsAIMqjqKXX7aRrANNZM/5ACdwAUtMDG/n8INoXgOKr851fbF6
4yBesmFjg2TbR8y0/ITAD+d+iyEpR7IO3/is9rWAj4ggbw8yqaDWn26eh3bAdoa+
p38qtqJHkUGF5vApeHiu6zO573bKs+nXcKVM8mNbjA==

  10. Paste the contents of either X509Certificate node into a new Notepad file and save the Notepad file with the following file name: LiveID-INT.cer.

  11. Configure the Windows Live ID certificate (extracted from metadata XML), as shown in the following example:

    Copy Code
    $certloc = "C:\LiveIDWithSAML\LiveID-INT.cer"

  12. Define a new trusted root authority in SharePoint Foundation 2010, as shown in the following example:

    Copy Code
    $rootcert = Get-PfxCertificate $certloc
New-SPTrustedRootAuthority "NewRootAuthority" -Certificate $rootcert | Out-Null

  13. Create an object with a Windows Live ID certificate, as shown in the following example:

    Copy Code
    $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certloc)

  14. Define the claim you will use as the unique identifier of the user. Map the UPN claim to the reserved claim name Identifier. The e-mail Address claim can also be mapped, as shown in the following example:

    Copy Code
    $map1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/claims/EmailAddress" -IncomingClaimTypeDisplayName "http://schemas.xmlsoap.org/claims/EmailAddress" -SameAsIncoming
$map2 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" -IncomingClaimTypeDisplayName "UPN" -LocalClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"

  15. Create a new SharePoint Foundation 2010 authentication provider for a new Web application, as shown in the following example:

    Copy Code
    $apSAML = New-SPTrustedIdentityTokenIssuer -Name "LiveID" -Description "LiveID" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1,$map2 -SignInUrl "https://login.live-int.com/login.srf" -IdentifierClaim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"

  16. Create a new SharePoint Foundation 2010 Web application to use with the authentication provider created in the previous step, as shown in the following example:

    Copy Code
    $waurl = https://" + $env:ComputerName - You might use FQDN url of your site here.
$title = "Site Title"
$waexe = New-SPWebApplication -Name $title -ApplicationPool $title -ApplicationPoolAccount $owner -Url $waurl -AuthenticationProvider
$scexe = New-SPSite $siteurl -Name $title -Description $title -Template 'STS#1' -OwnerAlias

  17. Start IIS Manager by typing INETMGR at a command prompt.

  18. Go to the Claims Web Application site in IIS.

  19. In the left pane, right-click Claims Web Application, and select Edit Bindings.

  20. Select https and click Edit.

  21. Under SSL Certificate, select any listed certificate. Consider using a self-signed certificate.

  22. Import the Windows Live ID public certificate to the Local computer, SharePoint Foundation 2010, and Trusted People folders.

Convert a Windows Live ID internal environment to a production environment

Use the procedures in this section to convert a Windows Live ID internal environment to a production environment.

To convert a Windows Live ID internal environment to a production environment

  1. Make sure the site is migrated to a production environment in MSM, and that compliance is complete. A compliance review is not required if the Windows Live ID environment in MSM is internal.

  2. Make sure that the authentication policy of the Windows Live ID production environment is configured with the following value: MBI_FED_SSL.

  3. Make sure that the Windows Live ID production environment uses HTTPS-based URLs because the production environment authentication policy is configured for SSL transport. The production environment sites send POST requests over SSL to https://login.live.com. In the SPTrustedIdentityTokenIssuer there is a Provider URI that should be the live login URI. Make sure the live logon URI is HTTPS-based.

  4. If the Windows Live ID claims provider is configured to use an e-mail address instead of a PUID, the production environment site should be in the Microsoft policy group. Be aware that this policy group is auto-approved for internal partners, and explicit approval is required for external partners.

Create different types of SharePoint claims-based Web applications

Use the procedures in this section to run a Windows PowerShell script to create different types of SharePoint Foundation 2010 claims-based Web applications.

To create different types of SharePoint claims-based Web applications 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, run the DeployLiveIdWithSAML script, as shown in the following example:

    Copy Code
    #.SYNOPSIS
#    Script for creating different types of claims web applications from the Windows PowerShell command line.
#.DESCRIPTION
#    Script will create ANON, WIN, FBA, MULTI, MIXED, SAML and combinations of these web applications.
#.NOTES
#    Script: ClaimsWA.ps1
#    Remark: The script will load/unload additional snap-ins depending on where it's being executed from.
#    Update: 1/15/2010 (v2.0)
#.PARAMETER type
#   Indicates the type of claims web app to create (see examples for full list of valid supported types)
#If not specified, this will default to ALL and each of the supported types of claims web apps will be created
#.PARAMETER port
#   Indicates the port number to create the web app on (See reserved ports at http://support.microsoft.com/kb/832017)
#If not specified, this will default to port 201 and will be incremented in sequence for multiple web apps
#.PARAMETER owner
#   Indicates the domain account that will be used for App Pool (should be registered as a SharePoint Server managed account)
#If not specified, this will default to logged on user and will use USERDOMAIN & USERNAME environment values
#.EXAMPLE
#   claimswa.ps1 WIN (create WIN-claims web app at port# 201 and use logged on user for app pool account)
#
#   Here are some more examples of HOWTO use the script:
#      claimswa.ps1 ANON (create ANON web app at port# 201)
#      claimswa.ps1 ANON/FBA 701 (create ANON/FBA web app at port# 701)
#      claimswa.ps1 FBA (create FBA web app at port# 201 using LDAP provider; default is REDMOND instance)
#      claimswa.ps1 FBA/IBM (create FBA web app at port# 201 using LDAP provider pointing to the IBM instance)
#      claimswa.ps1 FBA/SQL 851 (create forms-based authentication web app at port# 851 using SQL provider)
#      claimswa.ps1 WIN/FBA/MIXED 501 (create Windows/forms-based authentication mixed-mode web apps at port# 501)
#      claimswa.ps1 WIN/SAML/MULTI 901 (create Windows/SAML multi-auth web apps at port# 901)
#
#   Here is the full list of all the support TYPEs (combine options delimited with slash for your config):
#
#   Basic auth types:
#      WIN   : create Windows claims web application on the port# specified on command line
#      FBA   : create forms-based authentication claims web apps with the specified membership provider (SQL Server/LDAP listed below)
#      SAML  : create SAML-claims web application on the default HTTPS port# 443
#      ANON  : indicator switch for creating the web application to allow ANON mode
#   Complex auth types:
#      MULTI : create claims web application with multiple auth types using a single URL to access
#      MIXED : create claims web application with multiple auth types using multiple URLs to access
#   FBA membership/rolemanager providers
#      RED   : use the REDMOND domain LDAP provider; this is the default setting if a provider is not specified
#      SQL   : use the SQL Server provider for connecting to forms-based authentication web apps (connects to the ASPNETDB instance on ZADANG)
#      PPL   : use the PEOPLEDC domain LDAP provider that is a private domain used for testing PEOPLE features
#      SUN   : use the SUNOne LDAP provider in the PEOPLEDC domain which is used for profile import/sync testing
#      IBM   : use the IBM LDAP provider in the PEOPLEDC domain which is used for profile import/sync testing
#      NVL   : use the Novell LDAP provider in the PEOPLEDC domain which is used for profile import/sync testing

# TODO (no specific ETA for these updates):
#    1. Set the default IIS cert bindings for SAML web
#    2. Use IIS CMDlets instead of updating XML object
#    3. We should be able to define MixedMode base auth
#    4. Use the domain for logged on user for LDAP string
#    5. Do not attempt to write to CA/STS if running on WFE

# Define the args list that we will accept & work with
param ([string]$type, [int]$port, [string]$owner)

function main() {
    # Valid options list
    $auths  = @("WIN", "FBA", "SAML", "ANON")
    $extnd  = @("MULTI", "MIXED")
    $provs  = @("SQL", "RED", "PPL", "SUN", "IBM", "NVL")
    $optns  = @("APP", "FIX")
    $typeOK = $true

    # Do we have the minimum args data before we can proceed
    # I'm not doing extensive validation but at least minimum
    foreach ($arg in $type.split("/")) {
        if (($auths+$extnd+$optns+$provs) -notcontains $arg) {
            write-host -Fore Red "`nInvalid TYPE argument was specified; execution aborted!`nTo see a list of valid TYPEs, execute with -examples option`n"
            $typeOK=$false; break
        }
    }

    if ($typeOK) {
        $type = @($type.toupper().split("/") | Sort | Get-Unique)
        switch ($type.count) {
            1 {
                foreach ($arg in $type) {
                    if (($auths+$extnd+$optns) -notcontains $arg) {
                        write-host -Fore Red "`nInvalid AUTH argument was specified; execution aborted!`nTo see a list of valid AUTHs, execute with -examples option`n"
                        $typeOK=$false; break
                    }
                }
                if (($type -eq "MULTI") -or ($type -eq "MIXED")) {
                    $type += @("WIN", "FBA"); write-host -Fore Yellow "MULTI/MIXED auth combo not specified; defaulting to $type"
                }
                if ($type -eq "ANON") {
                    $type += @("WIN"); write-host -Fore Yellow "ANON auth combo not specified; defaulting to $type"
                }
            }

            2 {
                if ($type -contains "ANON") {
                    foreach ($arg in $type) {
                        if ($auths -notcontains $arg) {
                            write-host -Fore Red "`nInvalid ANON combo was specified; execution aborted!`nTo see a list of valid PROVIDERs, execute with -examples option`n"
                            $typeOK=$false; break
                        }
                    }
                }
                else {
                    $multiOK=$true
                    foreach ($arg in $type) {
                        if ($auth -notcontains $arg) {
                            $multiOK=$false; break
                        }
                    }
                    if ($multiOK) {$type += @("MULTI"); write-host -Fore Yellow "Multiple auth types specified; defaulting to $type"}
                }
            }
        }

        if (($type -contains "MULTI") -or ($type -contains "MIXED") -and ($type.count -lt 3)) {
            write-host -Fore Red "`nMULTI/MIXED option requires 2 base auth types be specified!`nTo see a list of valid TYPEs, execute with -examples option`n"
            $typeOK=$false
        }
    }

    if ($typeOK) {
        # We seem to have the TYPE argument, let's check the others

        if (-not $port) {
            if ($type -contains "SAML") {$port=443} else {$port=201}
            write-host -Fore Yellow "PORT not specified; defaulting to $port"
        }

        if (-not $owner) {
            $owner = $env:UserDomain + "\" + $env:UserName.tolower()
            write-host -Fore Yellow "OWNER not specified; defaulting to $owner"
        }

        #In case somebody attempts to execute this script in the regular PS/ISE console,
        #let's load the IIS/SP snap-in to ensure we have everything we need to work with
        Manage-SnapIns (1)

        # check what flavor of SERVER we're running
        $product = Get-SPProduct | Where-Object {$_.ProductName.contains("SharePoint Server 2010")};
        if ($product.ProductName.contains("Debug")) {$flavor="DEBUG"} else {$flavor="SHIP"}
        write-host -Fore Green "Detected $flavor flavor of MOSS installed on this farm!"

        if ($type -contains "APP") {
            Write-WEBConfigs 0 "APP"
        }
        elseif ($type -contains "FIX") {
            Fix-Environment
        }
        else {
            Create-WebApp $type $port
        }

        # We're done with the snap-ins, so let's unload them
        Manage-SnapIns (0)
    }
}

function Fix-Environment {
    # This is just a series of steps to clean up
    # Not recommended to use unless you know why!
    Remove-SPTrustedRootAuthority NewRootAuthority
    Remove-SPTrustedIdentityTokenIssuer ServerName

    # I need to add the other clean up stuff here...
}

# This is the core script block that creates the different web apps
function Create-WebApp ([string]$type, [int]$port) {
    $waurl = http://" + $env:ComputerName

    if ($type.contains("SAML")) { $waurl = $waurl.replace("http", "https") }
    $siteurl = $waurl + ":" + $port
    $title = "ClaimsWA-$port-" + $type.replace(" ","-")

    # Let's construct the WA/SC CMDlet call that we'll invoke later
    $waexe = "New-SPWebApplication -Name $title -ApplicationPool $title -ApplicationPoolAccount $owner -Url $waurl -AuthenticationProvider"
    $scexe = "New-SPSite $siteurl -Name $title -Description $title -Template 'STS#1' -OwnerAlias"

    write-host -Fore Cyan "`nSetting up $title on port $port now:"

    if ($type.contains("WIN")) {
        $apWIN = New-SPAuthenticationProvider -DisableKerberos:$true
        $cpWIN = New-SPClaimsPrincipal -Identity $owner -IdentityType 1
    }

    if ($type.contains("FBA")) {
        if ($type.contains("SQL")) {
            $membership="SQLms"; $rolemanager="SQLrm"; $identity = "sqlms:user1"
        }
        elseif ($type.contains("PPL")) {
            $membership="PPLms"; $rolemanager="PPLrm"; $identity = "pplms:fbauser1"
        }
        elseif ($type.contains("SUN")) {
            $membership="SUNms"; $rolemanager="SUNrm"; $identity = "sunms:fbauser1"
        }
        elseif ($type.contains("IBM")) {
            $membership="IBMms"; $rolemanager="IBMrm"; $identity = "ibmms:fbauser1"
        }
        elseif ($type.contains("NVL")) {
            $membership="NVLms"; $rolemanager="NVLrm"; $identity = "nvlms:fbauser1"
        }
        else {
            $membership="REDms"; $rolemanager="REDrm"; $identity = ("redms:$env:UserName").tolower()
        }

        $apFBA = New-SPAuthenticationProvider -ASPNETMembershipProvider $membership -ASPNETRoleProviderName $rolemanager;
        $cpFBA = New-SPClaimsPrincipal -Identity $identity -IdentityType 4
    }

    if ($type.contains("SAML")) {
        $realm = "urn:" + $env:ComputerName + ":ServerName"
        $user  = "000300008448E34D@live.com"
        $certloc = "C:\LiveIDWithSAML\LiveID-INT.cer"

        $rootcert = Get-PfxCertificate $certloc
        New-SPTrustedRootAuthority "NewRootAuthority" -Certificate $rootcert | Out-Null

       $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certloc)
       $map1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/claims/EmailAddress" -IncomingClaimTypeDisplayName "http://schemas.xmlsoap.org/claims/EmailAddress" -SameAsIncoming
       $map2 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" -IncomingClaimTypeDisplayName "UPN" -LocalClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"

       $apSAML = New-SPTrustedIdentityTokenIssuer -Name "LiveID" -Description "LiveID" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1,$map2 -SignInUrl "https://login.live-int.com/login.srf" -IdentifierClaim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"
       $cpSAML = New-SPClaimsPrincipal -TrustedIdentityTokenIssuer $apSAML -Identity $user.tolower()
    }

    if ($type.contains("WIN")) {
        $waexe += " `$apWIN"; $scexe += " `$cpWIN.ToEncodedString()"
    }
    elseif ($type.contains("FBA")) {
        $waexe += " `$apFBA"; $scexe += " `$cpFBA.ToEncodedString()"
    }
    else {
        $waexe += " `$apSAML -SecureSocketsLayer"; $scexe += " `$cpSAML.ToEncodedString()"
    }

    if ($type.contains("MULTI")) {
        if ($type.contains("WIN")) {
            if ($type.contains("FBA")) {
                $waexe += ",`$apFBA"; $scexe += " -SecondaryOwnerAlias `$cpFBA.ToEncodedString()"
            }
            if ($type.contains("SAML")) {
                $waexe += ",`$apSAML -SecureSocketsLayer"; if (!$scexe.contains("Secondary")) { $scexe += " -SecondaryOwnerAlias `$cpSAML.ToEncodedString()" }
            }
        }
        else {
            $waexe += ",`$apSAML -SecureSocketsLayer"; $scexe += " -SecondaryOwnerAlias `$cpSAML.ToEncodedString()"
        }
    }

    # Check if we're creating the ANON web apps
    if ($type.contains("ANON")) { $waexe += " -AllowAnonymousAccess" }

    $waexe += " -Port $port | Out-Null"; $scexe += " | Out-Null"

    write-host -Fore Cyan "Deploying app..." -noNewLine
    Invoke-Expression $waexe

    # We could do this with a simple if/else but there may be other auth types too
    if ($type.contains("WIN"))  { Create-UserPolicy $siteurl $cpWIN.ToEncodedString()  }
    if ($type.contains("FBA"))  { Create-UserPolicy $siteurl $cpFBA.ToEncodedString()  }
    if ($type.contains("SAML")) { Create-UserPolicy $siteurl $cpSAML.ToEncodedString() }

    write-host -Fore Cyan "Creating site..." -noNewLine
    Invoke-Expression $scexe

    # If this is the ANON web app, then set the root site access to entire web
    if ($type.contains("ANON")) { $web = Get-SPWeb $siteurl; $web.AnonymousState="On"; $web.Update() }

    # At this time, let's also check if it's going to be a MixedMode web app
    if ($type.contains("MIXED")) {
        # If it's a Mixed-Mode web app we need to extend the base app to another auth type too
        $port++; write-host -Fore Cyan "Extending port $port..." -noNewLine
        $waurl = $waurl.replace("https", "http")
        $waexe = "Get-SPWebApplication $siteurl | New-SPWebApplicationExtension -Name $title-Ext -Zone `"Intranet`" -URL $waurl -Port $port -AuthenticationProvider"
        if ($type.contains("WIN")) {
            if ($type.contains("FBA")) { $waexe += " `$apFBA" } else { $waexe += " `$apSAML" }
        }
        else {
            $waexe += " `$apSAML"
        }
        Invoke-Expression $waexe
    }

    # If we've created a FBA web app, then it's time to update the CA/STS/FBA web.config files
    if ($type.contains("FBA")) { Write-WEBConfigs 0 $port.tostring() }; write-host -Fore Cyan "done!"
}

function Create-UserPolicy ([string]$weburl, [string]$encodeduser) {
    $webapp = Get-SPWebApplication $weburl
    $policy = $webapp.Policies.Add($encodeduser, "ClaimsWA.ps1 User")
    $role = $webapp.PolicyRoles.GetSpecialRole([Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullControl)
    $policy.PolicyRoleBindings.Add($role)
    $webapp.Update()
}

function Write-WEBConfigs ([int]$begin, [string]$vroot) {
    # For now I'm using the XML object to load/save the config files
    # Eventually we should use the IIS:CMDlets from WebAdministration

    write-host -Fore Cyan "Writing WEBConfig..." -noNewLine
    #$filei = "\\back\scratch\suntoshs\backup\webconfigs.xml"
    $filei = "\\back\scratch\suntoshs\scripts\oobinstall\webconfigs.xml"

    $xmli = [xml](get-content $filei)
    $root = $xmli.get_DocumentElement()

    for ($j=$begin; $j -le 2; $j++) {
        if ($j -eq 0) {
            [void][reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint")
            $fileo = [Microsoft.SharePoint.Administration.SPAdministrationWebApplication]::Local.IisSettings.get_Item(0).Path.FullName + "\web.config"
        }
        elseif ($j -eq 1) {
            $fileo = $env:CommonProgramFiles + "\Microsoft Shared\Web Server Extensions\14\WebServices\SecurityToken\web.config"
            if ($flavor -eq "DEBUG") { $fileo = $fileo.replace("Shared", "Shared Debug") }
        }
        else {
            if ($vroot -ne "APP") { $fileo = $env:HomeDrive + "\inetpub\wwwroot\wss\VirtualDirectories\$vroot\web.config" }
        }

        $xmlo = [xml](get-content $fileo)
        $perf = $xmlo.CreateElement("clear")

        if ($flavor -eq "DEBUG") {
            $ship = $root.config[1].tokens.token[0].value
            $debug = $root.config[1].tokens.token[1].value
            $token = $root.config[0]["system.web"].membership.providers.add[0].type
            $root.config[0]["system.web"].membership.providers.add[0].SetAttribute("type", $token.replace($ship,$debug)) | Out-Null
            $token = $root.config[0]["system.web"].rolemanager.providers.add[0].type
            $root.config[0]["system.web"].rolemanager.providers.add[0].SetAttribute("type", $token.replace($ship,$debug)) | Out-Null
        }

        if ($j -eq 0) {
            # Update the CA web config
            if (-not $xmlo.SelectSingleNode("/configuration/connectionStrings")) {
                $xmlo.configuration["system.web"].membership.ParentNode.RemoveChild($xmlo.configuration["system.web"].membership) | Out-Null
                $xmlo.configuration["system.web"].roleManager.ParentNode.RemoveChild($xmlo.configuration["system.web"].roleManager) | Out-Null
                $xmlo.SelectSingleNode("/configuration").AppendChild($xmlo.ImportNode($root.config[0]["connectionStrings"], $true)) | Out-Null
                $xmlo.SelectSingleNode("/configuration/system.web").AppendChild($xmlo.ImportNode($root.config[0]["system.web"].membership, $true)) | Out-Null
                $xmlo.SelectSingleNode("/configuration/system.web/membership/providers").PrependChild($xmlo.ImportNode($perf, $true)) | Out-Null
                $xmlo.SelectSingleNode("/configuration/system.web").AppendChild($xmlo.ImportNode($root.config[0]["system.web"].rolemanager, $true)) | Out-Null
                $xmlo.SelectSingleNode("/configuration/system.web/roleManager/providers").PrependChild($xmlo.ImportNode($perf, $true)) | Out-Null
            }
        }
        elseif ($j -eq 1) {
            # Update the STS web config
            if (-not $xmlo.SelectSingleNode("/configuration/system.web")) {
                $xmlo.SelectSingleNode("/configuration").AppendChild($xmlo.ImportNode($root.config[0]["connectionStrings"], $true)) | Out-Null
                $xmlo.SelectSingleNode("/configuration").AppendChild($xmlo.ImportNode($root.config[0]["system.web"], $true)) | Out-Null
            }
        }
        else {
            # Update the FBA web config
            if ($vroot -ne "APP") {
                if ($type.contains("PPL")) {$provider=1} elseif ($type.contains("SUN")) {$provider=2} elseif ($type.contains("IBM")) {$provider=3} elseif ($type.contains("NVL")) {$provider=4} elseif ($type.contains("SQL")) {$provider=5} else {$provider=0}
                $xmlo.SelectSingleNode("/configuration").AppendChild($xmlo.ImportNode($root.config[0]["connectionStrings"], $true)) | Out-Null
                $xmlo.SelectSingleNode("/configuration/system.web/membership/providers").PrependChild($xmlo.ImportNode($root.config[0]["system.web"].membership.providers.add[$provider], $true)) | Out-Null
                $xmlo.SelectSingleNode("/configuration/system.web/membership/providers").PrependChild($xmlo.ImportNode($perf, $true)) | Out-Null
                $xmlo.SelectSingleNode("/configuration/system.web/roleManager/providers").PrependChild($xmlo.ImportNode($root.config[0]["system.web"].rolemanager.providers.add[$provider], $true)) | Out-Null
                $xmlo.SelectSingleNode("/configuration/system.web/roleManager/providers").PrependChild($xmlo.ImportNode($perf, $true)) | Out-Null
            }
        }
        $xmlo.Save($fileo)
    }
}

function Manage-SnapIns ([int]$action) {
    #The OWSTimer process always causes an update conflict (known bug) while
    #creating multiple web apps; let's temporarily shut it down until we're done

    if ($action -eq 1) { Stop-Service "SPTimerV4" }

    # We need to do this only if we're running on ISE so check it
    if ($host.name.contains("ISE")) {
        if ($action -eq 1) {
            write-host -Fore Yellow "Detecting host and loading dependent snap-ins..."
            # Add-PSSnapIn WebAdministration (later!)
            Add-PSSnapIn Microsoft.Sharepoint.PowerShell
        }
        else {
            write-host -Fore Yellow "Unloading dependent snap-ins loaded earlier on..."
            # Remove-PSSnapIn WebAdministration (later!)
            Remove-PSSnapIn Microsoft.Sharepoint.PowerShell
        }
    }
    if ($action -eq 0) {Start-Service "SPTimerV4"; write-host -Fore Yellow "`nAll done; if there were errors please research PS database for known issues!`n"}
}

main

  6. Start IIS Manager by typing INETMGR at a command prompt.

  7. Go to the Claims Web Application site in IIS.

  8. In the left pane, right-click Claims Web Application, and select Edit Bindings.

  9. Select https and click Edit.

  10. Under SSL Certificate, select any listed certificate. Consider using a self-signed certificate.

  11. Import the Windows Live ID public certificate to the Local computer, SharePoint Foundation 2010, and Trusted People folders.

  12. Perform IIS reset and browse the site URL.

Grant permissions to all Windows Live ID authenticated users

Use the procedures in this section to grant permissions to all Windows Live Id authenticated users.

To grant permissions to all Windows Live ID authenticated users

  1. Browse to the SharePoint Foundation 2010 site that you created and log on using the administrator account.

  2. On the Site Actions menu click Site Settings.

  3. In the Users and Permissions section, click Site Permissions.

  4. Click Site Name Visitors group, where Site Name is the name of the site.

  5. Click New, and then click Add Users.

  6. In the Grant Permissions window, click the browse icon.

  7. In the Select People and Groups window, click All Users, and then click All Users (LiveIDSTS) in the right pane.

  8. Click Add.

  9. Click OK.

  10. Verify that All Users (LiveIDSTS) is now part of the visitor's group. You should now be able to log on to the SharePoint Foundation 2010 site with any other Live ID user's credentials.

About the author

Birendra Acharya is a Senior Software Design Engineer for MSIT at Microsoft.

See Also

Other Resources

Understanding WS-Federation (http://go.microsoft.com/fwlink/p/?LinkId=192377)


Configure Digest authentication for a claims-based Web application (SharePoint Foundation 2010)
See Also

Published: January 20, 2011

This article describes how to configure digest authentication for one or more zones within a Microsoft SharePoint Foundation 2010 claims-based Web application. A Web application is an IIS Web site thatSharePoint Foundation 2010 creates and uses. Zones represent different logical paths for gaining access to the same Web application. Within each Web application, you can create up to five zones. A different Web site in IIS represents each zone. Use zones to enforce different access and policy conditions for large groups of users. To configure digest authentication for one or more zones in a SharePoint Foundation 2010 Web application, use the IIS Management Console to directly configure IIS.

Although digest authentication provides the same functionality as basic authentication, digest authentication encrypts user credentials to increase security. User credentials are sent as an MD5 message digest in which the original user name and password cannot be deciphered. Digest authentication uses a challenge/response protocol that requires the authentication requestor to present valid credentials in response to a challenge from the server. To authenticate against the server, the client has to supply an MD5 message digest in a response that contains a shared secret password string. The MD5 Message-Digest Algorithm is described in detail in RFC 1321. For access to RFC 1321, see The Internet Engineering Task Force (http://go.microsoft.com/fwlink/p/?LinkId=159913).

To use digest authentication, note the following requirements:

  • The user and IIS server must be members of, or trusted by, the same domain.

  • Users must have a valid Windows user account stored in Active Directory Domain Services (AD DS) on the domain controller.

  • The domain must use a Microsoft Windows Server 2008 domain controller.

Configure IIS to enable digest authentication

Use the IIS Management Console to configure IIS to enable digest authentication for one or more of the following zones for a claims-based Web application:

Note:

The Default zone is the zone that is first created when a Web application is created. The other zones are created by extending a Web application.

  • Default

  • Intranet

  • Extranet

To configure IIS to enable digest authentication

  1. Verify that you have one of the following administrative credentials:

    • You must be a member of the Administrators group on the server on which you are configuring IIS.

  2. On the Start menu, point to All Programs, click Administrative Tools , and then click Internet Information Services (IIS) Manager to start the IIS Management Console.

  3. Expand Sites on the console tree, right-click the IIS Web site that corresponds to the Web application zone on which you want to configure digest authentication.

  4. In Features View, double-click Authentication.

  5. On the Authentication page, select Digest Authentication.

  6. In the Actions pane, click Enable to use Digest authentication with the default settings.

  7. In the Actions pane, click Edit to enter a realm name.

  8. In the Edit Digest Authentication Settings dialog box, in the Realm text box, type the appropriate realm and click OK.

At this point, the Web site is configured to use digest authentication.

See Also

Other Resources

What is Digest Authentication? (http://go.microsoft.com/fwlink/p/?LinkId=209085)


Configure Basic authentication for a claims-based Web application (SharePoint Foundation 2010)

Published: January 20, 2011

This article describes how to configure basic authentication for one or more zones within a Microsoft SharePoint Foundation 2010 claims-based Web application. A Web application is an Internet Information Services (IIS) Web site that SharePoint Foundation 2010 creates and uses. Zones represent different logical paths for gaining access to the network services that are available within the same Web application. Within each Web application, you can create up to five zones. A different Web site in IIS represents each zone. Use zones to enforce different access and policy conditions for large groups of users. To configure basic authentication for one or more zones in a SharePoint Foundation 2010 Web application, use the IIS Management Console to directly configure IIS.

Basic authentication requires previously assigned Windows account credentials for user access. Basic authentication enables a Web browser to provide credentials when the browser makes a request during an HTTP transaction. Because user credentials are not encrypted for network transmission but are sent over the network in plaintext, we do not recommend using basic authentication over an unsecured HTTP connection. To use basic authentication, you should enable Secure Sockets Layer (SSL) encryption.

Configure IIS to enable basic authentication

Use the IIS Management Console to configure IIS to enable basic authentication for one or more of the following zones for a claims-based Web application:

Note:

The Default zone is the zone that is first created when a Web application is created. The other zones are created by extending a Web application.

  • Default

  • Intranet

  • Extranet

To configure IIS to enable basic authentication

  1. Verify that you have one of the following administrative credentials:

    • You must be a member of the Administrators group on the server on which you are configuring IIS.

  2. On the Start menu, point to All Programs, click Administrative Tools , and then click Internet Information Services (IIS) Manager to start the IIS Management Console.

  3. Expand Sites on the console tree, right-click the IIS Web site that corresponds to the Web application zone on which you want to configure Basic authentication.

  4. In Features View, double-click Authentication.

  5. On the Authentication page, select Basic Authentication.

  6. In the Actions pane, click Enable to use Basic authentication with the default settings.

  7. In the Actions pane, click Edit to enter a realm name.

  8. In the Edit Basic Authentication Settings dialog box, in the Realm text box, type the appropriate realm and click OK.

At this point, the Web site is configured to use basic authentication.

For information about creating a claims-based Web application in SharePoint Foundation 2010, see Create a Web application that uses Windows-claims authentication (SharePoint Foundation 2010).

If you want credentials of users to be sent over a network in a form that is not encrypted, select Basic authentication (password is sent in clear text).

Security Note:

You can select basic authentication or integrated Windows authentication, or both. If you select both, SharePoint Foundation 2010 will offer both authentication types to the client Web browser. The client Web browser then determines the 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.


Configure Client Certificate Authentication (SharePoint Foundation 2010)
See Also

Published: March 10, 2011

Client Certificate Authentication enables Web-based clients to establish their identity to a server and provides an additional layer of security for your network.

Note:

For more information about Client Certificate Authentication, see Certificate-based Authentication Protocols (http://go.microsoft.com/fwlink/p/?LinkId=212507).

Microsoft SharePoint Foundation 2010 does not provide built-in support for Client Certificate Authentication, but Client Certificate Authentication is available through integration with Active Directory Federation Services (AD FS) 2.0, or any third-party identity management system that supports standard security protocols such as claims-based authentication, WS-Trust, WS-Federation, and SAML 1.1.

Note:

For more information about SharePoint Foundation 2010 protocol requirements, see SharePoint Front-End Protocols (http://go.microsoft.com/fwlink/p/?LinkId=212509).

SharePoint Foundation 2010 makes it possible to use a variety of Security Token Services (STS) through claims-based authentication. If you use claims-based authentication and you configure AD FS 2.0 as your STS, SharePoint Foundation 2010 can support any Identity Provider that is trusted by AD FS 2.0, including Client Certificate Authentication.

Note:

For more information about AD FS 2.0, see Active Directory Federation Services Overview (http://go.microsoft.com/fwlink/p/?LinkId=212512).

In the following model, an administrator needs to configure SharePoint Foundation 2010 as a relying partner for an Identity Provider STS. (This example uses AD FS 2.0 for the STS, but you can also use a third-party STS.) AD FS 2.0 can authenticate user accounts via several different types of authentication methods: forms-based authentication, Active Directory Domain Services (AD DS), client certificates, and smart cards. When you configure SharePoint Foundation 2010 as a relying partner for an STS, SharePoint Foundation 2010 trusts the accounts that the STS validates, which is how SharePoint Foundation 2010 supports Client Certificate Authentication.

SharePoint Server 2010 with ADFS 2.0

Configure Client Certificate Authentication

The following topics explain how to configure SharePoint Foundation 2010 with Client Certificate authentication or Smart Card authentication by using AD FS 2.0 as your STS.

Note:

The required steps will be similar for a third-party STS.

  • Configure AD FS 2.0 or third-party STS to support CBA, and thereby Client Certificate authentication or Smart Card authentication.

    For information on making these configuration changes, see AD FS 2.0 - How to change the local authentication type (http://go.microsoft.com/fwlink/p/?LinkId=212513).

  • Configure SharePoint Foundation 2010 as relying party in AD FS 2.0 or third-party STS.

    For information on making these configuration changes using AD FS 2.0, see Configuring SharePoint 2010 and AD FS v2 End to End (http://go.microsoft.com/fwlink/p/?LinkID=207629).

  • Configure the Identity Provider STS, for example AD FS 2.0, inside SharePoint Foundation 2010 as a trusted identity provider.

    For information on making these configuration changes using AD FS 2.0, see Configure authentication using a SAML security token (SharePoint Server 2010).

  • Create a Web application that uses Claims-Based Authentication with a SAML security token, and thereby Client Certificate authentication or Smart Card authentication.

    For information on creating a Web application that uses SAML security tokens, see Configure authentication using a SAML security token (SharePoint Server 2010).

See Also

Concepts

Configure the security token service (SharePoint Foundation 2010)
Configure authentication using a SAML security token (SharePoint Foundation 2010)

Other Resources

Planning and Architecture: AD FS 2.0 (http://go.microsoft.com/fwlink/p/?LinkId=212521)
AD FS 2.0 Deployment Guide (http://go.microsoft.com/fwlink/p/?LinkId=212520)
Using Active Directory Federation Services 2.0 in Identity Solutions (http://go.microsoft.com/fwlink/p/?LinkID=209776)
Configure SharePoint as relying party in ADFS 2.0 or third-party STS (http://go.microsoft.com/fwlink/p/?LinkID=207629)


Create a site collection (SharePoint Foundation 2010)
See Also

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 Foundation 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, 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 Document Workspace template if you want to collaboratively author documents.

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 Foundation 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 Foundation 2010).

In this article:

Create a site collection by using Central Administration

Create a site collection by using Windows PowerShell

Create a site collection by using Central Administration

You typically use the Central Administration Web site to create a site collection in a stand-alone deployment.

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

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

See Also

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010


Deploy customizations - overview (SharePoint Foundation 2010)
See Also

The articles in this chapter describe how to deploy site elements that have been customized by developers or Web designers in a Microsoft SharePoint Foundation 2010 environment.

In this article:

  • Process overview

  • Before you begin

  • About the two kinds of customizable site elements

  • Deploying developed site elements

  • Deploying authored site elements

Process overview

Deploying customizations can be quite complex, particularly because there are many deployment methods available in SharePoint Foundation 2010, and the advantages of using one method over another are not always obvious.

You deploy these different types of site elements, or artifacts, by using different methods. You cannot deploy the full range of customizable site elements by using a single deployment method. There are other unique deployment considerations that apply to each type of element because they are likely to originate from different groups of designers, and because they are subject to different upgrade considerations. The different kinds of site elements are described in About the two kinds of customizable site elements, later in this article.

For specific deployment tasks and related considerations, see the following articles:

  • Deploy solution packages (SharePoint Foundation 2010)

  • Deploy authored site elements (SharePoint Foundation 2010)

  • Deploy site elements by using Features (SharePoint Foundation 2010)

  • Deploy templates (SharePoint Foundation 2010)

  • Workflow deployment process (SharePoint Foundation 2010)

Before you begin

Before you deploy any custom code to the environment, you should establish a baseline of the environment's performance so that you can analyze how customizations affect performance. After you have established a performance baseline, test the custom code thoroughly in a test or integration environment and compare the results with the baseline. Make sure that you thoroughly test all customizations before you deploy them to the production environment.

You should also test any code that you acquire from third parties before you deploy it to the production environment, even if you acquire it from a trusted source.

The descriptions and guidance in these articles apply to a SharePoint Foundation environment that has been deployed and configured to meet the requirements in Server farm and environment planning (SharePoint Foundation 2010).

About the two kinds of customizable site elements

Developed site elements are solution artifacts and are typically created by developers. A solution can include assemblies, which are SharePoint components that are written in Microsoft .NET Framework-based languages and compiled before being deployed. Developed site elements, except timer jobs assemblies and site definitions, are typically grouped into Features and deployed as part of a solution package. Developed site elements include:

  • Web Parts

  • Workflows

  • Site and list definitions

  • Document converters

  • Event receivers

  • Timer jobs

  • Assemblies

Authored site elements, which are typically created by Web designers, are not explicitly compiled and reside in a content database. Authored site elements include:

  • Master pages

  • Cascading style sheets

  • Forms

  • Layout pages

These two kinds of customizable site elements are differentiated by:

  • Where the files are stored in a SharePoint Foundation 2010 farm.

  • Which team in the organization is responsible for administering the site element.

  • What deployment mechanism the site element requires.

Some elements can be either solution artifacts or authored artifacts. For example, a content type can be defined in an XML file as a developed solution artifact, or created through a browser as an authored artifact. Site elements that can be solution artifacts or authored artifacts include site columns and list instances. Also, solution artifacts can be used to provision files into Web sites and set to be cached in memory on the front-end Web server.

Deploying developed site elements

Developed site elements can be generally defined as site elements that are created in a code-development environment and are deployed directly to front-end Web servers and application servers. These site elements are customized typically by developers by using Microsoft Visual Studio 2010 Tools for SharePoint 2010, Microsoft Office SharePoint Designer, or XML editing tools. For more information, see SharePoint Foundation Development Tools (http://go.microsoft.com/fwlink/p/?LinkId=183360).

Note:

This article does not discuss the deployment of developed site elements that are deployed as sandboxed solutions. Sandboxed solutions are solutions that can access a subset of the server object model and a subset of feature elements that site collection administrators can deploy. For more information, see Sandboxed solutions overview (SharePoint Foundation 2010).

A best practice is to use solution packages and Windows PowerShell to deploy developed site elements. The SharePoint Foundation Solution Framework simplifies and standardizes the process of deploying new and upgrade site elements across the farm and synchronizing a front-end Web server so that its state is consistent with the state of other servers in the farm. For example, solution packages simplify the process of rebuilding a farm. Deploying site elements by manually handling code and files can lead to inconsistencies in the upgrade process and can result in servers that are not synchronized with other servers. You can use solution packages to deploy developed site elements from developer environments to integration farms and then to staging, pilot, and production farms.

You can use Windows PowerShell cmdlets to create, import, export and provision solution packages, which leverage the Solution Framework to distribute developed site element customizations. Windows PowerShell cmdlets are useful for deployment of site customizations in most environments because they are included with SharePoint Foundation 2010, and you can use them alone or in conjunction with other methods. You can use Windows PowerShell cmdlets to deploy both artifacts and developed site elements. You can also use cmdlets to activate Features that are deployed in a solution package.

Deploying authored site elements

Authored site elements differ from developed site elements in that they are stored in the content database, although they can depend on resources that exist in the file system of Web servers or — less typically — application servers. In some cases, authored site elements do not function because they require that developed site elements be deployed first.

In environments where customization deployments are entirely automated, the required deployment order can be enforced by the system to eliminate synchronization issues. However, if customization deployment is partially or wholly manual, you must ensure that all required resources are in place on the Web servers and application servers before you deploy any content that relies on those resources.

You deploy authored site elements from authoring environments to staging, pilot, and production farms by using one or more of several different systems. The following table describes these systems and their associated interfaces and usage scenarios.

Deployment system Usage scenario

SharePoint Central Administration Web site

In environments where source and destination farms are connected by a network, you can use the content deployment features in Central Administration to create a content deployment package on the source farm and export the package to another farm.

This method is easy to configure and use, and can be used to automate deployment of authored site elements with very little setup time and maintenance.

Content Migration object model

Depending on the method you use (programming by using the deployment namespace APIs, using Simple Object Access Protocol (SOAP) calls to a Web service, or moving a whole site by using Windows PowerShell cmdlets), you can control what content is migrated and how. Using the API to import and export content is the only supported method that retains globally unique identifiers (GUIDs).

For more information, see Content Migration (http://go.microsoft.com/fwlink/p/?LinkId=183372).

Windows PowerShell

You can use Windows PowerShell cmdlets to perform import and export operations against the whole site, preserving time stamps, security information, and user information. Windows PowerShell cmdlets are most useful when you want to move basic content from a whole Web site.

Windows PowerShell is useful for deployment of site customizations in most environments because it is included with SharePoint 2010 Products, and you can use it alone or with other methods. You can use Windows PowerShell cmdlets to deploy both artifacts and developed site elements.

For more information, see SharePoint 2010 Products administration by using Windows PowerShell.

Custom Web service

You can create a custom Web service that automates content migration and deployment. You can write custom scripts and Windows applications to execute specific tasks within this process.

For more information about programmatic methods for writing a custom Web service, see the following resources in the Microsoft SharePoint 2010 Software Development Kit (SDK):

  • Sites Methods (http://go.microsoft.com/fwlink/p/?LinkID=183373)

  • Sites.ExportWeb Method (http://go.microsoft.com/fwlink/p/?LinkId=183377)

  • Sites.ImportWeb Method (http://go.microsoft.com/fwlink/p/?LinkId=183378)

Manual code handling

In smaller, disconnected environments, or in environments in which authored site elements are not continually customized, you can manually deploy site elements and related resources. In smaller connected environments, consider using the content deployment features in Central Administration to deploy authored site element customizations.

Solution packages and Features

Elements such as page layouts, master pages, forms, and style sheets, can be grouped and deployed in Features as part of a solution package. Features deployed from a solution package can be activated on the scopes where authored elements need to be provisioned.

For more information, see Deploy site elements by using Features (SharePoint Foundation 2010).

Custom templates

A user can save an existing site, with or without its specific content, as a custom template. This provides a means for reusing customized sites. A custom site template is stored as a .wsp file. Site templates are saved in the Solution Gallery of the top-level site in a site collection, where they become available for subsite creation on all Web sites in the site collection. Site templates can be downloaded and moved to other site collection galleries.

See Also

Concepts

Deploy solution packages (SharePoint Foundation 2010)
Deploy authored site elements (SharePoint Foundation 2010)
Deploy site elements by using Features (SharePoint Foundation 2010)
Deploy templates (SharePoint Foundation 2010)

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010


Deploy solution packages (SharePoint Foundation 2010)

This article describes solution packages and the role they play in deploying authored and developed customizations in Microsoft SharePoint Foundation 2010. It includes procedures for importing and deploying solution packages, and an example for building and deploying a solution package by using Microsoft Visual Studio 2010.

In this article:

  • What is a solution package?

  • Deploying site elements by using solution packages

  • Creating and deploying a custom Web Part solution package by using Visual Studio 2010

What is a solution package?

A solution package is a distribution package that delivers your custom SharePoint Foundation 2010 development work to the Web servers or the application servers in your server farm. Use solutions to package and deploy custom Features, site definitions, templates, layout pages, Web Parts, cascading style sheets, and assemblies.

This article does not discuss the deployment of sandboxed solutions. You can deploy a Microsoft SharePoint Foundation 2010 solution directly onto your SharePoint Foundation farm, or you can deploy the solution into a sandbox. A sandbox is a restricted execution environment that enables programs to access only certain resources, and that keeps problems that occur in the sandbox from affecting the rest of the server environment. For more information, see Sandboxed solutions overview (SharePoint Foundation 2010).

A solution package is a CAB file with a .wsp file name extension and a manifest file. It is recommended that you use Visual Studio 2010 Tools for SharePoint 2010 to develop and package SharePoint solutions. You can also create solution packages manually by using tools such as Makecab.exe and SharePoint Packman.

Components that can be packaged in a solution include:

  • .NET Framework assemblies, typically Web part assemblies and event receiver assemblies.

  • Deployment files such as resource files, pages, or other helper files.

  • Features, which allow you to activate and deactivate code in a Web site and provide functionality that include elements such as custom lists, libraries, fields, and content types.

  • New templates and site definitions.

  • Configurations that must be performed at the Web-server level — for example, deploying customizations to the Web.config files for the registration of Web Parts. You can also modify these configurations with a Feature that is distributed with a Feature.

  • Web content such as Web pages and images that are called by Web pages. If you must deploy Web content in a disconnected environment, you should use a content deployment package.

Deploying site elements by using solution packages

In this section:

  • When to use solution packages

  • Deploying farm solutions

  • Adding a solution package

  • Deploying a solution package

  • About creating a solution package

When to use solution packages

A best practice for deploying customizations is to use solution packages as part of a straightforward, safe, and consistent application lifecycle management process. Solution packages make it simpler to change the Features and functionality of the Web sites after the sites are created.

You can use solution packages to deploy new solutions and upgrade existing solutions across the farm. You can package all your SharePoint Foundation entities as one file, add the file to the solution store, and deploy it to the front-end Web servers in the farm. Use solution packages to synchronize a front-end Web server so that its state is consistent with the state of other Web servers in the farm.

You can use solution packages to deploy authored site element customizations from an integration farm to authoring, pilot, or production farm. In SharePoint Foundation, users can save a customized site as a template. This creates a solution package with a .wsp file name extension that can be deployed on another farm.

You can use solution packages to deploy customizations between these environments:

  • From developer workstations, to an integration farm or a software configuration management system

  • From an integration farm and authoring client workstations, to pilot or production farms

Deploying farm solutions

Farm solutions are deployed either locally or by using a timer service. Both local and timer-based deployments can be triggered either by using command-line instructions or programmatically by using the object model.

Local deployment

In a local deployment, solution files are deployed only to the computer from which the deployment operation was initiated. The solution is not marked as "deployed" in the configuration database until the solution files are deployed to all applicable servers in the server farm. Then solution features are installed, and schema and definition files are committed to the configuration store.

Timer Service deployments

In deployments that use the timer service, the deployment creates a timer job. This timer job is picked up by the timer service on each Web server in the server farm. Initially, manifest and feature manifests are parsed to find assembly and _layouts files, which are copied to the appropriate locations. All other files contained within a feature directory are copied to the feature directory. After solution files are copied to the target computers, a configuration reset is scheduled for all front-end Web servers; the reset then deploys the files and restarts Microsoft Internet Information Services (IIS). Solution features are then registered, and schema and definition files are committed to the configuration store.

For more information about the solution store, deployment, and synchronization, see Deploying a Solution (http://go.microsoft.com/fwlink/p/?LinkId=186995) in the Microsoft SharePoint 2010 Software Development Kit (SDK)

Adding a solution package

Before you can deploy a solution package, you must add it to the solution database of a SharePoint Foundation farm.

Important:

You must be a member of the Administrators group on any computer on which you run Windows PowerShell.

To import a solution package 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Add-SPSolution -LiteralPath <SolutionPath>

The solution is added to the farm's solution store. To use the solution, follow the procedure in the next section in this article. For more information, see Add-SPSolution.

Deploying a solution package

You can deploy imported solutions by using the Central Administration Web site or by using Windows PowerShell. After a solution has been added to the solution store by using the Windows PowerShellAdd-SPSolution cmdlet, it must be deployed to a site before it can be accessed.

Note:

You cannot add a solution to the solution store by using the Solution Management page in Central Administration.

The following procedures show how to deploy an imported solution to a site in the farm by using either the Central Administration Web site or Windows PowerShell.

To deploy a solution by using Central Administration

  1. On the Central Administration Home page, click System Settings.

  2. In the Farm Management section, click Manage farm solutions.

  3. On the Solution Management page, click the solution that you want to deploy.

  4. On the Solution Properties page, click Deploy Solution.

  5. On the Deploy Solution page, in the Deploy When section, select one of the following:

    • Now

    • At a specified time. If you select this option, specify a time by using the date and time boxes. We recommend that you select a time when the load on the destination servers is low.

  6. In the Deploy To? section, in the A specific web application list, click either All web applications or select a specific Web application.

  7. Click OK.

To deploy a solution package to a single Web application 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Install-SPSolution -Identity <SolutionName> -WebApplication <URLname>

    Where:

    • <SolutionName> is the name of the solution.

    • <URLname> is the URL of the Web application to which you want to deploy the imported solution.

    By default, the solution is immediately deployed. You can also schedule the deployment by using the time parameter. For more information, see Install-SPSolution.

To deploy a solution package to all Web applications 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Install-SPSolution -Identity <SolutionName> -AllWebApplications -time <TimeToDeploy> -GACDeployment -CASPolicies

    Where:

    • GACDeployment is the parameter that enables SharePoint Foundation 2010 to deploy the assemblies in the global assembly cache.

    • CASPolicies enables the creation of a custom code access security (CAS) policy file and the activation of it in the Web.config file of the targeted site collection.

    The solution is immediately deployed by default. You can also schedule the deployment by using the time parameter.

About creating a solution package

SharePoint Foundation 2010 does not include a tool for creating solution packages. This section describes ways to create solution packages that contain developed site elements and artifacts.

Visual Studio 2010

You can use Visual Studio 2010 to group related SharePoint elements into a Feature, and then bundle multiple Features, site definitions, assemblies, and other files into a single package (.wsp file) to deploy to servers running SharePoint Foundation 2010. You can use Visual Studio 2010 to debug and test the .wsp file on the server running SharePoint Foundation 2010. You can also customize the deployment steps on the development computer.

Developers can build their SharePoint solutions in Visual Studio 2010 and produce .wsp files by using the automated build process. Source code of the Visual Studio SharePoint project that is used to generate the .wsp file can also be added to the source code control system by using Visual Studio 2010 integration. Visual Studio 2010 can import .wsp files and create projects to further extend them and to create new .wsp files. The primary source of .wsp files that are imported into Visual Studio 2010 is templates saved from sites by using the Save As Template command on SharePoint Foundation 2010 sites. These templates can be used to save all of site customizations to a SharePoint solution.

For more information, see SharePoint Development in Visual Studio (http://go.microsoft.com/fwlink/p/?LinkId=187000).

Makecab

Solution packages can be created manually by using tools such as Makecab.exe. The Makecab.exe tool takes a pointer to a .ddf file, which describes the structure of the CAB file. The format of a .ddf file is similar to that of an .inf file — that is, you declare a standard header and then enumerate, one file per line, the set of files by where they are located on disk and where they should be located in the CAB file.

The Makecab.exe tool is available for download in the Microsoft Cabinet Software Development Kit (http://go.microsoft.com/fwlink/p/?LinkId=107292).

About customizing solution packages

If you need to make any of the following customizations in SharePoint Foundation 2010 solutions, it is recommended that you use Visual Studio 2010 to customize solution packages. You can also make these customizations by manually creating SharePoint solution packages.

  • Deploy .NET Framework assemblies in the private application folder instead of the global assembly cache.

  • Add code access security permissions to the solution that must be applied during the deployment.

  • Deviate from the names used by default for the Feature folders.

  • Localize the solution.

  • Associate Feature event handlers to certain types of SharePoint Foundation 2010 solutions, such as Web Part solutions.

  • Add resources (XML files, pictures, .dll files, and assemblies) to the solution package.

Manually create a solution file

In most SharePoint Foundation 2010 development scenarios, we recommend that you use Visual Studio 2010 Tools for SharePoint 2010 to develop and package SharePoint solutions. In Visual Studio 2010, the deployment process copies the .wsp file to the server running SharePoint Foundation 2010, installs the solution, and then activates the Features.

You can also manually create a solution file. The following are the basic steps of creating a solution file:

  1. Collect all individual solution files in a folder. There are no concrete guidelines about how you should do this, but a best practice is to separate the different types of solution files into their own subfolders.

  2. Create a manifest.xml file that lists the components of the solution.

  3. Create a .ddf file that defines the structure of the solution file. This file contains the list of individual solution files that determine the output .wsp file.

  4. Execute Makecab.exe with the .ddf file as input and the .wsp file as output.

About the solution manifest file

The solution manifest (always called manifest.xml) is stored at the root of a solution file. This file defines the list of Features, site definitions, resource files, Web Part files, and assemblies to process. It does not define the file structure — if files are included in a solution but not listed in the manifest.xml file, they are not processed in any way.

Following is an example of the structure of a manifest.xml file, shown in XML.

<?xml version="1.0" encoding="utf-8" ?>

<Solution xmlns="http://schemas.microsoft.com/sharepoint/"

SolutionId="{79d1a62e-3627-11db-963e-00e08161165f}"

ResetWebServer="TRUE">

    <Assemblies>

        <Assembly DeploymentTarget="GlobalAssemblyCache"

Location="Example.Sharepoint.Webparts\

Example.SharePoint.WebParts.dll">

            <SafeControls>

                <SafeControl Assembly="Example.Sharepoint.Webparts,

Version=1.0.0.0, Culture=Neutral, PublicKeyToken=63cce650e8605f5d"

Namespace="Example.Sharepoint.Webparts" TypeName="*"/>

            </SafeControls>

        </Assembly>

        <Assembly DeploymentTarget="GlobalAssemblyCache"

Location="Example.Sharepoint.Timer/Example.Sharepoint.Timer.dll"/>

    </Assemblies>

    <FeatureManifests>

        <FeatureManifest Location="Example.Sharepoint.Timer\Feature.xml"/>

        <FeatureManifest Location="Example.CustomType\Feature.xml"/>

        <FeatureManifest Location="Example.ExampleLibrary\Feature.xml"/>

        <FeatureManifest Location="Example.Columns\Feature.xml"/>

        <FeatureManifest Location="Example.Workflow.ProcessExample\Feature.xml"/>

        <FeatureManifest Location="Example.Workflow.ProvisionExample\Feature.xml"/>

    </FeatureManifests>

    <SiteDefinitionManifests>

        <SiteDefinitionManifest Location="EXAMPLE">

            <WebTempFile Location="1033\XML\WEBTEMPExample.XML"/>

        </SiteDefinitionManifest>

    </SiteDefinitionManifests>

</Solution>

In addition, you can add a DwpFiles element to specify .webpart or .dwp files, or a ResourceFiles element to specify resource files, site definitions, application resources, and code access security policies.

Optionally, annotate your Feature.xml files by using <ElementFile> tags.

If your solution contains Features, in the <ElementManifests> tag in your Feature.xml file, add <ElementFile Location="..."/> for all the extra files in your feature, such as ASP.NET pages (for example, allitems.aspx) or master pages, and so on.

For more information about solution manifest files that define the constituent parts of a solution, see Solution Schema (http://go.microsoft.com/fwlink/p/?LinkID=183466).

Creating and deploying a custom Web Part solution package by using Visual Studio 2010

For an example walkthrough that shows you how to use Visual Studio 2010 to create, customize, debug, and deploy a SharePoint list definition to track project tasks, see Walkthrough: Deploying a Project Task List Definition (http://go.microsoft.com/fwlink/p/?LinkId=189612) in the MSDN Library.

This walkthrough illustrates the following tasks:

  • Creating a SharePoint list definition project that contains tasks.

  • Adding the list definition to a SharePoint Feature.

  • Adding an event receiver to the list.

  • Creating and customizing a SharePoint package to deploy your Feature.

  • Building and deploying your SharePoint solution.

When you build the sample project in this walkthrough, Visual Studio 2010 automatically deploys the solution to the server running SharePoint Foundation 2010 on your development computer for testing and debugging. You can also create a solution package file that you can add and deploy on another computer. For more information, see How to: Deploy a SharePoint Solution (http://go.microsoft.com/fwlink/p/?LinkID=187004). You can use the Add-SPSolutionWindows PowerShell cmdlet to import the solution to another computer.

You can use the Solution Management page in Central Administration to deploy the solution package. Alternatively, you can use the Install-SPSolutionWindows PowerShell cmdlet to deploy the solution package.

In the walkthrough, the scope of the project list feature is Web. To activate the Feature, on the Web site, expand the Site Actions menu, and then click Site Settings. Under Site Actions, click Manage site features. On the Features page, next to the Feature name, click Activate.


Deploy authored site elements (SharePoint Foundation 2010)

This article discusses the deployment of authored site element customizations in Microsoft SharePoint Foundation 2010, including deployment procedures, general considerations, and best practices related to deploying custom content.

In this article:

  • About deploying authored site elements

  • Before you begin

  • Deploy content by using the Content Migration API

  • Create a content deployment package by using Windows PowerShell

About deploying authored site elements

Authored site elements can be thought of as the "content" in your sites. They are the Web pages, images, layout pages, cascading style sheets, and other resources that compose your SharePoint Foundation 2010 Web site. Authored site elements include:

  • Artifacts These are site elements — typically authored by using a design tool such as Microsoft SharePoint Designer 2010 — that compose the framework in which your site's content appears. Examples of artifacts include master pages and layouts.

  • Web content These are site elements — typically authored directly in the Web browser or in a client authoring program such as Word 2010 — that supply the content of your site. Examples of Web content include Web pages and images.

This article does not discuss deployment of developed site elements such as Web Parts and other code. For more information, see Deploy solution packages (SharePoint Foundation 2010) and Deploy site elements by using Features (SharePoint Foundation 2010).

Authored site elements can be deployed by various methods:

  • Use the object model to handle scenarios such as writing scripts to automate common tasks and setting custom properties for export and import that tailor the deployment. The object model provides the most control over your data migration scenarios.

  • Content deployment packages are intended for a one-time move or migration of content to a destination site collection. Content deployment packages are CAB files that can contain part or all of the authored site elements in a Web site, and can be deployed in a disconnected environment. Windows PowerShell cmdlets are used to create content deployment packages.

Note:

This article does not discuss using solution packages to deliver your custom SharePoint Foundation 2010 development work to the front-end Web servers or the application servers in your server farm. By using solution packages, you can deploy artifacts in a disconnected environment, and you can deploy artifacts and developed site elements in the same package. For more information, see Deploy solution packages (SharePoint Foundation 2010).

When to use a content deployment package

You can use content deployment packages to deploy authored site elements in one or more of the following scenarios:

  • One-time content migration Use a content deployment package to move content to a destination site collection only once. If you plan to update content regularly on a destination site collection, use the content deployment feature or the Content Migration API.

  • Disconnected environments If the farms are disconnected, you can create a content deployment package for asynchronous transfer to the integration farm.

  • Sample content If authored site element customizations need to be deployed from the authoring environment to the integration environment to be used as samples for development purposes, you can use a content deployment package to simplify this process.

Before you begin

To eliminate potential synchronization issues, you must often deploy developed site elements before you deploy authored site elements. Farm solutions and Web application solutions must be installed and deployed to the destination farm prior to content deployment. Also be aware that you must install on the destination server any language packs that are in use on the source server; if you fail to install the required language packs, content deployment will fail.

Before performing the procedures in this article, familiarize yourself with the concepts related to the deployment of site element customizations. For more information about planning and designing sites and site collections, see.Fundamental site planning (SharePoint Foundation 2010). Also, download an Excel version of the Content deployment planning worksheet (http://go.microsoft.com/fwlink/p/?LinkID=167835).

Deploy content by using the Content Migration API

Most deployment scenarios can be accomplished by using Central Administration without the need for scripts. However, you can use the object model to handle other scenarios, such as writing scripts to automate common tasks and setting custom properties for export and import that you cannot configure you set up a deployment by using the SharePoint Central Administration site. You can also create code that exports and imports a content package in situations where connectivity between a source farm and a destination farm may be limited or unavailable.

For more information about content migration and the content migration APIs, see Content Migration Overview (http://go.microsoft.com/fwlink/p/?LinkId=187033). For an overview of the content deployment feature and the background and resources necessary to build and implement custom deployment solutions, see Deploying Content Between Servers (http://go.microsoft.com/fwlink/p/?LinkID=181466). For a code example that shows how to use the object model to create paths and jobs that deploy content between site collections, see How to: Deploy Content Between Servers (http://go.microsoft.com/fwlink/p/?LinkId=187034). For a code sample and information about how to export and import a content package by using the Content Migration API, see How to: Customize Deployment for Disconnected Scenarios (http://go.microsoft.com/fwlink/p/?LinkID=181076).

Create a content deployment package by using Windows PowerShell

You can use Windows PowerShell to create a content deployment package that contains the authored site elements for a whole site (including all the content in the site) or a list or a document library.

Note:

Use content deployment packages for a one-time migration of content to a destination site collection. Use the content deployment feature or the Content Migration API to periodically move content from a source site collection to a destination site collection.

Content deployment packages are implemented as CMP (Content Migration Package) files. You export this package from the source server, and then import it into the destination server. You can use this method of content deployment in both connected and disconnected environments.

If you are using a software configuration management system, follow the steps for exporting the content deployment package, and then use the procedure appropriate to your software configuration management system to save the exported file.

To create a content deployment package 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Export-SPWeb -Identity <URLname> -path <ExportFileName> -IncludeUserSecurity -IncludeVersions 4 -NoFileCompression

    Where:

    • <URLname> is the site to export. This site is written to the content deployment package together with all the subsites beneath it.

    • IncludeUserSecurity causes the new site to have the same permissions as the original site.

    • IncludeVersions is set to 4 to specify that all versions should be included.

    • NoFileCompression causes the content deployment package to be output to an uncompressed folder instead of a single CAB file. This makes it more complicated to deploy the deployment package to a different server, but makes it easier to edit the individual files.

For more information, see Export-SPWeb.

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 import a content deployment package 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Import-SPWeb -Identity <URLname> -path <ImportFileName> -IncludeUserSecurity

    Where:

    • <URLname> is the site that will be imported, together with all the subsites beneath it.

For more information, see Import-SPWeb.

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.


Deploy site elements by using Features (SharePoint Foundation 2010)

This article describes how to deploy developed site element customizations by using Features. By using Features, you can control the scope within which the site customization can be activated and deactivated, and easily deploy the customizations across multiple server farms.

In this section:

  • What is a Feature?

  • When to use Features

  • Create a Feature

  • Install and activate a Feature by using Windows PowerShell

What is a Feature?

A Feature is a container of various defined extensions for SharePoint Foundation 2010, and is composed of a set of XML files that are deployed to front-end Web servers and application servers. You can deploy a Feature as part of a solution package, and you can individually activate a Feature in SharePoint Foundation sites.

Features reduce the complexity involved in making simple site customizations. Features eliminate the need to copy large chunks of code to change simple functionality, and therefore they reduce versioning and inconsistency issues that can arise among front-end Web servers.

Features make it easier to activate or deactivate functionality in the course of a deployment, and administrators can easily transform the template or definition of a site by turning on or turning off a particular Feature in the user interface.

An element is an atomic unit within a Feature. The Feature element is used in a Feature.xml file to define a Feature and to specify the location of assemblies, files, dependencies, or properties that support the Feature. A Feature includes a Feature.xml file and any number of files describing individual elements. Another Feature element from a different schema is used in an Onet.xml file to specify that a Feature be activated when a site is created from the site definition.

A Feature.xml file typically points to one or more XML files whose top-level <Elements> tag contains definitions for elements that support the Feature. Elements in SharePoint Foundation 2010 often correspond to what were discrete nodes in the Onet.xml or Schema.xml file of Microsoft Office SharePoint Portal Server 2003. There are several types of elements —for example, a custom menu item or an event handler.

  • For more information about the capabilities of Features, see Using Features (http://go.microsoft.com/fwlink/p/?LinkId=183450).

  • For specific information about the file format and XML elements used in the Feature.xml file, see Feature.xml Files (http://go.microsoft.com/fwlink/p/?LinkId=183451).

  • For information about how features affect the file format of the Onet.xml file in a site definition, see Site Definition (Onet.xml) Files (http://go.microsoft.com/fwlink/p/?LinkId=183454).

  • For more information about Feature element types, see Element Types (http://go.microsoft.com/fwlink/p/?LinkId=183455).

When to use Features

Features are the recommended method for deploying pieces of functionality, customizations, or configuration changes to front-end Web servers. Features are a flexible way to manage functionality through its lifecycle, including activation, upgrade, and eventually deactivation.

You can use Features to deploy developed site elements in one or more of the following scenarios:

  • Need for activation and deactivation When you deploy site element customizations in a Feature, you can install, activate, and deactivate the Feature by using Windows PowerShell or by using the object model. You can also activate and deactivate a Feature by using the Central Administration Web site.

  • Flexibility of scope You can activate a Feature for a single scope, including farm, Web application, site collection, or Web site.

  • Ease of distributed deployment A Feature is easy to deploy to multiple server farms as part of a solution.

  • Control through the Feature object model The Feature object model enables you to specify the list of installed features within a given scope and to control whether features are enabled at the farm and site levels.

Use solution packages to package Features to deploy to different environments. For example, use a solution package to deploy customizations between developer workstations and an integration farm, and also between either an integration farm or authoring client workstations, and pilot or production farms.

Create a Feature

When you create a custom Web page in SharePoint Foundation 2010 by using the browser or SharePoint Designer, the ASPX page can belong only to the root site collection of the server that is running SharePoint Foundation 2010. To create a page under a site collection that is available to the whole farm and in all site collections, use a solution to deploy the page under the \14\Template\Layouts folder (by using the TemplateFiles element in the solution manifest file).

A best practice on a farm is to deploy Features by using a solutions package. If a server must be rebuilt or another server is added to the farm, the Feature will not have to be manually added to each front-end Web server. By using solutions packages, you can deploy new and upgraded Features across the farm and synchronize a front-end Web server so that its state is consistent with the state of other servers in the farm.

To control the availability of a custom page in a site collection or a Web site, deploy the custom Web page as a SharePoint Feature as part of a solution. Use the module element in the Feature.xml file to deploy a Web page by using a scope of site collection and Web site. Modules are frequently used to implement a Web Part Page in the site.

A Feature that is deployed as part of a solution is installed automatically. If you manually deploy a Feature, you must install and activate it. See Install and activate a Feature by using Windows PowerShell, later in this article.

To create and deploy a custom Feature

  1. Create a Feature.xml file. The following is an example Feature.xml file, which is necessary for giving the feature a unique ID and pointing to the Module.xml file.

    Copy Code
    <?xml version="1.0"?>
<Feature Id="8C4DD0CB-5A94-44da-9B7F-E9ED49C2B2DC" Title=
"Custom Web page"
Description="This simple example feature adds an ASPX page
with a hosted XmlFormView control"
Version="1.0.0.0" Scope="Web"
xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
    <ElementManifest Location="Module.xml"/>
</ElementManifests>
</Feature>

  2. Create a Module.xml file. The following is an example Module.xml file, which contains information about the page or pages that are part of the solution.

    Copy Code
    <?xml version="1.0"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <module name="file" url="" path="">
        <file url="XmlFormViewPage.aspx" type="ghostable"> </file>
    </module>
</Elements>

  3. Change the file url value to the name of your ASPX page.

  4. Add a subfolder for the Feature definition within the Features setup directory on the server computer, typically located at %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\14\TEMPLATE\FEATURES.

    Important:

    A best practice is to use detailed, qualified names for the subfolders that you create for Feature definitions. This practice minimizes the likelihood that you will add multiple Features that have the same names and overwrite the Feature.xml file for another Feature. For example, use HR_Contract and Finance_Contract rather than Contract.

  5. Add your custom .aspx page to this subfolder for the Feature definition.

  6. Add Feature.xml and Module.xml files to the same location.

  7. Add the Feature to a solution package.

    You can use Visual Studio 2010 to add the Feature to a solution, or you can manually add a FeatureManifests element to the solution Manifest.xml file.

  8. Create the solution package.

    You can use Visual Studio 2010 to build the solution package. You can also use the Makecab.exe tool to create the solution package.

  9. Import and deploy the solution package.

    Add the solution to the solution store by using the Windows PowerShell Add-SPSolution cmdlet, and then deploy the solution from the solution store by using the Central Administration Web site or by using Windows PowerShell.

For more information about using Visual Studio 2010 to add Features to a solution packages, see Creating SharePoint Solution Packages (http://go.microsoft.com/fwlink/p/?LinkId=187035). For more information about manually creating a solution package or using the Makecab.exe tool to make the package, see Creating a Solution (http://go.microsoft.com/fwlink/p/?LinkId=187036). For more information about deploying solutions, see Deploy solution packages (SharePoint Foundation 2010).

Install and activate a Feature by using Windows PowerShell

You can install and activate a Feature by using Windows PowerShell or by using the object model. You can also activate a Feature by using the Manage Web Applications Features page or the Features page of the site collection or site on which you want to activate the Feature. Installing a Feature makes its definition and elements known throughout a server farm, and activating the Feature makes the Feature available at a particular scope.

Note:

Features that are deployed as part of a solution package are installed by the deployment and manual installation is not required.

You install Features in the 14\Template\Features folder, with each Feature in its own subfolder. At the root of this folder, a Feature.xml file defines the contents of the Feature. You must install individual Features before you can use them, and —unless the Feature is scoped to the farm — you must activate them after you install them. If a Feature is scoped to the farm or Web application, it is activated automatically.

To uninstall a Feature so that its definition is no longer available within a server farm, you first must deactivate the feature by using the Windows PowerShell Disable-SPFeature cmdlet, unless the Feature is scoped for Web applications or farms. After you deactivate the Feature, you can use the Uninstall-SPFeature cmdlet to uninstall it. For more information, see Uninstall-SPFeature. After uninstalling a Feature, reset Internet Information Services (IIS) so that the changes can take effect.

To deactivate a Feature so that it becomes inactive at its originally assigned scope without uninstalling it, you can use the Disable-SPFeature cmdlet. For more information, see Disable-SPFeature.

Use the following procedures to install and activate a Feature.

To install a Feature 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Install-SPFeature -path <Path> [-force]

    Where:

    • <Path> is a valid file path; for example, MyFeature. The path to the feature must be a literal path to the 14\Template\Features folder name. The Feature.xml file name is implied and does not need to be provided.

For more information, see Install-SPFeature.

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 activate a feature 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Enable-SPFeature -Identity <FeatureID> [-url] <URLname> [-force]

    Where:

    • <FeatureID> is the name of the Feature folder located in the 14\Template\Features folder. It must be a valid file path; for example, MyCustom.

    • <URLname> is the Feature parent URL of the Web application, site collection, or Web site for which the Feature is being activated; for example, http://somesite.

For more information, see Enable-SPFeature.

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.


Deploy templates (SharePoint Foundation 2010)

This article describes how to create a custom site definition and deploy it by using a solution package.

In this article:

  • What are site definitions?

  • Site definitions and configurations

  • Create a custom site definition and configuration

  • Deploy a site definition by using a solution package

What are site definitions?

In Microsoft SharePoint Foundation 2010, a user creates a site through the user interface (UI) by selecting a site definition configuration or custom site template that defines how to instantiate the site. A site definition is a template that determines, for example, the lists, files, Web Parts, Features, or settings with which to provision a new SharePoint site.

A site definition is a family of site definition configurations. Each site definition specifies a name and contains a list of the site definition configurations. In SharePoint Foundation 2010, a site definition consists of a set of XML files that can be applied to provision new sites. The files are located on Web servers.

Site definitions consist primarily of multiple XML and ASPX files stored on a front-end Web server in folders under the %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\SiteTemplates folder.

A site created from a site definition adds to, but does not repeat, the structural and content information from the original site definition. Throughout their lifecycle, sites continue to depend on the site definition that is their ultimate foundation. For this reason, Microsoft does not support changing or removing a site definition after sites have been created from it. Such changes may cause sites created from the definition to stop working properly or may prevent the creation of new sites based directly, or indirectly, on the site definition. To customize a site definition, developers can add a Feature that includes the changes to the site definition. The site definition itself is not modified.

For more information about what kinds of customizations of site definitions are supported by Microsoft, see Supported and unsupported scenarios for working with custom site definitions and custom area definitions in Windows SharePoint Services, in SharePoint Portal Server 2003, and in Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/p/?LinkId=187678).

In the object model, an SPWebTemplate represents a site definition (and configuration). For more information about site templates and site definitions, see Site Templates and Definitions (http://go.microsoft.com/fwlink/p/?LinkID=184756).

Note:

The STP format of a custom site template (.stp file) is deprecated in SharePoint Foundation 2010 and replaced with WSP format site templates. In Windows SharePoint Services 3.0, users can save an existing site as a custom site template. The site template is stored in the database as a model, and users can select the site template as a foundation that defines how to instantiate the site. In SharePoint Foundation 2010, users can save an existing site as a template. The template is saved as a .wsp file in the Solution Gallery of the top-level site in a site collection, where it becomes available for subsite creation on all Web sites in the site collection..

For more information about site definitions, see Site Definitions and Configurations (http://go.microsoft.com/fwlink/p/?LinkId=183458).

Site definitions and configurations

A site definition defines a specific SharePoint site. There are five site definitions natively installed in SharePoint Foundation 2010. A site definition can include more than one site definition configuration. SharePoint Web sites are based on specific site definition configurations that include the following:

  • STS includes the site definition configurations for Team Site, Blank Site, and Document Workspace.

  • MPS includes the site definition configurations for Basic Meeting Workspace, Blank Meeting Workspace, Decision Meeting Workspace, Social Meeting Workspace, and Multipage Meeting Workspace.

  • CENTRALADMIN provides a site definition configuration for Central Administration Web sites.

  • WIKI provides a site definition configuration for Web sites that support community content by using wiki technology.

  • BLOG provides a site definition configuration for blogs.

Each site definition consists of files that are placed in the \\Program Files\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\SiteTemplates subfolders of front-end Web servers during installation of SharePoint Foundation 2010. Site definition files include .xml, .aspx, .ascx, and .master page files, in addition to document template files — such as .dot and .htm — and content files, such as .gif and .doc.

Uncustomized pages and page customization

Site definition files are cached in memory on the server at process startup of Microsoft Internet Information Services (IIS). This allows uncustomized pages to be reused across sites. The information contained in these files is pulled from the cache at run time. Pages and list schemas are read from the site definition files but appear to be actual files within a site. New Web Part pages are also considered to be uncustomized.

When site pages are customized — excluding browser-based customizations such as modifications to Web Parts — their contents are stored in the content database, and the customized site page is used instead of the original page from the site definition. Uploaded .aspx files are automatically considered to be customized.

For more information about ghosting and page customization, see Site Definitions and Configurations (http://go.microsoft.com/fwlink/p/?LinkId=183458).

Core schema files

The following table lists the core XML files that can be modified for a site definition and shows their locations in the file system.

WebTemp.xml | Identifies the site definitions and provides information about their configurations. Located in: \TEMPLATE\1033\XML
Onet.xml | Defines the navigation areas, specifies the list definitions available, specifies document templates and their files, defines the base types for lists, and defines configurations and modules for site definitions. Located in: \TEMPLATE\SiteDefinitions\site_type\XML
Schema.xml | Defines the views, forms, toolbar, and special fields in a list definition. Each definition has its own Schema.xml file. Located in: \TEMPLATE\FEATURES\List_Definition_Name
DocIcon.xml | Each front-end Web server in a SharePoint Foundation deployment contains a DocIcon.xml file that maps file programmatic identifiers (ProgIDs) and file name extensions of document types to specific icons and to controls for opening each type. Changes to DocIcon.xml are global to a SharePoint Foundation deployment and affect all site definitions on the front-end Web server. Located in: \TEMPLATE\XML

These XML files use Collaborative Application Markup Language (CAML) (http://go.microsoft.com/fwlink/p/?LinkID=183464) for defining aspects of a site. For more information about these core XML files that you can use to customize site definitions, see Site Definitions and Configurations (http://go.microsoft.com/fwlink/p/?LinkID=183458).

Create a custom site definition and configuration

You can create custom site definitions by manually copying an existing site definition or by importing a .wsp file into Visual Studio 2010.

Import items from an existing SharePoint site

This method requires saving a site as a template from SharePoint Foundation to generate a .wsp file, and then importing the .wsp file into Visual Studio 2010 by using the solution import project template. The Import SharePoint Solution Package project template lets you reuse elements such as content types, list definitions, and fields from existing SharePoint sites in a new Visual Studio SharePoint solution. For more information about importing items from an existing SharePoint site into a Visual Studio SharePoint project, see Importing Items from an Existing SharePoint Site (http://go.microsoft.com/fwlink/p/?LinkID=187040). This chapter includes a walkthrough that demonstrates the following tasks:

  1. Customizing a SharePoint site by adding a custom site column.

  2. Exporting a SharePoint site to a .wsp file.

  3. Importing the .wsp file into Visual Studio SharePoint project by using the .wsp Import project.

Copy an existing SharePoint site

This method involves copying an existing site definition, modifying the copy, and changing two schema files: the copy of a WebTemp.xml file, and the copy of an Onet.xml file.

Warning:

Do not modify the originally installed WebTemp.xml file.

  1. Copy an existing site definition folder located in the Local_Drive:\Program Files\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\SiteTemplates\ directory. Your copy should be a peer of the original, and you can give it any name that contains no spaces.

    For example, to create a custom site definition that derives from the team site definition for Microsoft SharePoint Foundation, copy the \sts folder.

  2. Make a copy of the WebTemp.xml file. This file is located in Local_Drive:\Program Files\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\1033\XML.

    Give the file a unique name by appending a string to the name of the original file; for example, WebTempAction.xml. At run time, the compiler merges information contained in this file with the information contained in the original file to specify which site definition configurations are available for creating new sites.

  3. Customize the contents of the new WebTemp file.

    Each WebTemp.xml file contains a collection of Template elements and Configuration subelements, which identify to the compiler all the site definition configurations that can be instantiated. The Configuration element defines, for example, a title, a description, the URL for the image displayed in the user interface (UI), and a display category that specifies the tab on which to display the template in the Template Selection section of the Create Site Collection page.

    Important:

    In each Template element defined in the WebTemp file, the Name attribute must contain the same name that is assigned to the new folder.To avoid conflict with IDs already used in SharePoint Foundation 2010, use unique values greater than 10,000 for the ID attribute.

The following example uses two Configuration elements in the WebTemp.xml file to define different site definition configurations for instantiating a site, one for a Research Collaboration site and the other for a Research Document Workspace site. This example uses only two configurations within a single site definition, but you can include multiple site definitions, each with multiple configurations, within a single WebTemp.xml file. Each site definition references a different site definition folder and its Onet.xml file.

Copy Code
<?xml version="1.0" encoding="utf-8" ?>
<Templates xmlns:ows="Microsoft SharePoint">
  <Template Name="RESEARCH" ID="10001">
    <Configuration ID="0" Title="Research Collaboration site"
      Hidden="FALSE" ImageUrl="_layouts/images/stsprev.jpg"
      Description="This definition creates a site for the Research
      team to create, organize, and share general information."
      DisplayCategory="Collaboration">
    </Configuration>
    <Configuration ID="1" Title="Research Workspace" Hidden="FALSE"
      ImageUrl="_layouts/images/dwsprev.jpg" Description="This
      definition creates a site for Research team colleagues to
      work together on specific documents."
      DisplayCategory="Collaboration">
    </Configuration>
  </Template>
</Templates>

As indicated by the value of the Name attribute in the Template element, this example assumes that a site definition directory named "RESEARCH" exists. If a WebTemp*.xml file specifies more than one site definition, the definitions are distinguished by their unique ID values.

Each Configuration element also contains an ID attribute. The combination of this ID and the value of the Name attribute in the Template element provides a reference to the contents of a specific Configuration element in a specific Onet.xml file. In the example, the Name attribute contains RESEARCH and the ID attributes contain 0 and 1, which reference the RESEARCH site definition and configurations with IDs of 0 or 1 in Onet.xml.

You may need to reset IIS to cause the new definition configuration to appear as an option in the UI. To do this, enter iisreset at a command prompt.

For more information about defining each site definition configuration in Onet.xml, see How to: Use Site Definition Configurations (http://go.microsoft.com/fwlink/p/?LinkId=183465).

Deploy a site definition by using a solution package

To deploy a custom site definition by using a solution package, add a SiteDefinitionManifest element to the manifest file of the solution package. Add the TemplateFiles element to define the template files that must be deployed in a subfolder of the \14\Template folder

Add a SiteDefinitionManifest element

The SiteDefinitionManifest element has a Location attribute that picks up all the files in the specified folder and creates the required folder in the \14\Template\SiteTemplates folder. The WebTempFile child element deploys the webtemp*.xml file to make the template known to SharePoint 2010 Products, as shown in the following example:

Copy Code
  <SiteDefinitionManifests>
    <SiteDefinitionManifest Location="LitwareSiteTemplate">
      <WebTempFile Location="1033\xml\webtempLitware.xml" />
    </SiteDefinitionManifest>
  </SiteDefinitionManifests>

Add a TemplateFile element

The TemplateFile element in a solution manifest file is used to define the template files that must be deployed in a subfolder of the \14\Template folder. An example of the kind of file you can deploy in this way is the fldtypes*.xml file, which defines the details of a custom field type. Use the Location attribute to specify the relative path to the file, which is indicated by the string "Text" in the following example:

Copy Code
  <TemplateFiles
    <TemplateFile
      Location="Text"/>
      ...
  </TemplateFiles>

For more information about how to deploy solutions, see Deploy solution packages (SharePoint Foundation 2010).


Workflow deployment process (SharePoint Foundation 2010)
See Also

After you prepare a workflow for use in Microsoft SharePoint Foundation 2010, deployment of the workflow varies depending on whether you use a predefined workflow, a Microsoft Office SharePoint Designer workflow, or a Microsoft Visual Studio custom workflow.

This article contains information and procedures about how to deploy workflows in SharePoint Foundation 2010.

In this article:

  • Overview

  • Before you begin

  • Deploying workflows

  • Verification

Overview

SharePoint Foundation 2010 provides a single predefined workflow template, for the Three-state workflow. You can use the Three-state workflow template to create individual workflows to run in SharePoint sites. You can also use Office SharePoint Designer to define your own workflows, or you can use Visual Studio to create code-based custom workflows. Workflows are built on Windows Workflow Foundation and run in SharePoint sites, as follows:

  • SharePoint Foundation 2010: Used to host workflows. After a workflow is deployed to the host, you can activate, configure, start, participate in, and track the workflow.

  • SharePoint Designer 2010: Used to create user-defined workflows.

  • Microsoft Visio 2010: Used together with SharePoint Designer 2010 to create user-defined workflows.

  • Visual Studio: Used by developers to create workflows.

Before you begin

Before you perform the deployment procedures in this article, confirm that the server is running SharePoint Foundation 2010.

Deploying workflows

The predefined Three-state workflow is already installed as a SharePoint Feature in SharePoint Foundation 2010.

Workflows on a SharePoint Web site are stored as workflow templates. As an alternative to using the predefined workflow, you can create SharePoint workflow templates in Office SharePoint Designer and Visual Studio, and then deploy them to a SharePoint Foundation 2010 Web site. Use SharePoint administration tools as needed to add the template to libraries or lists on a SharePoint Foundation 2010 Web site.

To deploy a predefined workflow, you activate it for the site, associate it with a list, library, content type, or site, and then start the workflow.

To deploy workflows in SharePoint Foundation 2010, use the appropriate procedure from the following:

  • Deploy predefined workflows

  • Deploy SharePoint Designer workflows

  • Deploy Visual Studio workflows

Deploy predefined workflows

Activate the workflow

As described earlier in this article, before you can use a predefined workflow, it must be active in the site or site collection. Only active workflows can be associated with the lists and libraries on the site or site collection.

The predefined Three-state workflow is active by default when a site or site collection is created. Because the workflow can be deactivated, you can check the site or site collection to determine whether the Three-state workflow is active. Use the following procedure to determine whether the Three-state defined workflow is active, and then activate it as necessary.

To activate a workflow that is deployed as a feature, such as the predefined Three-state workflow, see Activate or deactivate a workflow (SharePoint Foundation 2010).

Add the workflow association to a list, library, content type, or site

When you add a workflow, you associate the workflow with a list, library, content type, or site. You configure the workflow by specifying parameters such as the workflow name, start options, participants, and completion options.

To add a workflow association, see Add a workflow association (SharePoint Foundation 2010).

Start the workflow

After you activate a workflow and add it to a list, library, content type, or site, an authenticated user can run the workflow on an item in the list, on a document in the library, or on a site in the case of a site workflow. When you add the workflow, you specify whether you want the workflow to run automatically or manually. If the workflow is configured to start automatically, the default settings are always used when the workflow begins. If the workflow is configured to start manually, a user can modify the default settings, such as specifying workflow participants and specifying a due date. The workflow runs on items in the list or documents in the library with which the workflow is associated.

The procedure for starting a workflow depends on whether it was configured to start manually or automatically.

For more information, see Start a workflow instance (SharePoint Foundation 2010).

Deploy SharePoint Designer workflows

When user-defined workflows are enabled, users can deploy Office SharePoint Designer workflows on their sites.

Enable user-defined workflows

To allow users to create and run SharePoint Designer 2010 workflows, you must ensure that user-defined workflows are enabled for the site collection. By default, this setting is enabled. When this setting is enabled, users can define workflows in a declarative workflow editor such as the SharePoint Designer 2010 workflow editor. A declarative workflow is a workflow that is built from conditions and actions that are assembled into rules and steps, and that sets the parameters for the workflow without writing code. Unlike code-centric workflows such as those that are created by using Visual Studio, declarative workflows are not deployed to SharePoint Foundation 2010 as compiled code. Instead they are compiled at runtime.

Because the capability to use declarative workflows on the Web application can be turned off, you can check the Web application to determine whether declarative workflows are active.

For information, see Enable or disable declarative workflows (SharePoint Foundation 2010).

Create a SharePoint Designer workflow

By using the Workflow Designer wizard in SharePoint Designer 2010, you can create workflows that add application logic to the site or site collection without writing custom code. The Workflow Designer incorporates the tasks of creating the workflow, activating the workflow, and adding it to the list, library, or site. You do not have to perform any manual configuration tasks outside the designer to deploy the workflow. However, if you publish a workflow template to a SharePoint site collection, you can download that template as a WSP file and then deploy it to other site collections. For more information, see Deploy a workflow as a WSP file (SharePoint Foundation 2010).

Start the workflow

Because SharePoint Designer 2010 can automatically activate the workflow and add it to a list, library, or site, an authenticated user can then run the workflow on an item in the list, on a document in the library, or on a site in the case of a site workflow. When you create the workflow in SharePoint Designer 2010, you specify whether you want the workflow to run automatically or manually. If the workflow is configured to start automatically, the default settings are always used when the workflow begins. If the workflow is configured to start manually, a user can modify the default settings, such as specifying workflow participants and specifying a due date, as allowed by the workflow template. When started, the workflow runs on items in the list, on documents in the library, or on the site with which the workflow is associated.

For more information, see Start a workflow instance (SharePoint Foundation 2010).

Deploy Visual Studio workflows

After a Visual Studio custom workflow is created and installed, the processing to deploy it resembles that of a predefined workflow.

Create a custom workflow

When a custom workflow is created by using Visual Studio, it is packaged as a SharePoint Feature. Feature packaging is a way of encapsulating SharePoint solutions and functionality for ease of deployment. After the development team has created a workflow and packaged it as a Feature, deploy the workflow using the Install-SPFeatureWindows PowerShell command as described in the following section.

Install the custom workflow

You install Features in the \Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Template\Features directory. Each Feature in its own subdirectory. At the root of this folder, a Feature.xml file defines the contents of the Feature. Use the Windows PowerShellInstall-SPFeature cmdlet to install the Feature. For details, see Install-SPFeature.

Important:

To run Windows PowerShell, you must be a member of the Administrators group on the local computer. Also, Windows PowerShell must be enabled as a feature on the server on which you are installing a workflow.

Activate the workflow

Before you can use a Visual Studio workflow that was deployed as a feature, you must activate it for the site collection. Only active workflows can be associated with the lists, libraries, content types, and sites.

To activate a workflow that is deployed as a feature, see Activate or deactivate a workflow (SharePoint Foundation 2010).

Add the workflow to a list, library, content type, or site

When you add a workflow, you associate the workflow with a list, library, content type, or site, and you configure the workflow by specifying parameters such as the workflow name, start options, participants, and completion options.

To add a workflow association, see Add a workflow association (SharePoint Foundation 2010).

Start the workflow

After you activate a workflow and add it to a list, library, content type, or site, an authenticated user can run the workflow on an item in the list or a document in the library or in the case of a site workflow, on a site. When you add the workflow, you specify whether you want the workflow to run automatically or manually. If the workflow is configured to start automatically, the default settings are always used when the workflow begins. If the workflow is configured to start manually, the user can modify the default settings, such as specifying workflow participants and specifying a due date. The workflow runs on items in the list or documents in the library with which the workflow is associated.

The procedure for starting a workflow depends on whether it was configured to start manually or automatically. For more information, see Start a workflow instance (SharePoint Foundation 2010).

Verification

After you deploy a workflow, we recommend that you test the workflow to ensure that it is functioning correctly, sending e-mail notifications to the correct workflow participants at the correct stages in the workflow, and delivering the expected results.

See Also

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010


Deploy software updates for SharePoint Foundation 2010
See Also

Published: July 8, 2010

Microsoft periodically releases software updates for Microsoft SharePoint Foundation 2010. It is important to understand what these updates are and how to deploy them to servers or server farms. This section describes the software update process for SharePoint Foundation.

In this section:

  • Software updates overview (SharePoint Foundation 2010)

    This article provides an overview of the software update process for SharePoint Foundation.

  • Prepare to deploy a software update (SharePoint Foundation 2010)

    This article helps you determine which approach to use to update the servers or server farms in your environment, and lists the steps that you must take before you can start to install the update.

  • Install a software update (SharePoint Foundation 2010)

    This article contains instructions for installing a software update and upgrading your content to that level.

  • Service Pack 1 (SP1) for SharePoint Foundation 2010 (white paper)

    This article describes the features that are included in Microsoft SharePoint Foundation 2010 with Service Pack 1 (SP1), and provides guidelines to help ensure your solutions work with current and future releases of SharePoint Foundation 2010.

See Also

Other Resources

Resource Center: Updates for SharePoint 2010 Products


Software updates overview (SharePoint Foundation 2010)
See Also

Published: July 8, 2010

This article provides an overview of deploying software updates on a Microsoft SharePoint Foundation 2010 farm.

In this article:

  • Improvements and new features

  • Intended audience and scope

  • Software update process

  • Software update strategy

  • Software update deployment cycle

Improvements and new features

SharePoint Foundation 2010 introduces improvements and new features that facilitate a better end-to-end software update experience. Some of these features are as follows:

  • There is support for backward compatibility between update versions on different servers, which enables you to install the update binary files and postpone update completion to a later time.

  • You can update multiple Microsoft SharePoint Foundation servers concurrently to shift the workload to the database servers.

  • There is full support for automatic updates that use Windows Server Update Services (WSUS), Windows Update, and Microsoft Update.

    Note:

    An automatic update will install the binary files on the farm servers, but you must complete the software update by running the upgrade on the servers.

  • Administrators can monitor the status of the update by using the Central Administration Web site or Windows PowerShell.

For more information about SharePoint Foundation improvements and new features, see What's new in upgrade (SharePoint Foundation 2010).

Intended audience and scope

The information that is provided about the software update process is intended for all IT professionals who maintain SharePoint Foundation 2010. However, the specific instructions for installing a software update are intended for IT professionals who have to deploy software updates on a SharePoint Foundation server farm.

The information in this article applies to the following products:

  • SharePoint Foundation 2010

  • SharePoint Foundation 2010 language pack

  • Microsoft Filter Pack

Note:

The process for installing software updates in stand-alone environments of SharePoint Foundation is a simpler process than the process for installing software updates in a server farm and does not require all the steps that are required for a server farm.

Software update process

It is important to understand that deploying updates in a SharePoint Foundation 2010 environment is a two-phase process: patching and upgrading. The term patch is used in this article to differentiate between updating the software and upgrading the software.

Each phase has specific steps and results. It is possible to postpone the upgrade phase.

Caution:

Inconsistent farm behavior may result from postponing the upgrade for more than several days. The longer the postponement, the larger the risk is that farm behavior issues will occur.

Update phase

The patch phase has two steps, the patching step and the deployment step. During the patching step, new binary files are copied to the Central Administration server. Any services that are using files that have to be replaced are temporarily stopped. Stopping services reduces the requirement to restart the server to replace files that are being used. However, there are some instances when you must restart the server.

The second step in the patch phase is the deployment step. In this step, the installer copies support files to the appropriate directories on the server that is running SharePoint Foundation. This step ensures that all the Web applications are running the correct binary files and will function correctly after the update is installed. The update phase is complete after the deployment step.

The next and final phase to deploy software updates is the upgrade phase.

Upgrade phase

After you finish the patch phase, you must complete the update installation by starting the upgrade phase. The upgrade phase is task intensive and, therefore, takes the most time to finish. The first action is to upgrade all the SharePoint Foundation processes that are running. After the processes are upgraded, the databases are crawled and upgraded. Because the upgrade process can run on a single server, the other servers in the farm can continue to serve requests.

For more information about upgrades, see Upgrade process overview (SharePoint Foundation 2010).

Software update strategy

The update strategy that you select will be based primarily on one of the following factors:

  • The amount of downtime that is acceptable for installing the update.

  • The additional staff and computing resources that are available to reduce downtime.

When you are determining your update strategy, consider how the strategy enables you to manage and control the update.

In terms of downtime reduction, the following options, ordered from most to least downtime, are available:

  • Install the update and do not postpone the upgrade phase.

  • Install the update and postpone the upgrade phase.

  • Install the update with the shortest possible downtime and postpone the upgrade phase.

Software update deployment cycle

The cycle that is used for upgrading SharePoint Foundation farms and servers also applies to deploying software updates, which are a subset of an upgrade. We recommend that you use the update cycle that is shown in the following illustration as a guide to deploy software updates.

The software update deployment cycle

Learn

During this phase of the cycle the purpose is to learn what is required to install the update. This information also affects new servers that you want to update and then add to the farm.

Requirements and prerequisites

First, ensure that the system can be provisioned as a farm server. For more information, see Hardware and software requirements (SharePoint Foundation 2010). Ensure that any server that you plan to update is running the same version of the operating system as the other farm servers. This includes updates, service packs, and security hotfixes.

Update strategy

Determine which strategy you want to use to update the farm. Depending on your requirements, you can use one of the following strategies:

  • In-place

  • Database attach

You can use either of the previous strategies to create a hybrid approach that is tailored to your environment. For more information, see Determine upgrade approach (SharePoint Foundation 2010).

Downtime reduction

Research and assess the options that are available for reducing downtime. The first thing to check for is missing dependencies, which may extend the amount of downtime. Identify all the dependencies for the update and either address these dependencies before you start to deploy the update, or factor the time cost into your schedule. Consider using read-only content databases and doing parallel upgrades to reduce downtime.

Important:

We strongly advise against using alternate access mapping URL redirection (AAM) with database attach as an option for downtime reduction. AAM was not designed to deploy software updates. For more information, see Using AAM URL redirection as part of the upgrade process (SharePoint Foundation 2010) (white paper).

Common issues

Identify and address common issues such as missing or out-of-date dependencies and lack of space on the servers where the update will be installed.

Prepare

Prepare for the software update by documenting the environment and planning an update strategy to ensure that the update will go as planned in the expected downtime window.

Document the environment

The purpose of documenting the environment is to determine what is unique in your farm. You can use several techniques to gather information about your farm, such as manual inspection, comparisons by using WinDiff, and Windows PowerShell commands.

Document, as appropriate, the following elements of the environment:

  • Farm topology and site hierarchy

  • Language packs and filter packs that are installed

  • Customizations that could be affected by the update

Manage customizations

Customizations are typically one of the top issues during a farm upgrade or software update. Identify your farm customizations and determine whether they might be affected by the update. If in doubt, err on the side of caution and determine how you will manage the customizations. You must ensure that customizations will work after the software update. You can use the Stsadm command, ExportIPFSAdminObjects, to collect and export customizations.

For more information, see Determine how to handle customizations (SharePoint Foundation 2010).

Plan the update strategy

During the Learn phase of the update cycle, you should have determined an update strategy and the required downtime minimization. In addition to determining hardware, space, and software requirements, you must include the following in your update strategy:

  • The update sequence for the farm servers

  • The order of operations

  • The downtime limits and how you plan to reduce downtime

  • A rollback process if there is a major problem

Tip:

Clean up the farm environment before you deploy the update. The benefits of a cleanup are improved update installation performance and the elimination of potential issues during and after the software update. For more information, see Clean up an environment before upgrade (SharePoint Foundation 2010).

The two final requirements for the update strategy are a communication plan and an update schedule.

It is very important to communicate with site owners and users about what to expect during an upgrade. The administrator should inform them about downtime and the risk that the upgrade may take longer than expected or that some sites may need some rework after upgrade. For more information, see Create a communication plan (SharePoint Foundation 2010).

Create a benchmark update operations schedule that contains the start times of operations related to the update deployment. At a minimum, the plan should include the following operations:

  • Back up the farm.

  • Start the update of the farm servers.

  • Start the upgrade of the farm databases.

  • Start a rollback of the environment, if it is required.

  • Resume the upgrade, if it is required.

  • Verify that the environment is completely working, either as the original version if you rolled back or the new version if you completed the upgrade.

Make farm items update-ready

Ensure that farm items are ready for the update. Farm items are ready if they are backed up, documented, or updated to ensure that the update can be installed. Verify that the following aspects of a farm are update-ready:

  • Solutions

  • Features

  • Site definitions

  • Web Parts

Test

The rigor, thoroughness, and detail of your tests determine the success or failure of the software update deployment. In a production computer environment there are no safe shortcuts, and there are consequences from insufficient testing. For more information, see Use a trial upgrade to find potential issues (SharePoint Foundation 2010).

Build a test farm

Build a test farm that is representative of the production environment. We recommend that you use a copy of the production data to determine potential problem areas and monitor overview system performance during the upgrade. The key indicator is the length of time it takes from the beginning to the end of the deployment process. This should include backup and validation. You can incorporate this information into the update schedule.

If possible, use hardware in the test environment that has equivalent performance capabilities to the production servers.

Tip:

Consider the use of a test farm in a virtual environment. After you finish the tests, you can shut down the virtual farm and use it later for future updates.

Evaluate techniques

A test farm also enables you to evaluate the techniques that you plan to use to update the production environment. In addition to testing and assessing your downtime reduction strategy, you can refine update monitoring. This is especially important in the areas of validating and troubleshooting the software update.

Implement

The update strategy that you use will determine whether you have to build a new farm or deploy the update on the current farm servers.

Build or update farms

Whether you build a new farm or do an in-place update, the most important farm elements to consider are as follows:

  • Content

  • Services

  • Service applications

Deploy customizations

Use solutions whenever possible so that you can quickly deploy any customizations.

Reduce downtime

Reduce downtime by using techniques such as read-only databases and update parallelism. For more information, see Determine upgrade approach (SharePoint Foundation 2010).

Monitor progress

The refined techniques that you use to monitor the software update in the test environment carry over to deploying the update in the production environment. Use the Upgrade and Migration page in Central Administration to monitor the status indicators that are available. This feature enables live monitoring and provides a single location to view the patch status for all farm servers. Additionally, you can use the Upgrade and Migration page to view the update status for individual servers and the status and type of farm databases. Finally, a valuable aspect of monitoring by using Central Administration is identifying farm servers that must be updated.

The following tables describe the status information that is available in Central Administration.

Status value | Description | Hyperlink
No action required | Farm server does not currently require any action to be taken by the administrator. | No hyperlink
Installation required | Farm server is missing an .msi file that is set to mandatory for all farm servers, or has a patch level below the individual farm-wide effective patch version. | Hyperlink to the Patch Deployment State page
Upgrade in progress | Farm server is currently undergoing an upgrade operation. | Hyperlink to the Upgrade Status page
Upgrade available | Farm server is running in backward-compatibility mode. | Hyperlink to the Upgrade and Migration page
Upgrade required | Farm server is outside the backward-compatibility mode range with one or more databases. | Hyperlink to the Upgrade and Migration page
Upgrade blocked | If an upgrade is available and any farm server requires installation, the remaining servers that do not require installation will be set to this status unless they are currently undergoing an upgrade. | Hyperlink to the Patch Deployment State page

Status value | Description
Installed | Indicates that no action is required
Missing/Required | Displayed if a product is required on each server or if a patch for a specific .msi file is located on one server but not on the server for which this status is shown
Missing/Optional | Displayed if a product is not required on each server
Superseded | Displayed if an update is no longer required on a server because a newer patch supersedes it

Other tools to monitor the update process are log files and Windows PowerShell commands.

Important:

Remember to monitor the length of time that the update is taking. Compare current update processes against the benchmark schedule to determine whether the update will meet the downtime window. If not, you should communicate this information to the farm users.

Validate

You can start to validate the success of the update during the implementation phase and continue validation after the update is implemented.

Logged event failures

Review the event logs to discover any issues that occurred during the deployment. Resolve these issues and then resume or restart the update as appropriate.

User interface or experience issues

Any user interface or user experience issues will surface on site pages. Look for the following issues:

  • Ghosting

  • User interface version mismatch

  • HTML and XHTML compliance

Additional issues may include missing templates, user identifiers, and content issues such as large lists.

Data issues

Data issues result from the condition of the farm databases and can include all or some of the following:

  • Connectivity issues to data sources

  • Database corruption

  • Orphaned items

  • Hidden column data

In some cases there may be minor issues that you can troubleshoot and then resume or restart the update. Be prepared to roll back the update as soon as there are issues that cannot be easily resolved.

See Also

Other Resources

Resource Center: Updates for SharePoint 2010 Products


Prepare to deploy a software update (SharePoint Foundation 2010)

Published: July 8, 2010

This article describes the required and recommended tasks that have to be completed before you install software updates on servers in a Microsoft SharePoint Foundation 2010 farm.

In this article:

  • Verify account permissions and security settings

  • Determine the update approach

  • Back up the environment

  • Document the environment

  • Determine whether related items need to be updated

  • Obtain the software update and prepare the installation source (optional)

Verify account permissions and security settings

Verify that you have the required account permissions and know which security settings are in place on the farm. For more information, see Initial deployment administrative and service accounts (SharePoint Foundation 2010).

Determine the update approach

There are two basic options for deploying a software update on a farm: in-place and database attach. Additionally, these options can be combined to use one of the hybrid approaches that are described in Determine upgrade approach (SharePoint Foundation 2010).

Note:

Because installing a software update is a subset of a software upgrade, documentation about software upgrades applies to deploying software updates.

The differences between the two update approaches are as follows:

  • In-place update: This approach is the easiest to do. With this method, the amount of downtime required is directly related to the size and complexity of the farm. You have two choices for an in-place update:

    • In-place without backward compatibility - The update is installed on all the farm servers at the same time and the content is upgraded without using backward compatibility. No downtime reduction is available for this method.

    • In-place with backward compatibility to reduce downtime - The update is installed in stages and uses postponed upgrade with backward compatibility to reduce downtime.

  • Database attach: This approach is more complex than an in-place update, and it costs more in person time and hardware resources. This update method uses two farms to provide high availability for existing content.

When you use either the in-place with backward compatibility method or the database attach method, you can use a postponed upgrade so that you can choose to upgrade the content first and then the farm and servers afterward.

We recommend that you use the following flowchart, which presents the key decision points and subsequent actions, for determining which update approach to use.

Decision flow chart to determine update strategy

Whichever method you choose to use for updating your servers, you can use either the SharePoint Products Configuration Wizard or Windows PowerShell cmdlets to upgrade your content.

Back up the environment

To ensure that you can recover the existing environment in case something goes wrong during the update deployment process, we recommend that you back up the SharePoint Foundation 2010 environment before you start to install the update. A failed software update can be caused by factors other than the update process, such as the following:

  • Media failure

  • User errors (such as deleting a file by mistake)

  • Hardware failures (such as a damaged hard disk or permanent loss of a server)

  • Power failures

  • Natural disaster

You can back up all or part of a farm. The following list summarizes the farm components that can be backed up individually:

  • Configuration settings

  • Web applications

  • Service applications

  • Site collections

  • Logs

For more information about how to determine what you need to back up and which method to use to do so, see Plan for backup and recovery (SharePoint Foundation 2010). After you determine which farm elements you will back up, refer to the articles listed in Backup (SharePoint Foundation 2010). These articles provide detailed instructions and guidance for backing up all or part of a farm.

Important:

Test the farm backups before you start to deploy the software update. You have to be sure that these backups are valid so that you can recover if there is a hardware failure or data corruption during the update process.

Document the environment

Be sure to document the farm, including any custom components in the farm, in case you need to rebuild. For more information about creating an inventory of customizations, see Identify and install customizations in the Upgrade guide. In addition, document unique things about your farm, such as the following:

  • Any large lists

  • Any sites with large access control lists (ACLs)

  • Any sites that are critical to your organization

Having a list of these items will help you more quickly validate your environment after you apply an update.

Determine whether related items need to be updated

Consider whether the following related items need to be updated when you update your farm:

  • Filter packs

  • Office Web applications

  • Language packs

All these items are updated separately from SharePoint Foundation 2010. Check to see if any updates to these items are available, and evaluate whether you want to apply the updates to your farm when you apply the updates for SharePoint Foundation 2010. Language packs are usually only updated when service packs (SP1, SP2, and so on) are released.

Obtain the software update and prepare the installation source (optional)

If the servers on which you want to install SharePoint Foundation 2010 are isolated from the Internet, it is usually necessary to install software updates from an offline location. Even if the servers are not isolated, if you install software updates from an offline central location, you can ensure farm server consistency by installing a well-known and controlled set of images. Use the following procedure to prepare a software update for installation on a farm server.

You do not need to perform this procedure if you are downloading and installing the update directly to your servers.

To prepare an installation source

  1. Download the software update that you want to install.

  2. Extract the software update to a shared location by using the following command:

    <package> /extract:<path>

    The /extract switch prompts you to provide a folder name for the files. An example of a folder name for x64 systems is as follows:

    sps-kb999999-x64-fullfile-en-us.exe /extract:<\\computername\updateshare\Updates>

  3. Copy the extracted files from the shared location to an Updates folder that you create on the computer where you want to start to install the update.

    Note:

    You must use the name Updates for this updates folder. If you use the SupdateLocation="path-list" property to specify a different location, Setup stops responding.

You can now use this location as an installation point, or you can create an image of this source that you can burn to physical media or save as an ISO file.

Slipstream package

In server farm deployments, all the Web servers must have the same software update version applied. This means that, before you add a new Web server to an existing server farm, the new Web server must have the same software updates as the rest of the Web servers in your server farm. Likewise, when you create a farm, all servers in the farm must have the same software updates. To make sure that all new servers have the same software updates applied, we recommend that you create an installation source that contains a copy of the release version of the software, together with software updates that match those installed on your server farm (also known as a slipstreamed installation source). When you run Setup from this updated installation source, the new Web server will have the same software update version as the rest of the Web servers in your server farm. For more information, see Create an installation source that includes software updates (Office SharePoint Server 2007) [http://technet.microsoft.com/en-us/library/cc261890(office.12).aspx].


Install a software update (SharePoint Foundation 2010)
See Also

Published: July 8, 2010

This article describes how to install a software update on servers in a Microsoft SharePoint Foundation 2010 farm. Additionally, three example scenarios are discussed and an update procedure is provided for each scenario.

In this article:

  • Verify the update strategy

  • Monitor installation progress

  • Handle update failures

  • Review update scenarios

  • Use the in-place method without backward compatibility

  • Use the in-place method with backward compatibility

  • Use the database attach method for high availability of existing content

  • Verify update completion and success

Verify the update strategy

Before you start to deploy the software update, verify that the update strategy that you plan to use is optimal for your Microsoft SharePoint Foundation environment. There are several factors, such as downtime reduction, cost, and complexity that determine which strategy to use to deploy a software update. Use the flowchart in the "Determine Update Strategy" section of Prepare to deploy a software update (SharePoint Foundation 2010) to verify the update strategy that you want to use: in-place, database attach, or a hybrid.

Monitor installation progress

Monitor the update deployment process during the update to verify that the update is proceeding as planned. There may be issues that will block the update or that will result in an updated farm that has elements that do not work as expected. Pay extra attention to database synchronization and customizations.

We recommend that you use the Upgrade and Migration view in Central Administration as the primary tool for viewing product and patch installation status, data status, and upgrade status in real time.

After Setup runs, you can also view the log files and use Windows PowerShell to obtain the current results of the installation progress.

Handle update failures

SharePoint Foundation 2010 provides an improved approach to handling upgrade failures after the patching phase finishes. If an update fails and you are running in backward compatibility mode, you can restore the SharePoint Foundation database and continue to run in backward compatibility mode. After the update issue is resolved for the site, you can resume the upgrade. Any tasks that were completed are not run again. For more information, see Testing and troubleshooting upgrade (SharePoint Foundation 2010).

If an update failed in earlier SharePoint Products and Technologies environments, you usually had to uninstall the product, install the older version, and then restore from a backup.

Review update scenarios

The following software update scenarios are discussed in this article:

  • In-place without backward compatibility - The update is installed on all the farm servers at the same time and the content is upgraded without using backward compatibility.

  • In-place with backward compatibility to reduce downtime - The update is installed in stages and uses deferred upgrade with backward compatibility to reduce downtime.

  • Database attach for high content availability - This update uses two farms to provide high availability for existing content.

For more information about how the in-place and database attach processes work, see the diagrams in the following article: Upgrade process overview (SharePoint Foundation 2010). Note that these articles are about how to upgrade across software versions, not how to install software updates. However, the general process is very similar.

The following illustration shows the farm topology that is used as an example for each patching scenario that is described in this article.

Example farm for installing software update

Initial state and required conditions

The preceding illustration shows the initial state of the farm before you install the update. Verify that the following conditions are true:

  • All the front-end Web servers are load balanced together and are in rotation with the load balancer.

  • All the farm servers are operating correctly.

  • All the databases are active and operating correctly.

Do not start the software if any of the preceding conditions are not true. Resolve all issues before you continue.

Use the in-place method without backward compatibility

In this scenario the complete farm is shut down by disabling incoming requests to the front-end Web servers and then installing the update on all the farm servers. This strategy combines the update and the upgrade phase described in the "Software Update Process" section in Software updates overview (SharePoint Foundation 2010).

The following illustration shows the sequence of steps to follow to install the update on the farm.

Applying updates in-place, no backwards compat

Use the preceding illustration as a guide for using the recommended steps in the following procedure.

To install an update without backward compatibility

  1. Remove the Web servers (WEB-1 to WEB-4) from rotation in the load balancer, or pause the load balancer to stop incoming requests to the servers.

  2. Run the executable file to install the update on the Web server that hosts Central Administration (WEB-4).

  3. Verify that the server was updated successfully.

  4. Log on to the first Web server (WEB-1).

  5. Run the executable file to install the update on the Web server.

  6. Run the executable file to install the update on the remaining Web servers (WEB-2 and WEB-3).

  7. Verify that all the servers were updated successfully.

  8. Run the SharePoint Products Configuration Wizard on the Central Administration server (WEB-4) to upgrade the configuration database and upgrade each content database serially.

  9. Run the SharePoint Products Configuration Wizard on the first Web server (WEB-1).

    Note:

    Run the configuration wizard to ensure that if the update fails for a specific server, the error is not propagated to the other Web servers. For example, a failed upgrade for one server could make the upgrade fail for one or more site collections.

  10. Repeat the preceding step for each remaining Web server.

  11. Verify update completion and success. For more information, see Verify update completion and success.

  12. Add the Web servers (WEB-1 to WEB-4) to the rotation in the load balancer, or start the load balancer to enable incoming requests to the servers.

Use the in-place method with backward compatibility

This scenario takes advantage of the backward compatibility of SharePoint Foundation 2010 and the deferred upgrade feature to reduce the downtime that is required to deploy a software update. However, downtime is not completely eliminated. The sites and services will not be available while the content is being upgraded.

This software update scenario uses two phases to install the update on farm servers. These phases are as follows:

  • Update to install the update on the farm servers.

  • Upgrade to complete the patching process.

During the update phase, the farm can continue to be in production with minimal to no downtime. However, during the upgrade phase, the farm will be unavailable. If you attempt to access content while the farm is upgrading, the result could be failed upgrades or excessive slowdowns in the upgrade process because of resource contention and locking. Such an attempt is unsupported and untested.

For more information about the software update process, see "The Software Update Process" section in Software updates overview (SharePoint Foundation 2010).

Update phase

The following illustration shows the sequence of steps that are required to install the update on the farm.

In-place update with backward compatibility

Use the preceding illustration as a guide for using the recommended steps in the following procedure.

To install the update on farm servers

  1. Remove half of the Web servers (WEB-1 and WEB-2) from rotation in the load balancer, or pause the load balancer to stop incoming requests to the servers.

  2. Run the executable file to install the update on each Web server that is out of the load-balancing rotation (WEB-1 and WEB-2). Do not run the SharePoint Products Configuration Wizard on either of these servers. Verify that both of the Web servers were updated successfully.

  3. Remove the remaining Web servers (WEB-3 and WEB-4) from rotation in the load balancer, or pause the load balancer to stop incoming requests to the servers. At this point none of the front-end Web servers are receiving requests for the farm.

  4. Add the updated Web servers (WEB-1 and WEB-2) back into the load-balancing rotation.

  5. Run the executable file to install the update on each Web server that is still out of the load-balancing rotation. Do not run the SharePoint Products Configuration Wizard on either of these servers. Verify that both of the Web servers were updated successfully.

  6. Add the updated Web servers (WEB-3 and WEB-4) back into the load-balancing rotation.

  7. Verify update completion and success. For more information, see Verify update completion and success.

At this point in the process, the databases and other components such as settings, features, and site-level data must still be upgraded because the SharePoint Products Configuration Wizard was not run on any of the farm servers. However, the farm should be capable of running in backward compatibility mode.

Upgrade phase

The following illustration shows the sequence of steps that are required to finish the patching process by upgrading the farm servers. During this process, the sites that are being upgraded will not be available to users.

Use the preceding illustration as a guide for using the recommended steps in the following procedure.

Important:

Monitor the status of the upgrade on each server before you upgrade the next server in the sequence. It is highly recommended that you create a backup of the farm before beginning upgrade.

The following procedure shows all the steps to upgrade the farm. You can upgrade all components within the same outage window, or you can take some smaller outage windows and upgrade separate parts of the farm at different times. If you want to break up the upgrade stage, you can upgrade the following components in separate outage windows:

  • Services

    If the software update contains updates to services that must be applied, you can upgrade the service, and then resume operating the farm (steps 6 and 7 in the procedure) until it is possible to take a longer farm outage to complete the content and farm upgrade.

  • Content databases

    You can take a short farm outage to upgrade only a few content databases (steps 1 through 3 in the procedure) each time and then resume farm operation (steps 6 and 7). You can repeat the process over successive outage windows until all content is upgraded and the farm servers are ready to be upgraded.

    You can also upgrade individual content databases in parallel for a very small number of content databases at the same time. However, do not attempt to upgrade too many content databases in parallel because it will slow down the overall upgrade process and extend the outage time. We recommend that you do not upgrade more than two content databases on the same Microsoft SQL Server volume at a time and that you stage the starting time of the upgrade for each content database that will occur in parallel by several minutes to prevent lock contention as the upgrade process starts. In addition, limit the number of content databases that are being upgraded on a single Web or application server because each additional upgrade process will consume a relatively large amount of resources. The typical number of content databases that can be upgraded per Web or application server is four databases. However, be sure not to exceed the number of databases that are being upgraded per SQL Server volume, no matter which Web or application server originates the upgrade.

To upgrade the farm

  1. Remove the Web servers (WEB-1 to WEB-4) from rotation in the load balancer, or pause the load balancer to stop incoming requests to the servers.

    Important:

    The sites and services will not be available until upgrade is complete and the servers are returned to an active load-balancing state.

  2. Upgrade specific services, as needed.

    Some updates might also require you to run additional Windows PowerShell cmdlets to upgrade specific service applications. If the notes for the software update indicate that a specific service must be upgraded so that it will continue to operate after patching, as in the case in which a service cannot operate in backward compatibility mode, a short farm outage can be taken so that the service can be upgraded without having to upgrade the complete farm. The additional Windows PowerShell cmdlets to upgrade specific service applications should be indicated in the notes if this is required.

  3. Use the Windows PowerShell Upgrade-SPContentDatabase cmdlet to upgrade each content database.

    This is an optional step, but it will help ensure that all content databases are upgraded first. It has the advantage of enabling some parallelism to reduce the outage time. If it is not performed, all remaining non-upgraded content databases will be upgraded serially when you run the SharePoint Products Configuration Wizard to upgrade the farm servers.

    Important:

    Run the Upgrade-SPContentDatabase cmdlet for each database. You can run this cmdlet from any of the upgraded Web servers or application servers. Note that the content for each database will be unavailable while this process is running on that database.

  4. Run the SharePoint Products Configuration Wizard on the Central Administration server (WEB-4).

    Important:

    The SharePoint Products Configuration Wizard also starts an immediate upgrade of the configuration database and any other databases that are not already upgraded. Because it is likely that the content databases are the only databases that have already been upgraded, as described in the previous step, all the service application databases are also upgraded in this step. Your sites will not be available while this process runs.

  5. Run the SharePoint Products Configuration Wizard on the remaining Web servers (WEB-1 to WEB-3).

  6. Verify update completion and success. For more information, see Verify update completion and success.

  7. Add the upgraded Web servers (WEB-1 to WEB-4) back into rotation in the load balancer.

Use the database attach method for high availability of existing content

To ensure high availability for existing content, this scenario uses read-only databases on the existing farm. The update is installed on a new farm and user traffic is rerouted to this farm.

The following illustration shows the sequence of steps to follow to install the update on a new farm by using the database attach method. For more information, see Attach databases and upgrade to SharePoint Foundation 2010.

Applying updates with minimal downtime

Use the preceding illustration as a guide for using the recommended steps in the following procedure.

To install the update by using database attach

  1. Create a new farm where you will install the software update. This farm does not require front-end Web servers. For more information, see Prepare the new SharePoint Foundation 2010 environment for a database attach upgrade.

    Note:

    If the original farm uses a database mirror, you must configure mirroring after you finish deploying the software update on the new farm.

  2. Configure the databases on the existing farm so that they are in a read-only state.

    Note:

    If the existing farm is mirrored, you must pause mirroring before setting the databases to read-only.

    For more information about how to configure read-only databases, see the "Set the Previous Version Databases to Be Read-Only (Database Attach with Read-Only Databases)" section in Attach databases and upgrade to SharePoint Foundation 2010 and Run a farm that uses read-only databases (SharePoint Foundation 2010).

  3. Configure the service application databases on the existing farm so that they are in a read-only state. This prevents unexpected changes to service applications.

  4. Back up the content databases on the existing farm. For more information, see Backup and recovery (SharePoint Foundation 2010).

  5. Restore the content databases to the new database server.

  6. Create service applications on the new farm for each existing service application in the old farm.

    You must duplicate all the settings from your existing farm.

  7. Use database attach to create the databases on the new farm. For more information, see Perform a database attach upgrade to SharePoint Foundation 2010 and Attach and restore a read-only content database (SharePoint Foundation 2010).

  8. Verify that there are no issues with the new farm.

  9. Enable the new farm as the production farm by configuring DNS to point to the new farm or by making sure that the new farm is load balanced. Verify that users can access the new farm.

  10. Allow time for users to switch from cached DNS, and then decommission the old farm.

  11. Verify update completion and success. For more information, see Verify update completion and success.

Verify update completion and success

Regardless of the update strategy that you use and the monitoring that you do during the software update, you must verify update completion and success. For more information, see Verify upgrade and review upgraded sites (SharePoint Foundation 2010).

See Also

Other Resources

Resource Center: Updates for SharePoint 2010 Products


Service Pack 1 (SP1) for SharePoint Foundation 2010 (white paper)

Published: June 28, 2011

The Service Pack 1 (SP1) for SharePoint Foundation 2010 and SharePoint Server 2010 (http://go.microsoft.com/fwlink/p/?LinkId=221773) white paper describes the features that are included in Microsoft SharePoint Foundation 2010 Service Pack 1 (SP1). In addition, this paper provides some guidelines you can follow so that your solutions work with current and future versions of SharePoint Foundation 2010.

Download this white paper (http://go.microsoft.com/fwlink/p/?LinkId=221773).


Upgrading to SharePoint Foundation 2010
See Also

Welcome to the upgrade guide for Microsoft SharePoint Foundation 2010. The articles in this guide help you plan for and perform an upgrade from Windows SharePoint Services 3.0 to SharePoint Foundation 2010.

For a graphical overview of the upgrade process, and information about how to plan and test upgrade, see the following upgrade models:

  • Upgrade planning

  • Upgrade approaches

  • Test your upgrade process

In this guide:

  • About the upgrade process (SharePoint Foundation 2010)

    Learn about what's new in upgrade and how the upgrade process works.

  • Plan and prepare for upgrade (SharePoint Foundation 2010)

    Determine which approach you should take to upgrade to SharePoint Foundation 2010 and plan your upgrade process.

  • Testing and troubleshooting upgrade (SharePoint Foundation 2010)

    Learn how to test your upgrade process ahead of time to understand what issues you might face in your actual upgrade, and determine the time and space you will need for upgrade. Also, learn how to troubleshoot issues that come up during the actual upgrade.

  • Perform pre-upgrade steps (SharePoint Foundation 2010)

    Find out what steps you need to take before upgrading, including information about how to run the pre-upgrade checker.

  • Perform an in-place upgrade (SharePoint Foundation 2010)

    Follow the steps in this section if you are upgrading in-place to SharePoint Foundation 2010. When you upgrade in-place, you install SharePoint Foundation 2010 on the same hardware, and then upgrade the content and settings on the server or server farm as part of a single process.

  • Upgrading from a stand-alone installation of Windows SharePoint Services 3.0 to SharePoint Foundation 2010 when content databases exceed 4 GB (RBS)

    Follow the steps in this section if you have a standalone installation with content databases that are approaching 4 GB.

  • Perform a database attach upgrade to SharePoint Foundation 2010

    Follow the steps in this section if you are using the database attach upgrade method to upgrade to SharePoint Foundation 2010. When you use the database attach upgrade method, you upgrade the content for the environment on a separate farm.

  • Perform post-upgrade steps (SharePoint Foundation 2010)

    Find out how to tell whether upgrade was completed successfully and what steps you need to perform after the upgrade to get your environment ready for users again.

  • Using AAM URL redirection as part of the upgrade process (SharePoint Foundation 2010) (white paper)

    This white paper describes the process for using alternate access mapping URL redirection to avoid an unacceptably long period of downtime during upgrade. This is an advanced technique and requires careful planning.

  • Migrate from forms-based authentication to claims-based authentication (SharePoint Foundation 2010)

    This article provides guidance to help you migrate existing Windows SharePoint Services 3.0 Web applications, which were configured to use forms-based authentication, to work in a Microsoft SharePoint Foundation 2010 environment as claims-based Web applications.

  • Migrate from classic-mode to claims-based authentication (SharePoint Foundation 2010)

    The procedures in this article provide guidance to help you migrate existing Microsoft SharePoint Server 2010 Web applications, which were configured to use classic-mode authentication, to use claims-based authentication.

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


About the upgrade process (SharePoint Foundation 2010)
See Also

The first step in any upgrade process is to learn about the process itself so that you can plan and prepare appropriately. This section of the upgrade guide contains articles that help you understand how upgrade works.

In this section:

  • What's new in upgrade (SharePoint Foundation 2010)

    Find out about new requirements, approaches, and features that are available for upgrade to Microsoft SharePoint Foundation 2010.

  • Upgrade process overview (SharePoint Foundation 2010)

    Get a visual overview of the steps involved in each upgrade approach.

  • Upgrade from Windows SharePoint Services 2.0 to SharePoint Foundation 2010

    Understand using database attach upgrades to upgrade your content from Windows SharePoint Services 2.0 to Microsoft SharePoint Foundation 2010.

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


What's new in upgrade (SharePoint Foundation 2010)
See Also

Microsoft SharePoint Foundation 2010 has been designed for scale and performance and as such requires new hardware and software requirements that are described in this article. These requirements apply to both the in-place and the database attach upgrade approaches. For more information, see Determine upgrade approach (SharePoint Foundation 2010).

In order to facilitate a predictable upgrade and minimize the impact of customization and environmental issues that may prevent a successful upgrade, you can use the Windows PowerShelltest-spcontentdatabase cmdlet, the new Visual Upgrade option, or the preupgradecheck Stsadm operation.

In this article:

  • Upgrade requirements

  • Pre-upgrade checker

  • Windows PowerShell command to check databases before attaching

  • Visual Upgrade

  • Feature Upgrade

  • New options for reducing downtime during upgrade

  • Changes in key features between versions

Upgrade requirements

Before you can perform an in-place upgrade or database attach upgrade to SharePoint Foundation 2010, your existing Windows SharePoint Services 3.0 environment or new SharePoint Foundation 2010 environment must meet the following minimum requirements.

Note:

For more information about general system requirements for SharePoint Foundation 2010, see Hardware and software requirements (SharePoint Foundation 2010). For more information about upgrade requirements, see Review system requirements for upgrade (SharePoint Foundation 2010).

Hardware requirement: 64-bit

SharePoint Foundation 2010 can only run on a 64-bit edition of the Windows Server 2008 R2 or Windows Server 2008 with SP2 operating system. If you plan an in-place upgrade, your Windows SharePoint Services 3.0 installation must be running in a 64-bit Windows Server 2008 environment. If your Windows SharePoint Services 3.0 installation is currently in a 32-bit environment, you cannot perform an in-place upgrade on the existing server or server farm. You must install SharePoint Foundation 2010 on a different server or farm that supports 64-bit applications, and then move your data to that server or farm by using database attach upgrade.

To more easily discover and address any issues in the migration and upgrade processes, we recommend that you do not combine the actions of migrating to a 64-bit environment and upgrading in-place to SharePoint Foundation 2010. Because you must have a 64-bit environment to be able to upgrade in place to SharePoint Foundation 2010, you must migrate to a 64-bit operating system before you perform an in-place upgrade. If you are using a database attach upgrade, you can migrate to 64-bit as part of your upgrade process.

Before you migrate to a 64-bit environment:

  • Update Windows SharePoint Services 3.0 to the same service pack or software update level on all computers in the source farm.

  • Find out whether you have to recompile existing 32-bit applications and custom assemblies — for example, Web Parts and event receivers — to run in the 64-bit environment. (Some applications can run in both environments and do not have to be recompiled.) If the existing applications are third-party applications, check with the third-party vendor about 64-bit versions and compatibility.

For more information about how to plan and perform a migration to a 64-bit environment, see the article Migrate an existing server farm to a 64-bit environment (Windows SharePoint Services 3.0) on TechNet (http://go.microsoft.com/fwlink/p/?LinkId=161120).

Operating system requirement: Windows Server 2008 or Windows Server 2008 R2

SharePoint Foundation 2010 must be run on a 64-bit edition of Windows Server 2008 R2 or Windows Server 2008 with Service Pack 2 (SP2). If you are currently running Windows SharePoint Services 3.0 on Windows Server 2003 and intend to upgrade to SharePoint Foundation 2010, you must plan to have a sufficient number of Windows Server licenses for the deployment on the newer operating system.

To more easily discover and address any issues in the migration and upgrade processes, we recommend that you do not combine the actions of upgrading or migrating to Windows Server 2008 or Windows Server 2008 R2 with the process of upgrading to SharePoint Foundation 2010. You can combine migration to 64-bit hardware with migration to Windows Server 2008 or Windows Server 2008 R2.

  • If you are already running 64-bit hardware, you can upgrade from Windows Server 2003 to Windows Server 2008 or Windows Server 2008 R2. For more information about how to perform an in-place upgrade to Windows Server 2008, see the article Upgrading to Windows Server 2008 for Windows SharePoint Services 3.0 with SP1 on TechNet (http://go.microsoft.com/fwlink/p/?LinkId=155575).

  • If you are migrating to 64-bit hardware, take the opportunity to also migrate to Windows Server 2008 or Windows Server 2008 R2 at the same time. For more information about how to install Windows SharePoint Services 3.0 on Windows Server 2008, see the article Deploy a simple farm on the Windows Server 2008 operating system (Windows SharePoint Services) on TechNet (http://go.microsoft.com/fwlink/p/?LinkID=95859).

Database requirement: 64-bit SQL Server 2005 SP3 or SQL Server 2008 SP1

SharePoint Foundation 2010 requires that its database server must be a 64-bit version of one of the following: Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, or SQL Server 2005 with SP3 and Cumulative Update 3. If your current Windows SharePoint Services 3.0 installation uses SQL Server 2000, you must upgrade to one of these versions before you can upgrade to SharePoint Foundation 2010.

To more easily discover and address any issues in the migration and upgrade processes, we recommend that you do not combine the actions of migrating to 64-bit SQL Server with the process of upgrading to SharePoint Foundation 2010. You can combine the migration to 64-bit SQL Server with the overall process of migration to 64-bit hardware.

  • If you are combining the migration to SQL Server 2005 SP3 or SQL Server 2008 on 64-bit hardware with an overall migration to a 64-bit environment, follow the guidance about how to migrate to a 64-bit environment earlier in this article.

    For more information about how to migrate all databases, see the article Move all databases (Windows SharePoint Services 3.0) on TechNet (http://go.microsoft.com/fwlink/p/?LinkId=161208).

  • If you already have 64-bit hardware, but have to upgrade to SQL Server 2005 SP3 or SQL Server 2008, follow the guidance in the SQL Server documentation.

Pre-upgrade checker

The pre-upgrade checker is a command-line tool that you run in a Windows SharePoint Services 3.0 environment to find any potential issues for upgrade and to review recommendations and best practices.

STSADM.exe -o preupgradecheck

By using the pre-upgrade checker, you can find information such as the following:

  • A list of all servers and components in the farm, and whether the servers meet the following requirements for upgrading: 64-bit hardware and the Windows Server 2008 operating system.

  • The alternate access mapping URLs that are being used in the farm.

  • A list of all site definitions, site templates, features, and language packs that are installed in the farm.

  • Whether there are customizations in the farm that are not supported (such as database schema modifications).

  • Whether there are any database or site orphans in the farm.

  • Whether there are missing or invalid configuration settings in the farm (such as a missing Web.config file, invalid host names, or invalid service accounts).

  • Whether the databases meet the requirements for upgrade — for example, databases are set to read/write, and any databases and site collections that are stored in Windows Internal Database are not larger than 4 GB.

The pre-upgrade checker is available with Windows SharePoint Services 3.0 Service Pack 2 and has been updated in the October 2009 Cumulative Update for Windows SharePoint Services 3.0. You can download and install the October 2009 Cumulative Update from October 2009 Cumulative Update Packages for SharePoint Server 2007 and Windows SharePoint Services 3.0 are published (http://go.microsoft.com/fwlink/p/?LinkID=169179). For more information about how to use the pre-upgrade checker, see the following articles on TechNet:

  • Preupgradecheck: Stsadm operation (Windows SharePoint Services) (http://go.microsoft.com/fwlink/p/?LinkId=161232)

  • Pre-upgrade scanning and reporting for future releases (Windows SharePoint Services) (http://go.microsoft.com/fwlink/p/?LinkID=152468)

  • Run the pre-upgrade checker (SharePoint Foundation 2010)

Windows PowerShell command to check databases before attaching

You can use the Windows PowerShell cmdlet test-spcontentdatabase before you attach a content database to SharePoint Foundation 2010 to determine whether any server-side customizations are missing from the environment. For more information, see Attach databases and upgrade to SharePoint Foundation 2010 and Test-SPContentDatabase.

Visual Upgrade

A new feature that is available with upgrade allows the server administrator or site owner to determine when and if the new look for SharePoint Foundation 2010 is used for a particular site collection. Server administrators can choose to adopt the new look and feel for all sites during upgrade, let site owners make the choice after upgrade, or keep the old look and feel for all sites.

If the server administrator lets the site owners decide, after a site is upgraded by using an in-place upgrade, a preview option is available in the site user interface. This option provides a preview of the SharePoint Foundation 2010 look for the site:

  • If the owner likes how the site looks and functions, the owner can accept the visual upgrade.

  • If the owner wants the site to keep the old look and feel, the owner can revert to the Windows SharePoint Services 3.0 look.

By default, the Windows SharePoint Services 3.0 look is retained. For more information, see Plan visual upgrade (SharePoint Foundation 2010).

Feature Upgrade

SharePoint Foundation 2010 provides new members and types that make it possible for you to upgrade custom Features through versioning and declarative upgrade actions. You can update any Features you created for Windows SharePoint Services 3.0 to work with SharePoint Foundation 2010 by using these members. For more information, see Upgrading Features.

New options for reducing downtime during upgrade

Depending on the environment and the complexity and number of SharePoint sites, the upgrade process can take a long time. To reduce downtime during this process, SharePoint Foundation 2010 supports the following options:

  • Upgrade multiple databases at the same time (parallel upgrade) When you upgrade to SharePoint Foundation 2010, you can manually initiate upgrade for multiple databases at the same time by using the detach databases hybrid approach for upgrade. In Windows SharePoint Services 3.0, only one upgrade process could run at a time, so that each database needed to be processed sequentially. There is a performance impact when you run the upgrade on multiple databases instead of on a single database, but it may be faster to upgrade multiple databases at the same time than to upgrade them sequentially. The number of databases that can be upgraded in parallel will depend on the hardware in your environment and on the structure of the content within the databases. For more information, see Roadmap: in-place upgrade with detached databases (SharePoint Foundation 2010).

  • Use read-only databases to provide continuous access to data If you perform a database attach upgrade — and if you set the original databases to read-only mode — the old farm can continue to serve content to users while you upgrade a copy of the databases on a new farm. If you do this, users can continue to access the data, although they cannot add new data or update the data. When the new farm is ready and all content has been successfully upgraded, users can be switched over to the new live farm.

    For more information about read-only databases, see the article Run a farm that uses read-only databases (Windows SharePoint Services).

For more information about these techniques to reduce downtime, see the article Determine upgrade approach (SharePoint Foundation 2010).

Changes in key features between versions

SharePoint Foundation 2010 has a new architecture and includes many new capabilities. The following tables list some of the key changes to terminology and features that immediately affect the administration and site management process after upgrading.

Concept, term, or feature New or changed Comments

Pre-upgrade checker

New

The pre-upgrade checker is an Stsadm command-line operation that you run in an Windows SharePoint Services 3.0 environment to find any potential issues for upgrade and to review recommendations and best practices.

Unlike the pre-upgrade scan tool (Prescan.exe) that was used when upgrading to Windows SharePoint Services 3.0, the pre-upgrade checker does not make any changes to your environment. For more information, see Run the pre-upgrade checker (SharePoint Foundation 2010).

SharePoint Central Administration Web site

Changed

The Central Administration Web site has been redesigned with such new available options and functionality as the following:

  • The ribbon makes it easier for you to view or change details about a Web application by supplying all the options on the same page. For more information about Web applications, see Web applications management (SharePoint Foundation 2010).

  • Configuration Wizards have been added to make the configuration process easier by guiding you through the steps to configure the server farm. For more information, see Deploy a single server with SQL Server (SharePoint Foundation 2010).

  • You can now perform a backup from the Backup and Restore page. For more information, see Backup (SharePoint Foundation 2010).

Ribbon

New

The ribbon user interface has been introduced to ensure a consistent user experience and to make it easier for you to work with SharePoint sites. The ribbon is contextual so that you only see the options that are relevant to the tasks that you want to perform. The ribbon is also customizable.

Service applications

New

New services architecture that allows you to effectively manage and centralize services. Individual services can be configured independently and third-party companies can add services to the platform. For more information, see Configure services (SharePoint Foundation 2010).

Master pages

Changed

A site owner can now apply branding to their site, independent of other sites, and administrators can specify whether the system pages in the _Layouts folder are rendered by using the site master pages provided by site owners or by default master pages available across the system. Also, it is possible to use Windows PowerShell to specify a customer master page to system error pages, login pages, confirmation pages, and other non-site-specific pages.

Themes

Changed

SharePoint Foundation 2010 has changed the way themes work, making them easier to customize. You can import Microsoft PowerPoint 2010 themes directly into SharePoint Foundation 2010. Additionally, themes can now be applied to all subsites from this interface. For more information, see Plan for using themes (SharePoint Foundation 2010).

Business Connectivity Services (BCS)

New

Business Connectivity Services (BCS) builds on the Business Data Catalog functionality available in the previous product version to provide access to external systems from SharePoint-based solutions. BCS supports interacting with external systems using SharePoint lists and Web Parts, and also supports interacting with data from rich Office clients. For more information, see Business Connectivity Services overview (SharePoint Foundation 2010).

Claims-based authentication

New

Claims-based authentication is a new, more powerful and flexible authentication model that works with any corporate identity system, including Active Directory Domain Services (AD DS), LDAP-based directories, application-specific databases, and new user-centric identity models such as LiveID. For more information, see Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010).

Throttling and list controls

New

Throttling and list controls are two new performance controls. Throttling provides a way to control server resources and is designed so that the server can be protected from overload during peak business hours. SharePoint Foundation 2010 also provides several different settings that will restrict the queries that can be run against a large list. These settings can be configured for each Web application.

SharePoint Designer

Changed

SharePoint Foundation 2010 gives administrators added control over how SharePoint Designer is used in each Web application; for example, administrators control whether site administrators are allowed to customize master pages and layout pages, and whether site administrators can manage the URL structure of their site.

Developer dashboard

New

This is a new addition to server diagnostics and displays detailed information for each page load and therefore helps troubleshoot performance issues.

Sandboxed solutions

New

You can now enable site administrators to upload custom user code by using sandboxed solutions. For more information, see Sandboxed solutions planning (SharePoint Foundation 2010).

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010
Resource Center: What's New in SharePoint Foundation 2010


Upgrade process overview (SharePoint Foundation 2010)
See Also

You can choose between two basic upgrade approaches when you upgrade from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010: in-place upgrade and database attach upgrade. An in-place upgrade is used to upgrade all Microsoft SharePoint sites on the same hardware. A database attach upgrade enables you to move your content to a new farm or new hardware. You can also combine these two types of upgrade in hybrid approaches that reduce downtime during an upgrade.

For more information about these approaches, see Determine upgrade approach (SharePoint Foundation 2010).

This article helps you understand the steps that are involved in performing upgrades by using these approaches so that you can plan your upgrade process. For detailed information about how to use one of these upgrade processes, see the following topics:

  • Upgrade in place to SharePoint Foundation 2010

  • Attach databases and upgrade to SharePoint Foundation 2010

In this article:

  • In-place upgrade

  • Database attach upgrade

  • Hybrid approach 1: Read-only databases

  • Hybrid approach 2: Detach databases

Important:

It is important that the server administrator communicate with site owners and users about what to expect during an upgrade. The administrator should inform them about downtime and the risk that the upgrade may take longer than expected or that some sites may need some rework after upgrade. For more information, see Create a communication plan (SharePoint Foundation 2010).

In-place upgrade

An in-place upgrade takes place on the same hardware as your previous version installation. When you run an in-place upgrade, the process upgrades the complete installation in a fixed order.

The following steps explain what happens as the in-place upgrade process runs:

  1. After the server administrator performs all pre-upgrade steps, the administrator runs Setup for SharePoint Foundation 2010 on the server that runs the SharePoint Central Administration Web site. Because the previous version was installed, an in-place upgrade is automatically selected.

  2. After Setup runs on the server that hosts the Central Administration Web site, the server administrator runs Setup on the remaining front-end Web servers and application servers in the farm.

  3. The server administrator runs the SharePoint Products Configuration Wizard on the server that hosts the Central Administration Web site. This server, the configuration database, the services, and the content databases are upgraded sequentially.

    When the configuration wizard finishes, the Central Administration Web site opens. A timer job schedules the upgrade process to run for each site collection. The upgrade process timer job upgrades each site collection. After all sites are upgraded, the upgrade process ends.

  4. The server administrator runs the SharePoint Products Configuration Wizard on all the other servers in the farm.

    In-place upgrade process

  5. The server administrator confirms that the upgrade has finished successfully.

  6. If Visual Upgrade is being used, the server administrator or site owner previews sites in the Microsoft SharePoint Foundation 2010 look. When the administrator or site owner is ready, he or she completes the change to the SharePoint Foundation 2010 look.

Database attach upgrade

A database attach upgrade enables you to move to new hardware or a new farm. During a database attach upgrade, you detach all the content databases from an existing farm and then attach the databases to a new server farm installation. When you attach the databases to the new server farm, the upgrade process runs and upgrades the data in place.

The following steps explain what happens during a database attach upgrade:

  1. The server administrator sets up and configures a new SharePoint Foundation 2010 farm. The administrator transfers all customizations to the new farm and tests the environment.

    For more information about how to configure the new environment, see Prepare the new SharePoint Foundation 2010 environment for a database attach upgrade.

  2. The server administrator detaches the content databases from the old Windows SharePoint Services 3.0 farm and takes the old farm offline (for example, by changing the load balancer or IIS Web applications to stop service requests, or by turning off all the components and services on each server computer in the farm).

  3. The server administrator attaches the content databases to the new farm and upgrades the content.

    Database migration upgrade process

  4. The server administrator confirms that the upgrade has finished successfully and then configures the new farm to start serving requests at the new URL.

Hybrid approach 1: Read-only databases

This approach gives users continuous read-only access to their data while you upgrade. The content databases in the original farm are set to read-only, and copies of the databases are upgraded on a new farm.

The following steps explain what happens during a database attach upgrade with read-only databases:

  1. The server administrator sets up and configures a new SharePoint Foundation 2010 farm. The administrator transfers all customizations to the new farm and tests the environment.

  2. The server administrator changes the content databases to read-only. The administrator then uses SQL Server to back up the content databases on the Windows SharePoint Services 3.0 farm and restore them to the new farm.

    Read-only databases upgrade process - part1

  3. The server administrator attaches the new copies of the content databases, and the upgrade process runs and upgrades the content.

    Read-only databases upgrade process - part2

  4. After the upgrade process runs, the server administrator confirms that the upgrade has finished successfully. The administrator then configures the new farm to start serving requests at the new URL and takes the original farm offline (for example, by changing the load balancer or IIS Web applications to stop service requests, or by turning off all the components and services on each server computer in the farm).

Hybrid approach 2: Detach databases

This approach enables you to speed up the upgrade process by detaching and attaching databases to upgrade multiple databases at the same time. It is an in-place upgrade because you are upgrading the original farm; however, you can also use another farm to perform the upgrade and then attach the upgraded databases to your original farm. Note that the original farm cannot serve requests during the upgrade process. As in a standard in-place upgrade, users cannot access their content while the upgrade is in progress.

The following steps explain what happens during an in-place upgrade with detached databases:

  1. The server administrator takes the original farm offline (for example, by changing the load balancer or IIS Web applications to stop service requests, or by turning off all of the components and services on each server computer in the farm).

  2. The server administrator detaches the content databases from the original farm.

  3. The server administrator runs an in-place upgrade on the original farm servers, services, and configuration database.

  4. The server administrator attaches the content databases to the original farm and upgrades the content.

    Detach databases upgrade process - part1

Alternatively, you can use a separate, temporary small farm to perform the upgrade. In this approach, you attach the databases to the original farm after they have been upgraded.

The following steps explain what happens during an in-place upgrade with detached databases and a temporary small farm to upgrade the content databases:

  1. The server administrator sets up a temporary small farm that is running the new version. Then the administrator takes the original farm offline (for example, by changing the load balancer or IIS Web applications to stop service requests, or by turning off all the components and services on each server computer in the farm).

  2. The server administrator detaches the content databases from the original farm.

  3. The server administrator runs an in-place upgrade on the original farm to upgrade the servers, services, and configuration database.

  4. The server administrator attaches the content databases to the temporary small farm and upgrades them in parallel.

  5. The server administrator reattaches the content databases to the original farm.

    Detach databases upgrade process - part2

  6. The server administrator confirms that the upgrade has finished successfully.

  7. If Visual Upgrade is being used, the server administrator or site owner previews sites in the Microsoft SharePoint Foundation 2010 look. When the administrator or site owner is ready, he or she completes the change to the Microsoft SharePoint Foundation 2010 look.

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Upgrade from Windows SharePoint Services 2.0 to SharePoint Foundation 2010
See Also

You cannot upgrade directly from Windows SharePoint Services 2.0 to Microsoft SharePoint Foundation 2010.

The changes between versions are too great, and the hardware requirements differ so much between versions that a direct, in-place upgrade is not possible or supported. You can, however, perform a series of database attach upgrades to first upgrade your content to Windows SharePoint Services 3.0 and then to SharePoint Foundation 2010. This article describes the process of performing this double-database attach upgrade.

Note:

During this entire process, your old environment should be offline, to prevent users from making changes in the old environment while you are upgrading. After you have finished and validated the upgrade, you can grant access to your users again in the SharePoint Foundation 2010 environment.

In this article:

  • Process overview

  • Before you begin

  • Prepare to upgrade

  • Prepare your farms

  • Perform the first upgrade

  • Perform the second upgrade

Process overview

Because this upgrade approach combines two upgrade processes that have already been documented, this article describes how the steps from each process fit together into the overall process. It does not provide details for every step, because those steps are available in the following articles:

  • Deploy a new server farm, then migrate content databases

  • Attach databases and upgrade to SharePoint Foundation 2010

These articles, combined with this roadmap, give you the information you need to perform the double-database attach upgrade.

Important:

Make sure that you try out this entire process in a test environment before you attempt to upgrade your actual live content. For more information about how to test your upgrade processes, see the following content:

  • Use a trial upgrade to find potential issues (Windows SharePoint Services)

  • Use a trial upgrade to find potential issues (SharePoint Foundation 2010) and the Test your upgrade process model on TechNet.

Upgrade sequence

To upgrade your content across the two versions, follow these steps.

  1. Prepare to upgrade

    1. Prepare your original farm by running the pre-upgrade scan tool and making an inventory of all of your customizations.

    2. Set up a small, temporary farm that is running Windows SharePoint Services 3.0.

    3. Set up your full SharePoint Foundation 2010 farm, and verify that it is configured and running correctly.

  2. First upgrade: Upgrade the content to Windows SharePoint Services 3.0

    1. Detach the content databases from the old farm, and then take that farm offline.

      Alternatively, you can leave the databases attached and make a copy of the databases if you want to ensure that your original farm can be restored to use quickly.

    2. Attach the content databases to the Windows SharePoint Services 3.0 farm and upgrade them.

    3. Verify that the content has been upgraded and that the Windows SharePoint Services 3.0 farm is working correctly.

  3. Second upgrade: Upgrade the content to SharePoint Foundation 2010

    1. Detach the content databases from the Windows SharePoint Services 3.0 farm.

    2. Attach the content databases to the SharePoint Foundation 2010 farm and upgrade them (optionally, you can upgrade them in parallel).

    3. Verify that the content has been upgraded and that the SharePoint Foundation 2010 farm is working correctly.

  4. Start serving requests on the SharePoint Foundation 2010 farm.

The following diagrams illustrate this process:

The database attach upgrade to Windows SharePoint Services 3.0.

Database attach to Windows SharePoint Services 3.0

The database attach upgrade to SharePoint Foundation 2010.

Database attach to SharePoint Foundation 2010

Before you begin

Before you begin your upgrade, review the following information about permissions, hardware requirements, and software requirements. Follow the specified steps to install or configure prerequisite software or to modify settings.

Review required permissions

  • When you create your temporary environment for Windows SharePoint Services 3.0, you must have the appropriate permissions. For more information, see Plan for administrative and service accounts (Windows SharePoint Services).

  • When you create and configure your destination SharePoint Foundation 2010 farm, you must have the appropriate permissions. For more information, see Initial deployment administrative and service accounts (SharePoint Foundation 2010).

Review required hardware and software

  • When you create your temporary environment for Windows SharePoint Services 3.0, you must meet specific hardware and software requirements. For more information, see Determine hardware and software requirements (Windows SharePoint Services).

  • When you create and configure your destination SharePoint Foundation 2010 farm, you must meet different hardware and software requirements. For more information, see Hardware and software requirements (SharePoint Foundation 2010).

In some environments, you must coordinate the procedures for moving databases to a separate farm with the database administrator. Make sure that you follow any applicable policies and guidelines for handling databases.

Prepare to upgrade

Because you are performing two upgrades, you need to understand all of the steps involved both in upgrading to Windows SharePoint Services 3.0 and to SharePoint Foundation 2010. The following content is available to help you understand these upgrade processes:

Preparing to upgrade to Windows SharePoint Services 3.0

  • Read the Plan and prepare for upgrade chapter on TechNet. In particular, read the following articles:

    • How the upgrade process works (Windows SharePoint Services)

    • Determine how to handle customizations (Windows SharePoint Services)

    • Develop new custom site definitions and create upgrade definition files (Windows SharePoint Services)

  • Read the Perform pre-upgrade steps (Windows SharePoint Services) chapter on TechNet. You must perform the following steps for a database attach upgrade (called database migration in this version):

    • Install Service Pack 2 for Windows SharePoint Services 2.0

    • Run the pre-upgrade scan tool (Windows SharePoint Services)

    Important:

    You follow these steps on your existing Windows SharePoint Services 2.0 farm.

Preparing to upgrade to SharePoint Foundation 2010

  • Plan and prepare for upgrade. Read the following article on TechNet:

    • Upgrade process overview (SharePoint Foundation 2010)

  • Perform pre-upgrade steps. Read the following article on TechNet:

    • Run the pre-upgrade checker (SharePoint Foundation 2010)

    Important:

    You perform these steps on your temporary Windows SharePoint Services 3.0 farm.

Prepare your farms

In this step, you follow the pre-upgrade steps on your existing farm, create your temporary farm for the upgrade to Windows SharePoint Services 3.0, and create your destination SharePoint Foundation 2010 farm. Use the following steps and related content when preparing your farm for the upgrades.

Create the temporary Windows SharePoint Services 3.0 farm

In a virtual or physical environment, create a temporary small farm that is running Windows SharePoint Services 3.0 with Service Pack 2 (SP2) and the October 2009 Cumulative Update. You will use this farm to upgrade your content to Windows SharePoint Services 3.0 on the way to SharePoint Foundation 2010.

Tip:

For best results, it is recommended that you apply the latest updates to the environment. The October 2009 Cumulative Update includes changes to the pre-upgrade checker that can help identify issues before upgrade. For a list of available updates, see Update Center for Microsoft Office, Office Servers, and Related Products (http://go.microsoft.com/fwlink/p/?LinkID=181115). For more information about applying updates, see Updates Resource Center for SharePoint Products and Technologies (http://go.microsoft.com/fwlink/p/?LinkID=181116).

  1. Download the software for the temporary farm.

    Download Windows SharePoint Services 3.0 with SP2 at one of the following links:

    • x86 version: Windows SharePoint Services 3.0 with Service Pack 2 (http://go.microsoft.com/fwlink/p/?LinkID=148403)

    • x64 version: Windows SharePoint Services 3.0 x64 with Service Pack 2 (http://go.microsoft.com/fwlink/p/?LinkId=181113)

  2. Install any language template packs needed for your sites. For more information, see Install available language template packs (Windows SharePoint Services).

  3. Configure the farm by using the appropriate farm settings for your environment and reapplying all of the customizations needed by your content. Make sure that you deploy the customizations and the upgrade definition files needed for any custom site definitions that might exist in your environment. You must create Web applications on the temporary farm for every virtual server that you had in your original farm. The URL for the new Web applications should match either the source farm URLs or the destination farm URLs, otherwise you risk adding references to additional temporary URLs to the content. Ideally, you should use the same URLs for the source farm and destination farm, so that the temporary farm URLs are exactly the same as well, including the port numbers used.

    For more information about configuring the farm, see Prepare the new Windows SharePoint Services 3.0 environment. For more information about deploying custom site definitions and upgrade definitions, see Deploy upgrade definition files and new site definitions (Windows SharePoint Services).

Set up your full SharePoint Foundation 2010 farm

This is the farm you will use for your production environment eventually, so make sure that you plan your infrastructure appropriately to support the solution you are hosting. For more information about how to plan your server farm, see Server farm and environment planning (SharePoint Foundation 2010).

  1. Create your farm on 64-bit hardware with database servers that are running a 64-bit version of Microsoft SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2. For more information, see Multiple servers for a three-tier farm (SharePoint Foundation 2010).

  2. Install any language template packs needed for your sites. For more information, see Install available language template packs (SharePoint Foundation 2010).

  3. Configure the farm by using the appropriate farm settings for your environment and reapplying all of the customizations needed by your content. Again, you must create Web applications on the destination farm for every virtual server that you had in your original farm.

    For more information about how to create and configure a server farm for a database attach upgrade, see Prepare the new SharePoint Foundation 2010 environment for a database attach upgrade.

Perform the first upgrade

With your farms set up and configured, you are ready to upgrade your content databases to Windows SharePoint Services 3.0.

Important:

Make sure that you have run the pre-upgrade scan tool on your original farm before you detach the databases. The upgrade process will not run if you have not scanned the databases. For more information, see Run the pre-upgrade scan tool (Windows SharePoint Services).

To perform a database attach upgrade (called database migration for this version), follow these steps:

  1. Back up the content databases.

  2. Restore the backed-up copies to your temporary farm.

  3. Add the databases to the Web applications to start the upgrade process.

For complete information and steps to follow, see Migrate content databases.

Verify the first upgrade

To verify the upgrade, do the following:

  • Review the upgrade log file. For more information, see Migrate content databases.

  • Review the upgraded sites to make sure that they still work as expected and that your Web Parts and other custom elements work correctly.

Perform the second upgrade

After you have verified that your sites work correctly, you can begin the upgrade to SharePoint Foundation 2010.

Important:

Run the pre-upgrade checker and review the report so that you can address any potential issues on your temporary farm before you upgrade the content. For more information, see Run the pre-upgrade checker (SharePoint Foundation 2010).

To perform the database attach upgrade, follow these steps:

  1. Back up the content databases.

  2. Restore the backed-up copies to your destination farm.

  3. Add the databases to the Web applications to start the upgrade process. In SharePoint Foundation 2010, you can attach databases in parallel to speed up the upgrade process.

For complete information and steps to follow, see Attach databases and upgrade to SharePoint Foundation 2010.

Verify the second upgrade

To verify the upgrade, do the following:

  • Review the upgrade log file.

  • Review the upgraded sites to make sure that they still work as expected and that your Web Parts and other custom elements work correctly.

For more information, see Verify upgrade and review upgraded sites (SharePoint Foundation 2010).

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Plan and prepare for upgrade (SharePoint Foundation 2010)
See Also

Now that you have learned how the upgrade process works by reading the articles in About the upgrade process (SharePoint Foundation 2010), you can begin your upgrade planning. This section contains articles that help you plan and prepare for upgrading from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010.

In this section:

  • Determine upgrade approach (SharePoint Foundation 2010)

    Learn about the different upgrade approaches and choose the one that is best suited to your environment.

  • Review upgrade best practices (SharePoint Foundation 2010)

    Avoid problems during the upgrade process by following these best practices.

  • Review supported and unsupported upgrade paths (SharePoint Foundation 2010)

    Understand which installation types and topologies can be upgraded to SharePoint Foundation 2010.

  • Review system requirements for upgrade (SharePoint Foundation 2010)

    Review the requirements to help ensure that your environment can be upgraded to SharePoint Foundation 2010.

  • Determine how to handle customizations (SharePoint Foundation 2010)

    Learn how to identify and evaluate the customizations in your environment, and determine whether you will upgrade them, and how.

  • Create a communication plan (SharePoint Foundation 2010)

    Create a plan to coordinate and communicate with the upgrade team, site owners and users, and stakeholders.

  • Plan visual upgrade (SharePoint Foundation 2010)

    Learn about the different visual upgrade options and how to choose the option that best suits your business needs.

A worksheet is available so you can record information about your environment while you prepare for upgrade. Download the worksheet from http://go.microsoft.com/fwlink/p/?LinkId=179928.

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Determine upgrade approach (SharePoint Foundation 2010)
See Also

Before you run any process to upgrade from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010, you have to determine which upgrade approach to take. Use the information in this article to help compare the pros and cons for each approach and to review information about special cases that might influence your approach. In addition to the information in this article, be sure to read Review supported and unsupported upgrade paths (SharePoint Foundation 2010) to understand exactly which upgrade situations are valid and lead to successful upgrades.

Note:

To perform an upgrade, you must have installed Windows SharePoint Services 3.0 with Service Pack 2 (SP2).

In this article:

  • Choose an upgrade approach

  • Special cases

Choose an upgrade approach

There are two basic approaches to upgrade: in-place and database attach. In addition, there are various techniques you can use to combine aspects of these basic approaches to mitigate downtime or potentially improve performance.

The following table compares the in-place and database attach approaches.

Approach | Description | Pros | Cons
In-place upgrade | You can install SharePoint Foundation 2010 on the same hardware. You can also upgrade the content and settings in the server farm as part of a single process. | Farm-wide settings are preserved and upgraded. Customizations are available in the environment after the upgrade, although manual steps may be required to upgrade or rework them. | Servers and farms are offline while the upgrade is in progress. The upgrade proceeds continuously. Consequently, you must allocate enough time for all content to be upgraded in sequence.
Database attach upgrade | You can upgrade the content for the environment on a separate farm. The result is that you do not upgrade any of the services or farm settings. You can upgrade the databases in any order and upgrade several databases at the same time. While each database is being upgraded, the content in that database is not available to users. | You can upgrade multiple content databases at the same time, which results in faster upgrade times overall than an in-place upgrade. You can use a database attach upgrade to combine multiple farms into one farm. | The server and farm settings are not upgraded. You must manually transfer settings that you want to preserve from the old farm to the new farm. Any customizations must also be transferred to the new farm manually. Any missing customizations may cause unintended losses of functionality or user experience issues. Copying databases over a network takes time and bandwidth. You must plan for that. You need direct access to the database servers.

For more information about how in-place and database attach upgrades work, see Upgrade process overview (SharePoint Foundation 2010).

The following table lists the downtime mitigation techniques that you can use during upgrade to reduce the amount of time that users cannot access their content or to potentially increase upgrade performance.

Technique Description Pros Cons

Parallel upgrade

You can attach and upgrade multiple databases at a time to speed up the upgrade process overall. The maximum number of parallel upgrades depends on your hardware. This technique works for either in-place or database attach upgrades.

Faster upgrade times for your overall environment.

This is a manual process that requires additional steps and monitoring.

Hybrid approach 1: Database attach with read-only databases

Lets you continue to provide read-only access to content during the upgrade process. For this approach, you set the databases to read-only while the upgrade is in progress on another farm. This method reduces perceived downtime for your users.

The existing farm can continue to host non-upgraded sites (in read-only mode) while you upgrade the content. As a result, there is minimal downtime for users.

You can upgrade multiple content databases at the same time, which results in faster upgrade times overall than an in-place upgrade.

You can upgrade hardware in addition to software.

The server and farm settings are not upgraded. You must manually transfer settings that you want to preserve from the old farm to the new farm.

Any customizations must also be transferred and upgraded manually. Any missing customizations may cause unintended losses of functionality or user experience issues.

Copying databases over a network takes time and bandwidth. You must plan for that.

You need direct access to the database servers.

Hybrid approach 2: In-place upgrade with detached databases

Lets you take advantage of an in-place upgrade's ability to upgrade content and settings, while adding the speed of a database attach upgrade. For this approach, you use an in-place upgrade to upgrade the farm and settings, and to detach and upgrade multiple databases in parallel (on the same farm or a separate farm).

Farmwide settings can be preserved and upgraded.

Customizations are available in the environment after upgrade, although manual steps may be required to upgrade or rework them.

You can upgrade multiple content databases at the same time, which results in faster upgrade times overall than an in-place upgrade.

Copying databases over a network takes time and bandwidth. You must plan for that.

You need direct access to the database servers.

Be aware that you can also combine these techniques. For example, you can set your original farm to read-only mode, create a copy of the farm and upgrade it without the content databases, use parallel upgrade to rapidly upgrade all the user content, and then finally switch users to the new farm after upgrade is completed. For more information about these downtime mitigation techniques work, see Upgrade process overview (SharePoint Foundation 2010).

Another option to consider if you are facing an overly long outage window is to use Alternate Access Mapping URL Redirection with a database attach approach, so that you temporarily redirect users to an existing farm while you upgrade the content on a new farm. This is an advanced method and should not be used unless other downtime mitigation techniques are not sufficient. For more information, see Using AAM URL redirection as part of the upgrade process (SharePoint Foundation 2010) (white paper).

Special cases

You might have other requirements or additional goals that you want to achieve when you perform an upgrade. The following table lists special cases and describes which upgrade approach is appropriate for each case.

Case Upgrade approach

Upgrading a stand-alone installation with Windows Internal Database?

If you are running Windows SharePoint Services 3.0 on a stand-alone server with Windows Internal Database, your database will be migrated to SQL Server Express as part of the in-place upgrade process. If your database is larger than 4 GB, you must configure Remote BLOB Storage to store some of the data. For more information, see Upgrade a stand-alone installation by using RBS (in-place) (SharePoint Foundation 2010).

Upgrading from a 32-bit to a 64-bit edition of SQL Server?

If you are running a 32-bit edition of SQL Server, you must migrate to a 64-bit edition. We recommend that you perform this migration before you upgrade to SharePoint Foundation 2010 to ensure best performance benefits. Ensure that you perform only one kind of upgrade or migration at a time to avoid upgrade failure. For more information, see Migrate an existing server farm to a 64-bit environment (Windows SharePoint Services 3.0).

The following are two options for upgrading from a 32-bit to a 64-bit edition of SQL Server:

  • You can back up the whole set of databases for the farm, perform the upgrade, and then restore the databases. (This option is supported and recommended because you will have a full backup, and after you restore the databases, you do not have to change anything within SharePoint Foundation 2010).

  • You can move the SQL Server databases that you want to upgrade to a different 64-bit edition of SQL Server. You must add the different 64-bit edition, and then run a command to the computers running SharePoint Foundation 2010 to point them to the new 64-bit edition of SQL Server. (This option is supported but not recommended because it requires more work in SharePoint Foundation 2010 when, for example, the databases change location).

Note:

If you upgrade a SQL Server version — for example, from SQL Server 2005 SP2 to SQL Server 2008 — you can perform this upgrade before, during, or after you upgrade from a 32-bit to a 64-bit edition of SQL Server.

Upgrading from Windows Server 2003 to Windows Server 2008?

Upgrade the operating system before you attempt to upgrade to SharePoint Foundation 2010.

If you are running Windows SharePoint Services 3.0, you must perform specific steps to upgrade to Windows Server 2008. For more information, see Upgrading to Windows Server 2008 for Windows SharePoint Services 3.0 with SP1.

Upgrading from a 32-bit operating system to a 64-bit operating system?

If you are using a 32-bit operating system, you must migrate to a 64-bit operating system before you upgrade. For more information, see Migrate an existing server farm to a 64-bit environment (Windows SharePoint Services 3.0).

Upgrading an environment that uses forms-based authentication?

Additional steps are required to upgrade when you are using forms-based authentication. For more information, see Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010).

Upgrading very large databases?

In general, very large databases — particularly databases that have a large number or large size of document versions inside them — take longer to upgrade than smaller databases. However, the complexity of the data determines how long it takes to upgrade, not the size of the database itself. If the upgrade process times out, it is usually because of connection issues. In Windows SharePoint Services 3.0, the upgrade process often timed out because of the time needed to execute a process, but this is rarely the case with SharePoint Foundation 2010. For more information about how long upgrade might take for your environment, see Estimate how long the upgrade process will take and the space that you need (SharePoint Foundation 2010).

Upgrading databases with a large number of site collections?

If you have 5,000 or more site collections in a database, consider breaking them out into multiple databases. In Windows SharePoint Services 3.0, there was a default warning at 9,000 site collections and a hard limit at 15,000 site collections. In SharePoint Foundation 2010, these values change to 2,000 site collections for the warning and 5,000 site collections for the limit. To avoid errors during upgrade or broken sites after upgrade, we recommend that you move some site collections into separate databases. If you have multiple content databases, you can also speed up your upgrade process by upgrading multiple databases in parallel.

For more information about moving site collections to a new database, see Move site collections to a new database (split a content database) (Windows SharePoint Services 3.0).

Upgrading from Windows SharePoint Services 2.0?

Use a database attach upgrade method to upgrade to Windows SharePoint Services 3.0, and then upgrade to SharePoint Foundation 2010. For more information about this upgrade process, see Upgrade from Windows SharePoint Services 2.0 to SharePoint Foundation 2010.

Changing languages?

You have two choices, depending on whether a single site or your entire environment is changing languages:

  • To change the language for a specific site, upgrade in the same language, and then install the new language pack and change to that language.

    Caution:

    You must have the appropriate language packs installed to upgrade any sites based on a localized site definition. If you do not have the new language pack, the sites will not be accessible. Wait for the new language packs to be released before attempting to upgrade those sites.

    Also, you must have any language packs you used for Windows SharePoint Services 3.0 installed before you can perform an in-place upgrade.

  • To change the installation language for your servers, use the database migration approach to migrate your data from the old version and language to the new version and language.

Using internationalized domain names?

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

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Review upgrade best practices (SharePoint Foundation 2010)
See Also

To ensure a smooth upgrade from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010, follow these best practices:

  1. Update your servers to Service Pack 2 (SP2) of Windows SharePoint Services 3.0 or later.

    Your environment must be updated to Service Pack 2 of Windows SharePoint Services 3.0 to run the upgrade process, either for an in-place or database attach upgrade. We recommend that you install the October 2009 Cumulative Update because it includes improvements to the pre-upgrade checker tool. For more information about how to install service packs and updates, see the Updates Resource Center for SharePoint Products and Technologies. For a list of all available updates, see Update Center for Microsoft Office, Office Servers, and Related Products.

  2. Ensure that the environment is fully functioning before you perform an upgrade.

    An upgrade does not solve any problems that might already exist in your environment. Therefore, ensure that the environment is fully functioning before you perform an upgrade. For example, if you have Web applications that are no longer being used, unextend them before you upgrade. If you want to delete a Web application in Internet Information Services (IIS), unextend the Web application before you delete it; otherwise, SharePoint Foundation 2010 will try to upgrade the Web application even though it does not exist, and the upgrade will fail. If you find and solve problems beforehand, you are more likely to meet the upgrade schedule that you have estimated.

  3. Before you try an in-place upgrade, migrate to 64-bit servers. Upgrade your operating system to a 64-bit version of Windows Server 2008 R2 or Windows Server 2008 with Service Pack 2 (SP2). If you are using SQL Server, upgrade or migrate to a 64-bit version of Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, or SQL Server 2005 with SP3 and Cumulative Update 3.

    Do not try to combine these operations with your upgrade process. You cannot perform an in-place upgrade unless your system already runs on a supported operating system and platform. For more information, see What's new in upgrade (SharePoint Foundation 2010).

  4. Run the pre-upgrade checker to look for potential issues.

    The pre-upgrade checker reports missing customizations and issues with orphaned sites, and more, so that you can address these issues before you perform your upgrade. For more information, see Run the pre-upgrade checker (SharePoint Foundation 2010).

  5. Perform a trial upgrade on a test farm first.

    Back up the live farm, restore to test servers, and then perform the upgrade. Examine the results to set expectations for what the live upgraded sites will look like, to determine how much post-upgrade customization will have to be done, and to estimate how long the upgrade will take. Try a full search indexing crawl. For more information, see Use a trial upgrade to find potential issues (SharePoint Foundation 2010).

  6. Plan for capacity.

    Ensure that you have disk, processor, and memory capacity sufficient to handle upgrade requirements. For more information about system requirements, see Review system requirements for upgrade (SharePoint Foundation 2010). For more information about how to plan the disk space that is required for upgrade, see Estimate how long the upgrade process will take and the space that you need (SharePoint Foundation 2010).

  7. Back up your environment.

    Perform a full backup of your environment before upgrading. That way, you can recover your environment if you must roll back from an upgrade. For more information, see Back up the entire environment before an in-place upgrade (SharePoint Foundation 2010).

  8. Optimize your environment before upgrade.

    A few key limits have changed in SharePoint Foundation 2010, such as query throttling on large lists and lower limits on the number of site collections allowed per content database (from 5,000 warning and 15,000 limit to 2,000 warning and 5,000 limit). Be sure to optimize your Windows SharePoint Services 3.0 environment to meet these limits or restrictions before upgrade to mitigate errors during the upgrade process or broken lists or sites after upgrade. For more information about the site collection limit, see SharePoint Server 2010 Capacity Management: Software Boundaries and Limits. For more information about large lists and addressing the lower limit on site collections, see Clean up an environment before upgrade (SharePoint Foundation 2010).

  9. (Optional) If you are using the database attach upgrade method, set the original databases to read-only.

    If you expect a long outage window while you perform a database attach upgrade, you can set the databases in the original environment to be read-only so that users can continue to access their data without changing it. For more information, Attach databases and upgrade to SharePoint Foundation 2010.

  10. Do not add any servers to your server farm after you begin the upgrade process.

    Running the SharePoint Products Configuration Wizard upgrades the configuration database. The configuration database contains the list of servers in the farm. Servers added to the farm after the configuration wizard has been run are not included in the database. Therefore, servers added after the wizard runs do not appear in the upgraded version topology. If you need to add servers to your farm, do so either before you start the upgrade or after you have completed the upgrade process.

  11. After upgrade, review the Upgrade Status page and upgrade logs to determine whether there are issues that must be addressed. Then review the upgraded sites.

    The Upgrade Status page reports on the upgrade progress, and the upgrade logs list any errors or warnings that occurred during the upgrade process. You should verify all of the sites and test them before you consider the upgrade complete. For more information, see Verify upgrade and review upgraded sites (SharePoint Foundation 2010).

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Review supported and unsupported upgrade paths (SharePoint Foundation 2010)
See Also

When you plan your upgrade process, make sure that you verify that the upgrade path you want to pursue is supported. This article describes supported and unsupported upgrade paths for an in-place upgrade, and covers which specific topologies can be upgraded in place to Microsoft SharePoint Foundation 2010.

Review supported topologies for upgrade

When you upgrade, you must upgrade to the same kind of installation: stand-alone to stand-alone, or server farm to server farm. You cannot migrate from stand-alone to farm or vice versa during an in-place upgrade process. However, either before or after you upgrade, you can change the size and scale of a server farm to suit your requirements. Or, if you perform a database attach upgrade, you can attach the databases to a different installation type.

Physical topology guidance

The Microsoft SQL Server topology — in addition to your network, physical storage, and caching — can significantly affect system performance. In planning your hardware, remember that for in-place upgrade, the server or server farm that you upgrade must be running a 64-bit version of Windows Server 2008 R2 or Windows Server 2008 with Service Pack 2 (SP2). For server farms, you must also be running a 64-bit version of Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, or SQL Server 2005 with SP3 and Cumulative Update 3. For more information about upgrade requirements, see Review system requirements for upgrade (SharePoint Foundation 2010).

Supported topologies

The following table lists the supported starting topologies in Windows SharePoint Services 3.0, and the supported and unsupported ending topologies when you upgrade in place to SharePoint Foundation 2010.

Starting topology (Windows SharePoint Services 3.0) | Supported ending topology (SharePoint Foundation 2010) | Unsupported ending topology (SharePoint Foundation 2010)
Stand-alone server with Windows Internal Database | Stand-alone server with Microsoft SQL Server 2008 Express | Any farm
Single server with SQL Server | Single server with SQL Server | Stand-alone server with Microsoft SQL Server 2008 Express
Any size farm | Any size farm | Stand-alone server with Microsoft SQL Server 2008 Express

Migrating from a stand-alone server to a server farm

If you want to change from a stand-alone server to a server farm, you can do so before you upgrade. To migrate from a stand-alone server to a server farm configuration, you must first create a new farm, and then move the databases from the stand-alone server to the server farm. For more information, see Migrate content databases from Windows Internal Database to an instance of SQL Server (Windows SharePoint Services 3.0). After you have migrated, you can perform your upgrade to SharePoint Foundation 2010.

Migrating from 32-bit hardware

You cannot upgrade in-place from Windows SharePoint Services 3.0 to SharePoint Foundation 2010 if you are on 32-bit hardware. If you start in 32-bit, you must first migrate to 64-bit hardware. For more information, see Migrate an existing server farm to a 64-bit environment (Windows SharePoint Services 3.0).

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Review system requirements for upgrade (SharePoint Foundation 2010)
See Also

Before you can upgrade your environment from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010, your servers must meet the following minimum requirements:

  • The hardware and software must meet or exceed the minimum system requirements to run the new version.

    This includes the requirement for 64-bit hardware and 64-bit versions of the operating system and Microsoft SQL Server. Before you begin the upgrade process, make sure that your system meets or exceeds the minimum requirements in Hardware and software requirements (SharePoint Foundation 2010). Before upgrading, determine how much production capacity you have to have in your upgraded environment and identify the hardware that you must have for your upgrade based on that information.

  • Windows SharePoint Services 3.0 must be updated to Service Pack 2

    Your environment must be updated to at least Service Pack 2 of Windows SharePoint Services 3.0 to run the upgrade process, either for an in-place or database attach upgrade. We recommend that you install the October 2009 Cumulative Update because it includes improvements to the pre-upgrade checker tool. For more information about how to install service packs and updates, see the Updates Resource Center for SharePoint Products and Technologies. For a list of all available updates, see Update Center for Microsoft Office, Office Servers, and Related Products.

About these requirements

It is important that your hardware meet at least the minimum requirements that are listed in the article Hardware and software requirements (SharePoint Foundation 2010); otherwise, you might encounter issues during the upgrade process. For example, if your database server has insufficient memory or processor power, it may be unable to keep up with the number of transactions that occur during the upgrade process, and the upgrade may fail.

We recommend that you use a trial upgrade to determine exactly what hardware capacity you must have for an acceptable upgrade experience. For more information, see Use a trial upgrade to find potential issues (SharePoint Foundation 2010). If you experience capacity problems with your hardware during the trial upgrade, you can increase the capacity and repeat the upgrade until you are satisfied that you have found the optimal level of upgrade performance.

Important:

It is important to track the following three resource components for a server that is running SQL Server: CPU, memory, and I/O subsystem. When one or more of these components seems to have reached capacity, analyze the appropriate strategy based on the current and projected work load, and determine whether to add more resources or to scale out to a new server that is running SQL Server. In general, we recommend that you consider scaling out, in addition to adding more resources.

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Determine how to handle customizations (SharePoint Foundation 2010)
See Also

If you have extensively customized your sites based on Windows SharePoint Services 3.0, you must determine how you want to handle your customized sites when you upgrade to Microsoft SharePoint Foundation 2010. Your approach will vary based on the extent of the customizations, the kind of customization, the complexity of your site, and your goals for upgrading. Before you upgrade, you must identify and then evaluate the customizations in your environment and determine whether you will upgrade them, and how.

In this article:

  • Identify customizations in your environment

  • Evaluate the customizations

  • Considerations for specific customizations

  • Ensure that future customizations follow best practices

Identify customizations in your environment

As part of your upgrade testing process, you should create an inventory of the server-side customizations in your environment (solutions, features, Web Parts, event handlers, master pages, page layouts, CSS files, and so on). For more information about how to identify customizations, see Use a trial upgrade to find potential issues (SharePoint Foundation 2010). You can use the Upgrade Planning worksheet to list specific customizations and then record the results of your evaluation in the next section. Download the worksheet from http://go.microsoft.com/fwlink/p/?LinkId=179928.

Evaluate the customizations

After you have identified the customizations, you can decide what to do about them. The following questions can help you evaluate the customizations:

  • Is the customization still valuable?

    • Does it serve a useful business need?

    • Is it widely deployed and used?

  • Is the customization well-designed?

    • Is it built on supported, predefined site definitions?

    • Does it follow best practices for customizations?

    • Is it a supported kind of customization, or does it introduce risk into your environment?

As you evaluate each individual customization, you can also think about your overall approach for customizations. You can choose from among these options:

  1. Keep the customizations Use Visual Upgrade to continue to use the previous version's user experience for specific sites. Although you can use this approach to keep the same functionality, you will not be able to take advantage of the new visuals — such as the Fluent user interface (UI), also called the ribbon — and capabilities that are available in the new version.

  2. Replace or redo the customizations If you want to use new functionality, plan to redesign your sites, or are significantly changing the information architecture, the upgrade is your opportunity to start over with new features, a new look, or a new organization. When you replace or redo customizations, you can take advantage of the new capabilities, modify your design slightly if you want, or move to a more manageable design.

    For more information about redoing and redeploying solutions, see Redeploying Customizations and Solutions in SharePoint Foundation 2010 and SharePoint Server 2010 (http://go.microsoft.com/fwlink/p/?LinkId=182335).

  3. Discard the customizations Replace the customizations by using default functionality. You can reset pages to the default site definitions and remove any Web Parts or features that you no longer want to support. If you decide to discard any customizations, you must fix any issues that result from removing the customizations in the sites that used them. You can use your customizations inventory to determine which sites require this kind of attention before or after upgrade.

Considerations for specific customizations

In addition to your overall decision about how to treat customizations in your environment during upgrade, you must examine specific types of customizations to determine whether you must perform any additional actions to make them work in the upgraded environment.

The following table lists some common customizations and a recommendation for addressing that kind of customization.

Customization type Recommendation

Site templates (.stp files)

Site templates (.stp files) are a deprecated feature in SharePoint Foundation 2010. New site templates in SharePoint Foundation 2010 are saved as .wsp files (solution packages).

A site that was provisioned by using a site template will be upgraded, but you will be unable to create new sites that are based on that template. If you want to be able to create new sites, you can create and deploy a solution package instead. For more information, see Troubleshoot upgrade issues (SharePoint Foundation 2010).

Site definition

Migrate sites to a supported, predefined site definition, then apply custom features by using solution deployment.

You can also continue to use a custom site definition. You do not have to create a new site definition that is based on SharePoint Foundation 2010.

However, if you must perform custom upgrade actions for the definition, you might have to create an upgrade definition file for that site definition. For more information, see Upgrade Definition Files (http://go.microsoft.com/fwlink/p/?LinkId=182339) on MSDN.

"Fabulous 40" application templates

Microsoft is not creating new versions of these templates. Sites that are based on these templates can be upgraded, but make sure that you test each site before you upgrade the production environment. For more information, see Troubleshoot upgrade issues (SharePoint Foundation 2010).

Feature

Evaluate, then redesign or redeploy if necessary.

Workflows and server controls

Depends on the solution. Contact the vendor to find out whether there is an updated solution. If a workflow is compatible with the new version, redeploy.

Event handler

Rewrite and redeploy as a feature.

Managed paths (inclusions/exclusions)

Re-create inclusions for a database attach upgrade. Exclusions are assumed and do not have to be re-created.

Themes

Because of the extensive changes to the UI, custom themes that are based on Windows SharePoint Services 3.0 will not work in SharePoint Foundation 2010. Use Visual Upgrade to continue to use the sites in the old user experience until you can create and apply a new theme that is based on SharePoint Foundation 2010.

Toolbar actions

Move to the ribbon (Fluent UI).

Master pages and CSS files

Rework to accommodate the new user experience.

JavaScript

Test to determine whether any actions are required. In some cases, you might have to adjust the scripts to work with the new page model. Verify that it works on an upgraded site, and in both Visual Upgrade modes.

Search provider or security trimmer

Test to determine whether any actions are required.

Web Parts

Test to determine whether any actions are required. You might have to adjust the Web Parts to work with strict XHMTL mode.

If a Web Part is located on a page but not in a Web Part Zone (so that it is, basically, HTML code embedded directly in a page), it will not work if you revert the page to the default template.

Services

Test to determine whether any actions are required. Redesign or adjust code, as needed.

Authentication providers

Test to determine whether any actions are required. Redeploy the provider on a test farm and ensure that it works correctly with claims authentication.

The following kinds of customizations are not supported. If you have any of these customizations in your environment, you must replace them by using a supported kind of customization before you can upgrade. Otherwise, you might experience upgrade issues that cannot be fixed:

  • Predefined files, features, or site definitions that have been modified.

    Warning:

    Some predefined file types — such as document icons or actions — can be modified and although they will not be upgraded, their changes can be carried forward in a supportable way. Modifications to other predefined files, such as server-side ASPX pages, will be lost during upgrade if you revert to the site template. Depending on the files that have been changed and the extent of these changes, the upgrade experience can vary significantly. The best practice is to revert all changes in all files on the disk.

  • SharePoint databases that have been modified, either by directly changing data or changing the schema, including adding or removing triggers, tables, views, or indexes.

If you have any of these kinds of customizations, remove them and replace them with supported customizations before you attempt to upgrade. This is a best practice for helping to ensure that not only your current upgrade will work, but any future upgrades will go more smoothly. Changing predefined files and databases will remain unsupported.

Ensure that future customizations follow best practices

Ensure that your environment performs well and follows best practices. Deploy only those customizations that follow the best practices described in the following articles on MSDN and TechNet:

  • Best Practices: Using Disposable Windows SharePoint Services Objects (http://go.microsoft.com/fwlink/p/?LinkId=105945&clcid=0x409).

  • Development Tools and Techniques for Working with Code in Windows SharePoint Services 3.0 (Part 1 of 2) (http://go.microsoft.com/fwlink/p/?LinkID=101494&clcid=0x409).

  • Best Practices: Common Coding Issues When Using the SharePoint Object Model (http://go.microsoft.com/fwlink/p/?LinkId=105946&clcid=0x409).

  • SharePoint Products and Technologies customization policy (http://go.microsoft.com/fwlink/p/?LinkId=105947&clcid=0x409).

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Create a communication plan (SharePoint Foundation 2010)
See Also

It is important that you communicate with your users during the upgrade process from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010. Site users need to know what to expect when they visit their sites again after upgrade, and site owners need to know how they can help prepare for upgrade and what they will have to do after upgrade. Both site users and site owners need to know when the upgrade will occur. As part of the planning process, determine the following:

  • Who are the members of your upgrade team, what other stakeholders are involved, and who will be affected by the upgrade.

  • What information must the upgrade team have, and when.

  • What information must site users and other stakeholders have, and when.

This article describes how to create your communication plan so that your upgrade team, your stakeholders, and your users know what to expect before, during, and after the upgrade.

In this article:

  • Who is on the upgrade team?

  • When and what to communicate to the upgrade team

  • When and what to communicate to site users

Who is on the upgrade team?

For small deployments in which sites have not been customized to any great degree, the upgrade team might consist of only one person. For larger deployments, on the other hand, several people with different roles can be required, as described in the following list:

  • Server administrators The server administrator performs most of the upgrade tasks. There must be at least one server administrator on the upgrade team because running the Setup wizard requires someone who is a member of the local Administrators group on each front-end Web server.

    Note:

    Farm administrators might not be local administrators for the server.

  • Database administrators If you have a separate database administration team, you must coordinate with them to schedule the upgrade and perform the upgrade, especially if you plan to use the database attach upgrade method.

  • Server security teams You must coordinate with your security teams, such as the Active Directory directory services team, to verify accounts and permissions or to take advantage of the new policy settings you can apply for SharePoint Foundation 2010.

  • Client deployment team Communicate with client deployment teams to coordinate deployments of new client and server applications. Client deployment might have to occur before you upgrade, or it could be an option available to users after their sites have been upgraded.

  • Site collection owners You must notify site collection owners when the upgrade process is about to occur, and warn them about any issues that you find when you run the pre-upgrade checker or when you upgrade their sites. If you are using Visual Upgrade, you must also communicate with site collection owners about the change to the new user interface and whether the farm administrators or site collection administrators will be completing that change.

  • Site designers and developers If you have custom templates, Web Parts, Web services, or other custom elements associated with your sites, you must work with the people responsible for developing or customizing those elements to ensure that you can create new versions of these custom elements or verify that these elements have been upgraded correctly. For more information about potential issues with custom elements, see Use a trial upgrade to find potential issues (SharePoint Foundation 2010).

  • Site users Although you do not have to include site users in making decisions about the upgrade process, you must tell site users when it will happen and what they should expect.

  • Sponsors and other stakeholders You might have other people in your organization involved in the upgrade planning process. Make sure that you include them in your communication plan appropriately.

    Note:

    An upgrade team can include one or more members in each role, depending on your organization.

When and what to communicate to the upgrade team

In general, the server administrators and shared services administrators set the timeline for upgrade, and site owners are notified only when the process is about to begin. However, because team members have their own tasks to perform at particular points in the overall upgrade process, it is critical that you have a solid plan to communicate the progress of the upgrade to all team members so that everyone knows when it is time to perform their particular tasks.

The whole upgrade team needs to work together to determine the following:

  • The upgrade approach to use The Determine upgrade approach (SharePoint Foundation 2010) article contains information to help you decide which kind of upgrade to perform. The report generated by the pre-upgrade checker is also important to consider when you make this decision.

  • Dates and times to perform the upgrade We recommend (especially for an in-place upgrade) that you upgrade when site usage is low. For small single-server deployments, upgrade may be completed in less than a day. For larger deployments, such as server farms with large amounts of data, the database attach upgrade method or the in-place upgrade with detached databases method can be used to distribute the upgrade process over several outage windows. There is no way to determine the precise length of time that will be required to upgrade any particular site collection. Because of this, it is very important to communicate with other team members involved in the upgrade process in addition to end users. The day or days that you choose for upgrading should be far enough in the future that the upgrade team has enough time to complete all of the preliminary steps. When you plan the timeline, make sure that you schedule time to validate the upgraded sites and time to implement any changes or do any work to re-brand sites.

It is important to communicate with site owners, designers, and developers at the following points during the upgrade process:

  • Before the process begins, so that they know the general timeline and what their roles in the process will be.

  • After the pre-upgrade checker has been run, so that they can address any issues that have been identified by the checker. For more information about the pre-upgrade checker, see Run the pre-upgrade checker (SharePoint Foundation 2010). For example, issues such as customized site templates or custom Web Parts should be reported to the appropriate site owner, designer, or developer before you schedule the upgrade, to give them time to investigate the issues and take preliminary steps. Or a developer might decide that it would be prudent to rebuild a Web Part before the upgrade occurs. And site owners might want to note any customizations that have been done to their sites, including site templates and changes to core Active Server Page Extension (ASPX) files.

  • After their sites have been upgraded, so that they can review the sites and make any changes that are needed.

When and what to communicate to site users

It is equally important to communicate with the users of the sites to tell them about the following issues:

  • When their sites will be upgraded In the case of an in-place upgrade, they must also be informed that their sites will be unavailable during the upgrade.

  • When to expect their upgraded sites to be ready This means that the upgrade team has not only upgraded, but also verified the functionality of, the upgraded sites.

  • How the upgrade might affect them and what they should know about the new environment For example, the site will look different and function slightly differently in the new user interface. If you are using Visual Upgrade, inform your users whether they will see the new or old user experience and what to expect. You can also point them to available content, such as What's New articles or training materials, to learn about the new version. For more information about feature changes and visual upgrade, see Plan visual upgrade (SharePoint Foundation 2010) and Changes in key features between versions in the article "What's New in Upgrade".

  • How to get help If they find an issue with their site after upgrade, where can they go to address it?

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Plan visual upgrade (SharePoint Foundation 2010)
See Also

This article discusses the new visual upgrade feature in Microsoft SharePoint Foundation 2010. If your organization plans to perform an upgrade of Windows SharePoint Services 3.0, you can take advantage of this new feature. By default, the look and feel of sites is preserved during an upgrade from Windows SharePoint Services 3.0. Site owners can switch to the new user interface permanently, or they can choose to preview the new user interface for their SharePoint sites. By using the visual upgrade feature, you can choose to move all sites to the new user interface. If you select the latter option, you override the user interface for site collection owners and site owners. You can also choose to either preserve customized pages or you can choose to reset all customized pages. Both choices will update the look and feel of template pages, but the latter option deletes modifications from customized pages and cannot be undone.

Note:

The visual upgrade feature is not available if you are performing an upgrade on a single server with built-in database through the SharePoint Products Configuration Wizard. However, the visual upgrade feature is still available if you use the PSConfig command-line tool for upgrade.

This article lists key considerations for planning to use visual upgrade, and it also discusses known issues. For more information, see Manage visual upgrade (SharePoint Foundation 2010).

In this article:

  • Key planning phase of visual upgrade

  • Training site collection owners and site owners

  • Known issues

Key planning phase of visual upgrade

Visual upgrade is a feature that is part of the upgrade process. Before you perform the upgrade, ensure that you know about the effects of choosing between the two different options visual upgrade has to offer.

Preserving the existing user interface

If you choose to preserve the look and feel of existing SharePoint sites, you give site collection owners control over their site collections and site owners control over their sites. All the data and settings from the original sites are preserved, and layout, command organization, and styles preserve the previous user interface. Regardless of the type of farm upgrade that you select, you receive all the infrastructure benefits of Microsoft SharePoint Foundation 2010 including improved reliability, scalability, and manageability. Preserving the previous user interface reduces the likelihood that customized content will cease to function. This ensures that you and the users can continue to use existing SharePoint sites until all upgrade work, including troubleshooting and updating customizations, has been completed.

Upgrading to the new user interface

If you choose to change all the existing SharePoint sites to the new user interface, site collection owners and site owners have no control over the upgrade. All the data and settings from the existing SharePoint sites are upgraded to the new user interface. You might want to choose this option if there are no customizations or if you have tested any customizations that you need before the upgrade. Even if you choose this option, you still have the option of either preserving customized pages or resetting customized pages. If you need to keep customizations, or if you are unsure whether to keep customizations, you should choose to preserve customized pages. Resetting the customized pages removes customizations and cannot be undone. Choose this option if you do not need the customizations any longer and if you know that no important data will be lost. For more information, see Determine how to handle customizations (SharePoint Foundation 2010), Use a trial upgrade to find potential issues (SharePoint Foundation 2010), and Redeploying Customizations and Solutions in SharePoint Foundation 2010 and SharePoint Server 2010 (http://go.microsoft.com/fwlink/p/?LinkId=186372).

Training site collection owners and site owners

It is important that you train users about the effects of either preserving the look and feel of existing SharePoint sites or upgrading all sites to the new user interface. Educated users are prepared and know what to expect, which will minimize helpdesk support and frustrations.

If you upgrade all sites to the new user interface, inform users about changes and new features, such as the ribbon, the new page editing interface, and interactive calendars. Also, let them know about possible issues that they can expect. For instance, they might have issues with customizations, such as pages not displaying correctly. For information about general upgrade issues, see Troubleshoot upgrade issues (SharePoint Foundation 2010).

If you choose to preserve the look and feel of existing SharePoint sites, explain to site collection owners and site owners that the user interface will not change during upgrade, and tell them about the choices they can make.

By default, site owners have control over their sites. They can use the Preview New Visuals option (under Site Settings) to preview the new user interface and then switch between the previous and new user interface. This gives them time to ensure that everything works correctly, and they can fix any issues with their pages that appeared after upgrade. When site owners are ready, they can update their sites to the new user interface. However, site collection owners can choose to finalize the new user interface, which overrides the control that site owners have over visual upgrade for their sites. If site collection owners want to keep the previous user interface for their site collection, they also have an option to hide visual upgrade settings from site owners.

Site owners also need to know that if they make changes in the new user interface while they are in preview mode and then switch back to the previous user interface, this information may not display correctly.

We recommend that you have a plan and set a time limit for how long the previous user interface should be used in your SharePoint deployment. For example, each site collection administrator may be given 90 days to work with his or her site owners to transition from the previous to the new user interface. This time limit ensures that users are given a reasonable time to become familiar with the new user interface and to resolve any issues that might have occurred during the upgrade. Ensure that you communicate the time limit to the users, and that they know you can force through an upgrade of all sites. Also, you can view the current status of the user interface of upgraded sites to monitor the progress of these sites. For more information, see Manage visual upgrade (SharePoint Foundation 2010).

If site collection owners decide to use the new user interface for all sites within their site collection, they cannot change their minds. However, as a farm administrator, you can change these settings by reverting sites to the previous user interface with Windows PowerShell or SharePoint Object Model. For more information, see Manage visual upgrade (SharePoint Foundation 2010).

It is important to tell site collection owners and site owners that as long as sites use the previous user interface, new features—such as the ribbon, in-place editing for Wiki pages, interactive calendars, and list relationships—will not be available. However, once sites switch to the new user interface, application features automatically appear. Also, it is important to note that all new sites created after the upgrade use the new user interface by default.

Known issues

There are a few known issues to consider:

  • If you use SharePoint Foundation 2010, ensure that you use the same version and service pack of SharePoint Designer.

See Also

Concepts

Upgrade in place to SharePoint Foundation 2010
Attach databases and upgrade to SharePoint Foundation 2010
Upgrading to SharePoint Foundation 2010

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Testing and troubleshooting upgrade (SharePoint Foundation 2010)
See Also

Before you upgrade from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010, you should take time to test your upgrade process and understand what issues you might face in your actual upgrade. This section includes information about how to test upgrade and use the information from that test to predict how much time and how much space you will need for upgrade, and what steps you can take to clean up your environment before you perform your actual upgrade.

During and after upgrade, use the articles in this section to address any issues and resume the upgrade process.

In this section:

  • Best practices for testing upgrade (SharePoint Foundation 2010)

    Follow these best practices to get the most out of your upgrade testing.

  • Use a trial upgrade to find potential issues (SharePoint Foundation 2010)

    Find out how to plan for success by testing upgrade by using your actual data in either a physical or virtual environment.

  • Estimate how long the upgrade process will take and the space that you need (SharePoint Foundation 2010)

    Use your test information to understand how long your upgrade will take.

  • Clean up an environment before upgrade (SharePoint Foundation 2010)

    Upgrade runs more smoothly when you prepare your environment by cleaning up extra sites or data. This article lists common things that you should consider cleaning up before you start the upgrade process.

  • Troubleshoot upgrade issues (SharePoint Foundation 2010)

    Follow these recommendations to troubleshoot any issues that occur during upgrade. You can also look up common issues and find out how to address them.

  • Recovering after a failed upgrade (SharePoint Foundation 2010)

    If you created a backup of your environment and databases before you began an in-place upgrade, or if you set your environment to read-only before you began a database attach upgrade, you can recover your environment if the upgrade process fails.

  • Resume upgrade (SharePoint Foundation 2010)

    If you encounter errors during upgrade, you can address them by using the troubleshooting article, and then use this article to restart or resume upgrade.

In addition, the following resources can be helpful when you test your upgrade process:

  • SharePoint Products 2010 Upgrade Worksheet

    Use this worksheet to record information about your environment while you test your upgrade. Download the worksheet from http://go.microsoft.com/fwlink/p/?LinkId=179928.

  • Microsoft SharePoint 2010 Products - Test Your Upgrade Process model

    This poster has a visual display of information about testing your upgrade process. Download the poster from http://go.microsoft.com/fwlink/p/?LinkId=166303.

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Best practices for testing upgrade (SharePoint Foundation 2010)
See Also

To understand your environment before you try to perform an upgrade, and to plan accurately for the time that an upgrade will require, you should perform one or more trial upgrades. The goal of testing upgrade is to find issues early and address them so that you can have confidence in your process and the outcome when you perform the real upgrade. To perform an accurate and useful test of the upgrade process from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010, follow these best practices:

  1. Make your test environment as similar as possible to your real environment.

    If possible, use the same kind of hardware and configure it by using the same settings, the same URLs, and so on. The more you can minimize the differences between your test environment and your real environment, the better. The more differences you introduce, the more time that you are likely to spend time tracking down unrelated issues to make sure that they will not occur during the actual upgrade.

  2. Know what is in your environment. Do a full survey first.

    Take the time to document the hardware and software that is present in your environment, what server-side customizations are installed and used, and where, and what settings you need. This will help you plan more fully, and also help you recover if upgrade fails. A worksheet is available so that you can record information about your environment while you prepare for upgrade. Download the worksheet from http://go.microsoft.com/fwlink/p/?LinkId=179928.

  3. Use real data.

    Use copies of your actual databases to run the tests. When you test by using real data, you can identify any trouble areas and also determine your upgrade performance. It also gives you the opportunity to measure how long different upgrade sequences and actions take on different kinds of data. If you cannot test all the data, test a representative subset of the data to make sure that you have uncovered any issues with the different kinds and sizes of sites, lists, libraries, and customizations that are present in your environment.

  4. Run multiple tests.

    A single test can tell you whether you will encounter big problems, but multiple tests will help ensure that you have uncovered all the issues that you might face and can also give you a more accurate timeline for the process. By running multiple tests, you can determine which upgrade approaches will work best for your environment, which downtime mitigation techniques you should plan to use, and how the process or performance may change after you address the issues that you uncovered in your first tests. Your final test pass can help you validate whether you have addressed all of the errors and are ready to upgrade your production environment.

  5. Do not ignore warnings.

    Even though it is not an error, a warning can lead to problems later in the upgrade process. Work through errors, yes, but also investigate any warnings to make sure that you know what the effect of that warning might be.

  6. Test the upgraded environment, not just the upgrade process.

    Check your service applications and services. Run a search crawl and review the log files. Verify that My Sites is working.

  7. Verify sites in both Visual Upgrade modes.

    Do not assume that because the site can be previewed well in one mode that it will work correctly in the other mode. Check both the previous version and new version user experience.

  8. Consider a preview environment.

    You can create a preview environment in which your users can verify their sites after a test upgrade, so that they can help you verify the upgrade and find issues. You can use a read-only environment, or you can let your users make changes but warn them that any changes they make will not be saved. Consider limiting this preview environment to a small set of representative sites, and limiting access to interested parties only, to reduce the time that you will need to host the preview environment and the amount of feedback you receive.

For more information about how to test upgrade, see Use a trial upgrade to find potential issues (SharePoint Foundation 2010) and the "Test your upgrade process" poster available at http://go.microsoft.com/fwlink/p/?LinkId=166303.

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Use a trial upgrade to find potential issues (SharePoint Foundation 2010)
See Also

Before you begin the process of upgrading from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010, you will want to test the upgrade process to make sure that you know exactly what you have to do to have a successful upgrade. By using a trial upgrade to test the process, you can find out:

  • What customizations you have in your environment, so that you can plan for how to deal with them during upgrade.

  • Whether you should upgrade your hardware to make your upgrade run more efficiently and more quickly.

  • The timing for your upgrade, or how long upgrade will take for your environment.

  • What you need to plan for, operationally — for example, resources to have available.

In addition, you can use the trial upgrade to become familiar with the upgrade tools and the process itself, so that you know what to expect when you go through the actual process. Through testing, you can find out:

  • Which special cases apply to your environment and which upgrade approach will be most efficient for you?

  • What does the upgrade user interface look like? How do you know when you have finished one phase and are moving through another?

  • Where are the log files, and how do you read them? What information do they provide?

  • Which techniques can you use to mitigate downtime?

This article provides basic steps for testing upgrade, and it gives recommendations for reviewing the results and adjusting your upgrade plans based on what you learn during the tests.

In this article:

  • Set up a test environment

  • Identify and install customizations

  • Copy real data to the test environment and try the upgrade

  • Review your results

  • Adjust your plans and test again

In addition, the following resources can be helpful when you test your upgrade process:

  • SharePoint Products 2010 Upgrade Worksheet

    Use this worksheet to record information about your environment while you test your upgrade. Download the worksheet from http://go.microsoft.com/fwlink/p/?LinkId=179928.

  • Microsoft SharePoint 2010 Products - Test Your Upgrade Process model

    This poster has a visual display of information about testing your upgrade process. Download the poster from http://go.microsoft.com/fwlink/p/?LinkId=166303.

Set up a test environment

You can use either virtual or physical hardware to test the upgrade process. Every environment is unique, so there are no general guidelines for how long upgrade will take or how difficult a particular customization will be to upgrade. The best way to gauge how your upgrade will go is to perform a series of trial upgrades.

When you create your test environment:

  • Make your test farm as similar as possible to your real farm — for example, hardware, software, and space available.

  • Use the same URLs in your test farm as in your real farm. (Otherwise, you will waste time diagnosing issues relating to the URLs that will not come up in the real upgrade.)

  • Be sure that you transfer all of your settings and customizations to the test environment. The section Identify and install customizations provides information about gathering this information.

Using a virtual test environment

When you test by using a virtualized environment, you do not need a lot of hardware. You can replicate your environment by using just two servers that are running Hyper-V. One server has images for the front-end Web servers and application servers, and the other server has images for the database servers.

Virtual test environment for trial upgrade

Using a physical test environment

When you test by using a physical environment, you need to replicate your entire server farm environment as closely as possible. If you simplify the number of front-end Web servers, application servers, or database servers too much, you will not have an accurate estimate of how long the upgrade process will take and you may not account for complications that arise from interactions between servers in the same role (such as SQL Server transactions). If you have multiple servers in a role in your original farm, use at least two servers for that role in the test farm to test for such issues.

Physical test farm for a trial upgrade

Additional test environments for database attach upgrade

If you are using the database attach upgrade approach, you might need to create one additional test environment: a single server farm that is running Windows SharePoint Services 3.0 that you can use to run the pre-upgrade checker before you attempt to upgrade the data.

You can avoid this step by running the pre-upgrade checker on your existing production farm.

Identify and install customizations

To have an accurate test process, you must find all the customizations in your current environment and copy them to the test environment. For more information about the types of customizations you need to identify, see Determine how to handle customizations (SharePoint Foundation 2010).

  • Use the pre-upgrade checker to identify site definitions, site templates, and features in your environment.

    The pre-upgrade checker steps through each site collection and generates a report about the state of each site. It also saves list definition information for each list. You can review the reports to find issues and address them before you start the upgrade process. Unlike the pre-upgrade scan tool for Windows SharePoint Services 3.0, the pre-upgrade checker is a read-only tool and does not change your sites. For more information about this tool and steps for running it, see Pre-upgrade scanning and reporting for future releases (Windows SharePoint Services) and Run the pre-upgrade checker (SharePoint Foundation 2010).

  • Use the Stsadm -o enumallwebs operation on all content databases in your Windows SharePoint Services 3.0 environment to identify specific customizations in subsites. This operation lists an ID for each site collection and subsite in your environment and the templates that the site relies on. This operation was first introduced in Windows SharePoint Services 3.0 with Service Pack 2 (SP2). For more information, see Enumallwebs: Stsadm operation (Windows SharePoint Services).

  • Use a tool such as WinDiff (a tool that is provided with most Microsoft operating systems) to compare your production environment servers with your test farm servers. You can use this tool to see which files exist on your servers and the differences between them.

  • Check the web.config files for any changes, and look in the SafeControls element to find any custom controls.

  • Use the SharePoint Diagnostics Tool (SPDiag) to find deployed solutions. For more information, see SharePoint Diagnostics Tool (SPDiag).

  • Create a list of all customizations that you find. Identify the source of the customizations, if possible. For example, are there third-party add-ins or templates that were customized in-house? After you identify the source, you can then check for updated or upgraded versions of the customizations. A worksheet is available that you can use to fill in information about your environment, based on the data you find in the results from the pre-upgrade checker and in your research on your customizations. Download the worksheet from http://go.microsoft.com/fwlink/p/?LinkId=179928 and customize it to suit your needs.

Tip:

Whom do you contact about customizations that you did not create?

  • Contact Microsoft if you are having trouble with a template that you downloaded from the Microsoft Web site (such as the Windows SharePoint Services 3.0 Application Templates).

  • Contact your third-party solution vendor if you are having trouble with a template or component that they supplied you for the previous version. They may have an upgraded version available.

After you identify all the customizations, copy them to the appropriate servers in your test farm. You can use the Windows PowerShell cmdlet test-spcontentdatabase before you attach a database to SharePoint Foundation 2010 to determine whether any customizations are missing from the environment. Run this command for each database after you restore the databases to your database server, but before you run the upgrade. Note that this cmdlet runs silently — it will not return any output unless there is an error.

Copy real data to the test environment and try the upgrade

You cannot achieve your testing goals unless you use your actual data. You can use the following methods to create a copy of your data:

  • For in-place upgrade, create a farm backup and then restore it to the test environment. For more information, see Back up and restore the entire farm (Windows SharePoint Services 3.0 technology).

  • For database attach upgrade, you need to use the Microsoft SQL Server backup and restore tools to create a copy of your content databases and any other databases that you want to upgrade. For more information, see Back up and restore content databases (Windows SharePoint Services 3.0).

There is no better way to tell what may come up during upgrade than to perform the test on a copy of all of your data; however, this might not always be a realistic option for initial testing. You can phase the testing by testing one database at a time (if the databases are large) so that you can make sure you test whatever is unique about that data set, or you can assemble a subset of data from representative sites in your environment. If you want to first test by using a subset of your data, be sure that the subset has the following characteristics:

  • The data subset contains sites that are typical of the sites you support in your environment.

  • The size and complexity of the data subset is very similar to the actual size and complexity of your environment.

Important:

Testing a subset of your data does not produce a valid benchmark for how long it will take to process the entire volume of data for your environment.

After copying the data, take a first pass through the upgrade process to see what happens. This is just the preliminary round.

Try in-place upgrade

If you want to try an in-place upgrade approach, use the following steps to try out the upgrade process:

  1. Create a backup of your farm.

  2. Restore the backup to your test farm.

    For more information, see Back up and restore the entire farm (Windows SharePoint Services 3.0 technology).

  3. Run the pre-upgrade checker. Make note of any issues it finds. You will want to address these issues in your original environment before you run the actual upgrade on your product farm. For more information, see Run the pre-upgrade checker (SharePoint Foundation 2010).

  4. Follow the steps in Perform an in-place upgrade (SharePoint Foundation 2010) to try the in-place upgrade.

  5. Review the results.

Try a database attach upgrade

  1. Create a SQL Server backup of your content databases.

  2. Use SQL Server to restore the backups into your single-server test farm and attach the content databases to that environment.

    For more information, see Back up and restore content databases (Windows SharePoint Services 3.0).

  3. Run the pre-upgrade checker. Make note of any issues it finds and any changes it makes. You will want to address these issues and make these changes in your original environment before you run the actual upgrade on your product farm. For more information, see Run the pre-upgrade checker (SharePoint Foundation 2010).

  4. Follow the steps in Prepare the new SharePoint Foundation 2010 environment for a database attach upgrade to configure the test environment for a database attach upgrade.

  5. Follow the steps in Attach databases and upgrade to SharePoint Foundation 2010 to try the database attach upgrade process.

Review your results

After your test upgrade has been completed, you can review the results and revisit your plans. Look at the log files, look at the upgraded sites, and check out your customizations. How did upgrade work for your environment? What did you find out? What do you need to rethink about your upgrade plan?

Review the log files

Review the following log files:

  • The pre-upgrade checker log file.

    The log files for the pre-upgrade checker (stsadm -o preupgradecheck) are located at %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS. The log files are named in the following format: PreUpgradeCheck_YYYYMMDD-HHMMSS-SSS-random-number.log, where YYYYMMDD is the date and HHMMSS-SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds) and the random number is used to differentiate between possible simultaneous attempts to run the pre-upgrade checker.

  • The SharePoint Products Configuration Wizard (Psconfig.exe) log file (generated when you run this wizard as part of your trial in-place upgrade).

    The PSCDiagnostics log files are located at %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS.

  • The upgrade log file and the upgrade error log file (generated when you run the upgrade).

    The upgrade log file (.log) and the upgrade error log file (.err) are located at %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS. The log files are named in the following format: Upgrade-YYYYMMDD-HHMMSS-SSS.log, where YYYYMMDD is the date and HHMMSS-SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds).

To review the log files to find and troubleshoot issues. start at the top of the files. Errors or warnings may be repeated if they occur for several site collections in the environment, or if they block the upgrade process altogether. For example, if you cannot connect to the configuration database, the upgrade process will try (and fail) several times and these attempts will be listed in the log file.

Search, or visually scan, for the following entries:

  • Finished upgrading SPFarm Name=<Name of Configuration Database>

  • In-place upgrade session finishes. Root object = SPFarm=<Name of Configuration Database>, recursive = True. 0 errors and 0 warnings encountered.

If you find these entries, the installation was successful.

If you do not find the entries from the previous step, you can identify specific issues that may have contributed to the failure by searching, or visually scanning, through the Upgrade.log file for the following terms:

  • Search for ERROR in the log files to find any failures (such as failing components or faulty database connections).

  • Search for WARNING to find issues such as missing features or components.

To find upgrade issues, you may find it useful to use a log parser to run queries against the log files.

Restart upgrade, if necessary

During a database attach upgrade, any sites that cannot be upgraded will be skipped. During an in-place upgrade, if the server restarts or the upgrade fails, you will need to restart the upgrade process to upgrade the remaining sites.

To see whether any sites were missed or skipped during upgrade, run the following Stsadm operation stsadm -o localupgradestatus on every front-end Web server in your SharePoint Foundation 2010 server farm. For more information about this operation, see Localupgradestatus: Stsadm operation (Windows SharePoint Services).

If the upgrade skipped any site collections, you can restart the upgrade process for the database that contains that site collection by using the following Windows PowerShell cmdlet: upgrade-spcontentdatabase -id <GUID>. For more information about this cmdlet, see Upgrade-SPContentDatabase.

For more information, see Resume upgrade (SharePoint Foundation 2010).

Review upgraded sites

Review your upgraded sites to identify any issues that need to be addressed before you run the upgrade process on your production environment. For more information about specific things to look for, Verify upgrade and review upgraded sites (SharePoint Foundation 2010).

Adjust your plans and test again

Repeat the testing process until you are sure that you have found all the issues that you may face and that you know how to deal with them. Your goal is to know what your plan is if it is 4:00 P.M. on Sunday, you have to be back online Monday morning, and it is not going well. Is there a point of no return? Test your rollback plan and make sure that it works before you begin your real upgrade.

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Estimate how long the upgrade process will take and the space that you need (SharePoint Foundation 2010)
See Also

An important part of planning your upgrade from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010 is determining how long the upgrade process will take and how much storage space will be required. Every environment is unique and includes different hardware capabilities and different site characteristics. The space and the length of time that you need to run an upgrade will vary greatly depending on your environment. The best way to estimate these factors is to perform a trial upgrade, and then review the space and time that it took. For more information about how to perform a trial upgrade, see Use a trial upgrade to find potential issues (SharePoint Foundation 2010).

In this article:

  • Estimate the space that you need for the upgrade

  • Estimate how long the upgrade will take

Estimate the space that you need for the upgrade

During both the in-place upgrade and database attach upgrade approaches, the databases might expand during upgrade. Also, many transactions take place while the upgrade process runs, so you must make sure that the log files have room to expand to accommodate the changes that are occurring. You have to plan for growth in both the databases and the log files.

When planning your upgrade, make sure that your current environment follows the best practices for storage for Windows SharePoint Services 3.0 so that you have the best experience and performance during upgrade. For more information, see Physical storage recommendations (Office SharePoint Server). You should also review the best practices for SharePoint Foundation 2010 and make any adjustments needed to your upgraded environment.

Because of the changes in table structures in the new version, the databases grow temporarily while the data is reorganized. This space can be recovered after upgrade, but you should ensure that there is room for the databases to grow up to 50 percent larger than their current sizes during either an in-place or database attach upgrade (be aware that after upgrade, you can reduce the database again to recover much of this space). You should also make sure that there is room on your database servers for your databases to grow over time with typical use. To find out how large your databases currently are, use Enterprise Manager in Microsoft SQL Server. In addition to database space, you also must have room for the following items:

  • The temporary databases. Ensure that you have enough database space to enable quick growth of the temporary databases. If you have insufficient space, the upgrade process might time out and the upgrade will fail.

  • The upgrade log files.

  • The transaction log files for the databases. These log files must grow quickly to accommodate the number of changes occurring in the databases.

    Note:

    In very large environments, there is a possibility that the default growth rate for the transaction log files (10 percent) is not enough to keep up with the upgrade process; this can cause a time-out. Again, a trial upgrade is the best way to determine whether the transaction log files can keep up with the upgrade process. If your environment is very large, or if the process timed out during a trial upgrade, consider expanding the SQL Server transaction log files beforehand to make sure you have room for the number of transactions that must be processed. For more information about how to expand the SQL Server transaction logs, see Expanding a Database (SQL Server 2005) (http://go.microsoft.com/fwlink/p/?LinkId=182619) or Expanding a Database (SQL Server 2008) (http://go.microsoft.com/fwlink/p/?LinkId=182620).

Estimate how long the upgrade will take

With your disk space estimates in hand, and some testing under your belt, you can now calculate a rough estimate of how long the actual upgrade process will take. Upgrade times vary widely among environments. The performance for an upgrade depends greatly on the hardware being used, the complexity of the sites, and the particular characteristics of your implementation. For example, if you have many large document libraries, these may take longer to upgrade than a simpler site.

Factors that influence performance are described in the following table.

Content factors Hardware factors

The number of:

  • Site collections

  • Subwebs

  • Lists

  • Document versions (number and size)

  • Documents

  • Links

Plus the overall database size itself.

  • SQL Server disk input/output per second

  • SQL Server database to disk layout

  • SQL Server temporary database optimizations

  • SQL Server CPU and memory characteristics

  • Web server CPU and memory characteristics

  • Network bandwidth and latency

How your data is structured can affect how long it takes to upgrade it. For example, 10,000 lists with 10 items each will have a longer upgrade time than 10 lists with 10,000 items. The actions required to upgrade the list infrastructure must be performed for each list, regardless of the number of items; therefore, more lists equals more actions. The same goes for most of the items in the "content factors" column in the table above.

The structure of your hardware can also have a big effect on performance. Generally, the database server performance is more important than Web server performance, but underpowered hardware or connectivity issues at either tier can significantly affect upgrade performance.

The upgrade approach you have chosen will also make a big difference in how long the process will take. Performing a database attach upgrade is the quickest method (however, the pre-upgrade and post-upgrade steps for this approach take longer than for in-place upgrade). An in-place upgrade takes a little more time because you are upgrading the environment in addition to the sites, but you do not have as many pre-upgrade and post-upgrade steps when you use this approach.

The best way to estimate overall time is to do a trial upgrade of a small part or all of the data, and then review the upgrade log files. The log files contain the duration for your upgrade — look for Total Elapsed Time at the bottom of the upgrade log file. Use this time to project a duration for your full set of content. You can also use the log files to check your progress during the upgrade process. The upgrade.log file is located at %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\14\LOGS.

The estimate you arrive at based on your trial upgrade is for the actual upgrade process for the data; it does not include all of the steps that you have to perform before and after this step, which can take more time than the upgrade of the data itself. When estimating how long the upgrade will take, in addition to the time that is required for data to be processed, you must also estimate how long the activities during the pre-upgrade and post-upgrade phases will take.

For pre-upgrade steps, consider the following factors:

  • Creating custom elements Upgrading Web Parts or re-doing custom templates to take advantage of new features will take some time. The process of creating custom elements should begin early, during the evaluation phase of your project.

  • Backing up the databases For in-place upgrade, you must perform a full backup — not a differential backup — of your entire environment to make sure that you can recover in the remote possibility that the upgrade fails and you must rebuild your server farm. For large environments, this step can take a significant amount of time. In particular, if you are backing up to a network location, network latency issues can slow this process down.

For post-upgrade steps, consider the following factors:

  • Verifying sites and making changes Allow enough time for users to validate their sites after the upgrade. This may take several days. For more information, see Verify upgrade and review upgraded sites (SharePoint Foundation 2010).

Additional factors in your environment can also contribute to longer upgrade times, including the following:

  • Very large document libraries A document library with more than 250,000 documents all in the root of the document library (instead of in folders) will take a long time to upgrade, and the upgrade might not be successful. Following the Windows SharePoint Services 3.0 guidelines for using folders to break up large document libraries can help you manage the library size. For example, if you rearrange the same document library so that the 250,000 documents are divided into 125 folders, it should upgrade more easily.

  • Very large databases Databases larger than 100 GB can take a long time to upgrade.

    Note:

    If you have content databases that are larger than 100 GB you might want to divide them up into smaller databases before you run the upgrade. Larger databases not only take longer to upgrade, but they can make it harder to recover if the upgrade is not completed successfully.

    You can use the mergecontentdbs or the backup and restore operations in Stsadm.exe to move sites between databases. For more information, see Mergecontentdbs: Stsadm operation (Windows SharePoint Services) and Backup and restore: Stsadm operations (Windows SharePoint Services).

    If you have a very large database (more than 100 GB) that you cannot break up because most of the content is in a single site collection, you may want to reconsider your upgrade approach. A database attach upgrade approach is more difficult with very large databases, because backing up and restoring such large databases is problematic.

    Caution:

    Be sure that you are following the capacity planning guidelines from the previous and new versions before you attempt the upgrade. If you have exceeded the guidelines for best performance, the upgrade process might take longer, or it might not succeed (for example, the process might time out repeatedly on the same large document library). If your deployment does not meet the recommended capacity guidelines, consider whether you need to do some work to meet those guidelines before you try the upgrade. Again, a trial upgrade can help you with that decision.

  • Communications requirements

    You need to notify your users and your team of the upgrade schedule, and give them time to do their tasks. For more information, see Create a communication plan (SharePoint Foundation 2010).

  • Managing system center alerts and alarms

    You need to monitor system performance during upgrade, but you will not need to monitor specific features. Pause any unnecessary alarms and alerts from Microsoft Systems Center Operations Manager or Microsoft Operations Manager, and then turn them on again after upgrade.

  • Turning SQL mirroring and log shipping on/off

    You should turn off mirroring and log shipping before you upgrade, and then turn them on again after you are sure that your environment is running correctly after the upgrade. We recommend that you do not run mirroring or log shipping during upgrade, because this creates additional load on the servers running SQL Server and also wastes resources mirroring or shipping temporary data.

Test your upgrade process to find out how long it may take, then create a schedule for your upgrade operations and test that to determine your timeline. You should include the time that you need to do the pre-upgrade and post-upgrade steps in your operations timeline: If it takes 5 hours to back up your environment before you start, you need to include that time in your outage window. Also include buffer time in case you need to restore or recover — you should determine both your planned outage (realistic case) and your emergency outage (worst case) timelines.

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Clean up an environment before upgrade (SharePoint Foundation 2010)
See Also

Before you begin upgrading from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010, you should make sure that your environment is functioning in a healthy state and that you clean up any content that you do not have to upgrade. You can also take the time to remove or rearrange content so that you will have the structure that you want after you perform the upgrade.

In this article:

  • Items to clean up

  • Making structural changes

Items to clean up

Many of these items can be removed or repaired by using Stsadm.exe commands.

Important:

To run the Stsadm command-line tool, you must be a member of the Administrators group on the local computer.

Delete unused or underused site collections and subwebs

You do not want to upgrade content that you do not have to keep. If it has been unused for a long time and will not be needed in the future, back it up, and then delete it to free storage and administrative resources, improve upgrade performance, and reduce upgrade risk. Be sure to communicate with site owners or organizational contacts regarding the site status — you want to make sure that the site is not needed before you delete it (for example, you do not want to delete sites that are required for compliance, such as emergency procedures, even though they may not be updated frequently).

For more information about how to delete site collections and subwebs, see:

  • Deletesite: Stsadm operation (Windows SharePoint Services)

  • Deleteweb: Stsadm operation (Windows SharePoint Services)

Address large lists

By default, large list query throttling is applied after an upgrade to SharePoint Foundation 2010. If a list is very large, and users use a view or perform a query that exceeds the limit or throttling threshold, the view or query will not be permitted. Check any large lists in your environment and have the site owner or list owner address the issue before upgrade. For example, they can create indexed columns by using filtered views, organize items into folders, set an item limit on the page for a large view, or use an external list. For more information about how to address issues with large lists, see Manage lists and libraries with many items (http://go.microsoft.com/fwlink/p/?LinkId=182370) on Office Online.

Address large numbers of site collections in a content database

If you have 5,000 or more site collections in a database, consider breaking them out into multiple databases. In Windows SharePoint Services 3.0, there was a default warning at 9,000 site collections and a hard limit at 15,000 site collections. In SharePoint Foundation 2010, these values change to 2,000 site collections for the warning and 5,000 site collections for the limit. To avoid errors during upgrade or broken sites after upgrade, we recommend that you move some site collections into separate databases. If you have multiple content databases, you can also speed up your upgrade process by upgrading multiple databases in parallel.

For more information about moving site collections to a new database, see Move site collections to a new database (split a content database) (Windows SharePoint Services 3.0).

Address large ACLs

Using item-level permissions frequently can result in large access control list (ACL) entries, which can in turn create performance problems on your servers. For information about this issue and for tips on how to handle lots of users, see Knowledge Base Article 953132: How to add lots of users to a site, to a list, or to a document library in Windows SharePoint Services 3.0 and in SharePoint Server 2007 (http://go.microsoft.com/fwlink/p/?LinkId=182327).

Remove extraneous document versions

Large numbers of document versions can slow down an upgrade significantly. If you do not have to keep multiple versions, you can have users delete them manually or use the object model to find and remove them. For more information about how to programmatically remove extraneous versions, see Versions Web Service (http://go.microsoft.com/fwlink/p/?LinkId=182330) on MSDN.

Remove unused templates, features, and Web Parts

First, verify that no sites are using the template, feature, or Web Part. You can use the pre-upgrade checker (Stsadm -o preupgradecheck) and the Stsadm -o EnumAllWebs operation to identify these customizations in your environment. Both of these operations were updated in the October 2009 Cumulative Update (CU) and now identify Web Parts, features, event handlers, and setup files that are being used in your environment. The pre-upgrade checker specifies which server-side files exist in your environment and how many times they are used. The EnumAllWebs command specifies which files are used by which sites.

For more information about how to identify customizations in your environment, see Use a trial upgrade to find potential issues (SharePoint Foundation 2010). If customizations are not being used, delete them. For more information about how to manage these kinds of customizations, see Features and Templates (http://go.microsoft.com/fwlink/p/?LinkId=182338) and Solutions and Web Part Packages (http://go.microsoft.com/fwlink/p/?LinkId=182332) on MSDN.

Repair data issues

Make sure that you repair any issues in your databases or site content before you upgrade. In particular, check the following items:

  • Check databases for corrupted data

    Clean up your databases to remove any orphaned sites or other corrupted data, such as a corrupted list. Consider defragmenting if you have removed sites or subsites from the database. For more information, see:

    • Databaserepair: Stsadm operation (Windows SharePoint Services)

    • Forcedeletelist: Stsadm operation (Windows SharePoint Services)

  • Check databases for duplicate or orphaned site collections

    Make sure that site collections exist in only one content database. Occasionally, site collections can leave behind duplicate or orphaned references in old content databases if they are moved to new ones, or if a duplicate copy of a database was attached to the farm, or if there was an error when a site collection was provisioned. If a site collection is referenced in more than one content database or there is more than one instance of the site collection in a content database, it can cause issues when you upgrade by using the database attach upgrade method. If you upgrade a duplicate version of the site collection first, the site map in your configuration database might end up pointing to that version of the site rather than the current version.

    Before you upgrade, use the pre-upgrade checker tool to identify all site collections and look for any duplicate or orphaned sites - any sites with the same URL or the same GUID as another site. For more information, see Run the pre-upgrade checker (SharePoint Foundation 2010). Also, use the enumallwebs operation in Stsadm.exe to find out which sites are in which content databases and compare the results. For more information, see Enumallwebs: Stsadm operation (Windows SharePoint Services). If you find duplicate or orphaned sites, you can use the deletesite operation in Stsadm.exe to remove the duplicate or orphaned sites from the database. To delete a site from a specific content database, use the following command:

    Copy Code
    Stsadm -o deletesite -force -siteid <SiteID> -database <databasename> -databaseserver <Servername>

    For more information, see Deletesite: Stsadm operation (Windows SharePoint Services).

Making structural changes

If you want to make structural changes to your environment, such as moving site collections around or changing how your databases are allocated, you can use the following methods:

  • Stsadm -o mergecontentdbs Use this to move site collections between databases. Upgrade is most efficient when databases contain similar data. Therefore, it is best if any site collections that share a content database are similar types. You can also use this operation to divide large databases if they contain multiple site collections. This can also help increase upgrade efficiency.

    For more information, see Mergecontentdbs: Stsadm operation (Windows SharePoint Services).

  • Export and import sites Use this method to move subwebs or site collections within a farm or between farms. For more information, see Import and export: Stsadm operations (Windows SharePoint Services).

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Troubleshoot upgrade issues (SharePoint Foundation 2010)
See Also

Even after you test the upgrade process to identify potential issues, you might experience unexpected issues during an upgrade from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010. If you experience issues after upgrade, the sooner you detect and fix them, the better the end-user experience will be.

This article describes general principles for identifying and addressing upgrade issues, and includes a list of common issues. After you have identified and addressed the issues, you can resume upgrade. For more information about how to resume upgrade, see Resume upgrade (SharePoint Foundation 2010).

In this article:

  • General principles for identifying issues

  • Common issues

    • Missing or deprecated server-side files or customizations

    • Incorrectly configured or missing settings for server farm, Web application, or services

    • Inconsistent or incorrect update levels

    • Missing global navigation for blogs

    • Data issues

    • UI changes

    • Lack of space

    • Forms-based authentication

    • Security and permissions

    • .Stp files are not working after upgrade

    • Cannot find new versions of the Fabulous 40 application templates

General principles for identifying issues

Start by checking the upgrade status to see where upgrade stopped (if it did stop), and check log files to find any errors or warnings. Next, address the issues that you find before you resume the upgrade.

First, check upgrade status and log files

Upgrade status indicators and log files should give you an indication of what went wrong during the upgrade process. We recommend that you carefully review all the errors that were logged in the upgrade log files. Warnings might not always indicate an issue, but you should review them all to determine whether any of them are likely to cause even more issues.

  1. Check upgrade status by doing one or both of the following:

    • Review the Upgrade Status page in the SharePoint Central Administration Web site.

    • Use the Stsadm.exe operation localupgradestatus to check upgrade status.

    For more information about how to check upgrade status, see Verify upgrade and review upgraded sites (SharePoint Foundation 2010).

  2. Review the following log files:

    • The Setup.exe log file.

    • The SharePoint Products Configuration Wizard (Psconfig.exe) log file.

    • The upgrade error log file and the upgrade log file (which contains more detailed information than the upgrade error log file).

    • ULS or trace log files.

      These files are stored in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14\LOGS folder and are named Servername_YYYYMMDD-MMSS.log.

    • The application event log file.

      This file can be viewed by using the Event Viewer.

    For more information about the Setup.exe, PSconfig.exe, and upgrade log files, see Verify upgrade and review upgraded sites (SharePoint Foundation 2010). For more information about the trace log file, see Trace Logs (http://go.microsoft.com/fwlink/p/?LinkId=182380) on MSDN.

Then, address issues in order

Some issues have more effect than others. For example, a missing server-side file can cause many seemingly unrelated errors at the site level.

Address issues in the following order:

  1. Missing server-side files or customizations, such as features or Web Parts.

  2. Configuration issues in the server farm, Web application, or services, such as managed paths or services that are not started.

  3. Additional issues that you discover on a site-by-site basis, starting with high-impact, high-profile sites.

As you identify and fix the top-level issues, you can try running upgrade again to see whether any issues further along in the upgrade process have also been fixed.

Common issues

Check to see whether any of the following issues are causing an upgrade error or warning.

Missing or deprecated server-side files or customizations

One common error during upgrade is missing server-side files — either files that were installed with Windows SharePoint Services 3.0 or customized files. When you prepared for upgrade, you should have created an inventory of the server-side customizations (such as site definitions, templates, features, Web Parts, assemblies) that your sites required. (The pre-upgrade checker can help identify these items.) Check this inventory to make sure that all the files that are needed for your customizations are installed in your upgrade environment.

If you are performing a database attach upgrade, you can use the test-spcontentdatabaseWindows PowerShell cmdlet before you upgrade the database to identify any missing files. You can also use the enumallwebs operation in Stsadm.exe to identify server-side customizations that are being used.

In the upgrade log files, you may see errors such as the following:

  • ERROR Found Reference Count web(s) using missing web template Site Template Identifier (lcid: Site Template Language Code) in ContentDatabase Content Database Name.

  • ERROR Found a missing feature Id = [Feature Identifier]

  • ERROR File [Relative File Path] is referenced [Reference Count] times in the database, but is not installed on the current farm.

  • WARNING WebPart class [Web Part Identifier] is referenced [Reference Count] times in the database, but is not installed on the current farm.

  • WARNING Assembly [Assembly Path] is referenced in the database, but is not installed on the current farm.

  • WARNING Feature could not be upgraded. Exception: Feature definition id 'Feature Identifier' could not be found.

If you can obtain a missing server-side file or dependency, install it and then run upgrade again for the affected sites. If the file or dependency (such as a Web Part) has been deprecated, you have to investigate whether you want to rebuild the site, page, or Web Part to use a different template, feature, or Web Part. If you can redo the customization by using dependencies that have not been deprecated, you can run upgrade again for the affected sites. If you cannot remove the dependency, you cannot upgrade the site.

After you install the missing file or dependency, use the test-SPContentDatabaseWindows PowerShell cmdlet on a test server to determine whether any other files for that database are missing. If you only run the pre-upgrade checker or run upgrade again, the error might not appear in the log files, even though it might still be occurring.

Incorrectly configured or missing settings for server farm, Web application, or services

Verify your farm and Web application settings, and create and start any missing services.

Verify that any managed paths (included or excluded paths) are configured correctly for each Web application.

In the upgrade log files, you may see errors such as the following:

  • ERROR Template Template Id: SPSite Id=Site Id could not be accessed due to exception. Skipping SPWeb Id=Web Id for template upgrade. Exception: System.IO.FileNotFoundException: The site with the id Site Id could not be found.

    This error indicates that a managed path is missing. Add the managed path for the site collection into the Web application and restart upgrade for the content database that contains this site collection.

Inconsistent or incorrect update levels

You must be running Windows SharePoint Services 3.0 with Service Pack 2 to run upgrade. If you do not meet this minimum requirement, you will see an error and upgrade will not run.

Missing global navigation for blogs

Another common error is the global navigation is missing for upgraded blogs. This occurs because the MySiteNavigation (6adff05c-d581-4c05-a6b9-920f15ec6fd9) feature is not enabled during the upgrade. To enable this feature, run the Enable-SPFeatureWindows PowerShell 2.0 cmdlet.

For more information, see Enable-SPFeature.

Data issues

The following data issues can cause errors or warnings during upgrade:

  • Connectivity to data sources. If your servers cannot connect to the databases, they cannot be upgraded.

  • Orphaned sites or lists, or other database corruptions. For more information, see Clean up an environment before upgrade (SharePoint Foundation 2010).

  • Hidden column data. If the upgrade process adds a column to a list, and a custom column that has that same name already exists in the list, the custom column is renamed. After upgrade, you might have to readjust your views to include the renamed column.

In the upgrade log files, you may see errors such as the following:

  • WARNING The orphaned sites could cause upgrade failures.

  • ERROR Database [Content Database Name] contains a site (Id = [Site Collection Identifier], Url = [Site Collection URL]) that is not found in the site map.

Fix any orphaned items or database corruptions, and then run upgrade again.

UI changes

Changes to the user interface (UI), such as the addition of the Fluent UI (also known as the ribbon) or adherence to XHTML standards, can cause problems in sites. Occasionally, custom elements (such as a content type) may have a name that conflicts with a name in the new version. You may also have pages that must be reverted to the standard site definition, or large lists for which you have to create new views.

For more information about how to review UI issues in sites, see Verify upgrade and review upgraded sites (SharePoint Foundation 2010).

In the upgrade log files, you may see errors such as the following:

  • Failed to activate site collection features on site Site Url. Exception: A duplicate content type name "name" was found.

    This error indicates that a 3rd party "Summary Info" content type was added to the specified site in o12 and during upgrade to o14 it name conflicts with our out of the box "Summary Info" content type. Delete or rename the 3rd party content type in the specified site to something other than "Summary Info" and re-run upgrade.

Lack of space

If you run out of space (for example, for transaction log files on your database servers), upgrade cannot continue. Free some space, or increase the size of the transaction log file before you resume upgrade. For more information, see Managing the Size of the Transaction Log File (http://go.microsoft.com/fwlink/p/?LinkID=124882).

Forms-based authentication

Additional steps are necessary if you are upgrading an environment that uses forms-based authentication. Follow the steps in Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010) to upgrade forms-based authentication providers.

Security and permissions

If you receive an error about an unknown account, or if a database is not upgraded, verify the following:

  • For an in-place upgrade, make sure that the account that you use to run the SharePoint Products Configuration Wizard is a member of the db_owner fixed database role for all the databases that you want to upgrade. If it is not a member of this role, you might see an error about an unknown user account when the wizard starts to upgrade the databases.

  • For a database attach upgrade, if you are moving databases between instances of SQL Server, make sure that you verify that security is configured correctly. Check that the accounts that you are using have the appropriate fixed roles and permissions on the databases, and that they will still be valid accounts if you are upgrading across domains.

.Stp files are not working after upgrade

Site templates (.stp files) are deprecated in SharePoint Foundation 2010 and cannot be used to create new sites. Existing sites that are based on .stp files will continue to function as usual. Solution packages (.wsp files) are the supported method for creating sites that are based on a template in SharePoint Foundation 2010. You can convert an .stp file to a .wsp file to continue to use the template after upgrade.

To convert an .stp file to a .wsp file

  1. In Windows SharePoint Services 3.0, create a site that is based on the template, and then upgrade the site to SharePoint Foundation 2010.

  2. In SharePoint Foundation 2010, on the Site Actions menu in the upgraded site, click Site Settings.

  3. On the Site Settings page, under Site Actions, click Save site as template.

  4. On the Save as Template page, enter a File name and Template name, and then click OK.

    The site template is saved as a .wsp file to the Solutions Gallery for that site collection and you can create new sites that are based on that solution.

Cannot find new versions of the Fabulous 40 application templates

Many people have used the "Fabulous 40" templates that were created for Windows SharePoint Services 3.0. Some of these templates were created as site admin templates (.stp files) and some were created as server admin templates (.wsp files). Microsoft is not releasing new versions of these templates for SharePoint 2010 Products. Also, .stp files are deprecated and cannot be used to create new sites when you upgrade to SharePoint Foundation 2010.

You can upgrade sites that are based on these templates. However, you should try to upgrade these sites in a test environment before you upgrade the production environment so that you can discover any potential issues. Use the pre-upgrade checker to discover any issues. (Some people have seen problems with custom workflows or CAML-based views in the templates.) Note that after upgrade, you will be unable to use .stp files to create new templates.

The following table describes how the templates can be used.

Type of template | Can I upgrade sites that are based on this template? | Can I use the template after upgrade?
Site admin (.stp file or site template) | Yes | No
Server admin (.wsp file or solution package) | Yes* | Yes*

*There are issues with some .wsp files after upgrade. In particular, after upgrade, some customers cannot create new sites that are based on the following templates: Absence Request and Vacation Schedule Management, Call Center, Help Desk, IT Team Workspace, Knowledge Base, and Physical Asset Tracking and Management. If you have problems using any of these templates, you can post an issue to the SharePoint 2010 - Setup, Upgrade, Administration and Operation TechNet Forum (http://go.microsoft.com/fwlink/p/?LinkId=201600), or contact Microsoft Customer Support.

If you want to continue to create sites that are based on the site admin templates (.stp files) in SharePoint Foundation 2010, you must convert them to solution packages (.wsp files). For more information, see the section .Stp files are not working after upgrade earlier in this article.

See Also

Concepts

Use a trial upgrade to find potential issues (SharePoint Foundation 2010)
Verify upgrade and review upgraded sites (SharePoint Foundation 2010)
Resume upgrade (SharePoint Foundation 2010)

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Recovering after a failed upgrade (SharePoint Foundation 2010)
See Also

If the upgrade to Microsoft SharePoint Foundation 2010 has failed and you do not have time to continue to troubleshoot the issues or resume the upgrade process, you have to recover your Windows SharePoint Services 3.0 environment. The steps differ depending on the type of backup you have. If you were performing a database attach upgrade and you kept your original environment available — either by using read-only databases or by taking the environment offline — you can recover your environment easily. If you were performing an in-place upgrade, you must recover your entire environment and restore the data.

If you do have time, you should troubleshoot the issues and resume upgrade. For more information, see Troubleshoot upgrade issues (SharePoint Foundation 2010) and Resume upgrade (SharePoint Foundation 2010).

In this article:

  • Recovering when you have read-only databases on a standby environment (database attach upgrade)

  • Recovering when you have a full environment backup (in-place upgrade)

  • Recovering when you have database backups (in-place upgrade)

Recovering when you have read-only databases in a standby environment (database attach upgrade)

When you perform a database attach upgrade, you can choose to leave your existing environment available, but with the databases set to read-only. Recovering when you are in this state is the simplest recovery path, because your original environment is still available, it is merely set to read-only. If you have to recover your environment, you can merely switch the databases to read/write again and resume serving requests. The article Run a farm that uses read-only databases (Windows SharePoint Services) describes the steps you take to set a farm to use read-only databases. To return the read-only farm to full operations, you set the Database Read-Only entry back to False, and then re-enable the timer jobs listed in the article.

Recovering when you have a full environment backup (in-place upgrade)

If you created a full backup of your environment before you started the upgrade process, you can restore that full backup to recover your environment. For more information about how to restore from a full backup, see Restore a farm by using built-in tools (Windows SharePoint Services 3.0).

Recovering when you have database backups (in-place upgrade)

If you only created backups of your content databases, you can still recover your environment, but it will take longer and involve more steps. You basically have to build out your environment again and then restore the database backups. For more information about how to recover an environment and restore backed up content databases, see Restore a farm after a configuration database problem (Windows SharePoint Services).

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Resume upgrade (SharePoint Foundation 2010)
See Also

In some cases, you might have to restart upgrade to finish upgrading your sites from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010. For example:

  • During an in-place upgrade, if the server restarts or the upgrade fails, you must restart the upgrade process by using Psconfig.exe to upgrade the remaining sites.

  • During a database attach upgrade, any sites that cannot be upgraded will be skipped. After you have corrected any issues in the sites (such as a missing template or language pack, or the site being set to read-only or having exceeded its quota), you can restart upgrade by using a Windows PowerShell command to upgrade just the skipped sites.

Note:

One frequent cause of failures during upgrade is that the environment is missing customized features, solutions, or other elements. Be sure that any custom elements that you need are installed on your front-end Web servers before you begin the upgrade process. You can use the pre-upgrade checker — and, for a database attach upgrade, the test-spcontentdatabaseWindows PowerShell cmdlet — to identify any custom elements that your sites might be using. For more information, see Identify and install customizations in the article "Use a trial upgrade to find potential issues."

In this article:

  • Restart upgrade for a server farm by using Psconfig.exe

  • Restart upgrade for a database by using Windows PowerShell

Restart upgrade for a server farm by using Psconfig.exe

If you determine that upgrade stopped or failed before the SharePoint Products Configuration Wizard was completed, you can restart the upgrade from that point by running the SharePoint Products Configuration Wizard again or by using a command line operation. This process is also known as forcing a software upgrade. Be sure to research and address the problem that caused the failure or stoppage before you restart upgrade.

To restart upgrade for the server farm

  1. Verify that you have the following administrative credentials:

    • To use Psconfig.exe, you must be a member of the local Administrators group on the server.

  2. Open a Command Prompt window and navigate to the following directory:

    %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\14\Bin\

  3. Type the following command:

    psconfig -cmd upgrade -inplace v2v -passphrase <passphrase> -wait

    Where <passphrase> is the passphrase that was specified when SharePoint Products Configuration Wizard was run. The passphrase is used to join the server farm. The passphrase value must be the same on all servers in the farm if the farm is to function correctly.

    There is an optional parameter, -force, that can force the upgrade to continue if the command does not work. Add -force to the end of the command string to force the upgrade process to continue.

Note:

You can enable Windows Installer logging before you start the software upgrade installation again. To enable logging for Windows Installer, see Microsoft Knowledge Base article 99206: How to enable Windows Installer logging (http://go.microsoft.com/fwlink/p/?LinkID=99206).

Restart upgrade for a database by using Windows PowerShell

If the upgrade skipped any site collections during in-place upgrade or database attach upgrade, you can restart the upgrade process for the database that contains that site collection by using a Windows PowerShell cmdlet.

To restart upgrade for a database 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. At the Windows PowerShell command prompt (PS C:\>), type the following command:

    upgrade-spcontentdatabase -id <GUID>

    Where GUID is the identifier for the database. You can run the following cmdlet to find the GUID for a content database:

    Get-SPContentDatabase -Identity<content_database_name>

For more information, see Upgrade-SPContentDatabase.

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Perform pre-upgrade steps (SharePoint Foundation 2010)
See Also

After you have planned your upgrade process to Microsoft SharePoint Foundation 2010, you can start the upgrade process by following the required pre-upgrade steps.

In this section:

  • Run the pre-upgrade checker (SharePoint Foundation 2010)

    The pre-upgrade checker identifies potential upgrade issues in your environment. Run this as you plan your upgrade and before you start the upgrade process, so that you can address these issues.

  • Back up the entire environment before an in-place upgrade (SharePoint Foundation 2010)

    Create a full backup of your environment to ensure that you can recover if upgrade does not go as planned.

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Run the pre-upgrade checker (SharePoint Foundation 2010)
See Also

You can use the pre-upgrade checker to report on the status of your environment and SharePoint sites before you upgrade to Microsoft SharePoint Foundation 2010. We highly recommend that the server administrator run the pre-upgrade checker and resolve as many problems as possible before scheduling the upgrade.

The pre-upgrade checker is an Stsadm operation that you run in a Windows SharePoint Services 3.0 environment to find any potential issues for upgrade and to review recommendations and best practices. The operation is available with Windows SharePoint Services 3.0 Service Pack 2 and has been updated in the October 2009 Cumulative Update for Windows SharePoint Services 3.0. You can download and install the October 2009 Cumulative Update from October 2009 Cumulative Update Packages for SharePoint Server 2007 and Windows SharePoint Services 3.0 are published (http://go.microsoft.com/fwlink/p/?LinkID=169179).

Note:

You might need to run the pre-upgrade checker more than once. For example, if you run the tool to evaluate your server farm but do not perform the upgrade for a few weeks, you can run the tool again just before you perform the upgrade to scan any new sites and to ensure that no additional issues have appeared in the meantime.

In this article:

  • About the pre-upgrade checker report

  • Run the pre-upgrade checker

Note:

One frequent cause of failures during upgrade is that the environment is missing customized features, solutions, or other elements. Be sure that any custom elements you need are installed on your front-end Web servers before you begin the upgrade process. You can use the pre-upgrade checker — and, for a database attach upgrade, the test-spcontentdatabaseWindows PowerShell cmdlet — to identify any custom elements that your sites might be using. For more information, see Identify and install customizations in the article "Use a trial upgrade to find potential issues."

About the pre-upgrade checker report

The pre-upgrade checker reports information about the status of your environment and the SharePoint sites in that environment, including:

  • Upgrade readiness and supported paths Returns a list of all servers and components in the farm and information about whether the servers meet requirements for upgrading.

  • Alternate access mapping settings Returns a list of the alternate access mapping URLs that are being used in the farm.

  • Installed elements Returns a list of all site definitions, site templates, features, and language packs that are installed in the farm. You need to know which site templates have been installed or used so that you can verify that they are available after an upgrade or database attach. You also need to know which elements have been customized so you can verify the customizations again after the upgrade. For example, you need to know whether a site depends on a language pack for Windows SharePoint Services 3.0 that does not exist yet for SharePoint Foundation 2010, so you can plan how to handle that site during upgrade.

  • Unsupported customizations Reports whether any server-side customizations that are not supported (such as database schema modifications) exist in the farm.

  • Orphaned objects Lists any database or site orphans in the farm. Objects such as list items, lists, documents, Web sites, and site collections can become orphaned — that is, the objects exist but are not associated with a particular site. Because orphaned objects do not work in the previous version, they won't work after the upgrade. If you perform an in-place upgrade, the orphaned items will still exist, but will not work. We recommend that you repair any orphaned objects before upgrading.

    Tip:

    Members of the Administrators group on the front-end Web servers can repair orphaned items before the upgrade by following the steps in Knowledge Base article 918744, Description of a new command-line operation that you can use to repair content databases in Windows SharePoint Services (http://go.microsoft.com/fwlink/p/?linkid=69958&clcid=0x409).

  • Valid configuration settings Reports any missing or invalid configuration settings (such as a missing Web.config file, invalid host names, or invalid service accounts) that exist in the farm.

  • Database requirements Reports whether the databases meet the requirements for upgrade — for example, databases are set to read/write, and any databases and site collections that are stored in the Windows Internal Database are not larger than 4 GB.

Use the information gathered from the pre-upgrade checker to determine:

  • Whether to perform an in-place upgrade or a database attach upgrade.

    Determine upgrade approach (SharePoint Foundation 2010) provides information to help you decide which type of upgrade to perform. It is important to consider the report generated by the pre-upgrade checker when you make this decision. If your servers do not meet the requirements for in-place upgrade, you need to consider performing a database attach upgrade.

  • Whether to upgrade some or all site collections that contain customized sites.

  • Which sites need to have customizations reapplied or redone after upgrade and therefore might take longer than others in the review stage.

A worksheet is available so you can record information about your environment while you prepare for upgrade. Download the worksheet from http://go.microsoft.com/fwlink/p/?LinkId=179928.

Run the pre-upgrade checker

Before you perform this procedure, confirm that:

  • Your system is running Windows SharePoint Services 3.0 with Service Pack 2

To run the pre-upgrade checker

  1. Verify that you have the following administrative credentials:

    • To use Stsadm, you must be a member of the local Administrators group on the server.

  2. Click Start, right-click Command Prompt, and then click Run as administrator.

  3. In the Command Prompt window, navigate to the following directory:

    %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\bin

  4. Type the following command and press ENTER:

    STSADM.EXE -o preupgradecheck

    This command checks both the local server and your farm-level settings. For a list of other parameters you can use with this operation, see Preupgradecheck: Stsadm operation (Windows SharePoint Services). For a list of rules included in the pre-upgrade checker, see Pre-upgrade scanning and reporting for future releases (Windows SharePoint Services).

After you run the pre-upgrade checker, the report automatically opens in your default browser. You can also view the report by opening it from its location in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\LOGS directory. The report is named in the following format: PreUpgradeCheck_YYYYMMDD-HHMMSS-SSS-random-number.htm, where YYYYMMDD is the date and HHMMSS-SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds), and the random number is used to differentiate between possible simultaneous attempts to run the pre-upgrade checker. There are also TXT and XML versions of the report in the same location.

Use the report to find and troubleshoot issues. You can also share the relevant results with other members of the upgrade team. For example, you can report issues such as customized site templates or custom Web Parts to the appropriate site owner, Web designer, or developer before scheduling the upgrade, to give them time to resolve the issues.

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Back up the entire environment before an in-place upgrade (SharePoint Foundation 2010)
See Also

To ensure that you can recover the existing environment in case something goes wrong during the upgrade process, you must back up the Windows SharePoint Services 3.0 environment before you run the upgrade process.

If you are running Windows SharePoint Services 3.0 in a Hyper-V virtual environment, see Using SharePoint Products and Technologies in a Hyper-V virtual environment (http://go.microsoft.com/fwlink/p/?LinkID=125834&clcid=0x409).

Back up the environment

You can do a full backup of the Windows SharePoint Services 3.0 environment. We recommend that you perform a full backup of the farm before upgrading.

To back up the Windows SharePoint Services 3.0 environment, use the procedures described in Back up a farm by using built-in tools (Windows SharePoint Services 3.0) (http://go.microsoft.com/fwlink/p/?LinkID=105988&clcid=0x409).

If you have deployed customizations, you must also back up the customizations. For more information, see Back up and restore customizations (Windows SharePoint Services) (http://go.microsoft.com/fwlink/p/?LinkId=186627).

Test the backups

You have to be sure that these backups are valid so that you can recover if there is a hardware failure or data corruption during the upgrade process. To test the backups, set up a non-production Windows SharePoint Services 3.0 farm, restore the backups and install any customizations (such as site definitions, Web Parts, and so on), and then verify that the restored backup is functional.

To do this, use the procedures described in Restore a farm by using built-in tools (Windows SharePoint Services 3.0) (http://go.microsoft.com/fwlink/p/?LinkID=105989&clcid=0x409).

See Also

Other Resources

Back up and restore the farm (Windows SharePoint Services 3.0)
Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Perform an in-place upgrade (SharePoint Foundation 2010)
See Also

Now that you have learned about the upgrade process by reading the articles in About the upgrade process (SharePoint Foundation 2010), and planned for your upgrade by following the steps in the articles in Plan and prepare for upgrade (SharePoint Foundation 2010), you are ready to perform the in-place upgrade to Microsoft SharePoint Foundation 2010. You can use the steps in this section for both a trial upgrade and your actual in-place upgrade on your production farm.

In this section:

  • Checklist for in-place upgrade (SharePoint Foundation 2010)

    Use this checklist to make sure that you follow all necessary steps as you prepare for upgrade, perform the upgrade, and perform post-upgrade steps.

  • Upgrade in place to SharePoint Foundation 2010

    Get all the steps that you need to perform an in-place upgrade, from installing prerequisites to upgrading sites.

  • Upgrade a stand-alone installation by using RBS (in-place) (SharePoint Foundation 2010)

    Get the steps to upgrade to SharePoint Foundation 2010 from a stand-alone Windows SharePoint Services 3.0 system that has content databases that are larger than 4 gigabytes (GB).

  • Roadmap: in-place upgrade with detached databases (SharePoint Foundation 2010)

    Understand the process for using the detach databases hybrid approach to upgrade. This approach combines an in-place upgrade with the efficiency and speed of upgrading multiple databases at the same time.

  • Install available language template packs (SharePoint Foundation 2010)

    Install any language packs that you need for your environment, after you run Setup and before you run the SharePoint Products Configuration Wizard.

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Checklist for in-place upgrade (SharePoint Foundation 2010)
See Also

This article contains a checklist you can use to make sure that you followed all necessary steps as you prepare for upgrade, perform the upgrade, and perform post-upgrade steps.

In this article:

  • Prepare for upgrade

  • Perform the upgrade

  • Perform post-upgrade steps

Some of the steps include notes about the amount of time the steps might take. These are rough estimates only, to give you a relative idea of the duration of the step. To find out how much time each step will take for your environment, we recommend that you perform trial upgrades in a test environment. For more information, see Estimate how long the upgrade process will take and the space that you need (SharePoint Foundation 2010) and Use a trial upgrade to find potential issues (SharePoint Foundation 2010).

Prepare for upgrade

Follow these steps in order before you begin an in-place upgrade:

Pre-upgrade steps for an in-place upgrade Notes

[ ]

Run the pre-upgrade checker

Run the pre-upgrade checker and address any issues. Use the report that is generated by the tool to fill out the Upgrade planning worksheet.

Detailed steps: Run the pre-upgrade checker (SharePoint Foundation 2010).

Perform this step multiple times as you clean up your environment and test your upgrade process.

Running the checker takes only a few minutes, but addressing any issues might take days or weeks.

[ ]

Clean up your environment

Before you begin the upgrade, make sure that your environment functions in a healthy state and that you clean up any content that you do not have to keep. Remove or repair any orphaned sites or data, address any large lists or large access control lists (ACLs), remove extraneous document versions, and remove any unused templates, features, or Web Parts.

Detailed steps: Clean up an environment before upgrade (SharePoint Foundation 2010).

Perform this step once for the whole environment.

This process might take days or weeks to complete.

[ ]

Record blocked file types

Blocked file types are not preserved during upgrade. Copy the list of blocked file types and save the list in the upgrade worksheet so you can reapply the settings after upgrade.

Perform this step once for the whole environment.

[ ]

Back up your environment

Back up your entire environment to ensure that you can recover the existing environment in case something goes wrong during the upgrade process.

Detailed steps: Back up the entire environment before an in-place upgrade (SharePoint Foundation 2010).

Perform this step once for the whole environment.

This step can take an hour, several hours, or longer, depending on your data set and your environment.

Perform the upgrade

Follow these steps in order during an in-place upgrade. Steps required for in-place upgrade with detached databases are also included.

Warning:

When you upgrade in-place from an installation of Windows SharePoint Services 3.0 that uses Windows Internal Database and the database size approaches 4 GB, you must perform additional steps. For more information about these steps, see Upgrading from a stand-alone installation of Windows SharePoint Services 3.0 to SharePoint Foundation 2010 when content databases exceed 4 GB (RBS).

Perform the in-place upgrade Notes

[ ]

Run the pre-upgrade checker

Run the pre-upgrade checker again to identify any new or remaining issues before you start the upgrade.

Detailed steps: Run the pre-upgrade checker (SharePoint Foundation 2010).

Running the checker takes only a few minutes, but addressing any issues might take longer.

[ ]

Install prerequisites on all servers

Before you can upgrade, you must run the prerequisite installer successfully on each Web server that has Windows SharePoint Services 3.0 installed.

Detailed steps: Install prerequisites in the "Upgrade in place to SharePoint Foundation 2010" article.

Perform this step for each Web server in your environment.

[ ]

Detach databases (in-place upgrade with detached databases only)

If you are performing an in-place upgrade with detached databases, detach the databases before you run Setup.

Detailed steps: Roadmap: in-place upgrade with detached databases (SharePoint Foundation 2010).

Perform this step for each content database in your environment.

[ ]

Disconnect users

If you are upgrading a server farm, disconnect all the users from the server farm by stopping the World Wide Web Publishing Service (W3SVC) on all Web servers.

Perform this step on each Web server in your environment.

[ ]

Run Setup on all servers

Run Setup on all servers to upgrade the software.

Detailed steps: Run Setup on all servers in the "Upgrade in place to SharePoint Foundation 2010" article.

Perform this step for each Web server in your environment.

This step might take a few minutes or more than an hour, depending on how many servers are in your environment.

[ ]

Install language packs

Install any language packs you need before you run the SharePoint Products Configuration Wizard.

Detailed steps: Install available language template packs (SharePoint Foundation 2010).

Perform this step on each Web server in your environment.

This step should take only a few minutes per Web server.

[ ]

Run the SharePoint Products Configuration Wizard

If you are upgrading a server farm, first run the SharePoint Products Configuration Wizard on the server that is running SharePoint Central Administration, pause and run the wizard on the other servers in the farm, and then return to the first server to complete the wizard.

Important:

You must upgrade SharePoint Central Administration before you attempt to upgrade any other content in the farm. Completing the wizard on the server running SharePoint Central Administration allows you to do so.

Detailed steps: Run the SharePoint Products Configuration Wizard in the "Upgrade in place to SharePoint Foundation 2010" article.

Perform this step for each Web server in your environment.

This step might take an hour or more.

[ ]

Configure forms-based authentication for a claims-based Web application (in-place upgrade with detached databases only)

For Web applications that were configured to use forms-based authentication or Web single sign-on (Web SSO) authentication, you must perform additional steps before you attach and upgrade the databases. First, you convert the Windows SharePoint Services 3.0 Web applications to claims authentication. After you convert the Web applications to claims authentication, you configure your Web application zones for forms-based authentication (or Web SSO authentication, as appropriate). Then, you can migrate users and permissions to SharePoint Foundation 2010.

Detailed steps: Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010).

Perform this step now if you are following the in-place upgrade with detached databases approach. If you are following a standard in-place upgrade approach, perform this step after upgrade is completed.

Perform this step for any Web applications that used forms-based authentication in Windows SharePoint Services 3.0.

[ ]

Attach databases (in-place upgrade with detached databases only)

If you are performing an in-place upgrade with detached databases, attach the databases and then upgrade the data.

Detailed steps: Roadmap: in-place upgrade with detached databases (SharePoint Foundation 2010).

Perform this step for each content database in your environment.

This step might take an hour, several hours, or days, depending on your data set, whether you are upgrading multiple databases in parallel, and the hardware on the Web servers, database servers, and storage subsystem.

[ ]

Monitor upgrade progress

Use the Upgrade Status page in SharePoint Central Administration to monitor progress as your sites are upgraded.

Detailed steps: Verify upgrade and review upgraded sites (SharePoint Foundation 2010).

Perform this step once for the whole environment.

This step might take an hour, several hours, or days, depending on your data set.

Perform post-upgrade steps

Perform the following steps in order after you perform an in-place upgrade.

Post-upgrade steps for an in-place upgrade Notes

[ ]

Configure forms-based authentication for a claims-based Web application

For Web applications that were configured to use forms-based authentication or Web single sign-on (Web SSO) authentication, you must perform additional steps after upgrading. First, you convert the Windows SharePoint Services 3.0 Web applications to claims authentication. After you convert the Web applications to claims authentication, you configure your Web application zones for forms-based authentication (or Web SSO authentication, as appropriate). Then, you can migrate users and permissions to SharePoint Foundation 2010.

Detailed steps: Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010).

Perform this step for any Web applications that used forms-based authentication in Windows SharePoint Services 3.0.

[ ]

Verify upgrade and review upgraded sites

Review sites to be sure that they have been upgraded successfully and are ready for users to view.

Detailed steps: Verify upgrade and review upgraded sites (SharePoint Foundation 2010).

Perform this step for every upgraded Web application and site collection in your environment.

This step might take an hour, several hours, or days, depending on your content.

You should also have site owners review their sites and report any issues.

See Also

Other Resources

Upgrade Worksheet for SharePoint 2010 Products
Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Upgrade in place to SharePoint Foundation 2010
See Also

When you run an in-place upgrade from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010, the configuration data for the farm and all the content in the farm is upgraded on the existing hardware, in a fixed order. When you start the in-place upgrade process, Setup takes the Web server offline and the Web sites are unavailable until the upgrade is finished, and then Setup restarts the Web server. After you begin an in-place upgrade, you cannot pause the upgrade or roll back to the previous version.

Note:

One frequent cause of failures during upgrade is that the environment is missing customized features, solutions, or other elements. Be sure that any custom elements you have to have are installed on your front-end Web servers before you begin the upgrade process. You can use the pre-upgrade checker to identify any custom elements that your sites might be using. For more information, see Identify and install customizations in the article "Use a trial upgrade to find potential issues."

Upgrading in place from an installation of Windows SharePoint Services 3.0 that uses Windows Internal Database requires additional steps if your database size has exceeded 4 GB. For more information, see Upgrading from a stand-alone installation of Windows SharePoint Services 3.0 to SharePoint Foundation 2010 when content databases exceed 4 GB (RBS).

You can also use many of the procedures in this article to perform a detach databases hybrid approach to upgrade, where you upgrade the server and infrastructure in place but upgrade the content databases by detaching and attaching them in parallel. For information about the detach databases process, see Roadmap: in-place upgrade with detached databases (SharePoint Foundation 2010). For more information about how to choose an upgrade approach, see Determine upgrade approach (SharePoint Foundation 2010) and Upgrade process overview (SharePoint Foundation 2010).

Important:

You must be running Service Pack 2 (SP2) of Windows SharePoint Services 3.0 in a 64-bit Windows Server 2008 environment to perform an in-place upgrade to SharePoint Foundation 2010. If you are in a server farm environment, you must also be running a 64-bit version of Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, or SQL Server 2005 with SP3 and Cumulative Update 3.

In this article:

  • Process overview

  • Before you begin

  • Install prerequisites

  • Run Setup on all servers

  • Run the SharePoint Products Configuration Wizard

  • Check upgrade status for sites

  • Verification

Process overview

By using the procedures in this article, you install SharePoint Foundation 2010 and upgrade all of the SharePoint sites in the environment. We recommend that you try out the upgrade process on a test environment before you attempt to upgrade your production environment. For more information, see Use a trial upgrade to find potential issues (SharePoint Foundation 2010).

When you upgrade a server farm, install and configure the new version to the servers in the following order:

  1. Install SharePoint Foundation 2010 on all servers in the server farm.

  2. Install any language packs for SharePoint Foundation 2010 that you need. For more information, see Install available language template packs (SharePoint Foundation 2010).

  3. Run the SharePoint Products Configuration Wizard on the front-end Web server that contains the SharePoint Central Administration Web site.

    To determine which server is running SharePoint Central Administration, open the Servers in Farm page (http://server_name:adminport/_admin/farmservers.aspx) and note which server or servers have Central Administration services running. Perform this step before you install SharePoint Foundation 2010, while SharePoint Central Administration for Windows SharePoint Services 3.0 is still available.

    Note:

    If you have multiple servers that are running SharePoint Central Administration, pick one and use that as the initial server on which to run upgrade. After you have completed the process on that one, you can continue with any other servers that are running SharePoint Central Administration.

  4. Run the SharePoint Products Configuration Wizard on the remaining front-end Web servers and application servers in the farm in any order.

For an overview and diagrams of the each upgrade approach, see Upgrade process overview (SharePoint Foundation 2010).

Note:

If you are using the detach databases hybrid approach for upgrading, the process you follow is similar, but you detach all content databases before you run Setup, and then attach them again after you run the SharePoint Products Configuration Wizard. For more information about the detach databases upgrade approach, see Roadmap: in-place upgrade with detached databases (SharePoint Foundation 2010).

Before you begin

Before you begin the in-place upgrade, review the following information about permissions, hardware requirements, and software requirements and steps to perform before beginning the process.

  • Make sure that you have run the pre-upgrade checker tool (stsadm -o preupgradecheck, available in Windows SharePoint Services 3.0 Service Pack 2 and updated in the October 2009 Cumulative Update) and addressed any issues before you begin the upgrade process. For more information, see Run the pre-upgrade checker (SharePoint Foundation 2010).

  • We recommend that you back up your environment before you begin the upgrade process. For more information, see Back up the entire environment before an in-place upgrade (SharePoint Foundation 2010).

  • Ensure that you have met all hardware and software requirements. You must have a 64-bit version of Windows Server 2008 or Windows Server 2008 R2. For server farms, you must also have a 64-bit version of SQL Server 2005 or SQL Server 2008. For more information about these requirements (such as specific updates that you must install), see Determine hardware and software requirements (SharePoint Foundation 2010).

  • Ensure that you are prepared to set up the required accounts by using appropriate permissions. For detailed information, see Administrative and service accounts required for initial deployment (SharePoint Foundation 2010).

  • Ensure that the account that you use to run the SharePoint Products Configuration Wizard is a member of the db_owner fixed database role for all the databases that you want to upgrade.

Install prerequisites

Before you can upgrade, you must run the prerequisite installer successfully on each Web server that has Windows SharePoint Services 3.0 installed. A prerequisite installer is available to install software needed to support SharePoint Foundation 2010.

To run the prerequisite installer

  1. From the product disc, open the installation folder and run PrerequisiteInstaller.exe.

    The Microsoft SharePoint Products Preparation Tool opens.

  2. Click Next.

  3. On the License Terms page, select the I accept the terms of the License Agreement(s) check box, and then click Next.

    The tool runs, installing and configuring required software.

  4. Click Next.

  5. On the Installation Complete screen, verify that each prerequisite is listed as successfully installed or already installed.

  6. Click Finish to close the wizard.

Run Setup on all servers

After all of the prerequisites are installed, you can run Setup.exe on all Web servers in your server farm.

Note:

If you are using the detach databases hybrid approach for upgrading, you should detach your content databases before you run Setup. For more information about how to detach databases, see Roadmap: in-place upgrade with detached databases (SharePoint Foundation 2010).

Important:

If you are running an in-place upgrade on a server farm, disconnect all the users from the server farm by stopping the World Wide Web Publishing Service (W3SVC) on all front-end Web servers. If you allow users in a server farm to connect after the files and databases have been updated on one Web server, but before the other Web servers have been updated, users will not be able to browse the Web sites.

To install the new version

  1. Run Setup.exe.

  2. On the Read the Microsoft Software License Terms page, review the terms, select the I accept the terms of this agreement check box, and then click Continue.

  3. On the Upgrade earlier versions page, click Install Now.

  4. Setup runs and installs SharePoint Foundation 2010.

    On the completion page, clear the Run the SharePoint Products Configuration Wizard now check box, and then click Close.

Before you run the SharePoint Products Configuration Wizard, install any language template packs for SharePoint Foundation 2010. For more information, see Install available language template packs (SharePoint Foundation 2010).

Run the SharePoint Products Configuration Wizard

If you are upgrading a single server, you can run the SharePoint Products Configuration Wizard on only that server and start to upgrade content. If you are upgrading a server farm, first run the SharePoint Products Configuration Wizard on the server that is running SharePoint Central Administration, pause and run the wizard on the other servers in the farm, and then return to the first server to complete the wizard. It is important to upgrade SharePoint Central Administration before you attempt to upgrade any other content in the farm, and completing the wizard on the server that is running SharePoint Central Administration allows you to do so.

Important:

Ensure that the account you use to run the SharePoint Products Configuration Wizard is a member of the db_owner fixed database role for all the databases that you want to upgrade. If it is not, you might see an error about an unknown user account when the wizard starts to upgrade the databases.

Be sure that you have installed any language template packs before you run the SharePoint Products Configuration Wizard.

Caution:

After you run the SharePoint Products Configuration Wizard, Windows SharePoint Services 3.0 will no longer be available. You cannot pause or roll back the setup and upgrade process. Be sure that you have a current and valid backup of your environment before you proceed with installing SharePoint Foundation 2010.

To run the SharePoint Products Configuration Wizard

  1. Click Start, point to All Programs, point to Administrative Tools, and then click SharePoint Products Configuration Wizard.

  2. In the SharePoint Products Configuration Wizard, on the Welcome to SharePoint Products page, click Next.

    A message appears, notifying you that Internet Information Services (IIS), the SharePoint Administration Services v4, and the SharePoint Timer Service v4 may need to be restarted or reset during configuration.

  3. Click Yes to continue with the wizard.

  4. On the Specify Farm Settings page, in the Passphrase box, type a passphrase and in the Confirm passphrase box, type the same passphrase.

    The passphrase should consist of at least eight characters and should contain characters from at least three of the following four groups:

    • English uppercase characters (from A through Z)

    • English lowercase characters (from a through z)

    • Numerals (from 0 through 9)

    • Nonalphabetic characters (such as !, $, #, %)

  5. On the Visual Upgrade page, select one of the following options:

    • Change existing SharePoint sites to use the new user experience. Administrators control the user experience for end users.

      This option allows you to change all sites over to the new user experience without previewing that experience first. If you select this option, you can also choose between the following two options:

      • Preserve customized pages, but update template and application pages to use the new UI.

      • Reset all customized pages to their original templates. This option will delete modifications from customized pages and cannot be undone.

    • Preserve the look and feel of existing SharePoint sites, and allow end users to update their sites' user experience.

      This is the default option. This option allows the site owners to preview their sites in the new user experience and determine when they are ready to switch the sites over to the new user experience permanently.

  6. On the Completing the SharePoint Products Configuration Wizard page, verify the settings, and then click Next.

    The SharePoint Products Configuration Wizard runs and configures the configuration database and SharePoint Central Administration for SharePoint Foundation 2010.

  7. A message appears, notifying you that if you have a server farm with multiple servers, you must run Setup on each server to install new binary files before you continue the SharePoint Products Configuration Wizard.

    • If this is the only server in your farm, or if you have already run Setup on all the servers in your farm, click OK to continue with the wizard.

    • If you have not yet run Setup on all the servers in your farm, run Setup on the remaining servers now, and then return to this server and click OK to continue with the wizard.

    The SharePoint Products Configuration Wizard continues the upgrade process by setting up the configuration database and installing SharePoint Central Administration.

  8. On the Configuration Successful, Upgrade in Progress page, review the settings that have been configured, and then click Finish.

    The SharePoint Products Configuration Wizard closes and the Upgrade Status page opens. You might be prompted to enter your user name and password before the Upgrade Status page will open. The upgrade process might take awhile to complete, depending on how much data you have in your farm.

    Note:

    If you are following the detach databases hybrid approach for upgrade, you can now begin to attach content databases to upgrade them. For more information, see Roadmap: in-place upgrade with detached databases (SharePoint Foundation 2010).

  9. If you are upgrading a server farm, you can now complete the SharePoint Products Configuration Wizard on the other servers in the farm.

Check upgrade status for sites

After the SharePoint Products Configuration Wizard has finished, you can monitor the upgrade process for each site from the Upgrade Status page in SharePoint Central Administration or by using the localupgradestatus operation in Stsadm.exe. For more information, see Verify upgrade and review upgraded sites (SharePoint Foundation 2010).

After upgrade is completed successfully for all sites, if you stopped the World Wide Web Publishing Service (W3SVC) on all front-end Web servers before the upgrade, manually start the World Wide Web Publishing Service on the front-end Web servers to make the Web servers available to users.

Note:

Search results might be incomplete or might not be returned for a few minutes after upgrade. This is because the Search Synchronization Timer job must run after upgrade, and search results are not available until the job has finished.

Verification

If upgrade fails or reports issues, you can refer to the log and error files for more information. For more information about how to review the log files and how to restart upgrade after a failure, see Verify upgrade and review upgraded sites (SharePoint Foundation 2010). If you are using Visual Upgrade, for more information about previewing sites and changing to the new user interface, see Manage visual upgrade (SharePoint Foundation 2010).

See Also

Concepts

Troubleshoot upgrade issues (SharePoint Foundation 2010)

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Roadmap: in-place upgrade with detached databases (SharePoint Foundation 2010)
See Also

When you upgrade from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010, you can perform an in-place upgrade or a database attach upgrade, or you can combine certain aspects of both approaches to increase availability or throughput during the upgrade process. This article describes how to perform a hybrid approach that combines in-place upgrade with detaching and attaching databases so that you can upgrade multiple databases at the same time, possibly even on separate hardware. You can use this approach to upgrade two or more content databases at a time, and therefore upgrade more quickly than if you used a standard in-place upgrade (which upgrades individual content databases and site collections serially). This approach uses the following hybrid techniques:

  • Use an in-place upgrade to upgrade the farm and settings.

  • Detach and upgrade multiple databases in parallel.

  • Alternative upgrade sequence: Upgrade databases on a temporary small farm.

Note that if you decide to use a temporary small farm to perform the actual upgrade, you must have direct access to the database servers to copy the databases from. Copying databases over the network takes time and bandwidth — make sure you test this process to determine whether you have the resources you need to use a temporary small farm.

For more information about the pros and cons of the different upgrade approaches, see Determine upgrade approach (SharePoint Foundation 2010). For a brief overview and graphical description of the steps you take for each approach, see Upgrade process overview (SharePoint Foundation 2010).

Note:

One frequent cause of failures during upgrade is that the environment is missing customized features, solutions, or other elements. Be sure that any custom elements you need are installed on your front-end Web servers before you begin the upgrade process. You can use the pre-upgrade checker — and, for a database attach upgrade, the test-spcontentdatabaseWindows PowerShell cmdlet — to identify any custom elements that your sites might be using. For more information, see Identify and install customizations in the article "Use a trial upgrade to find potential issues."

In this article:

  • Process overview

  • Before you begin

  • To detach databases and upgrade them in parallel on the same farm

  • To detach databases and upgrade them in parallel on a temporary small farm

  • Verification

Important:

You must be running Service Pack 2 (SP2) of Windows SharePoint Services 3.0 in a 64-bit Windows Server 2008 environment to perform an in-place upgrade to SharePoint Foundation 2010. If you are in a server farm environment, you must also be running a 64-bit version of one of the following: Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, and SQL Server 2005 with SP3 and Cumulative Update 3.

Process overview

Because this upgrade approach is a hybrid of the techniques used for in-place upgrade and database attach upgrade, this article describes how the steps from each approach fit together into the hybrid process. It does not provide details for every step in the process, because those steps are available in the following articles:

  • Upgrade in place to SharePoint Foundation 2010

  • Attach databases and upgrade to SharePoint Foundation 2010

These articles, combined with this roadmap, give you the information you need to perform this hybrid upgrade.

There are two ways in which you can perform this type of hybrid upgrade: using one farm throughout or using a temporary small farm to perform the actual upgrade. The sections below provide the steps you need to take to perform the upgrade by using each of these methods.

Before you begin

Before you begin the in-place upgrade, review the following information about permissions, hardware requirements, and software requirements and steps to perform before beginning the process.

  • Be sure you have run the pre-upgrade checker tool (stsadm -o preupgradecheck, available in Windows SharePoint Services 3.0 Service Pack 2 and updated in the October 2009 Cumulative Update) and addressed any issues before you begin the upgrade process. For more information, see Run the pre-upgrade checker (SharePoint Foundation 2010).

  • We recommend that you back up your environment before you begin the upgrade process. For more information, see Back up the entire environment before an in-place upgrade (SharePoint Foundation 2010).

  • Ensure that you have met all hardware and software requirements. You must have a 64-bit version of Windows Server 2008 or Windows Server 2008 R2. For server farms, you must also have a 64-bit version of SQL Server 2005 or SQL Server 2008. For more information about these requirements (such as specific updates that you must install), see Determine hardware and software requirements (SharePoint Foundation 2010).

  • Ensure that you are prepared to set up the required accounts by using appropriate permissions. For detailed information, see Administrative and service accounts required for initial deployment (SharePoint Foundation 2010).

To detach databases and upgrade them in parallel on the same farm

This section describes the steps to take to use the detach databases upgrade approach on a single farm.

Process for upgrading in-place with detached databases (same farm)

Detach databases

  1. Use the following operation to detach the content databases:

    Stsadm.exe -o deletecontentdb -url http://servername-databasename ContentDatabaseName

    For more information about this operation, see Deletecontentdb: Stsadm operation (Windows SharePoint Services).

Upgrade the farm in place

  1. Install all prerequisites to all servers in the farm.

  2. Run Setup on all servers in the farm.

  3. Run the SharePoint Products Configuration Wizard on all servers in the farm.

For detailed procedures that describe these steps, see Upgrade in place to SharePoint Foundation 2010.

Attach the databases and upgrade the content

  1. Add the content databases to the Web applications.

    Use the following Windows PowerShell cmdlet to add and upgrade the content databases:

    Copy Code
    Mount-SPContentDatabase -Name <DatabaseName> -DatabaseServer <ServerName> -WebApplication <URL> [-Updateuserexperience]

  2. Verify upgrade for the first database.

  3. Repeat the restore-and-add-database procedures for remaining databases in parallel.

For detailed procedures that describe these steps, see Perform a database attach upgrade to SharePoint Foundation 2010.

To detach databases and upgrade them in parallel on a temporary small farm

This section describes the steps to take to use the detach databases upgrade approach on two farms: the original farm and a temporary small farm.

Process for upgrading in-place with detached databases (temporary small farm)

Set up a temporary small farm to use in upgrading the databases

For detailed procedures that describe these steps, see Prepare the new SharePoint Foundation 2010 environment for a database attach upgrade.

2 - Detach databases from the original farm

  1. Back up the previous version databases by using SQL Server tools.

    For detailed procedures about backing up the databases, see Perform a database attach upgrade to SharePoint Foundation 2010.

  2. Use the following operation to detach the content databases:

    Stsadm.exe -o deletecontentdb -url http://servername-databasename ContentDatabaseName

    For more information about this operation, see Deletecontentdb: Stsadm operation (Windows SharePoint Services).

Upgrade the original farm in place

  1. Install all prerequisites to all servers in the farm.

  2. Run Setup on all servers in the farm.

  3. Run the SharePoint Products Configuration Wizard on all servers in the farm.

For detailed procedures that describe these steps, see Perform an in-place upgrade (SharePoint Foundation 2010).

Attach the databases to the temporary small farm and upgrade the content

  1. Restore the backup copy to the new farm.

  2. Add the content databases to the Web applications.

    Use the following Windows PowerShell cmdlet to add and upgrade the content databases:

    Copy Code
    Mount-SPContentDatabase -Name <DatabaseName> -DatabaseServer <ServerName> -WebApplication <URL> [-Updateuserexperience]

  3. Verify upgrade for the first database.

  4. Repeat the restore-and-add-database procedures for remaining databases in parallel.

For detailed procedures that describe these steps, see Perform a database attach upgrade to SharePoint Foundation 2010.

Back up the databases from the temporary small farm and attach them to the original farm

  1. Back up the upgraded databases by using SQL Server tools.

  2. Restore the backup copy to the original farm.

  3. Add the upgraded content databases to the original Web applications.

This is basically the same process as the previous step; however, you are moving the databases from the temporary small farm back to the original farm. The same procedures apply as in the previous steps.

Verification

If upgrade fails or reports issues, you can refer to the log and error files for more information. For more information about reviewing the log files, and about restarting upgrade after a failure, see Verify upgrade and review upgraded sites (SharePoint Foundation 2010).

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Install available language template packs (SharePoint Foundation 2010)
See Also

Before you can upgrade any sites that are based on a language pack for the previous version, you have to install the language pack for the new version.

In this article:

  • About installing language packs and upgrading sites

  • About changing languages

  • Moving from a fully localized product to a language pack

  • Changing languages to a new language pack

About installing language packs and upgrading sites

If you want to install a language pack for Microsoft SharePoint Foundation 2010, do so after running Setup and before running the SharePoint Products Configuration Wizard. This way, you can upgrade any sites based on a language pack for a previous version along with the other sites during the upgrade process. For more information about installing language packs, see Deploy language packs (SharePoint Foundation 2010) in the Deployment Guide.

You can also install a language pack after you have run the SharePoint Products Configuration Wizard, and after you have upgraded the sites in your environment that are not based on a language pack. If you choose this option, you must then use the PSConfig command-line tool to upgrade the sites based on the newly installed language pack.

About changing languages

Generally, a cross-language upgrade is not supported. You must upgrade from and to the same language. For example, if you are running U.S. English in the previous version, you need to upgrade to U.S. English in the new version. If you want to change languages, you must first perform the upgrade and then change the language for the site.

However, this process is complicated in some cases — for example, when the previous version had a fully localized product for a particular language but the new version only has a language pack, or when the new version has a language pack for a new language that was not available in the previous version.

Moving from a fully localized product to a language pack

Use the following procedure on each Web server to upgrade from a language that was supported with a fully localized product in the previous version, but that is only supported by a language pack in the new version:

To move from a fully localized product to a language pack

  1. Verify that the user account performing this procedure is a member of the Farm Administrators SharePoint group. .

  2. Choose a language to install for the new version (for example, English). This is the language that the SharePoint Central Administration Web site will use.

  3. In the SharePoint Products Configuration Wizard, when you are prompted to install language packs, stop the wizard and install the appropriate language pack.

    If you had additional previous-version language packs installed, install the corresponding SharePoint Foundation 2010 language packs now by canceling the wizard, and then running the appropriate Setup programs to install the language packs.

    Note:

    You must be a member of the Administrators group on the local computer to perform this step.

    For more information about installing language packs, see Deploy language packs (SharePoint Foundation 2010) in the Deployment Guide.

  4. Start the configuration wizard again to complete the upgrade process.

Changing languages to a new language pack

Use the following process to upgrade from a language in the previous version to a different language in the new version (for example, if the language you want was not available in the previous version, but is now available as a language pack in the new version).

To change languages to a new language pack

  1. Verify that the user account performing the next two steps is a member of the Administrators group on the local computer.

  2. Upgrade to the new version in the same language that you used for the previous version.

  3. After the upgrade is complete, install the new language pack.

  4. Verify that the user account performing the next two steps is a member of the Farm Administrators SharePoint group.

  5. Create new sites based on the new language pack.

  6. Manually move your content to the new sites.

See Also

Concepts

Deploy language packs (SharePoint Foundation 2010)

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Upgrading from a stand-alone installation of Windows SharePoint Services 3.0 to SharePoint Foundation 2010 when content databases exceed 4 GB (RBS)
See Also

This article describes the circumstances in which you might want to upgrade from a stand-alone Windows SharePoint Services 3.0 system to SharePoint Foundation 2010 with Remote BLOB Storage (RBS).

When you upgrade from a stand-alone installation of Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010, the upgrade process differs depending on the size of the content databases.

In a stand-alone installation of Windows SharePoint Services 3.0, content databases are stored in Windows Internal Database and have no size limitations. Conversely, in SharePoint Foundation 2010, the content databases are stored in Microsoft SQL Server 2008 Express and have a maximum size of 4 gigabytes (GB) per database. If you have databases that are larger than 4 GB, you must either use Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, or SQL Server 2005 with SP3 and Cumulative Update 3, or install Remote BLOB Storage (RBS).

Note:

Microsoft SQL Server 2008 R2 Express supports databases up to 10 GB. If the installation includes databases that are larger than 4 GB but smaller than 10 GB, you can upgrade to SQL Server 2008 R2 Express for your content database storage solution instead of implementing RBS. SQL Server 2008 R2 Express is available for download and installation at Microsoft SQL Server 2008 R2 Express Edition (http://go.microsoft.com/fwlink/p/?LinkID=189418).

RBS is designed to move the storage of binary large objects (BLOBs) from database servers to commodity storage solutions. RBS is an add-on that can be applied to SQL Server 2008 Express and to SQL Server 2008. For more information about RBS, see Overview of RBS (SharePoint Foundation 2010).

If you are upgrading fromWindows SharePoint Services 3.0 and all databases are smaller than 4 GB, you can follow the standard in-place upgrade process. For details, see Upgrade in place to SharePoint Foundation 2010.

If you are upgrading from Windows SharePoint Services 3.0 and the search database is larger than 4 GB, you cannot migrate that database. To upgrade, you must remove the existing instance of search before migrating and upgrading. After upgrading, you can create a new instance of search. The search database is limited to 4 GB if the new installation is hosted on SQL Server 2008 Express.

If you are upgrading from Windows SharePoint Services 3.0 and the configuration database is larger than 4 GB, you cannot migrate the configuration database. Instead, you must either create a new SharePoint Foundation system that uses SQL Server 2008 Express (if the configuration database is not expected to grow larger than 4 GB), or create a new installation that uses SQL Server 2008 Standard or SQL Server 2008 Enterprise. You can also migrate the existing system to SQL Server 2008 Standard or SQL Server 2008 Enterprise and then upgrade it.

If you are not upgrading an existing Windows SharePoint Services 3.0 system and you want to install and configure RBS in SharePoint Foundation 2010, see Install and configure RBS (SharePoint Foundation 2010).

Note:

If after you move content into RBS, a content database remains that is larger than 4 GB, the migration operation will fail. This failure typically occurs only with very large databases (20 GB or larger), but it can also occur if there is a smaller database that contains too much metadata.

If the configuration includes SharePoint databases that are larger than 16 GB, RBS is unlikely to provide a full solution to the limitations of SQL Server 2008 Express and SQL Server 2008 R2 Express. In this case, you should be prepared to use SQL Server 2008 Standard or SQL Server 2008 Enterprise to support the SharePoint databases.

Before beginning the upgrade process, confirm that the hardware configuration supports SharePoint Foundation 2010. For more information, see Hardware and software requirements (SharePoint Foundation 2010).

In This Section

  • Upgrade a stand-alone installation by using RBS (in-place) (SharePoint Foundation 2010)

    This article describes how to upgrade from a stand-alone Windows SharePoint Services 3.0 system that has content databases that are larger than 4 GB to SharePoint Foundation 2010.

  • Upgrade a stand-alone installation on a domain controller by using RBS (database attach) (SharePoint Foundation 2010)

    This article describes how to upgrade from a stand-alone Windows SharePoint Services 3.0 system that has content databases that are larger than 4 GB to a SharePoint Foundation 2010 system that is running on a domain controller.

  • Upgrade a stand-alone installation to new hardware by using RBS (database attach) (SharePoint Foundation 2010)

    This article describes how to upgrade from a stand-alone Windows SharePoint Services 3.0 system that has content databases that are larger than 4 GB to SharePoint Foundation 2010 that is installed on new hardware.

See Also

Concepts

Plan for RBS (SharePoint Foundation 2010)

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Upgrade a stand-alone installation by using RBS (in-place) (SharePoint Foundation 2010)
See Also

This article describes how to upgrade from a stand-alone Windows SharePoint Services 3.0 system that has content databases that range in size from 4 gigabytes (GB) to 16 GB to Microsoft SharePoint Foundation 2010 with Remote BLOB Storage (RBS).

Note:

Microsoft SQL Server 2008 R2 Express supports databases up to 10 GB. If the installation includes content databases that are larger than 4 GB but smaller than 10 GB, you can upgrade to SQL Server 2008 R2 Express for your content database storage solution instead of implementing RBS. For more information, see Microsoft SQL Server 2008 R2 Express Edition (http://go.microsoft.com/fwlink/p/?LinkID=189418).

Before performing the operations described in this article, we strongly recommend that you read the following articles to ensure that you are following the best upgrade path:

  • Plan for RBS (SharePoint Foundation 2010)

  • Overview of RBS (SharePoint Foundation 2010)

  • Upgrading from a stand-alone installation of Windows SharePoint Services 3.0 to SharePoint Foundation 2010 when content databases exceed 4 GB (RBS)

To upgrade from a stand-alone installation of Windows SharePoint Services 3.0 to SharePoint Foundation 2010 with RBS

  1. Verify that the user account that is used to perform the upgrade and installation is a member of the Administrators group on the computer running Windows SharePoint Services 3.0 on which the upgrade is being performed and on which RBS is being installed.

  2. Confirm that the hardware configuration supports SharePoint Foundation 2010. For more information, see Hardware and software requirements (SharePoint Foundation 2010).

  3. Verify that the available disk space meets the following requirements:

    • Available disk space is at least twice the size of the largest content database.

    • Available disk space is equal to or greater than the sum of the sizes of all content databases.

  4. Download the SharePoint Foundation 2010 software updates from the upgrade site.

  5. Open the local folder that contains the software download, and then double-click PrerequisiteInstaller. Accept the default values, and then complete the Prerequisite Installer Wizard.

  6. Double-click Setup, accept the default values, and then complete the Setup Wizard.

    When Setup completes, the SharePoint Products Configuration Wizard automatically runs. If the wizard detects a SharePoint database that is larger than 4 GB, a message appears that notifies you that you must migrate the databases to RBS.

    Note:

    If any SharePoint database is larger than 4 GB, all SharePoint databases must be migrated to RBS, even if some databases are smaller than 4 GB.

  7. If you have not previously installed RBS on the server, the SharePoint Products Configuration Wizard fails, and then displays an error message that explains that databases larger than 4 GB were detected and that RBS must be installed. If you must install RBS, continue with the following steps. If you have already installed RBS on the server, the wizard completes successfully without displaying the error message.

  8. Go to http://go.microsoft.com/fwlink/p/?LinkID=177388 to download the RBS_X64.msi file.

    Important:

    You must install the version of RBS that is included in the SQL Server Remote BLOB Store installation package from the SQL Server Remote BLOB Store installation package from the Feature Pack for Microsoft SQL Server 2008 R2. The version of RBS must be 10.50.xxx. No earlier version of RBS is supported for SharePoint Foundation 2010.

  9. Open the folder that contains the file, and then double-click RBS_X64.msi to start the Install SQL Remote BLOB Storage Wizard.

  10. In the Install SQL Remote BLOB Storage Wizard, on the Feature Selection page, expand Server, click the down arrow next to Execute scripts, and then click Entire feature will be unavailable.

  11. Expand FILESTREAM Provider, expand Server, click the down arrow next to Execute scripts, and then click Entire feature will be unavailable.

  12. Complete the wizard by using the default values.

  13. Click Start, click All Programs, click Microsoft SharePoint 2010 Products, and then click SharePoint 2010 Products Configuration Wizard.

  14. The wizard completes the upgrade.

See Also

Concepts

What's new in upgrade (SharePoint Foundation 2010)
Upgrade process overview (SharePoint Foundation 2010)

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Upgrade a stand-alone installation on a domain controller by using RBS (database attach) (SharePoint Foundation 2010)
See Also

This article discusses the upgrade procedures that are required to upgrade from a stand-alone Windows SharePoint Services 3.0 system that is running on a domain controller to Microsoft SharePoint Foundation 2010 with Remote BLOB Storage (RBS). We typically recommend that you use RBS if the content databases are 4 gigabytes (GB) or larger.

Important:

We strongly recommend that you read the article Upgrading from a stand-alone installation of Windows SharePoint Services 3.0 to SharePoint Foundation 2010 when content databases exceed 4 GB (RBS) for important information and recommendations about how to upgrade from Windows SharePoint Services 3.0 to SharePoint Foundation 2010 with RBS.

You can use RBS to move the storage of binary large objects (BLOBs) from database servers to commodity storage solutions. RBS is an add-on that can be applied to SQL Server 2008 Express and to SQL Server 2008.

The implementation of RBS that is discussed in this article uses the SQL Server FILESTREAM provider. For more information about RBS and the FILESTREAM provider, see Overview of RBS (SharePoint Foundation 2010).

In SharePoint Foundation 2010, the content databases are stored in SQL Server 2008 Express and have a maximum size of 4 GB per database. Because Microsoft SQL Server 2008 R2 Express supports content databases that are up to 10 GB, we recommend that you install SQL Server 2008 R2 Express to support the content databases.

This article is not a comprehensive guide to upgrading to SharePoint Foundation 2010. Instead, it refers you to the articles you should read to perform the upgrade. This article contains the additional steps that are required to install and implement RBS on a domain controller installation of SharePoint Foundation 2010.

Before beginning the upgrade process, read the following articles and create an upgrade plan:

  • About the upgrade process (SharePoint Foundation 2010)

  • Plan and prepare for upgrade (SharePoint Foundation 2010)

  • Upgrading from a stand-alone installation of Windows SharePoint Services 3.0 to SharePoint Foundation 2010 when content databases exceed 4 GB (RBS)

Procedures in this article:

  • To prepare for the upgrade to SharePoint Foundation 2010 with RBS on a domain controller

  • To install SQL Server 2008 Express R2

  • To install RBS

  • To install SharePoint Foundation 2010

  • To install SharePoint Foundation 2010

To prepare for the upgrade to SharePoint Foundation 2010 with RBS on a domain controller

  1. Verify that the user account that is used to perform the upgrade and installation meets the requirements listed in Initial deployment administrative and service accounts (SharePoint Foundation 2010).

  2. Verify that the user account is a member of the Administrators group on the local computer.

  3. Confirm that the hardware configuration supports SharePoint Foundation 2010. For more information, see Hardware and software requirements (SharePoint Foundation 2010).

  4. Verify that the available disk space meets the following requirements:

    • Available disk space is at least two times the size of the largest content database.

    • Available disk space is equal to or greater than the sum of the sizes of all content databases.

  5. Perform the pre-upgrade tasks that are discussed in the article Perform pre-upgrade steps (SharePoint Foundation 2010). These are as follows:

    • Run the pre-upgrade checker (SharePoint Foundation 2010)

      The pre-upgrade checker report includes the names of all content databases. You will need this list to enable RBS for the content databases.

      If you have multiple Web applications, you should compile a list of which content databases are attached to which Web applications. You will need this information after the upgrade.

    • Back up the entire environment before an in-place upgrade (SharePoint Foundation 2010)

To install SQL Server 2008 Express R2

  1. Download SQL Server 2008 R2 Express from Microsoft SQL Server 2008 R2 Express Edition (http://go.microsoft.com/fwlink/p/?LinkID=189418).

  2. Follow the on-screen instructions to install SQL Server 2008 R2 Express on the domain controller.

    For more information about how to install SQL Server 2008 R2 Express, see How to: Install SQL Server 2008 (Setup) (http://go.microsoft.com/fwlink/p/?LinkID=186119&clcid=0x409).

    Accept the default settings for most of the installation options. You should specifically accept the following options:

    1. On the Feature Selection page, you can select the components for the installation. Be sure to select SQL Server Management Studio as a feature to install.

    2. On the Instance Configuration page, specify whether to install a default instance or a named instance. If you create a named instance, note the instance name because you will need this name in a later procedure in this article.

    3. On the Server Configuration — Service Accounts page, you must specify login accounts for SQL Server services. You can assign the same login account to all SQL Server services, or you can configure each service account individually. You must use a domain account as the login account for the SQL Server Database Engine.

    4. On the Database Engine Configuration page, make sure that the domain account that is used for this installation is listed as a SQL Server administrator.

To install RBS

  1. Go to http://go.microsoft.com/fwlink/p/?LinkID=177388 (http://go.microsoft.com/fwlink/p/?LinkID=177388) to download the RBS_X64.msi file.

    Important:

    You must install the version of RBS that is included in the SQL Server Remote BLOB Store installation package from the Feature Pack for Microsoft SQL Server 2008 R2. The version of RBS must be 10.50.xxx. No earlier version of RBS is supported for SharePoint Foundation 2010.

  2. Open the folder that contains the file, and then double-click RBS_X64.msi to start the Install SQL Remote BLOB Storage Wizard.

  3. In the Install SQL Remote BLOB Storage Wizard, on the Feature Selection page, expand Server, click the down arrow next to Execute scripts, and then click Entire feature will be unavailable.

  4. Expand FILESTREAM Provider, expand Server, click the down arrow next to Execute scripts, and then click Entire feature will be unavailable.

    Note:

    The database that will host the scripts does not yet exist because it will be created during the database upgrade process. The Execute scripts option will be installed automatically during the installation of SharePoint Foundation 2010.

  5. Complete the wizard by using the default values.

    During the installation, a dialog box appears that describes an RBS Maintainer task. Click OK in that dialog box to continue with the installation.

To install SharePoint Foundation 2010

  1. Uninstall all previous versions of SharePoint Products and Technologies that exist on the domain controller by using Control Panel.

  2. Install SharePoint Foundation 2010 by following the instructions in Install SharePoint Foundation 2010 on the farm servers. During the installation, you must use the database instance name that you created in Step 2 of the procedure To install SQL Server 2008 Express R2. If you used the default named instance in that step, you must enter it in this step as "SQLExpress". If you used the default instance, you must type " " here instead of using the default SQLExpress named instance.

    Note that you are creating a new installation of SharePoint Foundation 2010. You are performing a database attach upgrade, not an in-place upgrade.

    Note:

    After you install SharePoint Foundation 2010, do not create any Web applications until instructed to do this later in this article.

To migrate the content database to RBS and complete the installation

  1. Verify that the user account that is performing this procedure is the same user account that was used to install the farm running SharePoint Foundation 2010 and RBS.

  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 to migrate the content database to RBS:

    Copy Code
    Move-SPBlobStorageLocation -SourceDatabase "<ContentDbName>" -DestinationDataSourceInstance "<InstanceName>"

    Where:

    • <ContentDbName> is the name of the content database.

    • <InstanceName> is the name of the SQL Server database instance name that you created in Step 2 of the procedure To install SQL Server 2008 Express R2. If you used the default named instance in that step, you must enter it here as "SQLExpress". If you used the default instance, you must type " " here instead of using the default "SQLExpress" named instance.

    You must repeat this command for each content database. Refer to the list of content databases that was generated by the Pre-upgrade checker in Step 5 of the To prepare for the upgrade to SharePoint Foundation 2010 with RBS on a domain controller procedure earlier in this article.

  6. Create the Web applications to which the content databases will be attached. For information about how to create a Web application in SharePoint Foundation 2010, see Create a Web application (SharePoint Foundation 2010) or Create a Web application that uses Windows-claims authentication (SharePoint Foundation 2010).

  7. To attach and upgrade the content database to a SharePoint Foundation 2010 Web application, type the following command:

    Copy Code
    Mount-SPContentDatabase "<ContentDbName>" -DatabaseServer "<DbServer>" -WebApplication <http://SiteName>

    Where:

    • <ContentDbName> is the name of the database.

    • <DbServer>is the name of the database server.

    • <http://SiteName> is the URL of the Web application.

    For more information, see Move-SPBlobStorageLocation and Mount-SPContentDatabase.

  8. Create or restore needed customizations onto the new system. For recommended post-upgrade steps, see Perform post-upgrade steps (SharePoint Foundation 2010).

See Also

Concepts

Plan for RBS (SharePoint Foundation 2010)
What's new in upgrade (SharePoint Foundation 2010)

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Upgrade a stand-alone installation to new hardware by using RBS (database attach) (SharePoint Foundation 2010)
See Also

This article discusses the upgrade procedures that are required to upgrade from a stand-alone Windows SharePoint Services 3.0 system to an installation of SharePoint Foundation 2010 with Remote BLOB Storage (RBS) onto a new hardware platform.

Important:

We strongly recommend that you read the article Upgrading from a stand-alone installation of Windows SharePoint Services 3.0 to SharePoint Foundation 2010 when content databases exceed 4 GB (RBS) for important information and recommendations about how to upgrade from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010 together with RBS.

RBS is designed to move the storage of binary large objects (BLOBs) from database servers to commodity storage solutions. RBS is an add-on that can be applied to Microsoft SQL Server 2008 Express and Microsoft SQL Server 2008 R2 Express. This implementation of RBS uses the SQL FILESTREAM provider. For more information about RBS and the FILESTREAM provider, see Overview of RBS (SharePoint Foundation 2010).

Because of the database size limitations in SQL Server 2008 Express, install Windows Internal Database and restore the Windows SharePoint Services 3.0 databases into Windows Internal Database. You then install RBS, move the content database from Windows Internal Database into SQL Server, and then move the BLOBs into a content database that is set to use RBS.

By default, content databases in SharePoint Foundation 2010 are stored in SQL Server 2008 Express, which has a maximum size of 4 gigabytes (GB) per content database. Because SQL Server 2008 R2 Express supports content databases that are up to 10 GB, we recommend you install SQL Server 2008 R2 Express to support content databases. SQL Server 2008 R2 Express is a free upgrade that you can download and install from Microsoft SQL Server 2008 R2 Express Edition (http://go.microsoft.com/fwlink/p/?LinkID=189418).

Note:

This article assumes that you have installed SQL Server Management Studio on the database server in the Windows SharePoint Services 3.0 farm. If you do not have this software installed, you can download and install it from Microsoft® SQL Server® 2008 Management Studio Express (http://go.microsoft.com/fwlink/p/?LinkID=186132&clcid=0x409).

This article is not a comprehensive guide to upgrading to SharePoint Foundation 2010. Before you begin the upgrade process, read the following articles and create an upgrade plan:

  • About the upgrade process (SharePoint Foundation 2010)

  • Plan and prepare for upgrade (SharePoint Foundation 2010)

  • Upgrading from a stand-alone installation of Windows SharePoint Services 3.0 to SharePoint Foundation 2010 when content databases exceed 4 GB (RBS)

In this article:

  • To prepare for the upgrade to SharePoint Foundation 2010 on the original server

  • To prepare for the upgrade to SharePoint Foundation 2010 on the new server

  • To install and configure Windows Internal Database on the new server

  • To move the content databases to the new server

  • To install SQL Server Express 2008 R2 on the new server

  • To install RBS on the new server

  • To install SharePoint Foundation 2010 on the new server

  • To migrate the content database to RBS and complete the installation

To prepare for the upgrade to SharePoint Foundation 2010 on the original server

  1. Verify that the user account that is used to perform this procedure meets the requirements listed in Initial deployment administrative and service accounts (SharePoint Foundation 2010), and that the user account is a member of the Administrators group on the local computer.

  2. Verify that Management Studio is installed on the original server.

  3. Back up the content databases by using the procedure described in How to: Back Up a Database (SQL Server Management Studio) (http://go.microsoft.com/fwlink/p/?LinkID=187768&clcid=0x409). You can use the default settings for most options, but you must use the following settings:

    • In step 1, you must set the instance name for Windows Internal Database as \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query.

    • In Step 12, select the option Destination. Make sure that the destination media has sufficient free space for the backup.

  4. Run the pre-upgrade checker that is discussed in the article Perform pre-upgrade steps (SharePoint Foundation 2010).

    The pre-upgrade checker report includes the names of all content databases. You have to have this list to migrate content databases to RBS. If you have multiple Web applications, you should also note which content databases are attached to which Web applications.

To prepare for the upgrade to SharePoint Foundation 2010 on the new server

  1. Verify that the user account that is used to perform the upgrade and installation meets the requirements listed in Initial deployment administrative and service accounts (SharePoint Foundation 2010), and that the user account is a member of the Administrators group on the local computer.

  2. Confirm that the hardware configuration supports SharePoint Foundation 2010. For more information, see Hardware and software requirements (SharePoint Foundation 2010).

  3. Verify that the available disk space meets the following requirements:

    • Available disk space is at least twice the size of the largest content database.

    • Available disk space is equal to or greater than the sum of the sizes of all content databases.

To install and configure Windows Internal Database on the new server

  1. Click Start, and click Server Manager.

  2. In Server Manager, click Features and then click Add Features.

  3. In the Add Features wizard, scroll down the list of features, and then select Windows Internal Database.

  4. Click Install.

  5. Exit Server Manager.

  6. Click Start, click Administrative Tools, and then click Computer Management.

  7. Expand Services and Applications.

  8. Click Services.

  9. In the Services pane, right-click Windows Internal Database, and then click Properties.

  10. Use the drop-down menu to change the Startup type to Automatic.

  11. Click Start to start the service.

  12. Click OK, and then exit Computer Management.

To move the content databases to the new server

  1. Copy the content database backup files that you created in the procedure To prepare for the upgrade to SharePoint Foundation 2010 on the original server to the new server.

  2. On the new server, download and install Management Studio from Microsoft® SQL Server® 2008 Management Studio Express (http://go.microsoft.com/fwlink/p/?LinkID=186132&clcid=0x409).

  3. Use the instructions at How to: Restore a Database Backup (SQL Server Management Studio) (http://go.microsoft.com/fwlink/p/?LinkID=187769&clcid=0x409) to restore the databases by using Management Studio. Use the following settings for the restore procedure:

    • In Step 1, use the following name for the Windows Internal Database instance: \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query.

    • In Step 5, enter the correct database name to be restored. We recommend that you use the same name that was used when the database was backed up.

    • In Step 7, select the database file that you copied in Step 1.

    • Accept all other default options and complete the restore.

To install SQL Server Express 2008 R2 on the new server

  1. Download SQL Server 2008 R2 Express from Microsoft SQL Server 2008 R2 Express Edition (http://go.microsoft.com/fwlink/p/?LinkID=189418).

  2. Follow the onscreen instructions to install SQL Server 2008 R2 Express.

    For additional information, see How to: Install SQL Server 2008 (Setup) (http://go.microsoft.com/fwlink/p/?LinkID=187771&clcid=0x409).

    Especially note the following settings:

    • On the Instance Configuration page, specify whether to install a Default instance or a Named instance. If you create a named instance, note the instance name. You have to supply this name in a later procedure.

    • On the Server Configuration — Service Accounts page, you must specify login accounts for SQL Server services. You can assign the same login account to all SQL Server services, or you can configure each service account individually.

    • On the Database Engine Configuration page, make sure that the domain account that is being used for this installation is listed as a SQL Server administrator.

To install RBS on the new server

  1. Go to http://go.microsoft.com/fwlink/p/?LinkID=177388 (http://go.microsoft.com/fwlink/p/?LinkID=177388) to download the RBS_X64.msi file.

    Important:

    You must install the version of RBS that is included in the SQL Server Remote BLOB Store installation package from the Feature Pack for Microsoft SQL Server 2008 R2. The version of RBS must be 10.50.xxx. No earlier version of RBS is supported for SharePoint Foundation 2010.

  2. Open the folder that contains the .msi file, and double-click RBS_X64.msi to start the Install SQL Remote BLOB Storage Wizard.

  3. In the Install SQL Remote BLOB Storage Wizard, on the Feature Selection page, expand Server, click the down arrow next to Execute scripts, and then click Entire feature will be unavailable.

  4. Expand FILESTREAM Provider, expand Server, click the down arrow next to Execute scripts, and then click Entire feature will be unavailable.

    Note:

    The database that will host the scripts does not yet exist. It is created during the database upgrade process. The Execute scripts option will be installed automatically during the installation of SharePoint Foundation 2010.

  5. Complete the wizard by using the default values.

    During the installation, a dialog box appears about an RBS Maintainer task. Click OK in that dialog box to proceed with the installation.

To install SharePoint Foundation 2010 on the new server

  1. Install SharePoint Foundation 2010 by following the instructions in Install SharePoint Foundation 2010 on the farm servers. You must use the database instance name that you created in Step 2 of the procedure To install SQL Server Express 2008 R2 on the new server that you performed earlier in this article. If you used the default named instance in that step, you must enter it here as "SQLExpress". If you used the default instance, then you must enter " " here instead of using the default SQLExpress named instance.

    Note that you are creating a new installation ofSharePoint Foundation 2010. You are performing a database attach upgrade, not an in-place upgrade.

    Note:

    After you install SharePoint Foundation 2010, do not create any Web applications until instructed to do this later in this article.

To migrate the content database to RBS and complete the installation

  1. Verify that the same user account that was used to install SharePoint Foundation 2010 and RBS is the user account that is performing this procedure.

  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 to migrate the content database to RBS. You must repeat this command for each content database. Refer to the list of content databases that was generated by the Pre-upgrade checker in Step 4 of the procedure To prepare for the upgrade to SharePoint Foundation 2010 on the original server earlier in this article.

    Copy Code
    Move-SPBlobStorageLocation -SourceDatabase "<DbName>" -DestinationDataSourceInstance "<InstanceName>"

    Where:

    • <DbName> is the name of the content database that you restored into Windows Internal Database.

    • <InstanceName> is the name of the SQL Server database instance that you created in the procedure To install SQL Server Express 2008 R2 on the new server earlier in this article. If you used the default named instance in that step, you must enter it here as "SQLExpress". If you used the default instance, then you must enter " " here instead of using the default SQLExpress named instance.

  6. Create the Web applications that attach to the content database. For information about how to create a Web application in SharePoint Foundation 2010, see Create a Web application (SharePoint Foundation 2010) or Create a Web application that uses Windows-claims authentication (SharePoint Foundation 2010).

  7. Type the following command to attach and upgrade a content database to a Web application:

    Copy Code
    Mount-SPContentDatabase "<DbName>" -WebApplication <http://SiteName>

    Where:

    • <DbName> is the name of the database.

    • <http://SiteName> is the name of the Web application.

    Repeat this command for each content database.

    For more information, see Move-SPBlobStorageLocation and Mount-SPContentDatabase.

  8. Create or restore needed customizations onto the new system. For recommended post-upgrade steps, see Perform post-upgrade steps (SharePoint Foundation 2010).

See Also

Concepts

Plan for RBS (SharePoint Foundation 2010)

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Perform a database attach upgrade to SharePoint Foundation 2010
See Also

Now that you have learned about the upgrade process by reading the articles in About the upgrade process (SharePoint Foundation 2010), and planned for your upgrade by following the steps in the articles in Plan and prepare for upgrade (SharePoint Foundation 2010), you are ready to perform database attach upgrade to Microsoft SharePoint Foundation 2010. You can follow the steps in this section for both a trial upgrade and your actual upgrade on your production farm.

In this section:

  • Checklist for database attach upgrade (SharePoint Foundation 2010)

    Use this checklist to make sure that you follow all necessary steps as you prepare for upgrade, perform the upgrade, and perform post-upgrade steps.

  • Prepare the new SharePoint Foundation 2010 environment for a database attach upgrade

    Before you can attach and upgrade your databases, you must fully configure your new environment.

  • Attach databases and upgrade to SharePoint Foundation 2010

    After your new environment is fully configured, follow these steps to attach the databases and upgrade your SharePoint sites.

  • Database attach upgrade video (SharePoint Foundation 2010)

    This video demonstrates how to use a database attach upgrade method with read-only databases to upgrade from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010.

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Checklist for database attach upgrade (SharePoint Foundation 2010)
See Also

This article contains a checklist you can use to make sure that you followed all necessary steps as you prepare for upgrade, perform the upgrade, and perform post-upgrade steps.

In this article:

  • Prepare for upgrade

  • Perform the upgrade

  • Perform post-upgrade steps

Some of the steps include notes about the amount of time the steps might take. These are rough estimates only, to give you a relative idea of the duration of the step. To find out how much time each step will take for your environment, we recommend that you perform trial upgrades in a test environment. For more information, see Estimate how long the upgrade process will take and the space that you need (SharePoint Foundation 2010) and Use a trial upgrade to find potential issues (SharePoint Foundation 2010).

Prepare for upgrade

Follow these steps in order before you begin a database attach upgrade:

Pre-upgrade steps for a database attach upgrade Notes

Prepare for upgrade

[ ]

Run the pre-upgrade checker

Run the pre-upgrade checker and address any issues. Use the report that is generated by the tool to fill out the Upgrade planning worksheet.

Detailed steps: Run the pre-upgrade checker (SharePoint Foundation 2010).

Perform this step multiple times as you clean up your environment and test your upgrade process.

Running the checker takes only a few minutes, but addressing any issues might take days or weeks.

[ ]

Create an inventory of server-side customizations in the environment

Create an inventory of the server-side customizations in your environment (solutions, features, Web Parts, event handlers, master pages, page layouts, CSS files, and so on). Much of this information is reported when you run the pre-upgrade checker. Record all customizations needed for your environment in the upgrade worksheet.

Detailed steps: Identify and install customizations in the "Use a trial upgrade to find potential issues" article.

Perform this step for the whole environment. Check each Web server to make sure that you don't miss any customizations. Keep the inventory up to date as you prepare for the upgrade.

[ ]

Clean up your environment

Before you begin upgrading, you should make sure that your environment is functioning in a healthy state and that you clean up any content that you do not have to upgrade. Clean up any orphaned sites or data, address any large lists and large ACLs, remove extraneous document versions, and remove any unused templates, features and Web Parts.

Detailed steps: Clean up an environment before upgrade (SharePoint Foundation 2010).

Perform this step once for the whole environment.

This process might take days or weeks to complete.

Prepare the new environment

Also see Prepare the new SharePoint Foundation 2010 environment for a database attach upgrade.

[ ]

Install and configure SharePoint Foundation 2010 and any language packs

Install the prerequisite software, and then install and configure SharePoint Foundation 2010.

Perform these steps on each server in your farm.

This step might take one or more hours, depending on how many servers are in your environment.

[ ]

Configure general farm settings

Reapply any general farm settings that you must have from your previous farm — such as blocked file types and e-mail and quota settings — and add users or groups to the Farm Administrators group. Configure new settings such as usage and health data collection, diagnostic logging, and mobile accounts.

Important:

If you had disabled the Workflow Auto Cleanup timer job in your Windows SharePoint Services 3.0 environment, make sure that you disable this timer job in your new environment also. If this timer job is enabled in the new environment and disabled in the previous version environment, you might lose workflow associations when you upgrade. For more information about this timer job, see Disable preservation of workflow history (SharePoint Foundation 2010).

Perform this step once for the whole environment.

[ ]

Create and configure Web applications

Create a Web application for each Web application that existed in the old environment.

Perform this step once for the whole environment.

[ ]

Reapply server-side customizations

Manually transfer all server-side customizations into your new farm. Refer to the inventory you created in the upgrade worksheet to make sure that you install any components that your sites depend on to work correctly.

Make sure that you reapply customizations to all Web servers in the farm.

[ ]

Verify the new environment

After you set up the new environment, you can perform tests to make sure it contains all the components you have to have before you upgrade your data.

Perform this step once for the whole environment.

Perform the upgrade

Follow these steps in order during a database attach upgrade. Steps required for database attach with read-only databases are also included.

Detailed steps: Attach databases and upgrade to SharePoint Foundation 2010.

Warning:

When you upgrade from an installation of Windows SharePoint Services 3.0 that uses Windows Internal Database and the database size exceeds 4 GB, you must perform additional steps. For more information about these steps, see Upgrading from a stand-alone installation of Windows SharePoint Services 3.0 to SharePoint Foundation 2010 when content databases exceed 4 GB (RBS).

Perform the database attach upgrade |  | Notes
[ ] | Run the pre-upgrade checker Run the pre-upgrade checker again to identify any new or remaining issues before you set the databases to read-only or back up the databases. Detailed steps: Run the pre-upgrade checker (SharePoint Foundation 2010). | Running the checker takes only a few minutes, but addressing any issues might take longer.
[ ] | Set the previous version databases to be read-only (database attach with read-only databases) If you want your original environment to remain available to users in a read-only state, set the databases to read-only before you back them up. | Perform this step for each content database in your environment. Depending on your organization, you might need a database administrator to perform this task.
[ ] | Back up databases Back up all of your content databases before you begin the database attach upgrade process. | Perform this step for each content database in your environment. This step can take an hour, several hours, or longer, depending on your data set and your environment. Depending on your organization, you might need a database administrator to perform this task.
[ ] | Detach the previous version databases (standard database attach) If you are going to upgrade the original databases (rather than a backup copy), detach the original databases from the instance of Microsoft SQL Server so that you can move them to the new environment. | Perform this step for each content database in your environment. Depending on your organization, you might need a database administrator to perform this task.
[ ] | Restore a backup copy of the database (database attach with read-only databases) If you are going to upgrade a copy of the databases, restore the databases from the backup. | Perform this step for each content database in your environment. This step can take an hour or longer, depending on your data set and your environment. Depending on your organization, you might need a database administrator to perform this task.
[ ] | Set the restored databases to be read-write (database attach with read-only databases) Before you can attach and upgrade the databases you copied to the new environment, they must be set to read-write. | Perform this step for each content database in your environment. Depending on your organization, you might need a database administrator to perform this task.
[ ] | Verify custom components Use the Test-SPContentDatabaseWindows PowerShell cmdlet to verify that you have all the custom components that you need for that database. | Perform this step for each content database in your environment. Running the cmdlet takes only a few minutes, but addressing any issues might take longer.
[ ] | Verify permissions Ensure that the account that you use to attach the databases is a member of the db_owner fixed database role for the content databases that you want to upgrade. |
[ ] | Attach a content database to a Web application Attach the first content database that you want to upgrade. You must perform this action from the command line. You can use the Mount-SPContentDatabaseWindows PowerShell cmdlet or the AddContentDB Stsadm operation. | Perform this step for one content database in your environment. This step might take an hour, several hours, or longer, depending on your data set and hardware on the Web servers, database servers, and storage subsystem.
[ ] | Verify upgrade for the first database Verify that upgrade succeeded for the first database, and review the site to see if there are any issues. Detailed steps: Verify upgrade and review upgraded sites (SharePoint Foundation 2010). | Perform this step for the content database you just attached.
[ ] | Attach remaining databases Attach and upgrade the remaining content databases in your environment. You must perform this action from the command line. | Perform this step for each of the remaining content databases in your environment. This step might take an hour, several hours, or longer, depending on your data set, whether you are upgrading multiple databases in parallel, and the hardware on the Web servers, database servers, and storage subsystem.
[ ] | Monitor upgrade progress Use the Upgrade Status page in SharePoint Central Administration to monitor progress as your sites are upgraded. Detailed steps: Verify upgrade and review upgraded sites (SharePoint Foundation 2010). | Perform this step for each content database that you upgrade. This step might take an hour, several hours, or days, depending on your data set.
[ ] | Verify upgrade for the remaining database Verify that upgrade succeeded for the remaining databases, and review the sites to see if there are any issues. Detailed steps: Verify upgrade and review upgraded sites (SharePoint Foundation 2010). | Perform this step for each of the remaining content databases in your environment. This step might take an hour, several hours, or days, depending on your content.

Perform post-upgrade steps

Follow these steps in order after you perform a database attach upgrade.

Post upgrade steps for database attach upgrade |  | Notes
[ ] | Verify upgrade and review upgraded sites Review sites to be sure that they have been upgraded successfully and are ready for users to view. Detailed steps: Verify upgrade and review upgraded sites (SharePoint Foundation 2010). | Perform this step for every upgraded database and site collection in your environment. This step might take an hour, several hours, or days, depending on your content. You should also have site owners review their sites and report any issues.

See Also

Other Resources

Upgrade Worksheet for SharePoint 2010 Products


Prepare the new SharePoint Foundation 2010 environment for a database attach upgrade
See Also

When you upgrade from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010 by using the database attach approach, you upgrade only the content for your environment and not the configuration settings. Using a database attach upgrade is useful when you are changing hardware or want to reconfigure your server farm topology as part of the upgrade process. For more information about how to choose an upgrade approach, see Determine upgrade approach (SharePoint Foundation 2010).

Before you can upgrade the data, you must configure a new server or server farm by using SharePoint Foundation 2010. This article explains the elements you need to configure to create that new environment. For more information about the general process of upgrading by using the database attach upgrade approach, see Upgrade process overview (SharePoint Foundation 2010).

Important:

To perform the steps in this article, you must have administrator rights on the local server computer. For more information, see Initial deployment administrative and service accounts (SharePoint Foundation 2010).

In this article:

  • Before you begin

  • Create and configure the new environment

  • Verify the new environment

  • Perform the upgrade

Before you begin

Before you begin to create the new environment for a database attach upgrade, review the following information about permissions, hardware requirements, and software requirements.

  • Ensure that you have met all hardware and software requirements. You must have a 64-bit version of Windows Server 2008 or Windows Server 2008 R2. For server farms, you must also have a 64-bit version of SQL Server 2005 or SQL Server 2008. For more information about these requirements (such as specific updates that you must install), see Determine hardware and software requirements (SharePoint Foundation 2010).

  • Ensure that you are prepared to set up the required accounts by using appropriate permissions. For detailed information, see Administrative and service accounts required for initial deployment (SharePoint Foundation 2010).

  • Run the pre-upgrade checker on your original environment. The pre-upgrade checker identifies potential upgrade issues in your environment so that you can address them before you upgrade. It can also help you identify settings that you need in your new environment. For more information, see Run the pre-upgrade checker (SharePoint Foundation 2010).

Create and configure the new environment

The process of creating and configuring the new environment contains several steps, which must be performed in the correct sequence. These steps are:

  1. Install SharePoint Foundation 2010 on the server or servers.

  2. Configure service applications.

  3. Configure general farm settings.

  4. Create and configure Web applications.

  5. Reapply customizations.

The remainder of this section describes these steps and provides links to other articles that contain step-by-step instructions for performing them. After you have performed these steps, you can verify the environment and then perform the upgrade.

Install

The first step in creating your new environment is to install SharePoint Foundation 2010 and configure your new server or server farm. You must do the following:

  1. Run the Microsoft SharePoint Products Preparation Tool to install all required software.

  2. Run Setup to install the product.

  3. Install any language packs that you need in your environment.

  4. Run the SharePoint Products Configuration Wizard to configure your server or servers.

The following articles provide step-by-step instructions for performing these tasks.

  • Install and configure the product

    Follow the steps in one of the following articles to install and configure SharePoint Foundation 2010 on a single server or server farm:

    • Deploy a single server with SQL Server (SharePoint Foundation 2010)

    • Multiple servers for a three-tier farm (SharePoint Foundation 2010)

    For more deployment scenarios (such as installing in a stand-alone environment with SQL Express), see Deployment scenarios (SharePoint Foundation 2010).

  • Install and configure language packs

    Follow the steps in Deploy language packs (SharePoint Foundation 2010) to install and configure any language packs that are needed for the sites in your environment.

Configure service applications

You must configure any services you want to use in your new environment, such as the Business Data Connectivity service. The steps included in the deployment scenarios articles listed above describe how to use the Initial Farm Configuration Wizard to enable all services. However, you can also configure services manually. For more information about how to configure services manually, see Configure services (SharePoint Foundation 2010).

Configure general farm settings

The next step in creating the new environment is to apply general farm settings. You must manually reapply configuration settings from your previous version farm, including the following:

  • Incoming and outgoing e-mail settings

  • Any farm-level security and permission settings, such as adding user or group accounts to the Farm Administrators group.

  • Blocked file types

  • Quota templates

And you must configure any new farm-level settings that you want to use, such as the following:

  • Usage and health data collection

  • Diagnostic logging

  • Mobile accounts

For more information about how to configure these settings, see Configure farm settings (SharePoint Foundation 2010).

Important:

If you had disabled the Workflow Auto Cleanup timer job in your Windows SharePoint Services 3.0 environment, make sure that you disable this timer job in your new environment also. If this timer job is enabled in the new environment and disabled in the previous version environment, you might lose workflow associations when you upgrade. For more information about this timer job, see Disable preservation of workflow history (SharePoint Foundation 2010).

Create and configure Web applications

Create a Web application for each Web application that existed in the original environment. For each Web application, do the following:

  • Use the same URL and configure any alternate-access mapping settings.

    Note:

    If you use a different URL, Microsoft Office applications might not be redirected correctly to the new URLs and any bookmarks to the old URLs will not work.

  • Use the same authentication method.

    Important:

    If you were using forms-based authentication, you will need to configure claims-based authentication instead. You must also create a Web application policy to grant Full Control to the user account that will be performing the database attach upgrade.

    For more information, see Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010).

  • Re-create included paths (such as /Sites).

  • Enable self-service site creation for any Web application that used it in the previous environment.

For more information about how to configure Web applications and authentication, see the following articles:

  • For classic authentication: Create a Web application (SharePoint Foundation 2010)

  • For claims-based authentication: Create a Web application that uses Windows-claims authentication (SharePoint Foundation 2010) and Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010)

Reapply customizations

One frequent cause of failures during upgrade is that the environment is missing customized features, solutions, or other elements. Make sure that any custom elements you have to have are installed on your front-end Web servers before you begin the upgrade process. You can use the pre-upgrade checker to compile a list of server-side customizations in your environment. For more information, see Identify and install customizations in the article "Use a trial upgrade to find potential issues."

In this step, you manually transfer all customizations into your new farm. Make sure to install any components that your sites depend on to work correctly, including the following:

  • Custom site definitions

    Note:

    If the site definition was created in Windows SharePoint Services 3.0, you can copy it over to the new environment as-is. If, however, it was created in Windows SharePoint Services version 2.0, you might have to create an upgrade definition file to map the site definition to the new features in Windows SharePoint Services 3.0. For more information, see Develop new custom site definitions and create upgrade definition files (Windows SharePoint Services) and Deploy upgrade definition files and new site definitions (Windows SharePoint Services).

  • Custom style sheets, including cascading style sheets, and images

  • Custom Web Parts

  • Custom Web services

  • Custom features and solutions

  • Custom assemblies

  • Web.config changes (such as security)

    Ensure that you transfer any unique settings from the Web.config files for each Web application to the new servers.

  • Any other components or files on which your sites depend.

For more information about how to update customizations for use in SharePoint Foundation 2010, see: Redeploying Customizations and Solutions in SharePoint Foundation 2010 and SharePoint Server 2010. For more information about how to deploy customizations to your environment, see Deploy customizations - overview (SharePoint Foundation 2010).

Verify the new environment

After you have set up the new environment, you can perform tests to make sure it contains all the components you need before you upgrade your data. To test your new environment, you can use the following methods:

  • Create a new Web application and then use the Windows PowerShellTest-SPContentDatabase cmdlet to verify that all the server-side customizations that are needed for that content database are present in the new environment. Do not attach or upgrade the database. For more information, see Test-SPContentDatabase.

    Note:

    You can also run this command on the original content database, but the database should not be in active use at the time.

  • Use the enumallwebs Stsadm operation in your Windows SharePoint Services 3.0 environment to see which template each site is associated with and then verify whether the template is installed in your SharePoint Foundation 2010 environment. The October Cumulative Update includes improvements to the enumallwebs operation that can help you find customizations in use. For more information about this operation, see Enumallwebs: Stsadm operation (Windows SharePoint Services).

Perform the upgrade

After you finish preparing the new environment, you can attach and upgrade the databases.

Follow the steps in Attach databases and upgrade to SharePoint Foundation 2010 to attach and upgrade the databases from the Windows SharePoint Services 3.0 server or server farm to the new SharePoint Foundation 2010 server or server farm.

Important:

When you upgrade from an installation of Windows SharePoint Services 3.0 that uses Windows Internal Database and the database size exceeds 4 GB, you must perform additional steps. For more information, see Upgrading from a stand-alone installation of Windows SharePoint Services 3.0 to SharePoint Foundation 2010 when content databases exceed 4 GB (RBS).

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Attach databases and upgrade to SharePoint Foundation 2010
See Also

When you upgrade from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010 by using the database attach upgrade approach, you upgrade only the content for your environment and not the configuration settings. Using a database attach upgrade approach is useful when you are changing hardware or want to reconfigure your server farm topology as part of the upgrade process. For more information about how to choose an upgrade approach, see Determine upgrade approach (SharePoint Foundation 2010).

The first step in the process is to set up a new environment to host the upgraded content. If you have not yet set up and configured the new environment, follow the steps in Prepare the new SharePoint Foundation 2010 environment for a database attach upgrade to do so. You must create a Web application in the new environment for every Web application in the old environment, copy any server-side customizations, configure services, and apply any farm settings to the new environment.

After you set up the new environment, you can use the procedures in this article to detach and then reconnect the databases to perform the actual upgrade. This article contains the steps required to perform a standard database attach upgrade and a database attach upgrade with read-only databases.

In this article:

  • Process overview

  • Before you begin

  • Set the previous version databases to be read-only (database attach with read-only databases)

  • Back up the previous version databases by using SQL Server tools

  • Detach the previous version databases (standard database attach)

  • Restore a backup copy of the database (database attach with read-only databases)

  • Set the databases to read-write (database attach with read-only databases)

  • Verify custom components

  • Attach a content database to a Web application

  • Verification: Verify upgrade for the first database

  • Attach the remaining databases

  • Verification: Verify upgrade for additional databases

Note:

One frequent cause of failures during upgrade is that the environment is missing customized features, solutions, or other elements. Be sure that any custom elements you have to have are installed on your front-end Web servers before you begin the upgrade process. Use the pre-upgrade checker — and, for a database attach upgrade, also use the test-spcontentdatabaseWindows PowerShell cmdlet — to identify any custom elements that your sites might be using. For more information, see Identify and install customizations in the article "Use a trial upgrade to find potential issues."

For more information about the general process of upgrading by using the database attach upgrade approach, see Upgrade process overview (SharePoint Foundation 2010).

Process overview

When you upgrade by using database attach upgrade, you detach the databases in the old farm and then attach them to the new farm. When you attach a database to the new farm, the upgrade process runs and upgrades the whole database. The database attach upgrade process is similar to the in-place upgrade process. The difference is that the database attach upgrade process is performed manually, and is performed in a separate environment.

If you want to preserve your original farm and allow users to continue to access their data, you must set the databases to read-only and then attach a backup copy of the databases.

Note:

The part of the process in this article that is specific to moving a database from one computer that is running Microsoft SQL Server to a different computer that is running SQL Server is known as planned relocation. For more information about planned relocation, see Moving User Databases (http://go.microsoft.com/fwlink/p/?LinkId=148425).

For a general overview of the upgrade process, see Upgrade process overview (SharePoint Foundation 2010).

Before you begin

Before you begin the database attach upgrade, review the following information about permissions, hardware requirements, and software requirements. Follow the specified steps to install or configure prerequisite software or to modify settings.

  • Ensure that you have met all hardware and software requirements. You must have a 64-bit version of Windows Server 2008 or Windows Server 2008 R2. For server farms, you must also have a 64-bit version of SQL Server 2005 or SQL Server 2008. For more information about these requirements (such as specific updates that you must install), see Determine hardware and software requirements (SharePoint Foundation 2010).

  • Ensure that you are prepared to set up the required accounts by using appropriate permissions. For detailed information, see Administrative and service accounts required for initial deployment (SharePoint Foundation 2010).

  • Ensure that the account you use to attach the databases is a member of the db_owner fixed database role for the content databases that you want to upgrade.

  • Run the pre-upgrade checker tool on the sites that are stored in the databases. The pre-upgrade checker identifies potential upgrade issues in your environment so that you can address them before you upgrade. For more information, see Run the pre-upgrade checker (SharePoint Foundation 2010).

  • Create a new server farm environment. For information about how to create the new environment, see Prepare the new SharePoint Foundation 2010 environment for a database attach upgrade.

  • Check for and repair any database consistency errors. For more information, see Database maintenance for Windows SharePoint Services 3.0 (white paper).

Set the previous version databases to be read-only (database attach with read-only databases)

If you are using the read-only databases hybrid approach to upgrade, set the previous version databases to read-only before you back up the databases. In any type of database attach upgrade, you can also set the databases to read-only temporarily to ensure that you capture all the data in the backup so that you are restoring and upgrading the current state of the environment. If the databases are set to read-only, users can continue to view content, but they will be unable to add or change content.

Important:

You cannot upgrade a database that is set to read-only. If you are using a database attach with read-only databases, you restore a copy of the database and perform the upgrade on the copy. If you are not using this method, but want to set content databases to read-only temporarily while you back up the current data, make sure that you set the databases to read-write before you attach and upgrade the databases.

Important:

Be sure you have run the pre-upgrade checker before you perform this procedure. For more information, see Run the pre-upgrade checker (SharePoint Foundation 2010).

To set a database to read-only in SQL Server 2000

  1. In SQL Server Enterprise Manager, right-click the name of the database that you want to set to read-only, and then click Properties.

  2. In the Properties dialog box, click the Options tab.

  3. Under Access, select the Read-only check box, and then click OK.

To set a database to read-only in SQL Server 2005

  1. In SQL Server Management Studio, right-click the name of the database that you want to set to read-only, and then click Properties.

  2. In the Select a page section, click Options.

  3. In the right pane, under Other options, in the State section, next to Database Read-Only, click the arrow, and then select True.

To set a database to read-only in SQL Server 2008

  1. In SQL Server Management Studio, in Object Explorer, connect to an instance of the Database Engine, expand the server, and then expand Databases.

  2. Select the database that you want to configure to be read-only, right-click the database, and then click Properties.

  3. In the Database Properties dialog box, in the Select a page section, click Options.

  4. In the right pane, under Other options, in the State section, next to Database Read-Only, click the arrow, and then select True.

You can configure the READ_ONLY database availability option by using Transact-SQL. For more information about how to use the SET clause of the ALTER DATABASE statement, see Setting Database Options (http://go.microsoft.com/fwlink/p/?LinkId=148362).

Back up the previous version databases by using SQL Server tools

Follow the appropriate procedure to back up databases in SQL Server 2000, SQL Server 2005, or SQL Server 2008. Repeat these steps for each content database in your server farm.

You do not have to back up the configuration or admin content databases, because you will re-create these databases in the new server farm. For more information about the kinds of databases that you might have in a Windows SharePoint Services 3.0 server farm, see Database types and descriptions (Windows SharePoint Services 3.0).

At the end of this procedure, you will have created duplicates of the read-only content databases.

To back up a database in SQL Server 2000

  1. On the database server, click Start, point to All Programs, point to Microsoft SQL Server, and then click Enterprise Manager.

  2. In SQL Server Enterprise Manager, expand Microsoft SQL Servers.

  3. Expand SQL Server Group.

  4. Expand (local) (Windows NT).

  5. Expand Databases.

  6. Right-click the database that you want to back up, point to All Tasks, and then click Backup Database.

  7. In the SQL Server Backup dialog box, in the Name box, specify a name for the backup, and then in the Backup area, select Database - complete.

  8. In the Destination area, either select an existing destination or do the following:

    1. Click Add.

    2. In the Select Backup Destination box, select File Name, and then next to the File Name box, click Browse.

    3. In the Backup Device Location - (local) dialog box, in the File name box, type a file name, and then click OK.

    4. Click OK again to close the Select Backup Destination dialog box.

  9. Click OK to start the backup process.

  10. Click OK to acknowledge that the backup process is complete.

Repeat the previous procedure to back up all the other content databases that are used by Windows SharePoint Services 3.0 in your environment.

To back up a database in SQL Server 2005

  1. On the database server, click Start, point to All Programs, point to Microsoft SQL Server 2005, and then click SQL Server Management Studio.

  2. In the Connect to Server box, fill in the connection information, and then click Connect.

  3. After you connect to the appropriate instance of the SQL Server 2005 Database Engine, in Object Explorer, expand the server tree by expanding the server name.

  4. Expand Databases, right-click the database that you want to back up, point to Tasks, and then click Back Up. The Back Up Database dialog box appears.

  5. In the Source area, in the Database box, verify the database name.

  6. In the Backup type box, select Full.

  7. Under Backup component, select Database.

  8. In the Backup set area, in the Name text box, either accept the default backup set name that is suggested or type a different name for the backup set.

  9. In the Destination area, specify the type of backup destination by selecting Disk or Tape, and then specify a destination. To create a different destination, click Add.

  10. Click OK to start the backup process.

Repeat the previous procedure to back up all the other content databases that are used by Windows SharePoint Services 3.0 in your environment.

To back up a database in SQL Server 2008

  1. On the database server, click Start, point to All Programs, point to Microsoft SQL Server 2008, and then click SQL Server Management Studio.

  2. In the Connect to Server box, fill in the connection information, and then click Connect.

  3. After you connect to the appropriate instance of the SQL Server 2008 Database Engine, in Object Explorer, expand the server name.

  4. Expand Databases, right-click the database that you want to back up, point to Tasks, and then click Back Up. The Back Up Database dialog box appears.

  5. In the Source area, in the Database box, verify the database name.

  6. In the Backup type box, select Full.

  7. Under Backup component, select Database.

  8. In the Backup set area, in the Name text box, either accept the default backup set name or type a new name.

  9. In the Destination area, specify the type of backup destination by selecting Disk or Tape, and then specify a destination. To create a different destination, click Add.

  10. Click OK to start the backup process.

Repeat the previous procedure to back up all the other content databases that are used by Windows SharePoint Services 3.0 in your environment.

Detach the previous version databases (standard database attach)

Before you can attach your databases to the new environment and upgrade the data, you need to detach them from the current environment. After you have detached the databases, you can move them to a new database server or leave them on the existing database server and attach them to the Web applications.

Important:

Do not use the following procedure if you are performing a database attach upgrade with read-only databases. To continue to provide your users with access to their content, you need to leave the databases attached, and follow the steps in the Restore a backup copy of the database (database attach with read-only databases) section later in this article to make a copy of the databases instead.

To detach a content database from a Web application

  1. In Central Administration, on the Application Management page, in the SharePoint Web Application Management section, click Content databases.

  2. On the Manage Content Databases page, click the content database you want to detach.

    Note:

    If the content database does not appear, it might be associated with another Web application. To select another Web application, on the Web Application menu, click Change Web Application.

  3. On the Manage Content Database Settings page, in the Remove Content Database section, select the Remove content database check box, and then click OK.

    Note:

    Removing the content database does not delete the database; it only removes the association of the database with the Web application.

  4. Repeat steps 2 and 3 for each content database that you want to detach.

You can also use the deletecontentdb Stsadm operation to detach a content database from a Web application. For more information, see Deletecontentdb: Stsadm operation (Windows SharePoint Services).

If you are moving the databases to a different database server, you must also detach the databases from the instance of SQL Server before you move them and attach them to the new instance of SQL Server after you move them.

Important:

If you move your databases to a different instance of SQL Server, make sure to verify that security is configured correctly. Check that the accounts you use have the appropriate fixed roles and permissions on the databases, and that they will still be valid accounts if you are moving across domains.

To detach a database from an instance of SQL Server and move it to another instance of SQL Server

  1. In SQL Server 2005 Management Studio, open the source instance of SQL Server, and then expand the Databases node.

  2. Right-click the content database, point to Tasks, and then click Detach. Repeat this step for each content database that you want to detach and move.

    Note:

    Use this procedure to move only content databases. Do not detach any other databases.

  3. In Windows Explorer, browse to the location of the .mdf and .ldf files for the content databases.

  4. Select the .mdf and .ldf files for the database you want to move and either copy or move them to the destination directory.

  5. In SQL Server 2005 Management Studio, open the source instance of SQL Server.

  6. Right-click the Databases node, point to Tasks, and then click Attach.

  7. In the Attach Database dialog box, browse to the location to which you transferred the .mdf and .ldf files, select the .mdf file for the database you want to attach, and then click OK.

  8. Repeat steps 6 and 7 for each content database that you are moving.

Restore a backup copy of the database (database attach with read-only databases)

After you configure the new server farm, you can restore the backup copies of the databases on one of the following: Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, and SQL Server 2005 with SP3 and Cumulative Update 3. Note that you must restore to a 64-bit version of SQL Server 2008 R2, SQL Server 2008 with SP1 and Cumulative Update 2, and SQL Server 2005 with SP3 and Cumulative Update 3. Start with one database, and then verify that the restoration has worked before you restore the other databases.

The following section provides procedures for restoring the backups.

To restore a backup copy of a database in SQL Server 2005 Enterprise Edition

  1. In SQL Server Management Studio, right-click Databases, and then click Restore Database. The Restore Database dialog box appears.

  2. In the Restore Database dialog box, on the General page, in the To database box, type the name of the database you are restoring.

  3. In the To a point in time text box, keep the default (Most recent possible).

  4. To specify the source and location of the backup sets to restore, click From device, and then click Browse to select the backup file.

  5. In the Specify Backup dialog box, in the Backup media box, make sure that File is selected.

  6. In the Backup location area, click Add.

  7. In the Locate Backup File dialog box, select the file that you want to restore, and then click OK.

  8. In the Select the backup sets to restore grid, select the Restore check box next to the most recent full backup.

  9. In the Restore Database dialog box, on the Options page, under Restore options, select the Overwrite the existing database check box.

  10. Click OK to start the restore process.

To restore a backup copy of a database in SQL Server 2008 Enterprise

  1. After you connect to the appropriate instance of the SQL Server 2008 Database Engine, in Object Explorer, expand the server name.

  2. Right-click Databases, and then click Restore Database. The Restore Database dialog box appears.

  3. In the Restore Database dialog box, on the General page, type the name of the database to be restored in the To database list.

  4. In the To a point in time text box, retain the default (Most recent possible).

  5. To specify the source and location of the backup sets to restore, click From device, and then click Browse to select the backup file.

  6. In the Specify Backup dialog box, in the Backup media box, be sure that File is selected.

  7. In the Backup location area, click Add.

  8. In the Locate Backup File dialog box, select the file that you want to restore, click OK, and then, in the Specify Backup dialog box, click OK.

  9. In the Restore Database dialog box, under Select the backup sets to restore grid, select the Restore check box next to the most recent full backup.

  10. In the Restore Database dialog box, on the Options page, under Restore options, select the Overwrite the existing database check box.

  11. Click OK to start the restore process.

Set the databases to read-write (database attach with read-only databases)

You must also set the databases back to read-write before you attach and upgrade them.

To set a database to read-write in SQL Server 2008

  1. In SQL Server Management Studio, in Object Explorer, connect to an instance of the Database Engine, expand the server, and then expand Databases.

  2. Select the database that you want to configure to be read-write, right-click the database, and then click Properties.

  3. In the Database Properties dialog box, in the Select a page section, click Options.

  4. In the right pane, under Other options, in the State section, next to Database Read-Only, click the arrow, and then select False.

To set a database to read-write in SQL Server 2000

  1. In SQL Server Enterprise Manager, right-click the name of the database that you want to set to read-write, and then click Properties.

  2. In the Properties dialog box, click the Options tab.

  3. Under Access, clear the Read-only check box, and then click OK.

Verify custom components

Before you attach the content databases to the Web applications, use the Test-SPContentDatabaseWindows PowerShell cmdlet to verify that you have all the custom components that you need for that database.

To verify custom components are available 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Test-SPContentDatabase -Name <DatabaseName> -WebApplication <URL>

    Where:

    • <DatabaseName> is the name of the database you want to test.

    • <URL> is the URL for the Web application that will host the sites.

For more information, see Test-SPContentDatabase.

Attach a content database to a Web application

When you attach a content database, make sure that the root site for the Web application is included in the first content database that you attach. In other words, before you continue, examine the root of the Web application in the original server farm to determine the first site collection. After you attach the database that contains the root site, you can attach the other content databases for the Web application in any order. You do not have to create any site collections to store the content before you attach the database; this process creates the site collections for you. Make sure that you do not add any new site collections until you have restored all the content databases. When you created the Web applications in the new environment, a content database was created for each Web application by default. You can ignore these default databases until after you have attached your previous version databases, and then you can delete the default databases.

Important:

If you are moving the content databases across domains or forests or into another environment that has different service accounts, ensure that the permissions for the service accounts are still correct before you attach the databases.

You can use either the Mount-SPContentDatabase cmdlet in Windows PowerShell or the addcontentdb Stsadm command to attach a content database to a Web application. Using the SharePoint Central Administration pages to attach a content database is not supported for upgrading.

Ensure that the account you use to attach the databases is a member of the db_owner fixed database role for the content databases that you want to upgrade.

Important:

If you were using forms-based authentication, you will need to configure claims-based authentication for your Web application before you attach any databases. You must also create a policy to grant Full Control to the Web application to the user account that will be performing the database attach upgrade.

For more information, see Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010).

Tip:

You cannot attach the same content database more than once to a farm, even on different Web applications. Each site collection in a content database has a GUID that is associated with it, which is registered in the configuration database. Therefore, you cannot add the same site collection twice to the farm, even in separate Web applications. Although you can successfully attach the database in this situation, you will be unable to start the site collection.

If you need a duplicate copy of a site collection in the same farm, first attach the database that contains the site collection to a separate farm, and then use the Stsadm backup and restore operations to copy the site collection over to the other farm. The Stsadm backup and restore process creates a new GUID for the site collection.

To attach a content database to a Web application 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Mount-SPContentDatabase -Name <DatabaseName> -DatabaseServer <ServerName> -WebApplication <URL> [-Updateuserexperience]

    Where:

    • <DatabaseName> is the name of the database you want to upgrade.

    • <ServerName> is server on which the database is stored.

    • <URL> is the URL for the Web application that will host the sites.

    • Updateuserexperience is the choice to update to the new user experience or stay in the old user experience (part of Visual Upgrade). When you include this parameter, the site is set to preview the new user experience. Omit this parameter if you want the site to remain in the old user experience after upgrade. For more information, see Plan visual upgrade (SharePoint Foundation 2010).

For more information, see Mount-SPContentDatabase.

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 attach a content database to a Web application by using the Stsadm command-line tool

  1. On the drive on which SharePoint Products and Technologies is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\14\Bin.

  2. Type the following command, and then press ENTER:

    stsadm -o addcontentdb -url<URL> -databasename<DatabaseName>

    [-databaseserver<ServerName>] [-databaseuser<UserName>]

    [-databasepassword<Password>] [-sitewarning<SiteWarningCount>]

    [-preserveolduserexperience true/false]

    [-sitemax<SiteMaxCount>]

    [-assignnewdatabaseid][-clearchangelog]

    Note:

    When you set the preserveolduserexperience parameter to true, the sites in the content database keep the look of the previous version after upgrade. When you set this parameter to false, the sites are upgraded to the new look and feel. The default for this parameter is true, which preserves the old look and feel.

    This parameter is part of the Visual Upgrade feature. For more information, see Plan visual upgrade (SharePoint Foundation 2010).

    For more information, see Addcontentdb: Stsadm operation (Windows SharePoint Services).

Verification: Verify upgrade for the first database

After you have attached a database, you can use the Upgrade Status page in Central Administration to check the status of upgrade on your site collections. After the upgrade process is complete, you can review the upgrade log file to see whether there were any issues during upgrade. Also, you can review each upgraded site to find and address any issues with how the content is displayed. For more information, see Verify upgrade and review upgraded sites (SharePoint Foundation 2010).

To view the Upgrade Status page

  • In Central Administration, click Upgrade and Migration, and then click Check upgrade status.

To open the upgrade log file

  • The upgrade error log file and the upgrade log file are located at %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\14\LOGS. The logs are named in the following format: Upgrade-YYYYMMDD-HHMMSS-SSS-error.log and Upgrade-YYYYMMDD-HHMMSS-SSS.log, where YYYYMMDD is the date and HHMMSS-SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds). An example for an upgrade error log is Upgrade-20090415-132126-374-error.log, and an example for an upgrade log is Upgrade-20090415-132126-374.log.

    Note:

    The upgrade log file includes the name of the content database being upgraded.

Attach the remaining databases

After you restore the first content database and verify the upgrade by reviewing the upgrade log file, you can continue by restoring and upgrading the next database or databases. You can attach multiple databases at the same time in separate Command Prompt windows to run multiple upgrades at one time. After you successfully restore and upgrade all the content databases, you can review the sites to make sure that they were upgraded correctly.

Verification: Verify upgrade for additional databases

After upgrading any additional databases, view the Upgrade Status page to monitor progress and verify that the upgrade process is complete. Review the log file to identify any other issues, and then review each upgraded site to find and address any issues with how the content is displayed. For more information, see Verify upgrade and review upgraded sites (SharePoint Foundation 2010) and Manage visual upgrade (SharePoint Foundation 2010).

See Also

Concepts

Troubleshoot upgrade issues (SharePoint Foundation 2010)

Other Resources

Resource Center: Updates for SharePoint 2010 Products


Database attach upgrade video (SharePoint Foundation 2010)

Published: July 14, 2011

The following video demonstrates how to use a database attach upgrade method with read-only databases to upgrade from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010.

Video still image

Running time: 7:35

Play video Watch the "Use read-only databases during a database attach upgrade" video

Download video For an optimal viewing experience, download the "Use read-only databases during a database attach upgrade" video.

Right-click the link, and then click Save Target As to download a copy. Clicking the link will open a .wmv file in the default video viewer for full-resolution viewing.

Related resources

Resource | Description
Upgrade and Migration for SharePoint Foundation 2010 Resource Center (http://go.microsoft.com/fwlink/p/?LinkID=178033) | Contains many resources about upgrade and migration for SharePoint Foundation 2010.
Checklist for database attach upgrade (SharePoint Foundation 2010) Attach databases and upgrade to SharePoint Foundation 2010 | These articles contain the full steps to use for procedures in the videos.
Prepare the new SharePoint Server 2010 environment for a database attach upgrade | Contains steps to take to get your new environment ready for attaching and upgrading databases.
SharePoint Products Tech Center (http://go.microsoft.com/fwlink/p/?LinkId=188761) | Find details about related technologies, downloads, and additional resources.


Perform post-upgrade steps (SharePoint Foundation 2010)
See Also

After you have performed an in-place upgrade or a database attach upgrade to Microsoft SharePoint Foundation 2010, you can verify your upgrade and follow the necessary configuration steps to get your environment ready for your users again.

In this section:

  • Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010)

    Upgrade existing Windows SharePoint Services 3.0 Web applications that were configured to use forms-based authentication to work with SharePoint Foundation 2010.

  • Verify upgrade and review upgraded sites (SharePoint Foundation 2010)

    Find out how to tell whether upgrade was completed successfully (both from the software standpoint and from a visual review of your sites) or any issues remain to address. If you must restart upgrade after a failure, you will find the steps to do so in this article.

  • Recovering after a failed upgrade (SharePoint Foundation 2010)

    Follow these steps if the upgrade to Microsoft SharePoint Foundation 2010 has failed and you do not have time to continue to troubleshoot the issues or resume the upgrade process.

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Verify upgrade and review upgraded sites (SharePoint Foundation 2010)
See Also

After you have performed either an in-place upgrade or a database attach upgrade to Microsoft SharePoint Foundation 2010, you must verify that the content was successfully upgraded to the new version. You can verify the status of the upgrade (is it still in progress, or has it been completed successfully or with errors or failures?) and then also review the upgraded sites to see whether any issues remain for you to address. When you follow these steps as part of a trial upgrade, you can use them to identify customizations that have to be reworked before you attempt to upgrade your production environment. When you upgrade your production environment, it is even more critical that you know when the upgrade was completed, which sites have been upgraded successfully, and which sites require additional work before you allow users access to them again.

In some cases, you might have to restart upgrade to finish upgrading your sites. For more information about how to restart upgrade, see Resume upgrade (SharePoint Foundation 2010).

In this article:

  • Verify upgrade status

  • Review upgraded sites

Verify upgrade status

The upgrade process has several phases. For in-place upgrade, you run Setup.exe to install the new software, and then run the SharePoint Products Configuration Wizard to upgrade the configuration database and the admin content database, and then the SharePoint Central Administration Web site opens. At this point, the content upgrade process starts. There are different ways to check the status of the upgrade process during each of these phases: You can review log files for Setup.exe, for the SharePoint Products Configuration Wizard, and for the content upgrade. In SharePoint Central Administration, you can view the version number to make sure that it is correct for the version that you upgraded to. Also, you can use the Upgrade Status page in SharePoint Central Administration or the localupgradestatus operation in Stsadm to find out which sites have been — or are currently being — upgraded. If upgrade was not successfully completed, you can view the log files to find the issues, address them, and then restart the upgrade process.

Review the log files

To verify that upgrade has succeeded, you can review the following log and error files:

  • The Setup.exe log file for SharePoint Foundation 2010.

    The Setup log file is stored in the temp directory for the user account that is running Setup (%USERTEMP% or %WINDIR%\Users\user account\AppData\Local\Temp). It is named SharePoint Foundation Setup(YYYYMMDD-HHMMSS-SSS).log, where YYYYMMDD is the date and HHMMSS-SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds).

  • The SharePoint Products Configuration Wizard (Psconfig.exe) log file.

    The Psconfig.exe log files are located at %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS. The logs are named in the following format: PSCDiagnostics_MM_DD_YYYY_HH_MM_SS_SSS_randomnumber.log, where MM_DD_YY is the date and HH_MM_SS_SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds), and the random number is used to differentiate between possible simultaneous attempts to run the Psconfig.exe program.

  • The upgrade log file and the upgrade error log file.

    The upgrade log file and the upgrade error log file are located at %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS. The logs are named in the following format: Upgrade-YYYYMMDD-HHMMSS-SSS.log, where YYYYMMDD is the date and HHMMSS-SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds). The upgrade error log file combines all errors and warnings into a shorter file and is named Upgrade-YYYYMMDD-HHMMSS-SSS-error.log.

To review the log files to find and troubleshoot issues, start at the top of the files. Errors or warnings may be repeated if they occur for several site collections in the environment, or if they block the upgrade process completely. For example, if you cannot connect to the configuration database, the upgrade process will try (and fail) several times and these attempts will be listed in the log file.

To review the log files

  1. Verify that you have the following administrative credentials:

    • To view the log files, you must be a member of the local Administrators group on the server.

  2. In Windows Explorer, change to the directory that contains the log file that you want to view.

  3. Use a text editor to open the log file.

  4. In the upgrade log file, search, or visually scan, for the following entry:

    Upgrade session finished successfully!

    If you find this entry, the installation was successful.

  5. If you do not find the entries from the previous step in the upgrade log file, or if you are reviewing one of the other log files, you can identify specific issues that may have contributed to a failure by searching, or visually scanning, through the file for the following terms:

    • Search for ERROR in the log files to find any failures (such as failing components and faulty database connections).

    • Search for WARNING to find issues such as missing features or components.

To find issues, you may find it useful to use a log parser to run queries against the log files.

If you find blocking issues in the log file, you can resolve the issues and then restart upgrade to continue with the process.

Verify the version number

In addition to viewing the upgrade log file, you can verify that the upgrade was successful by using the SharePoint Central Administration Web site to view the version number on the Servers in Farm page.

To verify the version number on the Servers in Farm page

  1. Verify that you have the following administrative credentials:

    • To use SharePoint Central Administration, you must be a member of the Farm Administrators group.

  2. On the Central Administration Home page, under System Settings, click Manage servers in this farm.

  3. Under Farm Information, next to Configuration database version, verify that the number starts with "14".

Check upgrade status for sites

To find out which sites have been upgraded or are currently being upgraded, you can use either the Upgrade Status page in SharePoint Central Administration or the localupgradestatus operation in Stsadm.exe.

The Upgrade Status page lists the upgrade sessions and gives details about the state of each session — whether it succeeded or failed, and how many errors or warnings occurred for each server. The Upgrade Status page also includes information about the log and error files for the upgrade process and suggests remedies for issues that might have occurred.

To see which sites were missed or skipped during upgrade, you can use the localupgradestatus operation in Stsadm.exe. You must run the command on every front-end Web server in a server farm.

To view upgrade status in SharePoint Central Administration

  1. Verify that you have the following administrative credentials:

    • To use SharePoint Central Administration, you must be a member of the Farm Administrators group.

  2. On the Central Administration Home page, under Upgrade and Migration, click Check upgrade status.

To view upgrade status from the command line

  1. Verify that you have the following administrative credentials:

    • To use Stsadm, you must be a member of the local Administrators group on the server.

  2. Click Start, right-click Command Prompt, and then click Run as administrator.

  3. In the Command Prompt window, navigate to the following directory:

    %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14\bin

  4. Type the following command and press ENTER:

    Stsadm -o localupgradestatus

For more information about the localupgradestatus operation, see Localupgradestatus: Stsadm operation (Windows SharePoint Services).

Review upgraded sites

Review your upgraded sites to identify any issues that must be addressed before you run the upgrade process on your production environment. If you performed an in-place upgrade and chose to use Visual Upgrade, you can use the Visual Upgrade feature to preview the sites in the new user interface. For more information about previewing sites using Visual Upgrade, see Manage visual upgrade (SharePoint Foundation 2010).

If you want to verify basic functionality, you can create a new site collection by using a representative set of lists, libraries, Web Parts, and so on. Review the new site to make sure that the common, basic elements of your sites are working.

If pages are not rendered, you can check the Site Settings page by going directly to the URL (http:// siteurl/_layouts/settings.aspx). If the Site Settings page works and the upgrade has succeeded, there might be issues with the master page or home page. If the Site Settings page does not work, go to the log file to see whether you can get more information about the problem.

Begin by validating high-impact or high-profile sites, and then move on to lower-priority sites. As part of the planning process, you should have identified which sites are high-impact and high-profile and require immediate attention, and which can wait a bit longer.

Use the following checklists to review your upgraded sites and look for issues.

Web Parts

The following table lists issues with Web Parts that can occur after upgrade and how to address them.

Tip:

To test your Web Parts quickly, you can build a new Web Part page that contains all of your custom Web Parts before you test your upgrade, and then review the page for any missing or broken Web Parts after the trial upgrade.

What to check What to do if there is a problem

Do all the Web Parts from your original site appear in your upgraded site?

If a Web Part zone exists in a customized (unghosted) page, but not in the site definition, the Web Parts from that Web Part zone may have been moved into the bottom zone on the page during the upgrade.

Either in Edit Mode for the page in the browser or in Microsoft SharePoint Designer 2010, look for missing Web Parts in the bottom zone or other zones, or check to see whether the Web Parts have been closed. For more information about how to work with Web Parts and Web Part zones in SharePoint Designer 2010, see the SharePoint Designer Help system.

Are the Web Parts displayed correctly (in the correct zone, location, and size)?

Either in Edit Mode for the page in the browser or in SharePoint Designer 2010, drag the Web Part into the correct zone or modify the Web Part properties to correct any sizing or positioning problems.

Are there any extra or missing Web Parts?

Open the page either in Edit Mode for the page in the browser or in SharePoint Designer 2010. If you see extra Web Parts on your page, look for closed or inactive Web Parts on the original version of the page. Were the closed or inactive Web Parts opened by the upgrade process? If so, you can modify the Web Part properties to close these Web Parts.

If Web Parts are missing, look for errors in SharePoint Designer 2010 such as "Error Rendering Control" or "Missing Assembly." These errors indicate that the Web Part was not installed or was configured incorrectly for the new environment and must be reinstalled or reconfigured.

Do the Web Parts work correctly?

Open the page either in Edit Mode for the page in the browser or in SharePoint Designer 2010, and look for errors that indicate that a component or service is missing. Make sure that any components or services that the Web Parts rely on exist in the upgraded site. Particularly for the database attach upgrade approach, you must make sure that you have installed all the components or services that you must have for your Web Parts, and that you have configured them correctly (for example, you have configured the Web.config Safe Controls list).

Update and redeploy any Web Parts that exist but no longer function correctly.

Tip:

If you have problems with a Web Part, append contents=1 to the end of the URL syntax (http:// siteurl/default.aspx?contents=1), and then press ENTER. This opens the Web Part Maintenance page where you can remove and repair the broken Web Part.

Large lists

By default, large list query throttling is applied after an upgrade to SharePoint Foundation 2010. If a list is very large, and users use a view or perform a query that exceeds the limit or throttling threshold, the view or query will not be permitted. Check any large lists in your environment and have the site owner or list owner address the issue. For example, they can create indexed columns with filtered views, organize items into folders, set an item limit on the page for a large view, or use an external list.

Styles and appearance

The following table lists common issues with the style and appearance of your Web site after upgrade and how to address them.

Tip:

Most of the issues in this section can be solved by correcting the links to an item.

What to check | What to do if there is a problem
Are all the images on your pages displayed correctly? | Verify or fix the links to the images.
Are the appropriate cascading style sheet colors and styles used in the appropriate locations? | Verify or fix the links to the cascading style sheet file. Verify the link on the master page.
Does the theme that you applied to your site still look the same? | Your site's home page, or other pages on your site, may look different after the site is upgraded. You may have to re-create or revise a theme and reapply it.
Do you have any scripted controls that are not working? | Verify or fix the links to the controls.
Are your pages displayed correctly in Windows Internet Explorer 8? | Verify that any HTML on the page is in strict XHTML mode.
Are any script errors displayed on any pages? | Verify the scripts and links, and verify that any HTML is in strict XHTML mode.

Permissions

Do the appropriate people and groups still have the correct level of permissions to sites, pages, lists, and items?

You can use the Check Permissions button in the Permission Tools section of the ribbon to see who has permissions to which items in a site or subsite.

Customized (unghosted) pages

Customized (unghosted) pages are pages that have been edited and are now unique versions of the pages, instead of the default template pages. The following table lists issues with customized pages that can occur after upgrade and how to address them.

What to check What to do if there is a problem

Are your customizations still in the correct locations?

Determine whether you have only one issue or a larger problem with the whole page.

If you added a brand new page to your original site (for example, if you replaced Default.aspx with a different file instad of changing the existing Default.aspx file), the new page has no association with the site definition. Therefore, it might not resemble the other pages on the upgraded site — nor can it be reset to resemble them. If you want your customized page to have the same look and feel as the other pages on your site, consider creating a brand-new page that is based on the site definition and then transferring your customizations to that new page.

Can you still access the editing controls on the pages?

If you customized the editing controls (for example, the Site Actions link or the Edit Page link), check whether they still appear. If they don't appear, you can replace them with the editing controls of the new version by resetting the page to the default version.

Use the Reset to Template command in SharePoint Designer to reset the page to the default version (also known as reghosting). After you have restored the default page, you can then reapply your customizations in the browser by applying a different master page, or by reapplying the customizations in SharePoint Designer.

Are your customizations still appropriate in the new environment, or do you want to update to the new functionality and look?

If you want the new functionality and features, you must reset any customized pages to use the template. Resetting the page basically discards the customizations and attaches your page to the appropriate master page. Any customizations you want can then be transferred to the master page instead of being stored in individual pages.

Use the Reset to Template command in SharePoint Designer to reset the page to the default version (that is, reghost it). After you have restored the default page, you can then reapply your customizations in the browser by applying a different master page, or by reapplying the customizations in SharePoint Designer.

Are any pages still checked out?

If you check out a page to make changes, make sure that you check in the page again.

See Also

Concepts

Resume upgrade (SharePoint Foundation 2010)
Troubleshoot upgrade issues (SharePoint Foundation 2010)

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Manage visual upgrade (SharePoint Foundation 2010)
See Also

This article provides procedures related to the Visual Upgrade feature. When you upgrade from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010, you can choose to use the Visual Upgrade feature to give site collection owners and site owners the opportunity to preserve the previous user interface temporarily. This allows them to update customizations to work in the new user interface. For a full description of Visual Upgrade and related choices, see Plan visual upgrade (SharePoint Foundation 2010).

In this article:

  • About using Visual Upgrade

  • View status of current user interface

  • Revert sites to previous user interface

  • Force an upgrade to the new user interface

  • Site owner options for visual upgrade

About using Visual Upgrade

When you upgrade, either by using in-place upgrade or by using the database attach upgrade method, you can choose to use Visual Upgrade.

During an in-place upgrade, you make the choice to use Visual Upgrade as a step in the SharePoint Products Configuration Wizard. The visual upgrade feature is not available in the SharePoint Products Configuration Wizard if you are performing an upgrade on a stand-alone server with built-in database. However, the Visual Upgrade feature is available in this case from the Psconfig command-line tool. You can then use the syntax: psconfig.exe -cmd upgrade [-preserveolduserexperience <true|false>].

During a database attach upgrade, the choice to update to the new user experience or stay in the old user experience is accomplished by using either:

  • The Updateuserexperience parameter of the Mount-SPContentDatabase Windows PowerShell cmdlet.

  • The preserveolduserexperience parameter of the addcontentdatabase Stsadm operation.

For additional information about using these parameters during an upgrade, see Attach databases and upgrade to SharePoint Foundation 2010.

View status of current user interface

You can view the current user interface status by generating a list of all Web sites in a site collection and their corresponding visual upgrade data. This is useful if you have set a time limit by which site owners must have prepared their sites for the new user interface and you want to monitor their progress. The following procedure shows you how to view the current user interface status.

To view status of current user interface 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    $sc = Get-SPSite http://machinename/sites/collectionname; $sc.GetVisualReport() | Format-Table

For more information, see Get-SPSite.

Revert sites to previous user interface

If a site collection owner or site owner finalizes the new user interface by mistake, or if they have a problem that they cannot solve, you can revert back to the previous user interface by using Windows PowerShell. This procedure shows you how to revert one or all sites in a site collection to the previous user interface.

To revert sites to the previous user interface 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. To revert a specific site in a site collection to the previous UI, at the Windows PowerShell command prompt, type the following command:

    Copy Code
    Get-SPSite http://machinename/sites/V3UI | Get-SPWeb "webname" | Foreach{$_.UIVersionConfigurationEnabled=1;$_.UIVersion=3;$_.Update();}

    To reverts all sites in a site collection to the previous user interface, at the Windows PowerShell command prompt, type the following command:

    Copy Code
    Get-SPSite http://machinename/sites/V3UI | Foreach{$_.UIVersionConfigurationEnabled=1;$_.UIVersion=3;$_.Update();}

For more information, see Get-SPSite.

Force an upgrade to the new user interface

If you want to forcibly apply the new user interface after an upgrade has taken place, you might first want to give site collection owners and site owners a specified time during which they can preview the new user interface and fix any issues they might have. When you force an upgrade to the new user interface, you can use a script or use the SharePoint Products Configuration Wizard during the initial upgrade. For information about upgrade and the SharePoint Products Configuration Wizard, see Run the SharePoint Products Configuration Wizard. The following procedure shows you how to programmatically upgrade all site collections and all sites to the new user interface.

To force through an upgrade to the new user interface 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    $webapp = Get-SPWebApplication http://sitename
    Copy Code
    foreach ($s in $webapp.sites)
    Copy Code
    {$s.VisualUpgradeWebs() }

For more information, see Get-SPWebApplication

To upgrade a single site collection to the new user interface, type the following commands at the Windows PowerShell command prompt:

Copy Code
$site = Get-SPSite http://server
Copy Code
$site.VisualUpgradeWebs()

To upgrade a single site to the new user interface, type the following commands at the Windows PowerShell command prompt:

Copy Code
$web = Get-SPWeb http://server/site
Copy Code
$web.UIVersion = 4
Copy Code
$web.UIVersionConfigurationEnabled = 0
Copy Code
$web.Update()

Site owner options for visual upgrade

The site owner can use the Site Setting user interface to toggle between the Use the previous user interface and Preview the updated user interface options. Once the site owner is satisfied with how the site looks, the new UI can be finalized by selecting the Update the user interface option.

The following table describes the different upgrade options that are available for the site owner to choose for their sites. The upgrade modes are available from the Site Settings page in the Title, Description, and Icon section.

Mode type | Description
Use the previous user interface | Site owners use this mode to have all their sites use the interface from Windows SharePoint Services 3.0.
Preview the updated user interface | Site owners use this mode to evaluate how their sites will look and function in the new interface. When this mode is chosen, features from the previous version interface will not be available.
Update the user interface | Site owners use this option when they are satisfied with the changes and are ready to switch to the new user interface. If needed, an administrator can restore the user interface to the previous version interface.

See Also

Concepts

Plan visual upgrade (SharePoint Foundation 2010)

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Using AAM URL redirection as part of the upgrade process (SharePoint Foundation 2010) (white paper)
See Also

This white paper describes the planning activities that you need to successfully deploy and use the alternate access mapping (AAM) URL redirection feature in Microsoft SharePoint Foundation 2010 to help mitigate downtime during a server computer or server farm upgrade. It also describes the procedures necessary to successfully complete the configuration of this feature by modifying existing Windows SharePoint Services 3.0 server computers.

Important:

The process described in this white paper is an advanced technique for avoiding downtime during upgrade. It should only be used if other techniques, such as read-only databases and upgrade in-place with detached databases, would cause an unacceptably long period of downtime for your users. Do not consider using this technique unless you know your upgrade process will take more than a long weekend. If your upgrade is not likely to take that long, you won't save any time by performing the procedures in this paper. For more information about other approaches to upgrade, see Determine upgrade approach (SharePoint Foundation 2010).

Download this white paper as a Microsoft Word document (.doc). (http://go.microsoft.com/fwlink/p/?LinkId=168857)

Download this white paper as a PDF file. (http://go.microsoft.com/fwlink/p/?LinkId=168858)

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Migrate from forms-based authentication to claims-based authentication (SharePoint Foundation 2010)
See Also

Published: September 23, 2010

The procedures in this article provide guidance to help you migrate existing Windows SharePoint Services 3.0 Web applications, which were configured to use forms-based authentication, to work in a Microsoft SharePoint Foundation 2010 environment as claims-based Web applications.

After upgrading to SharePoint Foundation 2010, upgraded Web applications retain the logon method that the Windows SharePoint Services 3.0 applications used. Windows SharePoint Services 3.0 Web applications that were configured to use Windows authentication require no additional steps for upgrade. However, you must convert Windows SharePoint Services 3.0 Web applications that were configured to use forms-based authentication to use claims-based authentication before the Windows SharePoint Services 3.0 Web applications can be used in SharePoint Foundation 2010. After you convert the Windows SharePoint Services 3.0 Web applications to claims-based authentication, configure the Web application zones for forms-based authentication. The final step is to migrate users and permissions to SharePoint Foundation 2010. This article provides the following procedures to complete Web application migration:

  • Convert Windows SharePoint Services 3.0 Web applications that use forms-based authentication to use claims-based authentication

  • Migrate users and permissions from Windows SharePoint Services 3.0 to SharePoint Foundation 2010

Convert Windows SharePoint Services 3.0 Web applications that use forms-based authentication to use claims-based authentication

Perform the steps in the following procedure to use Windows PowerShell to convert existing Web applications to claims-based authentication.

To convert Web applications to claims-based authentication

  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, type the following:

    Copy Code
    $w = Get-SPWebApplication "http://<server>/"
$w.UseClaimsAuthentication = 1
$w.Update()

$w.ProvisionGlobally()
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.

Migrate users and permissions from Windows SharePoint Services 3.0 to SharePoint Foundation 2010

Perform the steps in the following procedure to use Windows PowerShell to migrate users and permissions.

To migrate users and permissions from Windows SharePoint Services 3.0 to SharePoint Foundation 2010

  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, type the following:

    Copy Code
    $w = Get-SPWebApplication "http://<server>/"
$w.MigrateUsers($True)
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.

See Also

Concepts

Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010)

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Migrate from classic-mode to claims-based authentication (SharePoint Foundation 2010)
See Also

Published: October 14, 2010

The procedures in this article provide guidance to help you migrate existing Microsoft SharePoint Foundation 2010 Web applications, which were configured to use classic-mode authentication, to use claims-based authentication. You might decide to do this if you want to implement an authentication method other than Windows authentication (for example, if you want to create a Web application that supports forms-based authentication). For more information, see Plan authentication methods (SharePoint Foundation 2010).

Warning:

After you migrate a Web application to claims-based authentication, you cannot revert it to classic-mode authentication.

Convert SharePoint Foundation 2010 Web applications that use classic-mode authentication to use claims-based authentication

Perform the steps in the following procedure to use Windows PowerShell to convert existing Web applications to claims-based authentication.

To convert Web applications to claims-based authentication

  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, type the following:

    Copy Code
    $WebAppName = "http:// yourWebAppUrl"
$account = "yourDomain\yourUser"
$wa = get-SPWebApplication $WebAppName

Set-SPwebApplication $wa -AuthenticationProvider (New-SPAuthenticationProvider) -Zone Default

  6. At the Migration prompt, click Yes to continue.

  7. From the Windows PowerShell command prompt, type the following to set the user as an administrator for the site:

    Copy Code
    $account = "yourDomain\yourUser"
$account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()
$zp = $wa.ZonePolicies("Default")
$p = $zp.Add($account,"PSPolicy")
$fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
$p.PolicyRoleBindings.Add($fc)
$wa.Update()

  8. From the Windows PowerShell command prompt, type the following to configure the policy to enable the user to have full access:

    Copy Code
    $zp = $wa.ZonePolicies("Default")
$p = $zp.Add($account,"PSPolicy")
$fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
$p.PolicyRoleBindings.Add($fc)
$wa.Update()

  9. From the Windows PowerShell command prompt, type the following to perform user migration:

    Copy Code
    $wa = get-SPWebApplication $WebAppName
$wa.MigrateUsers($true)
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.

Additional migration guidelines

After you perform the steps in the previous procedures, you might experience one or more of the following issues.

  • Users who submit valid credentials might be notified that they do not have permissions. If this occurs, the portalsuperuseraccount property and the portalsuperreaderaccount property of the Web application were probably configured prior to migration. If this is the case, you must update the portalsuperuseraccount property and the portalsuperreaderaccount property to use the new claims-based account name. After migration, you can find the new claims-based account name in the Web application policy for the migrated Web application.

  • If existing alerts are not invoked after migration, you might have to delete and recreate the alerts.

  • If Search crawl does not function after migration, make sure the Search crawl account lists the new converted account name. If the new converted account name is not listed, you must manually create a new policy for the crawl account.

See Also

Other Resources

Downloadable book: Upgrading to SharePoint Foundation 2010
Resource Center: Upgrade and Migration for SharePoint Foundation 2010


Deploy Office Web Apps (Installed on SharePoint 2010 Products)

Published: May 16, 2012

Learn about Microsoft Office Web Apps and how to deploy them on Microsoft SharePoint 2010 Products on-premises in your organization.

Office Web Apps are the online companions to Microsoft Word, Microsoft Excel, Microsoft PowerPoint, and Microsoft OneNote applications. Office Web Apps enable users to access documents from anywhere by using a Web browser. Users can view, share, and work on documents with other users online across personal computers and mobile devices.

Office Web Apps requires a supported device, an Internet connection, and a supported browser. Some mobile functionality requires Office Mobile 2010, which is not included in Office 2010 applications, suites, or Office Web Apps. There are some differences among the features of Office Web Apps, Office Mobile 2010, and the Office 2010 applications. For more information about Office Web Apps requirements, see Planning Office Web Apps (Installed on SharePoint 2010 Products).

Important:

Do not install Office Web Apps on a computer that is configured as a domain controller. Instead, run Office Web Apps and the domain controller on separate computers. If you only have one computer, consider running Office Web Apps and the domain controller configuration as separate virtual machine instances on the single host computer, by using Hyper-V or other virtualization software.

Unless otherwise noted, SharePoint 2010 Products in this article refers to Microsoft SharePoint Server 2010 and Microsoft SharePoint Foundation 2010, which must be installed before you install Office Web Apps. This article does not provide guidance or instructions about how to deploy SharePoint 2010 Products. For more information about how to deploy SharePoint 2010 Products, see Deployment scenarios (SharePoint Server 2010) or Deployment scenarios (SharePoint Foundation 2010).

Before you deploy Office Web Apps in your organization, ensure that you understand the concepts and terminology in Understanding Office Web Apps (Installed on SharePoint 2010 Products) and Planning Office Web Apps (Installed on SharePoint 2010 Products).

Caution:

When you install Office Web Apps on server farm, it becomes tightly integrated into SharePoint 2010 Products.

Before you install Office Web Apps on a server farm in a production environment, we strongly recommend that you install Office Web Apps in a test environment and thoroughly evaluate it to ensure that it fully meets your organization's needs. This evaluation should include verifying that you have appropriate licenses to install and run Office Web Apps in a production environment. For more information about Office Web Apps licensing, see How to buy Office 2010 through Volume Licensing (http://go.microsoft.com/fwlink/p/?LinkId=220251).

Uninstalling Office Web Apps will result in some downtime for the farm. For more information, see Deactivate or Uninstall Office Web Apps (Installed on SharePoint 2010 Products).

To download Office Web Apps, go to the Office Professional Plus 2010 32-bit or Office Standard 2010 32-bit page on the Microsoft Volume Licensing Service Center (http://go.microsoft.com/fwlink/p/?LinkID=191841).

In this article:

  • Understanding Office Web Apps deployment

  • Deployment scenarios

Understanding Office Web Apps deployment

For stand-alone SharePoint 2010 Products servers and server farms, deploying Office Web Apps involves three phases:

Installing Office Web Apps Includes running Setup.exe for the Office Web Apps on a stand-alone SharePoint 2010 Products server or on each server in a SharePoint server farm. Running Setup.exe installs Office Web Apps files and components on a server.

Activating the Office Web Apps services Includes starting the services, and creating the service applications and service application proxies. How you activate the services depends on the state of your SharePoint 2010 Products installation before you install Office Web Apps. If the SharePoint Products Configuration Wizard and the SharePoint Farm Configuration Wizard have been previously run, which is usually the case when you are installing on an existing stand-alone server or server farm, you must activate the services manually or by using Windows PowerShell. If the configuration wizards have not been run before you install Office Web Apps, which is the case when you are installing on a new stand-alone server or server farm, you can run the configuration wizards after the installation to automatically activate the services.

Note:

When this article refers to the SharePoint Products Configuration Wizard, alternately you can use the Psconfig command-line tool to complete the task. For more information, see Psconfig command-line reference (SharePoint Server 2010).

Activating the Office Web Apps feature Includes activating the Office Web Apps feature on each existing SharePoint site collection where you want Office Web Apps to be available. If the SharePoint Farm Configuration Wizard was run before you installed Office Web Apps, the wizard will have created at least one site collection for which Office Web Apps are activated. After you have installed Office Web Apps, the Office Web Apps feature is activated automatically for new site collections that you create.

Some procedures in this article require you to run SharePoint 2010 cmdlets or scripts by using either Windows PowerShell or SharePoint 2010 Management Shell. To run SharePoint 2010 cmdlets in Windows PowerShell, you must add the Microsoft.SharePoint.PowerShell snap-in by using the Add-PSSnapin cmdlet. For more information about the Add-PSSnapin cmdlet, see Add-PSSnapin (http://go.microsoft.com/fwlink/p/?LinkId=188450). By default, the Microsoft.SharePoint.PowerShell snap-in is already registered and added to the SharePoint 2010 Management Shell. To run SharePoint 2010 cmdlets, you must be a member of the SharePoint_Shell_Access role on the configuration database and a member of the WSS_ADMIN_WPG local group on the computer where SharePoint 2010 Products is installed. See Add-SPShellAdmin. To run scripts in Windows PowerShell or SharePoint 2010 Management Shell, you must set the execution policy by using the set-executionpolicy cmdlet with the unrestricted parameter. For more information about how to use Windows PowerShell with SharePoint 2010 Products, see SharePoint 2010 Products administration by using Windows PowerShell.

Deployment scenarios

Based on your SharePoint 2010 Products installation type, choose the appropriate option to install and configure Office Web Apps:

  • Install and configure Office Web Apps on an existing stand-alone SharePoint 2010 Products server

  • Install and configure Office Web Apps on a new stand-alone SharePoint 2010 Products server

  • Install and configure Office Web Apps on an existing SharePoint server farm

  • Install and configure Office Web Apps on a new SharePoint server farm

Install and configure Office Web Apps on an existing stand-alone SharePoint 2010 Products server

Complete the procedures in this section only if you are installing Office Web Apps on an existing stand-alone SharePoint 2010 Products server on which the SharePoint Products Configuration Wizard has been previously run.

Note:

To complete the following procedures, you must be a member of the Administrators group on the local computer.

Run Office Web Apps Setup

Complete this procedure to install Office Web Apps components and files on a server.

To run Office Web Apps Setup

  1. From the root folder of the Office Web Apps files, run Setup.exe.

  2. On the Enter your Product Key page, enter your product key, and then click Continue.

  3. On the Choose a file location page, do one of the following:

    • To install to the default location, click Install Now.

    • To install to a different location, specify the location that you want to install to, and then click Install Now.

  4. On the Run Configuration Wizard page, ensure that the Run the SharePoint Products Configuration Wizard now check box is selected, and then click Close to start the SharePoint Products Configuration Wizard.

Run the SharePoint Products Configuration Wizard to register the services

Complete this procedure to register the Office Web Apps services on the SharePoint 2010 Products server.

To run the SharePoint Products Configuration Wizard to register the services

  1. If you left the Run the SharePoint Products Configuration Wizard now check box selected in the previous procedure, the SharePoint Products Configuration Wizard will start. If the wizard does not start, click Start, click All Programs, click Microsoft SharePoint 2010 Products, and then click SharePoint Products Configuration Wizard.

  2. On the Welcome to SharePoint Products page, click Next.

  3. In the dialog box that notifies you that some services might have to be started or reset during configuration, click Yes to begin the configuration.

  4. On the Configuration Successful page, click Finish.

Start the services

You must start the services before you create the service applications and the service application proxies. You can start the services by using Central Administration or by using Windows PowerShell.

Complete the procedures in this section to start the services on the server.

To start the services by using Central Administration

  1. On the Central Administration Web site, in System Settings, click Manage services on server.

  2. On the Services on Server page, for Excel Calculation Services, PowerPoint Service, and Word Viewing Service, click Start.

    Note:

    On a server that is running SharePoint Server 2010 Enterprise, the Excel Calculation Services service is installed and started by default. The OneNote Web App does not require a SharePoint service.

To start the services by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. Also verify that the account that you use to perform this procedure is a member of the Administrators group on the computer that is running Windows PowerShell.

  2. Copy the following code and paste it into a text editor, such as Notepad:

    Copy Code
    $machinesToActivate = @("<ServerName>")
$serviceInstanceNames = @("Word Viewing Service", "PowerPoint Service", "Excel Calculation Services")
foreach ($machine in $machinesToActivate)
{
  foreach ($serviceInstance in $serviceInstanceNames)
  {
     $serviceID = $(Get-SPServiceInstance | where {$_.TypeName -match $serviceInstance}).ID
     Start-SPServiceInstance -Identity $serviceID
  }
}

  3. Replace the following placeholders with values where:

    <ServerName> is the name of the SharePoint 2010 Products server on which you want to start the services.

  4. Save the file, naming it Start-WebAppSvcs.ps1.

    Note:

    You can use a different file name. However, you must save the file as an ANSI-encoded text file that has the extension .ps1.

  5. Click Start, click All Programs, and then click Microsoft SharePoint 2010 Products.

  6. Right-click SharePoint 2010 Management Shell, and then click Run as administrator.

  7. Change to the directory where you saved the file.

  8. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    ./Start-WebAppSvcs.ps1

Create the service applications and the service application proxies

Note:

You must start the services before you complete the procedures in this section.

After you have started the services, you must create the service applications and the service application proxies that connect the SharePoint Web front-end servers to the service applications. You can create the service applications and the service application proxies for the Word Web App, PowerPoint Web App, and Excel Web applications by using Central Administration or by using Windows PowerShell. After you create the service applications, they will automatically run on the services that you have started.

Note:

On a server that is running SharePoint Server 2010 Enterprise, the Excel Calculation Services service application is created by default. The OneNote Web App does not require a service application.

Complete the procedures in this section to create the Office Web Apps service applications and service application proxies for the Excel Web App, PowerPoint Web App and Word Web App.

To create the service applications and the service application proxies by using Central Administration

  1. On the Central Administration Web site, in Application Management, click Manage service applications.

  2. On the Manage Service Applications page, click New, and then click PowerPoint Service Application.

  3. In the PowerPoint Service Application dialog box, do the following:

    1. In the Name box, type PowerPoint Service Application or other descriptive name.

    2. In the Application Pool area, click Use existing application pool, and then in the list, select SharePoint Web Services Default.

    3. In the Add to default proxy list area, verify that the Add this service application's proxy to the farm's default proxy list check box is selected (default), and then click OK.

    Note:

    When you create a new application pool, you can specify a security account that is used by the application pool to be either a predefined Network Service account or a managed account. The account must have db_datareader, db_datawriter, and execute permissions for the SharePoint configuration database, and be assigned to the db_owner role for the content databases. For more information about services account permissions in SharePoint 2010 Products, see Account permissions and security settings (SharePoint Server 2010).

  4. On the Service Applications page, click New, and then click Word Viewing Service.

  5. In the Word Viewing Service Application dialog box do the following:

    1. In the Name box, type Word Viewing Service Application or other descriptive name.

    2. In the Application Pool area, click Use existing application pool, and then in the list, select SharePoint Web Services Default.

    3. In the Add to default proxy list area, verify that the Add this service application's proxy to the farm's default proxy list check box is selected (default), and then click OK.

  6. On a server that is running SharePoint Server 2010 Enterprise, the Excel Calculation Services service application is created by default. If an Excel Calculation Services service application does not already exist, on the Manage Service Applications page, click New, and then click Excel Services Application.

  7. In the Create New Excel Services Application dialog box, do the following:

    1. In the Name box, type either Excel Services Application or another descriptive name.

    2. In the Application Pool area, do one of the following:

      • Click Use existing application pool, and then, in the list, click SharePoint Web Services Default.

      • Click Create new application pool, and then, in the Application pool name box, type the name that you want to use for the application pool, and then select a managed account from the Configurable list.

    3. In the Add to default proxy list area, either leave the Add this service application's proxy to the farm's default proxy list check box selected or clear it, and then click OK.

    Note:

    You might have to refresh the Manage Service Applications page in your browser to see the new service applications and service application proxies.

To create the service applications and the service application proxies by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. Also verify that the account that you use to perform this procedure is a member of the Administrators group on the computer that is running Windows PowerShell.

  2. On a computer that is running SharePoint Server 2010 Enterprise, the Excel Calculation Services service application is created by default. Copy the following code and paste it into a text editor, such as Notepad:

    Copy Code
    $appPool = Get-SPServiceApplicationPool -Identity "SharePoint Web Services Default"
New-SPWordViewingServiceApplication -Name "WdView" -ApplicationPool $appPool | New-SPWordViewingServiceApplicationProxy -Name "WdProxy"
New-SPPowerPointServiceApplication -Name "PPT" -ApplicationPool $appPool | New-SPPowerPointServiceApplicationProxy -Name "PPTProxy" -AddToDefaultGroup

    If an Excel Calculation Services service application does not already exist, copy the following code and paste it into a text editor, such as Notepad:

    Copy Code
    $appPool = Get-SPServiceApplicationPool -Identity "SharePoint Web Services Default"
New-SPWordViewingServiceApplication -Name "WdView" -ApplicationPool $appPool | New-SPWordViewingServiceApplicationProxy -Name "WdProxy"
New-SPPowerPointServiceApplication -Name "PPT" -ApplicationPool $appPool | New-SPPowerPointServiceApplicationProxy -Name "PPTProxy" -AddToDefaultGroup
New-SPExcelServiceApplication -Name "Excel" -ApplicationPool $appPool
    Note:

    This script uses the SharePoint Web Services Default application pool as an example. You can use another existing application pool or create a new one.

  3. Save the file, naming it Create-SrvAppsProx.ps1.

    Note:

    You can use a different file name. However, you must save the file as an ANSI-encoded text file that has the extension .ps1.

  4. Click Start, click All Programs, and then click Microsoft SharePoint 2010 Products.

  5. Right-click SharePoint 2010 Management Shell, and then click Run as administrator.

  6. Change to the directory where you saved the file.

  7. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    ./Create-SrvAppsProx.ps1
Note:

You might have to refresh the Manage Service Applications page in your browser to see the new service applications and service application proxies.

Activate the Office Web Apps feature

After the services have been started and the service applications and service application proxies have been created, you must enable the Office Web Apps feature on any existing site collections. You can enable the feature on a single site collection either by using the Site Settings page or by using Windows PowerShell. If you have many site collections, you can enable the feature on all existing site collections at the same time by using Windows PowerShell.

Note:

You do not have to complete this procedure for new site collections that you create after you have installed Office Web Apps.

Complete the procedures in this section to enable the Office Web Apps feature on one or more existing site collections.

Note:

To complete the procedures in this section, you must be an administrator for the site collection.

To activate the Office Web Apps feature on a single site collection by using Site Settings

  1. In a supported browser, open the SharePoint site, click Site Actions, and then click Site Settings.

  2. On the Site Settings page, in Site Collection Administration, click Site collection features.

  3. On the Features page, for Office Web Apps, click Activate.

To activate the Office Web Apps feature on a single site collection by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. Also verify that the account that you use to perform this procedure is a member of the Administrators group on the computer that is running Windows PowerShell, and is a member of the Farm Administrators SharePoint group.

  2. Copy the following code and paste it into a text editor, such as Notepad:

    Copy Code
    $webAppsFeatureId = $(Get-SPFeature -limit all | where {$_.displayname -eq "OfficeWebApps"}).ID
$singleSiteCollection = Get-SPSite -Identity <SiteCollURL>
Enable-SPFeature $webAppsFeatureId -Url $singleSiteCollection.URL

  3. Replace the following placeholders with values where:

    <SiteCollURL> is the URL for the site collection

  4. Save the file, naming it Activate-WebApps.ps1.

  5. Click Start, click All Programs, and then click Microsoft SharePoint 2010 Products.

  6. Right-click SharePoint 2010 Management Shell, and then click Run as administrator.

  7. Change to the directory where you saved the file.

  8. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    ./Activate-WebApps.ps1

To activate the Office Web Apps feature on all site collections by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. Also verify that the account that you use to perform this procedure is a member of the Administrators group on the computer that is running Windows PowerShell, and is a member of the Farm Administrators SharePoint group.

  2. Copy the following code and paste it into a text editor, such as Notepad:

    Copy Code
    $webAppsFeatureId = $(Get-SPFeature -limit all | where {$_.displayname -eq "OfficeWebApps"}).ID
Get-SPSite -limit ALL | foreach {Enable-SPFeature $webAppsFeatureId -url $_.URL}

  3. Save the file, naming it Activate-AllWebApps.ps1.

  4. Click Start, click All Programs, and then click Microsoft SharePoint 2010 Products.

  5. Right-click SharePoint 2010 Management Shell, and then click Run as administrator.

  6. Change to the directory where you saved the file.

  7. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    ./Activate-AllWebApps.ps1

Install and configure Office Web Apps on a new stand-alone SharePoint 2010 Products server

This section applies only if you are installing Office Web Apps on a new SharePoint 2010 Products server on which the SharePoint Products Configuration Wizard has not been previously run.

Note:

To complete the following procedures, you must be a member of the Administrators group on the local computer.

Run Office Web Apps Setup

Complete the procedures in this section to install Office Web Apps components and files on a new stand-alone SharePoint 2010 Products server.

To run Office Web Apps Setup

  1. From the root folder of the Office Web Apps files, run Setup.exe.

  2. On the Enter your Product Key page, enter your product key, and then click Continue.

  3. On the Choose a file location page, do one of the following:

    • To install to the default location, click Install Now.

    • To install to a different location, specify the location that you want to install to, and then click Install Now.

  4. After Setup is complete, on the Run Configuration Wizard page, ensure that the Run the SharePoint Products Configuration Wizard now check box is selected, and then click Close to start the SharePoint Products Configuration Wizard.

To register and start the services by using the SharePoint Products Configuration Wizard

Complete this procedure to register and start the Office Web Apps services. Running the SharePoint Products Configuration Wizard on a new, stand-alone SharePoint 2010 Products server also creates the service applications and service application proxies, and enables the Office Web Apps feature on all existing site collections. The Office Web Apps feature is also enabled automatically for all new site collections.

To register and start the services by using the SharePoint Products Configuration Wizard

  1. If you left the Run the SharePoint Products Configuration Wizard now check box selected in the previous procedure, the SharePoint Products Configuration Wizard will be started automatically. If the wizard does not start, click Start, click All Programs, click Microsoft SharePoint 2010 Products, and then click SharePoint Products Configuration Wizard.

  2. On the Welcome to SharePoint Products page, click Next.

  3. In the dialog box that notifies you that some services might have to be started or reset during configuration, click Yes to begin the configuration.

  4. On the Configuration Successful page, click Finish. Your new SharePoint site opens to the Template Selection page.

  5. On the Template Selection page, click one of the following options, and then click OK:

    • In the Template Selection section, click a predefined template.

    • In the Solutions Gallery section, click Solutions Gallery, and then customize your own site template.

  6. On the Set Up Groups for this Site page, specify who should have access to your site, and then either create a new group or use an existing group for these users by doing one of the following:

    • To create a new group, click Create a new group, and then type the name of the group and the members that you want to add to this group.

    • To use an existing group, click Use an existing group, and then select the user group in the Item list.

  7. Click OK.

Install and configure Office Web Apps on an existing SharePoint server farm

Perform the procedures in this section only if you are installing Office Web Apps on an existing SharePoint 2010 Products server farm on which the SharePoint Products Configuration Wizard has been previously run.

Note:

When you run Setup.exe, Office Web Apps Setup configures the default open behavior for SharePoint to open Microsoft Word, Excel, PowerPoint, and OneNote documents in the browser by using their associated Web application.

If you have run Office Web Apps Setup on a live production server farm, but have not yet started the services, created the service applications, and activated the Office Web Apps feature, a user might not be able to access site collections or might get broken link error messages when he or she tries to open a document in the browser.

You can avoid end users getting these error messages while you complete additional deployment tasks on a live production server. We recommended that you enable the OpenInClient feature on all existing site collections prior to running Setup. For more information, see Configure the default open behavior for browser-enabled documents (Office Web Apps).

Note:

To complete the following procedures, you must be a member of the Administrators group on the local computer.

Run Office Web Apps Setup

Complete this procedure to install Office Web Apps on a single SharePoint 2010 Products server. You must perform this procedure on every server in the farm.

To run Office Web Apps Setup

  1. From the root folder of the Office Web Apps files, run Setup.exe.

  2. On the Enter your Product Key page, enter your product key, and then click Continue.

  3. On the Choose a file location page, do one of the following:

    • To install to the default location, click Install Now.

    • To install to a different location, specify the location that you want to install to, and then click Install Now.

  4. After Setup is complete, on the Run Configuration Wizard page, do one of the following:

    • Leave the Run the SharePoint Products Configuration Wizard now selected and leave the page open until you have installed Office Web Apps on all servers, and then click Close.

    • Clear the Run the SharePoint Products Configuration Wizard now check box, and then click Close.

  5. You must repeat this procedure on each server in the farm before proceeding to the next procedure.

Run the SharePoint Products Configuration Wizard to register the services

Complete this procedure to register the Office Web Apps services on a single SharePoint 2010 Products server. You must perform this procedure on every server in the farm.

To run the SharePoint Products Configuration Wizard to register the services

  1. To start the SharePoint Products Configuration Wizard, click Start, click All Programs, click Microsoft SharePoint 2010 Products, and then click SharePoint 2010 Products Configuration Wizard.

  2. On the Welcome to SharePoint Products page, click Next.

  3. In the dialog box that notifies you that some services might need to be started or reset during configuration, click Yes.

  4. On the Completing the SharePoint Products Configuration Wizard page, click Next to begin the configuration.

  5. On the Configuration Successful page, click Finish, and then, on the Configure your SharePoint farm page, click Cancel.

  6. On the Configure your SharePoint farm page, click No, I will configure everything myself. Cancel.

    Important:

    Do not run the Farm Configuration Wizard; you will configure the server farm for Office Web Apps by using the procedures that follow in this section.

  7. You must repeat this procedure on each server in the farm before proceeding to the next procedure.

Start the services

Note:

You should complete this procedure after you have installed Office Web Apps and run the SharePoint Products Configuration Wizard on each server in the farm.

A service provides the physical location for a service application. For each server that you want to run the Office Web Apps service applications, you must start the services. You can start the services by using Central Administration or by using Windows PowerShell.

Complete the procedures in this section to start the services before proceeding to the next procedure. Start the services on the Web front-end servers on which you want users to view and edit documents in the browser.

To start the services by using Central Administration

  1. On the Central Administration Web site, in System Settings, click Manage services on server.

  2. On the Services on Server page, do the following:

    1. In the list of services on the selected server, for Excel Calculation Services, PowerPoint Service, and Word Viewing Service, click Start.

    2. Click the Server button at the top, click Change Server, and then in the Select Server dialog box, click a different server name.

    3. Repeat these steps until the services have been started on all Web front-end servers on which you want users to view and edit documents in the browser.

    Note:

    On a server that is running SharePoint Server 2010 Enterprise, the Excel Calculation Services service is created and started by default. The OneNote Web App does not require a SharePoint service.

To start the services by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. Also verify that the account that you use to perform this procedure is a member of the Administrators group on the computer that is running Windows PowerShell.

  2. Copy the following code and paste it into a text editor, such as Notepad:

    Copy Code
    $machinesToActivate = @("<ServerName1>","<ServerName2>")
$serviceInstanceNames = @("Word Viewing Service","PowerPoint Service","Excel Calculation Services")
foreach ($machine in $machinesToActivate)
{
  foreach ($serviceInstance in $serviceInstanceNames)
  {
     $serviceID = $(Get-SPServiceInstance | where {$_.TypeName -match $serviceInstance} | where {$_.Server -match "SPServer Name="+$machine}).ID
     Start-SPServiceInstance -Identity $serviceID
  }
}

  3. Replace the following placeholders with values where:

    <ServerName1> and <ServerName2> are names of SharePoint 2010 Products servers on which you want to start the services.

  4. Save the file, naming it Start-WebAppSvcs.ps1.

    Note:

    You can use a different file name. However, you must save the file as an ANSI-encoded text file that has the extension .ps1.

  5. Click Start, click All Programs, and then click Microsoft SharePoint 2010 Products.

  6. Right-click SharePoint 2010 Management Shell, and then click Run as administrator.

  7. Change to the directory where you saved the file.

  8. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    ./Start-WebAppSvcs.ps1

Create the service applications and the service application proxies

Note:

You must start the services before you complete the procedures in this section. You need to complete the procedures in this section on only one server in the farm.

After you have started the services, you must create the service applications and the service application proxies that connect the SharePoint Web front-end servers to the service applications. You can create the service applications and the service application proxies for the, Word Web App, PowerPoint Web App, and Excel Calculation Services Web applications by using Central Administration or by using Windows PowerShell. After the service applications are created, they will run automatically on the services that have been started.

Note:

On a server that is running SharePoint Server 2010 Enterprise, the Excel Calculation Services service application is created by default. The OneNote Web App does not require a service application.

To create the service applications and the service application proxies by using Central Administration

  1. On the Central Administration Web site, click Application Management, and then, in the Service Applications area, click Manage service applications.

  2. On the Manage Service Applications page, click New, and then click PowerPoint Service Application.

  3. In the New PowerPoint Service Application dialog box, do the following:

    1. In the Name box, type either PowerPoint Service Application or another descriptive name.

    2. In the Application Pool area, do one of the following:

      • Click Use existing application pool, and then in the list click SharePoint Web Services Default.

      • Click Create new application pool, in the Application pool name box, type a name for the application pool, and then select a managed account from the Configurable list.

        Note:

        When you create a new application pool, you can specify a security account used by the application pool to be either a predefined Network Service account or a managed account. The account must have db_datareader, db_datawriter, and execute permissions for the SharePoint configuration database, and be assigned to the db_owner role for the content databases. For more information about services account permissions in SharePoint 2010 Products, see Account permissions and security settings (SharePoint Server 2010).

    3. In the Default Application Proxy Group area, either leave the Add application proxy to default group check box selected, or clear it and then click OK.

  4. On the Manage Service Applications page, click New, and then click Word Viewing Service.

  5. In the Word Viewing Service Application dialog box, do the following:

    1. In the Name box, either type Word Viewing Service Application or another descriptive name.

    2. In the Application Pool area, do one of the following:

      • Click Use existing application pool, and then, in the list, click SharePoint Web Services Default.

      • Click Create new application pool, and then, in the Application pool name box, type a name for the application pool, and then select a managed account from the Configurable list.

        Note:

        When you create a new application pool, you can specify a security account used by the application pool to be either a predefined Network Service account or a managed account. The account must have db_datareader, db_datawriter, and execute permissions for the SharePoint configuration database, and be assigned to the db_owner role for the content databases. For more information about services account permissions in SharePoint 2010 Products, see Account permissions and security settings (SharePoint Server 2010).

    3. In the Add to default proxy list area, either leave the Add this service application's proxy to the farm's default proxy list check box selected or clear it, and then click OK.

  6. On a server that is running SharePoint Server 2010, the Excel Calculation Services service application is created and started by default. If an Excel Calculation Services service application does not exist already, on the Manage Service Applications page, click New, and then click Excel Services Application.

  7. In the Create New Excel Services Application dialog box, do the following:

    1. In the Name box, type either Excel Services Application or another descriptive name.

    2. In the Application Pool area, do one of the following:

      • Click Use existing application pool, and then in the list click SharePoint Web Services Default

      • Click Create new application pool, and then, in the Application pool name box, type a name for the application pool, and then select a managed account from the Configurable list.

    3. In the Add to default proxy list area, either leave the Add this service application's proxy to the farm's default proxy list check box selected or clear it, and then click OK.

    Note:

    You might need to refresh the Manage Service Applications page in your browser to see the new service applications and service application proxies.

To create the service applications and the service application proxies by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. Also verify that the account that you use to perform this procedure is a member of the Administrators group on the computer that is running Windows PowerShell.

  2. On a computer that is running SharePoint Server 2010 Enterprise, the Excel Calculation Services service application is created by default. Copy the following code and paste it into a text editor, such as Notepad:

    Copy Code
    $appPool = Get-SPServiceApplicationPool -Identity "SharePoint Web Services Default"
New-SPWordViewingServiceApplication -Name "WdView" -ApplicationPool $appPool | New-SPWordViewingServiceApplicationProxy -Name "WdProxy"
New-SPPowerPointServiceApplication -Name "PPT" -ApplicationPool $appPool | New-SPPowerPointServiceApplicationProxy -Name "PPTProxy" -AddToDefaultGroup

    If an Excel Calculation Services service application does not already exist, copy the following code and paste it into a text editor, such as Notepad:

    Copy Code
    $appPool = Get-SPServiceApplicationPool - Identity "SharePoint Web Services Default"
New-SPWordViewingServiceApplication -Name "WdView" -ApplicationPool $appPool | New-SPWordViewingServiceApplicationProxy -Name "WdProxy"
New-SPPowerPointServiceApplication -Name "PPT" -ApplicationPool $appPool | New-SPPowerPointServiceApplicationProxy -Name "PPTProxy" -AddToDefaultGroup
New-SPExcelServiceApplication -Name "Excel" -ApplicationPool $appPool
    Note:

    This script uses the SharePoint Web Services Default application pool as an example. You can use another existing application pool or create a new one.

  3. Save the file, naming it Create-SvcAppsProx.ps1.

    Note:

    You can use a different file name. However, you must save the file as an ANSI-encoded text file that has the extension .ps1.

  4. Click Start, click All Programs, and then click Microsoft SharePoint 2010 Products.

  5. Right-click SharePoint 2010 Management Shell, and then click Run as administrator.

  6. Change to the directory where you saved the file.

  7. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    ./Create-SvcAppsProx.ps1
Note:

You might need to refresh the Manage Service Applications page in your browser to see the new service applications and service application proxies.

Activate the Office Web Apps feature

After you have started the services and created the service applications and service application proxies, you must activate the Office Web Apps feature on existing site collections. You can activate the feature on a single site collection by using the Site Settings page or by using Windows PowerShell. If you have a large number of site collections, you can activate the feature on all site collections at one time by using Windows PowerShell.

Complete the procedures in this section to activate the Office Web Apps feature on one or more existing site collections.

To activate the Office Web Apps feature by using the Site Settings page, you must be an administrator for the site collection. To activate the Office Web Apps feature by using Windows PowerShell, you must use an account that has read/write and execute permissions for the content databases and the SharePoint configuration database, and be assigned to the db_owner role for the content databases. For more information about services account permissions in SharePoint 2010 Products, see Account permissions and security settings (SharePoint Server 2010).You do not have to complete this procedure for new site collections that you create.

Important:

If you activated the OpenInClient feature on all existing site collections prior to running Setup to prevent users from getting broken link error messages, you should disable the OpenInClient feature after you activate the Office Web Apps feature. For more information, see Configure the default open behavior for browser-enabled documents (Office Web Apps).

To activate the Office Web Apps feature on a single site collection by using the Site Settings page

  1. In a supported browser, open the SharePoint site, click Site Actions, and then click Site Settings.

  2. On the Site Settings page, in Site Collection Administration, click Site collection features.

  3. On the Features page, for Office Web Apps, click Activate.

  4. Repeat this procedure for each existing site collection on which you want to activate the Office Web Apps feature.

To activate the Office Web Apps feature on a single site collection by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. Also verify that the account that you use to perform this procedure is a member of the Administrators group on the computer that is running Windows PowerShell, and is a member of the Farm Administrators SharePoint group.

  2. Copy the following code and paste it into a text editor, such as Notepad:

    Copy Code
    $webAppsFeatureId = $(Get-SPFeature -limit all | where {$_.displayname -eq "OfficeWebApps"}).ID
$singleSiteCollection = Get-SPSite -Identity <SiteURL>
Enable-SPFeature $webAppsFeatureId -Url $singleSiteCollection.URL

  3. Replace the following placeholders with values where:

    SiteURL is the URL of the site collection

  4. Save the file, naming it ActivateWebApps.ps1.

    Note:

    You can use a different file name. However, you must save the file as an ANSI-encoded text file that has the extension .ps1.

  5. Click Start, click All Programs, and then click Microsoft SharePoint 2010 Products.

  6. Right-click SharePoint 2010 Management Shell, and then click Run as administrator.

  7. Change to the directory where you saved the file.

  8. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    ./ActivateWebApps.ps1

To activate the Office Web Apps feature on all site collections by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. Also verify that the account that you use to perform this procedure is a member of the Administrators group on the computer that is running Windows PowerShell, and is a member of the Farm Administrators SharePoint group.

  2. Copy the following code and paste it into a text editor, such as Notepad:

    Copy Code
    $webAppsFeatureId = $(Get-SPFeature -limit all | where {$_.displayname -eq "OfficeWebApps"}).ID
Get-SPSite -limit ALL |foreach {Enable-SPFeature $webAppsFeatureId -url $_.URL}

  3. Save the file, naming it ActivateWebAppsAll.ps1.

    Note:

    You can use a different file name. However, you must save the file as an ANSI-encoded text file that has the extension .ps1.

  4. Click Start, click All Programs, and then click Microsoft SharePoint 2010 Products.

  5. Right-click SharePoint 2010 Management Shell, and then click Run as administrator.

  6. Change to the directory where you saved the file.

  7. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    ./ActivateWebAppsAll.ps1

Install and configure Office Web Apps on a new SharePoint server farm

Perform the procedures in this section only if you are installing Office Web Apps on a new SharePoint 2010 Products server farm on which neither the SharePoint Products Configuration Wizard nor the Farm Configuration Wizard have been previously run.

Note:

To complete the following procedures, you must be a member of the Administrators group on the local computer.

Run Office Web Apps Setup

Complete this procedure to install the Office Web Apps files and components on a single SharePoint 2010 Products server in a new server farm on which neither the SharePoint Products Configuration Wizard nor the Farm Configuration Wizard has not previously been run. You must complete this procedure on each server in the server farm.

To run Office Web Apps Setup

  1. From the root folder of the Office Web Apps files, run Setup.exe.

  2. On the Enter your Product Key page, enter your product key, and then click Continue.

  3. On the Choose a file location page, do one of the following:

    • To install to the default location, click Install Now.

    • To install to a different location, specify the location that you want to install to, and then click Install Now.

  4. After Setup is complete, on the Run Configuration Wizard page, ensure that the Run the SharePoint Products Configuration Wizard now check box is selected, and then click Close to open the wizard.

  5. Complete the following procedure before you install Office Web Apps on the other servers in the farm.

Run the SharePoint Products Configuration Wizard to register services

Complete this procedure to run the SharePoint Products Configuration Wizard to register the Office Web Apps services on a single SharePoint 2010 Products server. You must complete this procedure on each server in the server farm.

Important:

Install Office Web Apps and run the SharePoint Products Configuration Wizard first on a server on which you want to host the Central Administration Web application. The first time that you run the SharePoint Products Configuration Wizard, the wizard creates the configuration database that all successive servers that you add to farm will share. Then, install Office Web Apps and run the SharePoint Products Configuration Wizard on the other servers that you want to add to the new farm.

To run the SharePoint Products Configuration Wizard to register the services

  1. To start the SharePoint Products Configuration Wizard, click Start, click All Programs, click Microsoft SharePoint 2010 Products, and then click SharePoint 2010 Products Configuration Wizard.

  2. On the Welcome to SharePoint Products page, click Next.

  3. In the dialog box that notifies you that some services might have to be started or reset during configuration, click Yes.

  4. On the Connect to a server farm page, do one of the following:

    • To create a new server farm, on the first SharePoint 2010 Products server, click Create a new server farm, and then click Next.

    • To add more SharePoint 2010 Products servers to the farm, click Connect to an existing server farm, and then click Next.

  5. On the Specify Configuration Database Settings page, do the following:

    1. In the Database server box, type the name of the computer that is running SQL Server.

      • To create the new configuration database on the first SharePoint 2010 Products server, in the Database name box, type the name that you want to use for your configuration database or use the default database name. The default name is SharePoint_Config.

      • To add more SharePoint 2010 Products servers to the farm, click Retrieve Database Names, and then, in the Database name box, select the appropriate database from the list or type the name of your server farm's configuration database.

    3. On the first SharePoint 2010 Products server, to specify a database access account, do the following:

      • In the Username box, type the user name of the server farm account in DOMAIN\user name format.

        Important:

        The server farm account is used to create and access your configuration database. It also acts as the application pool identity account for the Central Administration application pool, and it is the account under which the Windows SharePoint Services Timer service runs. The SharePoint Products Configuration Wizard adds this account to the SQL Server Login accounts, the SQL Server dbcreator fixed server role, the SQL Server securityadmin fixed server role, and the db_owner fixed database role for all SharePoint databases in the server farm. The user account that you specify as the service account must be a domain user account. However, it does not have to be a member of any specific security group on your Web servers or your database servers. We recommend that you follow the least-privilege principle and specify a user account that is not a member of the Administrators group on your Web servers or your database servers.

      • In the Password box, type the user password.

    4. Click Next.

  6. On the Specify Farm Security Settings page, type a passphrase for your farm, and then click Next.

    Although a passphrase resembles a password, it is usually longer to increase security. It is used to encrypt credentials of accounts that are registered in SharePoint 2010 Products. For example, the SharePoint Server system account that you provide when you run the SharePoint Products Configuration Wizard. Ensure that the passphrase meets the following criteria:

    • Contains at least eight characters

    • Contains at least three of the following four character groups:

      • English uppercase characters (from A through Z)

      • English lowercase characters (from a through z)

      • Numerals (from 0 through 9)

      • Nonalphabetic characters (such as !, $, #, %)

      Important:

      Ensure that you remember the passphrase, because you must use it every time that you add a server to the farm.

  7. On the Configure SharePoint Central Administration Web Application page, do the following:

    Note:

    This page does not appear if you have added the first server to the farm and are adding an additional server to farm.

    1. To use the default port number for the Central Administration Web application, leave the Specify port number check box cleared, or — to use a specific port number — select the Specify port number check box, and then type the port number that you want to use.

      Note:

      If you want to access the Central Administration Web site from a remote computer, ensure that you enable access to the port number that you configure in this step. You do this by configuring an inbound rule for SharePoint Central Administration v4 in Windows Firewall with Advanced Security.

    2. Click either NTLM or Negotiate (Kerberos), and then click Next.

  8. On the Completing the SharePoint Products Configuration Wizard page, review the configuration settings, and then do one of the following:

    • If you are running the wizard on the first server in the farm, click Next to begin the configuration.

    • If you are adding an additional server to the farm and you want to use the server to host the Central Administration Web application, click Advanced Settings, and then click Use this machine to host the web site.

      Note:

      If you are adding an additional server to the farm, the default setting is Do not use this machine to host the web site.

  9. On the Configuration Successful page, click Finish. Your new SharePoint site opens to the Configure your SharePoint farm page.

    Important:

    Do not run the SharePoint Farm Configuration Wizard until you have installed Office Web Apps and run the SharePoint Products Configuration Wizard on every server in the farm.

Run the SharePoint Farm Configuration Wizard

After you have installed Office Web Apps and run the SharePoint Products Configuration Wizard on all servers in the farm, complete this procedure to run the SharePoint Farm Configuration Wizard. You need to run the Farm Configuration Wizard on only one server. Running the SharePoint Farm Configuration Wizard does the following on each server in the farm:

  • Starts the services

  • Creates the service applications and service application proxies

  • Activates the Office Web Apps feature for any existing site collections

On the Configure your SharePoint farm page, you can decide to use a wizard to configure services or you can configure services manually.

The choice that you make here is a matter of personal preference. The Farm Configuration Wizard will configure some services automatically when it is run. However, if you configure services manually, you have more flexibility in designing your logical architecture. For more information about how to configure the services manually, see Multiple servers for a three-tier farm (SharePoint Foundation 2010) or Multiple servers for a three-tier farm (SharePoint Server 2010).

Important:

If you are using DBA-created databases, see Deploy by using DBA-created databases (SharePoint Server 2010).

To run the SharePoint Farm Configuration Wizard

  1. To run the Farm Configuration Wizard, on the Central Administration Web site, click Configuration Wizards, and then click Launch the Farm Configuration Wizard.

  2. On the Configure your SharePoint Farm page, in the Service Account area, click Use an existing managed account, and then select the server farm account that you created in an earlier procedure.

  3. In the Services area, select the Office Web Apps services and other services that you want to enable, and then click Next.

  4. On the Create Site Collection page, either complete the optional page to create a new top-level site or click Skip to continue without creating a new top-level site at this point. For more information about how to create a top-level site, see Create a site collection (SharePoint Server 2010).

  5. On the Configure your SharePoint Farm page, click Finish.


Operations for SharePoint Foundation 2010

Welcome to the operations guide for Microsoft SharePoint Foundation 2010. The articles in this guide help you operate and maintain your servers, server farms, sites, and solutions.

In this section:

  • Server and server farm administration (SharePoint Foundation 2010)

    This section describes how to maintain servers and server farms within a SharePoint Foundation 2010 environment. It includes articles about backup and recovery, managing databases, Web application management, service application management, health and monitoring, and security and permissions administration.

  • Site and solution administration (SharePoint Foundation 2010)

    This section describes how to maintain sites and solutions within a SharePoint Foundation 2010 environment. It includes articles about managing site collections, service applications and services, features such as workflow, and sandboxed solutions.


Best practices (SharePoint Foundation 2010)

Published: June 28, 2011

Some design decisions that you make for Microsoft SharePoint Foundation 2010 can have a lasting effect on your environment and affect how well the solution performs. There are also operational practices that can improve performance and availability and provide a better experience for users and administrators. Many problems experienced by administrators and users can be avoided by reviewing concise descriptions of best practices for designing and operating SharePoint Foundation 2010 environments. The articles in this section summarize current knowledge and research from Microsoft Consulting Services and the SharePoint Foundation product team into a must-read quick reference for key design decisions and operational practices. Each article briefly describes the best practices for a particular environment or product area and provides links for additional reading.

Follow these best practices to help ensure that you avoid many common pitfalls and keep your SharePoint Foundation environment available and performing well. Use these articles as cheat sheets to help you get the most out of SharePoint Foundation.

In this section:

  • Best practices for operational excellence (SharePoint Foundation 2010)

  • Best practices for extranet environments (SharePoint Foundation 2010)

  • Best practices for virtualization (SharePoint Foundation 2010)

  • Backup and recovery best practices (SharePoint Foundation 2010)


Best practices for operational excellence (SharePoint Foundation 2010)
See Also

Published: July 14, 2011

Microsoft SharePoint Foundation 2010 is used for a broad set of applications and solutions, either stand-alone or in concert with other systems. To achieve this flexibility, the platform supports lots of possible architectures and configurations. Some parts of the system are well-known, but we still see variances to these parts. This article focuses on the top configuration best practices that you should consider, such as front-end Web server configuration, database configuration, servicing, and patching.

This article is one of a series of best practices articles for SharePoint Foundation 2010. This article describes best practices for operational excellence. For more articles in the series, see Best practices (SharePoint Foundation 2010). For additional information and resources about Best Practices for SharePoint Foundation 2010, see the Best Practices Resource Center (http://go.microsoft.com/fwlink/p/?LinkId=221383).

1. Use lots of memory, and fast network adapters

To get the performance you want from an environment, make sure that you use lots of memory on the Web and application servers.

Network speed is also important for performance of the environment. Take the following actions to make network traffic move quickly:

  • Use gigabit network adapters for all server roles.

  • For front-end Web servers and application servers, use dual network adapters in production environments. Use one network adapter for users and one for Microsoft SQL Server communication.

  • Use private network adapters for inter-server communications for tasks such as management and backups so that this traffic does not affect the overall farm performance.

  • Under heavy load, consider using virtual local area networks (VLANs) to reduce network traffic.

For more information, see Hardware and software requirements (SharePoint Foundation 2010) and Performance and capacity test results and recommendations (SharePoint Foundation 2010).

2. Stay close: Do not put too much network distance between front-end Web servers, application servers, and database servers

No front-end Web server or application server should have more than one millisecond (ms) of latency between it and the database server. In practice, this generally means that you should keep all the servers in a farm in the same data center. All servers in a farm must be in the same time zone.

3. Consider performance and availability when you configure Web servers and application servers

The way that you configure Web servers and application servers can have a big effect on throughput and availability. Follow the following recommendations for best results:

  • Separate system components into logical drives and use RAID for redundancy.

    Components on drive Recommended RAID level

    Windows and program files drive

    RAID 1

    Operating system swap drive and temp directory

    RAID 1

    Log files

    RAID 1

    Boot disk for imaging and Windows Desktop Search (optional)

    RAID 1

  • Use at least four physical disks and use separate disks to keep the log files and swap drive separate from the Windows and program files drive.

  • In most production environments, we recommend that you allocate at least 200 GB of disk space for the operating system and temporary files and 150 GB of disk space for logs.

  • Be sure to test the Web server capacity and provide sufficient servers for the number of users and requests that are in the farm. For high availability, make sure that you allocate an additional server so that you can pull one server out of a network load-balancing server farm and recycle it without affecting service availability.

For more information, see Plan for availability (SharePoint Foundation 2010).

4. Consider performance and availability when you configure database servers

As is also the case with Web servers and application servers, the configuration for database servers affects how well SharePoint Foundation 2010 performs. Certain databases require specific co-location with or separation from other databases.

The databases listed in the following table should be kept separate from other databases.

Database name | Size | Read/write optimization | Co-location
TempDB | Medium |  | Must be on a separate spindle from all other databases.
Secure Store | Small |  | Host on a separate database instance. Limit access to one administrator.
Usage | Extra large | Optimize for write | Must be on a separate spindle.
Note:

The usage database can be on a separate server, and does not need performance to be as high as other databases. The speed of the usage database does not affect the performance of the site.

The databases in the following table must be stored in the same location as other databases.

Database name | Size | Co-location
Configuration Central Admin content | Small | Must be located together
SQL Server ReportServer ReportServerTempDB | Small Varies | Must be on the same database server

More information about database sizing and read/write mix for specific databases is available in the Databases That Support SharePoint 2010 Products model(http://go.microsoft.com/fwlink/p/?LinkId=187970).

5. Keep it clean: Maintain databases in a healthy state

A healthy database server has enough headroom for databases and log files, plus enough capacity to keep up with requests. Use the recommendations in the following list to keep database servers performing optimally.

  • Pre-grow all databases and logs if you can. Be sure to monitor the sizes so that you do not run out of disk space.

  • Do not overload database servers by using too many databases or data. Use the following guidelines:

    • When you use SQL Server mirroring, do not store more than 50 databases on a single physical instance of SQL Server .

    • Limit content databases to 200 GB.

  • Defragment and rebuild indices daily, if you can absorb the downtime required to rebuild.

  • Monitor the database server to make sure that it is responding correctly and is not overloaded. Key performance counters to monitor include the following:

    • Network Wait Queue: at 0 or 1 for good performance

    • Average Disk Queue Length (latency): less than 5 ms

    • Memory used: less than 70 percent

    • Free disk space: more than 25 percent

    • Buffer cache hit ratio: 90 percent or better

For more information, see the following resources:

  • SharePoint Diagnostic Studio 2010 (SPDiag 3.0)

  • Good List of Performance Counters (http://go.microsoft.com/fwlink/p/?LinkId=123925)

    (Although this link points to content for Windows SharePoint Services 3.0, the guidance it contains is still valid for SharePoint Foundation 2010.)

6. Keep servers current by using the latest updates

It is important to keep current by applying the latest hotfixes, updates, and service packs. These updates contain important product enhancements and improvements. However, make sure that you thoroughly test these updates on the pre-production environments before you apply them to the production environments. Follow the recommended procedure to deploy the updates, including the following:

  • Turn on Windows Update to download updates automatically, but not install automatically.

  • Schedule time to install updates at off-peak hours.

  • For high availability, rotate servers out of service one at a time during the update process.

Make sure that you are patching the BIOS (server computers, controllers, and disks), Windows operating system, Microsoft SharePoint Foundation 2010 and SQL Server.

For more information, see the Updates for SharePoint 2010 Products Resource Center (http://go.microsoft.com/fwlink/p/?LinkID=209614).

7. Use different accounts for different actions

Use appropriate accounts for the Web applications and services. All accounts should be domain accounts. (Reminder: Do not use Network Service.) For best results, use separate accounts for the following:

  • Web applications: Use different accounts based on your security requirements.

  • Search account: Use one account for the farm.

There are many more accounts that are used by SharePoint Foundation 2010, such as SQL Server services accounts, the Central Administration application pool identity, the SharePoint Foundation Timer service account, the default content access account, the single sign-on account, and the profile import account. Be sure to follow recommended procedures to keep their passwords current and ensure that the services keep working.

For more information, see Change passwords used for administration accounts (SharePoint Foundation 2010).

8. Follow recommendations for backing up and restoring data

In general, it is best to use a local disk, not a network drive, for backups, and then copy the data later. Use compression when you can, but when you use compression with backups, be mindful not to overwhelm SQL Server. For example, LiteSpeed for SQL Server compresses during backup, which can disrupt SQL Server performance.

For large databases, rely on incremental backups such as those available with System Center Data Protection Manager (DPM) 2010. Do not rely on full backups as your primary mechanism. They are too large to restore quickly.

For more information, see Backup and recovery best practices (SharePoint Foundation 2010).

9. Be sure that you back up and truncate the log files

Do not only back up the data. Back up the log files, too. The usage logs, IIS logs, transaction logs, and SMTP e-mail logs all must be backed up if you want to be able to fully recover your environment. For transaction logs, you should back up and truncate the log file every five minutes. However, never shrink the transaction log because you may experience performance issues while the log re-grows.

For more information, see Back up or archive logs (SharePoint Foundation 2010) and How to stop the transaction log of a SQL Server database from growing unexpectedly (http://go.microsoft.com/fwlink/p/?LinkID=111458).

10. Restore data: Test backups and have a standby environment available for service continuity

Routinely test backups and validate their consistency. Do not assume that the backup will work when you want it to. Make sure that it will. Practice recovery to learn what else you must do to bring back the whole environment. For geographically dispersed environments, prepare for disaster recovery by setting up a remote farm. Then you can restore the environment by using the database attach command to upload a copy of the database to the remote farm and redirect users. Similarly, you can set up a standby environment that runs the same version of software as the production environment so that you can restore the databases and recover documents quickly. Keep databases small to speed recovery.

For more information, see Procedural best practices.

If you are using DPM 2010 for backup and recovery, make sure that you plan for backup and recovery of service applications separately. DPM 2010 does not back up Search or other service applications.

For more information, see Choose what to protect and recover in your environment and How to protect SharePoint with DPM 2010 whitepaper (http://go.microsoft.com/fwlink/p/?LinkId=218153).

Acknowledgments

The SharePoint Foundation 2010 Content Publishing team thanks the following contributors to this article:

  • Aaron Saikovski, Microsoft Consulting Services

  • Ali Mazaheri, Microsoft Consulting Services

  • Bryan Porter, Microsoft Consulting Services

  • Chris Holder, Microsoft SharePoint Customer Engineering

  • Dan Winter, Microsoft SharePoint Customer Engineering

  • Eric Charran, Microsoft Consulting Services

  • Gus Apostol, Microsoft SQL Server Customer Programs

  • John S. Moh, Microsoft Consulting Services

  • Luca Bandinelli, Microsoft SharePoint Customer Engineering

  • Rahim Dossa, Microsoft Consulting Services

  • Steve Peschka, Microsoft Consulting Services

  • Steve Walker, Microsoft SharePoint Customer Engineering

  • Tajeshwar Singh, Microsoft Consulting Services

See Also

Concepts

Health monitoring (SharePoint Foundation 2010)


Best practices for extranet environments (SharePoint Foundation 2010)

Published: May 26, 2011

This article describes planning and design recommendations for extranet environments based on SharePoint Foundation in which users outside the internal network are given access to sites. This article is one of a series of Best Practices articles for Microsoft SharePoint Foundation 2010.

1. Get started with the Extranet Topologies for SharePoint 2010 Products model

The Extranet Topologies for SharePoint 2010 Products model illustrates the specific extranet topologies that have been tested with SharePoint 2010 Products. It also provides a comparison of Internet Security and Acceleration (ISA) Server, Forefront Threat Management Gateway (TMG), and Forefront Unified Access Gateway (UAG) when used as a firewall or gateway product with SharePoint 2010 Products.

Extranet Topologies for SharePoint 2010 Products

Extranet topologies for SharePoint 2010 Products

Click the image to zoom into the Extranet Topologies for SharePoint 2010 Products model

Download the Extranet Topologies for SharePoint 2010 Products model (http://go.microsoft.com/fwlink/p/?LinkId=219527)

2. Choose the appropriate server license

The license or combination of licenses for servers depends on several factors. Companies that use SharePoint Foundation 2010 have to be properly licensed for Windows Server 2008.

3. Leverage multiple authentication mechanisms

Do not try to standardize all users to a single authentication mechanism. Use the authentication mechanism that gives the best experience for each user audience. For example, using SAML claims-based authentication for partners enables these users to use one set of credentials. Take advantage of the flexibility that SharePoint Foundation provides for configuring authentication, rather than deploying a single authentication mechanism to everyone in an organization.

For an example of a design that utilizes multiple authentication mechanisms, see Design sample: collaboration sites (SharePoint Foundation 2010).

4. Maintain consistency in user authentication for users

Ensure that users can use the same account and credentials to log on to sites whether they are inside or outside the internal network. This is important because if users connect to sites through two different authentication providers, SharePoint Foundation creates two different accounts and profiles for each user.

If you use Windows authentication internally, there are at least two options to ensure that users can log on with the same account internally and externally:

  • Use forms-based authentication on the firewall or gateway product to collect Windows credentials that are forwarded to the SharePoint farm. This works in environments that use classic-mode authentication in which forms-based authentication for SharePoint sites is not supported.

  • Using Secure Sockets Layer (SSL) to implement only one URL that can be used both internally and externally. In other words, employees use the same zone that is configured for SSL regardless of where they are located.

5. Configure zones identically across Web applications

In an extranet environment, the design of zones is critical. Ensure that the configuration of zones meets the following requirements:

  • Configure zones across multiple Web applications to mirror each other. The configuration of authentication, zones, and users who are assigned to zones should be the same. However, the policies that are associated with zones can differ across Web applications. For example, ensure that the intranet zone is used for the same employees across all Web applications. In other words, do not configure the intranet zone for internal employees in one Web application and remote employees in another Web application.

  • Configure alternate access mappings appropriately and accurately for each zone and each resource. Alternate access mappings are automatically created when you create the zone. However, SharePoint Foundation can be configured to crawl content in external resources, such as a file share. You must use alternate access mappings to manually create links for each zone to these external resources.

6. Take advantage of a reverse proxy server

Protect your environment from direct user requests by using a reverse proxy server, where request inspection rules can be applied to each request. A reverse proxy can prevent information disclosure about the configuration of an internal network, and it can be used to securely terminate client SSL sessions to avoid SSL overhead on the Web servers.

Forefront Unified Access Gateway (UAG) is a reverse-proxy server that provides many capabilities when you combine it with SharePoint Foundation in extranet environments. For more information, see the following resources:

  • SharePoint publishing solution guide

  • Why enable SharePoint extranet access with Forefront UAG?

7. Configure cross-firewall access and settings for mobile devices

A cross-firewall access zone is used to generate external URLS for mobile alert messages. It also enables users to click the E-mail a link button on the ribbon to send an externally accessible URL. Some configuration is necessary to ensure that SharePoint sites are accessible for mobile devices, such as Windows Phone 7, when the devices are used outside the corporate firewall.

For more information, see the following articles:

  • Configure external access for mobile devices (SharePoint Foundation 2010)

  • Plan for mobile devices (SharePoint Foundation 2010)

8. Configure the People Picker for multiple domains

Because extranet environments can span multiple domains, be sure to configure the People Picker to return users, groups, and claims from the intended domains.

For more information, see the following resources:

  • Using People Picker with multiple forests or domains

  • Enable cross-forest or cross-domain queries when using a one-way trust

9. Configure antivirus settings

SharePoint Foundation includes an antivirus scanner that you can configure by using either Central Administration or by using the stsadm command-line tool.

10. Configure DNS for split back-to-back topologies

If Web servers are split between the internal network and the perimeter network, ensure that DNS is configured with the appropriate records in each network zone to direct traffic to the intended Web servers.

For more information about configuring DNS, see "Zones and URLs" in Design sample: collaboration sites (SharePoint Foundation 2010).

The SharePoint Server 2010 Content Publishing team thanks the following contributors to this article:

  • Ali Mazaheri, Microsoft Consulting Services

  • Bryan Porter, Microsoft Consulting Services

  • Steve Walker, Microsoft SharePoint Customer Engineering

  • Tajeshwar Singh, Microsoft Consulting Services


Best practices for virtualization (SharePoint Foundation 2010)
See Also

Published: June 16, 2011

Microsoft SharePoint Foundation 2010 is fully supported when you deploy it in a virtual environment that is supported by Windows Server 2008 or by Windows Server 2008 Hyper-V technology. SharePoint Foundation 2010 is also supported for virtualization technologies that are accredited by the Server Virtualization Validation Program (http://go.microsoft.com/fwlink/p/?LinkId=125649) environment.

This article is one of a series of Best Practice articles for Microsoft SharePoint Foundation. This article describes best practices for SharePoint Foundation 2010 virtualization. For more articles in the series, see Best practices (SharePoint Foundation 2010) . For additional information and resources regarding Best Practices for SharePoint Foundation 2010, see the Best Practices Resource Center (http://go.microsoft.com/fwlink/?LinkID=125981).

The best practices in this article are ordered based on the sequence in which they would apply as you move from creating a virtual machine to deploying SharePoint Foundation.

1. Use hardware-assisted virtualization

If the host computer processor supports hardware-assisted virtualization (HAV), enable this option. Hardware-assisted virtualization helps to improve performance of virtualization software and application response times. Depending on workload, hardware-assisted virtualization can provide a 5% or better gain in throughput. You can use the Microsoft Hardware-assisted Virtualization Detection Tool (http://go.microsoft.com/fwlink/p/?LinkId=219550) to determine if a computer processor supports hardware-assisted virtualization and whether this setting is enabled.

Hardware-assisted virtualization is provided by the Intel Virtualization Technology (Intel VT) processor family and the AMD Virtualization (AMD-V) processor family.

2. Enable hyper-threading on processors that support this technology

Hyper-threading is a technology that is available with processors that support symmetric multithreading (SMT). This technology provides two threads for each processor core. The net effect is a doubling of logical processors for each core.

Performance tests on an 8-core server with hyper-threading enabled showed that throughput increased, on average, by 16% on a workload that is not specific to Microsoft SharePoint Foundation 2010.

For more information, see Requirements and Limits for Virtual Machines and Hyper-V in Windows Server 2008 R2.

3. Configure Non-Uniform Memory Access correctly

Non-uniform memory access (NUMA) is a computer memory design that is used in multiprocessors to improve performance by reducing memory access latency and increasing memory bandwidth. For more information, see Understanding Non-uniform Memory Access (http://go.microsoft.com/fwlink/p/?LinkID=164492) and Inside Windows Server 2008 Kernel Changes (http://go.microsoft.com/fwlink/p/?LinkId=219551).

However, incorrectly sized NUMA boundaries can reduce, instead of increase throughput. Ensure that virtual machines on a host server that supports non-uniform memory access are allocated the correct amount of memory in relation to the NUMA boundary. The NUMA boundary is calculated by dividing the memory on the host server by the number of processor sockets. Performance is reduced by approximately 8% when the virtual machine memory allocation is larger than the NUMA boundary.

4. Configure the Hyper-V host for optimal performance

Use the following recommendations to configure the host server for optimal performance.

  • Dedicate the host computer to Hyper-V. Do not run additional applications on the host.

  • Install and configure only the required roles and services.

  • Do not store virtual machine data on system drives. The root partition should only contain the operating system and Hyper-V.

  • Use more than one network adapter on the physical server and dedicate one adapter to Hyper-V Server administration. Do not bind any virtual networks to this adapter. If virtual machines are sharing a network adapter, monitor latency and throughput to ensure that the adapter is not oversubscribed.

5. Maintain version compatibility for integration services

For optimal performance, ensure that the management operating system and guest operating system run the same version of integration services. To upgrade the integration services on a guest operating system to a newer version, perform the upgrade when the virtual machine is running on the version of Hyper-V that includes the version of integration services to which you want to upgrade. For more information, see Version Compatibility for Integration Services.

Do not deploy virtual machines that support integration services together with virtual machines that cannot use integration services on the same host.

6. Determine storage options that are based on virtual machine roles and workloads

Hyper-V supports two storage options for virtual machines: attached physical storage (also known as pass-through disks) and virtual hard disks (VHDs).

Pass-through disks can be local storage or a storage area network (SAN). Pass-through disks are marginally faster than VHDs. When you use physical storage, you lose the benefits of VHDs, such as portability, snapshots, and thin provisioning.

Note:

As a best practice, snapshots are not recommended for a production environment.

We recommend that you use pass-through disks only when a virtual machine's storage requirement exceeds 2 Terabytes or when the application on the virtual machine is I/O bound. A good example is a SQL Server database server versus a front-end web server.

Of the three options for virtual hard disks (fixed size, dynamically expanding, and differencing), we recommend fixed-size disks. Fixed-size disks provide the best overall performance and reduce the risk of exceeding physical storage space when a dynamically expanding VHD is not carefully monitored.

Note:

Only install the base operating system on the IDE boot drive. Use virtual SCSI hard drives for additional programs and data storage. A virtual machine that is configured to use a SCSI controller lets you add hard drives without shutting down the VM.

For more information about virtual machine storage, see:

  • Planning for Disks and Storage

  • Virtual Hard Disk Performance (http://go.microsoft.com/fwlink/p/?LinkID=186519)

7. Configure general virtual machine settings for performance and stability

Configure general and specific virtual machine settings for best performance and stability. We recommend the following configurations:

  • Start up

    If the virtual machines are configured for automatic start, use a time delay to reduce resource contention on the host.

  • Shut down

    Do not save state before shutdown—let the virtual machine shutdown exactly like a physical computer.

  • Clock synchronization

    Do not synchronize virtual machine clocks to their host. Many SharePoint Foundation 2010 features use timer jobs. Any latency in time synchronization between a virtual machine and the host affects SharePoint reliability.

8. Do not use snapshots in a production environment

Virtual machine snapshots are file-based snapshots of the state, disk data, and configuration of a virtual machine at a specific point in time. Do not use snapshots in a production environment for the following reasons:

  • Microsoft SharePoint Foundation uses timer jobs extensively; snapshot latency adversely affects time-sensitive operations and can result in data corruption or data loss.

    Important:

    Do not configure a virtual machine to save state during shutdown as this is also affected by latency.

  • Snapshots reduce virtual machine performance and increase physical storage requirements.

For more information, see Hyper-V Virtual Machine Snapshots: FAQ.

9. Design the virtual topology for optimal performance

Design the virtual SharePoint Foundation farm topology across hosts to maximize overall throughput. We recommend the following:

  • Maximize overall throughput by mixing farm server roles on each host. For example, you can reduce disk contention by mixing front-end web servers with application servers because they usually do not write to disk at the same time.

  • Monitor the performance of the front-end web servers on a single host to ensure that scaling out the virtual machines does not result in diminishing or negative performance returns. If this is the case, scale out by deploying the additional virtual machines on a different host.

For more information, see Hyper-V performance tests (SharePoint Foundation 2010).

10. Do not overload the Hyper-V host

Avoid overloading the Hyper-V host computer by using careful planning to ensure that the following key host resources are not over-subscribed.

  • Processor

    The ratio of virtual processors to logical processors is one of the determining elements in measuring processor load. When the ratio of virtual processors to logical processors is not 1:1, the CPU is said to be oversubscribed, which has a negative effect on performance.

  • Memory

    The root and child partitions require adequate memory to operate effectively. The root partition must have sufficient memory (a minimum of 512 MB) to provide services such as I/O virtualization, snapshot, and management to support the child partitions. A good standard for the memory overhead of each VM is 32 MB for the first 1 GB of virtual RAM plus another 8 MB for each additional GB of virtual RAM. This should be factored in the calculations of how many VMs to host on a physical server. The memory overhead varies depending on the actual load and amount of memory that is assigned to each VM.

Carefully plan virtual machine configuration and deployment based on the following:

  • Overhead

    Allow for the processing and physical memory requirements of the operating system and Hyper-V.

  • High availability

    In a live migration environment, any host that is part of the cluster must have the capacity to host additional virtual machines.

  • Scale up or scale out

    It may be necessary to increase the resources for a virtual machine or add virtual machines to address performance issues on SharePoint Foundation farm servers.

11. Do not run resource intensive jobs on the Hyper-V host and virtual machines at the same time

To ensure consistent and optimal performance, carefully monitor the Hyper-V host and virtual machines to ensure that resource intensive jobs are not run at the same time. For example, if you run a backup program on the physical computer and the virtual machines at the same time, there will be resource contention.

Acknowledgements

The Microsoft SharePoint Foundation 2010 Content Publishing team thanks the following Microsoft colleagues for contributions to this article:

  • Bill Baer, Senior Technical Product Manager, SharePoint

  • Luca Bandinelli, Senior Program Manager, SharePoint Customer Advisory/Engineering Excellence

  • Bryan Porter, Senior Consultant, Microsoft Consulting Services

  • Steve Peschka, Senior Principal Service Engineer, SharePoint Online

  • Craig Schwandt, Principal Consultant, Microsoft Consulting Services

See Also

Other Resources

Best Practices Analyzer for Hyper-V
KB977238: Update for the Best Practices Analyzer for Hyper-V for Windows Server 2008 R2 x64 Edition (http://go.microsoft.com/fwlink/p/?LinkId=219554)


Backup and recovery best practices (SharePoint Foundation 2010)

Published: October 14, 2010

This article describes best practices that you can use to help ensure that backup and recovery operations in Microsoft SharePoint Foundation 2010 are successful and that the environment is protected against data loss or continuity gaps. The article includes best practices for performance, quality assurance, security, and operational excellence.

In this article:

  • Performance best practices

  • Quality assurance best practices

  • Procedural best practices

Performance best practices

Backup and restore operations can consume server resources and limit server performance while the operations are running. By following these best practices, you can reduce resource usage and increase the performance of servers and the backup or restore operation.

Minimize latency between SQL Server and the backup location

In general, it is best to use a local disk on the database server, not a network drive, for backups, and then copy the data later to a shared folder on the network. Network drives with 1 millisecond or less latency between them and the database server will perform well.

To avoid I/O bottlenecks, perform the main backup to a separate disk from the disk running Microsoft SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2.

By design, most backup jobs consume all available I/O resources to complete the job. Therefore, you might see disk queuing, which can result in greater than usual I/O request latency. This is typical and should not be considered a problem.

Avoid processing conflicts

Do not run backup jobs during times when users require access to the system. Consider staggering backups so that not all databases are backed up at the same time.

Keep databases small for faster recovery times

Keep databases small to speed both backup and recovery. You can do this by using multiple content databases for a Web application instead of one large content database.

Use incremental backups for large databases

Use incremental backups for large database such as those available with DPM 2010. Incremental backups can be restored faster and more efficiently than full backups for larger databases. For more information about backup types, see Backup Overview (SQL Server) (http://go.microsoft.com/fwlink/p/?LinkId=203863).

Use compression during backup

In some circumstances, you can use compression to improve backup size (30% decrease) and times (25% decrease). Backup compression has been in introduced in SQL Server 2008 Enterprise. For more information about how backup compression affects performance in SQL Server, see Backup Compression (SQL Server) (http://go.microsoft.com/fwlink/p/?LinkID=129381).

Follow SQL Server backup and restore optimization recommendations

If you are using SQL Server backups, use a combination of full, differential, and transaction log backups (for the full or bulk-logged recovery model) to minimize recovery time. Differential database backups are usually faster to create than full database backups and reduce the amount of transaction log required to recover the database.

If you are using the full recovery model, we recommend that you periodically truncate the transaction log files to avoid maintenance issues.

For detailed recommendations about how to optimize SQL Server backup and restore performance, see Optimizing Backup and Restore Performance in SQL Server (http://go.microsoft.com/fwlink/p/?LinkId=126630).

Use RAID 10 if you are going to use RAID

Carefully consider whether to use redundant array of independent disks (RAID) on the disk backup device. For example, RAID 5 has low write performance, approximately the same speed as for a single disk. (This is because RAID 5 has to maintain parity information.) Using RAID 10 for a backup device may provide faster backups. For more information about how to use RAID with backups, see Configure RAID for maximum SQL Server I/O throughput (http://go.microsoft.com/fwlink/p/?LinkId=126632).

Configure SharePoint settings for better backup or restore performance

You can configure settings in both Central Administration and Windows PowerShell to increase backup or restore efficiency and performance.

If you are using the Export-SPWeb Windows PowerShell cmdlet, you can use the NoFileCompression parameter. By default, SharePoint Foundation 2010 uses file compression while exporting Web applications, site collection, lists, or document libraries. You can use this parameter to suppress file compression while exporting and importing. File compression can use up to 30% more resources, but the exported file will use approximately 25% less disk space. If you use the NoFileCompression parameter when exporting, you must also use it when you import the same content.

You can also use the NoLogFile parameter. By default, SharePoint Foundation 2010 always creates a log file when you export content. You can use this parameter to suppress log file creation to save resources. However, we recommend that you always create logs. This is because logs can be used in troubleshooting. Moreover, log creation does not use many resources.

Note:

These settings are not available through Central Administration.

If you are using the Backup-SPFarm cmdlet, you can use the BackupThreads parameter to specify how many threads SharePoint Foundation 2010 will use during the backup process. The more threads you specify, the more resources that backup operation will take, but the faster that it will finish, if sufficient resources are available. However, each thread is reported individually in the log files, so using fewer threads makes interpreting the log files easier. By default, three threads are used. The maximum number of threads available is 10.

Note:

This setting is also available through Central Administration on the Default Backup and Restore Settings page in the Backup and Restore section.

Consider site collection size when determining the tools to use

If the business requires site collection backups in addition to farm-level or database-level backups, select the tools that you will use based on the site collection size.

  • Less than 15 gigabytes (GB): Use the Windows PowerShell command Backup-SPSite. For more information, see Back up a site collection (SharePoint Foundation 2010).

  • 15-100 GB: Use a SharePoint Products and Technologies tool, a SQL Server tool, or other database backup tool to protect the content database that contains the site collection. For more information, see Back up a site collection (SharePoint Foundation 2010).

  • Larger than 100 GB: Use a differential backup solution, such as Microsoft SQL Server 2005 or DPM 2010, instead of the built-in backup and recovery tools.

Quality assurance best practices

You can follow these best practices to help ensure the quality of the backups of the farm environment and reduce the chances of data loss.

Ensure you have adequate storage space

Be certain that the system has adequate disk space to accommodate the backup.

Routinely test backup quality

Routinely test backups and validate their consistency. Run practice recovery operations to validate the contents of the backup and to ensure that you can restore the entire environment. For geographically dispersed environments, prepare for disaster recovery by setting up a remote farm. Then you can restore the environment by using the database attach command to upload a copy of the database to the remote farm and redirect users. Periodically perform a trial data recovery operation to verify that the files are correctly backed up. A trial restoration can expose hardware problems that do not show up with software verifications.

Back up ULS trace logs

The SharePoint Foundation 2010 tools do not back up the ULS trace logs. Data in ULS trace logs can be useful for performance analysis, troubleshooting, monitoring compliance with service-level agreements, and legal, regulatory, or business reasons. Therefore, protect this data as part of the routine maintenance. For more information about backing up the ULS logs, see Back up or archive logs (SharePoint Foundation 2010).

Store a copy of backup files off-site

To safeguard against loss from a catastrophic event, such as a fire or earthquake, maintain duplicate copies of backups in a separate location from the servers. Doing so can help protect you against the loss of critical data. As a best practice, keep three copies of the backup media, and keep at least one copy offsite in a controlled environment. This should include all backup and recovery materials, documents, database and transaction log backups, and usage and trace log backups.

Procedural best practices

You can use these procedural best practices to help plan and perform backup and restore operations with better documentation, more ease, and greater assurance.

Use FQDN server names

When referring to servers in a different domain, always use fully qualified domain names (FQDN).

Keep accurate records

When you deploy SharePoint Foundation 2010, record the accounts that you create, and the computer names, passwords, and setup options that you choose. Keep this information in a safe place.

Have a recovery environment ready

Prepare for restore testing and disaster recovery by setting up a remote farm. Then you can restore the environment by using the database attach command to upload a copy of the database to the remote farm and redirect users. Similarly, you can set up a standby environment running the same version of software as the production environment so that you can restore the databases and recover documents quickly.

Schedule backup operations

If you want to schedule backups, you can use the Windows Task Scheduler to run them by using a Windows PowerShell script file (*.ps1).

Use the SQL FILESTREAM provider with BLOB storage

If you are using BLOB storage using the SQL FILESTREAM provider and you back up the content database with that Remote BLOB Store (RBS) defined, both the RBS and the content database will be backed up and restored when you use SharePoint tools or SQL Server tools. We do not recommend that you use RBS with other restore methods.


Server and server farm administration (SharePoint Foundation 2010)

This section describes how to configure administration settings for servers and server farms within a Microsoft SharePoint Foundation 2010 environment.

In this section:

  • Best practices for extranet environments (SharePoint Foundation 2010)

  • Best practices for virtualization (SharePoint Foundation 2010)

  • Backup and recovery (SharePoint Foundation 2010)

  • Database management (SharePoint Foundation 2010)

  • Security and permissions (SharePoint Foundation 2010)

  • Service application and service management (SharePoint Foundation 2010)

  • Web applications management (SharePoint Foundation 2010)

  • Health monitoring (SharePoint Foundation 2010)

  • Manage farm administration settings (SharePoint Foundation 2010)

  • Farm topology management (SharePoint Foundation 2010)

  • Availability configuration (SharePoint Foundation 2010)

  • Track or block SharePoint Foundation 2010 installations


Backup and recovery (SharePoint Foundation 2010)
See Also

The articles in this section are written to meet the requirements of information technology (IT) professionals who are responsible for the planning, design, deployment, and operations of backup and recovery solutions. These solutions might be in enterprise, corporate, or branch-office environments. The IT professionals who are responsible for backup and recovery solutions are expected to have an understanding of the technical details that are contained in this section. However, service-level expertise is not required to understand the enterprise-level discussions and decisions.

A backup is a copy of data that is used to restore and recover that data after a system failure. Backups allow you to restore data after a failure. Recovery allows you to quickly restore the farm if a problem arises. You can recover the entire farm or one or more components of the farm from a backup.

In this section:

  • Prepare to back up and recover (SharePoint Foundation 2010)

  • Backup and recovery best practices (SharePoint Foundation 2010)

  • Configuring permissions for backup and recovery (SharePoint Foundation 2010)

  • Backup (SharePoint Foundation 2010)

  • Recovery (SharePoint Foundation 2010)

  • Restore pre-SP1 backups to an SP1 farm (SharePoint Foundation 2010)

See Also

Other Resources

Resource Center: Operations and Manageability for SharePoint Foundation 2010


Prepare to back up and recover (SharePoint Foundation 2010)
See Also

Published: July 8, 2010

It is important to ensure that you have backed up and can recover the data that you need should a failure occur. Consider the information, procedures, and precautions that are described in this article before you back up and restore the environment. This article discusses restrictions and requirements for backup and recovery and how to create a shared folder on the network that can receive backed-up data.

Important:

The SharePoint 2010 Service Pack 1 (SP1) upgrade process alters the schema of some of the farm databases and all content databases. Because of these changes, you might need to take additional steps to restore a backup that you made before the farm was upgraded to SP1 to the farm after it is upgraded to SP1. For more information about doing this, see Restore pre-SP1 backups to an SP1 farm (SharePoint Foundation 2010).

In this article:

  • Restrictions

  • Requirements

  • How to create a shared folder

Restrictions

There are some restrictions in what can be backed up or restored. For more information about backup and recovery architecture and about what can or cannot be backed up and restored, see Backup and recovery overview (SharePoint Foundation 2010).

You cannot use a backup made from one version to restore to another version. To do this, you must use the upgrade process. You cannot restore to a farm with a lower update level than the update level of the farm that you backed up. The destination farm must have the same or newer update level. For information about how to upgrade, see Upgrading to SharePoint Foundation 2010.

If you perform a backup while any task that creates or deletes databases is running, these changes might not be included in the backup.

Do not modify the spbackup.xml file. This file is used by SharePoint Foundation 2010 and changing it can make the backups unusable.

Requirements

Before you back up data, you must create a shared folder in which the data will be stored. For best performance, you should create this folder on the database server. If you want to archive the backups to another server, you can copy the whole backup folder to that server after backup is complete. Be sure to copy and move the whole backup folder and not the individual backup folders under this folder.

The SQL Server VSS Writer service, which is available with Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, and SQL Server 2005 with SP3 and Cumulative Update 3 database software, must be started for the SharePoint 2010 VSS Writer service to work correctly. By default, the SharePoint 2010 VSS Writer service is not automatically started.

You must make sure that the SharePoint 2010 Administration service is started on all farm servers before you perform a backup. By default, this service is not started on stand-alone installations.

You must ensure that the user accounts that you want to perform a backup have access to the shared backup folder.

If you are backing up by using Central Administration, the database server's SQL service account, the Timer service account, and the Central Administration application pool identity account must have Full Control permissions to the backup locations.

The database server and farm server that you want to back up must be able to connect to one another.

If you have changed the farm account, before you back up, you must grant the new account the correct permissions to the shared folder that will contain the backup data.

If you are using SQL Server with Transparent Data Encryption (TDE), and you are backing up your environment by using either SharePoint tools or SQL Server tools, the TDE encryption key is not backed up or restored. You must manually back up the key. When restoring, you must manually restore the key before you restore the data. For more information, see Understanding Transparent Data Encryption (TDE) (http://go.microsoft.com/fwlink/p/?LinkId=196394&clcid=0x409).

How to create a shared folder

Use this procedure to create a shared folder on the network that can receive and hold backed-up data. You can also use this shared folder when you restore data. If you already have a shared folder that serves this purpose, you do not have to perform this procedure. By performing the following procedure, you ensure that you can access the shared folder from the computer that runs Microsoft SQL Server database software and from the computer that hosts the SharePoint Central Administration Web site.

If you are backing up by using Central Administration and SQL Server is not running on the same server, the backup folder must be on the same network or on a database server as SharePoint Foundation 2010. If you have a stand-alone installation where both SQL Server and SharePoint Foundation 2010 are running on the same server, you can use a local drive path as the backup folder location. If you are using SQL Server to directly back up a database, such as by using SQL Server Management Studio, the backup folder can be either local or on the network. For best performance, we recommend that you back up to a local folder on the database server and then move or copy the backup files to a network folder.

To create a shared folder

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the computer on which you want to create the shared folder.

  2. If you create the shared folder on a computer other than the one running SQL Server, ensure that the service account for SQL Server (MSSQLSERVER) is using a domain user account and that it has Full Control permissions on the shared folder.

  3. On the server on which you want to store the backup data, create a shared folder.

  4. On the Sharing tab of the Properties dialog box, click Share, and then in the File Sharing dialog box, add the following accounts and assign them the Co-Owner role:

    • SQL Server service account (MSSQLSERVER)

    • The SharePoint Central Administration application pool identity account

    • The SharePoint 2010 Timer service account (if you are using SharePoint Foundation 2010 to perform backups)

See Also

Other Resources

Shared Folders


Configuring permissions for backup and recovery (SharePoint Foundation 2010)
See Also

Before backing up or restoring Microsoft SharePoint Foundation 2010, you must ensure that the timer service account, SQL Server service account, and users running the backup or restore operations have the correct permissions or are members of the correct Windows security groups or SharePoint groups. These permissions and group memberships must be configured initially. Subsequently, they must be updated when new farm components are added to the environment and if you want to add users who will perform backup and restore operations.

In this topic:

  • Permissions for the SPTimerV4 timer service and SQL Server account

  • Group memberships required to run backup and restore operations in Central Administration

  • Setting permissions for running backup and restore operations by using Windows PowerShell

Permissions for the SPTimerV4 timer service and SQL Server account

The Windows SharePoint Services Timer V4 (SPTimerV4) and the SQL Server service account in SharePoint Foundation 2010 perform backup and restore operations on behalf of the user. These service accounts require Full Control permissions on any backup folders.

Group memberships required to run backup and restore operations in Central Administration

You must ensure that all user accounts that will be backing up or restoring your farm and farm components by using Central Administration have the group memberships that are described in the following table.

Required group memberships

Farm component | Member of Administrators group on the local computer | Member of Farm Administrators SharePoint group
Farm | Yes | No
Content Database | Yes | No
Site Collection | No | Yes
Site, list, document library | No | Yes

Setting permissions for running backup and restore operations by using Windows PowerShell

You must ensure that all user accounts that will be backing up or restoring your farm and farm components by using Windows PowerShell are added to the SharePoint_Shell_Access role for a specified database and have the permissions described in the table later in this section.

You can run the Add-SPShellAdmin cmdlet to add a user account to this role. You must run the command for each user account. Moreover, you must run the command for all databases to which you want to grant access.

Note:

You only need to grant a user account access to back up and restore a specific farm component one time. You will have to perform this task again only when new farm components are added to your environment or when you want to add users to perform backup and restore operations.

To add a user to or remove a user from the SharePoint_Shell_Access role 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. At the Windows PowerShell command prompt (that is, PS C:\>), type the following command, and then press ENTER:

    Add-SPShellAdmin -Username <User account> -Database <Database ID>

    To add a user account to all the databases in the farm, type the following command, and then press ENTER:

    ForEach ($db in Get-SPDatabase) {Add-SPShellAdmin -Username <User account> -Database $db}

    To remove a user account from all the databases in the farm, type the following command, and then press ENTER:

    ForEach ($db in Get-SPDatabase) {Remove-SPShellAdmin -Username <User account> -Database $db}

    To view the user accounts currently added to the databases in the farm, type the following command, and then press ENTER:

    ForEach ($db in Get-SPDatabase) {Get-SPShellAdmin -Database $db}

For more information, see Add-SPShellAdmin.

You might also have to grant additional permissions to the users running the backup or restore operation by using Windows PowerShell. The following table shows the permissions that are required.

Required permissions for Windows PowerShell

Farm component | Member of Administrators group on the local computer | Member of Farm Administrators SharePoint group | Full Control on backup folder
Farm | Yes | No | Yes
Content database | Yes | No | Yes
Site collection | No | Yes | Yes
Site, list, document library | Yes | No | Yes

See Also

Other Resources

Resource Center: Business Continuity Management for SharePoint Foundation 2010


Backup (SharePoint Foundation 2010)
See Also

The articles in this section are written to meet the requirements of information technology (IT) professionals who are responsible for the planning, design, deployment, and operations of backup and recovery solutions. These solutions might be in enterprise, corporate, or branch office environments. The IT professionals who are responsible for backup and recovery solutions are expected to have an understanding of the technical details that are contained in this section.

A backup is a copy of data that is used to restore and recover that data after a system failure. Backups allow you to restore data after a failure. If you make the appropriate backups, you can recover from many system failures, including the following:

  • Media failure

  • User errors (such as deleting a file by mistake)

  • Hardware failures (such as a damaged hard disk or permanent loss of a server)

  • Natural disasters

Additionally, it is useful to keep backups of data for routine purposes. Those purposes include copying a database from one server to another, setting up database mirroring, and archiving to comply with regulatory requirements.

Back up all or part of a farm

The following tasks for backup and recovery are performed on the entire farm, farm databases, sites, subsites, or files:

  • Back up a farm (SharePoint Foundation 2010)

    This article describes the procedures that you can use to back up the entire farm.

  • Back up a farm configuration (SharePoint Foundation 2010)

    This article describes the procedures that you can use to back up farm configuration settings.

  • Copy configuration settings from one farm to another (SharePoint Foundation 2010)

    This article describes the procedures that you can use to copy configuration settings from one farm to another, including how to back up and recover a farm without the content databases, how to back up and recover configurations only, and how to create a deployment script.

  • Back up a Web application (SharePoint Foundation 2010)

    This article describes the procedures that you can use to back up a Web application that is associated with the farm, including configuration and content databases.

  • Back up a service application (SharePoint Foundation 2010)

    This article describes the procedures that you can use to back up a service application that is associated with the farm, including configuration and content databases.

  • Back up a site collection (SharePoint Foundation 2010)

    This article describes the procedures that you can use to back up a site collection that is associated with the farm.

  • Back up a content database (SharePoint Foundation 2010)

    This article describes the procedures that you can use to back up a content database that is associated with the farm.

  • Back up databases to snapshots (SharePoint Foundation 2010)

    This article describes the procedures that you can use to back up a content database that is associated with the farm by saving the database to a snapshot.

  • Back up customizations (SharePoint Foundation 2010)

    This article describes the procedures that you can use to back up customizations that are associated with the farm.

  • Export a site, list, or document library (SharePoint Foundation 2010)

    This article describes the procedures that you can use to export a list, site, or document library that is associated with the farm. You can then import the items into another farm or move them to another place in this farm.

  • Back up or archive logs (SharePoint Foundation 2010)

    This article describes the procedures that you can use to back up or archive log files that are associated with the farm.

See Also

Concepts

Recovery (SharePoint Foundation 2010)


Back up a farm (SharePoint Foundation 2010)
See Also

This topic describes how to back up a whole server farm.

Procedures in this task:

  • Use Windows PowerShell to back up a farm

  • Use Central Administration to back up a farm

  • Use SQL Server tools to back up a farm

For information about which tool to use for backups, see Plan for backup and recovery (SharePoint Foundation 2010).

We recommend that you regularly back up the complete farm by backing up both the configuration and content. Regularly backing up the farm reduces the possibility of data losses that might occur from hardware failures, power outages, or other problems. It is a simple process and helps to ensure that all the farm data and configurations are available for recovery, if that is required.

Considerations when backing up a farm

Consider the following when you prepare to back up a farm:

  • Performing a backup does not affect the state of the farm. However, it does require resources and might slightly affect farm performance when the backup is running. You can avoid performance issues by backing up the farm during hours when farm use is lowest, such as outside office hours.

  • The farm backup process does not back up any certificates that you used to form trust relationships. Endure that you have copies of these certificates before you back up the farm. You must re-establish these trust relationships after restoring the farm.

  • Backing up the farm backs up the configuration and Central Administration content databases, but these cannot be restored using Microsoft SharePoint Foundation 2010 tools. For more information about backing up and restoring all the farm databases, see Move all databases (SharePoint Foundation 2010).

  • When you back up a farm that contains a Web application that is configured to use forms-based authentication, you must also use a file backup system to protect the Web.config files because the Web.config files have been updated manually to register the membership and role providers, and manual changes to the Web.config files are not backed up. Similarly, Web.config files are not restored when you restore a Web application. After recovery, you must update the Web.config files and redeploy the providers. For more information, see Plan authentication methods (SharePoint Foundation 2010) and Configure claims authentication (SharePoint Foundation 2010).

  • SharePoint Foundation 2010 backup backs up the Business Data Connectivity service external content type definitions but does not back up the data source itself. To protect the data, you should back up the data source when you back up the Business Data Connectivity service or the farm.

    If you restore the Business Data Connectivity service or the farm and then restore the data service to a different location, you must change the location information in the external content type definition. If you do not, the Business Data Connectivity service might not be able to locate the data source.

  • SharePoint Foundation 2010 backup backs up remote Binary Large Object (BLOB) stores but only if you are using the FILESTREAM remote BLOB store provider to put data in remote BLOB stores.

    If you are using another provider, you must manually back up the remote BLOB stores.

  • If you are using SQL Server with Transparent Data Encryption (TDE), and you are backing up your environment by using either SharePoint tools or SQL Server tools, the TDE encryption key in not backed up or restored. You must back up the key manually. When restoring, you must manually restore the key before restoring the data. For more information, see Understanding Transparent Data Encryption (TDE) (http://go.microsoft.com/fwlink/p/?LinkID=196394).

Task requirements

Before you begin, you must create a folder on the local computer or the network in which to store the backups. For better performance, we recommend that you back up to the local computer and then move the backup files to a network folder. For more information about how to create a backup folder, see Prepare to back up and recover (SharePoint Foundation 2010).

Use Windows PowerShell to back up a farm

You can use Windows PowerShell to back up the farm manually or as part of a script that can be run at scheduled intervals.

To back up a farm 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Backup-SPFarm -Directory <BackupFolder> -BackupMethod {Full | Differential} [-Verbose]

    Where <BackUpFolder> is the path of a folder on the local computer or the network in which you want to store the backups.

    Note:

    If you are backing up the farm for the first time, you must use the Full option. You must perform a full backup before you can perform a differential backup.

For more information, see Backup-SPFarm.

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.

Use Central Administration to back up a farm

You can use Central Administration to back up the farm.

To back up a farm by using Central Administration

  1. To perform this procedure, you must be a member of the Farm Administrators group on the computer that is running Central Administration.

  2. In Central Administration, on the Home page, in the Backup and Restore section, click Perform a backup.

  3. On the Perform a Backup — Step 1 of 2: Select Component to Back Up page, select the farm from the list of components, and then click Next.

  4. On the Start Backup — Step 2 of 2: Select Backup Options page, in the Backup Type section, select either Full or Differential.

    Note:

    If you are backing up the farm for the first time, you must use the Full option. You must perform a full backup before you can perform a differential backup.

  5. In the Back Up Only Configuration Settings section, click Back up content and configuration settings.

  6. In the Backup File Location section, type the UNC path of the backup folder, and then click Start Backup.

  7. You can view the general status of all backup jobs at the top of the Backup and Restore Status page in the Readiness section. You can view the status for the current backup job in the lower part of the page in the Backup section. The status page updates every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take several seconds for the backup to start.

    If you receive any errors, you can review them in the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Spbackup.log file at the UNC path that you specified in step 6.

Use SQL Server tools to back up a farm

If you want to back up the complete farm, you must use either Windows PowerShell or Central Administration. You cannot back up the complete farm by using the SQL Server tools because you cannot use the tools to back up the farm's configuration. However, you can back up all the databases that are associated with the farm.

To back up the databases associated with a farm by using SQL Server tools

  1. To use SQL Server tools to back up SharePoint Foundation 2010 databases, the account that is used to back up the databases must be a member of the SQL Server db_backupoperator fixed database role on the database server where each database is stored.

  2. Open SQL Server Management Studio and connect to the database server.

  3. In Object Explorer, expand Databases.

  4. Right-click the database that you want to back up, point to Tasks, and then click Back Up.

  5. In the Back Up Database dialog box, in the Source area, select the kind of backup that you want to perform from the Backup type list. For more information about which backup type to use, see Overview of Recovery Models (http://go.microsoft.com/fwlink/p/?LinkId=114396).

  6. In the Backup component area, click Database.

  7. Either use the default name provided or specify a name for the backup set in the Name text box.

  8. Specify the expiration date for the backup set. This date determines how long, or when, the backup set can be overwritten by any later backups that have the same name. By default, the backup set is set to never expire (0 days).

  9. In the Destination area, specify where you want to store the backup.

  10. Click OK to back up the database.

  11. Repeat steps 1-10 for each farm database.

Related content

Resource center | Business Continuity Management for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=201997)
IT Pro content | Restore a farm (SharePoint Foundation 2010) Restore a Web application (SharePoint Foundation 2010) Plan for backup and recovery (SharePoint Foundation 2010) Backup and recovery (SharePoint Foundation 2010)
Developer content | Data Protection and Recovery (http://go.microsoft.com/fwlink/p/?LinkID=199237)

See Also

Other Resources

Resource Center: Business Continuity Management for SharePoint Foundation 2010


Back up a farm configuration (SharePoint Foundation 2010)
See Also

This article describes how to back up the configuration of a server farm.

In earlier versions of Microsoft SharePoint Foundation, you could not back up or restore the configuration database. In Microsoft SharePoint Foundation 2010, you can perform the equivalent operation by backing up or restoring the configuration of the server farm.

We recommend that you regularly back up the complete farm by backing up both the configuration and content. However, you might want to perform configuration-only backups in test or development environments. Similarly, if you are using Microsoft SQL Server tools to back up the databases for the farm, you will want to back up the configuration. Regularly backing up the farm reduces the possibility of data losses that can occur from hardware failures, power outages, or other problems. It helps to ensure that all the farm data and configurations are available for recovery. For more information about what to back up, see Plan for backup and recovery (SharePoint Foundation 2010).

The configuration backup will extract and back up the configuration settings from a SharePoint Foundation 2010 configuration database. You can back up configuration from any configuration database that includes the configuration database for the current farm or another farm, or a configuration database that is not associated with any farm.

For information about which tool to use for backups, see Plan for backup and recovery (SharePoint Foundation 2010).

Procedures in this task:

  • Task requirements

  • Use Windows PowerShell to back up a farm configuration

Note:

You cannot use either SQL Server tools or Data Protection Manager to back up the farm configuration.

Task requirements

Before you begin, you must create a folder on the local computer or the network in which to store the backups. For better performance, we recommend that you back up to the local computer and then move the backup files to a network folder. For more information about how to create a backup folder, see Prepare to back up and recover (SharePoint Foundation 2010).

Important:

Backing up the farm configuration will not back up the information you have to have to restore service applications. If you want to restore a service application, you must perform a configuration and content backup of the farm. For more information about backing up service applications, see Back up a service application (SharePoint Foundation 2010).

Use Windows PowerShell to back up a farm configuration

You can use Windows PowerShell to back up the configuration from any configuration database on the current farm, on another farm, or from a configuration database that is not associated with any farm. You can back up a farm configuration manually or as part of a script that can be run at scheduled intervals.

To back up the configuration from any configuration database 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. At the Windows PowerShell command prompt (that is, PS C:\>), type the following command, and then press ENTER:

    Copy Code
    Backup-SPConfigurationDatabase -Directory <BackupFolder> -DatabaseServer <DatabaseServerName> -DatabaseName <DatabaseName> -DatabaseCredentials <WindowsPowerShellCredentialObject> [-Verbose]

    Where:

    • <BackupFolder> is the path to the folder with the correct backup files.

    • <DatabaseServerName> is the name of the database server for the farm that you are backing up.

    • <DatabaseName> is the name of the farm configuration database.

    • If you are not logged on with an account with db_backupoperator fixed database role on the database server where the configuration database is stored, you must specify the value for DatabaseCredentials parameter.

For more information, see Backup-SPConfigurationDatabase.

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.

Use Central Administration to back up a farm configuration

You can use Central Administration to back up the configuration of the farm that Central Administration is running on. To back up the configuration of a remote farm, you must use the Central Administration Web site that is running on the remote farm. You cannot use Central Administration to back up an unattached configuration database.

To back up a farm configuration by using Central Administration

  1. Verify that the user account performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration Home page, in the Backup and Restore section, click Perform a backup.

  3. On the Perform a Backup — Step 1 of 2: Select Component to Back Up page, select the farm from the list of components, and then click Next.

    Note:

    You can back up the configuration for any service or application. However, common practice is to back up configuration at the farm level.

  4. On the Start Backup — Step 2 of 2: Select Backup Options page, in the Backup Type section, select Full.

  5. In the Backup Only Configuration Settings section, select the Backup only configuration settings option.

  6. In the Backup File Location section, type the Universal Naming Convention (UNC) path of the backup folder, and then click Start Backup.

  7. You can view the general status of all backup jobs at the top of the Backup and Restore Job Status page in the Readiness section. You can view the status for the current backup job in the lower part of the page in the Backup section. The status page updates every 30 seconds automatically. You can manually refresh the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take several seconds for the backup to start.

    If you receive any errors, you can review them in the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Spbackup.log file at the UNC path that you specified in step 5.

See Also

Concepts

Restore a farm configuration (SharePoint Foundation 2010)


Back up a Web application (SharePoint Foundation 2010)
See Also

This article describes how to back up a Web application. Regularly backing up a Web application reduces the possibility of data losses that might occur from hardware failures, power outages, or other problems. It is a simple process that can help to ensure that all the Web application-related data and configurations are available for recovery, if that is required. We recommend that Web application backups be created in addition to regular backups at the farm level.

This topic describes how to back up a single Web application.

In this topic:

  • Considerations when backing up a Web application

  • Task requirements

  • Use Windows PowerShell to back up a Web application

  • Use Central Administration to back up a Web application

  • Use SQL Server tools to back up a Web application

Considerations when backing up a Web application

Consider the following when you prepare to back up a Web application.

  • You can back up only one Web application at a time by using the procedures in this article. However, you can simultaneously back up all Web applications by backing up the entire farm.

  • Backing up a Web application does not affect the state of the farm. However, it does require resources and might slightly affect farm performance when the backup is running. You can avoid performance issues by backing up the Web application during hours when farm use is lowest, such as outside office hours.

  • If the Web application uses the object cache, you must manually configure two special user accounts for the Web application after you restore the Web application. For more information about the object cache and how to configure these user accounts, see Configure object cache user accounts.

  • When you back up a Web application, the Internet Information Services (IIS) settings and all content databases that are associated with the Web application are also backed up.

  • When you back up a Web application that is configured to use forms-based authentication, you must also use a file backup system to protect the Web.config files because the Web.config files have been updated manually to register the membership and role providers, and manual changes to the Web.config files are not backed up. Similarly, Web.config files are not restored when you restore a Web application. After recovery, you must update the Web.config files and redeploy the providers. For more information, see Plan authentication methods (SharePoint Foundation 2010) and Configure claims authentication (SharePoint Foundation 2010).

Task requirements

Before you begin, you must create a network folder in which to store the backups. Both the Windows SharePoint Services Timer V4 service account and the server farm user account must have Full Control permissions to this folder. For more information about how to create a backup folder, see Prepare to back up and recover (SharePoint Foundation 2010).

Use Windows PowerShell to back up a Web application

You can use Windows PowerShell to back up a Web application manually or as part of a script that can be run at scheduled intervals.

To back up a Web application by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. Additionally, the user account performing this procedure must be a member of the SQL Server db_backupoperator fixed database role on the database server where each database is stored.

  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:

    Copy Code
    Backup-SPFarm -Directory <BackupFolder> -BackupMethod {Full | Differential} -Item <WebApplicationName> [-Verbose]

    Where:

    • <BackupFolder> is the path of the folder you use for storing backup files.

    • <WebApplicationName> is the name of the Web application.

      Note:

      You must use the exact name for the Web application that you are backing up with Windows PowerShell. To find the Web application name in Central Administration click Manage web applications in the Application Management section.

    Note:

    If you are backing up the Web application for the first time, you must use the Full option. You must perform a full backup before you can perform a differential backup.

For more information, see Backup-SPFarm.

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.

Use Central Administration to back up a Web application

You can use Central Administration to back up a Web application.

To back up a Web application by using Central Administration

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. In Central Administration, on the Home page, in the Backup and Restore section, click Perform a backup.

  3. On the Perform a Backup — Step 1 of 2: Select Component to Back Up page, select the Web application from the list of components, and then click Next.

    Note:

    The Web application might consist of several components. You must select the top-level component.

  4. On the Start Backup — Step 2 of 2: Select Backup Options page, in the Backup Type section, select either Full or Differential.

    Note:

    If you are backing up the Web application for the first time, you must use the Full option. You must perform a full backup before you can perform a differential backup.

  5. In the Back Up Only Configuration Settings section, click Back up content and configuration settings.

  6. In the Backup File Location section, type the Universal Naming Convention (UNC) path of the backup folder, and then click Start Backup.

  7. You can view the general status of all backup jobs at the top of the Backup and Restore Job Status page in the Readiness section. You can view the status for the current backup job in the lower part of the page in the Backup section. The status page updates every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take several seconds for the backup to start.

    If you receive any errors, you can review them in the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Spbackup.log file at the UNC path that you specified in step 6.

Use SQL Server tools to back up a Web application

You cannot back up the complete Web application by using SQL Server tools. However, you can back up all the databases that are associated with the Web application. To back up the complete Web application, use either Windows PowerShell or Central Administration.

To back up a Web application by using SQL Server tools

  1. Verify that the user account that is used to back up the databases is a member of the SQL Server db_backupoperator fixed database role on the database server where each database is stored. Additionally, verify that the user account has Full Control permissions on the backup folder.

  2. Open SQL Server Management Studio and connect to the database server.

  3. In Object Explorer, expand Databases.

  4. Right-click the database that you want to back up, point to Tasks, and then click Back Up.

  5. In the Back Up Database dialog box, in the Source area, select the kind of backup that you want to perform from the Backup type list. For more information about which backup type to use, see Overview of Recovery Models (http://go.microsoft.com/fwlink/p/?LinkId=114396).

  6. In the Backup component area, click Database.

  7. Either use the default name provided or specify a name for the backup set in the Name text box.

  8. Specify the expiration date for the backup set. This date determines how long, or when, the backup set can be overwritten by any later backups that have the same name. By default, the backup set is set to never expire (0 days).

  9. In the Destination area, specify where you want to store the backup.

  10. Click OK to back up the database.

  11. Repeat steps 1-10 for each database that is associated with the Web application.

Related content

Resource center | Business Continuity Management for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkID=201997)
IT Pro content | Restore a Web application (SharePoint Foundation 2010) Back up a farm (SharePoint Foundation 2010). Plan for backup and recovery (SharePoint Foundation 2010) Backup and recovery (SharePoint Foundation 2010)
Developer content | Data Protection and Recovery (http://go.microsoft.com/fwlink/p/?LinkID=199237)

See Also

Other Resources

Resource Center: Business Continuity Management for SharePoint Foundation 2010


Back up a service application (SharePoint Foundation 2010)
See Also

We recommend that you regularly back up at the farm level. However, business or IT requirements might require that you back up a service application. Regularly backing up a service application reduces the possibility of data losses that might occur from hardware failures, power outages, or other problems. It is a simple process that helps to ensure that all the service application-related data and configurations are available for recovery, if that is required. You can back up one service application at a time, or you can back up all service applications at once. For information about what to back up and which tools to use, see Plan for backup and recovery (SharePoint Foundation 2010). For more information, see Back up a farm (SharePoint Foundation 2010).

Backing up a service application does not affect the state of the farm. However, it does require resources. Therefore, backing up a service application might affect farm performance while the backup is running. You can avoid performance issues by backing up the service application during hours when farm use is lowest.

Note:

SharePoint Foundation 2010 backup backs up remote Binary Large Object (BLOB) stores but only if you are using the FILESTREAM remote BLOB store provider to put data in remote BLOB stores.

If you are using another provider, you must manually back up the remote BLOB stores.

Procedures in this topic:

  • Use Windows PowerShell to back up a service application

  • Use Central Administration to back up a service application

Note:

You cannot use SQL Server tools or Data Protection Manager to back up a service application.

Task requirements

Before you begin, you must create a folder on the local computer or the network in which to store the backups. For better performance, we recommend that you back up to the local computer and then move the backup files to a network folder. For more information about how to create a backup folder, see Prepare to back up and recover (SharePoint Foundation 2010).

Note:

Microsoft SharePoint Foundation 2010 backup backs up the Business Data Connectivity service external content type definitions but does not back up the data source itself. To protect the data, you should back up the data source when you back up the Business Data Connectivity service or the farm.

If you back up the Business Data Connectivity service or the farm and then restore the data source to a different location, you must change the location information in the external content type definition. If you do not, the Business Data Connectivity service might not be able to locate the data source.

Use Windows PowerShell to back up a service application

You can use Windows PowerShell to back up one or more service applications manually or as part of a script that can be run at scheduled intervals.

To back up a service application 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Backup-SPFarm -Directory <BackupFolder> -BackupMethod {Full | Differential} -Item <ServiceApplicationName> [-Verbose]

    Where:

    • <BackupFolder> is the path of a folder on the local computer or on the network in which you want to store the backups.

    • <ServiceApplicationName> is the name of the service application that you want to back up.

      Note:

      You must use the exact name for the service application that you are backing up with Windows PowerShell. To find the service application name in Central Administration click Manage service applications in the Application Management section.

    To back up all the service applications, at the Windows PowerShell command prompt, type the following command:

    Copy Code
    Backup-SPFarm -Directory <BackupFolder> -BackupMethod {Full | Differential} -Item "Farm\Shared Service Applications" [-Verbose]
    Note:

    If you are backing up the service application for the first time, you must use the Full option. You must perform a full backup before you can perform a differential backup.

    Some service applications always require a full backup. For these service applications, even if you select the Differential option, the system performs a full backup.

For more information, see Backup-SPFarm.

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.

Use Central Administration to back up a service application

You can use Central Administration to back up a service application.

To back up a service application by using Central Administration

  1. Verify that the user account that performs this procedure is a member of the Farm Administrators group.

  2. In Central Administration, on the Home page, in the Backup and Restore section, click Perform a backup.

  3. On the Perform a Backup — Step 1 of 2: Select Component to Back Up page, select the service application from the list of components, and then click Next. To back up all the service applications, select the Shared Service Applications node.

    Note:

    The service application might consist of several components. You must select the top-level component.

  4. On the Start Backup — Step 2 of 2: Select Backup Options page, in the Backup Type section, select either Full or Differential.

    Note:

    If you are backing up the service application for the first time, you must use the Full option. You must perform a full backup before you can perform a differential backup.

    Some service applications always require a full backup. For these service applications, the system performs a full backup even if you select the Differential option.

  5. In the Backup File Location section, in the Backup location box, type the path of the backup folder, and then click Start Backup.

  6. You can view the general status of all backup jobs at the top of the Backup and Restore Job Status page in the Readiness section. You can view the status for the current backup job in the lower part of the page in the Backup section. The status page updates every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take several seconds for the backup to start.

    If you receive any errors, you can review them in the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Spbackup.log file at the UNC path that you specified in step 5.

See Also

Concepts

Restore a service application (SharePoint Foundation 2010)

Other Resources

Resource Center: Business Continuity Management for SharePoint Foundation 2010


Back up a site collection (SharePoint Foundation 2010)
See Also

This article describes how to back up an individual site collection. We recommend that you regularly back up the complete farm. However, IT practices might require that you also back up a site collection. For more information about what to back up, see Plan for backup and recovery (SharePoint Foundation 2010).

Note:

If the site collection's Lock status is set to Not locked or Adding content prevented, Microsoft SharePoint Foundation 2010 temporarily sets the site to Read-Only while the backup operation is occurring. SharePoint Foundation 2010 does this to reduce the possibilities of users changing the site collection while it is being backed up. After the backup is finished, the setting is changed back its normal status.

Performing a site collection backup might require resources and might slightly affect farm performance when the backup is running. You can help avoid performance issues by backing up the farm during hours when farm use is lowest, such as outside office hours.

Procedures in this task:

  • Use Windows PowerShell to back up a site collection

  • Use Central Administration to back up a site collection

Task requirements

Before you begin, you must create a folder on the local computer or the network in which to store the backups. For better performance, we recommend that you back up to the local computer and then move the backup files to a network folder. For more information about how to create a backup folder, see Prepare to back up and recover (SharePoint Foundation 2010).

Use Windows PowerShell to back up a site collection

You can use Windows PowerShell to back up a site collection manually or as part of a script that can be run at scheduled intervals.

To back up 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. At the Windows PowerShell command prompt type the following command:

    Copy Code
    Backup-SPSite -Identity <Site collection name> -Path <backup file> [-Force] [-NoSiteLock] [-UseSqlSnapshot] [-Verbose]
    Note:

    You must use the exact name for the site collection that you are backing up with Windows PowerShell. To find the site collection name in Central Administration click Application Management and in the Site Collections section, click View all site collections.

    If you want to overwrite a previously used backup file, use the Force parameter. You can use the NoSiteLock parameter to keep the read-only lock from being set on the site collection while it is being backed up. However, using this parameter can allow users to change the site collection while it is being backed up and might lead to possible data corruption during backup.

    If the database server is running an Enterprise Edition of Microsoft SQL Server, we recommend that you also use the UseSqlSnapshot parameter for more consistent backups. You can also export sites or lists from these snapshots.

    Important:

    Applies to environments that have not been updated to Service Pack 1 - When you perform a backup that uses the UseSqlSnapshot parameter, a backup will be completed successfully. However, you will see an error similar to the following:

    Backup-SPSite : Operation is not valid due to the current state of the object.

    At line:1 char:14+ Backup-SPSite <<<< http://site -Path + CategoryInfo : NotSpecified: (:) [Backup-SPSite], InvalidOperationException + FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.SharePoint.PowerShell.SPCmdletBackupSite\\yourpath

    Note:

    If the RBS provider that you are using does not support snapshots, you cannot use snapshots for content deployment or backup. For example, the SQL FILESTREAM provider does not support snapshots.

    For more information about using SQL snapshots, see Back up databases to snapshots (SharePoint Foundation 2010).

For more information, see Backup-SPSite.

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.

Use Central Administration to back up a site collection

You can use Central Administration to back up a site collection.

To back up a site collection by using Central Administration

  1. Verify that the user account performing this procedure is a member of the Farm Administrators group. Additionally, verify that the Windows SharePoint Services Timer V4 service has Full Control permissions on the backup folder.

  2. In Central Administration, on the Home page, in the Backup and Restore section, click Perform a site collection backup.

  3. On the Site collection backup page, select the site collection from the Site Collection list.

  4. Type the local path of the backup file in the Filename box.

    Note:

    If you want to reuse a file, select the Overwrite existing file check box.

  5. Click Start Backup.

  6. You can view the general status of all backup jobs at the top of the Granular Backup Job Status page in the Readiness section. You can view the status for the current backup job in the lower part of the page in the Site Collection Backup section. The status page updates every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take several seconds for the backup to start.

    If you receive any errors, you can review them in the Failure Message column of the Granular Backup Job Status page.

See Also

Concepts

Restore a site collection (SharePoint Foundation 2010)


Back up customizations (SharePoint Foundation 2010)
See Also

This article describes how to back up customizations that have been made to Microsoft SharePoint Foundation 2010 sites.

The following kinds of customizations can be made to sites:

  • Customizations packaged as solutions (.wsp files). Solutions contain developed site elements, and are typically created by developers. Developed site elements include the following:

    • Web Parts

    • Workflows

    • Site and list definitions

    • Document converters

    • Event receivers

    • Timer jobs

    • Assemblies

  • Authored site elements, which are typically created by Web designers, are not explicitly compiled and reside in a content database. Authored site elements include the following:

    • Master pages

    • Cascading style sheets

    • Forms

    • Layout pages

  • Changes to the Web.config file

  • Third-party solutions and their associated binary files and registry keys, such as IFilters

  • Changes to sites created by direct editing through the browser

  • Developed customizations that are not packaged as solutions

Each of these kinds of customizations requires a different type of backup.

In this article:

  • Backing up solution packages

  • Backing up authored site elements

  • Backing up workflows

  • Backing up changes to the Web.config file

  • Backing up third-party products

  • Backing up changes made by direct editing

  • Backing up developed customizations that are not packaged as solutions

Backing up solution packages

Solution packages can be created by using Microsoft SharePoint Designer 2010 or Microsoft Visual Studio 2010. We strongly recommend that all customizations be deployed as solution packages.

A solution package is a deployable, reusable file that can contain a set of Features, site definitions, and assemblies that apply to sites, and that you can enable or disable individually. Solution packages can include Web Parts, site or list definitions, custom columns, new content types, custom fields, custom actions, coded workflows, or workflow activities and conditions.

The method that you use to back up solution packages is determined by whether the customizations are deployed as trusted solutions or sandboxed solutions.

Trusted solutions are solution packages that farm administrators deploy. Trusted solutions are deployed to the entire farm and can be used on any site within the farm. Trusted solutions are stored in the configuration database. Trusted solutions are backed up when a farm is backed up by using SharePoint Foundation 2010 backup, and are included in configuration-only backups. You can also back up trusted solutions as a group or individually. Trusted solutions are visible in the backup hierarchy.

Sandboxed solutions are solution packages that site collection administrators can deploy to a single site collection. Sandboxed solutions are stored in the content database that is associated with the site collection to which the solution packages are deployed. They are included in SharePoint Foundation 2010 farm, Web application, content database, and site collection backups, but are not visible in the backup hierarchy and cannot be selected or backed up individually.

We recommend that you keep a backup of the original .wsp file as well as the source code used to build the .wsp file for both trusted solutions and sandboxed solutions.

To back up trusted solutions by using Central Administration

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. In Central Administration, on the Home page, in the Backup and Restore section, click Perform a backup.

  3. On the Perform a Backup — Step 1 of 2: Select Component to Back Up page, select Solutions, and then click Next.

    You can also select an individual solution, if you only want to back up a single solution.

  4. On the Start Backup — Step 2 of 2: Select Backup Options page, in the Backup Type section, select either Full or Differential.

    Note:

    If you are backing up the solution for the first time, you must use the Full option. You must perform a full backup before you can perform a differential backup.

  5. In the Backup File Location section, type the Universal Naming Convention (UNC) path of the backup folder, and then click Start Backup.

  6. You can view the general status of all backup jobs at the top of the Backup and Restore Job Status page in the Readiness section. You can view the status of the current backup job in the lower part of the page in the Backup section. The status page updates every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take several seconds for the backup to start.

    If you receive any errors, review the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Spbackup.log file at the UNC path that you specified in step 4.

To back up trusted solutions 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. At the Windows PowerShell command prompt, type the following command to back up all of the solutions in the farm. To back up a single solution, add the name of the solution to the item path "farm\solutions".

    Copy Code
    Backup-SPFarm -backupmethod full -directory <UNC location> -item "farm\solutions"

    Where:

    • <UNC location> is UNC location of the directory that you want to back up to.

For more information, see Backup-SPFarm.

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.

Backing up sandboxed solutions

You cannot back up only sandboxed solutions. Instead, you must back up the farm, Web application, or content database with which the sandboxed solution is associated. For more information about these methods of backing up, see Related content.

Backing up authored site elements

You cannot back up only authored site elements. Instead, you must back up the farm, Web application, or content database with which the authored site element is associated. For more information about these methods of backing up, see Related content.

Backing up workflows

Workflows are a special case of customizations that you can back up. Make sure that your backup and recovery plan addresses any of the following scenarios that apply to your environment:

  • Declarative workflows, such as those created in Microsoft SharePoint Designer 2010, are stored in the content database for the site collection to which they are they are deployed. Backing up the content database protects these workflows.

  • Custom declarative workflow actions have components in the following three locations:

    1. The Visual Studio 2010 assemblies for the actions are stored in the global assembly cache (GAC).

    2. The XML definition files (.ACTIONS files) are stored in the 14\TEMPLATE\<LCID>\Workflow directory.

    3. An XML entry to mark the action as an authorized type is stored in the Web.config file for the Web applications in which it is used.

    If the farm workflows use custom actions, you should use a file backup system to protect these files and XML entries. Similar to SharePoint Foundation features such as Web Parts and event receivers, these files should be reapplied to the farm as needed after recovery.

  • Workflows that depend on custom code, such as those that are created by using Visual Studio 2010, are stored in two locations. The Visual Studio 2010 assemblies for the workflow are stored in the GAC, and the XML definition files are stored in the Features directory. This is the same as other types of SharePoint Foundation features such as Web Parts and event receivers. If the workflow was installed as part of a solution package, backing up the farm, Web application, content database, or site collection protects these workflows.

  • If you create a custom workflow that interacts with a site collection other than the one where the workflow is deployed, you must back up both site collections to protect the workflow. This includes workflows that write to a history list or other custom list in another site collection. Performing a farm backup is sufficient to back up all site collections in the farm and all workflows that are associated with them.

  • Workflows that are not yet deployed must be backed up and restored separately. When you are developing a new workflow but have not yet deployed it to the SharePoint Foundation farm, make sure that you back up the folder where you store the workflow project files by a file system backup application.

Backing up changes to the Web.config file

A common customization to SharePoint Foundation 2010 is to change the Web.config file. We strongly recommend that you make changes to the Web.config file by using Central Administration or the SharePoint Foundation 2010 APIs and object model. Because these changes are stored in the configuration database, they can be recovered from a farm or configuration-only backup.

Changes to the Web.config file that are not made by using Central Administration or the SharePoint Foundation 2010 APIs and object model should be protected by using a file system backup.

Note:

If you are using forms-based authentication, provider registration in the Web.config file is manual, and is not protected by SharePoint Foundation 2010 backup. In this case, be sure to back up the Web.config file by using a file system backup.

Backing up third-party products

If third-party products are deployed as solution packages, they are protected by SharePoint Foundation 2010 backup. We recommend that you keep all the original files, distribution media, documentation, and the license and product keys that are required for installation.

Backing up changes made by direct editing

Changes made directly to a site by directly editing through the browser can be difficult to back up. The following table describes backup strategies for specific objects.

Edited object | Backup strategy
List | Use SharePoint Designer 2010 and save as a template. For more information, see Save a SharePoint site as a template (http://go.microsoft.com/fwlink/p/?LinkId=199515).
Site | Use SharePoint Designer 2010 and save as a template. For more information, see Save a SharePoint site as a template (http://go.microsoft.com/fwlink/p/?LinkId=199515).
Site collection | Use site collection backup. For more information, see Back up a site collection (SharePoint Foundation 2010) .

Backing up developed customizations that are not packaged as solutions

Backing up developed customizations that are not deployed as solution packages can be a complex process because the customization file locations might not be stored in standardized places and SharePoint Foundation 2010 does not automatically back them up.

Consult with the development team or customization vendor to determine whether the customizations involve additional add-in software or files in other locations. We recommend that you back up these directories with a file system backup solution. The following table lists locations where developed customizations are typically stored on Web servers.

Location | Description
%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14 | Commonly updated files, custom assemblies, custom templates, custom site definitions
Inetpub | Location of IIS virtual directories
%WINDIR%\Assembly | Global assembly cache (GAC): a protected operating system location where the Microsoft .NET Framework code assemblies are installed to provide full system access

Related content

Resource Center | Business Continuity Management for SharePoint Server 2010: Backup, Recovery, Availability, and Disaster Recovery (http://go.microsoft.com/fwlink/p/?LinkID=199235)
IT Pro content | Deploy customizations - overview (SharePoint Foundation 2010) Restore customizations (SharePoint Foundation 2010) Back up a farm (SharePoint Foundation 2010) Back up a farm configuration (SharePoint Foundation 2010) Back up a Web application (SharePoint Foundation 2010) Back up a content database (SharePoint Foundation 2010) Back up a site collection (SharePoint Foundation 2010)
Developer content | Using solutions (MSDN) (http://go.microsoft.com/fwlink/p/?LinkID=156638) Sandboxed solutions (MSDN) (http://go.microsoft.com/fwlink/p/?LinkId=199517)

See Also

Other Resources

Resource Center: Business Continuity Management for SharePoint Foundation 2010


Back up a content database (SharePoint Foundation 2010)
See Also

Microsoft SharePoint Foundation 2010 content databases can grow to be very large. Therefore, you might want to back them up separately from farm backups. Regularly backing up content databases reduces data losses that might occur from hardware failures, power outages, or other problems. It is a simple process and helps to ensure that all the data is available for recovery, if that is required. You can only back up one content database at a time.

This topic describes how to back up a single content database.

Procedures in this task:

  • Use Windows PowerShell to back up a content database

  • Use Central Administration to back up a content database

  • Use SQL Server tools to back up a content database

Task requirements

Before you begin, you must create a folder on the local computer or the network in which to store the backups. For better performance, we recommend that you back up to the local computer and then move the backup files to a network folder.

Note:

SharePoint Foundation 2010 backup backs up remote Binary Large Objects (BLOB) stores but only if you are using the SQL Filestream remote BLOB store provider to place data in remote BLOB stores.

If you are using another provider you must manually back up these remote BLOB stores.

Important:

If you are using SQL Server with Transparent Data Encryption (TDE), and you are backing up your environment by using either SharePoint tools or SQL Server tools, the TDE encryption key in not backed up or restored. You must backup the key manually. When restoring, you must manually restore the key before restoring the data. For more information, see Understanding Transparent Data Encryption (TDE).

Use Windows PowerShell to back up a content database

You can use Windows PowerShell to back up a content database manually or as part of a script that can be run at scheduled intervals.

To back up a content database 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Backup-SPFarm -Directory   <Backup folder>  -BackupMethod {Full | Differential} -Item <Content database name> [-Verbose]
    Note:

    If you are backing up the content database for the first time, you must use the Full option. You must perform a full backup before you can perform a differential backup.

    Note:

    You must use the exact name for the content database that you are backing up with Windows PowerShell. To find the content database name in Central Administration click Manage content databases in the Application Management section.

For more information, see Backup-SPFarm.

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.

Use Central Administration to back up a content database

You can use Central Administration to back up a content database.

To back up a content database by using Central Administration

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. In Central Administration, on the Home page, in the Backup and Restore section, click Perform a backup.

  3. On the Perform a Backup — Step 1 of 2: Select Component to Back Up page, select the content database that you want to back up from the list of components, and then click Next.

    Note:

    Not all content databases can be selected in the list. If a database is not selectable, you must use Windows PowerShell to back up the content database.

  4. On the Start Backup — Step 2 of 2: Select Backup Options page, in the Backup Type section, select either Full or Differential.

    Note:

    If you are backing up the content database for the first time, you must use the Full option. You must perform a full backup before you can perform a differential backup.

  5. In the Backup File Location section, type the Universal Naming Convention (UNC) path of the backup folder, and then click Start Backup.

  6. You can view the general status of all backup jobs at the top of the Backup and Restore Job Status page in the Readiness section. You can view the status of the current backup job in the lower part of the page in the Backup section. The status page updates every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take several seconds for the backup to start.

    If you receive any errors, review the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Spbackup.log file at the UNC path that you specified in step 4.

Use SQL Server tools to back up a content database

You can use SQL Server tools to back up a content database.

To back up a content database by using SQL Server tools

  1. Verify that the user account that is performing this procedure is a member of the SQL Server db_backupoperator fixed database role on the database server where each database is stored.

  2. Open SQL Server Management Studio and connect to the database server.

  3. In Object Explorer, expand Databases.

  4. Right-click the database that you want to back up, point to Tasks, and then click Back Up.

  5. In the Back Up Database dialog box, in the Source area, select the kind of backup that you want to perform from the Backup type list. For more information about which backup type to use, see Overview of Recovery Models (http://go.microsoft.com/fwlink/p/?LinkId=114396) in SQL Server Books Online.

  6. In the Backup component area, click Database.

  7. Either use the default name provided or specify a name for the backup set in the Name text box.

  8. Specify the expiration date for the backup set. This date determines how long, or when, the backup set can be overwritten by any later backups that have the same name. By default, the backup set is set to never expire (0 days).

  9. In the Destination area, specify where you want to store the backup.

  10. Click OK to back up the database.

  11. Repeat steps 1-9 for each content database that you want to back up.

See Also

Concepts

Restore a content database (SharePoint Foundation 2010)

Other Resources

Resource Center: Business Continuity Management for SharePoint Foundation 2010


Back up databases to snapshots (SharePoint Foundation 2010)
See Also

This topic describes how to back up a farm database to a snapshot.

You can only use SQL Server tools to back up a farm database to a snapshot.

Important:

You must be running Microsoft SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2 Enterprise Edition to take database snapshots.

We recommend that you regularly back up the complete farm. Regularly backing up the farm reduces data losses that might occur from hardware failures, power outages, or other problems. It is a simple process and helps to ensure that that all the farm data and configurations are available for recovery, if that is required. For more information, see Back up a farm (SharePoint Foundation 2010). However, IT requirements might require that you backup databases to snapshots. Although you can back up any farm database to a snapshot, you typically back up content databases.

A database snapshot provides a read-only, static view of a source database as it existed at snapshot creation, minus any uncommitted transactions. Uncommitted transactions are rolled back in a newly created database snapshot because the Database Engine runs recovery after the snapshot has been created (transactions in the database are not affected). For more information about database snapshots, see Database Snapshots (http://go.microsoft.com/fwlink/p/?LinkId=163950).

Task requirements

Before you begin, you must create a folder on the database server. If you want to store the snapshots at another location, you can move the backup files to a backup folder on the network after the operation is finished.

Use SQL Server tools to back up a database to a snapshot

If you want to back up databases to snapshots, you must use SQL Server tools. The databases that are associated with the farm are determined by the features that you have installed on the farm.

To back up a database to a snapshot by using SQL Server tools

  1. Verify that the account that is used to back up the databases is a member of the SQL Server db_owner fixed database role.

  2. Open SQL Server Management Studio and connect to the database server.

  3. In Object Explorer, expand Databases.

  4. Select the database that you want to back up, and then click New Query.

  5. Copy the following text, and then paste it to the query pane.

    Copy Code
    CREATE DATABASE <snapshot name>
ON
(
NAME=<logical name of the database file>,
FILENAME = 'c:\WSS_Backup1.ss')
AS SNAPSHOT OF <database name>;

See Also

Other Resources

Database Snapshots


Export a site, list, or document library (SharePoint Foundation 2010)

We recommend that you regularly back up the complete farm. However, business or IT requirements might require that you export a site, list, or document library. Regularly exporting sites, lists, and document libraries reduces data losses that might occur from hardware failures, power outages, or other problems. It is a simple process and helps to ensure that data is available for recovery, if that is required. You can only export one site, list, or document library at a time.

For information about what to back up and which tools to use, see Plan for backup and recovery (SharePoint Foundation 2010).

Procedures in this task:

  • Use Windows PowerShell to export a site, list, or document library

  • Use Central Administration to export a site, list, or document library

Note:

You cannot use SQL Server tools or Data Protection Manager to export a site, list or document library.

Task requirements

Before you begin, you must create a folder on the local computer or the network in which to store the export file. For better performance, we recommend that you export to the local computer and then move the export file to a network folder.

Use Windows PowerShell to export a site, list, or document library

You can use Windows PowerShell to export a site, list, or document library manually or as part of a script that can be run at scheduled intervals.

To export a site, list or document library 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Export-SPWeb -Identity <Site URL> -Path <Path and file name> [-ItemUrl <URL of site, list, or library>] [-IncludeUserSecurity] [-IncludeVersions] [-NoFileCompression] [-GradualDelete] [-Verbose]
    Note:

    If the <Site URL>, <Path and file name>, or <URL of site, list, or library> contain any spaces, you must surround these in double quotes (" ") or the Windows PowerShell command will return errors.

    If you are exporting a large site, list, or document library, you can use the GradualDelete parameter. When this parameter is used, the site collection is marked as deleted, which immediately prevents any further access to its content. The data in the deleted site collection is then deleted gradually over time by a timer job instead of all at once, which reduces its impact on the performance of farm servers and SQL Server.

    To specify which version of the site, list, or document library to include, use the IncludeVersions parameter and specify "LastMajor" (default), "CurrentVersion", "LastMajorandMinor", or "All". To include the user security settings with the list or document library, use the IncludeUserSecurity parameter. If you want to overwrite the file that you specified, use the Force parameter. To view the progress of the backup operation, use the Verbose parameter.

    The NoFileCompression parameter lets you specify that no file compression is performed during the export process. Using this parameter can lower resource usage up to 30% during the export process. Using this parameter will result in a backup folder being created instead of a compressed file. If you use the NoFileCompression parameter in the Export-SPWeb command, you must also use it when you import the content by using the Import-SPWeb command.

For more information, see Export-SPWeb.

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.

Use Central Administration to export a site, list, or document library

You can use Central Administration to export a site, list, or document library. You can only export one site, list, or document library at a time.

To export a site, list, or document library by using Central Administration

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. In Central Administration, on the Home page, click Backup and Restore.

  3. On the Backup and Restore page, in the Granular Backup section, click Export a site or list.

  4. On the Site or List Export page, in the Site Collection section, select the site collection from the Site Collection list, and then select the site from the Site list.

  5. If you are exporting a site, skip this step, Select the list or document library from the List list.

  6. In the File Location section, in the Filename box, type the UNC path of the shared folder and the file to which you want to export the list or document library. The file name must use the .cmp extension.

  7. If the file already exists and you want to use this file, select the Overwrite existing files check box. Otherwise, specify a different file name.

  8. If you want to export all the security and permissions settings with the list or library, in the Export Full Security section, select the Export full security check box.

  9. If you want to specify which version of the list or library to export, select one of the following versions from the Export versions list:

    • All Versions

    • Last Major

    • Current Version

    • Last Major and Last Minor

  10. When you have specified the settings that you want, click Start Export.

  11. You can view the status of all backup jobs at the top of the Granular Backup Job Status page. You can view the status of the current backup job in the Content Export section of the page. The status page updates every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take several seconds for the backup to start.

    If you receive any errors, you can review them in the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the <file name>.export.log file at the UNC path that you specified in step 6.


Back up or archive logs (SharePoint Foundation 2010)

A system-wide strategy for data protection should include backing up or archiving the logs in which data related to Microsoft SharePoint Foundation 2010 is recorded. This data can be useful for performance analysis, troubleshooting, monitoring compliance with service level agreements, and legal, regulatory, or business reasons. Therefore, protect this data as part of the routine maintenance by backing up or archiving the logs.

The following sections are labeled in the following manner to indicate how important it is to back up or archive this kind of log:

  • [Essential] means that the log contains data that is essential to the environment. The data would be lost if a disk failure or other problem occurred.

  • [Recommended] means that the log contains data that is useful in most environments for troubleshooting, operational, legal, or other needs.

In this article:

  • [Essential] Back up transaction logs

  • [Recommended] Collect usage data

  • [Recommended] Archive diagnostic logs

[Essential] Back up transaction logs

Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, and SQL Server 2005 with SP3 and Cumulative Update 3 transaction logs record all changes that were made to a database since the last checkpoint or full backup. These logs contain required data for restoring the farm.

We recommend that you back up these logs every 5-10 minutes. When you back up these logs, they are automatically truncated. You can use the Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, and SQL Server 2005 with SP3 and Cumulative Update 3 tools to back up the transaction log. For more information, see Creating Transaction Log Backups (http://go.microsoft.com/fwlink/p/?LinkId=124881) in the Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, and SQL Server 2005 with SP3 and Cumulative Update 3 documentation.

Transaction logs are not automatically backed up when you back up the farm, Web application, or databases by using either the SharePoint Central Administration Web site or the Windows PowerShell. Therefore, you must manually backup and truncate the log. For more information, see Creating Transaction Log Backups (http://go.microsoft.com/fwlink/p/?LinkId=124881) in the Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, and SQL Server 2005 with SP3 and Cumulative Update 3 documentation.

How transaction log size affects farm backup times

When you back up SharePoint Foundation 2010, the size of the transaction log can affect how long the backup operation takes. Because the transaction log records all changes to a database since the last checkpoint or full backup, the log can grow very large over time. If the transaction log has grown very large, backups might take a very long time. For more information, see How to stop the transaction log of a SQL Server database from growing unexpectedly (http://go.microsoft.com/fwlink/?LinkID=111458).

The recommended way to truncate the transaction log if you are using a full recovery model is to back up the log. Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, and SQL Server 2005 with SP3 and Cumulative Update 3 automatically truncates the inactive parts of the transaction log when you back up the log. We also recommend that you pre-grow the transaction log to avoid auto-growing the log. For more information, see Managing the Size of the Transaction Log File (http://go.microsoft.com/fwlink/p/?LinkId=124882). For more information about using a full recovery model, see Backup Under the Full Recovery Model (http://go.microsoft.com/fwlink/p/?LinkId=127985). For more information about using a simple recovery model, see Backup Under the Simple Recovery Model (http://go.microsoft.com/fwlink/p/?LinkId=127987).

We do not recommend that you manually shrink the transaction log size or manually truncate the log by using the Truncate method.

[Recommended] Collect usage data

Usage analysis enables you to track how Web sites are being used. Log files are created daily to track usage. You can configure the setting for the collection of usage data. One of the most important settings is the location of the log files. By default, the log folder is configured to be on the same drive partition where SharePoint Foundation 2010 is installed. To make sure that the log files to not fill up that drive, you should change the log folder to be on a separate drive.

The location of the log directory is a farm-level setting, and the directory that is specified in this setting must exist on all servers in the farm. These logs are automatically backed up when you back up the farm.

For most environments, the default settings are adequate. For more information about configuring usage data collection settings, see Configure usage and health data collection (SharePoint Foundation 2010)

[Recommended] Archive diagnostic logs

Diagnostic logs provide detailed information about the operation of the farm. You can configure the level of detail that is logged. We recommend that you archive these logs when you archive the farm. You can archive the logs for the whole farm or a specific server. You can archive these files by manually copying them to a shared folder, or by using the Windows PowerShell Merge-SPlogFile cmdlet. You can use the Merge-SPLogFIle cmdlet to archive the log files on all of the farm servers at once. You can use the Windows PowerShell Copy-Item cmdlet to archive log files from a single server. The Copy-Item cmdlet does not provide filtering and you must copy the entire log file.

For more information about how to configure diagnostic logging, see Configure diagnostic logging (SharePoint Foundation 2010).

To archive diagnostic logs from all farm servers 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. At the Windows PowerShell command prompt, type the following command:

    Merge-SPLogFile -Path "<path to merged log file>.log" -Overwrite

    For example, Merge-SPLogFile -Path "C:\Logs\MergedFiles\AllFarm_merged_12.20.2009.log" -Overwrite

    Important:

    Merging all log entries for all farm servers can take a long time and use resources. We recommend filtering the entries to match a specific set of criteria before merging.

    To merge log entries that match a specific set of criteria, type the following command:

    Merge-SPLogFile -Path "<path to merged log file>.log" -Area "<Area>" -Category "<Category>"

    You can filter by one or more of the following:

    • Area (one or more, wildcard)

    • Category (one or more, wildcard)

    • Level

    • Correlation (one or more)

    • EventID (one or more, wildcard)

    • Message (wildcard)

    • StartTime

    • EndTime

    • Process (one or more, wildcard)

    • ThreadID (one or more)

    Tip:

    You can name the merged log file however you want. We recommend that you use a naming convention that makes it easy to determine what the log file contains, such as "<date merged>_<farm name>_<filtering criteria>. For example, to signify all the farm server log entries forSharePoint Foundation 2010 that involve the database category and are marked as "High" use, "Dec_2009_ContosoInternet_Foundation_Database_High.log".

For more information, see Merge-SPLogFile.

To archive diagnostic logs for a specific server 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. At the Windows PowerShell command prompt, type the following command:

    Copy-Item <Log folder path> -Destination <Archive folder path> -Recurse

For more information, type Get-Help Copy-Item -Full.

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.


Recovery (SharePoint Foundation 2010)
See Also

The articles in this section are written to meet the requirements of information technology (IT) professionals who are responsible for the planning, design, deployment, and operations of backup and recovery solutions. These solutions might be in enterprise, corporate, or branch office environments. The IT professionals who are responsible for backup and recovery solutions are expected to have an understanding of the technical details that are contained in this section. However, service-level expertise is not needed to understand the enterprise-level discussions and decisions.

Before you restore a farm, ensure that the following requirements are met:

  • To restore a farm by using the SharePoint Central Administration Web site, you must be a member of the Farm Administrators group.

  • To restore a farm by using Windows PowerShell, you must meet the following minimum requirements: See Add-SPShellAdmin.

  • The database server's SQL Server account, the Timer service account, and the Central Administration application pool account must have Read permissions to the backup locations. (The Timer service account and the Central Administration application pool account are usually the same.) The database server's SQL Server account must be a member of the sysadmin fixed server role.

  • Your login account must have Read permissions to the backup locations.

  • Ensure that the SharePoint Foundation Administration service is started on all farm servers. By default, this service is not started on stand-alone installations.

Consider the following before you restore a farm:

  • Restoring from one version of SharePoint Products and Technologies to a different version is not supported.

  • After recovery, search might take as long as 15 minutes to be available again. It can take longer than 15 minutes if the search system has to crawl all the content again. If you back up and restore the complete service, the system does not have to perform a full crawl.

  • You can only perform one recovery or one backup operation at a time.

Recover all or part of a farm

The following tasks for recovery are performed on the entire farm, farm databases, sites, subsites, or lists:

  • Restore a farm (SharePoint Foundation 2010)

    This article describes the procedures that you can use to restore the entire farm from a backup.

  • Restore a farm configuration (SharePoint Foundation 2010)

    This article describes the procedures that you can use to restore the farm configuration to the same farm from a backup.

  • Document farm configuration settings (SharePoint Foundation 2010)

    This article describes how to use Windows PowerShell to document the configuration settings for your farm. Documenting configuration settings is important both so that you can create scripted deployments for your environment, and so that you can quickly re-create a set of configurations in the event of a failure.

  • Copy configuration settings from one farm to another (SharePoint Foundation 2010)

    This article describes the procedures that you can use to copy configuration settings from one farm to another, including how to back up and recover a farm without the content databases, how to back up and recover configurations only, and how to create a deployment script.

  • Restore a Web application (SharePoint Foundation 2010)

    This article describes the procedures that you can use to restore a Web application that is associated with the farm, including configuration and content databases, from a backup.

  • Restore a service application (SharePoint Foundation 2010)

    This article describes the procedures that you can use to restore a service application that is associated with the farm, including configuration and content databases, from a backup.

  • Restore a content database (SharePoint Foundation 2010)

    This article describes the procedures that you can use to restore a content database from a backup.

  • Restore a site collection (SharePoint Foundation 2010)

    This article describes the procedures that you can use to restore a site collection from a backup.

  • Restore customizations (SharePoint Foundation 2010)

    This article describes the procedures that you can use to restore customizations that are associated with the farm from backups.

  • Attach and restore a read-only content database (SharePoint Foundation 2010)

    This article describes the procedures that you can use to attach a read-only content database to the farm.

  • Recover content from an unattached content database (SharePoint Foundation 2010)

    This article describes how you can restore or copy content, such as sites, site collections, lists, or document libraries, from a content database without having to attach the content database to the farm.

  • Import a list or document library (SharePoint Foundation 2010)

    This article describes the procedures that you can use to restore a site, list, or document library from a backup.

See Also

Concepts

Backup (SharePoint Foundation 2010)


Restore a farm (SharePoint Foundation 2010)
See Also

This article describes how to restore a Microsoft SharePoint Foundation 2010 farm. Farm-level recovery is usually performed only after a failure that involves the complete farm, or where partial recovery of part of the farm is not possible. If you only have to restore part of the farm, a specific database, a service application, a list, or document library, or a specific document, use another recovery method. For more information about alternate forms of recovery, see Related content.

Farm recovery is usually performed for any of the following reasons:

  • Restoring a farm after a fire, disaster, equipment failure, or other data-loss event.

  • Restoring farm configuration settings and data to a specific previous time and date.

  • Moving a SharePoint Foundation 2010 deployment from one farm to another farm.

In this article:

  • Considerations when recovering a farm

  • Use Windows PowerShell to restore a farm

  • Use Central Administration to restore a farm

  • Use SQL Server tools to restore a farm

Considerations when recovering a farm

When you prepare to recover a farm, be aware of the following issues:

  • You cannot restore a multiple-server farm to a stand-alone farm or a stand-alone farm to a multiple-server farm.

  • You cannot back up from one version of Microsoft SharePoint Foundation and restore to another version of SharePoint Foundation.

  • Backing up the farm will back up the configuration and Central Administration content databases, but these cannot be restored using Microsoft SharePoint Foundation 2010 tools. For more information about backing up and restoring all the farm databases, see Move all databases (SharePoint Foundation 2010).

  • When you restore the farm by using Microsoft SharePoint Foundation 2010, the restore process will not automatically start all of the service applications. You must manually start them by using Central Administration or Windows PowerShell. Do not use SharePoint Products Configuration Wizard to start the services because doing so will also re-provision the services and service proxies.

  • The identifier (ID) of each content database is retained when you restore or reattach a database by using built-in tools. Default change log retention behavior when using built-in tools is as follows:

    1. The change logs for all databases are retained when you restore a farm.

    2. The change log for content databases is retained when you reattach or restore a database.

      When a database ID and change log are retained, the search system continues crawling based on the regular schedule that is defined by crawl rules.

      When you restore an existing database and do not use the overwrite option, a new ID is assigned to the restored database, and the database change log is not preserved. The next crawl of the database will add data from the content database to the index.

      If a restore is performed and the ID in the backup package is already being used in the farm, a new ID is assigned to the restored database and a warning is added to the restore log. The ability to perform an incremental crawl instead of a full crawl depends on the content database ID being the same as before and the change log token that is used by the search system being valid for the current change log in the content database. If the change log is not preserved, the token is not valid and the search system has to perform a full crawl.

  • SharePoint Foundation 2010 backup backs up the Business Data Connectivity service external content type definitions but does not back up the data source itself. To protect the data, you should back up the data source when you back up the Business Data Connectivity service or the farm.

    If you restore the Business Data Connectivity service or the farm and then restore the data source to a different location, you must change the location information in the external content type definition. If you do not, the Business Data Connectivity service might be unable to locate the data source.

  • SharePoint Foundation 2010 restores remote Binary Large Objects (BLOB) stores only if you are using the FILESTREAM remote BLOB store provider to put data in remote BLOB stores.

    If you are using another provider, you must manually restore the remote BLOB stores.

  • If a user has taken copies of content for off-line editing in Microsoft SharePoint Workspace 2010 and the content is restored from a backup on the server, when the user re-connects, the server automatically synchronizes the off-line content with the restored content. This might result in data loss on the user's copies of the content.

  • If you are sharing service applications across farms, be aware that trust certificates that have been exchanged are not included in farm backups. You must back up your certificate store separately or retain the certificates in a separate location. When you restore a farm that shares a service application, you must import and redeploy the certificates, and then re-establish any inter-farm trusts.

    For more information, see Exchange trust certificates between farms (SharePoint Foundation 2010).

  • After a Web application that is configured to use claims-based authentication has been restored, duplicate or additional claims providers are often visible. If duplicates appear, you must then manually save each Web application zone to remove them. For more information, see Restore a Web application (SharePoint Foundation 2010).

  • Additional steps are required when you restore a farm that contains a Web application that is configured to use forms-based authentication. For more information, see Restore a Web application (SharePoint Foundation 2010).

Use Windows PowerShell to restore a farm

You can use Windows PowerShell to restore a farm.

To restore a farm 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Restore-SPFarm -Directory <BackupFolder> -RestoreMethod Overwrite [-BackupId <GUID>]

    Where:

    • <BackupFolder> is the path of the folder you use for storing backup files.

    • <GUID> is the identifier of the backup to restore from.

    Note:

    If you are not logged on as the Farm account, you are prompted for the Farm account's credentials.

    If you do not specify the BackupId, the most recent backup will be used. To view the backups for the farm, type the following command:

    Copy Code
    Get-SPBackupHistory -Directory <BackupFolder> -ShowBackup [-Verbose]

    Where:

    • <BackupFolder> is the path of the folder you use for storing backup files.

    You cannot use a configuration-only backup to restore content databases together with the configuration.

  6. To restart a service application, type the following command:

    Copy Code
    Start-SPServiceInstance -Identity <ServiceApplicationID>

    Where:

    • <ServiceApplicationID> is the GUID of the service application.

    Start-SPServiceInstance For more information about restarting service applications by using Windows PowerShell, see Start-SPServiceInstance.

For more information about restoring the farm by using Windows PowerShell, see Restore-SPFarm.

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.

Use Central Administration to restore a farm

You can use the Central Administration Web site to restore a farm.

To restore a farm 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, in the Backup and Restore section, click Restore from a backup.

  3. On the Restore from Backup — Step 1 of 3: Select Backup to Restore page, from the list of backups, select the backup job that contains the farm backup, and then click Next. You can view more details about each backup by clicking the (+) next to the backup.

    Note:

    If the correct backup job does not appear, in the Backup Directory Location text box, type the Universal Naming Convention (UNC) path of the correct backup folder, and then click Refresh.

    You cannot use a configuration-only backup to restore the farm.

  4. On the Restore from Backup — Step 2 of 3: Select Component to Restore page, select the check box that is next to the farm, and then click Next.

  5. On the Restore from Backup — Step 3 of 3: Select Restore Options page, in the Restore Component section, ensure that Farm appears in the Restore the following component list.

    In the Restore Only Configuration Settings section, ensure that the Restore content and configuration settings option is selected.

    In the Restore Options section, under Type of Restore, select the Same configuration option. A dialog box will appear that asks you to confirm the operation. Click OK.

    Note:

    If the Restore Only Configuration Settings section does not appear, the backup that you selected is a configuration-only backup. You must select another backup.

    Click Start Restore.

  6. You can view the general status of all recovery jobs at the top of the Backup and Restore Job Status page in the Readiness section. You can view the status for the current recovery job in the lower part of the page in the Restore section. The status page updates every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take several seconds for the recovery to start.

    If you receive any errors, you can review them in the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Sprestore.log file at the UNC path that you specified in step 3.

  7. When the restore process has completed, you may need to restart one or more service applications. In Central Administration, on the Home page, in the Application Management section, click Manage services on server.

  8. On the Services on Server page, start any services related to service applications that you want to run by clicking Start in the Actions column next to the service application.

  9. Re-establish any trust relationships. For more information, see Exchange trust certificates between farms (SharePoint Foundation 2010).

Use SQL Server tools to restore a farm

Although you cannot restore the complete farm by using SQL Server tools, you can restore most of the farm databases. If you restore the databases by using SQL Server tools, you must restore the farm configuration by using Central Administration or Windows PowerShell. For more information about how to restore the farm's configuration settings, see Restore a farm configuration (SharePoint Foundation 2010).

Note:

The search index is not stored in SQL Server. If you use SQL Server tools to back up and restore search, you must perform a full crawl after you restore the content database.

Before you restore SharePoint Foundation 2010, we recommend that you configure a recovery farm for site and item recovery.

Restore the databases by following these steps:

  1. If possible, back up the live transaction log of the current database to protect any changes that were made after the last full backup.

  2. Restore the last full database backup.

  3. Restore the most recent differential database backup that occurred after the most recent full database backup.

  4. Restore all transaction log backups that occurred after the most recent full or differential database backup.

To restore a farm by using SQL Server tools

  1. Verify that the user account that is performing this procedure is a member of the sysadmin fixed server role.

  2. If the Windows SharePoint Services Timer service is running, stop the service and wait for several minutes for any currently running stored procedures to finish. Do not restart the service until after you restore all the databases that you have to restore.

  3. Start SQL Server Management Studio and connect to the database server.

  4. In Object Explorer, expand Databases.

  5. Right-click the database that you want to restore, point to Tasks, point to Restore, and then click Database.

    The database is automatically taken offline during the recovery operation and cannot be accessed by other processes.

  6. In the Restore Database dialog box, specify the destination and the source, and then select the backup set or sets that you want to restore.

    The default values for destination and source are appropriate for most recovery scenarios.

  7. In the Select a page pane, click Options.

  8. In the Restore options section, select only Overwrite the existing database. Unless your environment or policies require otherwise, do not select the other options in this section.

  9. In the Recovery state section:

    • If you have included all the transaction logs that you must restore, select RECOVER WITH RECOVERY.

    • If you must restore additional transaction logs, select RECOVER WITH NORECOVERY.

    • The third option, RECOVER WITH STANDBY is not used in this scenario.

      Note:

      For more information about these recovery options, see Restore Database (Options Page) (http://go.microsoft.com/fwlink/p/?LinkId=114420).

  10. Click OK to complete the recovery operation.

  11. Except for the configuration database, repeat steps 4 through 9 for each database that you are restoring.

  12. To restore the configuration settings, you must use the existing configuration database or manually create a new database and restore the configuration to that database. For more information about restoring the farm configuration, see Restore a farm configuration (SharePoint Foundation 2010).

  13. Start the Windows SharePoint Services Timer service.

Related content

Resource Centers | Business Continuity Management for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=201997)
IT Pro content | Back up a farm (SharePoint Foundation 2010) Restore a farm configuration (SharePoint Foundation 2010) Restore a Web application (SharePoint Foundation 2010) Restore a content database (SharePoint Foundation 2010)

See Also

Other Resources

Resource Center: Business Continuity Management for SharePoint Foundation 2010


Restore a farm configuration (SharePoint Foundation 2010)
See Also

This topic describes how to a restore the configuration of a farm.

Note:

In previous versions of Microsoft SharePoint Foundation 2010, you could not restore the configuration database and, therefore, you could not restore the configuration of a farm. In this version of SharePoint Foundation 2010, you do not have to restore the configuration database because you can restore the farm configuration directly.

Procedures in this task:

  • Use Windows PowerShell to restore a farm's configuration

  • Use Central Administration to restore a farm's configuration

Overview

Farm-level configuration recovery is performed only after a failure that involves the configuration database but does not involve other farm data, such as a content database or Web application. If restoring the farm configuration does not solve the problems, you must restore the complete farm. For more information about restoring the complete farm, see Restore a farm (SharePoint Foundation 2010). You can restore the configuration from a farm backup that used either the Backup content and configuration settings option or the Backup only configuration settings option.

Use Windows PowerShell to restore a farm's configuration

You can use Windows PowerShell to restore a farm's configuration.

To restore a farm's configuration 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 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:

    Restore-SPFarm -Directory <RestoreShare> -RestoreMethod Overwrite -ConfigurationOnly

    You must use the ConfigurationOnly parameter. To view the progress of the operation, use the Verbose parameter.

For more information, see Restore-SPFarm.

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.

Use Central Administration to restore a farm's configuration

You can use Central Administration to restore a farm's configuration.

To restore a farm's configuration by using Central Administration

  1. Ensure that you are a member of the Farm Administrators SharePoint group on the computer that is running Central Administration and a member of the sysadmin fixed server role on the database server where each database is stored.

  2. In Central Administration, on the Home page, in the Backup and Restore section, click Restore from a backup.

  3. On the Restore from Backup — Step 1 of 3: Select Backup to Restore page, select the backup job that contains the farm backup from the list of backups, and then click Next.

    Note:

    You can view additional information about the backups by expanding the row that contains the backup.

    Note:

    If the correct backup job does not appear, in the Backup Directory Location text box, enter the UNC path of the correct backup folder, and then click Refresh.

  4. On the Restore from Backup — Step 2 of 3: Select Component to Restore page, select the check box that is next to the farm, and then click Next.

  5. On the Restore from Backup — Step 3 of 3: Select Restore Options page, in the Restore Component section, ensure that "Farm" appears in the Restore the following content list.

    In the Restore Only Configuration Settings section, ensure that the Restore content and configuration settings option is selected.

    In the Restore Options section, select the Type of Restore option. Use the Same configuration setting. A dialog box will appear that asks you to confirm the operation. Click OK.

    Note:

    If the Restore Only Configuration Settings section does not appear, then the backup that you selected is a configuration-only backup.

    Click Start Restore.

  6. You can view the general status of all recovery jobs at the top of the Backup and Restore Status page in the Readiness section. You can view the status of the current recovery job in the lower part of the page in the Restore section. The status page updates every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take several seconds for the recovery to start.

    If you receive any errors, you can review them in the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Sprestore.log file at the UNC path that you specified in step 2.

Use SQL Server to restore a farm's configuration

You cannot restore a farm's configuration by using SQL Server tools.

See Also

Concepts

Back up a farm configuration (SharePoint Foundation 2010)


Document farm configuration settings (SharePoint Foundation 2010)

This article describes how to use Windows PowerShell 2.0 to document the configuration settings for your farm. Documenting configuration settings is important both so that you can create scripted deployments for your environment, and so that you can quickly re-create a set of configurations in the event of a failure.

To document configuration settings 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. Using Notepad, create a text file and then copy and paste the following script into the file. The commands in the example create XML files that document the configurations of the Web applications and service applications in the current farm. Choose only those commands that are relevant to your environment.

    Copy Code
    ##
## Common SharePoint configuration settings
##
#Retrieve Web Application information. The default depth of 2 does not return much detail--we recommend that you use a depth of 4 for this cmdlet.
Get-SPWebApplication | Export-Clixml .\ WebAppFilename.xml -depth 4

#Retrieve custom layout information.
Get-SPWebApplication | Get-SPCustomLayoutsPage | Export-Clixml .\Get-SPCustomLayoutsPage.xml

#Determine how SharePoint designer access is configured
Get-SPWebApplication | Get-SPDesignerSettings  | Export-Clixml .\Get-SPDesignerSettings.xml

#Retrieve information about alternate access mapping
Get-SPAlternateURL  | Export-Clixml .\Get-SPAlternateURL.xml

#Retrieve information about content databases
Get-SPContentDatabase  | Export-Clixml .\Get-SPContentDatabase.xml

#Retrieve database properties for each database
Get-SPDatabase  | Export-Clixml .\Get-SPDatabase.xml

#Retrieve information about all SharePoint Products installed in the farm, and the versions of all updates installed for each product.
Get-SPProduct  | Export-Clixml .\Get-SPProduct.xml

#Retrieve farm information
Get-SPFarm  | Export-Clixml .\Get-SPFarm.xml
Get-SPFarmConfig  | Export-Clixml .\Get-SPFarmConfig.xml

#Retrieve information about the servers in the farm
Get-SPServer  | Export-Clixml .\Get-SPServer.xml

#Retrieve information about installed features
Get-SPFeature  | Export-Clixml .\Get-SPFeature.xml

#Retrieve information about globally-installed site templates
Get-SPWebTemplate  | Export-Clixml .\Get-SPWebTemplate.xml

#Retrieve information about deployed solutions
Get-SPSolution  | Export-Clixml .\Get-SPSolution.xml

#Retrieve information about sandboxed solutions deployed in a site collection
Get-SPSite | Get-SPUserSolution  | Export-Clixml .\Get-SPUserSolution.xml

#Retrieve information about installed Help
Get-SPHelpCollection  | Export-Clixml .\Get-SPHelpCollection.xml

#Retrieve information about the logging levels that have been set
Get-SPLogLevel  | Export-Clixml .\Get-SPLogLevel.xml

#Retrieve information about the sites in the farm
Get-SPSite  | Export-Clixml .\Get-SPSite.xml
Get-SPSiteAdministration  | Export-Clixml .\Get-SPSiteAdministration.xml
Get-SPSiteSubscription  | Export-Clixml .\Get-SPSiteSubscription.xml

#Retrieve ULS logging information
Get-SPDiagnosticConfig  | Export-Clixml .\Get-SPDiagnosticConfig.xml
Get-SPDiagnosticsPerformanceCounter  | Export-Clixml .\Get-SPDiagnosticsPerformanceCounter.xml
Get-SPDiagnosticsProvider  | Export-Clixml .\Get-SPDiagnosticsProvider.xml

#Retrieve information about accounts registered in the configuration database
Get-SPManagedAccount  | Export-Clixml .\Get-SPManagedAccount.xml
Get-SPProcessAccount  | Export-Clixml .\Get-SPProcessAccount.xml
Get-SPShellAdmin  | Export-Clixml .\Get-SPShellAdmin.xml

#Retrieve information about the Mobile Messaging account.
Get-SPWebApplication | Get-SPMobileMessagingAccount  | Export-Clixml .\Get-SPMobileMessagingAccount.xml

##
##Common service infrastructure settings
##
#Retrieve information about the service applications in the farm
Get-SPServiceApplication  | Export-Clixml .\Get-SPServiceApplication.xml
Get-SPServiceApplicationPool  | Export-Clixml .\Get-SPServiceApplicationPool.xml
Get-SPServiceApplicationProxy  | Export-Clixml .\Get-SPServiceApplicationProxy.xml
Get-SPServiceApplicationProxyGroup  | Export-Clixml .\Get-SPServiceApplicationProxyGroup.xml
Get-SPServiceApplication | Get-SPServiceApplicationEndpoint  | Export-Clixml .\Get-SPServiceApplicationEndpoint.xml

#Retrieve information about the services running in the farm
Get-SPServiceInstance  | Export-Clixml .\Get-SPServiceInstance.xml

#Retrieve information about common Web service settings
Get-SPServiceHostConfig  | Export-Clixml .\Get-SPServiceHostConfig.xml

##
## Common service application configurations
##

#Application Discovery and Load Balancer Service Application
Get-SPTopologyServiceApplication  | Export-Clixml .\Get-SPTopologyServiceApplication.xml
Get-SPTopologyServiceApplicationProxy  | Export-Clixml .\Get-SPTopologyServiceApplicationProxy.xml

#Business Data Connectivity Service
#Retrieve information about data connection files. ###WARNING: The following cmdlet requires  run as administrator rights
Get-SPDataConnectionFile | Export-Clixml .\Get-SPDataConnectionFile.xml
###WARNING: The following cmdlet requires  run as administrator rights
Get-SPDataConnectionFile | Get-SPDataConnectionFileDependent  | Export-Clixml .\Get-SPDataConnectionFileDependent.xml

#Security Token Service Application
#Retrieve information about the security token service used for incoming SOAP messages.
Get-SPSecurityTokenServiceConfig  | Export-Clixml .\Get-SPSecurityTokenServiceConfig.xml

#Usage and Health data collection
#Retrieve information about the Usage and Health Data Collection service application.
Get-SPUsageApplication  | Export-Clixml .\Get-SPUsageApplication.xml
Get-SPUsageDefinition  | Export-Clixml .\Get-SPUsageDefinition.xml
Get-SPUsageService  | Export-Clixml .\Get-SPUsageService.xml

###Note: These cmdlets are commented out because you are unlikely to want to run them. ###
#Get-SPSite | %{$web=Get-SPWeb $_.Url;$webid=$web.Id;$web | Get-SPUser | Export-Clixml .\Get-SPUser-$webid.xml}

# Get-SPSite | %{$web=Get-SPWeb $_.Url;$webid=$web.Id;$web | Export-Clixml .\Get-SPWeb-$webid.xml}

  6. To run the script, in the Windows PowerShell console, at the command prompt (that is, PS C:\>), type the following command and press ENTER:C:\<path>\<filename>.ps1

For more information, see Export-Clixml, Get-SPWebApplication, Get-SPServiceApplication.

Example of using a cmdlet

This section provides an example of ways that you can use one of the recommended cmdlets.

The Get-SPAlternateURL cmdlet provides information about alternate access mapping. Piping the cmdlet to the Export-Clixml cmdlet writes the information to an XML file.

Copy Code
Get-SPAlternateURL | Export-Clixml .\Get-SPAlternateURL.xml

The following section lists the content of the Get-SPAlternateURL.xml file. Some sections are collapsed.

Copy Code
- <Objs Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04">
+ <Obj RefId="0">
- <Obj RefId="7">
  <TNRef RefId="0" />
  <ToString>Microsoft.SharePoint.Administration.SPAlternateUrl</ToString>
- <Props>
  <S N="IncomingUrl">http://servername</S>
  <URI N="Uri">http://servername/</URI>
+ <Obj N="UrlZone" RefId="8">
- <Obj N="Collection" RefId="9">
  <TNRef RefId="2" />
- <IE>
- <Obj RefId="10">
  <TNRef RefId="0" />
  <ToString>Microsoft.SharePoint.Administration.SPAlternateUrl</ToString>
+ <Props>
- <MS>
  <S N="Zone">Default</S>
  <S N="PublicUrl">http://servername</S>
  </MS>
  </Obj>
  </IE>
- <Props>
  <I32 N="Count">1</I32>
  <B N="IsReadOnly">false</B>
  <S N="TypeName">Alternate Access Mapping Collection</S>
  <S N="DisplayName">SharePoint - 80</S>
  <U64 N="DiskSizeRequired">0</U64>
  <B N="CanSelectForBackup">false</B>
  <B N="CanRenameOnRestore">false</B>
  <B N="CanSelectForRestore">false</B>
  <S N="Name">SharePoint - 80</S>
  <G N="Id">5b65a69a-222d-4fe0-904b-0fb928bc7a89</G>
  <S N="Status">Online</S>
  <S N="Parent">SPFarm Name=SERVERNAME_SharePoint_Configuration_Database</S>
  <I64 N="Version">3661</I64>
+ <Obj N="Properties" RefId="12">
  <TNRef RefId="3" />
  <DCT />
  </Obj>
  <S N="Farm">SPFarm Name=SERVERNAME_SharePoint_Configuration_Database</S>
  <Ref N="UpgradedPersistedProperties" RefId="11" />
  </Props>
  </Obj>
  <Ref N="UpgradedPersistedProperties" RefId="11" />
  </Props>
+ <MS>
+ <Obj N="Zone" RefId="13">
  <TNRef RefId="1" />
  <ToString>Default</ToString>
  <I32>0</I32>
  </Obj>
  <S N="PublicUrl">http://servername</S>
  </MS>
  </Obj>
  </Objs>

This example imports the output from the XML file, so that you can see its contents more easily.

Copy Code
Import-Clixml .\Get-SPAlternateURL.xml

Once an XML file is imported, you can use the objects in the pipeline as though they were real objects of the given type.

Copy Code
Import-Clixml .\Get-SPAlternateURL.xml | %{$_.Uri}

You can also pipe the objects as part of the cmdlet, and view all of the expected properties, methods, and TypeNames. The following example pipes URIs.

Copy Code
Import-Clixml .\Get-SPAlternateURL.xml | %{$_.Uri | Get-Member}

For more information, see Export-Clixml, Import-Clixml, Get-SPAlternateURL, ForEach-Object, Get-Member.


Copy configuration settings from one farm to another (SharePoint Foundation 2010)

This article describes how to copy configuration settings from one Microsoft SharePoint Foundation 2010 farm to another SharePoint Foundation 2010 farm. Copying the configuration settings of one farm to another can be useful in the following circumstances:

  • Setting up similar development, test, and production environments.

  • Establishing an organization standard for farm configuration settings.

  • Setting up a disaster recovery environment.

In this article:

  • Back up and recover a farm without content databases to copy configuration settings

  • Back up and recover configuration settings only

  • Create a scripted deployment to copy configuration settings

There are many ways in which you can copy configurations from one farm to another. Determine which method to use based on the configuration settings that you want to copy and how often you need to copy them.

  • Back up and recover a farm without the content databases attached. This method provides you with farm settings and Web application settings, in addition to the settings for any service applications that you select.

  • Back up and recover configurations only. This method provides you with the core SharePoint Foundation 2010 settings only.

    Note:

    This method does not include Web application or service application settings. If Web application settings are required in the recovered farm, use one of the other methods.

  • Create a deployment script, based on your documented configuration. This method may be more work initially, but is easy to use to maintain standardization.

Back up and recover a farm without content databases to copy configuration settings

To copy configuration settings by using a farm backup, we recommend that you first detach the content databases from the farm. This is not a step that we recommend that you take with a live production farm.

Note:

Creating a farm backup without content databases does back up the service applications.

To back up and recover a farm without content databases 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. At the Windows PowerShell command prompt, type the following command to document the current Web application URLs and content database mappings.

    Copy Code
    Get-SPWebApplication | %{$_.Name;$_.Url;%{$_.ContentDatabases|%{$_.Name};Write-Host ""}}

  6. Either dismount all content databases, as in the following example:

    Copy Code
    Get-SPContentDatabase | Dismount-SPContentDatabase

    Or dismount a specific content database, as in the following example:

    Copy Code
    Get-SPContentDatabase WSS_Content | Dismount-SPContentDatabase

  7. Back up the farm.

    Copy Code
    Backup-SPFarm -Directory \\servername\share -BackupMethod Full
    Note:

    You can view the progress of the backup by looking at the \\servername\share\spbr####\spbackup.log file.

  8. After the backup is complete, re-mount the content databases. Replace <WSS_Content> and <http://servername> with each of the mappings documented in step 5).

    Copy Code
    Mount-SPContentDatabase -Name <WSS_Content> -WebApplication <http://servername>

Back up and recover configuration settings only

As part of farm backup, you can choose to back up only configuration settings. A configuration-only backup extracts and backs up many, but not all, configuration settings from a configuration database. By using built-in tools, you can back up the configuration of any configuration database, whether it is currently attached to a farm or not. For detailed information about how to back up a configuration, see Back up a farm configuration (SharePoint Foundation 2010) .A configuration backup can be restored to the same — or any other — server farm. When a configuration is restored, it will overwrite any settings present in the farm that have values that are set within the configuration backup. If any settings present in the farm are not contained in the configuration backup, they will not be overwritten. For detailed information about how to restore a farm configuration, see Restore a farm configuration (SharePoint Foundation 2010).

Create a scripted deployment to copy configuration settings

When you create a scripted deployment of SharePoint Foundation 2010, you are creating copies of configuration settings.


Restore a Web application (SharePoint Foundation 2010)
See Also

This article describes how to restore a Web application. When you restore a Web application, you also restore the Internet Information Services (IIS) settings and all content databases that are associated with the Web application.

In this article:

  • Considerations when restoring a Web application

  • Use Windows PowerShell to restore a Web application

  • Use Central Administration to restore a Web application

  • Use SQL Server tools to restore databases associated with a Web application

  • Additional steps to restore a Web application that uses forms-based authentication

  • Additional steps to remove duplicate claims providers after restoring a Web application that uses claims-based authentication

Considerations when restoring a Web application

Consider the following information as you prepare to restore a Web application:

  • You can only restore one Web application at a time by using the procedures in this article. However, you can simultaneously restore all the Web applications in the farm by restoring the complete farm.

  • You cannot use SQL Server tools to restore a Web application.

  • When you restore a Web application that is configured to use claims-based authentication, there are additional steps that you must follow after restoring the Web application to restore claims-based authentication.

Use Windows PowerShell to restore a Web application

You can use Windows PowerShell to restore a Web application manually or as part of a script that can be run at scheduled intervals.

To restore a Web application 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Restore-SPFarm -Directory <BackupFolderName> -RestoreMethod Overwrite -Item  <WebApplicationName> [-BackupId <GUID>] [-Verbose]

    Where:

    • <BackupFolderName> is the full path to the folder you use for backup files.

    • <WebApplicationName> is the name of the Web application that was backed up.

    • <GUID> is the identifier of the back up to use for the restore operation.

    If you do not specify the value of the BackupID parameter, the most recent backup will be used. You cannot restore a Web application by using a configuration-only backup. You can view the backups for the farm by typing the following:

    Copy Code
    Get-SPBackupHistory -Directory <BackupFolderName> -ShowBackup

For more information, see Restore-SPFarm.

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.

Use Central Administration to restore a Web application

You can use Central Administration to restore a Web application.

To restore a Web application by using Central Administration

  1. Verify that the user account performing this procedure is a member of the Farm Administrators group. Additionally, verify that the Windows SharePoint Services Timer V4 service and the Farm Database Access account have Full Control permissions on the backup folder.

  2. In Central Administration, on the Home page, in the Backup and Restore section, click Restore from a backup.

  3. On the Restore from Backup — Step 1 of 3: Select Backup to Restore page, from the list of backups, select the backup job that contains the farm or Web application backup, and then click Next. You can view more details about each backup by clicking the (+) next to the backup.

    Note:

    If the correct backup job does not appear, in the Current Directory Location text box, type the Universal Naming Convention (UNC) path of the correct backup folder, and then click Refresh.

    You cannot use a configuration-only backup to restore the Web application.

  4. On the Restore from Backup — Step 2 of 3: Select Component to Restore page, select the check box that is next to the Web application, and then click Next.

  5. On the Restore from Backup — Step 3 of 3: Select Restore Options page, in the Restore Component section, make sure that Farm\<Web application> appears in the Restore the following content list.

    In the Restore Only Configuration Settings section, make sure that the Restore content and configuration settings option is selected.

    In the Restore Options section, under Type of Restore, select the Same configuration option. A dialog box appears that asks you to confirm the operation. Click OK.

    Note:

    If the Restore Only Configuration Settings section does not appear, the backup that you selected is a configuration-only backup. You must select another backup.

    Click Start Restore.

  6. You can view the general status of all recovery jobs at the top of the Backup and Restore Job Status page in the Readiness section. You can view the status for the current recovery job in the lower part of the page in the Restore section. The status page updates every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take several seconds for the recovery to start.

    If you receive any errors, you can review them in the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Sprestore.log file at the UNC path that you specified.

Use SQL Server tools to restore databases associated with a Web application

You cannot restore the complete Web application by using SQL Server tools. However, you can restore all the databases that are associated with the Web application. To restore the complete Web application, use either Windows PowerShell or Central Administration.

To restore databases associated with a Web application by using SQL Server tools

  1. Verify that the user account performing this procedure is a member of the sysadmin fixed server role.

  2. If the Windows SharePoint Services Timer service is running, stop the service and wait for several minutes for any currently running stored procedures to finish. Do not restart the service until after you restore the databases.

  3. Start SQL Server Management Studio and connect to the database server.

  4. In Object Explorer, expand Databases.

  5. Right-click the database that you want to restore, point to Tasks, point to Restore, and then click Database.

    The database is automatically taken offline during the recovery operation and cannot be accessed by other processes.

  6. In the Restore Database dialog box, specify the destination and the source, and then select the backup set or sets that you want to restore.

    The default values for destination and source are appropriate for most recovery scenarios.

  7. In the Select a page pane, click Options.

  8. In the Restore options section, select only Overwrite the existing database. Unless the environment or policies require otherwise, do not select the other options in this section.

  9. In the Recovery state section:

    • If you have included all the transaction logs that you must restore, select RECOVER WITH RECOVERY.

    • If you must restore additional transaction logs, select RECOVER WITH NORECOVERY.

    • The third option, RECOVER WITH STANDBY is not used in this scenario.

      Note:

      For more information about these recovery options, see Restore Database (Options Page) (http://go.microsoft.com/fwlink/p/?LinkId=114420).

  10. Click OK to complete the recovery operation.

  11. Repeat steps 4 through 10 for each database that you are restoring.

  12. Start the Windows SharePoint Services Timer service.

Additional steps to restore a Web application that uses forms-based authentication

After you restore a Web application that uses forms-based authentication, you must perform the following steps to reconfigure the Web application to use forms-based authentication.

  1. Re-register the membership and role providers in the Web.config file.

  2. Redeploy the providers.

For more information, see Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010).

Additional steps to remove duplicate claims providers after restoring a Web application that uses claims-based authentication

After a Web application that is configured to use claims-based authentication has been restored, duplicate or additional claims providers are often visible. You must use the following process to remove the duplicate providers:

  1. In Central Administration, click Manage Web application, select a Web application that uses claims-based authentication, and then click Authentication Providers.

  2. Select a zone that the Web application is associated with to open the Edit Authentication page, and then click Save.

  3. Repeat for each zone, and then for each Web application that uses claims-based authentication.

Related content

Resource center | Business Continuity Management for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=201997)
IT Pro content | Back up a Web application (SharePoint Foundation 2010) Plan for backup and recovery (SharePoint Foundation 2010) Backup and recovery (SharePoint Foundation 2010)
Developer content | Data Protection and Recovery (http://go.microsoft.com/fwlink/p/?LinkID=199237)

See Also

Other Resources

Resource Center: Business Continuity Management for SharePoint Foundation 2010


Restore a service application (SharePoint Foundation 2010)
See Also

There are situations in which you might have to restore a specific service application instead of restoring the complete farm. Some service applications — for example, the Business Data Connectivity service application — provide data to other services and sites. As a result, users might experience some service interruption until the recovery process is complete.

You can also at the same time restore all the service applications in a farm by using Windows PowerShell or Central Administration.

Important:

You cannot back up from one version of Microsoft SharePoint Foundation and restore to another version of SharePoint Foundation.

Note:

SharePoint Foundation 2010 backs up the Business Data Connectivity service metadata store, which includes external content types, external systems, and Business Data Catalog models. For more information, see Business Data Connectivity service administration (SharePoint Foundation 2010). Note that this does not back up the external data sources. To protect the data, the external data sources must be backed up.

If you restore the service application or the farm and then restore the data source to a different location, you must configure the location information in the external content type definition. If you do not, the Business Data Connectivity service might be unable to locate the data source.

Note:

SharePoint Foundation 2010 restores remote Binary Large Object (BLOB) stores but only if you are using the FILESTREAM provider to put data in remote BLOB stores.

If you are using another provider, you must manually restore remote BLOB stores.

Procedures in this article:

  • Use Windows PowerShell to restore a service application

  • Use Central Administration to restore a service application

  • Use SQL Server tools to restore the databases for a service application

    Note:

    You cannot restore the complete service application by using SQL Server tools. However, you can restore the databases that are associated with the service application.

Use Windows PowerShell to restore a service application

You can use Windows PowerShell to restore a service application.

To restore a service application 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Restore-SPFarm -Directory <BackupFolder> -Item "<ServiceApplicationName>" -RecoveryMethod Overwrite [-BackupId <GUID>] [-Verbose]

    Where:

    • <BackupFolder> is the path for the backup folder where the service application was backed up.

    • <ServiceApplicationName> is the name the service application.

    • <GUID> is the ID of the backup to use.

    To specify which backup to use, use the BackupId parameter. You can view the backups for the farm by typing the following: Get-SPBackupHistory -Directory <BackupFolder> -ShowBackup. If you do not specify the BackupId, the most recent backup will be used. You cannot restore a service application from a configuration-only backup.

    To restore all the service applications, at the Windows PowerShell command prompt, type the following command:

    Copy Code
    Restore-SPFarm -Directory <BackupFolder> -Item "Farm\Shared Service Applications" -RecoveryMethod Overwrite [-BackupId <GUID>] [-Verbose]

    Where:

    • <BackupFolder> is the path for the backup folder where the service application was backed up.

    • <GUID> is the ID of the backup to use.

For more information, see Restore-SPFarm.

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.

Use Central Administration to restore a service application

Use the following procedure to restore a service application by using the SharePoint Central Administration Web site.

To restore a service application 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, in the Backup and Restore section, click Restore from a backup.

  3. On the Restore from Backup — Step 1 of 3: Select Backup to Restore page, select the backup job that contains the service application backup, or a farm-level backup, from the list of backups, and then click Next. You can view more details about each backup by clicking the (+) next to the backup.

    Note:

    If the correct backup job does not appear, in the Backup Directory Location text box, type the path of the correct backup folder, and then click Refresh.

    You cannot use a configuration-only backup to restore the farm.

  4. On the Restore from Backup — Step 2 of 3: Select Component to Restore page, expand Shared Services Applications, select the check box that is next to the service application, and then click Next. To restore all the service applications, select the Shared Services Applications node.

  5. On the Restore from Backup — Step 3 of 3: Select Restore Options page, in the Restore Component section, make sure that Farm\Shared Services Applications\<Service application> appears in the Restore the following component list.

    In the Restore Options section, under Type of restore, select the Same configuration option. A dialog box will appear that asks you to confirm the operation. Click OK.

    Click Start Restore.

  6. You can view the general status of all recovery jobs at the top of the Backup and Restore Job Status page in the Readiness section. You can view the status for the current recovery job in the lower part of the page in the Restore section. The status page updates every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take a several seconds for the recovery to start.

    If you receive any errors, you can review them in the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Sprestore.log file at the UNC path that you specified in step 3.

Use SQL Server tools to restore the databases for a service application

You cannot restore the complete service application by using SQL Server tools. However, you can use SQL Server tools to restore the databases that are associated with the service application. To restore the complete service application, use either Windows PowerShell or Central Administration.

To restore the databases for a service application by using SQL Server tools

  1. Verify that the user account that you are using to restore the databases is a member of the SQL Server sysadmin fixed server role on the database server where each database is stored.

  2. Open SQL Server Management Studio and connect to the database server.

  3. In Object Explorer, expand Databases.

  4. Right-click the database that you want to restore, point to Tasks, point to Restore, and then click Database.

  5. In the Restore Database dialog box, on the General page, select the database to restore to from the To database drop-down list.

  6. Select the restore source from the From database drop-down list.

  7. In the Select the backup sets to restore section area, select the check box next to the database.

  8. On the Options tab, select the recovery state from the Recover state section.

    For more information about which recovery type to use, see Overview of Recovery Models (http://go.microsoft.com/fwlink/p/?LinkId=114396) in SQL Server Books Online.

  9. Click OK to restore the database.

  10. Repeat steps 1-9 for each database that is associated with the service application.

See Also

Other Resources

Resource Center: Business Continuity Management for SharePoint Foundation 2010


Restore a site collection (SharePoint Foundation 2010)
See Also

You can use only Windows PowerShell to restore a site collection.

Important:

The SharePoint 2010 Service Pack 1 (SP1) upgrade process alters the schema of all content databases. Because of these changes, you might need to take additional steps to restore a backup that you made before the farm was upgraded to SP1 to the farm after it is upgraded to SP1. For more information about doing this, see Restore pre-SP1 backups to an SP1 farm (SharePoint Foundation 2010).

Use Windows PowerShell to restore a site collection

You can use Windows PowerShell to restore a site collection manually or as part of a script that can be run at scheduled intervals.

Note:

If a user has taken copies of content for off-line editing in Microsoft SharePoint Workspace 2010 and the content is restored from a backup on the server, when the user re-connects, the server automatically synchronizes the off-line content with the restored content. This might result in data loss on the user's copies of the content.

To restore a site collection by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. Additionally, verify that the user account performing this procedure has read permissions to the backup folder and is a member of the db_owner fixed database role on both the farm configuration database and the content database where the site collection is being restored.

  2. On the Start menu, click Administrative Tools.

  3. Click SharePoint 2010 Management Shell.

  4. At the Windows PowerShell command prompt (that is, PS C:\>), type the following command, and then press ENTER:

    Restore-SPSite -Identity <Site collection URL> -Path <Backup file> [-DatabaseServer <Database server name>] [-DatabaseName <Content database name>] [-HostHeader <Host header>] [-Force] [-GradualDelete] [-Verbose]

    If you want to restore the site collection to a specific content database, use the DatabaseServer and DatabaseName parameters to specify the content database. If you do not specify a content database, the site collection will be restored to a content database chosen by Microsoft SharePoint Foundation 2010.

    If you are restoring a host-named site collection, use the Identity parameter to specify the URL of the host-named site collection and use the HostHeader parameter to specify the URL of the Web application that will hold the host-named site collection.

    If you want to overwrite an existing site collection, use the Force parameter.

    Note:

    If the site collection that you are restoring is 1 gigabyte or larger, you can use the GradualDelete parameter for better performance during the restore process. When this parameter is used, the site collection that is overwritten is marked as deleted, which immediately prevents any additional access to its content. The data in the marked site collection is then deleted gradually over time by a timer job instead of all at the same time, which reduces the impact on server performance.

For more information, see Restore-SPSite.

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.

See Also

Concepts

Back up a site collection (SharePoint Foundation 2010)


Restore customizations (SharePoint Foundation 2010)
See Also

This article describes how to restore customizations that have been made to sites in a Microsoft SharePoint Foundation farm.

This article assumes that you are familiar with the concepts and procedures in Back up customizations (SharePoint Foundation 2010).

In this article:

  • Restoring solution packages

  • Restoring authored site elements

  • Restoring workflows

  • Restoring changes to the Web.config file

  • Recovering changes made by direct editing

  • Restoring developed customizations that are not packaged as solutions

Restoring solution packages

The method that you use to restore solution packages is determined by whether the customizations were deployed as trusted solutions or sandboxed solutions.

Trusted solutions are solutions that farm administrators deploy. They are deployed to the entire farm, and can be used on any site within the farm. Trusted solutions are stored in the configuration database. Trusted solutions are backed up when a farm is backed up by using SharePoint Foundation 2010 backup, and are included in configuration-only backups, and can also be backed up as a group, or individually. They are visible in the restore hierarchy.

Sandboxed solutions are solutions that site collection administrators can deploy to a single site collection. Sandboxed solutions are stored in the content database associated with the site collection that they are deployed to. They are included in SharePoint Foundation 2010 farm, Web application, content database, and site collection backups, but are not visible in the restore hierarchy, and cannot be selected or restored individually.

We recommend that you keep a backup of the original .wsp file as well as the source code used to build the .wsp file for both trusted and sandboxed solutions.

To restore a trusted solution 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, in the Backup and Restore section, click Restore from a backup.

  3. On the Restore from Backup — Step 1 of 3: Select Backup to Restore page, from the list of backups, select the backup job that contains the solution package, and then click Next. You can view more details about each backup by clicking the (+) next to the backup.

    Note:

    If the correct backup job does not appear, in the Backup Directory Location text box, type the Universal Naming Convention (UNC) path of the correct backup folder, and then click Refresh.

  4. On the Restore from Backup — Step 2 of 3: Select Component to Restore page, select the check box that is next to the solution, and then click Next.

  5. On the Restore from Backup — Step 3 of 3: Select Restore Options page, in the Restore Component section, ensure that Solution appears in the Restore the following component list.

    In the Restore Only Configuration Settings section, ensure that the Restore content and configuration settings option is selected.

    In the Restore Options section, under Type of Restore, select the Same configuration option. A dialog box appears that asks you to confirm the operation. Click OK.

    Click Start Restore.

  6. You can view the general status of all recovery jobs at the top of the Backup and Restore Job Status page in the Readiness section. You can view the status for the current recovery job in the lower part of the page in the Restore section. The status page updates every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take several seconds for the recovery to start.

    If you receive any errors, you can review them in the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Sprestore.log file at the UNC path that you specified in step 3.

To restore a trusted solution 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Restore-SPFarm -Directory <BackupFolder> -RestoreMethod Overwrite -BackupId <GUID> -Item <SolutionPath>

    Where:

    • <BackupFolder> is the UNC location of the directory that you want to restore from.

    • <GUID> is the GUID of the backup ID that you want to restore from. If you do not specify a backup, the most recent one is used.

    • <SolutionPath> is the path of the solution within the backup tree (usually farm\solutions\SolutionName).

For more information, see Restore-SPFarm.

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.

Restoring a sandboxed solution

You cannot restore only customizations that were deployed as sandboxed solutions. Instead, you must restore the farm, Web application, content database, or site collection with which the customization is associated. For more information about these methods of restoring, see Related content later in this article.

Restoring authored site elements

You cannot restore only authored site elements. Instead, you must restore the farm, Web application, or content database with which the authored site element is associated. For more information about these methods of backing up, see Related content.

Restoring workflows

Workflows are a special case of customizations that you can restore. Make sure that the backup and recovery plan includes any of the following scenarios that apply to the environment:

  • Declarative workflows, such as those created in Microsoft SharePoint Designer 2010, are stored in the content database for the site collection to which they are they are deployed. Restoring the content database or site collection restores these workflows.

  • Custom declarative workflow actions have components in the following three locations:

    1. The Microsoft Visual Studio 2010 assemblies for the actions are stored in the global assembly cache (GAC).

    2. The XML definition files (.actions files) are stored in the 14\TEMPLATE\<LCID>\Workflow directory.

    3. An XML entry to mark the action as an authorized type is stored in the Web.config file for the Web applications in which it is used.

    If the farm workflows use custom actions, you should use a file restore system to restore these files and XML entries. You can reapply the files as needed after recovery.

  • Workflows that depend on custom code, such as those that are created by using Visual Studio 2010, are stored in two locations. The Visual Studio 2010 assemblies for the workflow are stored in the GAC, and the XML definition files are stored in the Features directory. This is the same as other types of SharePoint Foundation features such as Web Parts and event receivers. If the workflow was installed as part of a solution package, follow the instructions for restoring solution packages.

  • If you create a custom workflow that interacts with a site collection other than the one where the workflow is deployed, you must restore both site collections to recover the workflow. Restoring a farm is sufficient to recover all site collections in the farm and all workflows that are associated with them.

  • Workflows that have not been deployed must be restored separately by using a file system backup application.

Restoring changes to the Web.config file

You can recover changes to the Web.config file made by using Central Administration or the SharePoint Foundation 2010 APIs and object model by performing a farm or configuration-only restore.

You should use a file system backup to protect changes to the Web.config file that are not made by using Central Administration or the SharePoint APIs and object model. You can recover the backup by using a file system restore.

Recovering changes made by direct editing

Changes made directly to a site by directly editing through the browser can be difficult to recover. The following table describes recovery strategies for specific objects.

Edited object | Backup strategy
List | If you have used SharePoint Designer 2010 to save as a template, you can deploy and activate the template. For more information, see Save a SharePoint site as a template (http://go.microsoft.com/fwlink/p/?LinkID=199515).
Site | If you have used SharePoint Designer 2010 to save as a template, you can deploy and activate the template. For more information, see Save a SharePoint site as a template (http://go.microsoft.com/fwlink/p/?LinkID=199515).
Site collection | Use site collection recovery. For more information, see Restore a site collection (SharePoint Foundation 2010).

Restoring developed customizations that are not packaged as solutions

Restoring developed customizations that are not packaged as solutions can be a complex process because the customization file locations are not standardized.

Consult with the development team or customization vendor to determine whether the customizations involve additional add-in software or files in other locations. We recommend that you restore directories with a file system restore solution. The following table lists locations where customizations are typically stored on Web servers.

Location | Description
%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14 | Commonly updated files, custom assemblies, custom templates, custom site definitions
Inetpub | Location of IIS virtual directories
%WINDIR%\Assembly | Global assembly cache (GAC): a protected operating system location where the Microsoft .NET Framework code assemblies are installed to provide full system access

Related content

Resource Center | Business Continuity Management for SharePoint Server 2010: Backup, Recovery, Availability, and Disaster Recovery (http://go.microsoft.com/fwlink/p/?LinkID=199235)
IT Pro content | Deploy customizations - overview (SharePoint Foundation 2010) Back up customizations (SharePoint Foundation 2010) Restore a farm (SharePoint Foundation 2010) Restore a farm configuration (SharePoint Foundation 2010) Restore a Web application (SharePoint Foundation 2010) Restore a content database (SharePoint Foundation 2010) Restore a site collection (SharePoint Foundation 2010)
Developer content | Using solutions (MSDN) (http://go.microsoft.com/fwlink/p/?LinkID=156638) Sandboxed solutions (MSDN) (http://go.microsoft.com/fwlink/p/?LinkID=199517)

See Also

Other Resources

Resource Center: Business Continuity Management for SharePoint Foundation 2010


Restore a content database (SharePoint Foundation 2010)
See Also

You can restore any content database or several content databases, one at a time. For information about how to back up all the content databases in a farm at the same time, see Back up a farm (SharePoint Foundation 2010).

Note:

SharePoint Foundation 2010 restores up remote Binary Large Objects (BLOB) stores but only if you are using the SQL Filestream remote BLOB store provider to place data in remote BLOB stores.

If you are using another provider you must manually restore these remote BLOB stores.

Note:

If a user has taken copies of content for off-line editing in Microsoft SharePoint Workspace 2010 and the content is restored from a backup on the server, when the user re-connects, the server automatically synchronizes the off-line content with the restored content. This might result in data loss on the user's copies of the content.

Procedures in this task:

  • Use Windows PowerShell to restore a content database

  • Use Central Administration to restore a content database

  • Use SQL Server tools to restore a content database

Use Windows PowerShell to restore a content database

You can use Windows PowerShell to restore a content database.

To restore a content database 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. At the Windows PowerShell command prompt (that is, PS C:\>), type the following command, and then press ENTER:

    Restore-SPFarm -Directory <Backup folder name> -RestoreMethod Overwrite -Item <Content database name> [-BackupId <GUID>] [-Verbose]

    Note:

    If you are not logged on as the Farm account, you are prompted for the Farm account's credentials.

    If you do not use the BackupId parameter, the most recent backup will be used. To view a list of the backups, including their Backup IDs, type the following command, and then press ENTER:

    Get-SPBackupHistory -Directory <Backup folder>

For more information, see Restore-SPFarm.

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.

Use Central Administration to restore a content database

You can use Central Administration to restore a farm or components of a farm.

To restore a content database by using Central Administration

  1. Verify that you are logged on as a member of the Farm Administrators group.

  2. In Central Administration, on the Home page, in the Backup and Restore section, click Restore from a backup.

  3. On the Restore from Backup — Step 1 of 3: Select Backup to Restore page, from the list of backups, select the backup job that contains the content database backup, and then click Next.

    Note:

    If the correct backup job does not appear, in the Current Directory Location text box, enter the path of the correct backup folder, and then click Refresh.

  4. On the Restore from Backup — Step 2 of 3: Select Component to Restore page, select the check box that is next to the content database, and then click Next.

    Note:

    If the content database is not selectable, you must use Windows PowerShell or SQL Server tools to restore the content database.

  5. On the Restore from Backup — Step 3 of 3: Select Restore Options page, in the Restore Options section, under Type of Restore, click the Same configuration option. A dialog box appears that asks you to confirm the operation. Click OK.

    Click Start Restore.

  6. You can view the general status of all recovery jobs at the top of the Backup and Restore Job Status page in the Readiness section. You can view the status for the current recovery job in the lower part of the page in the Restore section. The status page updates every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take several seconds for the recovery to start.

    If you receive any errors, you can review them in the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Sprestore.log file at the UNC path that you specified in step 2.

Use SQL Server tools to restore a content database

You can use SQL Server tools to restore a content database by following these steps:

  1. If possible, back up the live transaction log of the content database to protect any changes that were made after the last full backup.

  2. Restore the last full database backup.

  3. Restore the most recent differential database backup that occurred after the most recent full database backup.

  4. Restore all transaction log backups that occurred after the most recent full or differential database backup.

To restore a content database by using SQL Server tools

  1. Verify that the user account performing this procedure is a member of the sysadmin fixed server role.

  2. If the Windows SharePoint Services Timer service is running, stop the service and wait for several minutes for any currently running stored procedures to finish. Do not restart the service until after you restore the content databases.

  3. Start SQL Server Management Studio and connect to the database server.

  4. In Object Explorer, expand Databases.

  5. Right-click the database that you want to restore, point to Tasks, point to Restore, and then click Database.

    The database is automatically taken offline during the recovery operation and cannot be accessed by other processes.

  6. In the Restore Database dialog box, specify the destination and the source, and then select the backup set or sets that you want to restore.

    The default values for destination and source are appropriate for most recovery scenarios.

  7. In the Select a page pane, click Options.

  8. In the Restore options section, select only Overwrite the existing database. Unless the environment or policies require otherwise, do not select the other options in this section.

  9. In the Recovery state section:

    • If you have included all the transaction logs that you must restore, select RECOVER WITH RECOVERY.

    • If you must restore additional transaction logs, select RECOVER WITH NORECOVERY.

    • The third option, RECOVER WITH STANDBY is not used in this scenario.

      Note:

      For more information about these recovery options, see Restore Database (Options Page) (http://go.microsoft.com/fwlink/p/?LinkId=114420).

  10. Click OK to complete the recovery operation.

  11. Repeat steps 4 through 10 for each database that you are restoring.

  12. Start the Windows SharePoint Services Timer service.

See Also

Concepts

Back up a content database (SharePoint Foundation 2010)

Other Resources

Resource Center: Business Continuity Management for SharePoint Foundation 2010


Attach and restore a read-only content database (SharePoint Foundation 2010)
See Also

A Microsoft SharePoint Foundation 2010 farm in which content databases have been set to be read-only can be part of a failure recovery environment that runs against mirrored or log-shipped content databases or part of a highly available maintenance or patching environment that provides user access when another version of the farm is being updated. When you re-attach the read-only databases, they become read-write.

For more information about how to use read-only databases, see Run a farm that uses read-only databases (SharePoint Foundation 2010).

Use Windows PowerShell to attach and restore a read-only content database

You can use only Windows PowerShell to attach and restore a read-only content database.

To attach and restore a read-only content database 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. At the Windows PowerShell command prompt (that is, PS C:\>), type the following command, and then press ENTER:

    Mount-SPContentDatabase -Name <Database name> -WebApplication <Web application ID> [-Verbose]

    Note:

    Attaching a content database by using the Mount-SPContentDatabase cmdlet differs from attaching a database in SQL Server by using SQL Server tools. Mount-SPContentDatabase associates the content database with a Web application so that the contents can be read.

For more information, see Mount-SPContentDatabase.

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.

See Also

Concepts

Recovery (SharePoint Foundation 2010)

Other Resources

Resource Center: Business Continuity Management for SharePoint Foundation 2010


Recover content from an unattached content database (SharePoint Foundation 2010)

Published: June 16, 2011

You can restore or copy content, such as sites, site collections, lists, or document libraries, from a content database without having to attach the content database to the farm.

Important:

The SharePoint 2010 Service Pack 1 (SP1) upgrade process alters the schema of all content databases. Because of these changes, you might need to take additional steps to restore a backup that you made before the farm was upgraded to SP1 to the farm after it is upgraded to SP1. For more information about doing this, see Restore pre-SP1 backups to an SP1 farm (SharePoint Foundation 2010).

Use Windows PowerShell to recover content from an unattached content database

You can recover content from an unattached content database by using Windows PowerShell.

To recover content from an unattached content database 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Get-SPContentDatabase -ConnectAsUnattachedDatabase  -DatabaseName <DatabaseName> -DatabaseServer <DatabaseServer>

    Where:

    • <DatabaseName> is the name of the unattached database from which you want to recover content.

    • <DatabaseServer> is the name of the database server that hosts the unattached database from which you want to recover content.

For more information, see Get-SPContentDatabase.

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.

Use Central Administration to recover content from an unattached content database

You can recover content from an unattached content database by using Central Administration.

To recover content from an unattached content database by using Central Administration

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group and is a member of the db_owner fixed database role.

  2. In Central Administration, on the Home page, click Backup and Restore.

  3. On the Backup and Restore page, in the Granular Backup section, click Recover data from an unattached content database.

  4. On the Unattached Content Database Data Recovery page, type the database server name in the Database Server text box and type the database name in the Database Name text box.

  5. Select the database authentication method that you want to use.

  6. Select the Browse content option, and then click Next.

    Click Start Restore.

  7. On the Browse content page, select the site collection, site, and or list that you want to restore, select the Backup site collection or Export site or list option, and then click Next.

    Complete the process to restore the content. For more information about using the Backup site collection option, see Back up a site collection (SharePoint Foundation 2010). For more information about using the Export site or list option, see Export a site, list, or document library (SharePoint Foundation 2010).


Import a list or document library (SharePoint Foundation 2010)
See Also

Although you can use either Windows PowerShell or Central Administration to export a site, list, or document library, you can use only Windows PowerShell to import a site, list, or document library. For information about how to export lists or libraries, see Export a site, list, or document library (SharePoint Foundation 2010).

You can use importing as a method of restoring the items, or as a method of moving or copying the items from one farm to another farm. You can import a site, list, or document library from a backup of the current farm, from a backup of another farm, or from a read-only content database. To import from a read-only content database, you must first attach the read-only database. For more information, see Attach and restore a read-only content database (SharePoint Foundation 2010).

Important:

You cannot import a site, list or document library exported from one version of Microsoft SharePoint Foundation to another version of SharePoint Foundation.

Import a site, list or document library

You can use Windows PowerShell to manually import a site, list, or document library or as part of a script that can be run at regular intervals.

To import a site, list or document library 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. At the Windows PowerShell command prompt (that is, PS C:\>), type the following command, and then press ENTER:

    Import-SPWeb -Identity <Site URL> -Path <Export file name> [-Force] [-NoFileCompression] [-Verbose]

    Important:

    The site or subsite that you are importing must have a template that matches the template of the site specified by Identity.

    You can also use the Get-SPWeb cmdlet and pass the ID to Import-SPWeb by using the Windows PowerShell pipeline. The value of the Path parameter specifies the path and file name of the file from which to import the list or library. To include the user security settings with the list or document library, use the IncludeUserSecurity parameter. To overwrite the list or library that you specified, use the Force parameter. You can use the UpdateVersions parameter to specify how versioning conflicts will be handled. To view the progress of the operation, use the Verbose parameter.

    The NoFileCompression parameter lets you specify that no file compression is performed during the import process. Using this parameter can lower resource usage up to 30% during the export and import process. If you are importing a site, list, or document library that you exported from Central Administration, or if you exported a site, list, or document library by using Windows PowerShell and you did not use the NoFileCompression parameter in the Export-SPWeb cmdlet, you cannot use this parameter in the Import-SPWeb cmdlet.

    Note:

    There is no facility in the Import-SPWeb cmdlet import a subset of the items in the export file. Therefore, the import operation will import everything from the file.

For more information, see Import-SPWeb.

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.

See Also

Concepts

Export a site, list, or document library (SharePoint Foundation 2010)


Restore pre-SP1 backups to an SP1 farm (SharePoint Foundation 2010)

Published: August 11, 2011

This article explains how to restore backups of databases that you made on farms before you installed SharePoint 2010 Service Pack 1 (SP1) to farms that have SP1 installed.

The SharePoint 2010 Service Pack 1 (SP1) upgrade process alters the schema of some farm databases and all content databases. Because of these changes, you might need to take additional steps to restore a backup that you made before the farm was upgraded to SP1 to the farm after it is upgraded to SP1. For more information about SP1, see Service Pack 1 (SP1) for SharePoint Foundation 2010 and SharePoint Server 2010.

Important:

We strongly recommend that you perform a full backup immediately after you upgrade to SP1.

In this article:

Restoring a pre-SP1 farm, Web application, or content database backup to an SP1 farm

Before you restore a pre-SP1 farm Web application or content database backup to an SP1 farm environment, you must use the procedure in this section to upgrade the backup to SP1.

To restore a pre-SP1 farm, Web application, or content database backup to an SP1 farm

  1. Restore the pre-SP1 farm backup by using the Central Administration Web site or Windows PowerShell. For more information about how to restore a farm backup, see Restore a farm (SharePoint Foundation 2010).

  2. Upgrade the content database to SP1 by running the Psconfig Upgrade command. For more information, see Psconfig command-line reference (SharePoint Foundation 2010).

Restoring a pre-SP1 site collection backup to an SP1 farm

Before you restore a pre-SP1 farm backup to an SP1 farm environment, you must use the procedure in this section to upgrade the backup to SP1.

Important:

You have to complete these procedures on a test farm that does not have SP1 installed.

To restore a pre-SP1 farm, Web application, or content database backup to an SP1 farm

  1. Restore the pre-SP1 site collection backup to a pre-SP1 test farm. For more information see, Restore a site collection (SharePoint Foundation 2010).

  2. Upgrade the test farm to SP1.

  3. Perform a site collection backup on the test farm. For more information see, Back up a site collection (SharePoint Foundation 2010).

  4. Restore the site collection backup to the SP1 production farm. For more information see, Restore a site collection (SharePoint Foundation 2010).

Restoring content from a pre-SP1 unattached content database to an SP1 farm

Before you restore a pre-SP1 farm backup to an SP1 farm environment, you must use the procedure in this section to upgrade the backup to SP1.

To restore a pre-SP1 farm, Web application, or content database backup to an SP1 farm

  1. Attach the pre-SP1 content database to an SP1 farm.

  2. Run the Psconfig Upgrade command to upgrade the content database to SP1. For more information, see Psconfig command-line reference (SharePoint Foundation 2010).

  3. Detach the content database from the SP1 farm by following the directions in Attach or detach content databases (SharePoint Foundation 2010).

  4. Recover content from the unattached content database by following the procedure in Recover content from an unattached content database (SharePoint Foundation 2010).


Database management (SharePoint Foundation 2010)
See Also

This section describes techniques for managing the databases that are associated with Microsoft SharePoint Foundation 2010.

In this section:

  • Add a content database (SharePoint Foundation 2010)

    Adding a content database to an existing Web application is a common task. This article describes how to add a content database to an existing SharePoint Foundation 2010 implementation.

  • Attach or detach content databases (SharePoint Foundation 2010)

    Certain operations, such as applying updates or creating copies of configuration settings, require that you detach and then attach databases. This article describes how to do these procedures.

  • Move site collections between databases (SharePoint Foundation 2010)

    Under some circumstances, you might want to move one or more site collections to a different content database. For example, a site collection can outgrow the content database on which it is located, and you would have to move the site collection to a larger content database. Conversely, if site collections do not grow to their expected capacity, it might be convenient to combine several site collections onto one content database. This article describes how to move site collections between databases.

  • Move content databases (SharePoint Foundation 2010).

    This article describes how to move content databases between servers that are running Microsoft SQL Server, between instances of SQL Server, or from one Microsoft SharePoint Foundation 2010 Web application to another. You can also move a content database to load balance a database server or Web application.

  • Rename or move service application databases (SharePoint Foundation 2010)

    This article describes how to rename or move service application databases by using SQL Server, and then how to point the service application to the renamed or moved database. This can be a complex process because different types of service applications require different methods of pointing to the new database name or location. This article directs you to the supported method of pointing to a renamed or moved database for each service application.

  • Move all databases (SharePoint Foundation 2010)

    This article describes how to move all of the databases associated with SharePoint Foundation 2010 from one database server to another database server. If your databases are hosted on different servers, this procedure applies to the database server that hosts the configuration database.

  • Scale out collaboration sites (SharePoint Foundation 2010)

    This article describes how to move RBS-enabled collaboration sites from content databases that are larger than 200GB to smaller content databases to achieve greater performance and to meet support requirements.

  • Run a farm that uses read-only databases (SharePoint Foundation 2010)

    A read-only farm can be part of a disaster recovery environment. Alternatively, it can be part of a highly available maintenance, patching, or upgrade environment that provides user access while another version of the farm is being updated. This article describes how to run a SharePoint Foundation 2010 farm in which content databases are set to be read-only (a read-only farm).

  • Managing Multi-Terabyte Content Databases with SharePoint 2010 (white paper)

    This paper provides guidance and procedures for administering content databases in three size ranges: up to 200 gigabytes (GB), 200 GB-4 terabytes (TB), and larger than 4 TB.

  • Database maintenance for SharePoint Foundation 2010

    This white paper provides information and guidelines for maintaining the databases that host data and configurations for SharePoint 2010 Products.

  • Manage RBS (SharePoint Foundation 2010)

    Remote BLOB Storage (RBS) is an add-on feature pack for Microsoft SQL Server 2008. RBS is designed to move the storage of binary large objects (BLOBs) from database servers to commodity storage solutions. If the content databases in SharePoint Foundation 2010 are 4 gigabytes (GB) or larger, consider using RBS as part of your data storage solution. This article introduces RBS.

See Also

Concepts

Database types and descriptions (SharePoint Foundation 2010)

Other Resources

Resource Center: Operations and Manageability for SharePoint Foundation 2010


Add a content database (SharePoint Foundation 2010)
See Also

You can use the procedures that are described in this article to create a new content database and attach it to a Web application.

In this article:

  • To add a content database to a Web application by using Central Administration

  • To add a content database to a Web application by using Windows PowerShell

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:

    1. Specify a Web application for the new database.

    2. Specify a database server to host the new database.

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

    4. Specify the name of the failover database server, if one exists.

    5. Specify the number of top-level sites that can be created before a warning is issued. By default, this is 2,000.

    6. Specify the total number of top-level sites that can be created in the database. By default, this is 5,000.

    7. Click OK.

To add a content database to a Web application by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. 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:

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

    For more information, see New-SPContentDatabase.

Note:

To attach an existing content database to a Web application, use the Windows PowerShell cmdlet Mount-SPContentDatabase. For more information, see 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.

See Also

Concepts

Attach or detach content databases (SharePoint Foundation 2010)
Move site collections between databases (SharePoint Foundation 2010)


Attach or detach content databases (SharePoint Foundation 2010)
See Also

This article describes how to attach or detach Microsoft SharePoint Foundation 2010 content databases by using the SharePoint Central Administration Web site or by using Windows PowerShell 2.0.

You might want to attach or detach content databases in the following situations:

  • You want to add a new content database for new site collections to keep content databases at a manageable size.

  • You have restored a content database from another farm and you want the sites that it contains to be accessible from a Web application.

  • You have archived site collections and you no longer need as many content databases. You can move the remaining site collections out of a content database and then detach the content database from the Web application. For more information, see Move site collections between databases (SharePoint Foundation 2010).

The steps to add a database and to attach a database are very similar. For more information about how to add a database, see Add a content database (SharePoint Foundation 2010).

To attach a content database 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 want to create a new content database at the same time that you attach it, the SharePoint farm service account must be a member of the SQL Server dbcreator fixed server role. To attach a content database to a Web application, the SharePoint farm service account must have db_owner permission for the content database.

    Tip:

    If the database already exists, it must be the same version as the Microsoft SharePoint 2010 Products farm or this operation will fail. To attach a content database that is a different version than the farm, use the Windows PowerShell 2.0 command in the following section.

  2. On the SharePoint Central Administration Web site, click Application Management.

  3. On the Application Management page, 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:

    1. Use the Web Application drop-down menu to select the Web application to which you want to attach a content database.

    2. Specify the database server that hosts the database.

    3. Specify the database name. If the database does not already exist, it will be created.

    4. Specify the authentication method for the database, and supply an account name and password if you are using SQL authentication.

      Important:

      The account name and password must already exist as a SQL Server login. We recommend that you use Windows authentication instead of SQL authentication because, by default, SQL authentication sends an unencrypted password to the computer that is running SQL Server. If you use SQL authentication, the SQL account requires the same SQL permissions as the SharePoint farm service account.

    5. Click OK.

To detach a content database 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. On the SharePoint Central Administration Web site, click Application Management.

  3. On the Application Management page, in the Databases section, click Manage content databases.

  4. Select the Web application for which you want to detach a content database.

  5. Click the content database that you want to detach.

  6. On the Manage Content Database Settings page, select the Remove content database check box.

    If the content database contains data, you will receive a warning. Click OK to continue with the operation.

  7. Click OK to confirm the detachment, or click Cancel to stop the operation without detaching the database.

    After detaching the content database in Central Administration, the content database still exists in SQL Server. If you want to permanently remove the content database, you must do so by using a SQL Server procedure.

To attach or detach a content database by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. The user account must also be a member of the SQL Serverdbcreator fixed server role on the SQL Server instance where the content database exists.

  2. If you are using the Remove-SPContentDatabase cmdlet to delete the content database from SQL Server at the same time that you detach it, you must also be a member of the SharePoint_Shell_Access role on the content database.

  3. On the Start menu, click All Programs.

  4. Click Microsoft SharePoint 2010 Products.

  5. Click SharePoint 2010 Management Shell.

  6. At the Windows PowerShell command prompt, type the appropriate command.

    • To attach an existing content database:

      Copy Code
      Mount-SPContentDatabase "<ContentDb>" -DatabaseServer "<DbServer>" -WebApplication http://SiteName

      Where:

      • <ContentDb> is the content database to be attached.

      • <DbServer> is the name of the database server.

      • http://SiteName is the name of the Web application to which the content database is being attached.

    • To detach a content database:

    Copy Code
    Dismount-SPContentDatabase "<ContentdBName>"

    Where <ContentdBName> is the name of the content database.

    Important:

    If you have multiple content databases that have the same name, you must use the content database GUID in this command instead of using the content database name. To retrieve the GUID of the content database, run the Get-SPContentDatabase cmdlet with no arguments.

    The Dismount-SPContentDatabase cmdlet detaches the content database from the Web application, but it does not delete the content database from SQL Server. After a content database is detached, you cannot delete it by using Windows PowerShell 2.0. You can only remove it by using SQL Server tools. If you want to delete the content database from SQL Server while you detach it, use the Remove-SPContentDatabase cmdlet instead.

For more information, see Mount-SPContentDatabase and Dismount-SPContentDatabase.

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.

See Also

Reference

Get-SPContentDatabase
New-SPContentDatabase
Remove-SPContentDatabase


Move site collections between databases (SharePoint Foundation 2010)
See Also

Published: March 17, 2011

Under some circumstances, you might want to move one or more site collections to a different content database. For example, a site collection can outgrow the content database on which it resides, and you would have to move the site collection to a larger content database. In Windows SharePoint Services 3.0, this process was also known as splitting a content database because of the name of the Stsadm command that was used to perform the procedure. In Microsoft SharePoint Foundation 2010, it is more accurate to view this procedure as moving the site collection to a larger database.

On the other hand, if site collections do not grow to their expected capacity, it might be convenient to combine several site collections onto one content database. In Windows SharePoint Services 3.0, this process was also known as merging content databases. During this process, no content databases are actually merged — the site collections are moved to and consolidated on a new database.

This article describes how to prepare for and move site collections between content databases.

You can move site collections between content databases by using the Stsadm command-line tool or Windows PowerShell 2.0 commands. There is no graphical user interface for this task.

Tip:

You can also move site collections by using Backup and Restore procedures. For information about how to do this, see Back up a site collection (SharePoint Foundation 2010) and Restore a site collection (SharePoint Foundation 2010)

To perform the procedures that are described in this article, verify that the user account has access to one of the servers on which Windows PowerShell 2.0 is running, and that the user account is a member of the following groups:

  • The db_owner fixed database role and the SharePoint_Shell_Access role in the SQL Server source content database, administration content database, destination content database, and configuration database.

  • The WSS_ADMIN_WPG group on the local computer.

For these procedures to work, the following conditions must be true:

  • The destination content database must already exist.

  • The source content database and destination content database must be located on the same instance of SQL Server.

  • The source content database and destination content database must be attached to the same Web application. For more information about how to add a content database to a Web application, see Add a content database (SharePoint Foundation 2010).

Important:

If you have applied the October 2010 cumulative update, the default behavior when moving site collections to another content database has changed. After the update is applied, auditing data is moved with the site collection. The auditing data is copied whether you use Central Administration or Windows PowerShell. This size of the auditing data varies depending upon the event collection settings for the site collection.

If the amount of auditing data is large, you can move the data to another database before moving the site collection. To do this, use the To archive and trim audit data by using Windows PowerShell procedure in this article.

In this article:

  • Determining the size of the source site collection

  • Moving site collections between content databases

Determining the size of the source site collection

Regardless of the reason for moving a site collection, you should always begin the task by determining the size of the site collection that is to be moved. You can then be sure that the destination hard disk can sufficiently contain the site collection contents. Verify that the destination hard disk has at least three times the free space that is required for the site collection.

Tip:

You can stay current about the space that site collections are using by creating site quotas and e-mail alerts. For more information about this feature, see Manage site quotas and locks (Windows SharePoint Services).

To determine the size of the site collection

  1. On the Start menu, click All Programs.

  2. Click SharePoint 2010 Products.

  3. Click SharePoint 2010 Management Shell.

  4. At the Windows PowerShell 2.0 command prompt, type the following commands:

    Copy Code
    $used = (Get-SPSiteAdministration -Identity <http://ServerName/Sites/SiteName>).DiskUsed
    Copy Code
    $used

    Where:

    • <http://ServerName/Sites/SiteName> is the name of the site collection.

    The amount of disk space that is being used by the specified site collection is stored in the $used variable, and is displayed at the command prompt when the second command is run.

    Note:

    The amount of disk space that is displayed does not include the disk space used by the auditing data that will be moved with the site collection.

For more information, see Get-SPSiteAdministration.

To archive and trim audit data 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    (Get-SPSite -Identity <http://ServerName/Sites/SiteName>).Audit.TrimAuditLog(deleteEndDate)

    Where:

    • <http://ServerName/Sites/SiteName> is the name of the site collection.

    To delete the audit data without archiving it first, type the following command:

    Copy Code
    (Get-SPSite -Identity <http://ServerName/Sites/SiteName>).Audit.DeleteEntries(deleteEndDate)

For more information, see Get-SPSite.

Moving site collections between content databases

You can use the Windows PowerShell command Move-SPSite to move site collections between content databases. Two procedures are provided here. The first procedure moves a single site collection to a new content database, and the second procedure moves multiple site collections to a new content database.

To move a single site collection

  • At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Move-SPSite <http://ServerName/Sites/SiteName> -DestinationDatabase <DestinationContentDb>

    Where:

    • <http://ServerName/Sites/SiteName> is the name of the site collection.

    • <DestinationContentDb> is the name of the destination content database.

To move multiple site collections

  • At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Get-SPSite -ContentDatabase <SourceContentDb> | Move-SPSite -DestinationDatabase <DestinationContentDb>

    Where:

    • <SourceContentDb> is the name of the original content database.

    • <DestinationContentDb> is the name of the destination content database.

    This command moves all site collections from the source content database to the destination content database.

For more information, see Move-SPSite.

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.

See Also

Concepts

Add a content database (SharePoint Foundation 2010)


Move content databases (SharePoint Foundation 2010)

Published: July 15, 2010

This article describes how you can move content databases between servers that are running Microsoft SQL Server, between instances of SQL Server, or from one Microsoft SharePoint Foundation 2010 Web application to another. You can move a content database to load-balance a database server or Web application.

Important:

This article only describes how to move content databases. For information about how to move other kinds of databases that are associated with SharePoint Foundation 2010, see Rename or move service application databases (SharePoint Foundation 2010) and Move all databases (SharePoint Foundation 2010).

Overview of moving content databases

When you move content databases, you must use both SharePoint Foundation 2010 tools and SQL Server tools. You can use either the SharePoint Foundation Central Administration Web site or Windows PowerShell 2.0. The following list summarizes how to move content databases:

  1. Record the name of the content database and which Web application it is associated with. For details, see To record which content databases are associated with each Web application.

  2. Pause any service applications and services that may attempt to run against the database, including timer jobs and search crawls. For details, see To pause timer jobs by using Windows PowerShell (option 1) or To pause timer jobs by using Central Administration (option 2).

  3. In SharePoint Foundation, remove the content database from the Web application. You can perform this action by using Central Administration or Windows PowerShell 2.0. In general, if you are only working with more than one database, it may be faster to write a Windows PowerShell 2.0 script. For details, see To detach the content databases from a Web application by using Central Administration (option 1) or To detach content databases from a Web application by using Windows PowerShell (option 2).

  4. In SQL Server, detach the database from the current instance. For details, see To detach the content databases from SQL Server.

  5. Using Windows Explorer, copy or move the .mdf, .ndf, and .ldf files associated with the database from the source location to the destination location. For details, see To move the content databases to a new location.

    Note:

    You can also back up and restore databases to move them. However, backup and recovery are not described in this article. For information, see Backup and recovery (SharePoint Foundation 2010).

  6. In SQL Server, attach the database to the new instance. For details, see To attach the content databases to the new instance of SQL Server.

  7. In SharePoint Foundation, add the content database to the destination Web application. Be sure that you use exactly the same name when you reattach the content database. Otherwise, SharePoint Foundation creates a new content database. You can use either Central Administration or Windows PowerShell 2.0 to perform this action. For details, see To attach the content databases to the Web application by using Central Administration (option 1) or To attach content databases to a Web application by using Windows PowerShell (option 2).

  8. Restart any service applications and services that should be run against the database, including timer jobs and search crawls. For details, see To restart timer jobs by using Windows PowerShell (option 1) or To restart timer jobs by using Central Administration (option 2).

Moving content databases

Note:

Membership in the Administrators group on the local computers is required to complete the following procedures. If you are running SharePoint Foundation 2010 in a least-privileged environment, and you are running procedures from within Central Administration, ensure that you have the following roles in SQL Server:

  • The dbowner fixed database role for the configuration database and the content database on the source server, in order to detach the content database.

  • The dbcreator and securityadmin fixed server roles on the destination server, in order to attach the database and configure SQL Server logins.

Note:

If you are moving a content database to a different farm, you must make the server farm account a member of the Administrators group on the database server during the restore process. This enables the account to replicate the security setting for the databases. This access level can be removed after the content database has been moved.

The destination farm must be running the same version or a later version of SharePoint Foundation 2010 than the source farm is running.

To record which content databases are associated with each Web application

  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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Get-SPContentDatabase -WebApplication <http://SiteName>

    Where <http://SiteName> is the URL of the Web application.

  6. Repeat for each Web application.

For more information, see Get-SPContentDatabase.

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 pause timer jobs by using Windows PowerShell (option 1)

  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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Get-SPTimerJob -webapplication <http://WebApplicationURL> | select name | Out-File <c:\timerjobfile.txt> -Append -Encoding ascii

ForEach($tmrjob in (Get-Content <c:\timerjobfile.txt>)) { Get-SPTimerJob -Identity $tmrjob | Disable-SPTimerjob }

    Where:

    • <http://WebApplicationURL> is the Web application associated with the content database that you are moving.

    • <c:\timerjobfile.txt> is the location of the file that you are creating that lists all timer jobs associated with the Web application.

For more information, see Get-SPTimerJob, Out-File, ForEach-Object, Get-Content, and Disable-SPTimerJob.

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 pause timer jobs by using Central Administration (option 2)

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.

  2. In Central Administration, in the Monitoring section, click Check Job Status.

  3. For each scheduled job that runs against the content database that you are moving, click the job to open the Edit Timer Job page, click Disable, and then click OK.

To detach the content databases from a Web application by using Central Administration (option 1)

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.

  2. In Central Administration, in the Application Management section, click Manage Content databases.

  3. On the Manage Content Databases page, click the content database that you want to move.

    The Manage Content Database Settings page opens.

    Note:

    If the content database does not appear in the list, it might be associated with another Web application. To select another Web application, on the Web Application menu, click Change Web Application.

  4. On the Manage Content Database Settings page, in the Remove Content Database section, select the Remove content database check box, and then click OK.

    Note:

    Removing the content database does not delete the database; it only removes the association of the database with the Web application.

  5. Repeat steps 3 and 4 for each content database that you want to move.

To detach content databases from a Web application by using Windows PowerShell (option 2)

  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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Dismount-SPContentDatabase "<ContentDB>"

    Where <ContentDB> is the name of the content database.

    Note:

    If you have multiple content databases that have the same name, you must use the content database GUID in this command instead of using the content database name. To retrieve the GUID of the content database, run the Get-SPContentDatabase cmdlet without arguments.

For more information, see Dismount-SPContentDatabase and Get-SPContentDatabase.

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 detach the content databases from SQL Server

  1. Verify that the user account that is performing this procedure is a member of the db_owner fixed database role on the database server where each database is stored.

  2. In SQL Server Management Studio, open the source SQL Server instance, and then expand the Databases node.

  3. Right-click the content database, point to Tasks, and then click Detach. Repeat this step for each content database that you want to move.

    Note:

    Use this procedure to move only content databases. Do not detach any other kinds of databases.

To move the content databases to a new location

  1. Verify that the user account that is performing this procedure has Write access to both the source and destination folders.

  2. Using Windows Explorer, locate the .mdf, .ldf, and .ndf files for the content databases.

  3. Select the .mdf, .ldf, and .ndf files for the database that you want to move and either copy or move them to the destination directory.

To attach the content databases to the new instance of SQL Server

  1. Verify that the user account that is performing this procedure is a member of the dbcreator fixed server role on the database server where each database is stored.

  2. In Management Studio, open the destination SQL Server instance.

  3. Right-click the Databases node, point to Tasks, and then click Attach.

  4. In the Attach Database dialog box, browse to where you transferred the .mdf, .ldf, and .ndf files, select the .mdf file for the database that you want to attach, and then click OK.

  5. Repeat for each content database that you are moving.

To attach the content databases to the Web application by using Central Administration (option 1)

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. In Central Administration, in the Application Management section, click Manage Content databases.

  3. On the Manage Content Databases page, click Add a content database.

  4. On the Add Content Database page, verify that the Web Application menu displays the correct Web application.

  5. In the Server box, specify the database server that hosts the database.

  6. In the Database Name box, type the exact name of the transferred content database.

    Note:

    Verify that the name is correct. If it is not, a new database will be created.

  7. Specify the authentication method for the database, and then click OK.

  8. Repeat these steps for each database that you are adding. Be sure that you select the correct Web application from the Web Application menu for each database.

To attach content databases to a Web application by using Windows PowerShell (option 2)

  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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Mount-SPContentDatabase "<ContentDB>" -DatabaseServer "<DBServer>" -WebApplication <http://SiteName>

    Where:

    • <ContentDB> is the content database to be attached.

    • <DBServer> is the name of the database server.

    • <http://SiteName> is the URL of the Web application to which the content database is being attached.

For more information, see Mount-SPContentDatabase.

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 restart timer jobs by using Windows PowerShell (option 1)

  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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    ForEach($tmrjob in (Get-Content <c:\timerjobfile.txt>)) {Get-SPTimerJob -Identity $tmrjob | Enable-SPTimerjob}

    Where:

    • <c:\timerjobfile.txt> is the location of the file that you created that lists all of the timer jobs associated with the Web application.

For more information, see Get-SPTimerJob, ForEach-Object, Get-Content, and Enable-SPTimerJob.

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 restart timer jobs by using Central Administration (option 2)

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. In Central Administration, in the Monitoring section, click Check Job Status.

  3. For each scheduled job that you disabled previously, click the job to open the Edit Timer Job page, click Enable, and then click OK.


Rename or move service application databases (SharePoint Foundation 2010)
See Also

Published: July 22, 2010

This article describes how to rename or move Microsoft SharePoint Foundation 2010 service application databases. Renaming service application databases is typically done to remove the GUID from the database name after the databases have been created by the SharePoint Products Configuration Wizard, or to bring the databases into alignment with your organization's naming standards. Moving service application databases can be done to load-balance a system.

The general process for renaming or moving service application databases is as follows:

  1. Rename or move the database by using SQL Server tools.

  2. Point the service application to the renamed or moved database.

    Pointing a service application to a renamed or moved service application database can be a complex process, especially if you must rename or move the databases for multiple service applications. This is because different types of service applications require different methods of pointing to the new database name or location. Based on the service application database that you are renaming or moving, you will use one of the following methods to point the service application to the renamed or moved database:

    • Delete the service application, re-create the service application, and then point the service application to the existing renamed or moved database.

      You can use this method for most service application databases, but this method can be complex for some service applications, such as Search.

    • Use Windows PowerShell to point the service application to the renamed or moved changed database.

      You can also use Central Administration for a subset of the service application databases that you can use Windows PowerShell to point to. When possible, we recommend that you use Central Administration to rename or move databases because that is the easiest way to perform the operation. Windows PowerShell is available for only some service application databases, and Central Administration is available for a subset of those service applications.

The following table shows the methods that can be used to point each service application to a renamed or moved database.

Methods available for pointing to renamed or moved service application databases

Service application or database | Delete and re-create service application | Use Windows PowerShell | Use Central Administration
Usage and Health Data Collection | Possible | Possible | Preferred
Business Data Connectivity | Preferred | Not available | Not available1
Application Registry2 | Not available | Not available | Not available
Subscription settings | Possible | Preferred | Not available

1It may appear that you can rename the Business Data Connectivity database in Central Administration or by using the Windows PowerShell cmdlet Set-SPBusinessDataCatalogServiceApplication. However, using either Central Administration or Set-SPBusinessDataCatalogServiceApplication creates a new database. It does not rename the existing database.

2Because there is no Windows PowerShell cmdlet to create the Application Registry service application, it cannot be renamed. It can be moved by using Microsoft SharePoint Foundation 2010 backup and recovery.

In this article:

  • Renaming or moving service application databases by using SQL Server

    This method includes the following procedures:

    • To stop a service application

    • To rename a database by using SQL Server Management Studio

    • Move a database by using SQL Server Management Studio and Windows Explorer

  • General method for pointing a service application to a renamed or moved database

    This method includes the following procedures:

    • To document service application settings

    • To delete a service application

    • To re-create a service application

    • To restart a service application

    Note:

    This method does not apply to all service application databases. Refer to the guidance for the specific service application to determine which method to use.

  • Service application-specific guidance for renaming or moving databases

    • Pointing the Usage and Health Data Collection service application to a renamed or moved database

    • Pointing the Business Data Connectivity service application to a renamed or moved database

    • Pointing the Application Registry service application to a renamed or moved database

    • Pointing the Subscription Settings service application to a renamed or moved database

Renaming or moving service application databases by using SQL Server

To rename a service application database, you must use SQL Server. To move a service application database, you must use SQL Server and Windows Explorer. We recommend that you stop the services related to the service application before you rename or move the related database. In general, we expect that you will either rename or move a database. That is, you will typically not perform both actions.

The instructions in this article assume that you have installed SQL Server Management Studio on the database server. If this is not the case, you can download and install Management Studio at Microsoft SQL Server 2008 Management Studio Express (http://go.microsoft.com/fwlink/p/?LinkID=186132&clcid=0x409).

Important:

On the database servers on which the operations are performed, you must be a member of the following:

  • Administrators group on the local server

  • db_owner fixed database role

In some environments, you must coordinate the rename and move procedures with the database administrator. Be sure to follow any applicable policies and guidelines for managing databases.

To stop a service application

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.

  2. For each service application that you plan to change the database for, you must stop the service or disable the service application by following the appropriate procedure for the service application that you are working with. For more information, see Manage service applications (SharePoint Foundation 2010) .

To rename a database by using SQL Server Management Studio

  1. In SQL Server Management Studio, connect to the source SQL Server instance, and then expand the Databases node.

  2. Right-click the database that you want to rename, click Rename, and then type the new name. Repeat this step for each database that you want to rename.

Move a database by using SQL Server Management Studio and Windows Explorer

Moving a database requires detaching the database from SQL Server, moving the files to the new location by using Windows Explorer, and then attaching the database to the new instance of SQL Server.

To detach a database from SQL Server

  1. In SQL Server Management Studio, open the source SQL Server instance, and then expand the Databases node.

  2. Right-click the database, point to Tasks, and then click Detach. Repeat this step for each database that you want to move.

To move database files to a new location by using Windows Explorer

  1. In Windows Explorer, locate the .mdf, .ndf, and .ldf files for the service application databases.

  2. Select the .mdf, .ndf, and .ldf files for the databases that you want to move, and then either copy or move them to the destination directory.

To attach a database to a new instance of SQL Server

  1. In Management Studio, open the destination SQL Server instance.

  2. Right-click the Databases node, point to Tasks, and then click Attach.

  3. In the Attach Database dialog box, browse to where you transferred the .mdf, .ndf, and .ldf files, select the .mdf file for the database that you want to attach, and then click OK.

  4. Repeat for each database that you are moving.

General method for pointing a service application to a renamed or moved database

The method for pointing a service application to a renamed or moved database that works for most service applications is to delete the service application and then re-create the service application. When you re-create the service application, use the new name or new location.

This is the only method that can be used to point to moved or renamed databases for the Business Data Connectivity service application.

This method includes the following steps:

  1. To document service application settings

  2. To delete a service application

  3. To re-create a service application

  4. To restart a service application

To document service application settings

  • Before you delete and re-create a service application, document the settings for the service application. To do this, use the recommended Windows PowerShell cmdlets that are described in the article Document farm configuration settings (SharePoint Foundation 2010) .

To delete a service application

  • To delete a service application, follow the procedure in Delete a service application (SharePoint Foundation 2010), but do not delete the service application database.

To re-create a service application

  • Re-create the service application, pointing it to the renamed database, and reusing all the other initial configuration settings. For more information, see the following articles:

    • Configure usage and health data collection (SharePoint Foundation 2010)

    • Enabling Multi Tenant Support in SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=197114)

    • Business Data Connectivity service administration (SharePoint Foundation 2010)

  • Depending on the service application, you may have to manually start the related service.

To restart a service application

  1. In Central Administration, under System Settings, click Manage services on server.

  2. In the Service list, next to the appropriate service or services that support the service application that you are restarting, click Start.

Service application-specific guidance for renaming or moving databases

This section describes specific guidance for each kind of service application.

Pointing the Usage and Health Data Collection service application to a renamed or moved database

You can use either Central Administration or Windows PowerShell to point the Usage and Health Data Collection service application to a renamed or moved database.

To point the Usage and Health Data Collection service application to a renamed or moved database by using Central Administration

  1. Verify that the user account that is performing the procedure is a member of the Farm Administrators SharePoint group.

  2. In Central Administration, click Monitoring, and then on the Monitoring page, click Configure usage and health data collection.

    The Configure web analytics and health data collection page appears.

  3. Clear the Enable health data collection check box, and then click OK.

    You return to the Monitoring page.

  4. Click Configure usage and health data collection to return to the Configure web analytics and health data collection page.

  5. Select the Enable health data collection check box

  6. In the Logging Database Server section, specify the updated database server and database name, and then click OK.

To point the Usage and Health data collection service application to a renamed or moved database 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Set-SPUsageApplication -Identity "<ServiceApplicationName>" -DatabaseName "<DbName>" -DatabaseServer "<SQLServerName>"

    Where:

    • <ServiceApplicationName>is the name of the usage and health data collection service application.

    • <DbName> is the name of the database.

    • <SQLServerName> is the name of the database server.

For more information, see Set-SPUsageApplication.

Pointing the Business Data Connectivity service application to a renamed or moved database

You must delete the Business Data Connectivity service application, rename or move the database, and then re-create the service application to point to a renamed or moved database. For information, see General method for pointing a service application to a renamed or moved database.

Pointing the Application Registry service application to a renamed or moved database

Because there is no Windows PowerShell cmdlet to create the Application Registry service application, the associated database cannot be renamed. You can move the database by using SharePoint Foundation 2010 backup and recovery. For more information, see Back up a service application (SharePoint Server 2010) and Restore a service application (SharePoint Server 2010) Back up a service application (SharePoint Foundation 2010) and Restore a service application (SharePoint Foundation 2010).

Pointing the Subscription Settings service application to a renamed or moved database

You can point the Subscription Settings service application to a renamed or moved database by using Windows PowerShell.

To point the Subscription Settings service application to a renamed or moved database by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. Record the Subscription Settings service application name and the database name that you plan to configure.

  3. On the Start menu, click All Programs.

  4. Click Microsoft SharePoint 2010 Products.

  5. Click SharePoint 2010 Management Shell.

  6. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Set-SPSubscriptionSettingsServiceApplication -Identity "<ServiceApplicationName>" -DatabaseName "<DatabaseName>" -DatabaseServer "<DatabaseServer>"

    Where:

    • <ServiceApplicationName> is the name of the Subscription Settings service application.

    • <DatabaseName> is the name of the renamed or moved database.

    • <DatabaseServer> is the location of the renamed or moved database. Do not include this parameter if you are just renaming the database in the same location.

    For more information, see Set-SPSubscriptionSettingsServiceApplication.

See Also

Concepts

Deploy by using DBA-created databases (SharePoint Foundation 2010)
Database types and descriptions (SharePoint Foundation 2010)
Manage service applications (SharePoint Foundation 2010)


Move all databases (SharePoint Foundation 2010)

Published: June 17, 2010

This article describes how to move all of the databases associated with Microsoft SharePoint Foundation 2010 from one database server to another database server. If your databases are hosted on different servers, this procedure applies to the database server that hosts the configuration database. For moving content databases only, see Move content databases (SharePoint Foundation 2010). For moving service application databases only, see Rename or move service application databases (SharePoint Foundation 2010).

Important:

Moving databases makes all farm sites and assets unavailable to users until the process is completed.

The following kinds of databases hosted on a single database server can be moved by using the procedures in this article:

  • Configuration database

  • Central Administration content database

  • Content databases

  • Service application databases

Moving all databases

The process of moving all of the databases from one database server to another database server requires you to work in both SharePoint Foundation 2010 and SQL Server. The following list summarizes the process of moving all databases, with detailed steps presented in the subsequent procedures:

  1. Prepare the new database server. For details, see To prepare the new database server.

  2. Close any open Windows PowerShell management shell windows and any open Stsadm command prompt windows. For details, see To close any open management sessions.

  3. In the Services Microsoft Management Console snap-in, stop all of the services related to SharePoint Foundation 2010 and Internet Information Services (IIS). For details, see To stop the farm.

  4. In SQL Server, detach the databases from the current instance. For details, see To detach databases.

  5. Using Windows Explorer, copy or move the .mdf, .ldf, and .ndf files associated with the database from the source server to the destination server. For details, see To move database files to the new server.

    Note:

    You can also back up all databases and restore them to the new server. Procedures for backing up and restoring all databases are not included in this article. For more information, see How to: Back Up a Database (SQL Server Management Studio) (http://go.microsoft.com/fwlink/p/?LinkID=179208) and How to: Restore a Database Backup (SQL Server Management Studio) (http://go.microsoft.com/fwlink/p/?LinkID=183032).

  6. In SQL Server, ensure that all of the SQL Server logins, fixed server roles, fixed database roles, and permissions for the databases from the source server have also been configured correctly on the destination server. For details, see To set up permissions on the new server.

  7. In SQL Server, attach the database to the new instance. For details, see To attach databases to the new instance of SQL Server.

  8. Use SQL Server connection aliases to point to the new database server, and then use the connection alias to update all Web servers. A connection alias is a defined alternate name that can be used to connect to an instance of SQL Server. You have to configure the alias on all Web servers and application servers in the farm. For details, see To point the Web application to the new database server by setting up SQL Server connection aliases.

    Note:

    The use of SQL Server client aliases is recommended as part of hardening SQL Server for SharePoint environments. For more information, see Harden SQL Server for SharePoint environments (SharePoint Foundation 2010).

  9. Restart the services. For details, see To restart the services in the farm.

The following are the minimum permissions that are required to perform this process:

  • You must be a member of the Farm Administrators SharePoint group.

  • On the computer that is running the SharePoint Central Administration Web site, you must be a member of the Administrators group.

  • On the database server from which the databases are being moved, you must be a member of the following:

    • The Administrators group

    • The db_backupoperator fixed database role

  • On the database server to which the databases are being moved, you must be a member of the following:

    • The Administrators group

    • The db_owner fixed database role

In some environments, you must coordinate the move procedures with the database administrator. Be sure to follow any applicable policies and guidelines for managing databases.

To prepare the new database server

  • Configure the new database server by using the procedures in the article Harden SQL Server for SharePoint environments (SharePoint Foundation 2010).

    Note:

    The new database server must be running the same version of Windows Server and Microsoft SQL Server as the existing database server.

To close any open management sessions

  • Close any open Windows PowerShell management shell windows, and any open command prompt windows if you have been running the Stsadm command-line tool.

To stop the farm

  1. On the server that is running the Central Administration Web site, in the Services snap-in, stop the following services:

    • SharePoint 2010 Administration

    • SharePoint 2010 Timer

    • SharePoint 2010 Tracing

    • SharePoint 2010 User Code Host

    • SharePoint 2010 VSS Writer

    • SharePoint Foundation Search V4

    • World Wide Web Publishing Service

  2. On the server that is running the Central Administration Web site, at the command prompt, type iisreset /stop.

To detach databases

  • In SQL Server Management Studio on the original database server, detach the databases that you want to move from the instance that they are attached to. If you are running many databases, you may want to run a Transact-SQL script to detach databases.

    Note:

    A database cannot be detached if any one of the following is true:

    • The database is being mirrored.

    • A database snapshot exists on the database.

    For more information, see:

    • Detaching and Attaching Databases (http://go.microsoft.com/fwlink/p/?LinkId=194806)

    • How to: Detach a Database (SQL Server Management Studio) (http://go.microsoft.com/fwlink/p/?LinkId=194807)

    • sp_detach_db (Transact-SQL) (http://go.microsoft.com/fwlink/p/?LinkId=194808)

To move database files to the new server

  • Using Windows Explorer, locate the .mdf, .ldf, and .ndf files associated with each database that you are moving, and then copy or move them to the destination directory on the new computer that is running SQL Server.

To set up permissions on the new server

  • On the destination database server, open SQL Server Management Studio and transfer your logins and permissions from the original instance to the destination instance. We recommend that you transfer permissions by running a script. An example script is available in Knowledge Base article 918992: How to transfer the logins and the passwords between instances of SQL Server 2005 (http://go.microsoft.com/fwlink/p/?LinkId=122053).

    For more information about how to transfer SQL Server metadata between instances, see the SQL Server Books Online article Managing Metadata When Making a Database Available on Another Server Instance (http://go.microsoft.com/fwlink/p/?LinkId=122055).

To attach databases to the new instance of SQL Server

  • On the destination database server, attach the databases to the new instance. For more information, see How to: Attach a Database (SQL Server Management Studio) (http://go.microsoft.com/fwlink/p/?LinkId=194809) and sp_attach_db (Transact-SQL) (http://go.microsoft.com/fwlink/p/?LinkId=194810).

To point the Web application to the new database server by setting up SQL Server connection aliases

  1. Start SQL Server Configuration Manager. On the Start menu, point to All Programs, point to Microsoft SQL Server 2008, point to Configuration Tools, and then click SQL Server Configuration Manager.

    Note:

    If SQL Server Configuration Manager is not installed, you must run SQL Server setup to install it.

  2. Expand SQL Native Client Configuration, right-click Aliases, and then click New Alias.

  3. In the Alias Name field, enter the name of the original SQL Server instance, for Protocol, verify that TCP/IP is selected, for Server, enter the name of the new server that is hosting the SharePoint Foundation 2010 databases, and then click OK.

  4. Repeat this procedure on each Web and application server.

  5. Optional. If your environment relies on System Center Data Protection Manager (DPM) 2010 or a third-party application that uses the Volume Shadow Copy Service (VSS) framework for backup and recovery, you must install the SQL Server connectivity components on each Web server or application server by running SQL Server setup. For more information, see How to: Install SQL Server 2008 R2 (Setup) (http://go.microsoft.com/fwlink/p/?LinkID=186119).

To reconfigure Web Analytics database locations

  1. Note:

    This procedure is required only if you are running a Web Analytics service application and if you have renamed your server instead of using SQL Server connection aliases.

    On the SharePoint Central Administration Web site, under Application Management, click Manage Service Applications.

  2. Select the Web Analytics service application, and then click Properties.

    The Edit Web Analytics Service Application wizard appears.

  3. Click Next.

  4. On the second page of the wizard, update the location of each Web Analytics database to the new SQL Server instance, and then click Next.

  5. In Central Administration, under System Settings, click Manage Services on Server.

  6. Stop and restart the Web Analytics Data Processing Service, and the Web Analytics Web Service.

    Note:

    The SharePoint Web Analytics feature relies on SQL Server service broker to function. The SQL Server service broker cannot be started manually. A SharePoint timer job runs one time per day to ensure that SQL Server service broker is enabled on the necessary databases.

  7. After moving databases, you should manually run the health rule "Web Analytics: Verifies that the SQL Server Service Broker is enabled for the Web Analytics staging databases." To manually run the health rule, follow these steps:

    • In Central Administration, click Monitoring.

    • In the Health Analyzer section, click Review rule definitions.

      The All Rules page is displayed.

    • Under Category: Configuration, click the health rule Web Analytics: Verifies that the SQL Server Service Broker is enabled for the Web Analytics staging databases.

      The Health Analyzer Rule Definition dialog box opens.

      Note:

      In order to see the health rule, you may need to click the right arrow at the bottom of the All Rules page.

    • On the ribbon of the Health Analyzer Rule Definitions dialog box, click Run Now.

To restart the services in the farm

  1. On the server that is running the Central Administration Web site, at the command prompt, type iisreset /start.

  2. In the Microsoft Management Console Services snap-in, start all of the services related to SharePoint and Internet Information Services (IIS). These include the following services:

    • SharePoint 2010 Administration

    • SharePoint 2010 Timer

    • SharePoint 2010 Tracing

    • SharePoint 2010 User Code Host

    • SharePoint 2010 VSS Writer

    • SharePoint Foundation Search V4

    • World Wide Web Publishing Service


Scale out collaboration sites (SharePoint Foundation 2010)
See Also

Published: July 14, 2011

This article describes how to scale out Microsoft SharePoint Foundation 2010 collaboration sites when you are using Remote BLOB Storage (RBS) and Microsoft SQL Server.

Before you implement RBS, we highly recommend that you evaluate its potential costs and benefits. For more information and recommendations about how to use RBS in a SharePoint Foundation 2010 installation, see Plan for RBS (SharePoint Foundation 2010).

Note:

Unless otherwise specified, the information in this article is specific to RBS using the FILESTREAM provider. For guidance specific to another provider, contact the provider manufacturer.

In this article:

  • About RBS and collaboration sites

  • About scaling out collaboration sites

  • Scaling out site collections by performing a shallow move

  • Scaling out site collections by performing a deep move

About RBS and collaboration sites

Collaboration sites store information that people and groups can collectively author, share, and revise. However, collaboration sites typically require more input/output (I/O) resources and consume more disk space as documents are revised. The use of RBS-enabled content databases over 200 gigabytes (GB) with collaboration sites is not supported. Because collaboration sites have larger I/O requirements and because of the support limits for RBS, you might want to scale out collaboration sites by moving them onto one or more separate content databases. For more information about RBS support limits, see the "Content database limits" section in SharePoint Server 2010 capacity management: Software boundaries and limits. For more information about how to plan collaboration sites, see Collaboration site planning (SharePoint Server 2010).

As documents are revised, data is sent over the network to and from the SharePoint content database. This results in more network bandwidth being used, especially if the documents are very large. This is especially the case if a document is being edited by many people at the same time, or many documents are being revised at the same time.

Documents in libraries are stored as unstructured data, or Binary Large Objects (BLOBs). Because BLOBs are immutable, a new BLOB is stored in the library for each revision. If you have enabled minor versioning, these BLOBs can consume disk space very quickly.

You can improve performance of highly-collaborative sites that have large documents by using RBS and by moving content onto separate content databases of 200 GB or smaller. This includes the stored BLOB data.

About scaling out collaboration sites

You can use the Windows PowerShellMove-SPSite command to move the site collections and the BLOB data from the large RBS-enabled content database (that is, more than 200 GB) to one or more smaller RBS-enabled content databases. You can do this in either of the following ways:

  • Shallow move. If you have installed Microsoft SQL Server 2008 R2 with Service Pack 1 (SP1), you can use the Move-SPSite cmdlet with the RBSMappingProvider parameter. This will move only the metadata. The BLOB data will not be moved. Although this operation is much faster than the deep move procedure that is described later in this article, it has the following requirements:

    • You must have installed SQL Server 2008 R2 with SP1.

    • You must have upgraded the content database to the new SP1 schema.

    • The RBS provider for both the source and destination content databases must support the RBSMappingProvider parameter.

    • You must have created the site collection after you installed SQL Server 2008 R2 with SP1 or you moved the site collection by using the Move-SPSite cmdlet after you installed SQL Server 2008 R2 with SP1.

  • Deep move. If you have not installed SQL Server 2008 R2 with SP1, you can use the Move-SPSite cmdlet. However, doing this moves both the metadata and the BLOB data. This operation can take a long time.

Scaling out site collections by performing a shallow move

You can use Windows PowerShell to move the site collections and the BLOB data from the large content database (that is, more than 200 GB) to one or more smaller databases.

To perform a shallow move of site collection metadata 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Move-SPSite -Identity <SiteCollectionName> -DestinationDatabase <DatabaseName> -RbsProviderMapping @{"<SourceProvider>"="<TargetProvider>",…}

    Where:

    • <SiteCollectionName> is the site collection that you want to move — for example, http://ServerName/Sites/SiteName.

    • <DatabaseName> is name of the content database to which you want to move the site collection — for example, ContentDB2.

    • <SourceProvider> is the value of the source RBS stores.

    • <TargetProvider> is the value of the target RBS stores.

      Note:

      You can move more than one site collection by typing multiple <SourceProvider> to <TargetProvider> pairs inside the braces.

For more information, see Move-SPSite.

Scaling out site collections by performing a deep move

Note:

Because a deep move moves the actual BLOB data, the operation can take a long time and can use lots of disk and network resources while the operation is occurring. You should plan a deep move carefully and run the procedure during off-peak hours. We recommend that you perform a shallow move if that is possible.

To perform a deep move of BLOB data and site collection metadata 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Move-SPSite -Identity <SiteCollectionName> -DestinationDatabase <DatabaseName>

    Where:

    • <SiteCollectionName> is the identity of the site collection that you want to move — for example, http://ServerName/Sites/SiteName.

    • <DatabaseName> is name of the content database to which you want to move the site collection — for example, ContentDB2.

For more information, see Move-SPSite.

See Also

Reference

Move-SPSite

Concepts

Plan for RBS (SharePoint Foundation 2010)

Other Resources

SharePoint Server 2010 capacity management: Software boundaries and limits
Collaboration site planning (SharePoint Server 2010)


Run a farm that uses read-only databases (SharePoint Foundation 2010)

This article describes how to run a Microsoft SharePoint Foundation 2010 farm in which some or all databases are set to be read-only (a read-only farm).

A farm is considered to be read-only if any of the following are true:

  • All content databases are set to read-only.

  • Service application databases are set to read-only.

The functionality and user experience in a read-only farm depends on which databases are set to read-only.

A farm that uses read-only content and service application databases is likely to be part of a disaster recovery environment or a highly available maintenance, update, or upgrade environment.

Procedures in this task:

  • Prepare users for the read-only experience

  • Set content databases to be read-only

  • Set service application databases to be read-only

Prepare users for the read-only experience

If you plan to provide users with access to a read-only site or farm, you should set expectations for what they will be able to do on the site and how the user interface (UI) will differ.

Sites that use read-only content databases

The user experience of a site that uses a content database that is set to read-only is characterized by the following:

  • Common tasks that do not require writing to the content database are fully available.

  • Most of the common tasks that require writing to the content database are not available, either because they have been disabled in the UI, or because the user is no longer allowed to apply changes.

  • Some common tasks that require writing to the content database appear to be available, but return errors.

For detailed information about the user experience on a read-only site, see User experience on read-only sites (SharePoint Foundation 2010).

Farms that use read-only service application databases

The user experience of a farm that uses service application databases that are set to read-only is characterized by the following:

  • Common tasks that do not require writing to the service databases are fully available.

  • All common tasks that require writing to the service databases appear to be available, but return errors.

Set content databases to be read-only

Before you set content databases to be read-only, you may need to determine which content database is associated with a particular site collection.

To determine which content database is associated with a site collection

  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. At the Windows PowerShell command prompt (PS C:\>), type the following command, and then press ENTER:

    Get-SPContentDatabase -Site <Site URL>

    -Site specifies the site collection for which you want to know the associated content database.

    The command returns the content database associated with the site.

For more information, see Get-SPContentDatabase.

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.

You can use the following procedure to set read/write content databases to be read-only by using SQL Server Management Studio. You can also use the Transact-SQL ALTER DATABASE statement to set content databases to be read-only. For more information, see ALTER DATABASE (Transact-SQL) (http://go.microsoft.com/fwlink/p/?LinkId=148619).

Important:

Do not perform this procedure on databases in a failover environment that have been log-shipped or mirrored.

To set content databases to be read-only

  1. Verify that you have the following administrative credentials: You must be a member of the db_owner fixed database role in each database.

  2. Open SQL Server Management Studio.

  3. Right-click the content database that you want to change to read-only, and then click Properties.

  4. Select the Options page, and, in the Other options list, scroll to the State section.

  5. In the Database Read-Only row, click the arrow next to False, select True, and then click OK.

  6. Repeat for all other content databases.

    Note:

    When a database is set to read-only, all connections except the one that is setting the read-only flag are stopped. After the read-only flag is set, other connections are enabled.

The site collection that is associated with a read-only content database is automatically set to be read-only if the locking status of the site collection was previously None, No Additions, or Read-Only. If the locking status of the site collection was previously No Access, it remains No Access when the database locking status is changed.

Set service application databases to be read-only

It is possible to set any service application database to be read-only. However, some service applications do not function when their databases are set to read-only.

To set service application databases to be read-only

  1. Verify that you have the following administrative credentials: You must be a member of the db_owner fixed database role in each database.

  2. Open SQL Server Management Studio.

  3. Right-click the database that you want to change to read-only, and then click Properties.

  4. Select the Options page, and, in the Other options list, scroll to the State section.

  5. In the Database Read-Only row, click the arrow next to False, select True, and then click OK.

  6. Repeat for other service application databases as appropriate.

    Note:

    When a database is set to read-only, all connections except the one that is setting the read-only flag are stopped. After the read-only flag is set, other connections are enabled.


Managing Multi-Terabyte Content Databases with SharePoint 2010 (white paper)

Published: July 14, 2011

In this white paper, Senior Technical Product Manager and Microsoft Certified Master for SharePoint, Bill Baer, explains how to manage large content databases in Microsoft SharePoint Foundation 2010. The paper discusses content databases in three size ranges: up to 200 gigabytes (GB), 200 GB-4 terabytes (TB), and larger than 4 TB. These ranges have different limitations, recommended architectures, and operational requirements. The paper provides detailed guidance for capacity management, performance, data protection, and maintenance of large content databases.

You can download the white paper in any of the following formats:

  • Word

  • PDF

  • XPS


Database maintenance for SharePoint Foundation 2010
See Also

Published: May 12, 2011

Summary: Learn how to maintain the databases that host data and configuration settings for Microsoft SharePoint 2010 Products. Read guidelines and study examples of the recommended database maintenance strategies and tasks.

Applies to: Microsoft SharePoint Server 2010, Microsoft SharePoint Foundation 2010

Authors: Bill Baer and Bryan Porter

Technical Reviewer: Paul S. Randal (SQLskills.com)

Contents

  • Introduction

  • Using Database Console Command (DBCC) CHECKDB to check for consistency errors

  • About DBCC CHECKDB

  • DBCC CHECKDB and performance

  • Measure and reduce index fragmentation

  • Online vs. offline index rebuilds

  • Measure fragmentation in a SQL Server 2008 or 2005 database (sys.dm_db_index_physical_stats)

  • Reducing fragmentation for a database

  • Reducing fragmentation for a specific table and its indexes

  • Fine tuning index performance by setting fill factor

  • Shrinking data files

  • Creating SQL Server 2008 maintenance plans

  • Conclusion

Note:

Before you implement any database maintenance tasks or modify SharePoint 2010 databases, read Support for changes to the databases that are used by Office server products and by Windows SharePoint Services.

Introduction

Routine database maintenance is essential for the smooth operation of Microsoft SharePoint 2010 databases.

The recommended maintenance tasks for SharePoint 2010 databases include the following:

  • Check database integrity.

  • Defragment indexes by reorganizing them or rebuilding them.

  • Set the fill factor for a server.

Note:

This article discusses database maintenance; it does not discuss planning for capacity or performance. For information about capacity or capacity planning, see Storage and SQL Server capacity planning and configuration (SharePoint Server 2010).

Although previous versions of SharePoint Products and Technologies required manual intervention to perform index defragmentation and statistics maintenance, several SharePoint Health Analyzer rules automate this process in SharePoint 2010. These rules evaluate the health of database indexes and statistics daily, and automatically address those items for the following databases:

  • Configuration databases

  • Content databases

  • User Profile Service Application Profile databases

  • User Profile Service Application Social databases

  • Web Analytics Service Application Reporting databases

  • Web Analytics Service Application Staging databases

  • Word Automation Services databases

You can perform database maintenance tasks by running Transact-SQL commands, or by running the Database Maintenance Wizard. This article describes the Transact-SQL commands that you can use, and then explains how to create database maintenance plans by using the Microsoft SQL Server Database Maintenance Wizard. (The detailed examples are for Microsoft SQL Server 2008 R2 and Microsoft SQL Server 2005.)

Using Database Console Command (DBCC) CHECKDB to check for consistency errors

Start your routine maintenance operations with consistency checks to ensure that your data and indexes are not corrupted. You can use the Database Console Command (DBCC) CHECKDB statement to perform an internal consistency check of the data and index pages.

Most database consistency problems result from I/O subsystem errors. However, other factors and events can affect database consistency too; for example, an improper shutdown of a database server or a drive failure. Noticeable performance and availability issues can sometimes be symptoms of underlying database consistency problems. Perform database consistency checks at least once per week on your SharePoint 2010 databases, and when events such as database server or I/O subsystem failures occur.

About DBCC CHECKDB

DBCC CHECKDB checks the logical and physical integrity of all the objects in the specified database by performing the following operations:

  • Runs the equivalent of DBCC CHECKALLOC to verify the allocation structures in the database.

  • Runs the equivalent of DBCC CHECKTABLE on every table and view in the database to verify their logical and physical integrity.

  • Runs the equivalent of DBCC CHECKCATALOG on the database to verify the consistency of the metadata in the database.

We recommend that you run DBCC CHECKDB instead of the individual operations (DBCC CHECKALLOC, DBCC CHECKTABLE, and DBCC CHECKCATALOG commands) because DBCC CHECKDB identifies the widest range of possible errors and is therefore safer to run in a production environment.

DBCC CHECKDB uses a lot of memory, I/O, and CPU resources. Instead of running DBCC CHECKDB on your production system, you can run it on a restored backup of your SharePoint databases on a different server, and thereby offload the consistency-checking workload from the production system.

We recommend that you first run DBCC CHECKDB, and then, if it reveals errors, restore the affected database by using your most recent backups.

Important:

You cannot run DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS. However, you can run DBCC_CHECKDB WITH REPAIR_FAST and REPAIR_REBUILD because those commands update the indexes only of the associated database.

The following is sample output from DBCC CHECKDB.

Copy Code
DBCC results for 'Contoso_Content_1'.
Service Broker Msg 9675, State 1: Message Types analyzed: 14.
Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.
Service Broker Msg 9667, State 1: Services analyzed: 3.
Service Broker Msg 9668, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.
DBCC results for 'sys.sysrowsetcolumns'.
There are 2663 rows in 21 pages for object "sys.sysrowsetcolumns".
DBCC results for 'sys.sysrowsets'.
There are 309 rows in 4 pages for object "sys.sysrowsets".

…more

CHECKDB found 0 allocation errors and 0 consistency errors in database 'Contoso_Content_1'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

For more information about how to use DBCC CHECKDB with SQL Server 2008, see DBCC CHECKDB (Transact-SQL).

DBCC CHECKDB and performance

We recommend that you run consistency checks during non-production hours because DBCC CHECKDB is extremely resource-intensive (I/O, CPU, memory, and tempdb space). There is a common misconception that DBCC CHECKDB acquires blocking locks, but that has not been true since before SQL Server 2000. For more information, see A SQL Server DBA myth a day: (2/30) DBCC CHECKDB causes blocking.

You might find that running DBCC CHECKDB uses too many resources for your production system. In that case, do not attempt to run consistency checks one table at a time. The best ways to reduce the overhead of an integrity check on the production system is to use one of the following options:

  • Use the WITH PHYSICAL_ONLY option to reduce the CPU and memory usage.

  • Restore a database backup on a separate SQL Server and run consistency checks on the restored copy of the database.

For more information about these options, see the blog entry from Paul S. Randal, CHECKDB From Every Angle: Consistency Checking Options for a VLDB.

Measure and reduce index fragmentation

Index fragmentation occurs when the logical order of pages in a table or index (as defined by the index key) differs from the physical order of the pages in the data files. It can also mean that the data density on data file pages is low, which results in wasted disk space, memory, and I/Os. Index fragmentation can be the result of many inserts, updates, or deletions to a table. The following illustrations contrast a newly built, non-fragmented index with an index that is fragmented after many inserts, updates, and deletions. The red arrow shows the physical order of the index; the black arrows show the logical ordering of the index pages.

Figure 1. Non-fragmented index (Image source: Paul S. Randal)

Figure 2. Fragmented Index (Image source: Paul S. Randal)

Because inserts, updates, and deletions are not distributed equally among the rows of the table and indexes, the fullness (or data density) of each page can vary over time. For queries that scan part or all of the indexes of a table, fragmentation can cause additional page reads, which hinders parallel scanning of data and can significantly affect search performance.

Index fragmentation can result in a decrease in performance and inefficient use of space, and indexes might become quickly fragmented on databases that have only moderate use.

Before you implement an index fragmentation maintenance plan, determine which tables and indexes are most fragmented. Then, create a maintenance plan to rebuild or reorganize those indexes.

For example, in SharePoint 2010, a table that often becomes fragmented is AllDocs, which contains document libraries, their associated documents and lists and list items, and their respective metadata.

The fragmentation level of an index is the percentage of index pages that are not in the same logical and physical order.

Online vs. offline index rebuilds

Online index rebuilding is available in SQL Server Enterprise, Developer, and Evaluation editions only. The methods described in this article take those restrictions into account. The procedures in the article fall back to an offline index rebuild if the edition of SQL Server that is hosting a specific database does not support online index rebuilds, or if the index that is being rebuilt is not eligible for an online index rebuild. An index might not be eligible for an online rebuild due to the presence of large object (LOB) columns, such as columns with a data type of NVARCHAR(MAX), IMAGE, and so on.

For information about online index rebuilds, see How Online Index Operations Work. When an offline index rebuild is performed, table level locks are taken during the rebuild process, which might prevent the table from being written to or even accessed at all. Many of the indexes in SharePoint databases are always rebuilt by using an offline index rebuild because of LOB columns.

Even if online index rebuild is used, there are still two points in the operation where table locks are held momentarily, and these could cause blocking. As a result, we recommend that you always schedule index rebuild activities during periods of low activity.

Measure fragmentation in a SQL Server 2008 or 2005 database (sys.dm_db_index_physical_stats)

In SQL Server 2008 or SQL Server 2005, use the sys.dm_db_index_physical_stats dynamic management view to determine fragmentation for the indexes on a specified table or view.

For measuring fragmentation, we recommend that you monitor the column avg_fragmentation_in_percent. The value for avg_fragmentation_in_percent should be as close to zero as possible for maximum performance. However, values from 0 percent through 10 percent might be acceptable. For more information see sys.dm_db_index_physical_stats.

The following table shows sample results from sys.dm_db_index_physical_stats, with a value of 9.375 for avg_fragmentation_in_percent in one row.

database_id | index_type_desc | alloc_unit_type_ desc | avg_fragmentation_ in_percent
10 | CLUSTERED INDEX | IN_ROW_DATA | 0
10 | NONCLUSTERED INDEX | IN_ROW_DATA | 0
10 | NONCLUSTERED INDEX | IN_ROW_DATA | 0
10 | CLUSTERED INDEX | IN_ROW_DATA | 0
10 | NONCLUSTERED INDEX | IN_ROW_DATA | 0
10 | CLUSTERED INDEX | IN_ROW_DATA | 9.375

To use the sys.dm_db_index_physical_stats dynamic management view

  1. On the taskbar, click Start, point to All Programs, point to Microsoft SQL Server 2008, and then click SQL Server Management Studio.

    To use sys.dm_db_index_physical_stats with a database object, you must know the database ID and object ID.

  2. Select the content database in the Object Explorer, and then click New Query. Execute the following script.

    SELECT DB_ID() AS [Database ID];

    Note:

    When you use DB_ID without specifying a database name, the compatibility level of the current database must be 100 (a SQL Server 2008 database) or 90 (a SQL Server 2005 database). If you have upgraded from an earlier version of SQL Server, you must specify a database name in the DB_ID statement. For more information about compatibility levels, see sp_dbcmptlevel (Transact-SQL).

  3. Execute sys.dm_db_index_physical_stats on the database or object that you select. You can specify the database, and also a table or index.

    Use the following syntax when you run sys.dm_db_index_physical_stats.

    Copy Code
    sys.dm_db_index_physical_stats (
    { database_id | NULL | 0 | DEFAULT }
    , { object_id | NULL | 0 | DEFAULT }
    , { index_id | NULL | 0 | -1 | DEFAULT }
    , { partition_number | NULL | 0 | DEFAULT }
    , { mode | NULL | DEFAULT }
)

    Be careful when you use the sys.dm_db_index_physical_stats DMV because it can be very resource-intensive. See Inside sys.dm_db_index_physical_stats for a comprehensive guide that explains the various ways to use it.

Reducing fragmentation for a database

Use the following guidance to reduce the level of index fragmentation.

Run database maintenance Health Analyzer rules

SharePoint 2010 includes the Health Analyzer rules framework. The framework has many rules that monitor the health and well-being of a SharePoint environment and in some instances, takes action to correct certain kinds of issues.

SharePoint 2010 includes several rules that are pertinent to content database maintenance. There are rules that automatically reduce index fragmentation for some SharePoint databases, and rules that check for outdated statistics, updating them if necessary. These Health Analyzer rules replace the updated Database Statistics timer job that was introduced in Service Pack 2 for SharePoint Products and Technologies. By default, these rules are configured to execute on a schedule that varies from daily, weekly, to on-demand, depending on the rule target.

All Health Analyzer rules that are configured to execute daily and that are associated with a particular SharePoint service are executed by the same timer job. Adjusting the scheduling of this timer job will adjust when Health Analyzer rules configured for daily execution and associated to that service will execute during the day. All rules discussed in this article are associated to the SharePoint Timer service.

Health Analyzer rules that are configured to execute on a different time interval (such as weekly) or associated with a different service have distinct timer jobs. If you configure a Health Analyzer rule to execute weekly, that rule executes with the timer job that is configured to execute weekly for the specific service to which that Health Analyzer rule is associated. In other words, the rule executes on the schedule that is defined for that timer job.

You can run Health Analyzer rules manually by clicking Run Now from the ribbon on the Health Analyzer Rules page in Central Administration. Running these rules evaluates the health of indexes and statistics; it also rebuilds and recalculates the index as appropriate.

Databases used by SharePoint have fragmented indices. Running this rule performs the following tasks:

  • The rule reports indexes as fragmented. Because evaluating index health is an expensive operation, after the Health Analyzer rule executes, this rule always reports indexes as fragmented to trigger the corrective action.

  • For each SharePoint database, the rule action looks for, and if found, executes the proc_DefragmentIndices stored procedure, which builds a listing of all indexes in the database. The present level of fragmentation is evaluated in each index. Any index that is fragmented more than 30 percent is considered for rebuild.

  • If the edition of SQL Server supports online index rebuilds, an online index rebuild is attempted for each index. If this fails, (for example, the underlying index might not support online rebuilds because of LOB columns) an offline index rebuild is performed.

As previously noted, this rule does not service every database in a SharePoint environment. Certain databases use different rules to perform similar maintenance activities.

Search - One or more property databases have fragmented indices. This rule maintains the indexes in the SharePoint 2010 Enterprise Search Property Databases. By default, this rule is configured to execute weekly on any server in the farm. All processing for this rule, including corrective actions, occurs during the Check phase of the rule. This means that if you want to manage index rebuilds for the Enterprise Search Property Database, it is not enough to simply configure this rule not to rebuild indexes automatically. You must disable the rule completely if you do not want SharePoint 2010 to automatically run index maintenance operations.

Running Search - One or more property databases have fragmented indices performs the following tasks:

  • The rule confirms that the environment is in a state in which it is safe to perform an index rebuild.

  • For each property database that is configured for search applications in the local farm, the rule executes the proc_MSS_DefragSearchIndexes stored procedure, which builds a listing of all indexes that have an average fragmentation over 10%.

  • Each index in the list that affects the performance of the Property database is rebuilt. If the edition of SQL Server supports online index rebuilds, an online index rebuild is performed. If an online index rebuild is attempted, but fails, the index is rebuilt offline.

Search - One or more crawl databases may have fragmented indices. This rule maintains the indexes in the SharePoint 2010 Enterprise Search Property Databases. By default, this rule is configured to execute weekly on any server in the farm. All processing for this rule, including corrective actions, occurs during the Check phase of the rule. This means that if you want to manage index rebuilds for the Enterprise Search Property Database, it is not enough to simply configure this rule not to rebuild indexes automatically. You must disable the rule complete if you do not want SharePoint 2010 to automatically run index maintenance operations.

Running Search - One or more property databases have fragmented indices performs the following tasks:

  • The rule confirms that the environment is in a state in which it is safe to perform an index rebuild.

  • For each property database that is configured for search applications in the local farm, the rule executes the proc_MSS_DefragSearchIndexes stored procedure, which builds a listing of all indexes that have an average fragmentation over 10%.

  • Each index in the list that affects the performance of the Property database is rebuilt. If the edition of SQL Server supports online index rebuilds, an online index rebuild is performed. If an online index rebuild is attempted, but fails, the index is rebuilt offline.

Search - One or more crawl databases may have fragmented indices. This rule maintains the indexes in the SharePoint 2010 Enterprise Search Crawl Databases. By default, this rule is configured to execute only on demand. When executed, it can execute from any server in the farm.

The rule reports indexes in the crawl database as fragmented because checking for fragmentation in a database is an expensive operation. Simply disabling the 'Repair' activity for this rule results in a report that all crawl databases are unhealthy, even when the crawl databases have had their indexes recently rebuilt.

To maintain indexes in crawl databases manually, disable the Search - One or more crawl databases may have fragmented indices rule completely.

Running Search - One or more crawl databases may have fragmented indices performs the following tasks:

  • The rule confirms that the environment is in a state in which it is safe to perform an index rebuild.

  • For each Crawl database that is configured for search applications in the local farm, the rule executes the proc_MSS_DefragGathererIndexes stored procedure.

  • Each index in the Crawl database in the list is rebuilt. If the edition of SQL Server supports online index rebuilds, an online index rebuild is performed. If an online index rebuild is attempted, but fails, the index is rebuilt offline.

Important:

The Search - One or more crawl databases may have fragmented indices rule rebuilds every index in all Crawl databases regardless of fragmentation level. It also enables page level data compression, if supported by the edition of SQL Server that is hosting the Crawl database.

Because of the nature of the Crawl database, you typically do not have to defragment this database frequently. Execute this rule after you have first performed a full crawl over your content. Afterwards, monitor the indexes in the Crawl database for fragmentation, and execute this rule when index fragmentation grows. Index fragmentation might occur because of a sudden addition or removal of a large amount of crawled content; for example, during the content expulsion that results from an environmental cleanup, or after the on-boarding of a new content source, such as a file share or large SharePoint web application.

The following databases do not have an automated maintenance mechanism in place. These databases do not typically have much fragmentation. Monitor these databases for fragmentation, and rebuild the indexes in these databases when fragmentation exceeds 30%.

  • Search Administration Database

  • Secure Store Database

  • State Service Database

  • Profile Sync Database

  • Usage Database

  • Managed Metadata Database

  • Business Connectivity Services Database

  • PerformancePoint Services Database

For more information about the changes that are supported for SharePoint 2010 databases, see Support for changes to the databases that are used by Office server products and by Windows SharePoint Services in the Microsoft Knowledge Base.

If the performance of a heavily fragmented database or table is not measurably improved by frequent defragmentation, you should check the performance of the I/O subsystem.

Reducing fragmentation for a specific table and its indexes

If you want to defragment an index that is associated with a particular table instead of an entire database, you can reorganize or rebuild the index.

  • Reorganizing an index specifies that the index leaf level is reorganized. Index reorganization defragments and compacts clustered and non-clustered indexes on tables and views, and can significantly improve index scanning performance. Reorganizing an index uses the existing space allocated to the index. Reorganization is always performed online so that the underlying table is available to users.

  • Rebuilding an index specifies that a brand new copy of the index is built. Therefore, a rebuild operation requires enough extra space to build the new copy of the index before removing the old, fragmented index. Rebuilding improves the performance of index scans and seeks. You can rebuild the index with a table online or offline.

The fragmentation level of an index determines the method that you should use to defragment it, and whether it can remain online, or should be taken offline. The following table describes the defragmentation method that is recommended for different fragmentation levels.

Fragmentation level | Defragmentation method
Up to 10% | Reorganize (online)
10-75% | Rebuild (online)
75% | Rebuild (offline)
Note:

Using the DROP INDEX and CREATE INDEX commands is not supported on SharePoint 2010 databases.

You can reorganize and rebuild indexes by using the SQL Server 2008 or SQL Server 2005 ALTER INDEX statement, or the SQL Server 2008 or SQL Server 2005 Maintenance Plan Wizard. This article presents the SQL Server 2008 or SQL Server 2005 options only in detail.

Using ALTER INDEX

ALTER INDEX enables a database administrator to perform maintenance operations against an index on a table or view. You can use it to disable, rebuild, and reorganize indexes. Also, you can use it to set options on the index. In most cases, you can rebuild indexes while the database is online, which keeps the data more available to users than an offline index rebuild.

Important:

SQL Server 2000 supported DBCC DBREINDEX and DBCC INDEXDEFRAG for index maintenance. These commands have been deprecated from SQL Server 2005 onwards and will be removed in a future version of SQL Server. Do not use these commands to perform index maintenance on a SharePoint 2010 database.

Note:

When an index is being rebuilt offline, a shared table lock is put on the table to prevent all operations except SELECT. SharePoint 2010 databases use clustered indexes specifically. When a clustered index is being rebuilt offline, an exclusive table lock is put on the table to prevent users from accessing it.

You can customize the following sample script to rebuild all indexes on a table.

Copy Code
USE Contoso_Content_1
GO
ALTER INDEX ALL ON [database_name. [ schema_name ] . | schema_name. ]table_or_view_name
REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON,
STATISTICS_NORECOMPUTE = ON)
GO

Fine tuning index performance by setting fill factor

To further improve index data storage and performance, use fill factor. When indexes are created or rebuilt, the fill factor value (1-100) determines the percentage of space that can be filled with data on each leaf level page. The remaining space is reserved for future growth. For many situations, the default server-wide fill factor level of 0 (fill each page to 100% full) is optimal. However, for SharePoint 2010, a server-wide setting of 80 is optimal to support growth and minimize fragmentation.

Note:

We do not recommend that you set the fill factor for individual tables or indexes. Although this is the preferred method for non-SharePoint SQL Server databases, tests show that SharePoint databases work best with an 80% fill factor.

To view the fill factor value of one or more indexes, query the sys.indexes catalog view. For more information about the view, see sys.indexes (Transact-SQL).

To configure the server-wide fill factor value, use the sp_configure system stored procedure. For more information, see spconfigure (Transact-SQL).

Shrinking data files

In SQL Server 2008 and SQL Server 2005, you can shrink each file in a database (file name extensions .mdf, .ldf, and .ndf) to remove unused pages and recover disk space. SharePoint 2010 databases do not automatically shrink data files, although many activities create unused space in the database. Activities that can create unused space include running the Move-SPSite Windows PowerShell command, and deleting documents, document libraries, lists, list items, and sites.

Figure 3. Database allocation

Free space is only released from the end of the file; for example, a content database file of 60 GB with a specified target size of 40 GB frees as much space as possible from the ending (conceptually, the 'right-hand' end) 20 GB of the database file. If used pages are included in the ending 20 GB, those pages are later relocated to the beginning 40 GB of the file that is retained. You can shrink database files individually or as a group.

Only perform shrink operations rarely, and only after you perform an operation that removes a lot of data from a database, and then only when you do not expect to use that free space again. Data file shrink operations cause heavy index fragmentation and are extremely resource-intensive. Examples of when you might have to shrink database files are when you relocate a large of number of site collections from one content database to another content database or when you delete a large list. Either of those operations can create large amounts of unused space. Database files can only be reduced to the point where there is no free space remaining. Therefore, a content database in which you rarely delete content might not benefit much from shrinking, and will likely experience a decrease in performance when it has to grow to accommodate additional data without specific accommodations. For more information, see Database File Initialization.

Because shrinking causes index fragmentation, do not shrink database files regularly. Instead, shrink database files only in response to large quantities of unused space that appear as a result of operations that significantly impact the relative amount of used space in a database. If at all possible, avoid shrinking a database.

However, if you must shrink a database, use the following guidelines:

  • Do not auto-shrink databases or configure a maintenance plan that programmatically shrinks your databases.

  • Shrink a database only when users or administrators remove 50% or more of the content and you do not expect to reuse the unused space.

  • Shrink only content databases. Users and administrators do not delete enough data from the configuration database, Central Administration content database, and various service application databases to contain significant free space.

  • Shrinking databases is an extremely resource-intensive operation. Therefore, if you absolutely must shrink a database, carefully consider when you schedule the shrink operation.

  • After you shrink a database, the indexes in that database are fragmented. Use ALTER INDEX… REORGANIZE to address the fragmentation. If you are not configured to allow instant file initialization, shrink the database to a target size that accommodates the size required for the near-term growth that you expect. For more information, see Database File Initialization.

You can shrink databases and database files manually to recover space by executing the DBCC SHRINKFILE and DBCC SHRINKDATABASE statements in SQL Server 2008 or SQL Server 2005 Management Studio.

For more information about why shrinking a database damages performance and should not be done unless absolutely necessary, see Why you should not shrink your data files.

Shrinking a database by using Transact-SQL commands

DBCC SHRINKDATABASE shrinks the data and log files for a specific database. To shrink individual files, use DBCC SHRINKFILE.

DBCC SHRINKDATABASE

DBCC SHRINKDATABASE uses the following syntax.

Copy Code
DBCC SHRINKDATABASE
( 'database_name' | database_id | 0
     [ ,target_percent ]
     [ , { NOTRUNCATE | TRUNCATEONLY } ]
)
[ WITH NO_INFOMSGS ]

database_name | database_id | 0 specifies the database name or ID. To select the current database, use 0.

target_percent is the free space, as a percentage, that you want to keep after you shrink the database.

NOTRUNCATE compacts the data in data files by moving allocated pages from the end of a file to unallocated pages in the front of the file.

TRUNCATEONLY releases all free space at the end of the file to the operating system but does not perform any page movement in the file.

Note:

Using the TRUNCATEONLY option is not supported for SharePoint 2010 content databases.

For more information, see DBCC SHRINKDATABASE (Transact-SQL).

DBCC SHRINKFILE

DBCC SHRINKFILE uses the following syntax.

Copy Code
DBCC SHRINKFILE
(
     { 'file_name' | file_id }
    { [ , EMPTYFILE ]
    | [ [ , target_size ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ]
    }
)
[ WITH NO_INFOMSGS ]

file_name | file_id specifies the file name or ID.

EMPTYFILE migrates all data from the specified file to other files in the same filegroup.

Important:

Using the EMPTYFILE option is not supported for SharePoint 2010 database files.

target_size is the target size for the file in megabytes, expressed as an integer.

NOTRUNCATE compacts the data in data files by moving allocated pages from the end of a file to unallocated pages in the front of the file.

TRUNCATEONLY releases all free space at the end of the file to the operating system but does not perform any page movement inside the file.

Important:

Using the TRUNCATEONLY option is not supported for SharePoint 2010 content databases

For more information, see DBCC SHRINKFILE (Transact-SQL).

Shrinking a database by using SQL Server 2008 Management Studio

Use the following procedure.

To shrink a database by using SQL Server 2008 Management Studio

  1. On the taskbar, choose Start, All Programs, Microsoft SQL Server 2008, SQL Server Management Studio.

  2. In Object Explorer, connect to an instance of the SQL Server 2008 Database Engine and then expand that instance.

  3. Expand Databases, right-click the database that you want to shrink, choose Tasks, Shrink, Files.

  4. Select the file type and file name.

  5. Select Reorganize files before releasing unused space. You must also set the Shrink file value. Select this option to release any unused space in the file to the operating system and to relocate rows to unallocated pages.

  6. Click OK.

Creating SQL Server 2008 maintenance plans

You can programmatically apply many of the database maintenance operations that are discussed in this article by implementing SQL Server maintenance plans. Maintenance plans can automate and schedule essential tasks to protect your data. By using maintenance plans in SQL Server 2008 or SQL Server 2005, an administrator can schedule operations such as running database consistency checks, reorganizing indexes, or rebuilding indexes. For more information, see the following resources:

  • Maintenance Plan Wizard for SQL Server 2008.

  • Database Maintenance Plan Wizard for SQL Server 2005.

To configure a SQL Server 2008 database maintenance plan

  1. On the taskbar, choose Start, All Programs, Microsoft SQL Server 2008, SQL Server Management Studio.

  2. In Object Explorer, connect to an instance of the SQL Server 2008 Database Engine and then expand that instance.

  3. Choose Management, right-click Maintenance Plans, and then choose Maintenance Plan Wizard.

  4. Choose Next until you reach the Select Plan Properties page.

    Figure 4. Select Plan Properties page

    Select Plan Properties page

  5. In the Name and Description fields, specify a name and description.

  6. Decide whether to configure one or more maintenance plans.

    • To configure a single maintenance plan, select Single schedule for the entire plan or no schedule.

    • To configure multiple maintenance plans with specific tasks, select Separate schedules for each task.

    If you have an environment that has 10 or more content databases or more than 200 GB of content, we recommend that you configure separate maintenance plans to provide appropriate specificity and to maximize the maintenance window.

    If you configure multiple maintenance plans for a database, specify a name or description that enables you to differentiate the plans and their purposes, including their schedules.

  7. Click Change to set a schedule for one or more plans.

    The Job Schedule Properties dialog box appears.

    Figure 5. Job Schedule Properties dialog box

    Job Schedule Properties dialog box

  8. Complete the schedule, click OK, and then click Next.

  9. On the Select Maintenance Tasks page, select the maintenance tasks to include in the plan, and then click Next.

    Figure 6. Select Maintenance Tasks page

    Select Maintenance Tasks page

    Consider the following notes:

    • A maintenance plan should include index reorganization or index rebuilding; not both.

    • A maintenance plan should never include shrinking a database.

    • To determine the duration of each task, test each task individually before combining tasks into a single plan. You might have to define several maintenance plans on separate schedules to enable tasks to complete during hours that do not adversely affect users.

    • The Maintenance Cleanup Task removes files that are left over after a scheduled maintenance.

  10. On the Select Maintenance Task Order page, change the order of the maintenance plan tasks if you need to. Select a task, and then click Move up or Move down. After you order the tasks, click Next.

    Note:

    If your databases are very large, you might want to create a separate maintenance plan that checks database integrity less frequently than index maintenance.

    Figure 7. Select Maintenance Task Order page

    Select Maintenance Task Order page

  11. Next, the wizard guides you through setting the details for each task. On the Define Database Check Integrity Task page, select the databases to check for integrity, and then click Next.

    Note:

    You can safely check all SharePoint 2010 databases for integrity.

    Figure 8. Define Database Check Integrity Task page

    Define Database Check Integrity Task page

  12. On the Define Reorganize Index Task page, in the Databases list, specify the databases for which you want to reorganize the indexes, select the Compact large objects check box, and then click Next.

    Figure 9. Define Reorganize Index Task page

    Define Reorganize Index Task page

  13. On the Define Rebuild Index Task page, if you chose to rebuild indexes instead of reorganize indexes, specify the databases in the Databases list.

  14. Select Change free space per page percentage, type 80, and then click Next.

    Change free space per percentage sets the fill factor for the database.

    Figure 10. Define Rebuild Index Task page

    Define Rebuild Index Task page

  15. On the Define Maintenance Cleanup Task page, specify the requested values, and then click Next.

    Tip:

    We recommend that you delete Maintenance Plan text reports.

    Figure 11. Define Maintenance Cleanup Task page

    Define Maintenance Cleanup Task page

  16. On the Select Report Options page, select Write a report to a text file, select a location for the files, and then click Next until you complete the wizard.

    Figure 12. Select Report Options

    Select Report Options

Conclusion

Consistently maintaining the databases that host SharePoint 2010 can significantly improve the health and performance of your system.

Ensure that you have reliable backups for all databases before you implement maintenance operations and maintenance plans.

Before you implement a maintenance plan or specific maintenance operations that run consistently, test the impact of the operations on your system and the time that is required to run them.

As much as possible, set any maintenance operations or maintenance plans to run during off-hours to minimize the performance effect on users.

See Also

Other Resources

This topic also available as a download


Manage RBS (SharePoint Foundation 2010)
See Also

Remote BLOB Storage (RBS) is an add-on feature pack for Microsoft SQL Server 2008. RBS is designed to move the storage of binary large objects (BLOBs) from database servers to commodity storage solutions. If the content databases in Microsoft SharePoint Foundation 2010 are 4 gigabytes (GB) or larger, consider using RBS as part of your data storage solution.

In This Section

  • Overview of RBS (SharePoint Foundation 2010)

    This article is a conceptual overview of how RBS works with Microsoft SQL Server 2008 Express and Microsoft SQL Server 2008 R2 Express. It contains important information about RBS features and providers. We strongly recommend that you read this article before you implement RBS.

  • Install and configure RBS (SharePoint Foundation 2010)

    This article describes how to install and configure RBS and implement the FILESTREAM provider for use with SharePoint Foundation 2010.

  • Install and configure RBS with a 3rd party provider (SharePoint Foundation 2010)

    This article describes how to install and configure RBS without using the FILESTREAM provider.

  • Set a content database to use RBS (SharePoint Foundation 2010)

    This article describes how to set a content database to use RBS. You must already have RBS installed to perform these procedures.

  • Migrate content into or out of RBS (SharePoint Foundation 2010)

    This article describes how to migrate content into or out of RBS, or to a different RBS provider.

  • Disable RBS on a content database (SharePoint Foundation 2010)

    This article describes how to disable RBS in a SharePoint Foundation 2010 environment.

See Also

Concepts

Plan for RBS (SharePoint Foundation 2010)
Upgrade a stand-alone installation by using RBS (in-place) (SharePoint Foundation 2010)
Upgrade a stand-alone installation on a domain controller by using RBS (database attach) (SharePoint Foundation 2010)
Upgrade a stand-alone installation to new hardware by using RBS (database attach) (SharePoint Foundation 2010)

Other Resources

Upgrading from a stand-alone installation of Windows SharePoint Services 3.0 to SharePoint Foundation 2010 when content databases exceed 4 GB (RBS)


Install and configure RBS with a 3rd party provider (SharePoint Foundation 2010)
See Also

This article describes how to install and configure Remote BLOB Storage (RBS) for a Microsoft SQL Server 2008 R2 Express database server that supports a Microsoft SharePoint Foundation 2010 farm.

Important:

SQL Server 2008 R2 Express supports databases that are as large as 10 GB. If your installation includes databases that are larger than 4 GB but smaller than 10 GB, we recommend that you upgrade to SQL Server 2008 R2 Express for content database storage. SQL Server 2008 R2 Express is a free upgrade that you can download and install from Microsoft® SQL Server® 2008 R2 Feature Pack (http://go.microsoft.com/fwlink/p/?LinkID=177388).

Important:

This solution uses a 3rd-party provider. Before continuing, be sure to read the instructions from the manufacturer of the provider.

Do not directly access BLOBs when using 3rd party providers. Always access these BLOBs by using SharePoint Foundation 2010.

To use RBS, you must do the following:

  • Install the RBS client library on each Web server - the RBS client library stores the BLOB data on the file system, enable fidelity checks, and perform other tasks.

  • Install the 3rd-party provider - Be sure to follow the instructions from the manufacturer of the provider.

  • Enable RBS for each content database - You must enable RBS for each content database for which you want to use RBS.

  • Test the RBS installation

The user account that you use to perform the procedures that are described in this article must have the following memberships:

  • Administrators group on the Web servers and application servers.

  • SQL Server dbcreator and securityadmin fixed server roles on the computer that is running SQL Server 2008 R2 Express.

Install the RBS client library on each Web server

You must install RBS client library on all Web servers in the SharePoint farm. The RBS client library is installed only once per Web server, but RBS is configured separately for each associated content database. The client library consists of a client-side DLL that is linked into a user application, as well as a set of stored procedures to be installed on SQL Server.

Warning:

Do not install RBS by running the RBS_x64.msi file and starting the Install SQL Remote BLOB Storage wizard. The wizard sets certain default values that are not recommended for SharePoint Foundation 2010.

To install the RBS client library on the on the first Web server

  1. On any Web server, browse to http://go.microsoft.com/fwlink/?LinkID=188395&clcid=0x409 and download the RBS.msi file.

  2. Click Start, click Run, type cmd into the Run text box, and then click OK.

  3. Copy and paste the following command into the Command Prompt window. Replace WSS_Content with the database name, and replace DBInstanceName with the SQL Server instance name. You should run this command by using the specific database name and SQL Server instance name only one time. The operation should finish within approximately one minute.

    Copy Code
    msiexec /qn /lvx* rbs_install_log.txt /i RBS.msi TRUSTSERVERCERTIFICATE=true FILEGROUP=PRIMARY DBNAME="WSS_Content" DBINSTANCE="DBInstanceName" FILESTREAMFILEGROUP=RBSFilestreamProvider FILESTREAMSTORENAME=FilestreamProvider_1

To install the RBS client library on all additional Web and application servers

  1. On a Web server, download the RBS.msi at http://go.microsoft.com/fwlink/?LinkID=188395&clcid=0x409.

  2. Click Start, click Run, type cmd into the Run text box, and then click OK.

  3. Copy and paste the following command into the Command Prompt window. Replace WSS_Content with the database name, and replace DBInstanceName with the name of the SQL Server instance. The operation should finish within approximately one minute.

    Copy Code
    msiexec /qn /lvx* rbs_install_log.txt /i RBS.msi DBNAME="WSS_Content" DBINSTANCE="DBInstanceName" ADDLOCAL=Client,Docs,Maintainer,ServerScript,FilestreamClient,FilestreamServer

  4. Repeat this procedure for all Web servers and application servers in the SharePoint farm.

To confirm the RBS client library installation

  1. The rbs_install_log.txt log file is created in the same location as the RBS.msi file. Open the rbs_install_log.txt log file by using a text editor and scroll toward the bottom of the file. Within the last 20 lines of the end of the file, an entry should read as follows: Product: SQL Remote Blob Storage - Installation completed successfully.

  2. On the computer that is running SQL Server 2008, verify that the RBS tables were created in the content database. Several tables should be listed under the content database that have names that are preceded by the letters "mssqlrbs".

Install the 3rd-party provider

The steps that you use to install the 3rd-party provider will vary between manufacturers. Be sure to follow the instructions from the manufacturer of the provider.

Enable RBS for each content database

You must enable RBS on one Web server in the SharePoint farm. It is not important which Web server that you select for this activity, as long as RBS was installed on it by using the previous procedure. You must perform this procedure once for each content database.

Note:

You can only enable RBS by using Windows PowerShell.

To enable RBS 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    $cdb = Get-SPContentDatabase <ContentDatabaseName>
$rbss = $cdb.RemoteBlobStorageSettings
$rbss.Installed()
$rbss.Enable()
$rbss.SetActiveProviderName($rbss.GetProviderNames()[0])
$rbss

    Where:

    • <ContentDatabaseName> is the name of the content database.

For more information, see Get-SPContentDatabase.

Test the RBS installation

You should test the RBS installation on one Web server in the SharePoint farm to ensure that the system works correctly.

To test the RBS data store

  1. On the computer that contains the RBS data store, click Start, and then click Computer.

  2. Browse to the RBS data store directory.

  3. Confirm that the folder is empty.

  4. On the SharePoint farm, upload a file that is at least 100 kilobytes (KB) to a document library.

  5. On the computer that contains the RBS data store, click Start, and then click Computer.

  6. Browse to the RBS data store directory.

  7. Browse to the file list and open the file that has the most recent modified date. This should be the file that you uploaded.

See Also

Concepts

Overview of RBS (SharePoint Foundation 2010)
Plan for RBS (SharePoint Foundation 2010)

Other Resources

How to: Enable FILESTREAM
Resource Center: Installation and Deployment for SharePoint Foundation 2010


Set a content database to use RBS (SharePoint Foundation 2010)
See Also

This article describes how to set a content database to use Remote BLOB Storage (RBS). Its instructions assume that you have already installed RBS for use with Microsoft SharePoint Foundation 2010. To install and configure RBS, see Install and configure RBS (SharePoint Foundation 2010) or Upgrading from a stand-alone installation of Windows SharePoint Services 3.0 to SharePoint Foundation 2010 when content databases exceed 4 GB (RBS).

Set a content database to use RBS

To set a content database to use RBS, you must provision a binary large object (BLOB) store in SQL Server, add the content database information to the RBS configuration on a Web server, and then test the RBS data store.

These instructions assume that you have installed SQL Server Management Studio on the database server. If this is not the case, you can download and install Management Studio from Microsoft SQL Server 2008 Management Studio Express (http://go.microsoft.com/fwlink/p/?LinkID=186132&clcid=0x409). You can perform the following procedures on any Web server or application server in the farm. However, for simplicity in this article, we refer to this server as a Web server.

Note:

These instructions assume that you are using the FILESTREAM RBS provider. If you are using a different RBS provider, refer to that provider's instructions to perform these operations.

To set a content database to use RBS

  1. Verify that the user account that you use to perform this procedure is a member of the Administrators group on the Web server, and is a member of the SQL Server dbcreator and securityadmin fixed server roles on the computer that is running Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, or SQL Server 2005 with SP3 and Cumulative Update 3.

  2. Click Start, click All Programs, click Microsoft SQL Server 2008, and then click SQL Server Management Studio.

  3. In the Connect to Server dialog box, specify the server type, server name, and authentication method of the database server that you want to connect to, and then click Connect.

  4. Expand Databases.

  5. Right-click the content database for which you want to create a BLOB store, and then click New Query.

  6. In the Query pane, copy and execute the following SQL queries in the sequence that is provided.

    Copy Code
    use [ContentDbName]
if not exists (select * from sys.symmetric_keys where name = N'##MS_DatabaseMasterKey##')
create master key encryption by password = N'Admin Key Password !2#4'
    Copy Code
    use [ContentDbName]
if not exists (select groupname from sysfilegroups where groupname=N'RBSFilestreamProvider')
alter database [ContentDbName] add filegroup RBSFilestreamProvider contains filestream
    Copy Code
    use [ContentDbName]
alter database [ContentDbName] add file (name = RBSFilestreamFile, filename = 'c:\RBSStore') to filegroup RBSFilestreamProvider

    Where [ContentDbName] is the content database name and c:\RBSStore is the volume\directory that will contain the RBS data store. Be aware that you can provision a RBS store only one time. If you attempt to provision the same RBS data store multiple times, you will receive an error.

    Tip:

    For best performance, simplified troubleshooting, and as a general best practice, we recommend that you create the RBS data store on a volume that does not contain the operating system, paging files, database data, log files, or the tempdb file.

  7. Click Start, click Run, type cmd into the Run text box, and then click OK.

  8. Copy and paste the following command at the command prompt:

    Copy Code
    msiexec /qn /i rbs.msi REMOTEBLOBENABLE=1 FILESTREAMPROVIDERENABLE=1 DBNAME=<ContentDbName> FILESTREAMSTORENAME=FilestreamProvider_1 ADDLOCAL=EnableRBS,FilestreamRunScript DBINSTANCE=<DBInstanceName>>

    Where <ContentDbName> is the name of the content database, and <DBInstanceName> is the name of the SQL Server instance. The operation should finish within approximately one minute.

To test the RBS data store

  1. Connect to a document library on any Web server.

  2. Upload a file that is at least 100 kilobytes (KB) to the document library.

  3. On the computer that contains the RBS data store, click Start, and then click Computer.

  4. Navigate to the RBS data store directory.

  5. Locate the folder that has the most recent modification date, other than the $FSLOG folder. Open this folder and locate the file that has the most recent modification date. Verify that this file has the same size and contents as the file that you uploaded. If does not, ensure that RBS is installed and enabled correctly.

See Also

Concepts

Overview of RBS (SharePoint Foundation 2010)
Migrate content into or out of RBS (SharePoint Foundation 2010)


Migrate content into or out of RBS (SharePoint Foundation 2010)
See Also

This article describes how to migrate content into or out of Remote BLOB Storage (RBS), or to a different RBS provider.

After installing RBS and setting a content database to use RBS, all existing content in that database can be migrated into the database's active provider. You use the same Windows PowerShell 2.0 command to migrate content into or out of RBS, or to another RBS provider. When RBS is implemented, SQL Server itself is regarded as an RBS provider.

You can migrate content databases at any time, but we recommend that you perform migrations during low usage periods so that this activity does not cause performance degradation for users. Migration moves all content from the specified content database into the storage mechanism of the newly named provider.

This operation can be performed on any Web server in the farm. You only need to perform the operation one time on one Web server for each content database that you want to migrate.

To migrate a content database 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. At the Windows PowerShell command prompt, type the commands in the following steps.

  6. To obtain the content database RBS settings object:

    Copy Code
    $cdb=Get-SPContentDatabase <ContentDbName>
$rbs=$cdb.RemoteBlobStorageSettings

    Where <ContentDbName> is the name of the content database.

  7. To view a list of all RBS providers that are installed on the Web server:

    Copy Code
    $rbs.GetProviderNames()

  8. To set the active RBS provider:

    Copy Code
    $rbs.SetActiveProviderName(<NewProvider>)

    Where <NewProvider> is the name of the provider that you want to make active for this content database. If you want to migrate the content database out of RBS altogether and back into SQL Server inline storage, set this value to ().

  9. Migrate the data from RBS to the new provider or to SQL Server:

    Copy Code
    $rbs.Migrate()

See Also

Concepts

Set a content database to use RBS (SharePoint Foundation 2010)


Maintain RBS (SharePoint Foundation 2010)
See Also

Published: August 27, 2010

This article describes how to perform maintenance tasks that are associated with Remote BLOB Storage (RBS) in Microsoft SharePoint Foundation 2010.

You perform most of the maintenance tasks associated with RBS in SharePoint Foundation 2010 by using the RBS Maintainer, which is a tool in Microsoft SQL Server. The RBS Maintainer performs periodic garbage collection and other maintenance tasks for a SharePoint 2010 RBS deployment. You can schedule these tasks for each database that uses RBS by using Windows Task Scheduler or Microsoft SQL Server Agent. You must provision the RBS Maintainer by using command-line parameters or through an XML file. In the case of mirrored or replicated databases, you can run the RBS Maintainer against any single instance.

In this article:

  • Garbage collection

  • RBS and BLOB store consistency checks

  • Running the RBS Maintainer

Garbage collection

SharePoint Foundation 2010 automatically marks unreferenced or deleted BLOB data for removal. SharePoint Foundation 2010 counts references to BLOBs by looking at the list of BLOB IDs stored by SharePoint Foundation 2010 in its content databases at the time of removal. Any BLOB references that are present in the RBS store tables but absent in the content database are assumed to be deleted by SharePoint Foundation 2010 and will be marked for removal. BLOBs that are not present in the content database and were created before the orphan cleanup time window, described later in this article, are also assumed to be deleted by SharePoint Foundation 2010 and will be marked for removal.

Because SharePoint Foundation 2010 tabulates BLOB references from the RBS columns of the content database, every RBS column must have a valid index before it can be registered in RBS.

The SQL Server RBS Maintainer tool removes the items marked by SharePoint Foundation 2010 for removal. You should schedule the clean-up tasks to be run during off-peak hours to reduce the effect on regular database operations.

RBS garbage collection is performed in the following three steps:

  • Reference scan. The first step compares the contents of the RBS tables in the SharePoint Foundation 2010 content database with RBS's own internal tables and determines which BLOBs are no longer referenced. Any unreferenced BLOBs are marked for deletion.

  • Delete propagation. The next step determines which BLOBs have been marked for deletion for a period of time longer than the garbage_collection_time_window value and deletes them from the BLOB store.

  • Orphan cleanup. The final step determines whether any BLOBs are present in the BLOB store but absent in the RBS tables. These orphaned BLOBs are then deleted.

Configuring RBS garbage collection

You can configure garbage collection by specifying the following RBS Maintainer settings and database settings:

  • Maintainer schedule. This setting determines how often the RBS Maintainer will be run.

  • Task Duration. This setting determines the maximum length that a single RBS Maintainer task can run. The default setting is two hours.

You should configure the RBS Maintainer so that its activity has minimal effect on regular activity. For information about database garbage collection settings, including how to configure the settings, see Running RBS Maintainer (http://go.microsoft.com/fwlink/p/?LinkId=199638).

RBS and BLOB store consistency checks

The RBS Maintainer verifies the integrity of RBS BLOB references and corrects any errors that are found. It performs several consistency checks for the database, such as verifying that indexes exist for the RBS columns, and verifying that all BLOBs that are referenced by SharePoint Foundation 2010 exist in RBS.

The Auxiliary Table Consistency Check verifies that the RBS auxiliary tables are in a consistent state. The checks performed are the following:

  • Verify that each RBS table column has a valid index.

  • Verify that RBS table columns exist; have enabled, valid indexes; and have the correct column type.

Although you can disable the following consistency checks, we recommend that you do not disable them because they help ensure the consistency of your RBS store. By default, the following consistency checks are enabled:

  • Verify that all BLOBs that are referenced by SharePoint Foundation 2010 are present in the RBS tables.

  • Verify that no BLOBs are marked as both in use and deleted.

Any discovered problems are logged and the RBS Maintainer attempts to fix them by creating missing index entries, unregistering missing columns, or marking in-use BLOBs as not deleted.

Running the RBS Maintainer

RBS requires you to define a connection string to each database that uses RBS before you run the RBS Maintainer. This string is stored in a configuration file in the <RBS installation path>\Microsoft SQL Remote Blob Storage 10.50\Maintainer folder that is ordinarily created during installation. The RBS Maintainer can be run manually by executing the Microsoft.Data.SqlRemoteBlobs.Maintainer.exe program together with the parameters that are listed in the following table.

Parameter name | Description | Values | Required?
ConnectionStringName <string name> | The name of the connection string for the configuration file. | RBSMaintainerConnection is the default name that is created during RBS setup. | Yes
Operation <space-separated list of operations to perform> | The garbage collection operations to perform. This parameter takes one to four arguments. The ForceFinalize value cannot be used in combination with any other operation. | ConsistencyCheck GarbageCollection Maintenance ConsistencyCheckForStores ForceFinalize | Yes
GarbageCollectionPhases <phases> | The garbage collection phases to perform. This parameter is used to run or complete the garbage collection. The value must be one or more letters without spaces. | r — Reference scan. d — Delete propagation. o — Orphan cleanup. | Yes, if garbage collection is to be performed.
ConsistencyCheckMode <c, r, or b> | Specifies the kind of consistency check to be performed. | c — Only a check will be performed. r — A check will be performed and any issues found will be repaired. b — A check, repair, and rebuild of the internal data structures. | Yes, if a consistency check is to be performed.
ConsistencyCheckExtent <m or c> | Specifies the extent of the consistency check. | m — Only metadata will be checked; individual BLOBs will remain unchecked. This is the default parameter. c — A complete check will be performed. | If not specified, m is assumed.
ConsistencyCheckForStores <space-separated list of BLOB store names> | Lists the names of the BLOB stores that will be checked for consistency. | By default, all BLOB stores are checked. | No
TimeLimit <time in minutes> | Specifies the time that is available for the RBS Maintainer to perform its tasks. The argument must be a positive integer. |  | No

You must schedule a separate RBS Maintainer task for every database that uses RBS. The following steps describe how to schedule an RBS Maintainer task.

To schedule an RBS Maintainer task

  1. Verify that you have Write permissions for the folder where you installed RBS.

  2. Add a connection string to the <RBS installation directory>\Maintainer\Microsoft.Data.SqlRemoteBlobs.Maintainer.exe.config file for the RBS Maintainer task that is to be performed. The RBS installer creates one connection string that is named RBSMaintainerConnection by using the connection information that was provided during setup. However, new connection strings must be added for every additional database.

    If you are using Windows authentication, the connection string does not have to be encrypted. You can add the unencrypted connection string by running the following command:

    aspnet_regiis -pef connectionStrings . -prov DataProtectionConfigurationProvider
    rename web.config Microsoft.Data.SqlRemoteBlobs.Maintainer.exe.config

    If you are using SQL authentication, the RBS Maintainer connection strings must be in an encrypted format. Therefore, to add connection strings, either the new strings must be encrypted or all the connection strings must be decrypted. Encrypted strings must be added one at a time. However all the connection strings can be decrypted at the same time by using the %windir%\Microsoft.net\Framework\<version>\Aspnet_regiis.exe tool, which is distributed as a part of the Microsoft .NET Framework.

    Run the following commands to decrypt the connection strings and store the results in a Web.config file:

    rename Microsoft.Data.SqlRemoteBlobs.Maintainer.exe.config web.config
    aspnet_regiis -pdf connectionStrings

    Strings can then be added in decrypted form and the file can be encrypted and renamed to Microsoft.Data.SqlRemoteBlobs.Maintainer.exe.config by using the following commands:

    aspnet_regiis -pef connectionStrings . -prov DataProtectionConfigurationProvider
    rename web.config Microsoft.Data.SqlRemoteBlobs.Maintainer.exe.config

  3. Create a Windows scheduler task to run the RBS Maintainer task for each applicable database. If you ran the RBS installer in GUI mode, it automatically created a Windows scheduler task. However, if you ran the RBS installer in command-line mode, you must perform the following steps every time that you schedule a task to run the RBS Maintainer:

    1. On the Start menu, click Administrative Tools, and then click Task Scheduler.

    2. On the Action menu, click Create Task.

    3. On the Actions tab, click New.

    4. In the New Action dialog box, in the Action drop-down list, select Start a program.

    5. Under Settings, in the Program/script box, browse to the Maintainer binary file <RBS installation directory>\Maintainer\Microsoft.Data.SqlRemoteBlobs.Maintainer.exe, and in the Add arguments (optional) text box, add any optional arguments. The following default values are created by the installer:
      <-ConnectionStringName RBSMaintainerConnection>
      <-Operation GarbageCollection ConsistencyCheck ConsistencyCheckForStores>
      <-GarbageCollectionPhases rdo>
      <-ConsistencyCheckMode r>
      <-TimeLimit 120>

    6. Click OK.

    7. On the Triggers tab, click New.

    8. In the New Trigger dialog box, schedule the task, and then click OK. We recommend that you schedule the task to run during low system activity times.

    9. On the General tab, under Security, ensure that the user account has the correct permissions to run the task. You can change permissions by clicking Change User or Group.

    10. On the General tab, click Run whether user is logged on or not, and then click OK.

See Also

Concepts

Overview of RBS (SharePoint Foundation 2010)
Plan for RBS (SharePoint Foundation 2010)
Install and configure RBS (SharePoint Foundation 2010)
Install and configure RBS with a 3rd party provider (SharePoint Foundation 2010)
Set a content database to use RBS (SharePoint Foundation 2010)
Migrate content into or out of RBS (SharePoint Foundation 2010)
Disable RBS on a content database (SharePoint Foundation 2010)

Other Resources

Upgrading from a stand-alone installation of Windows SharePoint Services 3.0 to SharePoint Foundation 2010 when content databases exceed 4 GB (RBS)


Disable RBS on a content database (SharePoint Foundation 2010)

You can disable Remote BLOB Storage (RBS) on any content database. After you disable RBS on a content database, binary large objects (BLOBs) are stored inline in SQL Server for all subsequent writes to the content database. This article describes how to disable RBS on a content database.

You can disable RBS on a content database by setting the active provider name to the empty string in Windows PowerShell. Each content database has a RemoteBlobStorageSettings property that can be used to invoke the SetActiveProviderName method.

This action does not change the storage location of any BLOBs that have previously been stored in RBS or inline storage. Disabling RBS does not uninstall RBS. We do not recommend that you uninstall RBS.

This operation can be performed on any Web server in the farm. You only need to perform the operation one time on one Web server for each content database for which you want to disable RBS.

Caution:

Do not use the Disable() method on the RemoteBlobStorageSettings object. This method is used only to uninstall RBS, and it is not recommended to simply disable the writing of new BLOBs into RBS.

You must use Windows PowerShell 2.0 cmdlets to disable RBS. There is no user interface option for this task.

To disable RBS 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. At the Windows PowerShell command prompt, type the following commands:

    Copy Code
    $site=Get-SPSite "<http://yourSiteURL>"
$rbss=$site.ContentDatabase.RemoteBlobStorageSettings
$rbss.SetActiveProviderName("")

    Where <http://yourSiteURL> is the Web application that is attached to the content database that is being disabled for RBS.

    For more information, see Get-SPSite.


StorSimple RBS performance in SharePoint 2010 (white paper)

Published: May 12, 2011

This paper explains the Remote BLOB Storage (RBS) feature as it applies to Microsoft SharePoint Server 2010 and analyzes its performance impacts on key attributes of a SharePoint farm such as database size, database backup size, transaction response times, backup times, and restore times. Although the white paper was written specifically for SharePoint Server 2010, most of the information — except for the section, "Effects of RBS on crawl performance" — also applies to Microsoft SharePoint Foundation 2010.

You can download the white paper in any of the following formats:

  • Word

  • PDF

  • XPS


Security and permissions (SharePoint Foundation 2010)

This section describes how to manage security and permissions for Microsoft SharePoint Foundation 2010.

In this section:

  • Configure custom permissions (SharePoint Foundation 2010)

  • Change passwords used for administration accounts (SharePoint Foundation 2010)

  • Configure People Picker (SharePoint Foundation 2010)

  • Allow or prevent Contributors ability to edit scriptable Web Parts (SharePoint Foundation 2010)

  • How to configure AD FS v 2.0 in SharePoint Foundation 2010


Configure custom permissions (SharePoint Foundation 2010)
See Also

For more control over the level of access to a site, site collection, or site content, you can define custom permission levels. For more information, see Determine permission levels and groups (SharePoint Foundation 2010) and User permissions and permission levels (SharePoint Foundation 2010).

In this procedure:

  • Customize an existing permission level

  • Copy an existing permission level

  • Create a permission level

Customize an existing permission level

If the custom permission level that you want is nearly identical to an existing default permission level and you do not need to use the default permission level, you can customize the default permission level.

To customize an existing permission level

  1. Verify that you have one of the following administrative credentials:

    • You are a member of the Administrators group for the site collection.

    • You are a member of the Owners group for the site.

    • You have the Manage Permissions permission.

  2. On the Site Settings page, under Users and Permissions, click Site permissions.

  3. In the Manage section of the ribbon, click Permission Levels.

  4. In the list of permission levels, click the name of the permission level you want to customize.

  5. In the list of permissions, select or clear the check boxes to add permissions to or remove permissions from the permission level.

  6. Click Submit.

Copy an existing permission level

If the custom permission level that you want is similar to an existing default permission level, and you need to use both the default permission level and your custom permission level, you can copy the default permission level, and then modify the copy and save it as a new permission level.

To copy an existing permission level

  1. Verify that you have one of the following administrative credentials:

    • You are a member of the Administrators group for the site collection.

    • You are a member of the Owners group for the site.

    • You have the Manage Permissions permission.

  2. On the Site Settings page, under Users and Permissions, click Site permissions.

  3. In the Manage section of the ribbon, click Permission Levels.

  4. In the list of permission levels, click the name of the permission level you want to copy.

  5. At the bottom of the page, click Copy Permission Level.

  6. On the Copy Permission Level page, in the Name field, type a name for the new permission level.

  7. In the Description field, type a description for the new permission level.

  8. In the list of permissions, select or clear the check boxes to add permissions to or remove permissions from the permission level.

  9. Click Create.

Create a permission level

If there is no permission level similar to the one you need, you can create one.

To create a permission level

  1. Verify that you have one of the following administrative credentials:

    • You are a member of the Administrators group for the site collection.

    • You are a member of the Owners group for the site.

    • You have the Manage Permissions permission.

  2. On the Site Settings page, under Users and Permissions, click Site permissions.

  3. In the Manage section of the ribbon, click Permission Levels.

  4. On the toolbar, click Add a Permission Level.

  5. On the Add a Permission Level page, in the Name field, type a name for the new permission level.

  6. In the Description field, type a description of the new permission level.

  7. In the list of permissions, select the check boxes to add permissions to the permission level.

  8. Click Create.

See Also

Other Resources

Resource Center: Security and Authentication for SharePoint Foundation 2010


Change passwords used for administration accounts (SharePoint Foundation 2010)
See Also

Published: July 8, 2010

Certain Microsoft SharePoint Foundation services and features must be associated with a Windows account in order to run. If the account has a password -- that is, if the account is anything other than the Local System account, the Local Service account, or the Network Service account -- then the password in SharePoint Foundation must be updated whenever the account's password changes.

There are two ways to keep passwords synchronized between Windows and SharePoint Foundation: automatically and manually. To synchronize passwords automatically you can register managed accounts and configure SharePoint Foundation to change the managed accounts' passwords according to a schedule. SharePoint Foundation automatically generates a new password, updates the password in Active Directory Domain Services (AD DS), and propagates the changes to other servers in the farm. For more information about managed accounts, see Plan automatic password change (SharePoint Foundation 2010).

Warning:

Windows Server 2008 R2 includes managed accounts at the operating system level. Do not use Windows Server 2008 R2 managed accounts. They are not compatible with SharePoint Foundation managed accounts.

We recommend that you use SharePoint Foundation managed accounts when possible. You can use managed accounts to control the passwords for the following things:

  • Central administration

  • Timer service

  • Service applications

  • Application pools

When managed accounts are unsuitable, you must change passwords in SharePoint Foundation manually when the passwords change in AD DS. Passwords must be changed manually for the following things:

  • SQL Server services

  • The default content access account

The articles in this section contain procedures for changing the passwords for accounts that SharePoint Foundation uses. In this section:

  • Configure automatic password change (SharePoint Foundation 2010)

  • Change passwords for SQL Server services (SharePoint Foundation 2010)

  • Change the password for the default content access account (SharePoint Foundation 2010)

See Also

Concepts

Plan automatic password change (SharePoint Foundation 2010)


Configure automatic password change (SharePoint Foundation 2010)
See Also

Automatic password change enables Microsoft SharePoint Foundation 2010 to automatically generate long, cryptographically-strong passwords on a schedule that you can determine.

In this article:

  • Configure managed accounts

  • Configure automatic password change settings

  • Troubleshooting automatic password change

Configure managed accounts

You need to register managed accounts with the farm to make the accounts available to multiple services. You can register a managed account by using the Register Managed Account page in Central Administration. There are no options on the Register Managed Account page to create an account in Active Directory Domain Services, or on the local computer. The options can be used to register an existing account on the SharePoint Foundation 2010 farm. Perform the steps in the following procedure to use Central Administration to configure managed account settings.

To configure managed account settings by using Central Administration

  1. Verify that the user account that is performing this procedure is a farm administrator.

  2. On the Central Administration Web site, select Security.

  3. Under General Security, click Configure managed accounts.

  4. On the Managed Accounts page, click Register Managed Account.

  5. In the Account Registration section of the Register Managed Account page, enter the service account credentials.

  6. In the Automatic Password Change section, select the Enable automatic password change check box to allow SharePoint Foundation 2010 to manage the password for the selected account. Next, enter a numeric value that indicates the number of days prior to password expiration that the automatic password change process will be initiated.

  7. In the Automatic Password Change section, select the Start notifying by e-mail check box, and then enter a numeric value that indicates the number of days prior to the initiation of the automatic password change process that an e-mail notification will be sent. You can then configure a weekly or monthly e-mail notification schedule.

  8. Click OK.

Configure automatic password change settings

Use the Password Management Settings page of Central Administration to configure farm-level settings for automatic password changes. Farm administrators can configure the notification e-mail address that will be used to send all password change notification e-mails, as well as monitoring and scheduling options. Perform the steps in the following procedure to use Central Administration to configure automatic password change settings.

To configure automatic password change settings by using Central Administration

  1. Verify that the user account that is performing this procedure is a farm administrator.

  2. On the Central Administration Web site, click Security.

  3. Under General Security, click Configure password change settings.

  4. In the Notification E-Mail Address section of the Password Management Settings page, enter the e-mail address of an individual or group to be notified of any imminent password change or expiration events.

  5. If automatic password change is not configured for a managed account, enter a numeric value in the Account Monitoring Process Settings section that indicates the number of days prior to password expiration that a notification will be sent to the e-mail address configured in the Notification E-Mail Address section.

  6. In the Automatic Password Change Settings section, enter a numeric value that indicates the number of seconds that automatic password change will wait (after notifying services of a pending password change) before initiating the change. Enter a numeric value that indicates the number of times a password change will be attempted before the process stops.

  7. Click OK.

Troubleshooting automatic password change

Use the following guidance to avoid the most common issues that can occur when you configure automatic password change.

Password mismatch

If the automatic password change process fails because there is a password mismatch between Active Directory Domain Services (AD DS) and SharePoint Foundation 2010, the password change process can result in access denial at login, an account lockout, or AD DS read errors. If any of these issues occur, make sure your AD DS passwords are configured correctly and that the AD DS account has read access for setup. Use Windows PowerShell to fix any password mismatch issues that might occur, and then resume the password change process.

To correct for a password mismatch

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs. Click Microsoft SharePoint 2010 Products.

  3. Click SharePoint 2010 Management Shell.

  4. From the Windows PowerShell command prompt, type the following ENTER:

    Copy Code
    Set-SPManagedAccount [-Identity] <SPManagedAccountPipeBind> -ExistingPassword <SecureString> -UseExistingPassword $true

    For more information, see Set-SPManagedAccount.

Service account provisioning failure

If service account provisioning or re-provisioning fails on one or more servers in the farm, check the status of the Timer Service. If the Timer Service has stopped, restart it. Consider using the following Stsadm command to immediately start Timer Service administration jobs: stsadm -o execadmsvcjobs

If restarting the Timer Service does not resolve the issue, use Windows PowerShell to repair the managed account on each server in the farm that has experienced a provisioning failure.

To resolve a service account provisioning failure

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs. Click Microsoft SharePoint 2010 Products.

  3. Click SharePoint 2010 Management Shell.

  4. From the Windows PowerShell command prompt, type the following:

    Copy Code
    Repair-SPManagedAccountDeployment

    For more information, see Repair-SPManagedAccountDeployment.

If the preceding procedure does not resolve a service account provisioning failure, it is likely because the farm encryption key cannot be decrypted. If this is the issue, use Windows PowerShell to update the local server pass phrase to match the pass phrase for the farm.

To update the local server pass phrase

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs. Click Microsoft SharePoint 2010 Products.

  3. Click SharePoint 2010 Management Shell.

  4. From the Windows PowerShell command prompt, type the following:

    Copy Code
    Set-SPPassPhrase -PassPhrase <SecureString> -ConfirmPassPhrase <SecureString> -LocalServerOnly $true

    For more information, see Set-SPPassPhrase.

Imminent password expiration

If the password is about to expire, but automatic password change has not been configured for this account, use Windows PowerShell to update the account password to a new value that can be chosen by the administrator or automatically generated. After you have updated the account password, make sure the Timer Service is started and the Administrator Service is enabled on all servers in the farm. Then, the password change can be propagated to all of the servers in the farm.

To update the account password

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click All Programs. Click Microsoft SharePoint 2010 Products.

  3. Click SharePoint 2010 Management Shell.

  4. To update the account password to a new value chosen by the administrator, from the Windows PowerShell command prompt, type the following:

    Copy Code
    Set-SPManagedAccount [-Identity] <SPManagedAccountPipeBind> -Password <SecureString>

  5. To update the account password to a new automatically generated value, from the Windows PowerShell command prompt, type the following:

    Copy Code
    Set-SPManagedAccount [-Identity] <SPManagedAccountPipeBind> -AutoGeneratePassword $true

    For more information, see Set-SPManagedAccount.

Requirement to change the farm account to a different account

If you need to change the farm account to a different account, use the following Stsadm command: stsadm.exe -o updatefarmcredentials -userlogin DOMAIN\username -password password

See Also

Other Resources

Resource Center: Security and Authentication for SharePoint Foundation 2010


Change passwords for SQL Server services (SharePoint Foundation 2010)

Published: July 8, 2010

The SQL Server service and the SQL Server Agent service must be associated with Windows accounts in order to run. If the accounts have passwords -- that is, if they are anything other than the Local System account, the Local Service account, or the Network Service account -- then you must update the password for the service when the account's password changes.

Important:

Perform these procedures during a scheduled maintenance period. When you change the password, you will have to restart the service. SharePoint Foundation will be unable to connect to the database while the service is unavailable.

Important:

Do not change the passwords for the service accounts when a failover cluster node is offline. If you do this, you will have to reset the password again when all nodes are back online.

In this article:

  • Change the password for the SQL Server service

  • To change the password for the SQL Server Agent service

Change the password for the SQL Server service

  1. Verify that you have the following administrative credentials:

    • To change the password for the SQL Server service, you must be a member of the Administrators group on the computer that is running SQL Server.

  2. Click Start, and then click Server Manager.

  3. In the navigation pane of the Server Manager window, expand Configuration, and then click Services.

  4. In the middle pane, right-click the service named SQL Server (MSSQLSERVER), and then click Properties.

  5. In the Properties dialog box, on the Log On tab, type the new password in the Password and Confirm password boxes.

  6. You must restart the service for the changes to be saved. On the General tab, under Service status, click Stop to stop the service.

  7. If a dialog box appears that notifies you that other services will also stop, click Yes to stop the dependent services.

  8. When the service has stopped, click Start to start the service.

  9. Click OK to save the changes.

To change the password for the SQL Server Agent service

  1. Verify that you have the following administrative credentials:

    • To change the password for the SQL Server Agent service, you must be a member of the Administrators group on the computer that is running SQL Server.

  2. Click Start, and then click Server Manager.

  3. In the navigation pane of the Server Manager window, expand Configuration, and then click Services.

  4. In the middle pane, right-click the service named SQL Server Agent (MSSQLSERVER), and then click Properties.

  5. In the Properties dialog box, on the Log On tab, type the new password in the Password and Confirm password boxes.

  6. You must restart the service for the changes to be saved. On the General tab, under Service status, click Stop to stop the service.

  7. If a dialog box appears that notifies you that other services will also stop, click Yes to stop the dependent services.

  8. When the service has stopped, click Start to start the service.

  9. Click OK to save the changes.


Change the password for the default content access account (SharePoint Foundation 2010)

Published: July 8, 2010

Use this procedure to change the password for the default content access account. The default content access account is the account that is used to crawl content. This account can be overridden by specifying a different account by using a crawl rule. This account must have the Read permission for the content that the account is crawling. It is a best practice to limit the account's access to the content to read-only. If the account password expires and is not updated, the search feature will be unable to crawl content.

Only change the default content access account's password if it has been changed in Active Directory. The credentials that you enter are checked against those on the domain controller. If you enter the new password before the password is changed on the domain controller, an error will result and the settings will not be changed.

Note:

This procedure changes only the password for the default content access account. If you specified a different account in a crawl rule, and if you want to change that account's password, you must change the crawl rule.

Follow these steps to configure the password for the default content access account on the computer that is running the SharePoint Central Administration Web site.

To change the password for the default content access account

  1. Verify that you have the following administrative credentials:

    • To change the password for the default content access account, you must be a member of the Farm Administrators group (WSS_RESTRICTED_WPG Windows security group).

  2. Ensure that the SPAdmin service is running on all servers in the farm.

  3. On the home page of the SharePoint Central Administration Web site, under System Settings, select Manage services on server.

  4. Click SharePoint Foundation Search.

  5. On the Configure Microsoft SharePoint Foundation Search Service Settings page, in the Content Access Account section, type the new password in the Password box.

  6. Click OK to save the changes.

  7. Optionally, disable the SPAdmin service on any server in the farm that you do not want to run the service.


Configure People Picker (SharePoint Foundation 2010)
See Also

Published: February 3, 2011

People Picker is configured at the zone level for a farm by using the Stsadm setproperty operation. By configuring the settings for the control, you can filter and restrict the results that are displayed when a user searches for a user, group, or claim. Those settings will apply to every site within the site collection.

The information in this article applies only to Web applications that use Windows authentication in either classic mode or claims mode.

The People Picker control is used to find and select users, groups, and claims when a site, list, or library owner assigns permissions in Microsoft SharePoint Foundation 2010. People Picker is configured at the zone level for a farm by using the Stsadm setproperty operation. By configuring the settings for the control, you can filter and restrict the results that are displayed when a user searches for a user, group or claim. Those settings will apply to every site within the site collection. For more information about the People Picker properties, see Peoplepicker: Stsadm properties.

Note:

There are no Windows PowerShell commands to configure People Picker.

This article contains information about how to configure People Picker for specific scenarios. For more information about the People Picker control and how it works, its relationship to authentication and claim providers, and how to plan for People Picker, see People Picker overview (SharePoint Foundation 2010).

Before you perform the procedures in this article, you must do the following:

  • Verify that the account you use to run Stsadm is a member of the local Administrators group on the server on which SharePoint Foundation 2010 is installed.

  • Open the command prompt window as an administrator to perform the procedures in this article.

  • In the command prompt on the driver where SharePoint Foundation 2010 is installed, change to the following directory: %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\14\Bin.

In this article:

  • Check the setting value for any property

  • Clear a property value from People Picker

  • Set an encryption key for use with a one-way trust

  • Enable cross-forest or cross-domain queries when using a one-way trust

  • Restrict People Picker to a certain group in Active Directory

  • Define the location of administrator accounts

  • Force People Picker to pick only from users in the site collection

  • Filter Active Directory accounts by using LDAP queries

  • Return only non-Active Directory user accounts

Check the setting value for any property

To check the setting for any People Picker property, type the following command:

stsadm.exe -o getproperty -pn<Property Name>-url<Web application URL>

For more information, see Peoplepicker: Stsadm properties (http://technet.microsoft.com/en-us/library/cc263318(office.12).aspx).

Clear a property value from People Picker

You can remove the setting for a People Picker property by specifying the property name you want to clear, and using empty quotation marks for the property value.

To remove a property setting from People Picker, type the following command:

stsadm.exe -o setproperty -pn<Property Name>-pv "" -url<Web application URL>

For more information, see Peoplepicker-searchadforests: Stsadm property (http://technet.microsoft.com/en-us/library/cc263460(office.12).aspx).

Set an encryption key for use with a one-way trust

If the forest or domain on which SharePoint Foundation 2010 is installed has a one-way trust with another forest or domain, you must first set the credentials for an account that is allowed to authenticate with the forest or domain to be queried before you can use the Stsadm peoplepicker-searchadforests property.

Note:

The encryption key must be set on every front-end Web server in the farm on which SharePoint Foundation 2010 is installed.

To set an encryption key, type the following command:

stsadm.exe -o setapppassword -password<key>

For more information about querying additional forests or domains, see All you want to know about People Picker in SharePoint ( Functionality | Configuration | Troubleshooting ) Part-2 (http://go.microsoft.com/fwlink/p/?LinkId=207666).

Enable cross-forest or cross-domain queries when using a one-way trust

If the forest or domain on which SharePoint Foundation 2010 is installed has a one-way trust with another forest or domain, you must specify the credentials to be used to query the forest or domain, in addition to the names of the forests or domains to be queried. People Picker will only query the forests or domains that you specify in the peoplepicker-searchadforests property setting.

To specify the forests or domains to be queried along with the credentials, type the following command:

stsadm.exe -o setproperty -pn peoplepicker-searchadforests -pv<Valid list of forests or domains, Login name, Password>-url<Web application URL>

Note:

You do not need to include the encryption key password that you assigned to the account when you use the peoplepicker-searchadforests property. However, if you have not already set an encryption key for the account, en error message will be displayed.

The following example configures People Picker for use with a forest named Contoso.com and a domain named Fabrikam.com, and includes the credentials for each:

Copy Code
STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv "forest:Contoso.com,Contoso\User1,Password1; domain:Fabrikam.com,Fabrikam\User2,Password2" -url http://ServerName

For more information, see Peoplepicker-searchadforests: Stsadm property (http://technet.microsoft.com/en-us/library/cc263460(office.12).aspx).

Restrict People Picker to a certain group in Active Directory

If a Web application is using Windows authentication and the site user directory path is not set, the People Picker control searches the entire Active Directory to resolve users' names or find users, instead of searching only users within a particular organizational unit (OU). The Stsadm setsiteuseraccountdirectorypath operation allows the user's directory path to be set to a specific OU in the same domain. After the directory path is set to a site collection, the People Picker control will only search under that particular OU.

To restrict People Picker to a certain OU in Active Directory, type the following command:

stsadm -o setsiteuseraccountdirectorypath -path<Valid OU name>-url<Web application URL>

The following example configures People Picker to only return users and groups in the OU named "Sales":

Copy Code
stsadm -o setsiteuseraccountdirectorypath -path "OU=Sales,DC=ContosoCorp,DC=local" -url http://ServerName
Note:

Only a single site user directory path can be set at a time for a site collection. Because this property specifies only one OU at a time, you should run the Stsadm setsiteuseraccountdirectorypath operation only once per site collection.

For more information, see Setsiteuseraccountdirectorypath: Stsadm operation (http://technet.microsoft.com/en-us/library/cc263328(office.12).aspx).

Define the location of administrator accounts

Administrative user accounts are often located in a different OU from regular site users. If you have used the Stsadm setsiteuseraccountdirectorypath operation to force People Picker to only return query results from a specific OU, you must also set the Stsadm peoplepicker-serviceaccountdirectorypaths property so the administrator can manage the site collection.

Note:

Before the peoplepicker-serviceaccountdirectorypaths property will work, the Setsiteuseraccountdirectorypath operation must be set and contain a value.

To define the location of administrator accounts, type the following command:

Stsadm -o setproperty -pn peoplepicker-serviceaccountdirectorypaths -pv<A list of OU names>-url<Web application URL>

The following example configures People Picker to allow users that are in the OU "FarmAdmin":

Copy Code
stsadm -o setproperty -pn peoplepicker-serviceaccountdirectorypaths -pv "OU=FarmAdmin,DC=Contoso,DC=local" -url http://ServerName

For more information, see Peoplepicker-serviceaccountdirectorypaths: Stsadm property (http://technet.microsoft.com/en-us/library/cc263012(office.12).aspx).

Force People Picker to pick only from users in the site collection

The People Picker control consists of a text box, and two buttons; the Check Names button and the Browse button. The Check Names button is used to resolve a user name, group name or e-mail address exactly as it was typed into the text box. The Browse button opens the Select People and Groups dialog box, which can be used to submit a query for a full or partial string. The important difference between the two is that the Check Names button only resolves exactly what is in the text box, whereas the Select People and Groups dialog box searches for the query string. You can force People Picker to only return users who have permissions in the site collection by using either the PeoplePicker-Peopleeditoronlyresolvewithinsitecollection property or the PeoplePicker-Onlysearchwithinsitecollection property. However, the property you use to configure this restriction will depend on whether you want to set the restriction for the text box (People editor) and Check Names button, or for the Select People and Groups dialog box.

To force People Picker to only return users who have permissions in the site collection when the Check Names button is clicked, type the following command:

stsadm -o setproperty -pn peoplepicker-Peopleeditoronlyresolvewithinsitecollection -pv yes -url<Web application URL>

To force People Picker to only return users who have permissions in the site collection when the Select People and Groups dialog box is used, type the following command:

stsadm -o setproperty -pn peoplepicker-onlysearchwithinsitecollection -pv yes -url<Web application URL>

For more information, see Peoplepicker-onlysearchwithinsitecollection: Stsadm property (http://technet.microsoft.com/en-us/library/cc261988(office.12).aspx) and Peoplepicker-peopleeditoronlyresolvewithinsitecollection: Stsadm property (SharePoint Foundation 2010).

Filter Active Directory accounts by using LDAP queries

You can use a Lightweight Directory Access Protocol (LDAP) query to create a custom filter for displaying query results. For more information about LDAP queries, see LDAP Query Basics (http://go.microsoft.com/fwlink/p/?LinkId=207670).

To use a custom LDAP query, type the following command:

Stsadm -o setproperty -pn peoplepicker-searchadcustomfilter -pv<LDAP query filter>-url<Web application URL>

The following example filters out user accounts that do not have e-mail addresses, or that are disabled. Because security groups do not always have e-mail addresses associated with them, an OR statement is used to ensure that security groups are still included in the query results:

Copy Code
stsadm -o setproperty -pn peoplepicker-searchadcustomfilter -pv "(|(&(mail=*)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))(objectcategory=group))" -url http://ServerName

The following example only returns active users, and not groups:

Copy Code
stsadm -o setproperty -pn peoplepicker-searchadcustomfilter -pv "(&(objectCategory=person)(objectClass=user)(!userAccountControl:1.2.840.113556.1.4.803:=2))" -url http://ServerName

For an explanation of the user account control string used in this query, see Search Filter Syntax (http://go.microsoft.com/fwlink/p/?LinkId=210020).

The following example returns a list of Active Directory users with the title "Manager":

Copy Code
stsadm -o setproperty -pn peoplepicker-searchadcustomfilter -pv "((Title=Manager))" -url http://ServerName
Important:

Remember that every time you run the setproperty command for a specific property, that property's current values will be overwritten by the new values you specify. If you need to filter query results based on multiple criteria, you will need to build a compound LDAP query that includes all the values for which you want to filter.

For more information, see Peoplepicker-searchadcustomfilter: Stsadm property (http://technet.microsoft.com/en-us/library/cc263452(office.12).aspx).

Return only non-Active Directory user accounts

If your Web application uses forms-based authentication, you can prevent People Picker from returning Active Directory accounts in the query results.

To return only non-Active Directory user accounts, type the following command:

stsadm -o setproperty -pn peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode -pv yes -url<Web application URL>

For more information, see Peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode: Stsadm property (http://technet.microsoft.com/en-us/library/cc263264(office.12).aspx).

See Also

Other Resources

Resource Center: Security and Authentication for SharePoint Foundation 2010


Allow or prevent Contributors ability to edit scriptable Web Parts (SharePoint Foundation 2010)
See Also

Published: June 28, 2011

In SharePoint Foundation 2010, Web Parts are categorized as to whether or not users with the default Contribute permission level can add or modify JavaScript.

Users who have the default Contribute permission level cannot add or modify scriptable Web Parts. This is because the scriptable Web Parts are marked as "unsafe against Contributor scripting" in a web.config file by default and the default setting in Central Administration is "Prevent contributors from adding or editing scriptable Web Parts". However, when the scriptable Web Parts are marked as "unsafe against Contributor scripting", a member of the Farm Administrators group can change the Web Part Security setting in Central Administration to allow users with the Contribute permissions level to edit scriptable Web Parts.

Developers can set scriptable Web Parts to "safe against Contributor scripting" in a web.config file. In this situation, the scriptable Web Parts can be edited by users with the Contribute permission level without any actions by a member of the Farm Administrators group. For more information about these safe Web Parts, see the "About editing Web Parts" section in Contribute permission level overview (SharePoint Foundation 2010).

The following table shows the effective behavior of a given Web Part with different settings from developers and members of the Farm Administrators group.

Settings | Farm administrator allows contributors to edit scriptable web parts | Farm administrator prevents contributors from editing scriptable web parts (default)
Developer marks part type as "SafeAgainstScript=true" | Contributors can edit scriptable Web Parts | Contributors can edit scriptable Web Parts
Developer marks part type as "SafeAgainstScript=false" (default) | Contributors can edit scriptable Web Parts | Contributors cannot edit scriptable Web Parts
Note:

A change to the Web Part Security setting in Central Administration applies to all scriptable Web Parts in the Web Application.

In this article:

  • Allow or prevent Contributors ability to edit scriptable Web Parts

Allow or prevent Contributors ability to edit scriptable Web Parts

When upgrading from Windows SharePoint Services 3.0 to SharePoint Foundation 2010, users with the Contribute permission level will not be able to edit scriptable Web files and Web parts any longer. A member of the Farm Administrators group can enable them to do this by change the setting in Central Administration.

Note:

To secure Web Parts from script injection, this setting is set to Prevent contributors from adding or editing scriptable Web Parts by default.

To enable or prevent Contributors from editing scriptable Web Parts by using Central Administration

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration Web site, in the Application Management section, click Manage web applications.

  3. Click the Web Application for which you want to change settings.

  4. In the Security group of the ribbon, click Web Part Security.

  5. In the Scriptable Web Parts section of the Security For Web Part Pages dialog box, select the appropriate option.

    • To enable the setting:

      Select Allows contributors to add or edit scriptable Web Parts.

    • To disable the setting:

      Select Prevent contributors from adding or editing scriptable Web Parts.

  6. Click OK.

See Also

Concepts

Contribute permission level overview (SharePoint Foundation 2010)


How to configure AD FS v 2.0 in SharePoint Foundation 2010

Published: July 14, 2011

The procedures in this article describe how to configure Active Directory Federation Services version 2.0 (AD FS) in Microsoft SharePoint Foundation 2010.

You can use Active Directory Federation Services (AD FS) 2.0 with the Windows Server 2008 operating system to build a federated identity management solution that extends distributed identification, authentication, and authorization services to Web-based applications across organization and platform boundaries. By deploying AD FS 2.0, you can extend your organization's existing identity management capabilities to the Internet.

In this article, AD FS v2 is our identity provider, also known as IP-STS (Security Token Service). AD FS will provide claims-based authentication. To begin, AD FS needs to be configured with information about our relying party, in this case, SharePoint Foundation 2010. From the Microsoft SharePoint 2010 Products perspective, AD FS needs to be configured to trust the IP-STS that is sending a claims-based mapping. Finally, a Web application and site collection are created that will use the claims-based authentication level.

Note:

You must install and configure a server running Active Directory Federation Services (AD FS) 2.0 before you perform the procedures in this article. For information about configuring a server to run AD FS 2.0, see the AD FS 2.0 Deployment Guide (http://go.microsoft.com/fwlink/p/?LinkId=191723).

The following video illustrates the step-by-step process that configures Active Directory Federation Services version 2.0 (AD FS) in Microsoft SharePoint Foundation 2010.

Configure AD FS for SharePoint Server 2010

Running time: 9:43

Play video Watch the " Configure SharePoint Server 2010 with AD FS trusted claims " video

Download video For an optimal viewing experience, download the " Configure SharePoint Server 2010 with AD FS trusted claims " video.

Right-click the link, and then click Save Target As to download a copy. Clicking the link will open a .wmv file in the default video viewer for full-resolution viewing.

In this article:

  • Configure a relying party

  • Configure the claim rule

  • Export the token signing certificate

  • Exporting multiple parent certificates

  • Import a token signing certificate by using Windows PowerShell

  • Define a unique identifier for claims mapping by using Windows PowerShell

  • Create a new authentication provider

  • Associate a Web application with a trusted identity provider

  • Create a site collection

Note:

The steps listed in this article need to be completed in consecutive order.

Configure a relying party

Use the procedure in this section to configure a relying party. The relying party defines how the AD FS recognizes the relying party and issues claims to it.

To configure a relying party

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer. For additional information about accounts and group memberships, see Local and Domain Default Groups.

  2. Open the Active Directory Federation Services (AD FS) 2.0 Management console.

  3. In the left pane, expand Trust Relationships, and then double-click the Relying Party Trusts folder.

  4. In the right pane, click Add Relying Party Trust. This opens the Active Directory Federation Services (AD FS) 2.0 configuration wizard.

  5. On the Welcome to the Add Relying Party Trust Wizard page, click Start.

  6. Select Enter data about the relying party manually, and then click Next.

  7. Type a relying party name and click Next.

  8. Make sure Active Directory Federation Services (AD FS) 2.0 Profile is selected, and click Next.

  9. Do not use an encryption certificate. Click Next.

  10. Click to select the Enable support for the WS-Federation Passive protocol check box.

  11. In the WS-Federation Passive protocol URL field, type the name of the Web application URL, and append /_trust/ (for example, https://WebAppName/_trust/). Click Next.

    Note:

    The name of the URL has to use Secure Socket Layer (SSL).

  12. Type the name of the relying party trust identifier (for example, urn:sharepoint:WebAppName), and click Add. Click Next.

  13. Select Permit all users to access this relying party. Click Next.

  14. On the Ready to Add Trust page, there is no action required, click Next.

  15. On the Finish page, click Close. This opens the Rules Editor Management console. Use this console to configure the mapping of claims from an LDAP Web application to SharePoint Foundation 2010.

Configure the claim rule

Use the procedure in this step to send values of a Lightweight Directory Access Protocol (LDAP) attribute as claims and specify how the attributes will map to the outgoing claim type.

To configure a claim rule

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer. For additional information about accounts and group memberships, see Local and Domain Default Groups.

  2. On the Issuance Transform Rules tab, click Add Rule.

  3. On the Select Rule Template page, select Send LDAP Attributes as Claims. Click Next.

  4. On the Configure Rule page, type the name of the claim rule in the Claim rule name field.

  5. From the Attribute Store drop-down list, select Active Directory.

  6. In the Mapping of LDAP attributes to outgoing claim types section, under LDAP Attribute, select E-Mail Addresses.

  7. Under Outgoing Claim Type, select E-Mail Address.

  8. Under LDAP Attribute, select Token Groups-Unqualified Names.

  9. Under Outgoing Claim Type, select Role.

  10. Click Finish, and then click OK.

Export the token signing certificate

Use the procedure in this section to export the token signing certificate of the AD FS Server with which you want to establish a trust relationship, and then copy the certificate to a location that SharePoint Foundation 2010 can access.

To export a token signing certificate

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer. For additional information about accounts and group memberships, see Local and Domain Default Groups.

  2. Open the Active Directory Federation Services (AD FS) 2.0 Management console.

  3. In the left pane, click to expand Service, and then click the Certificates folder.

  4. Under Token signing, click the primary token certificate as indicated in the Primary column.

  5. In the right pane, click View Certificate link. This displays the properties of the certificate.

  6. Click the Details tab.

  7. Click Copy to File. This starts the Certificate Export Wizard.

  8. On the Welcome to the Certificate Export Wizard page, click Next.

  9. On the Export Private Key page, click No, do not export the private key, and then click Next.

  10. On the Export File Format page, select DER encoded binary X.509 (.CER), and then click Next.

  11. On the File to Export page, type the name and location of the file you want to export, and then click Next. For example, enter C:\ADFS.cer.

  12. On the Completing the Certificate Export Wizard page, click Finish.

Exporting multiple parent certificates

To complete the configuration of the AD FS Server, copy the .CER file to the computer running AD FS.

The token signing certificate may have one or more parent certificates in its chain. If it does, every certificate in that chain needs to be added to the SharePoint Foundation list of trusted root authorities.

To determine if one or more parent certificates exist, use the following steps.

Note:

These steps should be repeated until all certificates have been exported up to the root authority certificate.

To export multiple parent certificates

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer. For additional information about accounts and group memberships, see Local and Domain Default Groups.

  2. Open the Active Directory Federation Services (AD FS) 2.0 Management console.

  3. In the left pane, click to expand Service, and then click the Certificates folder.

  4. Under Token signing, click the primary token certificate as indicated in the Primary column.

  5. In the right pane, click View Certificate link. This displays the properties of the certificate.

  6. Click the Certification tab.

    This displays any other certificate(s) in the chain.

  7. Click the Details tab.

  8. Click Copy to File. This starts the Certificate Export Wizard.

  9. On the Welcome to the Certificate Export Wizard page, click Next.

  10. On the Export Private Key page, click No, do not export the private key, and then click Next.

  11. On the Export File Format page, select DER encoded binary X.509 (.CER), and then click Next.

  12. On the File to Export page, type the name and location of the file you want to export, and then click Next. For example, enter C:\ADFS.cer.

  13. On the Completing the Certificate Export Wizard page, click Finish.

Import a token signing certificate by using Windows PowerShell

Use this section to import the token signing certificates to the trusted root authority list that resides on the SharePoint server. This step must be repeated for every token signing certificate in the chain until the root certificate authority is reached.

To import a token signing certificate 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, import the parent certificate of the token signing certificate (that is, the root authority certificate), as shown in the following syntax:

    Copy Code
    $root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\adfsParent.cer")
    Copy Code
    New-SPTrustedRootAuthority -Name "Token Signing Cert Parent" -Certificate $root

  6. From the Windows PowerShell command prompt, import the token signing certificate that was copied from the AD FS server, as shown in the following syntax:

    Copy Code
    $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\adfs.cer ")
    Copy Code
    New-SPTrustedRootAuthority -Name "Token Signing Cert" -Certificate $cert

For additional information about the New-SPTrustedRootAuthority cmdlet, see New-SPTrustedRootAuthority

Define a unique identifier for claims mapping by using Windows PowerShell

Use the procedure in this section to define a unique identifier for claims mapping. Typically, this information is in the form of an e-mail address and the administrator of the trusted STS will have to provide this information because only the owner of the STS knows which claim type will be always unique for each user.

To define a unique identifier for claims mapping 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, create an identity claim mapping, as shown in the following syntax:

    Copy Code
    $map = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming

  6. From the Windows PowerShell command prompt, create the role claim mapping as shown in the following syntax:

    Copy Code
    $map2 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming

For additional information about the New-SPClaimTypeMapping cmdlet, see New-SPClaimTypeMapping

Create a new authentication provider

Use the procedure in this section to create a new SPTrustedIdentityTokenIssuer.

To create a new authentication provider 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, create a new authentication provider, as shown in the following syntax.

    Note:

    The $realm variable defines the trusted STS that identifies a specific SharePoint farm and the $cert variable is the one that was used from the Import a token signing certificate by using Windows PowerShell section. The SignInUrl parameter is to the AD FS server.

    Copy Code
    $realm = "urn:sharepoint:WebAppName"
    Copy Code
    $ap = New-SPTrustedIdentityTokenIssuer -Name "SAML Provider" -Description "SharePoint secured by SAML" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2 -SignInUrl "https://congen1.contoso.local/adfs/ls" -IdentifierClaim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

For additional information about the New-SPTrustedIdentityTokenIssuer cmdlet, see New-SPTrustedIdentityTokenIssuer

Associate a Web application with a trusted identity provider

To configure an existing Web application to use SAML sign-in, the trusted identity provider in the claims authentication type section needs to be modified.

To configure an existing Web application to use the SAML Provider

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

  3. On the Application Management page, in the Web Applications section, click Manage web applications.

  4. Click to select the appropriate Web application.

  5. From the ribbon, click Authentication Providers.

  6. Under Zone, click the name of the zone. For example, Default.

  7. On the Edit Authentication page in the Claims Authentication Types section, click to select the new Trusted Identity provider name check box.

If you need to create a Web application and configure it to use SAML sign-in, see Create a new SharePoint Web application and configure it to use SAML sign-in.

Create a site collection

As a final step, create a SharePoint site collection and assign an owner. Remember that when adding a site collection administrator, you must enter the name in the format of your identity claim. For example, in this article, the identity claim is an e-mail address. For more information, see Create a site collection (SharePoint Foundation 2010).


About service applications and services (SharePoint Foundation 2010)

In Microsoft SharePoint Foundation 2010, individual services can be configured independently and third-party companies can add services to the platform. The services infrastructure gives you control over which services are deployed and how services are shared.

Services that are deployed are named service applications. A service application provides a resource that can be shared across sites throughout a farm, and can be accessed by users through a hosting Web application. Service applications are associated to Web applications by service application connections. Some services can be shared across farms.

For more information about the logical structure of services and service applications, see Services architecture planning (SharePoint Foundation 2010).

For more information about how to manage service applications, including instructions for publishing service applications across farms, see Manage service applications (SharePoint Foundation 2010) and Share service applications across farms (SharePoint Foundation 2010).

For more information about starting, stopping, and configuring services, Manage services on the server (SharePoint Foundation 2010).


Manage service applications (SharePoint Foundation 2010)
See Also

Microsoft SharePoint Foundation 2010 includes a set of service applications that you can use to share services across Web applications. In some cases, you can also share service applications across farms. You can manage service applications by using Central Administration or by using Windows PowerShell 2.0.

The following articles in this section provide general instructions for service applications:

  • Share service applications across farms (SharePoint Foundation 2010)

    In SharePoint Foundation 2010, you can share service applications across farms. This article describes how to establish trust between farms, publish a service application, and connect to a published service application in a remote farm.

  • Add or remove a service application connection to a Web application (SharePoint Foundation 2010)

    This article describes how to configure a service application connection, or proxy, to a Web application. A service application can be accessed by users only by way of its connection to a Web application. By default, all service applications are part of the default connection group.

  • Restrict or enable access to a service application (SharePoint Foundation 2010)

    By default, all service applications on the local farm are available to all Web applications on the local farm. However, you can restrict access to a service application so that it is available to only specified Web applications. This article describes how to restrict or enable access to a service application.

  • Assign or remove administrators to a service application (SharePoint Foundation 2010)

    In SharePoint Foundation 2010, you can assign additional administrators to a service application. This article describes how to do this.

  • Delete a service application (SharePoint Foundation 2010)

    You can delete a service application that is no longer being used. This article contains instructions for doing this.

You can create, configure, and manage the Business Data Connectivity service application. For more information about how to do this, see Business Data Connectivity service administration (SharePoint Foundation 2010).

See Also

Concepts

About service applications and services (SharePoint Foundation 2010)
Services architecture planning (SharePoint Foundation 2010)


Share service applications across farms (SharePoint Foundation 2010)
See Also

In Microsoft SharePoint Foundation 2010, some service applications can be shared across server farms. This article describes the process and caveats that are involved in sharing service applications.

By publishing a service application, you can optimize resources, avoid redundancy, and provide enterprise-wide services without installing a dedicated enterprise services farm. You can publish the Business Data Connectivity service application in a SharePoint Foundation 2010 farm.

The farm that contains the service application and publishes the service application so that other farms can consume the service application is known as the publishing farm. The farm that connects to a remote location to use a service application that the remote location is hosting is known as the consuming farm.

Note:

If you are familiar with Microsoft Office SharePoint Server 2007, you might find it useful to think of the publishing farm as the parent farm and the consuming farm as a child farm.

This article describes the steps that are required to publish and consume service applications across farms. These steps must be performed in the order listed.

  1. Exchange trust certificates between the farms.

    To start, an administrator of the consuming farm must provide two trust certificates to the administrator of the publishing farm: a root certificate and a security token service (STS) certificate. Additionally, an administrator of the publishing farm must provide a root certificate to the administrator of the consuming farm. By exchanging certificates, each farm acknowledges that the other farm can be trusted.

    For more information, see Exchange trust certificates between farms (SharePoint Foundation 2010).

  2. On the publishing farm, publish the service application.

    On the farm on which the service application is located, an administrator must explicitly publish the service application. Service applications that are not explicitly published are available to the local farm only.

    For more information, see Publish a service application (SharePoint Foundation 2010).

  3. On the consuming farm, set the permission to the appropriate service applications

    You must give the consuming farm permission to the Application Discovery and Load Balancing Service Application on the publishing farm. After doing this, give the consuming farm permission to the published service applications that it will be consuming.

    For more information, see Set permission to a published service application (SharePoint Foundation 2010).

  4. On the consuming farm, connect to the remote service application.

    After the publishing farm has published the service application, an administrator of the consuming farm can connect to that service application from the consuming farm if the address of the specific service application is known.

    For more information, see Connect to a service application on a remote farm (SharePoint Foundation 2010).

    Important:

    You cannot share a User Profile service application across farms that reside in separate domains unless you first establish a domain-level trust between the two domains.

  5. Add the shared service application to a Web application proxy group on the consuming farm.

    An administrator must associate the new service application connection with a local Web application on the consuming farm. Only Web applications that are configured to use this association can use the remote service application.

    For information about how to configure a Web application proxy group connection, see Add or remove a service application connection to a Web application (SharePoint Foundation 2010).

    Note:

    It is important that you plan the proxy group layout before you add service applications to proxy groups. For more information about how to plan the service application architecture, see Services architecture planning (SharePoint Foundation 2010).

See Also

Concepts

Technical diagrams (SharePoint Foundation 2010)


Exchange trust certificates between farms (SharePoint Foundation 2010)
See Also

In Microsoft SharePoint Foundation 2010, a SharePoint farm can connect to and consume a service application that is published on another SharePoint Foundation 2010 farm. For this to occur, the farms must exchange trust certificates.

This article describes how to exchange trust certificates between the publishing farm and the consuming farm. Note that both farms must participate in this exchange for service application sharing to work.

Important:

Before you start to share service applications, we highly recommend that you read the articles Share service applications across farms (SharePoint Foundation 2010) and Services architecture planning (SharePoint Foundation 2010).

You must use Windows PowerShell 2.0 commands to export and copy the certificates between farms. After the certificates are exported and copied, you can use either Windows PowerShell 2.0 commands or Central Administration to manage the trusts within the farm.

The instructions here assume the following criteria:

  • That the servers that are used for these procedures are running Windows PowerShell 2.0.

  • That the administrator will select and use the same server in each farm for all steps in the process.

  • If User Account Control (UAC) is turned on, you must run the Windows PowerShell 2.0 commands with elevated privileges.

In this article:

  • Exporting and copying certificates

  • Managing trust certificates using Windows Powershell

  • Managing trust certificates using Central Administration

Exporting and copying certificates

An administrator of the consuming farm must provide two trust certificates to the publishing farm: a root certificate and a security token service (STS) certificate. An administrator of the publishing farm must provide a root certificate to the consuming farm.

You can only export and copy certificates by using Windows PowerShell 2.0.

To export the root certificate from the consuming farm

  1. On a server that is running SharePoint Foundation 2010 on the consuming farm, verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click Administrative Tools.

  3. Click SharePoint 2010 Management Shell.

  4. At the Windows PowerShell command prompt, type each of the following commands:

    Copy Code
    $rootCert = (Get-SPCertificateAuthority).RootCertificate
    Copy Code
    $rootCert.Export("Cert") | Set-Content <C:\ConsumingFarmRoot.cer> -Encoding byte

    Where <C:\ConsumingFarmRoot.cer> is the path of the root certificate.

To export the STS certificate from the consuming farm

  1. At the Windows PowerShell command prompt, type the following commands:

    Copy Code
    $stsCert = (Get-SPSecurityTokenServiceConfig).LocalLoginProvider.SigningCertificate
    Copy Code
    $stsCert.Export("Cert") | Set-Content <C:\ConsumingFarmSTS.cer> -Encoding byte

    Where <C:\ConsumingFarmSTS.cer> is the path of the STS certificate.

To export the root certificate from the publishing farm

  1. On a server that is running SharePoint Foundation 2010 on the publishing farm, verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click Administrative Tools.

  3. Click SharePoint 2010 Management Shell.

  4. At the Windows PowerShell command prompt, type the following commands:

    Copy Code
    $rootCert = (Get-SPCertificateAuthority).RootCertificate
    Copy Code
    $rootCert.Export("Cert") | Set-Content <C:\PublishingFarmRoot.cer> -Encoding byte

    Where <C:\PublishingFarmRoot.cer> is the path of the root certificate.

To copy the certificates

  1. Copy the root certificate and the STS certificate from the server in the consuming farm to the server in the publishing farm.

  2. Copy the root certificate from the server in the publishing farm to a server in the consuming farm.

Managing trust certificates by using Windows Powershell

Managing trust certificates within a farm involves establishing trust. This section describes how to establish trust on both the consuming and publishing farms, using Windows PowerShell 2.0 commands.

Establishing trust on the consuming farm

To establish trust on the consuming farm, you must import the root certificate that was copied from the publisher farm and create a trusted root authority.

To import the root certificate and create a trusted root authority on the consuming farm

  1. At the Windows PowerShell command prompt on a server in the consuming farm, type the following commands:

    Copy Code
    $trustCert = Get-PfxCertificate <C:\PublishingFarmRoot.cer>
    Copy Code
    New-SPTrustedRootAuthority <PublishingFarm> -Certificate $trustCert

Where:

  • <C:\PublishingFarmRoot.cer> is the path of the root certificate that you copied to the consuming farm from the publishing farm.

  • <PublishingFarm> is a unique name that identifies the publishing farm. Each trusted root authority must have a unique name.

Establishing trust on the publishing farm

To establish trust on the publishing farm, you must import the root certificate that was copied from the consuming farm and create a trusted root authority. You must then import the STS certificate that was copied from the consuming farm and create a trusted service token issuer.

To import the root certificate and create a trusted root authority on the publishing farm

  1. At the Windows PowerShell command prompt on a server in the publishing farm, type the following commands:

    Copy Code
    $trustCert = Get-PfxCertificate <C:\ConsumingFarmRoot.cer>
    Copy Code
    New-SPTrustedRootAuthority <ConsumingFarm> -Certificate $trustCert

Where:

  • <C:\ConsumingFarmRoot.cer> is the name and location of the root certificate that you copied to the publishing farm from the consuming farm.

  • <ConsumingFarm> is a unique name that identifies the consuming farm. Each trusted root authority must have a unique name.

To import the STS certificate and create a trusted service token issuer on the publishing farm

  1. At the Windows PowerShell command prompt on a server in the publishing farm, type the following commands:

    Copy Code
    $stsCert = Get-PfxCertificate <c:\ConsumingFarmSTS.cer>
    Copy Code
    New-SPTrustedServiceTokenIssuer <ConsumingFarm> -Certificate $stsCert

Where:

  1. <C:\ConsumingFarmSTS.cer> is the path of the STS certificate that you copied to the publishing farm from the consuming farm.

  2. <ConsumingFarm> is a unique name that identifies the consuming farm. Each trusted service token issuer must have a unique name.

For more information about these Windows PowerShell 2.0 cmdlets, see the following articles:

  • Get-SPCertificateAuthority

  • Get-SPSecurityTokenServiceConfig

  • New-SPTrustedRootAuthority

  • New-SPTrustedServiceTokenIssuer

  • Get-PfxCertificate (http://go.microsoft.com/fwlink/p/?LinkID=178943&clcid=0x409)

For information about using a script to automate part of this process, see Exchange trust certificates between farms (http://go.microsoft.com/fwlink/p/?LinkId=230666).

Managing trust certificates by using Central Administration

You can manage trusts on a farm only after the relevant certificates have already been exported and copied to the farm.

To establish trust 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. On the SharePoint Central Administration Web site, click Security.

  3. On the Security page, in the General Security section, click Manage trust.

  4. On the Trust Relationship page, on the ribbon, click New.

  5. On the Establish Trust Relationship page:

    1. Supply a name that describes the purpose of the trust relationship.

    2. Browse to and select the Root Authority Certificate for the trust relationship. This must be the Root Authority Certificate that was exported from the other farm by using Windows PowerShell, as described in Exporting and copying certificates.

    3. If you are performing this task on the publishing farm, select the check box for Provide Trust Relationship. Type in a descriptive name for the token issuer and browse to and select the STS certificate that was copied from the consuming farm, as described in Exporting and copying certificates.

    4. Click OK.

    After a trust relationship is established, you can modify the Token Issuer description or the certificates that are used by clicking the trust, and then clicking Edit. You can delete a trust by clicking it, and then clicking Delete.

See Also

Concepts

Plan authentication methods (SharePoint Foundation 2010)
Configure claims authentication (SharePoint Foundation 2010)
Configure the security token service (SharePoint Foundation 2010)

Other Resources

Resource Center: Security and Authentication for SharePoint Foundation 2010


Publish a service application (SharePoint Foundation 2010)
See Also

In Microsoft SharePoint Foundation 2010, some service applications can be published across farms and thereby be made available over remote connections. This article describes how to publish a service application.

Important:

Before you start to share service applications, we highly recommend that you read the articles Share service applications across farms (SharePoint Foundation 2010) and Services architecture planning (SharePoint Foundation 2010).

In this article:

  • To publish a service application by using Central Administration

  • To publish a service application by using Windows PowerShell

To publish a service application 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. On the SharePoint Central Administration Web site, click Application Management, and then click Manage service applications.

  3. Click the row that contains the service application that you want to publish. Commands on the ribbon become available.

  4. On the ribbon, click Publish.

  5. In the Publish Service Application dialog box:

    1. Select the Connection Type that you want from the drop-down list.

    2. If you want the service application to be available to remote farms, select the check box for Publish this Service Application to other farms.

    3. We recommend that you use the instructions in Exchange trust certificates between farms (SharePoint Foundation 2010) to establish trust between the two farms.

    4. Copy the Published URL into Notepad or another text editor. You must provide this URL to remote farms to connect the remote farms to the published service application. The URL will be similar to the following: urn:schemas-microsoft-com:sharepoint:service:9c1870b7ee97445888d9e846519cfa27#authority=urn:uuid:02a493b92a5547828e21386e28056cba&authority=https://ua_powershell:32844/Topology/topology.svc.

  6. You can optionally provide descriptive text and a link to a Web page that will be visible to administrators of remote farms. After you have specified the publication options that you want, click OK to publish the service application.

To publish a service application by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  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:

    Copy Code
    Publish-SPServiceApplication -Identity <ServiceApplicationGUID>

    If you do not know the GUID of the service application, you can use the following Windows PowerShell 2.0 cmdlet to list all service applications in the farm, together with their GUIDS:

    Copy Code
    Get-SPServiceApplication

  5. To view the published service application load balancer URL, type the following command and record the output:

    Copy Code
    Get-SPTopologyServiceApplication

    Any connecting remote farms will need the information that is generated by this command.

See Also

Reference

Publish-SPServiceApplication
Get-SPServiceApplication
Get-SPTopologyServiceApplication

Concepts

Add or remove a service application connection to a Web application (SharePoint Foundation 2010)


Set permission to a published service application (SharePoint Foundation 2010)

Published: May 15, 2010

In Microsoft SharePoint Foundation 2010, you must establish a relationship between the publishing farm and the consuming farm by giving the consuming farm permission to the Application Discovery and Load Balancer Service Application on the publishing farm. After doing this, the consuming farm can be given permission to other service applications. This article describes how to configure permissions to the Application Discovery and Load Balancer Service Application and published service applications for the consuming farm.

Important:

Before you start to configure publishing and consuming farms, we highly recommend that you read the articles Share service applications across farms (SharePoint Foundation 2010) and Services architecture planning (SharePoint Foundation 2010).

In this article:

  • Set permission to the Application Discovery and Load Balancer Service Application and any other service application for a consuming farm by using Windows PowerShell

  • Set permission to the Application Discovery and Load Balancer Service Application and any other published service application for a consuming farm by using Central Administration

Important:

You must perform steps 1 through 5 in the Windows PowerShell procedure to obtain the consuming farm ID, which you must have in order to complete either the Windows PowerShell or Central Administration procedures.

Set permission to the Application Discovery and Load Balancer Service Application and any other service application for a consuming farm by using Windows PowerShell

The first procedure explains how to set permission to the Application and Load Balancer Service Application. The second explains how to set permissions to any other service applications.

To set permission to the Application Discovery and Load Balancer Service Application for a consuming farm by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On a server in the consuming farm, 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:

    Copy Code
    Get-SPFarm | Select Id

    For more information, see Get-SPFarm.

  6. On a server in the publishing farm, access the SharePoint 2010 Management Shell and at the Windows PowerShell command prompt, type the following commands:

    Copy Code
    $security=Get-SPTopologyServiceApplication | Get-SPServiceApplicationSecurity
    Copy Code
    $claimprovider=(Get-SPClaimProvider System).ClaimProvider
    Copy Code
    $principal=New-SPClaimsPrincipal -ClaimType "http://schemas.microsoft.com/sharepoint/2009/08/claims/farmid" -ClaimProvider $claimprovider -ClaimValue <consumingfarmid>
    Copy Code
    Grant-SPObjectSecurity -Identity $security -Principal $principal -Rights "Full Control"
    Copy Code
    Get-SPTopologyServiceApplication | Set-SPServiceApplicationSecurity -ObjectSecurity $security

    Where:

    Consumingfarmid is the GUID value of the consuming farm

    For more information, see the following:

    • Get-SPTopologyServiceApplication

    • Set-SPServiceApplicationSecurity

    • Get-SPServiceApplicationSecurity

    • New-SPClaimsPrincipal

    • Get-SPClaimProvider

    • Grant-SPObjectSecurity

To set permission to a published service application for a consuming farm by using Windows PowerShell

  1. At the Windows PowerShell command prompt, type the following commands:

    Copy Code
    $security=Get-SPServiceApplication <GUID>| Get-SPServiceApplicationSecurity
    Copy Code
    $claimprovider=(Get-SPClaimProvider System).ClaimProvider
    Copy Code
    $principal=New-SPClaimsPrincipal -ClaimType "http://schemas.microsoft.com/sharepoint/2009/08/claims/farmid" -ClaimProvider $claimprovider -ClaimValue <consumingfarmid>
    Copy Code
    Grant-SPObjectSecurity -Identity $security -Principal $principal -Rights <NamedAccessRights>
    Copy Code
    Set-SPServiceApplicationSecurity <GUID> -ObjectSecurity $security

    Where:

    Consumingfarmid is the GUID value of the consuming farm

    <GUID> is the ID of the published service application.

    <NamedAccessRights> is the name of the access right from the Get-SPServiceApplicationSecurity <GUID>.NamedRights.

For more information, see the following:

  • Get-SPServiceApplication

  • New-SPClaimsPrincipal

  • Get-SPServiceApplication

  • Get-SPServiceApplicationSecurity

  • Grant-SPObjectSecurity

  • Set-SPServiceApplicationSecurity

Set permission to the Application Discovery and Load Balancer Service Application and any other published service application for a consuming farm by using Central Administration

This procedure explains how to set permission to any service application, but most specifically, the Application and Load Balancer Service Application.

Important:

You must perform steps 1 through 5 in the Windows PowerShell procedure to obtain the consuming farm ID, which you must have in order to complete this procedure.

To set permission to the Application Discovery and Load Balancer Service Application and any other published service application for a consuming farm by using Central Administration

  1. On the server that hosts the Central Administration Web site for the publishing farm, verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.

  2. On the SharePoint Central Administration Web site, click Application Management, and then click Manage service applications.

  3. Click the row that contains Application Discovery and Load Balancer Service Application.

  4. On the ribbon, click Permissions.

  5. In the Connection Permissions dialog box, do the following:

    1. Manually paste the ID of the consuming farm from Step 5 of the Windows PowerShell section.

    2. Click Add.

    3. Select the consuming farm ID, and then select the Full Control check box.

    4. Click OK.

  6. Repeat steps 2 through 5 for any published service applications for which you want to enable access from the consuming farm and assign the necessary permission.


Connect to a service application on a remote farm (SharePoint Foundation 2010)
See Also

In Microsoft SharePoint Foundation 2010, you can publish some service applications to make them available over remote connections. By publishing a service application, you can optimize resources and avoid redundancy, and provide enterprise-wide services without installing a dedicated enterprise services farm. This article describes how to connect to and consume a published service application.

Important:

Before you start to share service applications, we highly recommend that you read the articles Share service applications across farms (SharePoint Foundation 2010) and Services architecture planning (SharePoint Foundation 2010).

You can connect to a service application that has been shared by another farm if you know the address of the farm's discovery service or the address of the service application. Be aware that you can only connect to a service application on a remote farm if the farm administrator for the remote farm has published the service application.

In this article:

  • To connect to a service application on a remote farm by using Central Administration

  • To connect to a service application on a remote farm by using Windows PowerShell

To connect to a service application on a remote farm by using Central Administration

  1. Verify that you are a member of the Farm Administrators SharePoint group.

  2. On the SharePoint Central Administration Web site, click Application Management, and then click Manage service applications.

  3. On the ribbon, click Connect.

  4. On the Connect drop-down menu, click the kind of service application to which you want to connect.

  5. On the Connect to a Remote Service Application page, type the appropriate URL in the Farm or Service Application address text box, and then click OK.

    Note:

    You can obtain the URL from the administrator of the publishing farm. For more information, see Publish a service application (SharePoint Foundation 2010). There are two kinds of URLs that you can use in this step: either the URL of the service application or the URL of the remote farm's topology service application. If you use the URL of the service application, only the corresponding service application will be listed in Step 6 of this procedure. If you use the URL of the topology service, all service applications in the farm will be listed in Step 6 of this procedure.

  6. The new Connect to a Remote Service Application dialog box displays the service applications that match the URL that you typed in Step 5. Click the row that contains the name of the service application, and then select the check box to add the service application connection to the farm's default list of service application connections (that is, the default proxy group). Click OK.

  7. You are prompted to change the connection name. Type a new name into the Connection Name text box or leave the default name, and then click OK.

  8. We recommend that you use the instructions in Exchange trust certificates between farms (SharePoint Foundation 2010) to establish trust between the two farms.

  9. After the new connection is created, you must click OK to complete the procedure.

  10. Associate the new service application connection with a local Web application. For information about how to do this, see Add or remove a service application connection to a Web application (SharePoint Foundation 2010).

To connect to a service application on a remote farm by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  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:

    Copy Code
    Receive-SPSharedServiceApplicationInfo -FarmUrl <PublishingFarmTopologyURL>

    Where the <PublishingFarmTopologyURL> is the information that is retrieved by running the Get-SPTopologyServiceApplication cmdlet on the publishing farm. For more information, see Publish a service application (SharePoint Foundation 2010).

  5. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    New-SP*ServiceApplicationProxy -Name " <ServiceApplicationProxyName>" -Url "<PublishingFarmTopologyURL>"

    Where:

    • <ServiceApplicationProxyName> is a unique name for a service application connection on the consuming farm.

    • <PublishingFarmTopologyURL> is the service application topology URL that was also used in the previous command.

    Each kind of service application has a specific Windows PowerShell 2.0 cmdlet that should be used instead of New-SP*ServiceApplicationProxy. (These cmdlets are listed in the See Also section.) For example, the following command creates a new Managed Metadata service application proxy named "MetadataServiceProxy1" that connects to the service application located at the stated URL.

    Copy Code
    New-SPMetadataServiceApplicationProxy -Name "MetadataServiceProxy1" -Uri "
urn:schemas-microsoft-com:sharepoint:service:9c1870b7ee97445888d9e846519cfa27#authority=urn:uuid:02a493b92a5547828e21386e28056cba&authority=https://ua_powershell:32844/Topology/topology.svc  "

  6. You must associate the new service application connection with a local Web application. For information about how to do this, see Add or remove a service application connection to a Web application (SharePoint Foundation 2010).

See Also

Reference

New-SPBusinessDataCatalogServiceApplicationProxy

Other Resources

New-SPEnterpriseSearchServiceApplicationProxy
New-SPMetadataServiceApplicationProxy
New-SPProfileServiceApplicationProxy
New-SPSecureStoreServiceApplicationProxy
New-SPWebAnalyticsServiceApplicationProxy


Add or remove a service application connection to a Web application (SharePoint Foundation 2010)

When you create a service application in Microsoft SharePoint Foundation 2010, a service application connection is created. A service application connection is also referred to as an application proxy. A service application connection associates the service application to Web applications via membership in a service application connection group (also referred to as application proxy group).

This article describes how to add or remove service application connections to a service application connection group.

Important:

If you are creating a service application connection to a service application in a remote farm, you should read the article Share service applications across farms (SharePoint Foundation 2010) to gain a full understanding of the requirements to successfully share service applications across farms.

By default, a new service application connection is added to the farm's Default group of service application connections when you create the service application by using Central Administration. You can override this default membership. If a new service application is created by using Windows PowerShell 2.0 instead of by using Central Administration, the new service application does not automatically become a member of the Default service application connections group unless the -default parameter is supplied.

Note:

For more information about how to create and configure service applications, see Manage service applications (SharePoint Foundation 2010).

By default, all Web applications are associated with the farm's Default group of service application connections, although you can change this setting. You can also create one custom connection group for each Web application in the farm. You can change the service applications with which a Web application is associated at any time, and you can change the service applications that are included in the Default service application connection group.

For more information about how to create and configure Web applications, see Web applications management (SharePoint Foundation 2010).

Editing a service connection group

You can add or remove service application connections to a service application connection group by using Central Administration or by using Windows PowerShell 2.0 cmdlets.

To edit a service connection group 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. On the Central Administration Home page, click Application Management.

  3. On the Application Management page, in the Service Applications section, click Configure service application associations.

  4. On the Service Application Associations page, select Web Applications from the View drop-down menu.

  5. In the list of Web applications, in the Application Proxy Group column, click the name of the service application connection group that you want to change.

  6. To add a service connection to the group, select the check box that is next to the service application that you want to add to the connection group. To remove a service application connection from the connection group, clear the check box next to the service application that you want to remove from the connection group. When you have made the changes that you want, click OK.

    Note:

    You can also change custom service application connection groups by clicking Manage Web Applications from the Central Administration Home page, selecting a listed Web application, and then clicking Service Connections on the ribbon. You cannot change the default service applications connection group through this page, however.

To add a service application connection to a service application connection group by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click Administrative Tools.

  3. Click SharePoint 2010 Management Shell.

  4. At the Windows PowerShell command prompt (that is, PS C:\>), type the following command, and then press ENTER:

    Add-SPServiceApplicationProxyGroupMember [-Identity <the service application proxy group>] [-Member <members to add to the service application proxy group>]

For more information, see Add-SPServiceApplicationProxyGroupMember.

To remove a service application connection from a service application connection group by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click Administrative Tools.

  3. Click SharePoint 2010 Management Shell.

  4. At the Windows PowerShell command prompt (that is, PS C:\>), type the following command, and then press ENTER:

    Remove-SPServiceApplicationProxyGroupMember [-Identity <SPServiceApplicationProxyGroupPipeBind>] [-Member <SPServiceApplicationProxyPipeBind[]>]

For more information, see Remove-SPServiceApplicationProxyGroupMember.


Restrict or enable access to a service application (SharePoint Foundation 2010)
See Also

In Microsoft SharePoint Foundation 2010, you can restrict the access to a service application so that the service application is available to only specified Web applications.

By default, all service applications on the local farm are available to all Web applications on the local farm. However, you can restrict access to a service application so that it is available to only specified Web applications. This can be a useful strategy if you host multiple customers on the same farm, and you want to isolate one customer's service applications from another customer's Web application.

If you restrict access to a service application and you later decide that you want to make it available to the whole farm, you can remove the restriction.

This article describes how to restrict access to a service application by adding and removing service accounts. It also describes how to reestablish local farm-wide access to a service application.

Important:

We strongly recommend that you plan the security and services infrastructure before you restrict access to service applications.

For information about how to plan the services architecture in SharePoint Foundation 2010, see the following articles:

  • Services architecture planning (SharePoint Foundation 2010)

  • Technical diagrams (SharePoint Foundation 2010)

In this article:

  • Restricting access to a service application

  • Restore farm-wide access to a service application

  • Windows PowerShell code examples

Restricting access to a service application

You can restrict access to a service application by removing service accounts from the service application. Conversely, you can allow access to a service application by adding service accounts to the service application. You can perform these tasks by using Central Administration or by using Windows PowerShell 2.0.

To restrict access to a service application, you must perform the following tasks:

  1. Add a specific service account to the service application.

  2. Remove the local farm ID from the service application.

Note:

The procedures in this article describe how to restrict or restore access to a service application. However, you can follow the steps provided in the procedures to add any service account to any service application, or to remove any service account from any service application.

For example, the procedure To restore local farm-wide access to a service application by using Central Administration explicitly describes how to add the local farm ID to a service application. However, you can use the same procedure to add any other service account to a service application. To do this, you provide the appropriate service account instead of the local farm ID.

Because the local farm ID provides local farm-wide access to the service application by default, it is redundant to also grant explicit local Web application permissions to a service application unless you also remove the local farm ID.

To grant permissions to a service application, you must retrieve and supply the appropriate service account. For a Web application, this account is also known as an application pool identity account.

After you grant permissions to a service account and remove the local farm ID from a service application, only Web applications that are managed by the assigned service account can access the service application. You can assign multiple Web applications (that have different managing service accounts) to the same service application by repeating these procedures and adding the various Web application service accounts to the service application.

Warning:

If you remove the local farm ID from a service application and do not assign any other service account to that service application, the service application becomes unavailable to all Web applications.

In this section:

  • Restrict access to a service application by using Central Administration

  • Restricting access to a service application by using Windows PowerShell

Restrict access to a service application by using Central Administration

To restrict access to a service application by using Central Administration, you must perform the following steps:

  1. Retrieve the Web application service account.

  2. Add the Web application service account to the service application.

  3. Remove the local farm ID from the service application.

Procedures in this section:

  • To retrieve a Web application service account by using Central Administration

  • To grant and remove permissions for service accounts to access a service application by using Central Administration

To retrieve a Web application service account 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. On the Central Administration Home page, in the Security section, click Configure service accounts.

  3. On the Service Accounts page, select the Web application name from the first drop-down list.

    The service account is shown in the Select an account for this component list. Record the service account name because you will use it in the next procedure.

  4. Click Cancel to exit the Service Accounts page without making any changes.

To grant and remove permissions for service accounts to access a service application 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. On the Central Administration Home page, in the Application Management section, click Manage service applications.

  3. On the Manage Service Applications page, click the row that contains the service application for which you want to assign permissions. The ribbon becomes available.

  4. On the ribbon, click Permissions.

  5. In the Connection Permissions dialog box, type the service account name that you retrieved in the previous procedure, and then click Add.

  6. Make sure that the newly-added service account name is selected in the middle pane, and then click the appropriate check box in the bottom pane to supply the required permission level.

  7. In the middle pane, click Local Farm, and then click Remove.

  8. Verify that the Connection Permissions page now lists only the service account that you want to access the service application, and that the service account has the required permissions on the service application. Click OK to change the permissions, or click Cancel to end the operation without making changes.

You can grant and remove permissions for any service account by using this procedure.

Note:

Restoring the local farm ID to the service application by using Central Administration requires an additional step that does not apply to other service accounts. For information about how to do this, see Restore farm-wide access to a service application later in this article.

Restricting access to a service application by using Windows PowerShell

All procedures in this section assume that you have the appropriate permissions and have opened the Windows PowerShell 2.0 command prompt window, as described in the procedure To initiate a Windows PowerShell session later in this section.

The process to restrict access to a service application by using Windows PowerShell 2.0 is more complex than performing the same task by using Central Administration. In Windows PowerShell 2.0, you will use some procedures to gather and store information for input into later procedures.

After you have started Windows PowerShell 2.0, the remaining steps to restrict access to a service application are as follows:

  1. Retrieve the local farm ID.

  2. Retrieve the Web application service account.

  3. Create a new claims principal that contains the Web application service account.

  4. Retrieve the security object of the service application.

  5. Add the Web application service account to the security object of the service application.

  6. Remove the local farm ID from the security object of the service application.

  7. Assign the updated security object to the service application.

  8. Display and review updated permissions

In this section:

  • To initiate a Windows PowerShell session

  • To retrieve the local farm ID by using Windows PowerShell

  • To retrieve a Web application service account and create a new claims principal by using Windows PowerShell

  • To retrieve the security object of the service application

  • To update the service application security object with the preferred permissions

To initiate a Windows PowerShell session

  1. Verify that you meet the following minimum requirements: You are a member of the SharePoint_Shell_Access role on the configuration database and a member of the WSS_ADMIN_WPG local group on the computer where SharePoint Foundation 2010 is installed.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

To retrieve a Web application service account and create a new claims principal by using Windows PowerShell

  1. At the Windows PowerShell 2.0 command prompt, type the following command to retrieve the service account (that is, the application pool identity account) of a Web application:

    Copy Code
    $webapp = Get-SPWebApplication <http://WebApplication>
$webApp.ApplicationPool.UserName

    Where <http://WebApplication> is the Web application URL.

    The Web application service account name displays at the command prompt.

  2. To create a new claims principal, type the following command:

    Copy Code
    $principal = New-SPClaimsPrincipal <ServiceAccount> -IdentityType WindowsSamAccountName

    Where <ServiceAccount> is the user name (in the form of jane@contoso.com or contoso\jane) that was retrieved by running the previous command. The $principal variable will contain the new claims principal.

To retrieve the security object of the service application

  1. To retrieve the security object of the service application, type the following commands. The $security variable will store the service application security object.

    Copy Code
    $spapp = Get-SPServiceApplication -Name "<ServiceApplicationDisplayName>"
$spguid = $spapp.id
$security = Get-SPServiceApplicationSecurity $spguid

    Where <ServiceApplicationDisplayName>is the display name of the service application.

    Important:

    You must enclose the display name in quotation marks, and it must exactly match the service application display name. This includes capitalization. If you have more than one service application that has exactly the same display name (we do not recommend this), you can run the Get-SPServiceApplication cmdlet without arguments to view all service applications. You can then identify the service application directly by its GUID. For example:

    Get-SpServiceApplication

    All service applications are listed.

    $spapp = Get-SpserviceApplication -Identity <GUID>

    $spguid = $spapp.id

    Where <GUID> is the GUID for the service application for which you want to update permissions.

To update the service application security object with the preferred permissions

  1. The first step to update the service application security object is to add the new claims principal $principal to the service application security object $security. To do this, type the following command:

    Copy Code
    Grant-SPObjectSecurity $security $principal -Rights "<Rights>"

    Where <Rights> is the permissions that you want to grant. Typically, this will be Full Control. The available permissions can vary between service applications.

    Tip:

    If you do not want to grant Full Control permissions, and you do not know what permissions can be granted to the service application, you can run the following commands to return the available permissions strings:

    $rightslist = Get-SPServiceApplicationSecurity $spapp

    $rightslist.NamedAccessRights

  2. To remove the local farm ID (that is stored in the $farmID variable) from the service application security object $security, type the following command:

    Copy Code
    Revoke-SPObjectSecurity $security $farmID

  3. To assign the updated $security security object to the service application and confirm that the security object for the service application is appropriately updated, type the following commands:

    Copy Code
    Set-SPServiceApplicationSecurity $spapp -ObjectSecurity $security
(Get-SPServiceApplicationSecurity $spapp).AccessRules

You can add or remove any service account to a service application by using these procedures.

Restore farm-wide access to a service application

You can restore farm-wide access to a service application by adding the local farm ID to the service application. You can do this by using Central Administration or by using Windows PowerShell 2.0 commands. However, you must use Windows PowerShell 2.0 to obtain the local farm ID.

In this section:

  • To retrieve the local farm ID by using Windows PowerShell

  • To restore local farm-wide access to a service application by using Central Administration

  • To restore local farm-wide access to a service application by using Windows PowerShell

To retrieve the local farm ID by using Windows PowerShell

  1. This procedure starts after step 4 of the To initiate a Windows PowerShell session procedure.

  2. The following command retrieves the local farm ID, stores it in the $farmID variable, and displays the ID at the command prompt:

    Copy Code
    $farmID = Get-SPFarm | select id

    If you want to restore farm-wide access by using Central Administration, copy this value into the clipboard for use in the following procedure.

    If you want to restore farm-wide access to the service application by using Windows PowerShell 2.0, type the following additional commands at the Windows PowerShell 2.0 command prompt. You will use the retrieved information in the following procedure.

    Copy Code
    $claimProvider = (Get-SPClaimProvider System).ClaimProvider
$principal = New-SPClaimsPrincipal -ClaimType "http://schemas.microsoft.com/sharepoint/2009/08/claims/farmid" -ClaimProvider $claimProvider -ClaimValue $farmid

To restore local farm-wide access to a service application by using Central Administration

  1. Perform steps 1 through 3 of the procedure To grant and remove permissions for service accounts to access a service application by using Central Administration.

  2. In the Connection Permissions dialog box, copy the local farm ID that you retrieved in the previous procedure, and then click Add.

  3. Make sure that the local farm ID is selected in the middle pane. Click the Full Control check box in the bottom pane.

  4. Click OK to restore farm-wide access to the service application, or click Cancel to end the operation without making changes.

To restore local farm-wide access to a service application by using Windows PowerShell

  1. This procedure starts after Step 2 of the procedure To retrieve the local farm ID by using Windows PowerShell .

  2. To restore the retrieved local farm ID to the service application security object $security, type the following commands:

    Copy Code
    $spapp = Get-SPServiceApplication -Name "<ServiceApplicationDisplayName>"
$spguid = $spapp.id
$security = Get-SPServiceApplicationSecurity $spguid
Grant-SPObjectSecurity -Identity $security -Principal $farmID -Rights "Full Control"
Set-SPServiceApplicationSecurity $spguid -ObjectSecurity $security

    Where <ServiceApplicationDisplayName> is the display name of the service application.

    Important:

    You must enclose the display name in quotation marks, and it must exactly match the service application display name. This includes capitalization. If you have more than one service application that has exactly the same display name (we do not recommend this), you can run the Get-SPServiceApplication cmdlet without arguments to view all service applications. You can then identify the service application directly by its GUID.

Windows PowerShell code examples

In the following example, the administrator wants to restrict access to the "Contoso BDC" service application to the http://contoso/hawaii Web application, which is managed by the service account "contoso\jane". By adding "contoso\jane" and removing the local farm service account from the service application, "Contoso BDC" is restricted to only those Web applications that are managed by the service account "contoso\jane" - in this case, http://contoso/hawaii.

Copy Code
$farmid = Get-SPFarm | select id
$claimProvider = (Get-SPClaimProvider System).ClaimProvider
$principal = New-SPClaimsPrincipal -ClaimType "http://schemas.microsoft.com/sharepoint/2009/08/claims/farmid" -ClaimProvider $claimProvider -ClaimValue $farmid
webapp = get-spwebapplication http://contoso
$webapp.applicationpool
$principal = New-SPClaimsPrincipal contoso/jane -IdentityType WindowsSamAccountName
$spapp = Get-SPServiceApplication -Name "Contoso BDC"
$spguid = $spapp.id
$security = Get-SPServiceApplicationSecurity $spguid
Grant-SPObjectSecurity $security $principal -Rights "Full Control"
Revoke-SPObjectSecurity $security $farmaccount
Set-SPServiceApplicationSecurity $spguid -ObjectSecurity $security
(Get-SPServiceApplicationSecurity $spguid).AccessRules

In the following example, access to the service application "Contoso BDC" is restored to all Web applications in the local farm.

Copy Code
$farmid = Get-SPFarm | select id
$claimProvider = (Get-SPClaimProvider System).ClaimProvider
$principal = New-SPClaimsPrincipal -ClaimType "http://schemas.microsoft.com/sharepoint/2009/08/claims/farmid" -ClaimProvider $claimProvider -ClaimValue $farmid
$spapp = Get-SPServiceApplication -Name "Contoso BDC"
$spguid = $spapp.id
$security = Get-SPServiceApplicationSecurity $spguid
Grant-SPObjectSecurity -Identity $security -Principal $farmaccount -Rights "Full Control"
Set-SPServiceApplicationSecurity $spguid -ObjectSecurity $security
(Get-SPServiceApplicationSecurity $spguid).AccessRules

See Also

Reference

Get-SPWebApplication
New-SPClaimsPrincipal
Get-SPServiceApplication
Get-SPServiceApplicationSecurity
Grant-SPObjectSecurity
Revoke-SPObjectSecurity
Set-SPServiceApplicationSecurity
Get-SPFarm
Get-SPClaimProvider

Concepts

Configure claims authentication (SharePoint Foundation 2010)
Add or remove a service application connection to a Web application (SharePoint Foundation 2010)

Other Resources

Resource Center: Security and Authentication for SharePoint Foundation 2010


Assign or remove administrators to a service application (SharePoint Foundation 2010)

An administrator of a Microsoft SharePoint Foundation 2010 service application can assign additional administrators to that service application. These users are granted security-trimmed access to the SharePoint Central Administration Web site and can manage settings related to the service application. You can similarly remove administrators from a service application.

Note:

By default, members of the Farm Administrators group have permissions to manage all service applications.

You can assign or remove service application administrators by using Central Administration or by using Windows PowerShell 2.0.

To assign or remove administrators to a service application by using Central Administration

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration Home page, in the Application Management section, click Manage service applications.

  3. On the Manage Service Applications page, select the row that contains the service application to which you want to add or remove administrators. The ribbon becomes available.

  4. On the ribbon, click Administrators.

  5. To add an administrator:

    1. In the first text box on the page, type the user accounts or groups that you want to add. You can click the People icon to validate a name. You can click the Address book icon to search for users to add. You can add multiple administrators into the text box.

    2. After you have added the administrators, click OK.

  6. To remove an administrator:

    1. In the second text box on the page, select the administrator whom you want to remove. Note that this step does not remove the user from the system—it merely revokes the user's administrative permissions to the selected service application.

    2. Click Remove.

    3. After you have finished removing administrators, click OK.

To assign or remove administrators to a service application 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. At the Windows PowerShell command prompt type the following commands.

  6. To create a new claims principal, type the following command:

    Copy Code
    $principal = New-SPClaimsPrincipal "<contoso\jane>" -IdentityType WindowsSamAccountName

    Where <contoso\jane> is the user name for which you want to assign administrative permissions. The user name should be entered in the form of jane@contoso.com or contoso\jane. The new claims principal is stored in the $principal variable.

  7. To retrieve the service application, type the following command:

    Copy Code
    $spapp = Get-SPServiceApplication -Name "<ServiceApplicationDisplayName>"

    Where <ServiceApplicationDisplayName> is the display name of the service application. The service application identification is stored in the $spapp variable.

    Important:

    The display name must be enclosed in quotation marks, and it must exactly match the service application display name. This includes capitalization. If you have more than one service application that has exactly the same display name (we do not recommend this), you can use the Get-SPServiceApplication cmdlet to view all service applications. You can then identify the service application by its GUID. For more information, see Get-SPServiceApplication.

  8. To retrieve the administrator security object for the service application, type the following command:

    Copy Code
    $security = Get-SPServiceApplicationSecurity $spapp -Admin

    The retrieved administrator security object is stored in the $security variable.

    Warning:

    It is important that you use the -Admin argument when you use this command.

  9. To assign or revoke administrative permissions for the user who is identified by the new claims principal $principal (that was created in Step 6 of this procedure) to the service application administrator security object $security (that was obtained in Step 8 of this procedure) use the appropriate command as follows.

    1. To assign administrative permissions, type the following command:

      Copy Code
      Grant-SPObjectSecurity $security $principal "Full Control"

    2. To revoke administrative permissions, type the following command:

      Copy Code
      Revoke-SPObjectSecurity $security $principal

  10. To assign the updated $security security object to the service application, type the following command:

    Copy Code
    Set-SPServiceApplicationSecurity $spapp $security -Admin
    Warning:

    It is important that you use the -Admin argument when you use this command.

  11. To confirm that the service application's security object is updated appropriately, type the following command:

    Copy Code
    (Get-SPServiceApplicationSecurity $spapp -Admin).AccessRules

Examples

In the following example, the service account user "contoso\jane" is added to the administrators security object for the service application named "Contoso Visio Graphics".

Copy Code
$principal = New-SPClaimsPrincipal "contoso\jane" -IdentityType WindowsSamAccountName
$spapp = Get-SPServiceApplication -Name "Contoso Visio Graphics"
$security = Get-SPServiceApplicationSecurity $spapp -Admin
Grant-SPObjectSecurity $security $principal "Full Control"
Set-SPServiceApplicationSecurity $spapp $security -Admin
(Get-SPServiceApplicationSecurity $spapp -Admin).AccessRules

In the following example, the service account user "contoso\jane" is removed from the administrators security object for the service application named "Contoso Visio Graphics".

Copy Code
$principal = New-SPClaimsPrincipal "contoso\jane" -IdentityType WindowsSamAccountName
$spapp = Get-SPServiceApplication -Name "Contoso Visio Graphics"
$security = Get-SPServiceApplicationSecurity $spapp -Admin
Revoke-SPObjectSecurity $security $principal "Full Control"
Set-SPServiceApplicationSecurity $spapp $security -Admin
(Get-SPServiceApplicationSecurity $spapp -Admin).AccessRules

For more information, see the following Windows PowerShell articles:

  • New-SPClaimsPrincipal

  • Get-SPServiceApplication

  • Get-SPServiceApplicationSecurity

  • Grant-SPObjectSecurity

  • Revoke-SPObjectSecurity

  • Set-SPServiceApplicationSecurity

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.


Delete a service application (SharePoint Foundation 2010)
See Also

You can delete a service application by using SharePoint Central Administration or by using Windows PowerShell 2.0 cmdlets. Be aware that the act of deleting a service application is permanent—you cannot undo this operation.

Before you delete a service application, verify that its removal will not adversely affect users. As a best practice, you should ensure that no Web applications are currently consuming the service application that you are going to delete. For information about how to disconnect a service application from a Web application, see Add or remove a service application connection to a Web application (SharePoint Foundation 2010).

When you delete a service application, you have the option to also delete the service application database (not all service applications have databases). If the service application is to be re-created in the future, do not delete the service application database. On the other hand, if the service application is temporary, you will most likely want to delete the database during this operation.

To ensure that the service application is available for potential future use, consider backing up the service application before you delete it. For more information, see Back up a service application (SharePoint Foundation 2010) and Restore a service application (SharePoint Foundation 2010).

In this article:

  • To delete a service application by using Central Administration

  • To delete a service application by using Windows PowerShell

To delete a service application 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. On the SharePoint Central Administration Web site, click Application Management, and then click Manage service applications.

  3. On the Manage Service Applications page, click the row that contains the service application that you want to delete. The ribbon becomes available.

  4. On the ribbon, click Delete.

  5. In the confirmation dialog box, select the check box next to Delete data associated with the Service Applications if you want to delete the service application database. If you want to retain the database, leave this check box cleared.

  6. Click OK to delete the service application, or click Cancel to stop the operation.

To delete a service application 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. At the Windows PowerShell command prompt, type the following commands.

  6. To retrieve the service application that you want to delete, type the following command:

    Copy Code
    $spapp = Get-SPServiceApplication -Name "<Service application display name>"

    Where <Service application display name> is the display name of the service application that you want to delete.

    The service application information will be stored in the $spapp variable.

    Important:

    You must type the display name within quotation marks, and what you type must exactly match the service application display name. This includes capitalization. It is strongly recommended that you do not create multiple service applications that have the same display name—if you do have this situation, you can use the Get-SPServiceApplication cmdlet to list all service applications. You can then use the service application GUID together with the -Identity parameter to specify the service application that you want to delete. For more information, see Get-SPServiceApplication.

  7. To delete the selected service application, run one of the following commands. In both cases, you are prompted to confirm the deletion.

    • To delete the selected service application without removing the service application database, type the following command:

      Copy Code
      Remove-SPServiceApplication $spapp

    • To delete the selected service application and also delete the service application database, type the following command:

      Copy Code
      Remove-SPServiceApplication $spapp -RemoveData

Example

Copy Code
$spapp = Get-SPServiceApplication -Name "Contoso BDC Service"
Remove-SPServiceApplication $spapp -RemoveData
ConfirmAre you sure you want to perform this action? YPerforming operation "Remove-SPServiceApplication" on Target

In this example, the service application "Contoso BDC Service" information is stored in the $spapp variable. After the action is confirmed, the service application and its database are permanently deleted.

For more information, see Get-SPServiceApplication and Remove-SPServiceApplication.

See Also

Reference

Remove-SPServiceApplicationProxyGroup


Business Data Connectivity service administration (SharePoint Foundation 2010)

Microsoft Business Connectivity Services are administered primarily by using the Business Data Connectivity service. This topic provides descriptions of general administrative Business Data Connectivity service operations. See the following topics for Business Data Connectivity service operations related to the items that are stored and managed by using the service:

  • Manage external systems (SharePoint Foundation 2010)

  • Manage external content types (SharePoint Foundation 2010)

  • Manage BDC models (SharePoint Foundation 2010)

  • Business Connectivity Services security operations (SharePoint Foundation 2010)


Manage external systems (SharePoint Foundation 2010)
See Also

An external system is a source of data, such as a Web service, SQL Server database, other relational database, or a custom connector, that can be used in a solution. An instance of an external system includes connection and authentication information for a specific instance of an external system. There can be one or more instances of an external system for any external system. Configuring multiple external system instances allows the solution designer to set different security parameters on external data connections to support multiple ways to connect to the same external system. However, in many applications, a single external system instance is all that is needed.

In this article:

  • Set permissions on an external system

  • View all external systems for a Business Data Connectivity service application instance

  • Delete an external system

  • View the external content types of an external system

  • Configure an external system

  • Configure an instance of an external system

Set permissions on an external system

You set permissions on an external system to specify who can edit it, who can execute operations (such as read or update) on external content types stored at the external system, who can create external lists using the data that is stored in the external system, and who can set permission on it.

We recommend that you give specific permissions to each user or group that needs them, in such a way that the credentials provide the least privilege necessary to perform the needed tasks. For more information about setting permissions, see Business Connectivity Service permissions overview in "Business Connectivity Services security overview (SharePoint Foundation 2010)".

To set permissions on an external system

  1. Verify that you have one of the following administrative credentials:

    • You must be a farm administrator.

    • You must be an administrator of the Business Data Connectivity service application and have Set Permissions permission on the external system.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the View group of the ribbon, click External Systems.

  5. Click the check box of the external system for which you want to set permissions.

  6. In the Permissions group of the ribbon, click Set Object Permissions.

  7. In the box, type the user accounts, groups, or claims for which permissions will be granted, and then click Add.

    Note:

    The user account, group, or claim cannot have a vertical bar (|) in its name.

  8. Set the permissions for the account, group, or claim:

    Note:

    At least one user, group or claim in the metadata object's access control list must have the Set Permissions permission.

    • Click Edit to allow the user, group, or claim to edit the external system.

      Security Note:

      The Edit permission should be considered highly privileged. With the Edit permission a malicious user can steal credentials or corrupt a server farm. To help ensure a secure solution, we recommend using a test environment where the Edit permission can be assigned freely to developers and solution designers. When you deploy the tested solution to a production environment, remove the Edit permissions.

    • Click Execute to allow the user, group, or claim to execute operations (create, read, update, delete, or query) on external content types that are stored at the external system.

      Tip:

      The Execute permission is not applicable to the external system itself. This setting is used when you want to propagate the Execute permission to child objects (such as external content types) in the external system.

    • Click Selectable In Clients to allow the user, group, or claim to create external lists of any external content types whose data is stored at the external system and to view the external content types in the external item picker.

      Tip:

      The Selectable In Clients permission is not applicable to the external system itself. This setting is used when you want to propagate the Selectable In Clients permission to child objects (such as external content types) in the external system.

    • Click Set Permissions to allow the user, group, or claim to set permissions on the external system.

      Security Note:

      The Set Permissions permission should be considered highly privileged. With the Set Permissions permission, a user can grant Edit permission to the external system.

  9. To propagate permissions to all items nested in the external system, click Propagate permissions to all External Content Types that belong to this External System. Doing so will overwrite existing permissions.

View all external systems for a Business Data Connectivity service application instance

View the external systems in the Business Data Connectivity service application to choose an external system before configuring it or to perform some other operation.

To view all external systems for a Business Data Connectivity service application instance

  1. Verify that you have the following administrative credentials:

    • You must be a farm administrator or an administrator of the service application.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the View group of the ribbon, click External Systems.

Delete an external system

Delete an external system to remove it from the metadata store.

Note:

You cannot delete an external system that contains external content types in the metadata store. To delete the external system, you must first delete all external content types that it contains.

To delete an external system

  1. Verify that you have one of the following administrative credentials:

    • You must be a farm administrator.

    • You must be an administrator of the Business Data Connectivity service application and have Edit permission on the external system.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the View group of the ribbon, click External Systems.

  5. Point to the external system, click the arrow that appears, and then click Delete.

View the external content types of an external system

External systems make external data available using external content types. You can view all the external content types associated with an external system.

To view the external content types of an external system

  1. Verify that you have the following administrative credentials:

    • You must be a farm administrator or an administrator of the service application.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the View group of the ribbon, click External Systems.

  5. Point to the external system, click the arrow that appears, and then click View External Content Types.

Configure an external system

You can configure some settings of an external system by using the Business Data Connectivity service.

To configure an external system

  1. Verify that you have one of the following administrative credentials:

    • You must be a farm administrator.

    • You must be an administrator of the Business Data Connectivity service application and have Edit permission on the external system.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the View group of the ribbon, click External Systems.

    Tip:

    The only external systems that are configurable in the Business Data Connectivity service are Windows Communication Foundation (WCF) Web services.

  5. Point to the external system, click the arrow that appears, and then click Settings.

  6. Edit or view the settings.

    If the external system is a WCF Web service, the following settings are available:

    Field Notes

    Metadata Exchange URL

    The full Web address of the Web service description language (.wsdl) file of the Web service.

    Metadata Exchange Discovery Mode

    The protocol to use for discovering web service metadata:

    • Disco: the Business Data Connectivity service uses the DiscoveryClientProtocol (equivalent to wsdl.exe ) to download the metadata.

    • MetadataExchange: the Business Data Connectivity service uses WS-Transfer (equivalent to svcutil /mex) to download the metadata.

    • CustomProxy: the Business Data Connectivity service does not attempt to discover the service. When this option is used, the user must provide Address, Binding and Contract for the service.

    WSDL Authentication Mode

    The default way that incoming credentials are passed to the Web service.

    Five choices are available:

    Mode Description

    User's Identity

    Uses the credentials of the logged on user to authenticate to the Web service.

    This mode is called PassThrough in the BDC model file.

    BDC Identity

    Uses the application pool account under which the Business Data Connectivity service is running to authenticate the logged on user to the Web service.

    This mode is called RevertToSelf in the BDC model file.

    Impersonate Custom Identity

    For Web services that use basic authentication instead of Windows authentication.

    Uses the Secure Store Service to map the user's credentials to the individual or group credentials that are used by the Web service.

    This mode is called Credentials in the BDC model file.

    Impersonate Windows Identity

    For Web services that use Windows authentication.

    Uses the Secure Store Service to map the user's credentials to the individual or group credentials that are used by the Web service.

    This mode is called WindowsCredentials in the BDC model file.

    Impersonate Custom Identity - Digest

    For Web services that use digest authentication instead of Windows authentication. Uses the Secure Store Service to map the user's credentials to the individual or group credentials that are used by the Web service.

    This mode is called DigestCredentials in the BDC model file.

    Secure Store WSDL Target Application ID

    For Impersonate Custom Identity, Impersonate Windows Identity, and Impersonate Custom Identity-Digest authentication, the target application identifier for this Web service, as configured in the Secure Store Service.

    Secure Store Implementation

    If you are providing a custom secure store provider, specify the fully qualified assembly name of the provider. Otherwise, leave this field empty.

  7. Click OK.

Configure an instance of an external system

There can be one or more instances of an external system for any external system. Configuring multiple external system instances allows the solution designer to set different security parameters on external data connections to support multiple ways to connect to the same external system.

To configure an instance of an external system

  1. Verify that you have one of the following administrative credentials:

    • You must be a farm administrator.

    • You must be an administrator of the Business Data Connectivity service application and have Edit permission on the external system.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the View group of the ribbon, click External Systems.

  5. Click the external system to view its instances.

    Tip:

    The only instances of external system types that are configurable by default are databases and WCF Web services.

  6. Point to the external system instance, click the arrow that appears, and then click Settings.

  7. Edit or view the settings.

    If the external system is a WCF Web service, the following settings are available:

    Field Description

    Authentication Mode

    The way that incoming credentials are passed to the Web service.

    Five choices are available:

    Mode Description

    User's Identity

    Uses the credentials of the logged on user to authenticate to the Web service.

    This mode is called PassThrough in the BDC model file.

    BDC Identity

    Uses the application pool account under which the Business Data Connectivity service is running to authenticate the logged on user to the Web service.

    This mode is called RevertToSelf in the BDC model file.

    Impersonate Custom Identity

    For Web services that use basic authentication instead of Windows authentication.

    Uses the Secure Store Service to map the user's credentials to the individual or group credentials that are used by the Web service.

    This mode is called Credentials in the BDC model file.

    Impersonate Windows Identity

    For Web services that use Windows authentication.

    Uses the Secure Store Service to map the user's credentials to the individual or group credentials that are used by the Web service.

    This mode is called WindowsCredentials in the BDC model file.

    Impersonate Custom Identity - Digest

    For Web services that use digest authentication instead of Windows authentication. Uses the Secure Store Service to map the user's credentials to the individual or group credentials that are used by the Web service.

    This mode is called DigestCredentials in the BDC model file.

    Service Endpoint Address

    The full Web address of the Web service's .wsdl file.

    Impersonation Level

    The degree to which the Business Data Connectivity service will can act on behalf of the user when connecting to an external web service. Values include:

    • None: An impersonation level is not assigned.

    • Anonymous: The server process cannot obtain identification information about the client, and it cannot impersonate the client.

    • Identification: The server process can obtain information about the client, such as security identifiers and privileges, but it cannot impersonate the client. This is useful for servers that export their own objects, for example, database products that export tables and views. Using the retrieved client-security information, the server can make access-validation decisions without being able to use other services that are using the client's security context.

    • Impersonation: The server process can impersonate the client's security context on its local system. The server cannot impersonate the client on remote systems.

    • Delegation: The server process can impersonate the client's security context on its local system. The server cannot impersonate the client on remote systems.

    Secure Store Target Application ID

    For Impersonate Custom Identity and Impersonate Windows Identity authentication, the target application identifier for this Web service, as configured in the Secure Store Service.

    Secondary Secure Store Target Application ID

    This field is used to provide the target application identifier of the optional filter that will be used to capture user-supplied input values for Secure Store related filters. For information on the types of filters supported, and on implementing filters, see the Microsoft SharePoint 2010 Software Development Kit (http://go.microsoft.com/fwlink/p/?LinkId=166117).

    Secure Store Implementation

    If you are providing a custom secure store provider, specify the fully qualified assembly name of the provider. Otherwise, leave this field empty.

    If the external system is a database, the following settings are available:

    Field Description

    Access Provider

    The type of database.

    Authentication Mode

    The way that incoming credentials are passed to the database.

    Four choices are available:

    Mode Description

    User's Identity

    Uses the credentials of the logged on user to authenticate to the database.

    This mode is called PassThrough in the BDC model file.

    BDC Identity

    Uses the application pool account under which the Business Data Connectivity service is running to authenticate the logged on user to the database.

    This mode is called RevertToSelf in the BDC model file.

    Impersonate Custom Identity

    For databases that do not use Windows authentication.

    Uses the Secure Store Service to map the user's credentials to the individual or group credentials that are used by the database.

    This mode is called RdbCredentials in the BDC model file.

    Impersonate Windows Identity

    For databases that use Windows authentication.

    Uses the Secure Store Service to map the user's credentials to the individual or group credentials that are used by the database.

    This mode is called WindowsCredentials in the BDC model file.

    Database Server

    The name of the database server.

    Initial Database Name

    The name of the database.

    Integrated Security

    If you are using integrated security, type the string, SSPI, and the Business Data Connectivity service will use the user's Windows credentials to connect to the external system. If you are not using integrated security, leave this field blank, and the Business Data Connectivity service will connect by using unique credentials for the database server.

    Connection Pooling

    If this is selected, the Business Data Connectivity service maintains ownership of the connections to the external system in a pool as an optimization.

    Secure Store Target Application Target ID

    For Impersonate Custom Identity and Impersonate Windows Identity authentication, the target application identifier for this database, as configured in the Secure Store Service.

    Secondary Secure Store Target Application Target ID

    This field is used to provide the target application identifier of the optional filter that will be used to capture user-supplied input values for Secure Store related filters. For information on the types of filters supported, and on implementing filters, see the Microsoft SharePoint 2010 Software Development Kit (http://go.microsoft.com/fwlink/p/?LinkId=166117).

    Secure Store Implementation

    If you are providing a custom secure store provider, specify the fully qualified assembly name of the provider. Otherwise, leave this field empty.

  8. Click OK.

See Also

Other Resources

Resource Center: Operations and Manageability for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=220234)


Manage BDC models (SharePoint Foundation 2010)
See Also

A BDC model is an XML file that contains sets of descriptions of one or more external content types, their related external systems, and information that is specific to the environment, such as authentication properties. The metadata in a model defines the fields of data in each external content type, the operations that are supported on the external system (to support tasks such as reading, writing, and querying the external system), and connectivity information.

The Business Data Connectivity service provides a set of operations that support importing and exporting models, setting permissions on them, and viewing the external content types that they contain. For example, you can export a BDC model to deploy it from a development environment to a production environment.

A resource file contains the localized names, properties, and permissions for one or more external content types. You can use the same techniques that you use for BDC models to import and export resource files. For example, you can import a resource file to provide a new set of localized strings for an additional language in which a solution will be used.

In this article:

  • Import a BDC model

  • Export a BDC model or resource file

  • Set permissions on a BDC model

  • View all models

  • Delete a BDC model

  • View a model's external content types

Import a BDC model

Importing a model is a primary way to add it, and its related external content types and external systems, into a metadata store. All external content types in a model are automatically activated when you import the model.

Each external content type has a name, namespace and version number, which are used to identify the external content type. Multiple versions of an external content type can exist in the metadata store at any given time. As you import models, add or delete models, activate or deactivate external content types, and add or delete external content types, you can end up with many versions of an external content type. If multiple versions of an external content type exist in the metadata store, the Business Data Connectivity runtime uses the version of the external content type that is active, regardless of the version number of the external content type. The active external content type can be the last imported version of the external content type or the version of the external content type that was activated by using the Enable-SPBusinessDataCatalogEntity cmdlet.

Caution:

If the model does not specify an authentication mode, then PassThrough authentication mode is used. PassThrough authentication may not be suitable for all scenarios. It is meant to be used primarily in a testing environment with a "single-box" configuration (that is, the database server and SharePoint Foundation are running on the same computer). For more information about authentication modes, see Business Connectivity Services authentication overview.

Tip:

You can also import a model or resource file by using Windows PowerShell. See Import-SPBusinessDataCatalogModel for details.

To import a BDC model or resource file

  1. Verify that you have one of the following administrative credentials:

    • You must be a farm administrator.

    • You must be an administrator of the Business Data Connectivity service application and have Edit permission on the metadata store.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the BDC models group of the ribbon, click Import.

  5. On the Import BDC model page, in the BDC Model File field, click Browse to find the BDC model or resource file.

    Important:

    A BDC model cannot have any of the following characters in its name: ~"#%&*:<>?\{|} or the character 0x7f.

  6. In the File Type section, select the type of BDC model file to import: Model or Resource.

  7. In the Advanced Settings section, select one or more types of resource to import:

    • Click Localized names to import localized names for the external content types in a particular locale.

      Imported localized names are merged with the existing localized names in the Business Data Connectivity service database.

    • Click Properties to import properties for external content types.

      Imported properties are merged with the existing property descriptions in the Business Data Connectivity service database.

    • Click Permissions to import permissions for external content types and other securable objects in the model.

      Caution:

      Permissions are stored together with the existing permissions information in the Business Data Connectivity service. If an entry for an object already exists in the access control list, its value is overwritten with the permissions information from the imported file. For example, suppose that the permissions for an external content type X provide access to that external content type to User A. If you import permissions that specify that only User B has access to external content type X, the previous permissions for external content type X will be deleted and new permissions will be stored that only contain the permissions for User B.

  8. To save the group of imported resource settings in a file that can later be exported for use in a particular environment, in the Use Custom Environment Settings field, type a unique name for the set of environment-specific settings.

Export a BDC model or resource file

After a BDC model or resource file has been exported, you can use the exported file to deploy the BDC model on a different system. You can use any of the following methods to export a BDC model or resource file:

  • Use Central Administration to export a BDC model or resource file.

  • Use the Export-SPBusinessDataCatalogModel cmdlet to export a BDC model or resource file.

  • Use Microsoft SharePoint Designer 2010 to export a BDC model.

    Note:

    If a BDC model was created by using SharePoint Designer 2010, you must use SharePoint Designer to export the BDC model. If a model that was created by using SharePoint Designer is exported by using Central Administration or the Export-SPBusinessDataCatalogModel cmdlet, the exported model file includes only placeholders for the external content types. For more information about SharePoint Designer, see SharePoint Designer Help and How-to (http://go.microsoft.com/fwlink/p/?LinkID=198249).

To export a BDC model or resource file

  1. Verify that you have one of the following administrative credentials:

    • You must be a farm administrator.

    • You must be an administrator of the Business Data Connectivity service application and have Edit permission on the model and on all external systems that are contained in the model.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the View group of the ribbon, click BDC Models.

  5. On the BDC Models page, select the model or resource file to export.

  6. In the BDC Models group, click Export.

  7. On the Export page, in the File Type field, select the type of file that you are exporting (Model or Resource) and, in the Advanced Settings area, select one or more types of resource to export:

    • Click Localized names to export localized names for the external content types in a particular locale.

    • Click Properties to export properties for external content types.

    • Click Permissions to export permissions for external content types.

    • Click Proxies to export an implementation-specific proxy that is used to connect to the external system.

  8. If you saved a set of resources that can later be exported for use in a particular environment, in the Use Custom Environment Settings field, type the unique name associated with the environment-specific settings to export.

  9. Click Export.

    Your computer's interface for saving the BDC model or resource file to a location on your network will be displayed.

Set permissions on a BDC model

You set permissions on a BDC model to specify who can edit it and who can set permissions on it.

We recommend that you give specific permissions to each user or group that needs them, in such a way that the credentials provide the least privilege necessary to perform the needed tasks. For more information about setting permissions, see Business Connectivity Service permissions overview in "Business Connectivity Services security overview (SharePoint Foundation 2010)."

To set permissions on a BDC model

  1. Verify that you have one of the following administrative credentials:

    • You must be a farm administrator.

    • You must be an administrator of the Business Data Connectivity service application and have Set Permissions permission on the model.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the View group of the ribbon, click BDC Models.

  5. Select the check box of each BDC model for which you want to set permissions.

  6. In the Permissions group, click Set Object Permissions.

  7. In the box, type the user accounts, groups, or claims for which permissions will be granted, and then click Add.

    Note:

    The user account, group, or claim cannot have a vertical bar (|) in its name.

  8. Set the permissions for the account, group, or claim.

    Note:

    At least one user, group or claim in the metadata object's access control list must have the Set Permissions permission.

    • Click Edit to allow the user, group, or claim to edit the BDC model.

      Security Note:

      The Edit permission should be considered highly privileged. With the Edit permission, a malicious user can steal credentials or corrupt a server farm. To help ensure a secure solution, we recommend using a test environment where the Edit permission can be assigned freely to developers and solution designers. When you deploy the tested solution to a production environment, remove the Edit permissions.

    • Click Set Permissions to allow the user, group, or claim to set permissions on the BDC model.

      Security Note:

      The Set Permissions permission should be considered highly privileged. With the Set Permissions permission, a user can grant Edit permission to the BDC model.

      Important:

      The other two listed permissions, Selectable In Clients and Execute, are not applicable to BDC models.

View all models

You can view all the models in a Business Data Connectivity service application.

To view all models

  1. Verify that you have the following administrative credentials:

    • You must be a farm administrator or an administrator of the service application.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the View group of the ribbon, click BDC Models.

Delete a BDC model

When you delete a BDC model, all external content types and external systems that are contained in the model and that are not also contained in another model are deleted along with it.

To delete a BDC model

  1. Verify that you have one of the following administrative credentials:

    • You must be a farm administrator.

    • You must be an administrator of the Business Data Connectivity service application and have Edit permission on the model.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the View group of the ribbon, click BDC Models.

  5. On the BDC Models page, select the model to delete.

  6. In the BDC models group, click Delete and, when you are prompted, click OK.

View a model's external content types

View a model's external content types to learn about the model or to choose an external content type for a subsequent task.

To view a model's external content types

  1. Verify that you have the following administrative credentials:

    • You must be a farm administrator or an administrator of the service application.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the View group of the ribbon, click BDC Models.

  5. Point to the model, click the arrow that appears, and then click View External Content Types.

See Also

Other Resources

Resource Center: Operations and Manageability for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=220234)


Manage external content types (SharePoint Foundation 2010)
See Also

An external content type is an XML file that defines an object, such as "Customer," "Order," or "Contact," that can be used in a business application. The definition can include the following information:

  • The fields of data that are contained in the object

  • The methods to create, read, update, query, or delete that object

  • Actions that users can take on the object

  • Information that supports connecting to the external data source that provides the object's data

External content types define data that is stored in a supported external system, such as a SQL Server database or other relational database, a SharePoint site, a Web service, or a custom data connector.

An external content type can be added to the Business Data Connectivity service in the following ways:

  • Use Microsoft SharePoint Designer 2010 to create a new external content type.

  • Import an application model into the Business Data Connectivity service application that contains one or more external content types.

    The external content types are added to the Business Data Connectivity service application.

After an external content type is added to the Business Data Connectivity service application, administrators of that service application can modify its permissions, or add more features such as actions and profile pages.

In this article:

  • Set permissions on an external content type

  • View all external content types for an instance of a Business Data Connectivity service application

  • View all external content types contained in a model

  • View details of an external content type

  • Delete an external content type

  • Add an action to an external content type

  • Specify the profile page host for a Business Data Connectivity service application instance

  • Create or update a profile page for an external content type

Set permissions on an external content type

You set permissions on an external content type to specify who can edit the content type, who can execute operations (such as read or update) on it, who can use it to create external lists, and who can set permission on it.

We recommend that you give specific permissions to each user or group that needs them, in such a way that the credentials provide the least privilege necessary to perform the needed tasks. For more information about setting permissions, see Business Connectivity Service permissions overview in "Business Connectivity Services security overview (SharePoint Foundation 2010)".

To set permissions on an external content type

  1. Verify that you have one of the following administrative credentials:

    • You must be a farm administrator.

    • You must be an administrator of the Business Data Connectivity service application and have Set Permissions permission on the external content type.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the View group of the ribbon, click External Content Types.

  5. Click the check box of each external content type for which you want to set permissions.

  6. In the Permissions group of the ribbon, click Set Object Permissions.

  7. In the box, type the user accounts, groups, or claims for which permissions will be granted, and then click Add.

    Note:

    The user account, group, or claim cannot have a vertical bar (|) in its name.

  8. Set the permissions for the account, group, or claim:

    Note:

    At least one user, group or claim in the metadata object's access control list must have the Set Permissions permission.

    • Click Edit to allow the user, group, or claim to edit the external content type.

      Security Note:

      The Edit permission should be considered highly privileged. With the Edit permission a malicious user can steal credentials or corrupt a server farm. To help ensure a secure solution, we recommend using a test environment where the Edit permission can be assigned freely to developers and solution designers. When deploying the tested solution to a production environment, remove the Edit permissions.

    • Click Execute to allow the user, group, or claim to execute operations (create, read, update, delete, or query) on the external content type.

    • Click Selectable In Clients to allow the user, group, or claim to create external lists of the external content type and to view the external content type in the external item picker.

    • Click Set Permissions to allow the user, group, or claim to set permissions on the external content type.

      The Set Permissions permission should be considered highly privileged. With the Set Permissions permission, a user can grant Edit permission to the external content type.

  9. To propagate permissions to all methods nested in the external content type, click Propagate permissions to all methods of this external content type. Doing so will overwrite existing permissions.

View all external content types for an instance of a Business Data Connectivity service application

You can use commands in the View group of the ribbon to view all external content types in the Business Data Connectivity service application.

To view all external content types for an instance of a Business Data Connectivity service application

  1. Verify that you have the following administrative credentials:

    • You must be a farm administrator or an administrator of the service application.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the View group of the ribbon, click External Content Types.

View all external content types contained in a model

View all external content types in a model to learn more about the model, or to select an external content type for other operations.

To view all external content types contained in a model

  1. Verify that you have the following administrative credentials:

    • You must be a farm administrator or an administrator of the service application.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the View group of the ribbon, click BDC Models.

  5. Point to the BDC model, click the arrow that appears, and then click View External Content Types.

View details of an external content type

You can view an external content type to learn about the external type, to view its fields, to view its relationship to other entities, and to view actions or filters that are associated with the external content type. You can view a list of all external content types for a Business Data Connectivity service application, or you can view only those entities that are associated with a particular model.

To view details of an external content type

  1. Verify that you have the following administrative credentials:

    • You must be a farm administrator or an administrator of the service application.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. Point to the external content type that you want to view, click the arrow that appears, and then click View External Content Type.

Delete an external content type

Delete an external content type to remove it from the metadata store. If there are multiple versions of an external content type, deleting the external content type will delete all versions.

To delete an external content type

  1. Verify that you have one of the following administrative credentials:

    • You must be a farm administrator.

    • You must be an administrator of the Business Data Connectivity service application and have Edit permission on the external content type.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the View group of the ribbon, click External Content Types.

  5. Select each external content type to delete.

  6. On the Edit tab, in the Manage group, click Delete.

Add an action to an external content type

You can add a custom action to an external content type. A custom action can be a program or Web page that is accessible by using its uniform resource locator (URL). When you associate an action with an external content type, you can pass parameters to that action based on the contents of one or more fields in the external content type. For example, you could associate a search page's URL with an external content type and provide data from an item of that external content type to parameterize the search.

Note:

When you add a new action to an external content type, that action will not be available in existing external lists of that external content type. Only new external lists of the appropriate external content type will display the action in the shortcut menu.

To add an action to an external content type

  1. Verify that you have the following administrative credentials:

    • You must be a farm administrator or an administrator of the service application.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the View group of the ribbon, click External Content Types.

  5. On the View External Content Types page, select the external content type that you want to add an action to.

  6. Point to the external content type, click the arrow that appears, and then click Add Action.

  7. On the Add Action page, in the Action Name box, type the name of the action.

    This can be any text string. It is the command name that users will see in the shortcut menu when they point to an item of the external content type and click the arrow that appears.

  8. In the Navigate to this URL field, type the full URL of the command that the user will browse to when he or she clicks the action.

    A command can include parameters that will be populated with the contents of one or more fields in the external content type. In the URL that you type in this field, you can include placeholders for each parameter to use. Placeholders should be numbered with integers starting at zero (0, 1, 2, and so on) and should be of the form {number}. For example, the following sample URL provides two parameters, "p0" and "p1":

    http://www.adventure-works.com/sample.aspx?p0={0}&p1={1}

    Caution:

    Parameters can contain personally identifying information such as names and Social Security numbers. When designing actions, be careful not to use fields that display such information inadvertently, or, if this is necessary, make sure that your Web servers use Secure Sockets Layer on all connection points.

  9. If your action is available from within a Web Part, click Yes under Launch the action in a new Web browser window (applies to External Data Web Parts only) to have the action launch a new browser window. This will protect the user from losing the current context when using the action. To have the action occur in the current browser window, click No.

  10. If your action includes parameters, in the Parameter Property field, for each parameter placeholder in your URL, starting with parameter {0}, click Add Parameter and, in the list of available fields in the external content type, click the field whose contents you want to pass for that parameter.

    Repeat this step for each parameter in the URL of the command. You can remove any parameter by clicking the button labeled Remove next to the parameter.

  11. To associate an icon with the custom action, in the Icon section, either click Standard icon and select an icon from the list or, in the The image at this URL field, type the full URL of an image to use as the action's icon.

  12. The default action is the action that occurs when the user clicks the item instead of picking an action from a menu. To make the action the default action, click Default Action.

  13. Click OK to add the action.

Specify the profile page host for a Business Data Connectivity service application instance

A profile page displays the data for an item of an external content type. Profile pages for a Business Data Connectivity service application are stored in a site in the farm that hosts the Business Data Connectivity service. You can specify the site where profile pages are hosted.

To specify the profile page host for a Business Data Connectivity service application instance

  1. Verify that you have the following administrative credentials:

    • You must be a farm administrator or an administrator of the service application.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the Profile Pages group of the ribbon, click Configure.

  5. On the Entity Profile Page Host page, in the Host SharePoint site URL field, specify the URL of a site where profile pages of external content types will be created and stored. This site must be in the same server farm as the Business Data Connectivity service application instance.

    Important:

    The site where profile pages of an external content type are created and stored must grant design rights for anyone who creates or updates profile pages, and read-only permission for all end users who will view the profile pages. If you have to create this site in a new Web application, associate that Web application with the Business Data Connectivity service application.

  6. To lock the site so that profile pages cannot be created, deselect Enable Profile Page Creation.

  7. Click OK.

Create or update a profile page for an external content type

You can create a new profile page for an external content type or you can update an existing page. For example, when you add an external data column to or remove an external data column from an external content type, you could update the profile page to reflect the changes to the external content type.

Caution:

Updating an existing profile page may overwrite the current profile page. Any customizations on the current page could be lost on the updated page.

To create or update a profile page for an external content type

  1. Verify that you have the following administrative credentials:

    • You must be a farm administrator or an administrator of the service application.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the View group of the ribbon, click External Content Types.

  5. On the View External Content Types page, select the external content type for which you want to create or update a profile page.

  6. Point to the external content type, click the arrow that appears, and then click Create/Upgrade Profile Page.

  7. On the Create/Upgrade Profile Pages page, click OK.

    Tip:

    To create or update multiple external content types' profile pages, select a set of external content types, click the Edit tab, and in the Profile Pages group click Create/Upgrade.

See Also

Other Resources

Resource Center: Operations and Manageability for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=220234)


Manage services on the server (SharePoint Foundation 2010)
See Also

Microsoft SharePoint Foundation 2010 includes services that reside on individual servers in the farm. In some cases, you can configure global service settings and start or stop a service. Services are managed directly in Central Administration instead of through a separate administration site. You can also remotely monitor and manage services. Additionally, you can manage services by using Windows PowerShell 2.0.

For more information about services and service applications, see About service applications and services (SharePoint Foundation 2010) and Services architecture planning (SharePoint Foundation 2010).

In this article:

  • Configuring global settings

  • Starting or stopping a service

Configuring global settings

Some services have settings that you can globally configure. For information about how to configure those settings, see the article listed in the following table.

Service | Article
Microsoft SharePoint Foundation Workflow Timer Service | Configure global workflow settings (SharePoint Foundation 2010)

Starting or stopping a service

You can manage services by using the Central Administration Web site or by using Windows PowerShell 2.0.

To start or stop a service by using Central Administration

  1. Confirm that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.

  2. On the SharePoint Central Administration Web site, click System Settings.

  3. On the System Settings page, in the Servers section, click Manage services on server.

  4. To change the server on which you want to start or stop the service, on the Server menu, click Change Server, and then click the server name that you want.

  5. By default, only configurable services are displayed. To view all services, on the View menu, click All.

  6. To start or stop a service, click Start or Stop in the Action column of the relevant service.

  7. Click OK to start or stop the service.

To start a service by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  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:

    Copy Code
    Start-SPServiceInstance -Identity <ServiceGUID>

    Where <ServiceGUID> is the GUID of the service. If you do not know the service GUID, you can retrieve a list of all services in the farm together with their GUIDs by using the Get-SPServiceInstance cmdlet.

For more information, see Start-SPServiceInstance.

To stop a service by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  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:

    Copy Code
    Stop-SPServiceInstance -Identity <ServiceGUID>

    Where <ServiceGUID> is the GUID of the service. If you do not know the service GUID, you can retrieve a list of all services in the farm together with their GUIDs by using the Get-SPServiceInstance cmdlet.

For more information, see Stop-SPServiceInstance.

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.

See Also

Reference

Get-SPServiceInstance


Configure global workflow settings (SharePoint Foundation 2010)

Workflow settings that you configure globally apply to all sites in a Web application. You can enable deployment of user-defined Microsoft SharePoint Designer workflows, allow non-authenticated users to participate in workflows, and disable the automatic cleanup of workflow history that is older than 60 days.

In this section:

  • Enable or disable declarative workflows (SharePoint Foundation 2010)

    Use this procedure to enable or disable workflows that were created and deployed by using Microsoft SharePoint Designer or a third-party application.

  • Allow non-authenticated users to participate in workflows (SharePoint Foundation 2010)

    Use this procedure to allow users who have not been authenticated to receive e-mail messages from workflows and tasks.

  • Disable preservation of workflow history (SharePoint Foundation 2010)

    Use this procedure to disable the workflow automatic cleanup job which, by default, removes workflows and workflow entries 60 days after a workflow is completed or canceled.


Enable or disable declarative workflows (SharePoint Foundation 2010)

When a Farm Administrator enables declarative workflows, users can use Microsoft SharePoint Designer 2010 to deploy declarative workflows.

You can specify whether you want users to be able to deploy declarative workflows, such as those that are created by using Microsoft SharePoint Designer 2010, on sites in a particular Web application. The default setting enables deployment of declarative workflows. When this setting is enabled, users who have been granted minimally the Design permission-level on the site can create and deploy workflows by using the Workflow Editor in Microsoft SharePoint Designer 2010.

To enable or disable declarative workflows for a Web application

  1. Verify that you have the following administrative credentials:

    • To enable or disable declarative workflows, you must be a member of the Farm Administrators SharePoint group.

  2. From the Central Administration Web site, on the Quick Launch, click Application Management.

  3. In the Web Applications section, click Manage web applications.

  4. On the Web Applications Management page, click the Web application that you want to configure.

  5. In the Manage group of the ribbon, click General Settings, and then click Workflow in the list that appears.

  6. In the Workflow Settings dialog box, in the User-Defined Workflows section, do one of the following:

    • To enable declarative workflows for sites in this Web application, click Yes.

    • To disable declarative workflows for this Web application, click No.

  7. Click OK to close the Workflow Settings dialog box.


Allow non-authenticated users to participate in workflows (SharePoint Foundation 2010)

You can allow either or both of the following kinds of non-authenticated users to participate in workflows: internal users who do not have access to the site and external users who do not have access to internal network resources. For internal users, an e-mail message that explains how to request access to the site (subject to administrator approval) is sent to users. For external users, an e-mail message that includes an attached document or list item for the participant to review or sign is sent to users.

Caution:

When you allow non-authenticated users to participate in workflows, you do not give non-authorized users access to the site. However, the e-mail message and attachment might contain sensitive information. Before you enable these settings, consider whether there are possible risks of disclosure of information with regard to users who do not have access to the site.

Allow non-authenticated users to participate in workflows

To allow internal users without site access to participate in workflows

  1. Verify that you have the following administrative credentials:

    • To allow internal users without site access to participate in workflows, you must be a member of the Farm Administrators SharePoint group.

  2. From Central Administration Web site, on the Quick Launch, click Application Management.

  3. In the Web Applications section, click Manage web applications.

  4. On the Web Applications Management page, in the Name column, click the Web application that you want to configure.

  5. In the Manage group of the ribbon, click General Settings, and then click Workflow in the list that appears.

  6. In the Workflow Settings dialog box, in the Workflow Task Notifications section, in the Alert internal users who do not have site access when they are assigned a workflow task? option, click Yes to send an e-mail message to internal users who do not have access to the site when they are assigned a workflow task. By default, this setting is enabled.

    Tip:

    You must also grant each user, who is not a site member, minimally the Contribute permission-level to the task list that is used by the workflow in which you want them to participate.

  7. Click OK to close the Workflow Settings dialog box.

To allow external users to participate in workflows

  1. From the Central Administration Web site, on the Quick Launch, click Application Management.

  2. In the Web Applications section, click Manage web applications.

  3. On the Web Applications Management page, click the Web application that you want to configure.

  4. In the Manage group of the ribbon, click General Settings, and then click Workflow in the list that appears.

  5. In the Workflow Settings dialog box, in the Workflow Task Notifications section, in the Allow external users to participate in workflow by sending them a copy of the document? option, click Yes to allow external users to participate in workflow by sending them a copy of the document. By default, this setting is disabled.

  6. Click OK to close the Workflow Settings dialog box.

Note:

If you later decide that you do not want non-authenticated participants to participate in workflows, access this page again and then click No to disable one or both options.


Disable preservation of workflow history (SharePoint Foundation 2010)

A workflow is made up of a sequence of events such as workflow initiation, task creation, and task completion. When you add a workflow, you specify a task list and a history list that workflow instances of that workflow association will use to track the events for the workflow. The task list contains items that users interact with and enter data into while interacting with a workflow. The workflow history contains key information about each event including date, status, participant, and description.

For more information about workflow status reports, see Monitor workflows (SharePoint Foundation 2010).

Disable automatic workflow cleanup

By default, Microsoft SharePoint Foundation 2010 runs a daily Workflow Auto Cleanup job to permanently delete workflow instances and related task entries that still exist 60 days after a workflow is completed or canceled. Workflow history items themselves are not deleted, but the entry point to view them on the status page for a particular instance of a workflow will no longer be available. You can disable the Workflow Auto Cleanup job if you want to keep workflow data available longer. However, as with any SharePoint list, as the workflow history and task lists grow in size, site performance may be compromised. If you are concerned about the size of these lists, keep the Workflow Auto Cleanup job enabled. Whether or not you keep the Workflow Auto Cleanup job enabled, you can create a separate history and task list for each workflow association to distribute items across lists.

For more information, see Add a workflow association (SharePoint Foundation 2010).

Note:

Workflow history is not intended to be used to audit workflow events and is not necessarily secure because a user who has edit permissions on the site can update items in the history list, by default.

To disable automatic workflow cleanup

  1. Verify that you have the following administrative credentials:

    • To disable automatic workflow cleanup, you must be a member of the Farm Administrators SharePoint group.

  2. From the Central Administration Web site, on the Quick Launch, click Monitoring.

  3. On the Monitoring page, in the Timer Jobs section, click Review job definitions.

  4. On the Job Definitions page, in the Title column, click the Workflow Auto Cleanup link that is associated with the Web application for which you want to disable automatic workflow cleanup.

    Tip:

    The Web Application column on the Job Definitions page contains the name of the Web application to which each timer job is associated.

  5. On the Edit Timer Job page, click Disable to disable the Workflow Auto Cleanup feature.

Note:

If you later decide that you want to enable automatic workflow cleanup, access this page again and then click Enable to enable automatic workflow cleanup.


Web applications management (SharePoint Foundation 2010)
See Also

The articles in this section describe how to create and manage Web applications in a Microsoft SharePoint Foundation 2010 server farm. These articles are written for farm administrators who will operate SharePoint Foundation 2010. The articles also describe how to configure cache settings and how to manage permissions and permission policies for a Web application.

In this section:

  • Create a Web application (SharePoint Foundation 2010)

    This article describes how to create a Web application.

  • Configure settings for a Web application (SharePoint Foundation 2010)

    After you create a Web application, you will most likely want to customize it. This article describes the available settings that you can configure for a Web application.

  • Extend a Web application (SharePoint Foundation 2010)

    If you want to use separate IIS Web sites to expose the same content to users, you can extend an existing Web application. This article describes how to extend a Web application.

  • Unextend a Web application (SharePoint Foundation 2010)

    This article describes how to unextend a Web application.

  • Delete a Web application (SharePoint Foundation 2010)

    This article describes how to delete a Web application.

  • View site collections in a Web application (SharePoint Foundation 2010)

    You can view a list of site collections in a Web application to find information about the URL, title, description, primary site collection administrator, and other data for each site collection in the Web application. This article describes how to view site collections.

  • Manage permissions for a Web application (SharePoint Foundation 2010)

    This article describes how to manage permissions for a Web application.

  • Manage permission policies for a Web application (SharePoint Foundation 2010)

    This article describes how to manage permission policies for a Web application.

See Also

Concepts

Configure claims authentication (SharePoint Foundation 2010)
Create a site collection (SharePoint Foundation 2010)
Manage blocked file types (SharePoint Foundation 2010)
Plan site permissions (SharePoint Foundation 2010)


Configure settings for a Web application (SharePoint Foundation 2010)
See Also

After you create a Web application, you can use Central Administration, Windows PowerShell 2.0 cmdlets, or the Stsadm command-line tool to configure Web application settings. Web application settings affect all site collections in the Web application.

This article describes the general settings that you can configure for a Web application, and introduces other articles that describe additional Web application settings.

Web application general settings

You typically configure the Web application general settings when you create a new Web application. You can access the general settings in Central Administration by clicking Manage Web applications in the Application Management section, clicking the Web application that you want to configure, and then clicking General Settings on the ribbon.

Note:

You must be a member of the Farm Administrators SharePoint group to use Central Administration.

Many of these settings can also be configured by using Windows PowerShell 2.0 cmdlets. For information about how to use Windows PowerShell 2.0 cmdlets for Microsoft SharePoint Foundation 2010 administrative tasks, see Windows PowerShell for SharePoint Foundation 2010, and the individual articles that are referenced in this article for particular settings.

The following list describes general settings for a Web application:

  • Resource throttling

    Resource throttling settings let you fine-tune the Web application for improved performance. We do not recommend that you adjust the default settings unless you have tested the server configuration and know that making these changes will definitely improve performance.

  • Workflow

    SharePoint Foundation 2010 provides a set of predefined workflows that you can use to guide and track common tasks such as document review or approval. In addition to using the predefined workflows, you can define your own workflows by using Microsoft Office SharePoint Designer 2007 or create code-based custom workflows by using Visual Studio. You can configure workflow settings that apply to all sites in a Web application. For more information about using and configuring workflows, see Workflow administration (SharePoint Foundation 2010).

  • Outgoing e-mail

    You can configure outgoing e-mail for a specific Web application so that users can track changes and updates to individual site collections. For more information, see Configure outgoing e-mail (SharePoint Foundation 2010).

  • Mobile account

    You can configure and manage a mobile account to enable users to subscribe to alerts that are sent via Short Message Service (SMS). The alerts are sent to users' mobile phones when changes are made in a SharePoint list or item. For more information, see Configure a mobile account (SharePoint Foundation 2010).

  • SharePoint Designer

    You can specify whether to allow users to edit sites by using Microsoft SharePoint Designer 2010. By default, this setting is On. Additional settings for SharePoint Designer 2010 are as follows:

    • Allow Site Collection Administrators to Detach Pages from the Site Template.

      You can specify whether to allow site collection administrators to detach pages from the original site definition by using SharePoint Designer 2010. By default, this setting is On.

    • Allow Site Collection Administrators to Customize Master Pages and Layout Pages.

      You can specify whether to allow site collection administrators to customize master pages and layout pages by using SharePoint Designer 2010. By default, this setting is On.

    • Allow Site Collection Administrators to see the URL Structure of their Web Site.

      You can specify whether to allow site collection administrators to manage the URL structure of a Web site by using SharePoint Designer 2010. By default, this setting is On.

  • General settings

    The General Settings option on the General Settings drop-down menu lets you view and modify the following settings for a Web application.

    • Default Time Zone

      You can define the default time zone that is used for all sites in the Web application.

    • Default Quota Template

      A quota template consists of storage limit values that specify how much data can be stored in a site collection, and the storage size limit that triggers an e-mail alert to the site collection administrator. Use this setting to select a default quota template for all site collections in the Web application. For more information, see Plan quota management (SharePoint Foundation 2010).

    • Person Name Smart Tag and Presence Settings

      When the Person Name smart tag and Online Status is enabled, online presence information is displayed next to member names and the Person Name smart tag appears when users move the pointer over a member name anywhere on the Web site. This setting is enabled by default.

    • Alerts

      You can specify alert settings for the Web application. By default, alerts are enabled and each user is limited to 500 alerts. For more information, see Configure alert settings for a Web application (SharePoint Foundation 2010).

    • RSS Settings

      You can enable Really Simple Syndication (RSS) feeds for viewing RSS feeds from blogs, news sources, and other venues. By default, RSS feeds are enabled.

    • Blog API Settings

      You can select whether to enable the MetaWeblog API for the Web application. By default, the MetaWebLog API is enabled and the setting to accept a user name and password from the API is set to No.

    • Browser File Handling

      You can specify whether additional security headers are added to documents that are served to Web browsers. These security headers specify that a browser shows a download prompt for certain types of files (for example, .html), and to use the server's specified Multipurpose Internet Mail Extensions (MIME) type for other types of files.

      The Permissive setting specifies that no headers are added. The Strict setting adds headers that force the browser to download certain types of files. The forced download improves security for the server by disallowing the automatic execution of Web content. By default, the setting is Strict.

    • Web Page Security Validation

      The Web Page Security Validation setting establishes an amount of time after which a user is required to retry the last operation. By default, security validation is set to On with a 30-minute expiration time.

    • Send User Name and Password in E-Mail

      This option lets users retrieve their user name and password by e-mail. If this option is turned off, a new user cannot access the site until an administrator changes the user's password and notifies them of the new password. By default, this setting is On.

    • Master Page Setting for Application _Layouts Pages

      You can allow pages in the _Layouts folder to reference site master pages. Pages in the Application _Layouts folder are available to all sites in the farm. If this setting is Yes, most pages in the _Layouts folder will reference the site master page and show the customizations that have been made to that master page. By default, this setting is Yes.

    • Recycle Bin

      You can specify whether the Recycle Bins in the Web application are turned on. For more information, see Configure Recycle Bin settings (SharePoint Foundation 2010).

    • Maximum Upload Size

      You can specify the maximum size to allow for any single upload to any site. By default, the maximum upload size is set to 50 megabytes (MB).

    • Customer Experience Improvement Program

      You can collect Web site analytics about Web page usage on the Web application. By default, this setting is Yes.

In this section

The following list references additional articles that describe how to configure settings for a Web application:

  • Manage permission policies for a Web application (SharePoint Foundation 2010)

    Administrators can define policies to establish different levels of access to sites within Web applications to various users. This article describes how to create and manage permissions policies.

  • Manage permissions for a Web application (SharePoint Foundation 2010)

    Administrators can control user actions by enabling or disabling the associated permission on the Web application. This article describes how to establish permissions on a Web application.

  • Turn on or turn off self-service site creation (SharePoint Foundation 2010)

    Self-service site creation lets designated users create sites in defined URL namespaces. This article describes how to configure this feature for a Web application.

  • Configure Recycle Bin settings (SharePoint Foundation 2010)

    Recycle Bins help users and site collection administrators recover data. This article describes how to configure Recycle Bins for a Web application.

  • Configure alert settings for a Web application (SharePoint Foundation 2010)

    The alerts feature helps users keep track of changes that were made to a Web site. The feature does this through an e-mail notification service. This article describes how to configure alerts.

  • Define managed paths (SharePoint Foundation 2010)

    By defining managed paths, you can specify which paths in the URL namespace of a Web application are used for site collections. This article describes how to configure managed paths for a Web application.

  • Add or remove a service application connection to a Web application (SharePoint Foundation 2010)

    A service application connection associates the service application to Web applications via membership in a service application connection group (also referred to as application proxy group). This article describes how to add or remove service application connections to a service application connection group.

See Also

Concepts

View site collections in a Web application (SharePoint Foundation 2010)
Create a Web application (SharePoint Foundation 2010)
Extend a Web application (SharePoint Foundation 2010)
Add or remove a service application connection to a Web application (SharePoint Foundation 2010)


Configure alert settings for a Web application (SharePoint Foundation 2010)

To help users keep track of changes that are made to a Web site, Microsoft SharePoint Foundation 2010 includes the alerts feature, which is an e-mail notification service. Users can configure which alerts they want to receive or send to communicate and track changes to items on a Web site.

Users can create alerts on the following items in a site:

  • Lists

    Users are notified of changes to the list, such as when an item is added, deleted, or changed in a list.

  • List items

    Users are notified of changes to a particular item in a list.

  • Document libraries

    Users are notified of changes to the document library, such as when a document is added, deleted, or changed in a document library or when Web discussions are added, changed, deleted, closed, or started for a document.

  • Documents

    Users are notified of changes in a particular document such as when a document is changed, added, deleted, or closed.

Note:

Users must have at least View Items permissions to use alerts. For more information about how to assign user permissions to a Web application, see Plan site permissions (SharePoint Foundation 2010).

You can use Central Administration or Windows PowerShell 2.0 cmdlets to configure alerts. You can turn on or turn off alerts, and you can specify how many alerts users can create.

Before alerts can work for any Web site, outgoing e-mail must be enabled for the server. For more information about how to use alerts and administrative messages and set up outgoing e-mail, see Configure outgoing e-mail (SharePoint Foundation 2010).

Note:

Some deployments have a resource forest in which users are in a different domain from SharePoint Foundation 2010. If the resource forest trusts the user domain but the user domain does not trust the resource forest, users will receive intermittent alerts. To resolve this issue, implement one of the following solutions:

  • Retain the one-way trust, and use universal security groups in the user domain to grant permission to SharePoint resources. For more information, see Create a New Group (http://go.microsoft.com/fwlink/p/?LinkID=235815).

  • Create a two-way, forest trust for the resource domain and the user domain, and then use local security groups in the resource domain to grant permission to SharePoint resources. For more information, see Create a Two-Way, Forest Trust for Both Sides of the Trust (http://go.microsoft.com/fwlink/p/?LinkID=261337) and Create a New Group (http://go.microsoft.com/fwlink/p/?LinkID=235815).

For more information, see "Scenarios with Alerts and more than one Active Directory Forest when using NTLM for a WebApp" entry in the Microsoft Office and related blog (http://go.microsoft.com/fwlink/p/?LinkId=264920).

In this article:

  • To configure alert settings for a Web application by using Central Administration

  • To configure alert settings for a Web application by using Windows PowerShell

To configure alert settings for a Web application by using Central Administration

  1. Verify that the user account that is performing this task is a member of the Farm Administrators SharePoint group.

  2. On the SharePoint Central Administration Web site, click Application Management.

  3. On the Application Management page, click Manage Web Applications.

  4. Click the Web application for which you want to configure alerts. The ribbon becomes active.

  5. On the ribbon, click the General Settings drop-down menu, and then click General Settings.

  6. On the Web Application General Settings page, in the Alerts section, configure the following settings:

    • Specify whether alerts are On or Off. By default, alerts are On.

    • Specify the Maximum number of alerts that a user can create in a SharePoint Web site. This value can be any integer from 1 through 2,000,000,000, or you can specify that the number of alerts is unlimited. The default value is 500 alerts.

  7. After you have finished configuring alerts, click OK.

To configure alert settings for a Web application 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. To configure alerts by using Windows PowerShell 2.0, you must first retrieve the SPWebApplication object for the Web application by using the Get-SPWebApplication cmdlet together with the URL of the Web application. You must then set the appropriate alert properties for the object, and save the changes by using the Update() method of the SPWebApplication object. The following code sample performs each of these steps.

    At the Windows PowerShell command prompt, type the following commands:

    Copy Code
    $webappurl="<http://ServerName:WebApplicationName>"
$webapp=Get-SPWebApplication $webappurl
# to query the settings you can use the following properties
# Gets a value that specifies whether alerts are allowed in the Web application.
$webapp.AlertsEnabled

# Gets a value specifying whether there is a limit to the number of
# lists, document libraries, documents and list items for which a user can create alerts.
$webapp.AlertsLimited

# Gets the maximum number of lists, document libraries, documents and list items
# for which a single user can create alerts in a SharePoint web site.
$webapp.AlertsMaximum

# Sets a value that specifies whether alerts are allowed in the Web application.
# to enable alerts in this Web application
$webapp.AlertsEnabled = $true
$webapp.Update()

# to disable alerts in this Web application
$webapp.AlertsEnabled = $false
$webapp.Update()

# Sets a value specifying whether there is a limit to the number of
# lists, document libraries, documents and list items for which a user can create alerts.
# to enable limited number of alerts and use of AlertsMaximum setting
$webapp.AlertsLimited = $true
$webapp.Update()

# to enable unlimited number of alerts
$webapp.AlertsLimited = $false
$webapp.Update()

# Sets the maximum number of lists, document libraries, documents and list items
# for which a single user can create alerts in a SharePoint web site.
$webapp.AlertsMaximum=<MaxAlertsNumber>
$webapp.Update()

    Where:

    • <http://ServerName:WebApplicationName> is the URL of the Web application.

    • <MaxAlertsNumber> is the maximum number of alerts that a single user can create.

For more information, see Get-SPWebApplication.


Configure Recycle Bin settings (SharePoint Foundation 2010)
See Also

Recycle Bins are used to help users protect and recover data.Microsoft SharePoint Foundation 2010 supports two stages of Recycle Bins: the first-stage Recycle Bin and second-stage Recycle Bin.

When a user deletes an item, the item is automatically sent to the first-stage Recycle Bin. By default, when an item is deleted from the first-stage Recycle Bin, the item is sent to the second-stage Recycle Bin. A site collection administrator can restore items from the second-stage Recycle Bin.

You turn on and configure Recycle Bins at the Web application level. By default, Recycle Bins are turned on in all the site collections in a Web application. This article describes how to configure Recycle Bin settings for a Web application.

For more information and usage recommendations about Microsoft SharePoint Foundation 2010 Recycle Bins, see Plan to protect content by using recycle bins and versioning (SharePoint Foundation 2010).

Note:

You cannot perform this task by using Windows PowerShell cmdlets. You must use the Stsadm command-line tool or the SharePoint Central Administration Web site instead. For information about how to configure Recycle Bin settings by using the Stsadm command-line tool, see Recycle Bin: Stsadm properties (Windows SharePoint Services).

To configure Recycle Bin settings 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. On the SharePoint Central Administration Web site, click Application Management.

  3. On the Application Management page, click Manage Web Applications.

  4. Click the Web application for which you want to configure Recycle Bin settings. The ribbon becomes active.

  5. On the ribbon, click the General Settings drop-down menu, and then click General Settings.

  6. On the Web Application General Settings page, in the Recycle Bin section, you can configure the following settings:

    • You can set the Recycle Bins for the Web application to be On or Off. By default, Recycle Bins are turned on.

      Note:

      If you turn off the Recycle Bins, any existing items in both the first and second-stage Recycle Bins are deleted. Depending on how much data is contained in the Recycle Bins, deleting these items can take a long time.

    • You can specify a time after which items in the Recycle Bins are deleted, or you can specify that these items should never be deleted. By default, items are deleted after 30 days.

    • You can specify a percentage of live site quota for second-stage deleted items. The default setting is 50 percent. You can also turn off second-stage Recycle Bins. If you select Off, site collection administrators cannot recover items deleted from end-user Recycle Bins.The second-stage Recycle Bin quota percentage must be a value from 1 through 500.

  7. After you have finished configuring the Recycle Bins, click OK.

See Also

Other Resources

View, restore, or delete items in the Recycle Bin
Resource Center: Business Continuity Management for SharePoint Foundation 2010


Define managed paths (SharePoint Foundation 2010)
See Also

By defining managed paths, you can specify which paths in the URL namespace of a Web application are used for site collections. You can specify that one or more site collections exists at a specified path. This can be a convenient method of consolidating multiple site access for users in various departments.

An explicitly named path (for example, http://server/sites/team) is used for a single site collection. A wildcard path of "sites" (for example, http://server/sites/) indicates that child URLs of the path are site collections.

Important:

Do not use "/*" to indicate wildcard managed sites at the root of the site collection. Using this wildcard prevents a site from being created at the root of the Web application, which is required for some Microsoft SharePoint Foundation 2010 features to work.

In this article:

  • Define managed paths for a Web application by using Central Administration

  • Define managed paths for a Web application by using Windows Powershell

Define managed paths for a Web application by using Central Administration

Use the procedures described here to add or delete managed paths for a Web application by using Central Administration.

To add a managed path by using Central Administration

  1. Verify that the user account that is performing this task is a member of the Farm Administrators SharePoint group.

  2. On the SharePoint Central Administration Web site, click Application Management.

  3. On the Application Management page, click Manage Web Applications.

  4. Click the Web application for which you want to manage paths. The ribbon becomes active.

  5. On the ribbon, click Managed Paths.

  6. On the Define Managed Paths page, in the Add a New Path section, type the path to include.

  7. Click Check URL to confirm the path name.

  8. Use the Type dropdown menu to identify the path as either Wildcard inclusion or Explicit inclusion. The Wildcard inclusion type includes all paths that are subordinate to the specified path. The Explicit inclusion type includes only the site that is indicated by the specified path. Sites subordinate to the specified path are not included.

  9. Click Add Path.

  10. When you have finished adding paths, click OK.

To remove a managed path by using Central Administration:

  1. Verify that the user account that is performing this task is a member of the Farm Administrators SharePoint group.

  2. On the SharePoint Central Administration Web site, click Application Management.

  3. On the Application Management page, click Manage Web Applications.

  4. Click the Web application for which you want to manage paths. The ribbon becomes active.

  5. On the ribbon, click Managed Paths.

  6. On the Define Managed Paths page, in the Included Paths section, click the check box next to the path that you want to remove.

  7. Click Delete selected paths.

    Warning:

    Be sure that you want to remove the selected path before performing this action. You will have no additional opportunity to confirm. Deletion is immediate.

  8. When you have finished removing paths, click OK.

Define managed paths for a Web application by using Windows Powershell

You can use the New-SPManagedPath cmdlet to add managed paths for a Web application. You can use the Remove-SPManagedPath cmdlet to remove managed paths from a Web application.

The New-SPManagedPath cmdlet adds a new managed path to a given Web application or for use with all host header site collections. If the HostHeader switch is provided, the managed path is shared among all host header site collections; otherwise, you must specify a Web application in which to create this managed path. The relative URL is a partial URL that represents the managed path. When the slash mark (/) is used, the root is defined. If the Explicit parameter is not provided, the new managed path is a wildcard path.

To add a managed path 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    New-SPManagedPath [-RelativeURL] "</RelativeURL>" -WebApplication <WebApplication>

    Where:

    • </RelativeURL> is the relative URL for the new managed path. The type must be a valid partial URL, such as site or sites/teams/.

    • <WebApplication> is the Web application group to add this path.

For more information, see New-SPManagedPath.

To remove a managed path 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. At the Windows PowerShell command prompt, type the following command:.

    Copy Code
    Remove-SPManagedPath [-Identity] <ManagedPathName> -WebApplication <WebApplication>

    Where:

    • <ManagedPathName> is the name of the managed path to delete.

    • <WebApplication> is the identity of the Web application that hosts the managed path to delete.

    You are prompted to confirm the deletion.

For more information, see Remove-SPManagedPath.

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.

See Also

Reference

Get-SPManagedPath

Concepts

Plan for collaboration sites (SharePoint Foundation 2010)


Turn on or turn off self-service site creation (SharePoint Foundation 2010)

The self-service site creation feature in Microsoft SharePoint Foundation 2010 allows users who have the Use Self-Service Site Creation permission to create sites in defined URL namespaces. For more information about user and site permissions, see User permissions and permission levels (SharePoint Foundation 2010). To determine whether self-service site creation is a good practice for Web sites in your organization, see Plan sites and site collections (SharePoint Foundation 2010).

Note:

You cannot perform this task by using Windows PowerShell cmdlets. You must use the Stsadm command-line tool or the SharePoint Central Administration Web site instead.

In this article:

  • To turn on or turn off self-service site creation by using Central Administration

  • To turn on or turn off self-service site creation by using the Stsadm command-line tool

To turn on or turn off self-service site creation by using Central Administration

  1. Verify that the user account that is performing this task is a member of the Farm Administrators SharePoint group.

  2. On the SharePoint Central Administration Web site, click Application Management.

  3. On the Application Management page, click Manage Web Applications.

  4. Click the Web application for which you want to turn on or turn off self-service site creation. The ribbon becomes active.

  5. On the ribbon, click Self-Service Site Creation.

  6. On the Self-Service Site Collection Management page, configure the following settings:

    • Specify whether self-service site creation is On (enabled) or Off (disabled) for the Web application. The default value is On.

    • To require users of self-service site creation to supply a secondary contact name on the sign-up page, select Require secondary contact.

  7. Click OK to complete the operation.

    Note:

    When you turn on self-service site creation, an announcement is added to the Announcements list on the home page of the top-level Web site in the root site collection for the Web application. The announcement provides a link to the site creation page.

To turn on or turn off self-service site creation by using the Stsadm command-line tool

  1. Verify that the user account that you use to run the Stsadm command-line tool is a member of the Administrators group on the local computer and a member of the Farm Administrators group.

  2. On the drive where SharePoint Foundation 2010 is installed, click Start, and then type command prompt into the text box. In the list of results, right-click Command Prompt, click Run as administrator, and then click OK.

  3. At the command prompt, type the following command:

    cd %CommonProgramFiles%\Microsoft Shared\Web server extensions\14\bin

    • To turn on self-service site creation, type the following command:

      stsadm.exe -o enablessc -url<url>-requiresecondarycontact

      Where <url> is the URL of the Web application.

      This command turns on self-service site creation and requires a secondary contact.

    • To turn off self-service site creation, type the following command:

      stsadm -o disablessc -url<url>

      Where <url> is the URL of the Web application.

For more information, see Enablessc: Stsadm operation (Windows SharePoint Services) and Disablessc: Stsadm operation (Windows SharePoint Services).


Extend a Web application (SharePoint Foundation 2010)

If you want to expose the same content in a Web application to different types of users by using additional URLs or authentication methods, you can extend an existing Web application into a new zone. When you extend the Web application into a new zone, you create a separate Internet Information Services (IIS) Web site to serve the same content, but with a unique URL and authentication type.

An extended Web application can use up to five network zones (Default, Intranet, Internet, Custom, and Extranet). For example, if you want to extend a Web application so that customers can access content from the Internet, you select the Internet zone and choose to allow anonymous access and grant anonymous users read-only permissions. Customers can then access the same Web application as internal users, but through different URLs and authentication settings. For more information, see Logical architecture components (SharePoint Foundation 2010) Configure anonymous access for a claims-based Web application (SharePoint Foundation 2010), and Plan authentication methods (SharePoint Foundation 2010).

In this section:

  • Extend a Web application that uses Windows-classic authentication (SharePoint Foundation 2010)

  • Extend a Web application that uses Windows-claims authentication (SharePoint Foundation 2010)


Extend a Web application that uses Windows-classic authentication (SharePoint Foundation 2010)
See Also

Published: October 7, 2010

This article describes how to extend a Web application that uses Windows-classic authentication.

Tip:

If you want to use Windows-claims authentication instead, see Extend a Web application that uses Windows-claims authentication (SharePoint Foundation 2010).

Before you perform this procedure, confirm the following:

  • Your system is running Microsoft SharePoint Foundation 2010.

  • You already have a Web application to extend.

  • You have read Plan authentication methods (SharePoint Foundation 2010) and know which authentication method to use.

  • You have read about zones, anonymous access, and permissions.

  • If you have User Account Control (UAC) turned on in Windows, and you use Windows PowerShell to extend a Web application, you must right-click the SharePoint 2010 Management Shell and select Run as administrator.

You can extend a Web application that uses Windows-classic authentication by using Central Administration or Windows PowerShell. Use one of the following procedures to extend a Web application. You typically use Central Administration to extend a Web application. If you want to automate the task of extending a Web application, which is common in enterprises, use Windows PowerShell. After the procedure is complete, you will have two separate IIS Web sites that expose the same content to users.

To extend a Web application that uses Windows-classic authentication by using Central Administration

  1. Verify that you have the following administrative credentials:

    • To extend a Web application, you must be a member of the Farm Administrators SharePoint group and a member of the local Adminstrator 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 Web application page, select the Web application that you want to extend.

  4. On the ribbon, click Extend.

  5. On the Extend Web Application to Another IIS Web Site page, in the IIS Web Site section, you can configure the settings for your 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 extend your existing 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 point multiple server names to the same server.

  8. In the IIS Web Site section, in the Path box, type the path to the site 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 extended Web application.

    1. In the Authentication Provider section, click Negotiate (Kerberos) or NTLM.

      Note:

      To enable Kerberos authentication, you must perform additional configuration. For more information, see Plan for Kerberos authentication (SharePoint Foundation 2010).

    2. In the Allow Anonymous section, click Yes or No. If you choose to allow anonymous access, this enables anonymous access to the Web site by using the computer-specific anonymous access account (that is, IIS_IUSRS).

      Note:

      If you want users to be able to access any site content anonymously, you must enable anonymous access for the entire Web application zone before you enable anonymous access at the SharePoint site level; later, site owners can configure how anonymous access is used within their sites. If you do not enable anonymous access at the Web application level, you cannot enable anonymous access later, at the site level. For more information, see Choose security groups (SharePoint Foundation 2010).

    3. 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/p/?LinkId=187887).

  10. 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 this Web application zone. 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 Foundation 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.

  11. In the Public URL section, select the zone to use for the Web application in the drop-down menu.

    Note:

    You can create up to five zones within a Web application.

  12. Click OK to extend your existing Web application.

To extend an existing 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 local Administrator on the computer that is running Windows PowerShell.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. To extend a Web application to the same port, but with a different host header, at the Windows PowerShell command prompt, type the following command:

    Copy Code
    Get-SPWebApplication -Identity <Identity> | New-SPWebApplicationExtension -Name <Name> -HostHeader <HostHeader> -Port <Port> -Zone <Zone> -URL <URL>

    Where:

    • <Identity> is the Web application that you want to extend.

    • <Name> is the name of the new IIS Web site in the Web application.

    • <HostHeader> is the host name assigned to this zone of the Web application.

    • <Port> is the port on which this zone of the Web application can be accessed.

    • <Zone> is the zone with which this new extension is to be associated.

    • <URL> is the public URL for this Web application zone.

    Example

    Copy Code
    Get-SPWebApplication -Identity http://sitename | New-SPWebApplicationExtension -Name ExtranetSite -HostHeader www.contoso.com -Port 80 -Zone Extranet -URL http://extranet.sitename.com

For more information, see New-SPWebApplicationExtension.

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.

See Also

Concepts

Create a Web application that uses Windows-classic authentication (SharePoint Foundation 2010)
Extend a Web application that uses Windows-claims authentication (SharePoint Foundation 2010)


Extend a Web application that uses Windows-claims authentication (SharePoint Foundation 2010)
See Also

Published: October 7, 2010

This article describes how to extend a Web application that uses Windows-claims authentication.

Tip:

If you want to use Windows-classic authentication instead, see Extend a Web application that uses Windows-classic authentication (SharePoint Foundation 2010).

Before you perform these procedures, confirm the following:

  • Your system is running Microsoft SharePoint Foundation 2010.

  • You already have a Web application to extend.

  • You have read Plan authentication methods (SharePoint Foundation 2010) and know which authentication method to use.

  • You have read about zones, anonymous access, and permissions..

  • If you have User Account Control (UAC) turned on in Windows, and you use Windows PowerShell to extend a Web application, you must right-click the SharePoint 2010 Management Shell and select Run as administrator.

You can extend a Web application that uses Windows-claims authentication by using Central Administration or Windows PowerShell. Use one of the following procedures to extend a Web application. You typically use Central Administration to extend a Web application. If you want to automate the task of extending a Web application, which is common in enterprises, use Windows PowerShell. After the procedure is complete, you will have two separate IIS Web sites that expose the same content to users.

To extend a Web application that uses 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 Extend.

  4. On the Extend Web Application to Another IIS Web Site page, in the IIS Web Site section, you can configure the settings for your extended 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 extend your existing Web application.

    • Click Create a new IIS web site, and then type the name of the Web site in the Name box.

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

  6. Optional: In the IIS Web Site section, in the Host Header box, type the host name (for example, www.contoso.com) that 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 to use port 80 on the same server and DNS has been configured to point multiple server names to the same server.

  7. In the IIS Web Site section, in the Path box, type the path to the site 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.

  8. In the Security Configuration section, choose whether to use allow anonymous access and whether to use Secure Sockets Layer (SSL).

    1. Under Allow Anonymous, click Yes or No. If you choose to allow anonymous access, this enables anonymous access to the Web site by using the computer-specific anonymous access account (that is, IIS_IUSRS).

      Note:

      If you want users to be able to access any site content anonymously, you must enable anonymous access for the entire Web application zone before you enable anonymous access at the SharePoint site level; later, site owners can configure how anonymous access is used within their sites. If you do not enable anonymous access at the Web application level, you cannot enable anonymous access later, at the site level. For more information, see Choose security groups (SharePoint Foundation 2010).

    2. 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/p/?LinkId=187887).

  9. In the Claims Authentication Types section, select the authentication that you want to use for the Web application.

    1. 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 Plan for Kerberos authentication (SharePoint Foundation 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 Foundation 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.

    2. 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 Foundation 2010).

      Note:

      If you select this option, ensure that SSL is enabled; otherwise, the credentials can be intercepted by a malicious user.

    3. 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 Foundation 2010).

    You can use one or more claims authentication types. For more information, see Plan authentication methods (SharePoint Foundation 2010).

  10. In the Sign In Page URL section, choose one of the following options to sign into SharePoint Foundation 2010.

    • Select Default Sign In Page URL if you want users to be redirected to a default sign-in Web site for claims-based authentication.

    • Select Custom Sign In page URL and then type the sign-in URL if you want users to be redirected to a custom sign-in Web site for claims-based authentication.

  11. 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 in all links shown on pages within the Web application. The default URL is the current server name and port.

  12. In the Public URL section, select the zone to use for the Web application in the drop-down menu.

    Note:

    You can create up to five zones within a Web application.

  13. Click OK to extend the existing Web application.

To extend an existing 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 local Administrator on the computer that is running Windows PowerShell.

  2. On the Start menu, click All Programs.

  3. Click Microsoft SharePoint 2010 Products.

  4. Click SharePoint 2010 Management Shell.

  5. To change the authentication from Windows-claims authentication to forms-based authentication, at the Windows PowerShell command prompt, type the following command:

    Copy Code
    $ap = New-SPAuthenticationProvider -ASPNETRoleProviderName <RoleProviderName> -ASPNETMembershipProvider <MembershipProviderName>

    To extend a Web application to the same port, but with a different host header, at the Windows PowerShell command prompt, type the following command:

    Copy Code
    Get-SPWebApplication -Identity http://sitename | New-SPWebApplicationExtension -Name <Name> -HostHeader <HostHeader> -Zone <Zone> -URL <URL> -Port <Port> -AuthenticationProvider $ap

    Where:

    • <RoleProviderName> is the name of the role provider.

    • <MembershipProviderName> is the name of the membership provider.

    • <Identity> is the Web application that you want to extend.

    • <Name> is the name of the new IIS Web site in the Web application.

    • <HostHeader> is the hostname assigned to this zone of the Web application.

    • <Zone> is the zone with which this new extension is to be associated.

    • <URL> is the public URL for this Web application zone.

    • <Port> is the port on which this zone of the Web application can be accessed.

    Example

    Copy Code
    $ap = New-SPAuthenticationProvider -ASPNETRoleProviderName roleprovidername -ASPNETMembershipProvider membershipprovidername
    Copy Code
    Get-SPWebApplication -Identity http://sitename | New-SPWebApplicationExtension -Name IntranetSite -HostHeader www.contoso.com -Zone Intranet -URL http://intranet.sitename.com -Port 9876 -AuthenticationProvider $ap

For more information, see New-SPWebApplicationExtension.

Note:

After you have extended an existing Web application that uses Windows-claims authentication to a Web application that uses forms-based authentication, you must perform additional configuration. For more information about forms-based authentication, see Configure forms-based authentication for a claims-based Web application (SharePoint Foundation 2010).

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.

See Also

Concepts

Create a Web application that uses Windows-claims authentication (SharePoint Foundation 2010)
Extend a Web application that uses Windows-classic authentication (SharePoint Foundation 2010)


Unextend a Web application (SharePoint Foundation 2010)
See Also

This article describes how to unextend a Web application. When you unextend a Web application, you remove the association between the Web application on the one hand and the IIS Web site and zone on the other hand. You would typically unextend a Web application if you want to be able to use the Web application at a later time, but do not want it to be available on that particular IIS Web site. This enables you to preserve the content databases and Web application settings associated with the Web application for later reuse.

If you update the alternate access mapping URLs of a Web application, SharePoint Foundation 2010 does not automatically update the IIS bindings. To fix this issue, you must unextend the Web application from the associated zone, and then re-extend the Web application with the updated IIS bindings.

You can also delete the IIS Web site if it is only hosting SharePoint-based content and you do not need the IIS Web site anymore.

Before you perform these procedures, confirm that:

  • No one is using the Web application zone that you want to unextend.

  • If you have User Account Control (UAC) turned on in Windows and you use Windows PowerShell to unextend a Web application, you must right-click the SharePoint 2010 Management Shell and select Run as administrator.

You can unextend a Web application by using the SharePoint Central Administration Web site or Windows PowerShell. You typically use Central Administration to unextend a Web application in a single server with built-in database deployment. If you want to automate the task of unextending a Web application, which is common in enterprises, use Windows PowerShell.

To unextend a Web application by using Central Administration

  1. Verify that you have the following administrative credentials:

    • To unextend a Web application, you must be a member of the Farm Administrators SharePoint group and a 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. Select the Web application that you want to unextend, and on the ribbon, select Delete, and then click Remove SharePoint from IIS Web Site.

  4. On the Remove SharePoint From IIS Web Site page, in the Deletion Options section, in the Select IIS Web site and zone to remove list, click the name Web application that you want to unextend from the IIS Web site and zone.

  5. Under Delete IIS web sites, do one of the following:

    • Select Yes if you want to delete the IIS Web site.

    • Select No if you do not want to delete the IIS Web site.

  6. Click OK.

To unextend a Web application by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. You must also be a member of the local Administrators group on the computer running Central Administration.

  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:

    Copy Code
    Remove-SPWebApplication -identity http://sitename -Zone {Default | Intranet | Internet | Internet | Custom | Extranet} -Confirm

    This command removes the zone that you have specified for the Web application extension at http://sitename. This command does not remove the content databases or the IIS Web site.

    Note:

    Be aware that this cmdlet can be used to delete the Web application, so be sure to use the appropriate parameters.

For more information, see Remove-SPWebApplication.

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.

See Also

Concepts

Extend a Web application (SharePoint Foundation 2010)


Delete a Web application (SharePoint Foundation 2010)

This article describes how to delete a Web application. When you delete a Web application, you can optionally delete the content databases and the IIS Web sites. If you delete the content databases, all site content contained within them is deleted. If you delete the IIS Web sites, all IIS metabase entries that refer to the Web application are also deleted. If you only delete the Web application and not the content databases and the IIS Web sites, the content databases and IIS Web sites can be reused by another Web application.

Typically, you would delete a Web application for maintenance purposes or if you are rearchitecting the server farm.

If you are hosting content or applications other than SharePoint content on the IIS Web site that is hosting the Web application, you might want to consider not removing the IIS Web sites. Also, if you are performing maintenance work, you probably want to keep the IIS Web sites. However, if you are only hosting SharePoint content on the IIS Web site or if you plan to do a complete restructuring, then you would want to delete the IIS Web site.

If you want to delete the Web application temporarily, for example, to create the Web application under a different application pool, you might consider not removing the content databases. You can then recreate the Web application with the desired settings and reattach the existing content databases. If you delete the content databases, your content is gone forever unless you have a backup to restore the content databases.

Before you perform these procedures, confirm that:

  • You know the implications of deleting the IIS Web site and the content databases should you chose this option.

  • You have made a backup of the Web application that you plan to delete if, for some reason, you want to restore the deleted Web application. For more information, see Back up a Web application (SharePoint Foundation 2010).

  • If you have User Account Control (UAC) turned on in Windows, and you use Windows PowerShell to delete a Web application, you must right-click the SharePoint 2010 Management Shell and select Run as administrator.

You can delete a Web application by using the SharePoint Central Administration Web site or Windows PowerShell. You typically use Central Administration to delete a Web application in a single server with built-in database deployment. If you want to automate the task of deleting a Web application, which is common in enterprises, use Windows PowerShell.

To delete a Web application by using Central Administration

  1. Verify that you have the following administrative credentials:

    • To delete a Web application, you must be a member of the Farm Administrators SharePoint group and a 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. Select the Web application that you want to delete, and on the ribbon, click Delete and then Delete Web Application.

  4. On the Delete Web Application page, in the Delete Options section, under Delete content databases select Yes if you want to delete the content databases associated with the Web application. Otherwise, select No to keep the content databases.

  5. Under Delete IIS Web sites, select Yes to delete the Web application and the associated IIS Web site. Otherwise, select No to remove only the association of the IIS Web site with the Web application.

Important:

If your IT environment requires the use of a database administrator (DBA) for database creation and management, you might need to contact your DBA to delete the content databases for the Web application. For information about deploying in an environment that uses DBA-created databases, see Deploy by using DBA-created databases (SharePoint Foundation 2010).

To delete a Web application by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. You must also be a member of the local Administrators group on the computer running Central Administration. If you want to delete the content databases associated with this Web application, you also need to have the SharePoint_Shell_Access role within these content databases.

  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:

    Copy Code
    Remove-SPWebApplication -identity http://sitename -Confirm

    This command permanently removes the Web application at http://sitename. This command does not remove the content databases or the IIS Web site.

For more information, see Remove-SPWebApplication.

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.


View site collections in a Web application (SharePoint Foundation 2010)
See Also

When you view a list of site collections through the Central Administration Web site, the page shows the URL, title, description, primary site collection administrator, the contact e-mail address, and the content database name for each site collection. When you use Windows PowerShell 2.0 commands to view site collections, you can view additional information, such as the name of the secondary site collection administrator, the maximum storage limit for the content database, and other details.

In this article:

  • To view site collections by using Central Administration

  • To view site collections by using Windows PowerShell

To view site collections 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. On the Central Administration Home page, click Application Management.

  3. On the Application Management page, in the Site Collections section, click View all site collections. The page lists site collections for the Web application that is displayed in the Web Application drop-down menu.

  4. If the Web application for which you want to view site collections is not listed, click the down-arrow on the Web Application menu, and then click Change Web Application. In the Select Web Application dialog box, click the name of the Web application that you want.

    A list of all site collections that are associated with the Web application is displayed. The site collections are listed in alphabetical order, in groups of 10 site collections per page.

  5. To view the details of a listed site collection, click the URL of the site collection in the URL column of the page (for example, /mysites or /sites/team).

  6. When you have finished viewing site collections, click OK.

To view site collections 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. At the Windows PowerShell command prompt, type the following command:

    Run the Get-SPWebApplication command to return all site collections for a Web application.

    Copy Code
    Get-SPWebApplication <http://WebApplicationURL> | Get-SPSiteAdministration -Limit ALL | Select URL

    Where <http://WebApplicationURL> is the URL of the Web application.

    Run the Get-SPSite command to store the identity of the desired site collection into the $site variable. This retrieves and stores the content database GUID for the site collection into the $dbguid variable.

    Copy Code
    $site = Get-SPSite <http://SiteName>
$dbguid = $site.contentdatabase.id

    Where <http://SiteName> is the name of the site collection.

    Run the Get-SPSite command using the $dbguid variable to display properties for the sites contained on this content database. In the following example, the URL, owner, secondary owner, and quota properties will be displayed in table format. Additional properties can be viewed by adding them to the command.

    Copy Code
    Get-SPSite -ContentDatabase $dbguid | Format-Table -Property Url, Owner, SecondaryOwner, Quota

For more information, see Get-SPWebApplication and Get-SPSite.

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.

See Also

Reference

Get-SPSiteAdministration


Manage permissions for a Web application (SharePoint Foundation 2010)
See Also

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 create a Web application.

All Web applications have List, Site, and Personal permissions. Permissions for a Web application are comprehensive settings that apply to all users and groups for all site collections within a Web application. You can control user actions by enabling or disabling the associated permission on the Web application. For example, if you do not want users to be able to add pages to a Web site, you can disable the Add and Customize Pages permission that is one of the site-related permissions. For more information, see User permissions and permission levels (SharePoint Foundation 2010).

Important:

After you disable a specific permission for a Web application, the permission cannot be granted to any user of a site on the Web application.

If you want to set permissions for specific users or groups in a Web application, you can create a permission policy for the Web application. For more information, see Manage permission policies for a Web application (SharePoint Foundation 2010).

Manage permissions for a Web application

You can configure a set of permissions to control the way users can interact with the sites and content within a Web application.

To manage permissions for a Web application

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators 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 Manage web applications.

  3. On the Web Applications tab of the ribbon, click the Web application for which you want to manage permissions.

  4. In the Security group of the ribbon, click User Permissions.

  5. In the User Permissions for Web Application dialog box, select the check boxes next to the permissions that you want to enable, and clear the check boxes next to those permissions that you want to disable.

    You can select all permissions by selecting the Select All check box. You can clear all permissions by clearing the Select All check box.

  6. Click Save.

See Also

Other Resources

Resource Center: Security and Authentication for SharePoint Foundation 2010


Manage permission policies for a Web application (SharePoint Foundation 2010)

A Web application is composed of an Internet Information Services (IIS) Web site that acts as a logical container for the site collections that you create. Before you can create a site collection, you must first create a Web application.

A Web application can contain as many as 250,000 site collections. Managing permissions for so many site collections can be complicated and error-prone, especially if some users or groups need permissions other than those that apply for the entire Web application.

Permission policies provide a centralized way to configure and manage a set of permissions that applies to only a subset of users or groups in a Web application. For more information, see User permissions and permission levels (SharePoint Foundation 2010).

The differences between specifying user permissions for a Web application and creating a permission policy for a Web application are the users and to which the permissions apply and the scope at which the permissions apply. There is also a difference in the permissions lists where individual permissions are selected.

  • Permissions for a Web application are comprehensive settings that apply to all users and groups for all site collections within a Web application. The permissions list contains only one column, and all permissions are enabled by default. You must disable specific permissions individually. For more information, see Manage permissions for a Web application (SharePoint Foundation 2010).

  • A permission policy level for a Web application contains permissions that enable a subset of users or groups to work with site collections in a specific way. For example, you might want to create a permission policy level for users of a site collection who will be allowed to add, edit, or delete items from a list, open a list, and view items, lists, and pages. However, you might want to prevent the same users from creating or deleting lists, which would require the Manage Lists permission.

    The permissions list contains a Grant All column and a Deny All column. You can either grant or deny all permissions as part of a permission policy level. You can also grant or deny individual permissions. No permissions are enabled by default. If an individual permission is neither granted nor denied, it can be set at the discretion of the site collection administrator or site administrator.

Warning:

A permission policy is different from an information management policy. A permission policy enables centralized management of permissions for a Web application. Information management policies enable you to control who can access information, what they can do with the information, and how long the information should be retained. A permission policy is also different from Group Policy, which provides an infrastructure for centralized configuration management of an operating system and applications that run on an operating system.

In this article:

  1. Manage user permission policy

  2. Manage permission policy for anonymous users

  3. Manage permission policy levels

Manage user permission policy

You can add users to a permission policy, edit the policy settings, and delete users from a permission policy. The following settings can be specified or changed:

  • Zone: If a Web application has multiple zones, you can specify the zone that you want the permission policy to apply to. The default is all zones, which can be specified for Windows users only.

  • Permissions: You can specify Full Control, Full Read, Deny Write, and Deny All permissions, or you can specify a custom permission level.

  • System: This setting enables SharePoint to display SHAREPOINT\System for system-related activity regardless of the Windows user accounts that have been configured for the hosting application pool and the SharePoint farm service account. You may want to specify this setting to prevent unnecessary information disclosure to end users and potential hackers who would be interested in knowing more about how SharePoint is deployed in your enterprise.

Add users to a permission policy

You may want to add users to a permission policy to ensure that all users are accessing content with the same set of permissions.

To add users to a permission policy

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators 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 Manage web applications.

  3. Click to highlight the line for the Web application whose permission policy you want to manage.

  4. In the Policy group of the ribbon, click User Policy.

  5. In the Policy for Web Application dialog box, select the check box next to the user or group that you want to manage, and then click Add Users.

  6. In the Add Users dialog box, in the Zone list, click the zone to which you want the permissions policy to apply.

  7. In the Choose Users section, type the user names, group names, or e-mail addresses that you want to add to the permissions policy. You can also click the applicable icon to check a name or browse for names.

  8. In the Choose Permissions section, select the permissions that you want the users to have.

  9. In the Choose System Settings section, check Account operates as System to specify whether a user account should be displayed as SHAREPOINT\System instead of the actual accounts that perform specific tasks within the SharePoint environment.

  10. Click Finish.

Edit a user permissions policy

You can edit a user permission policy to change the permission level or to specify whether a user account should be displayed as SHAREPOINT\System instead of the actual accounts that perform specific tasks within the SharePoint environment.

To edit a user permissions policy

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators 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 Manage web applications.

  3. Click to highlight the line for the Web application whose permission policy you want to edit.

  4. In the Policy group of the ribbon, click User Policy.

  5. In the Policy for Web Application dialog box, select the check box next to the user or group that you want to manage, and then click Edit Permissions of Selected Users.

  6. In the Edit Users dialog box, in the Permission Policy Levels section, select the permissions that you want the users to have.

  7. In the Choose System Settings section, click Account operates as System to specify whether a user account should be displayed as SHAREPOINT\System instead of the actual accounts that perform specific tasks within the SharePoint environment.

  8. Click Save.

Delete users from a permissions policy

You might want to delete users from a permission policy when they are no longer members of the group or organization to which the policy applies. For example, when an employee leaves the company, that person's user account should be removed from all permissions policies.

To delete users from a permission policy

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators 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 Manage web applications.

  3. Click to highlight the line for the Web application whose permission policy you want to manage.

  4. In the Policy group of the ribbon, click User Policy.

  5. In the Policy for Web Application dialog box, select the check box next to the user or group that you want to manage, click Delete Selected Users, and then click OK.

Manage permission policy for anonymous users

You can enable or disable anonymous access for a Web application. If you enable anonymous access for a Web application, site administrators can then grant or deny anonymous access at the site collection, site, or item level. If anonymous access is disabled for a Web application, no sites within that Web application can be accessed by anonymous users.

The following permission policies can be specified for anonymous users:

  1. None: No policy is specified. This setting gives anonymous users the same default permissions available to NT AUTHORITY\Authenticated Users and All Authenticated Users.

  2. Deny Write: This setting permits anonymous users to read all content within the site collections in a Web application. You can then restrict the Read access by site collection, site, or item.

  3. Deny All: Anonymous users have no access to any part of the Web application.

To manage permission policy for anonymous users

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators 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 Manage web applications.

  3. Click to highlight the line for the Web application whose permission policy you want to manage.

  4. In the Policy group of the ribbon, click Anonymous Policy.

  5. In the Anonymous Access Restrictions dialog box, in the Zone list, click the zone for which you want the policy to apply.

  6. In the Permissions section, select the permission policy that you want anonymous users to have, and then click Save.

Manage permission policy levels

Permission policy levels contain permissions that apply to specific users or groups. You can specify a combination of List, Site, or Personal permissions. You can also specify one of the following levels of site collection permissions:

  • Site Collection Administrator: Has Full Control permission on the entire site collection and can perform any action on any object.

  • Site Collection Auditor: Has Full Read permission on the entire site collection and associated data, such as permissions and configuration information.

If you specify either or both of these permission levels, you cannot specify individual permissions.

Add a permission policy level

You can create a permission policy level to customize a set of permissions for a specific group or organization.

To add a permission policy level

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators 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 Manage web applications.

  3. Click to highlight the line for the Web application whose permission policy you want to manage.

  4. In the Policy group of the ribbon, click Permission Policy.

  5. In the Manage Permission Policy Levels dialog box, click Add Permission Policy Level.

  6. In the Add Permission Policy Level dialog box, in the Name and Description section, type the name and description for the policy that you want to create.

  7. In the Site Collection Permissions section, select the site collection permissions for this policy.

  8. In the Permissions section, select the permissions to grant or deny for this permission level.

    • Select the Grant All check box to include all available permissions in this policy.

    • Select the Deny All check box to deny all available permissions in this policy.

    • Select either the Grant or Deny check boxes to include or exclude individual List, Site, and Personal permissions from this policy.

      Do not click either Grant or Deny if you want to allow site collection or site owners to configure this permission.

  9. Click Save.

Edit a permission policy level

You can edit a permission policy level to add or remove individual permissions, depending on the needs of the user or group that is using the permission policy level.

To edit a permission policy level

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators 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 Manage web applications.

  3. Click to highlight the line for the Web application whose permission policy you want to manage.

  4. In the Policy group of the ribbon, click Permission Policy.

  5. In the Manage Permission Policy Levels dialog box, click the link for the permission policy level you want to edit.

  6. On the Edit Permission Policy Level page, edit the settings, and then click Save.

Delete a permission policy level

You might want to delete a permission policy level if the group or organization for which you created it no longer needs to use it. It is a good practice to review all existing permission policy levels to ensure that they are still required.

To delete a permission policy level

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators 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 Manage web applications.

  3. Click to highlight the line for the Web application whose permission policy you want to manage.

  4. In the Policy group of the ribbon, click Permission Policy.

  5. In the Manage Permission Policy Levels dialog box, select the check box of a permission policy level, click Delete Selected Permission Policy Levels, and then click OK.


Health monitoring (SharePoint Foundation 2010)

The articles in this section are written to meet the requirements of information technology (IT) professionals who are responsible for the planning, design, deployment, and operations of monitoring. These solutions might be in enterprise, corporate, or branch-office environments. The IT professionals who are responsible for monitoring solutions are expected to have an understanding of the technical details that are contained in this section. However, service-level expertise is not needed to understand the enterprise-level discussions and decisions.

The monitoring features in Microsoft SharePoint Foundation 2010 help you to understand how the SharePoint Foundation 2010 system is running, analyze and repair problems, and view metrics for the sites. Monitoring the SharePoint Foundation 2010 environment includes the following tasks:

  1. Configuring the various aspects of monitoring to suit business needs.

  2. Monitoring the environment and resolving any problems that might arise.

  3. Viewing reports and logs of the environment activity.

Monitoring

Included in this section:

  • Monitoring overview (SharePoint Foundation 2010)

  • Configuring monitoring (SharePoint Foundation 2010)

  • Viewing reports and logs (SharePoint Foundation 2010)

  • Solving problems and troubleshooting (SharePoint Foundation 2010)

  • Monitor health and performance of a virtual environment (SharePoint Foundation 2010)


Monitoring overview (SharePoint Foundation 2010)
See Also

The monitoring features in Microsoft SharePoint Foundation 2010 help you to understand how the SharePoint Foundation 2010 system is running, analyze and repair problems, and view metrics for the sites. Monitoring the SharePoint Foundation 2010 environment includes the following tasks:

  1. Configuring the various aspects of monitoring to suit business needs.

  2. Monitoring the environment and resolving any problems that might arise.

  3. Viewing reports and logs of the environment activity.

In this article:

  • Configuring monitoring

  • Monitoring the farm and resolving problems by using SharePoint Health Analyzer

  • Viewing and using reports and logs

Configuring monitoring

SharePoint Foundation 2010 comes installed with default settings for its monitoring features. However, you might want to change some of these settings to better suit the business needs. The aspects that you might change configuration settings for include diagnostic logging and health and usage data collection.

Diagnostic logging

SharePoint Foundation 2010 collects data in the diagnostic log that can be useful in troubleshooting. The default settings are sufficient for most situations, but depending upon the business needs and lifecycle of the farm, you might want to change these settings. For example, if you are deploying a new feature or making large-scale changes to the environment, you might want to change the logging level to either a more verbose level, to capture as much data about the state of the system during the changes, or to a lower level to reduce the size of the log and the resources needed to log the data. For more information and best practices, see Configure diagnostic logging (SharePoint Foundation 2010).

Health and usage data collection

The monitoring features in SharePoint Foundation 2010 use specific timer jobs to perform monitoring tasks and collect monitoring data. The health and usage data might consist of performance counter data, event log data, timer service data, metrics for site collections and sites, search usage data, or various performance aspects of the Web servers. The system uses this data to create health reports, Web Analysis reports, and administrative reports. The system writes usage and health data to the logging folder and to the logging database.

A timer job is a trigger to start to run a specific Windows service for one of the SharePoint 2010 products. It contains a definition of the service to run and specifies how frequently the service should be started. The Windows SharePoint Services Timer v4 service (SPTimerV4) runs timer jobs. Many features in SharePoint 2010 products rely on timer jobs to run services according to a schedule.

You might want to change the schedules that the timer jobs run on to collect data more frequently or less frequently. You might even want to disable jobs that collect data that you are not interested in. You can perform the following tasks on timer jobs:

  • Modify the schedule that the timer job runs on.

  • Run timer jobs immediately.

  • Enable or disable timer jobs.

  • View timer job status. You can view currently scheduled jobs, failed jobs, currently running jobs, and a complete timer job history.

For more information about configuring these settings, see Configure SharePoint Health Analyzer timer jobs (SharePoint Foundation 2010).

Monitoring the farm and resolving problems by using SharePoint Health Analyzer

SharePoint Foundation 2010 includes a new, integrated health analysis tool that is named SharePoint Health Analyzer that enables you to check for potential configuration, performance, and usage problems. SharePoint Health Analyzer runs predefined health rules against servers in the farm. A health rule runs a test and returns a status that tells you the outcome of the test. When any rule fails, the status is written to the Health Reports list in SharePoint Foundation 2010 and to the Windows Event log. The SharePoint Health Analyzer also creates an alert in the Health Analyzer Reports list on the Review problems and solutions page in Central Administration. You can click an alert to view more information about the problem and see steps to resolve the problem. You can also open the rule that raised the alert and change its settings.

Like all SharePoint Foundation 2010 lists, you can edit Health Analyzer Reports list items, create custom views, export the list items into Microsoft Excel, subscribe to the RSS feed for the list, and many other tasks. Each health rule falls in one of the following categories: Security, Performance, Configuration, or Availability.

A health rule can be run on a defined schedule or on an impromptu basis. All health rules are available through Central Administration, on the Monitoring page, for either immediate or scheduled execution.

For more information about the health rules and how to troubleshoot problems in SharePoint Foundation 2010, see SharePoint Health Analyzer rules reference (SharePoint Foundation 2010).

Farm administrators can configure specific health rules to do the following:

  • Enable or disable rules.

  • Configure rules to run on a predefined schedule.

  • Define the scope where the rules run.

  • Receive e-mail alerts when problems are found.

  • Run rules an impromptu basis.

For more information about configuring these settings, see Configure usage and health data collection (SharePoint Foundation 2010).

Viewing and using reports and logs

SharePoint Foundation 2010 can be configured to collect data and create reports about server status and site use. You perform the following using reporting:

  • View administrative reports, such as search reports.

  • Create and review Information Management Policy Usage reports.

  • View health reports that include slowest pages and top active pages.

  • View Web Analytics reports that include Web site traffic reports, search query reports, and customized reports.

See Also

Concepts

Configuring monitoring (SharePoint Foundation 2010)
Solving problems and troubleshooting (SharePoint Foundation 2010)

Other Resources

Resource Center: What's New in SharePoint Foundation 2010


Configuring monitoring (SharePoint Foundation 2010)
See Also

The articles in this section are written to meet the requirements of information technology (IT) professionals who are responsible for the planning, design, deployment, and operations of monitoring. These solutions might be in enterprise, corporate, or branch-office environments. The IT professionals who are responsible for monitoring solutions are expected to have an understanding of the technical details that are contained in this section. However, service-level expertise is not needed to understand the enterprise-level discussions and decisions.

The Microsoft SharePoint Foundation 2010 environment might require that you configure monitoring settings after initial deployment or upgrade. You might need to change the information that is collected for monitoring, when and how often it is collected, or other logging settings that better suit the business and environment requirements.

Configure monitoring

Included in this section

  • Configure diagnostic logging (SharePoint Foundation 2010)

  • Configure usage and health data collection (SharePoint Foundation 2010)

  • Configure SharePoint Health Analyzer rules (SharePoint Foundation 2010)

  • Configure SharePoint Health Analyzer timer jobs (SharePoint Foundation 2010)

See Also

Concepts

Health monitoring (SharePoint Foundation 2010)


Configure SharePoint Health Analyzer timer jobs (SharePoint Foundation 2010)
See Also

The SharePoint Health Analyzer in SharePoint Foundation 2010 uses timer jobs to collect health data and then writes the data to the logging folder and to the Logging database. This data are used in reports to display health of the farm servers. You can reschedule these timer jobs, run them immediately, or enable or disable them.

In this article:

  • Use Central Administration to configure health data collection timer jobs

  • Use Windows PowerShell to configure health data collection timer jobs

Use Central Administration to configure health data collection timer jobs

You can use Central Administration to configure health data collection timer jobs.

To configure health data collection timer jobs by using Central Administration

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

    Note:

    The health data collection timer job settings are farm-wide and cannot be set for individual servers in the farm.

  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, do one of the following:

    • To enable the timer job, click Enable.

    • To disable the timer job, click Disable.

    1. in the Health Logging section, click Health Logging Schedule. A page opens that lists all the timer jobs that collect health data.

    2. On the Job Definitions page, click the timer job that you want to configure.

    3. On the Edit Timer Job page, in the Recurring Schedule section, change the timer job schedule, and then click OK.

Use Windows PowerShell to configure health data collection timer jobs

You can configure the health collection timer job schedule by using Windows PowerShell.

To configure health data timer jobs 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. At the Windows PowerShell command prompt (that is, PS C:\>), type the following command, and then press ENTER:

    Set-SPTimerJob [-Identity <name>] [-Schedule <Schedule string>]

    The value of the Identity parameter specifies the timer job. If you do not use the Identity parameter, all timer jobs are configured. To see a list of all the timer jobs, type the following command, and then press ENTER:

    Get-SPTimerJob | Format-Table -property id,title

    Use the value of the Schedule parameter to specify the schedule, where <Schedule string> is one of the following:

    • every <1-60> seconds

    • every <1-60> minutes at <1-60>

    • every <1-60> minutes between <1-60> and <1-60>

    • hourly between <1-59> minutes past the hour and <1-59> minutes past the hour

    • daily between starting from <hh:mm:ss> and starting no later than <hh:mm:ss>

    • weekly between starting on <day of the week hh:mm:ss> and starting no later than <day of the week hh:mm:ss>

    • monthly between starting on < day number hh:mm:ss> and starting no later than < day number hh:mm:ss>

    • monthly by <hh:mm:ss> on <week number> <day of week>

    To see examples of timer job schedules, type the following command, and then press ENTER:

    Get-SPTimerJob | Format-Table -property id,title,schedule

    For more information, see Get-SPTimerJob and Set-SPTimerJob.

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.

See Also

Concepts

Monitoring overview (SharePoint Foundation 2010)


Configure SharePoint Health Analyzer rules (SharePoint Foundation 2010)
See Also

This topic describes how to configure SharePoint Health Analyzer rules.

Note:

You can use only Central Administration to configure SharePoint Health Analyzer rules.

Configuring health rules

You can accept the default settings for each health rule, or you can change settings for a health rule by using Central Administration.

To configure health rules by using Central Administration

  1. Verify that the user account that is 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, under Health Analyzer, click Review rule definitions.

  4. On the Health Rule Definitions page, click the rule that you want to configure.

  5. In the Health Analyzer Rule Definitions dialog, click Edit Item.

  6. Edit one or more rule fields, and then click Save.

    To leave the rule unchanged, either dismiss the dialog or click Cancel.

Each health rule has configurable fields, which are described in the following table.

Configurable Field Possible Values

Title

The name of the health rule. You can rename a health rule to clarify its functionality. The title is the name of the rule as it appears in the Health Rule Definitions list In Central Administration.

Changing the title does not affect how the rule runs.

Scope

You can set a health rule to run against all servers or any server. If set to any server, the rule will run on the first available server that the system encounters.

Schedule

You can schedule a health rule to run hourly, daily, weekly, monthly, or on demand only.

Enabled

You can use this to enable or disable a health rule.

Repair Automatically

You can define whether a health rule automatically tries to recover from any error conditions that it finds. If this option is selected, SharePoint Foundation 2010 will repair errors as soon as they are found, as defined by the rule.

Note:

If no repair is specified by the rule, the system does not attempt to repair the problem.

Version

Version history enables you to track the changes performed on each rule. The version number is updated every time the rule is saved. The version number does not affect how the rule behaves.

Each health rule has read-only fields, which are described in the following table.

Read-Only Field | Meaning
Version | This current version number of the rule.
Created at | The date and time that the rule was originally created and the user account that created the rule.
Last modified at | The date and time that the rule was last changed and the user account that created the rule.

See Also

Concepts

SharePoint Health Analyzer rules reference (SharePoint Foundation 2010)


Viewing reports and logs (SharePoint Foundation 2010)
See Also

The articles in this section are written to meet the requirements of information technology (IT) professionals who are responsible for the planning, design, deployment, and operations of monitoring. These solutions might be in enterprise, corporate, or branch-office environments. The IT professionals who are responsible for monitoring solutions are expected to have an understanding of the technical details that are contained in this section. However, service-level expertise is not needed to understand the enterprise-level discussions and decisions.

You can monitor the Microsoft SharePoint Foundation 2010 environment by viewing reports of the health of the system and sites and diagnostic logs that provide detailed information about any problems that might arise.

Included in this section

  • View health reports (SharePoint Foundation 2010)

  • View diagnostic logs (SharePoint Foundation 2010)

  • View timer job status (SharePoint Foundation 2010)

  • Understanding the Logging Database (SharePoint Foundation 2010)

See Also

Concepts

Health monitoring (SharePoint Foundation 2010)


View health reports (SharePoint Foundation 2010)
See Also

This article provides information about how to view health reports in.

Health reports are pre-built reports in Microsoft SharePoint Foundation 2010 that use usage data to analyze various aspects of sites and site collections such as slowest pages and top active users.

Note:

You cannot use Windows PowerShell to view health report data.

View health reports by using Central Administration

You can view health reports only by using Central Administration.

To view health reports by using Central Administration

  1. Log on as a member of Farm Administrators SharePoint group.

  2. In Central Administration, on the Home page, click Monitoring.

  3. On the Monitoring page, in the Reporting section, click View health reports.

  4. On the report page, in the Quick Launch, click the name of the report to view the report.

  5. To view report data, select the data criteria, and then click Go.

  6. To sort data rows, click the column name.

See Also

Concepts

Monitoring overview (SharePoint Foundation 2010)


View diagnostic logs (SharePoint Foundation 2010)
See Also

You can use data from the Universal Logging System (ULS) logs in Microsoft SharePoint Foundation 2010 to troubleshoot problems in the farm. The ULS log can collect data at varying levels depending upon the logging settings. You can use Windows PowerShell to filter the data, display it in various ways, and output the data to a data grid with which you can filter, sort, group, and export data to Microsoft Excel 2010.

For more information, see Configure diagnostic logging (SharePoint Foundation 2010).

View and filter log events by using Windows PowerShell

You can use Windows PowerShell to view and filter log events. You cannot view or filter log events by using Central Administration.

To view and filter log events 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. At the Windows PowerShell command prompt, type one of the following commands:

    • All trace events:

      Get-SPLogEvent

    • By level:

      Get-SPLogEvent | Where-Object {$_.Level -eq [Information | Warning | Error | Critical | Verbose | Unexpected | Monitorable | High | Medium]}

    • By area:

      Get-SPLogEvent | Where-Object {$_.Area -eq <Area>}

      Where <Area> is the value of the Area property.

    • By category:

      Get-SPLogEvent | Where-Object {$_.Category -eq <Category>

      Where <Category > is the value of the Category property.

    • By event ID:

      Get-SPLogEvent | Where-Object {$_.EventID -eq <EventID>}

      Where <EventID> is the value of the EventID property.

    • By message text:

      Get-SPLogEvent | Where-Object {$_.Message -like "*<string>*"}

      Where <string> is the string found in the event message.

    • By process:

      Get-SPLogEvent | Where-Object {$_.Process -like "*<Process>*"}

      Where <Process > is the value of the Process property.

    Tip:

    By default, the command retrieves data from the default ULS log folder. To view and filter trace events that are on shared folder on a network, use the Directory parameter of the Get-SPLogEvent cmdlet.

    To view more details about each trace event, use Format-List at the end of the command. For example, Get-SPLogEvent | Where-Object {$_.Area -eq "SharePoint Foundation"} | Format-List.

For more information, see Get-SPLogEvent.

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.

View and export diagnostic logs by using the Windows PowerShell Out-GridView cmdlet

Windows PowerShell provides a powerful and easy-to-use feature that displays tabular data resulting from Windows PowerShell commands in a filterable, searchable data grid in a separate window. You can use this grid to view log events and to perform the following operations on the data:

  • Sort the data by any column.

  • View the data in groups.

  • Filter the data by Level, Area, Category, Message, Event ID, or Timestamp.

  • Search the data for any string.

  • Export raw or sorted or filtered data to a spreadsheet.

Note:

The Out-GridView cmdlet cannot be used with cmdlets that use the Format verb. The Out-GridView cmdlet receives objects whereas the cmdlets that use the Format verb return only formatted text. However, you can pre-filter the data sent to the grid view by using the Where-Object pipeline — for example, Get-SPLogEvent | Where-Object {$_.Area -eq "SharePoint Foundation"} | Out-GridView.

If the grid is displaying more than several hundred rows, it might run slowly, especially if performing complex filtering operations. For faster performance, export the data to Excel 2010.

For more information, see Out-GridView (http://go.microsoft.com/fwlink/p/?LinkId=181248) and Out-GridView Revisited (http://go.microsoft.com/fwlink/p/?LinkId=181249).

To view and filter diagnostic logs 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. At the Windows PowerShell command prompt, type the following command:

    Get-SPLogEvent | Out-GridView

  6. To view the results in groups:

    1. Right-click the column header, click Show In Groups, and then click the column header for the value by which you want to group the results.

    2. To expand or collapse a specific group, click the arrow next to the group name.

    3. To remove grouping, right-click the column header, and then click Show In Groups.

  7. To sort columns, click the column header.

  8. To search for a specific string, type the string in the Search box. Search is performed over all columns and rows. To clear the search, click Clear All.

  9. To filter data on only one criterion, type the following in the Search box: <property name>:<value>. For example, to search for all log entries raised by SharePoint Foundation 2010, type the following: Area:SharePoint Foundation. To clear the filter, click Clear All.

  10. To filter data by using more than one criterion or by using criteria with "contains, begins with, ends with" or other methods:

    1. Click Query.

    2. Click Add.

    3. Click the check box for the properties that you want to filter on, and then click OK.

    4. Click contains to change to a different filter method. The methods available are contains, does not contain, starts with, equals, does not equal, ends with, is empty, and is not empty.

    5. Type a value in the text box.

    6. Repeat steps "e" and "f" for each property you selected in step "c".

    7. When all the filtering criteria are specified, click the search button to filter the data grid.

    8. To clear a specific filter, click the X button.

    9. To clear all the filters, collapse the query view and click the Clear All button.

To export grid data to a spreadsheet

  1. Select the rows that you want to export. You can select multiple rows by using SHIFT+DRAG to select a block of rows, CTRL+CLICK to select specific rows, or CTRL+A to select all rows.

    You can also filter and sort the results before you copy the data into a spreadsheet. When you sort or filter data, only the resulting viewable data is copied over.

  2. Copy the selected rows by using CTRL+C.

  3. Open the spreadsheet workbook page, and then paste the copied rows into it by using CTRL+V.

See Also

Concepts

Configure diagnostic logging (SharePoint Foundation 2010)
Monitoring overview (SharePoint Foundation 2010)


View timer job status (SharePoint Foundation 2010)
See Also

A timer job runs a specific Windows service for Microsoft SharePoint Foundation 2010. The timer job contains a definition of the service to run and specifies how frequently the service is started. The Windows SharePoint Services Timer v4 service (SPTimerV4) runs timer jobs. Many features inSharePoint Foundation 2010 rely on timer jobs to run services according to a schedule. You can view the status of timer jobs that have been run by using the Central Administration Web site or Windows PowerShell.

In this article:

  • View timer job status by using Central Administration

  • View timer job status by using Windows PowerShell

View timer job status by using Central Administration

You can view timer job status by using Central Administration.

To view timer job status 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 Timer Jobs section, click Check job status.

  4. Timer job status is divided into three groups: Scheduled, Running, and History. To page through the timer job status data rows, click the paging arrows at the bottom of these groups.

  5. To view the timer job status for a specific group, click the title of the group. Alternatively, in the Quick Launch, click Scheduled Jobs, Running Jobs, or Job History.

View timer job status by using Windows PowerShell

You can view timer job status by using Windows PowerShell.

To view timer job status by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. On the Start menu, click Administrative Tools.

  3. Click SharePoint 2010 Management Shell.

  4. At the Windows PowerShell command prompt (that is, PS C:\>), type the following command, and then press ENTER:

    Get-SPTimerJob [-Identity <Timer job name…>] | Format-Table -Property DisplayName,Id,LastRunTime,Status

    You can use the value of the Identity parameter to specify a timer job. If you do not use the Identity parameter, all timer jobs are returned.

    To view the history of a specific timer job, type the following command, and then press ENTER:

    (Get-SPTimerJob [-Identity <Timer job name…>]).HistoryEntries | Format-Table -Property Status,StartTime,EndTime,ErrorMessage

For more information, see Get-SPTimerJob.

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.

See Also

Concepts

Monitoring overview (SharePoint Foundation 2010)


Understanding the Logging Database (SharePoint Foundation 2010)

Published: January 10, 2012

This article introduces the Microsoft SharePoint 2010 Products logging database and describes how to view monitoring information inside SharePoint Foundation 2010 logging database (by default, named WSS_Logging). This article also describes how to use custom views in the logging database, and how to export monitoring information into Microsoft Excel.

In this article:

  • Introduction to the logging database

  • Pre-defined SQL views in the logging database

  • Custom SQL views in the logging database

Introduction to the logging database

To monitor SharePoint Foundation 2010 servers and the services that run on the servers, you can directly access various logs such as the Windows Server event logs, SharePoint Universal Logging System (ULS) logs (also known as trace logs), or usage data logs. You can also go to SharePoint Foundation 2010 Central Administration to review various reports. Health analyzer reports contain SharePoint Foundation 2010 rules for servers or services. Administration (diagnostics) reports contain search-related information. Web Analytics reports contain web analytics metrics. For more information about reports, see Viewing reports and logs (SharePoint Foundation 2010).

All the monitoring methods mentioned previously have limits. For example, Windows Server event logs, SharePoint ULS logs, and usage data logs are not stored in one single place. You have to go to different places to find related logs. Similarly, although reports from Central Administration contain the most commonly used metrics and monitoring information, if you want to add more monitoring information to those reports, you cannot do it because these reports are pre-defined and cannot be modified.

You can increase monitoring efficiency by using the logging database in SharePoint Foundation 2010. The logging database is a farm-wide repository of SharePoint Foundation 2010 monitoring information from every server in the farm. The logging database provides the option to view and customize various monitoring information in one place. Moreover, the logging database is the only SharePoint Foundation 2010 database for which you can customize reports by directly modifying the database.

Note:

For more information about SharePoint Foundation 2010 databases, see Database types and descriptions (SharePoint Foundation 2010).

Note:

The default name of the database is WSS_Logging. You can change the default name and the SharePoint database server location by using Windows PowerShell. For more information about the logging database name and database server location, see Configure usage and health data collection (SharePoint Foundation 2010).

A single place that stores various monitoring information helps you efficiently monitor SharePoint Foundation 2010 servers and services. More importantly, you can create your own reports for unique monitoring, reporting and troubleshooting requirement based on tables inside the logging database. This article describes how to create reports using existing tables and views. You might want to write your own providers to create new tables. For more information about writing new providers to create new tables and views inside the logging database, see SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=224502).

Note:

A SQL view is a virtual table. One difference between a table and a SQL view is that you can modify the data inside a table but you cannot modify the data inside a SQL view.

You use SharePoint Foundation 2010 Central Administration to configure logs imported into the logging database. For more information about how to configure log categories, log levels, and trace (ULS) log path, see Configure diagnostic logging (SharePoint Foundation 2010). For more information about how to enable what is written into the logging database, see Configure usage and health data collection (SharePoint Foundation 2010). For more information about how to specify the logging database server, name and database authentication information, the events to be written to the logging database, and the frequency that logs are written to the logging database (that is, timer jobs related to usage database importing), see Configure SharePoint Health Analyzer timer jobs (SharePoint Foundation 2010).

The procedures in this article use SQL Server Management Studio to access the logging database. Management Studio is a component of Microsoft SQL Server 2008.

Note:

To access the logging database, you have to have either Windows authentication (recommended) or SQL authentication. The database authentication information is configured in SharePoint Foundation 2010 Central Administration. For more information about authentication methods, see Configure usage and health data collection (SharePoint Foundation 2010).

Pre-defined SQL views in the logging database

This section describes partition tables and SQL views inside the SharePoint Foundation 2010 logging database, and includes the following three procedures:

  • To access the logging database by using SQL Server Management Studio

  • To view the logging information from default views

  • To export to and view the logging data using Excel

The logging database uses a separate partition table for the daily data for each category. For example, the timer job usage data for the first day is written to the dbo.TimerJobUsage_Partition0 table and the data for 32 days later is written to the dbo.TimerJobUsageUsage_Partition31 table. Logs within one day are written to one partition table. That means, for each log category, each partition table stores one particular day's logs.

Note:

The mapping between one partition table and the exact date depends on the logging database retention period and the starting date to write logs into the logging database. You can get the mapping by observing time information inside each table. For example, if the retention period is 14 days and today's logs are written to partition table 2, tomorrow's logs will be written into partition table 3 and so on. After 14 days, all logs are deleted and new logs are written to these partition tables starting from partition table 0.

You can use the pre-defined SQL views in Management Studio to view all monitoring information in one place. Each pre-defined view collects the data from all 32 partition tables for the specific log category. For example, you can view the monitoring information in 32 tables from dbo.TimerJobUsage_Partition0 to dbo.TimerJobUsageUsage_Partition31.

To access the pre-defined views, you must access the SharePoint Foundation 2010 logging database. Then from the logging database, you view the monitoring information.

To access the logging database by using Management Studio

  1. On the taskbar, click Start, point to All Programs, click Microsoft SQL Server 2008 or the latest Microsoft SQL Server version that is installed, and then click SQL Server Management Studio.

    Note:

    If you do not have Management Studio on your server, reinstall SQL Server 2008 and add the Management Studio component. For more information, see SQL Server Install.

  2. In the Connect to Server dialog box, choose Database Engine. Then specify the server name, for example, ServerName\SharePoint. Select the authentication type (Windows Authentication or SQL Server Authentication) that you configured through SharePoint Foundation 2010 Central Administration. If it is SQL Server Authentication, specify the credentials for the database administrator. After the information is set, click Connect.

  3. Switch to the Object Explorer view by clicking View, and then clicking Object Explorer. Expand Databases to see the logging database that has default name WSS_Logging or a name that you configured from SharePoint Foundation 2010 Central Administration.

  4. Optionally, expand the logging database to see tables and views.

To view the logging information from default views

  1. In Management Studio, go to the logging database node by using the previous procedure.

  2. Expand the Views node of the database to see the default views. Right-click the view, for example dbo.RequestUsage, and choose Select Top 1000 Rows.

    The operation Select Top 1000 Rows is the following T-SQL query script:

    Copy Code
    /****** Script for SelectTopNRows command from SSMS  ******/
SELECT TOP 1000 [PartitionId]
      ,[RowId]
      ,[LogTime]
      ,[MachineName]
      ,[FarmId]
      ,[SiteSubscriptionId]
      ,[UserLogin]
      ,[CorrelationId]
      ,[WebApplicationId]
      ,[ServerUrl]
      ,[SiteId]
      ,[SiteUrl]
      ,[WebId]
      ,[WebUrl]
      ,[DocumentPath]
      ,[ContentTypeId]
      ,[QueryString]
      ,[BytesConsumed]
      ,[HttpStatus]
      ,[SessionId]
      ,[ReferrerUrl]
      ,[ReferrerQueryString]
      ,[Browser]
      ,[UserAgent]
      ,[UserAddress]
      ,[RequestCount]
      ,[QueryCount]
      ,[QueryDurationSum]
      ,[ServiceCallCount]
      ,[ServiceCallDurationSum]
      ,[OperationCount]
      ,[Duration]
      ,[RequestType]
      ,[Title]
      ,[RowCreatedTime]
  FROM [WSS_Logging].[dbo].[RequestUsage]

    The top 1000 rows of the table category Request Usage appear in the result window.

  3. You can modify the T-SQL query in the SQL editor window. For example, if there are more than 1000 rows in the tables, you might want to view the top 5000 rows. To do that, change the script by replacing "SELECT TOP 1000" with "SELECT TOP 5000", and then click Execute.

If you want to view logs by using tools other than Management Studio, you can extract the monitoring information from the views and save as a text file or a CSV file. In the following procedure, Microsoft Excel is used as an example.

To export and view the logging data by using Excel

  1. In Management Studio, go to the logging database node.

  2. Expand the Views node, right-click the view from which you want to extract data, and then click Select Top 1000 Rows.

  3. In the result window, right-click, and then click Select All. Then right-click and then click Save Results As….

  4. In the Save Grid Results window, specify the folder in which you want to save the file, specify the Save as type as CSV(Comma delimited), and then specify an appropriate file name.

  5. Open the CSV file by double-clicking it in Excel.

Custom SQL views in the logging database

The logging database in SharePoint Foundation 2010 enables you to create custom reports in two ways. You can generate new views by combining related information from existing tables, or you can write providers to generate new partition tables inside the logging database. The examples in this section only show the first way.

In usage tables and the ULSTraceLog tables, the CorrelationId is an important parameter for troubleshooting. This is because every error message contains a unique CorrelationId. CorrelationId is a GUID that links all the related information with respect to a request. The following procedure shows how to make a custom view that links multiple log categories by using the CorrelationId.

To create a custom SQL view that uses existing tables

  1. In Management Studio, go to the logging database node.

  2. In the logging database, expand the Views node. Choose one of the views for which you want to collect information. Right-click the view, and then click New View….

  3. In the Add Table window, choose the tables to add. For example, if you want to get information about feature usage site requests for a single day, you can add dbo.FeatureUsage_Partion1 and dbo.RequestUsage_Partion1.

    The T-SQL query automatically inner joins the unique key PartionId in these two tables.

    Copy Code
    SELECT
FROM   dbo.FeatureUsage_Partition1 INNER JOIN
    dbo.RequestUsage_Partition1 ON dbo.FeatureUsage_Partition1.PartitionId = dbo.RequestUsage_Partition1.PartitionId

  4. Disjoin the two tables by right-clicking the link between these tables and selecting removing.

  5. To inner join the two tables using CorrelationId, click the CorrelationId column in one table and move the cursor to the CorrelationId column in another table. Or you can modify the SQL query directly from the Query Editor.

    Copy Code
    SELECT
FROM   dbo.FeatureUsage_Partition1 INNER JOIN
    dbo.RequestUsage_Partition1 ON dbo.FeatureUsage_Partition1.CorrelationId = dbo.RequestUsage_Partition1.CorrelationId

  6. Choose the columns in each table that you want to show in the new view.

  7. Right-click and choose Execute SQL. The results appear in the result window.


Solving problems and troubleshooting (SharePoint Foundation 2010)
See Also

The articles in this section are written to meet the requirements of information technology (IT) professionals who are responsible for the planning, design, deployment, and operations of monitoring. These solutions might be in enterprise, corporate, or branch-office environments. The IT professionals who are responsible for monitoring solutions are expected to have an understanding of the technical details that are contained in this section. However, service-level expertise is not needed to understand the enterprise-level discussions and decisions.

Microsoft SharePoint Foundation 2010 includes a new tool named SharePoint Health Analyzer that enables you to diagnose and resolve configuration, performance, and usage problems. SharePoint Health Analyzer runs predefined health rules against servers in the farm. A health rule runs a test and returns an alert that tells you the outcome of the test. You can use Central Administration to view alerts and resolve problems.

In this section:

  • Viewing and resolving SharePoint Health Analyzer alerts (SharePoint Foundation 2010) - This article describes how can use SharePoint Health Analyzer to view alerts and resolve problems.

  • Update alerts by using Windows PowerShell (SharePoint Foundation 2010) - This article explains how to add an advanced function that allows you to update alerts when a Web application's URL changes.

See Also

Concepts

Health monitoring (SharePoint Foundation 2010)


Viewing and resolving SharePoint Health Analyzer alerts (SharePoint Foundation 2010)
See Also

Microsoft SharePoint Foundation 2010 includes a new tool named SharePoint Health Analyzer that enables you to diagnose and resolve configuration, performance, and usage problems. SharePoint Health Analyzer runs predefined health rules against servers in the farm. A health rule runs a test and returns an alert that tells you the outcome of the test. You can use Central Administration to view alerts and resolve problems.

Viewing and resolving SharePoint Health Analyzer alerts

You can use Central Administration to view and resolve health alerts.

To view and resolve SharePoint Health Analyzer alerts by using Central Administration

  1. Verify that the user account that is 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 Health Analyzer section, click Review problems and solutions.

  4. On the Review problems and solutions page, click the alert that you want to view and resolve.

  5. To resolve the problem, follow the guidance given in the Remedy section of the Review problems and solutions dialog. Keep the dialog open so you can run the rule again to confirm the resolution.

  6. After following the guidance given in the Remedy section, in the Review problems and solutions dialog for the alert, click Reanalyze Now to confirm the resolution. If the problem is resolved, the alert status changes to 4-Success.

For more information about the health rules and how to troubleshoot problems in SharePoint Foundation 2010, see SharePoint Health Analyzer rules reference (SharePoint Foundation 2010).

Health alert fields

The fields in alerts are described in the following table.

Field | Meaning
Title | The name of the alert. By default, this is the name of the health rule that generated the alert.
Severity | Possible values are the following: 1-Error, 2-Warning, 3-Information, 4-Success, 0-Rule Execution Failure.
Category | Pre-set values are the following: Configuration, Security, Performance, and Availability. You can also type a value in the Specify your own value box.
Explanation | A detailed explanation of the cause of the alert. This explanation might include exception or trace information.
Remedy | Details about how to resolve the problem that caused the alert. This might include precise steps or a link to more information.
Failing Servers | The server that the failure occurred on.
Failing Services | The service where the failure occurred.
Rule Settings | A link to the health rule that generated the alert. The information in the rule might be useful in analyzing the problem, or you might want to change the schedule or disable the rule.
Version [Read-Only] | This number is automatically incremented every time the alert is altered.
Created (time) [Read-Only] | The date and time that the alert was generated and the domain or local security account under which the alert was generated.
Last modified (time) [Read-Only] | The date and time that the alert was last changed and the domain or local security account under which the alert was changed. This information might be useful in tracking changes to the alert, such as during resolution of the problem.

See Also

Concepts

SharePoint Health Analyzer rules reference (SharePoint Foundation 2010)


Update alerts by using Windows PowerShell (SharePoint Foundation 2010)
See Also

Updated: March 12, 2013

This article describes Invoke-AlertFixup, a Windows PowerShell advanced function used to update the Uniform Resource Locator (URL) of a Web application used in alert e-mails after a Web application address changes. It replaces the Stsadm updatealert operation that was available in the April 2008 release of the SharePoint Administration Toolkit. The advanced function is loaded by running a script of the same name.

For more information about advanced functions, see about_Functions_Advanced (http://go.microsoft.com/fwlink/p/?LinkId=196720).

To update URLs by using Windows PowerShell

  1. Verify that you meet the following minimum requirements:

    • See Add-SPShellAdmin.

    • You must read about_Execution_Policies (http://go.microsoft.com/fwlink/p/?LinkId=193050).

  2. Copy the code from the Script Center (http://go.microsoft.com/fwlink/p/?LinkId=196687), and then paste it into a text editor, such as Notepad.

  3. Save the file, naming it Invoke-AlertFixup.ps1.

    Note:

    You must use the provided name or the script will fail, and you must save the file as an ANSI-encoded text file.

  4. On the Start menu, click All Programs.

  5. Click Microsoft SharePoint 2010 Products.

  6. Click SharePoint 2010 Management Shell.

  7. Change to the directory where you saved the file.

  8. At the Windows PowerShell command prompt, dot source the Invoke-AlertFixup.ps1 file by typing the following:

    Copy Code
    . ./Invoke-AlertFixup.ps1
    Note:

    To dot source a script, type a dot (.) and a space before the script path. The dot sourcing feature lets you run a script in the current scope instead of in the script scope. When you run a script that is dot sourced, the commands in the script run as though you had typed them at the command prompt. For more information, see about_Scripts (http://go.microsoft.com/fwlink/p/?LinkId=239611).

    This script contains the Invoke-AlertFixup advanced function. Once the script is loaded to memory for the current Windows PowerShell session, Invoke-AlertFixup can be used like a Windows PowerShell cmdlet, for example:

    Copy Code
    Invoke-AlertFixup -site <SiteCollURL> -oldurl <OldURL>

    Where:

    • <SiteCollURL> is the Site Collection URL seen in the ImmedSubscriptions table of the content database.

    • <OldURL> is the old URL of the site.

    Note:

    In order for Invoke-AlertFixup to work correctly, the URLs specified with the site and oldurl parameters must reside in the same site collection. This is necessary to allow proper updating of alerts in a specific zone. Alerts for each zone must be updated individually using the proper new zone URL to that of the original (old) zone URL.

  9. To display all alerts that would be updated using the Invoke-AlertFixup command, at the Windows PowerShell command prompt type the following syntax:

    Copy Code
    Invoke-AlertFixup -site <SiteCollURL> -Oldurl <OldURL> -whatif

    Where:

    • <SiteCollURL> is the Site Collection URL seen in the ImmedSubscriptions table of the content database.

    • <OldURL> is the old URL of the site.

Example

Your company has a Web application that is configured with three zones, as shown in the following table.

Coho Winery zone mapping

Description | URL | Zone
Intranet | http://cohowinery | Default
Extranet | http://extranet.cohowinery.com | Extranet
Vendor | http://vendors.cohowinery.com | Custom

Your company merges with Coho Vineyard and changes its name to Coho Winery and Vineyard. Management wants to change the Intranet and Extranet zones to reflect the new name change. The following table displays the new zone configuration.

Coho Winery and Vineyard zone mapping

Description | URL | Zone
Intranet | http://cohovineyardandwinery | Default
Extranet | http://extranet.cohovineyardandwinery.com | Extranet

After the name of the Web application is changed and the alternate access mappings are updated, Invoke-AlertFixup should be run to update the e-mail alerts associated with the intranet and extranet sites, as follows:

Copy Code
Invoke-AlertFixup -site http://cohovineyardandwinery -oldurl http://cohowinery
Copy Code
Invoke-AlertFixup -site http://extranet.cohovineyardandwinery.com -oldurl http://extranet.cohowinery.com
Note:

No changes are made regarding the vendor site, as Coho Winery has decided not to change the name of the vendor portal.

For additional information about extranet scenarios, see Design sample: Corporate deployment (SharePoint Server 2010).

See Also

Other Resources

Running Windows PowerShell Scripts
Resource Center: Windows PowerShell for SharePoint Server 2010

Change History

Date | Description
March 12, 2013 | Updated the parameters of the Invoke-AlertFixup command.
July 15, 2010 | Initial publication


Monitor health and performance of a virtual environment (SharePoint Foundation 2010)

This article describes the monitoring required for a virtual environment. It is necessary to monitor the virtual machines in the farm as well as the virtualization servers to ensure that the health and performance levels meet operational standards and the service level agreements that are in place.

Monitor SharePoint health and performance

The following articles provide information about monitoring Microsoft SharePoint Foundation 2010 health and performance:

  • Health monitoring (SharePoint Foundation 2010)

Monitor Hyper-V health and performance

You can monitor Windows Server 2008 Hyper-V technology health and server performance using Microsoft products or by using Windows PowerShell scripts. The following products can be used to monitor a virtual environment.

Microsoft System Center Operations Manager 2007 R2 provides an end-to-end monitoring and reporting system that you can use to monitor Microsoft SharePoint Foundation 2010 and supported versions of Windows Server 2008 and SQL Server. For more information, see System Center Operations Manager (http://go.microsoft.com/fwlink/p/?LinkId=187743).

If you are using System Center Operations Manager we recommend that you obtain and install the following management packs as appropriate for your environment:

  • Windows Server Hyper-V Management Pack for System Center Operations Manager 2007 (http://go.microsoft.com/fwlink/p/?LinkId=187744)

  • Microsoft Windows Server Failover Clustering Management Pack for Operations Manager 2007 (http://go.microsoft.com/fwlink/p/?LinkId=147087)

  • System Center Virtual Machine Manager 2008 Management Pack for System Center Operations Manager 2007 (http://go.microsoft.com/fwlink/p/?LinkId=156500)

Microsoft System Center Virtual Machine Manager 2008 R (SCVMM) is a robust tool for managing all aspects of a Hyper-V virtual environment. In addition to virtual provisioning, the Performance and Resource Optimization (PRO) enables the dynamic management of virtual resources though Management Packs that are PRO enabled. SCVMM can use the monitoring capabilities of System Center Operations Manager 2007, which enables administrators to establish remedial actions for VMM to execute if poor performance or pending hardware failures are identified in hardware, operating systems, or applications. You can also obtain the current health and state of virtual machines and get a real time view of CPU, memory, and storage consumption on the virtualization servers.

Note:

System Center Virtual Machine Manager fully supports Windows PowerShell scripting.

Health and performance resources

Numerous articles and blog posts provide in-depth guidance to monitoring Hyper-V health and performance. We recommend that you consult the following resources:

  • Hyper-V performance FAQ R2 (http://go.microsoft.com/fwlink/p/?LinkId=187745)

  • Monitoring Hyper-V performance (http://go.microsoft.com/fwlink/p/?LinkId=187746)

  • Hyper-V performance comparison: Microsoft Windows Server 2008 SP2 and R2 with Intel Xeon processor X5570- and E5450-based servers (http://go.microsoft.com/fwlink/p/?LinkId=187747)

  • Windows Server 2008 R2 Virtual Hard Disk (VHD) Performance Paper (http://go.microsoft.com/fwlink/p/?LinkId=187749)

  • Windows Server Performance Team Blog: Increase VMBus buffer sizes to increase network throughput to guest VMs (http://go.microsoft.com/fwlink/p/?LinkId=187750)

  • Microsoft Hyper-V 2008 R2 IDE vs. SCSI Performance (http://go.microsoft.com/fwlink/p/?LinkId=187751)

  • Benchmarking Hyper-V on Windows Server 2008 R2 x64 (http://go.microsoft.com/fwlink/p/?LinkId=187752)

  • Henk's tech blog: Archive for the 'SQL 2008 R2' Category (http://go.microsoft.com/fwlink/p/?LinkId=187753)


Manage farm administration settings (SharePoint Foundation 2010)

After the initial installation of Microsoft SharePoint Foundation 2010, you can configure the default farm settings. The configuration of these settings is optional, but some key features are not available unless these settings are configured.

In this section:

  • Configure diagnostic logging (SharePoint Foundation 2010)

    This article describes how to configure diagnostic loggings settings after initial deployment or upgrade and lists guidelines that can help you implement best practices for the specific environment.

  • E-mail integration (SharePoint Foundation 2010)

    This article describes how to configure incoming and outgoing e-mail settings.

  • Configure a mobile account (SharePoint Foundation 2010)

    This article discusses how to configure and manage a mobile account to let users subscribe to alerts that are sent by using the Short Message Service (SMS) protocol.

  • Change the Central Administration Web site port number (SharePoint Foundation 2010)

    During the installation of Microsoft SharePoint Foundation 2010, the Central Administration Web site is established on a randomly-assigned TCP port, or on a port that you select when you create the farm. This article describes how to change the port number for the Central Administration Web site.


Change the Central Administration Web site port number (SharePoint Foundation 2010)
See Also

During the installation of Microsoft SharePoint Foundation 2010, the Central Administration Web site is established on a randomly-assigned TCP port, or on a port that you select when you create the farm. The security policies of your organization might require you to change this port number.

This procedure describes how to change the Central Administration Web site port number by using a Windows PowerShell 2.0 cmdlet. You cannot use the user interface to perform this task.

To change the Central Administration Web site port number by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. Additionally, verify that you are a member of the Farm Administrators SharePoint group.

  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:

    Copy Code
    Set-SPCentralAdministration -Port <PortNumber>

    Where <PortNumber> is the port number that you want to use. You are prompted for confirmation to change the port number unless you use the Confirm:$false parameter with the command.

    Note:

    The Set-SPCentralAdministration cmdlet blocks the following ports:

    • Lower than 1023

    • Higher than 32767

    • 443 (SSL)

    If you must use a blocked port, you can do so by using the Stsadm command stsadm -o setadminport. For more information, see Setadminport: Stsadm operation (Windows SharePoint Services).

For more information about the Windows PowerShell cmdlet, see Set-SPCentralAdministration.

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.

See Also

Reference

New-SPCentralAdministration


Farm topology management (SharePoint Foundation 2010)

This chapter describes how to add servers to a farm, how to rename servers, and how to remove servers from a farm.

Topology examples are available that can be used as a template for building out a farm. For more information, see the Topologies for SharePoint Server 2010 model in the Technical diagrams (SharePoint Foundation 2010) article.

The following tasks are part of managing the topology of a farm:

  1. Add a Web or application server to the farm (SharePoint Foundation 2010)

    This article describes how to add Web servers to a farm.

  2. Add a database server to an existing farm (SharePoint Foundation 2010)

    This article describes how to add a database server to a farm.

  3. Rename a stand-alone server (SharePoint Foundation 2010)

    This article describes how to rename a stand-alone server.

  4. Remove a server from the farm (SharePoint Foundation 2010)

    This article describes how to remove a server from a farm.


Add a Web or application server to the farm (SharePoint Foundation 2010)

This article describes how to add a server to an existing Microsoft SharePoint Foundation 2010 farm so the server can later be configured for use as a front-end Web server or as an application server. The procedures in this article apply to a SharePoint Foundation 2010 farm that consists of at least two tiers; they are not intended to be used for converting a single server deployment to a multiple server farm.

In this article:

  • Preparation

  • Install prerequisite software

  • Install SharePoint software

  • Add the server to the farm

  • Configure the new server

Preparation

Planning and preparation is required before you add a server to the farm. There are several tasks that fall within the scope of planning and preparation. The first task is to determine the role that the new server will in the farm. After you complete this task there are additional tasks to complete before you begin installing software on the new server.

Determine server role

In order to add a new server to the farm you must know its intended role in order to plan for additional or specialized configuration as well as assess the potential impact of adding the server to a production environment.

Note:

In a typical three-tier farm, there are front-end Web servers, an application server that also hosts Central Administration, and a database server. The scope of this article is the front-end Web server and application server roles.

After you determine the role that the server will have in your farm topology you need to identify the services and features that must be configured in order for the server to meet this role. This information will determine how SharePoint Foundation 2010 is configured in order to provision the server for its role in either the Web tier or the application tier. For more information, see Service application and service management (SharePoint Foundation 2010).

The following illustration shows a SharePoint Foundation 2010 farm with two front-end Web servers (Web-1 and Web-2) that serve content. The only application server (App-1) hosts Central Administration for the farm.

Options for adding a server to a farm

SharePoint Foundation 2010 farm: Add a server

The following sections provide information about the general characteristics of the front-end Web server and application server roles.

Front-end Web server role

The fundamental role of a front-end Web server is hosting the Web pages, the Web services, and the Web Parts that are necessary to process requests received from users. The Web server directs these requests to the application server, which returns the results to the front-end Web server.

Depending on farm requirements, the front-end Web server may also be configured to support search in scenarios where there are not any dedicated search servers.

Note:

Distributing search is not an option for SharePoint Foundation 2010, where only a single search instance is permitted for each content database.

In a SharePoint Foundation 2010 farm you can scale out the Web tier by adding a front-end Web server; shown by option A in the preceding illustration. Adding a third server improves load balancing and increases front-end Web server availability. A three server deployment on the Web tier is called a stretched farm.

Application server role

In a three tier farm, the server that hosts Central Administration is by default, an application server. You can add application servers to host services that can be deployed to a single server and used by all the servers in a farm.

Referring to the SharePoint Foundation 2010 farm illustration, option B is to configure the new server with Central Administration so you can add redundancy to the farm. Option C shows additional options, such as hosting timer jobs or the sandbox code service.

Additional tasks

Before you start installing prerequisite software on the server you need to:

  • Verify that the new server meets the hardware and software requirements described in Hardware and software requirements (SharePoint Foundation 2010).

    Note:

    As a best practice, we recommend the operating system on the new server should be at the same service pack level and have the same security updates and other hotfixes as the existing farm servers.

  • Verify that you have the minimum level of permissions required to install and configure on the new server. You must be a member of the Farm Administrators SharePoint group and the Administrators group on the local server computer to complete the procedures in this article. For more information, see Initial deployment administrative and service accounts (SharePoint Foundation 2010).

  • Verify that you know the name of the database server that the farm you are connecting to uses, as well as the name of the configuration database if you are adding the server by using Windows PowerShell commands.

  • If you intend to use Windows PowerShell commands to add the server, verify that you meet the following minimum requirements: You are a member of the SharePoint_Shell_Access role on the configuration database and a member of the WSS_ADMIN_WPG local group on the computer where SharePoint 2010 Products is installed.

  • Document the location of the SharePoint Foundation 2010 binary and log files on the existing farm servers. We recommend that the location of these files on the new server map to the locations used on the other servers in the farm. For more information, see Configure diagnostic logging (SharePoint Foundation 2010).

    Important:

    If you change the trace log path to a non-system drive, this location must exist on all the servers in the farm. Existing or new servers cannot log data if the location does not exist. In addition, you will not be able to add new servers unless the path you specify exists on the new server. You cannot use a network share for logging purposes.

Install prerequisite software

Before you can install SharePoint Foundation 2010 and add a server to the farm you must check for, and install all the prerequisite software on the new server. This is done by using the SharePoint Foundation 2010 Preparation Tool, which requires an Internet connection to download and configure SharePoint Foundation 2010 prerequisites. If you do not have an Internet connection for the farm servers, you can still use the tool to determine what software is required. You will have to obtain installable images for the required software. For installation locations, see Software requirements in "Determine hardware and software requirements (SharePoint Foundation 2010)."

Tip:

After you obtain a copy of the required software, we recommend that you create an installation point that you can use for storing the images. You can use this installation point for installing future software updates.

For detailed instructions about how to install the prerequisites, see "Prepare the farm servers" in the Multiple servers for a three-tier farm (SharePoint Foundation 2010) article.

Install the SharePoint Products software

After all the prerequisites are installed, use the following procedure to install SharePoint Foundation 2010 on the new server. For detailed instructions about how to install SharePoint Foundation 2010, see Deploy a single server with SQL Server (SharePoint Foundation 2010).

To install SharePoint

  1. From the product media or a file share that contains the SharePoint Foundation 2010 Products installation files run Setup.exe.

  2. On the Start page, click the link to install SharePoint Foundation 2010.

  3. Review and accept the Microsoft License Terms.

  4. Select a Server farm installation and then select a complete installation.

    Note:

    You can choose to install only the components required for a front-end Web server. However, by using a complete installation you have more flexibility in re-purposing the server role in the farm at a later time.

  5. Accept the default file location where SharePoint Foundation 2010 will be installed or change the installation path to suit your requirements.

    Note:

    As a best practice, we recommend that you install SharePoint Foundation 2010 on a non-system drive.

  6. When Setup finishes, a dialog box prompts you to complete the configuration of your server by running the SharePoint Products Configuration wizard. You can start the wizard immediately or from the Windows command prompt later.

Add the server to the farm

You can a server to the farm by using the SharePoint Foundation 2010 user interface or by using Windows PowerShell. Both approaches are described in the following procedures:

  • Add a server by using the user interface

  • Add a server by using Windows PowerShell

Use the following procedure to add the server to the farm by using the configuration wizard.

To add a server by using the user interface

  1. On the new server, click Start, point to All Programs and then click Microsoft SharePoint 2010 Products Configuration Wizard.

  2. On the Welcome to SharePoint Products page, click Next.

  3. On the Connect to a server farm page, click Connect to an existing server farm.

  4. Click Next.

  5. On the Specify Configuration Database settings page, type the name of the instance of SQL Server in the Database server box, and then click Retrieve Database Names.

  6. Select the name of the configuration database in the Database name list, and then click Next.

  7. On the Specify Farm Security Settings page, type the name of the farm passphrase in the Passphrase box, and then click Next.

  8. On the Completing the SharePoint Products Configuration Wizard page, click Next.

  9. On the server that hosts Central Administration, click Manage servers in this farm to verify that the new server is part of the farm.

    Note:

    You can also verify a successful server addition, or troubleshoot a failed addition by examining the log files. These files are located on the drive on which SharePoint Foundation 2010 is installed, in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14\LOGS folder. For more information, see Health monitoring (SharePoint Foundation 2010).

  10. On the Servers in Farm page, click the name of the new server. Use the list of available services on the Services on Server page to start the services that you want to run on the new server.

  11. Configure SharePoint Foundation 2010 so the new server can accommodate the role it was intended for. For more information, see Configure the new server.

Before you begin adding the server by using the following Windows PowerShell procedure, install SharePoint Foundation 2010 using the setup program.

To add a server by using Windows PowerShell

  1. On the Start menu, click All Programs.

  2. Click SharePoint 2010 Management Shell. At this point you can issue the following commands to add the server to the farm.

  3. At the Windows PowerShell command prompt, type the following command to connect the server to a configuration database:

    Copy Code
    Connect-SPConfigurationDatabase -DatabaseServer "<$DatabaseServer>" -DatabaseName "<$RunSettings.ConfigurationDatabaseName>" -Passphrase "<$Passphrase>"

    Where:

    • <$DatabaseServer> is the name of the server that hosts the configuration database

    • <$RunSettings.ConfigurationDatabaseName> is the name of the configuration database

    • <$Passphrase> is the passphrase for the farm

  4. At the Windows PowerShell command prompt, type the following command to install the Help File Collections:

    Copy Code
    Install-SPHelpCollection -All

  5. At the Windows PowerShell command prompt, type the following command to install the Security Resource for SharePoint:

    Copy Code
    Initialize-SPResourceSecurity

  6. At the Windows PowerShell command prompt, type the following command to install the basic Services:

    Copy Code
    Install-SPService

  7. At the Windows PowerShell command prompt, type the following command to install all the features:

    Copy Code
    Install-SPFeature -AllExistingFeatures

  8. At the Windows PowerShell command prompt, type the following command to install Application Content:

    Copy Code
    Install-SPApplicationContent

  9. At the Windows PowerShell command prompt, type the following command to get a list of servers in the farm.

    Copy Code
    Get-SPFarm | select Servers
    Note:

    You can also verify a successful server addition, or troubleshoot a failed addition by examining the log files. These files are located on the drive on which SharePoint Foundation 2010 is installed, in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14\LOGS folder. For more information, see Health monitoring (SharePoint Foundation 2010).

  10. Configure SharePoint Foundation 2010 so the new server can accommodate the role it was intended for. For more information, see Configure the new server.

Configure the new server

The new server has no real functionality in the farm until you configure the services that are required to support the role that you planned for the new server. For more information, see Configure services (SharePoint Foundation 2010).


Add a database server to an existing farm (SharePoint Foundation 2010)

This article provides information about adding a new database server to an existing Microsoft SharePoint Foundation 2010 farm. You can add additional database servers at any time in response to business or operations requirements. Because the database server contains the farm content, which can consist of diverse types of data and can have a rapidly growing document collection, the size of the farm databases can grow rapidly. Although storage capacity is a key factor driving the need to add additional database servers, other factors are adding new features, performance, and high availability.

Note:

In the case of high availability, this is typically implemented as part of the initial farm topology design and deployment; and is not included in this article. For more information about high availability forMicrosoft SQL Server 2008, see High Availability Solutions Overview (http://go.microsoft.com/fwlink/p/?LinkId=188016).

In most cases, all that is required to add a database server to an existing SharePoint Foundation 2010 farm is to set up and configure a new database server and join it to the farm by referencing the new server when you add a feature or move database content from the old server to the new one. SharePoint Foundation 2010 will automatically allocate and assign new database resources as necessary when they are required.

In this article:

  • Prepare the new database server

  • Configure and use the new database server

Prepare the new database server

Before you can use the new database server, you need to prepare it so it can be used in a Microsoft SharePoint Foundation farm. Use the following steps as guidance for provisioning the new server.

Important:

IT policy may require that some or all of the steps given in these procedures be performed by a database administrator (DBA). Before beginning any of the following procedures, ensure that you are complying with your company's IT policy requirements.

To provision the database server

  1. Review Hardware and software requirements (SharePoint Foundation 2010)

  2. Install the operating system, ensuring that:

    • The drive configuration is the same as the existing server.

    • The operating system is updated to the same service pack or hotfix level as the existing server.

  3. Install the same version of SQL Server that is installed on the existing farm database server. The procedures in this article are intended to show how to configure a new database server for a specific task in SharePoint Foundation 2010.

    For information about installing and configuring SQL Server before adding it to an existing server farm, see the SQL Server installation documentation.

  4. Configure SQL Server, confirming the following:

    • The database collation is LATIN1_General_CI_AS_KS_WS.

    • Membership in the SQL Server database dbcreator fixed server role and the Farm Administrators SharePoint group is the minimum requirement to perform the procedures in this article.

    • A login account is created for the SharePoint Foundation Setup user account. This account will be the database owner for the new database.

  5. Install the same SQL Server service packs and hotfixes that are installed on the existing database server.

Configure and use the new database server

Use the following procedures as a guide for configuring a new database server to host specific SharePoint Foundation 2010 databases. This includes:

  • Creating a new Web application

  • Moving a site collection to the new server

You can use either Central Administration or Windows PowerShell to create a new Web application; however, you must use Windows PowerShell to move a site collection.

To create a new Web application

  1. Verify that you have the correct credentials on the SharePoint Foundation farm and on SQL Server.

  2. Use the Application Management page on the Central Administration Web site to create a new Web site.

  3. Configure either classic mode authentication (Windows authentication) or claims-based authentication.

  4. Configure IIS to use either the existing Web site or create a new Web site and configure the following settings:

    • Specify the port number you want to use to access the Web application.

    • Provide the URL you want to use to access the Web application (optional).

    • Provide the path to the site directory on the server where the Web site is hosted.

  5. Configure authentication and encryption for your Web using the following options.

    • Negotiate (Kerberos) or NTLM authentication.

    • Anonymous access to the Web site

    • Secure Sockets Layer (SSL)

  6. Provide a URL for the domain name for all sites that users will access in this Web application.

  7. Use the existing application pool or create a new one.

  8. Configure security for the application pool (pre-defined or configurable).

  9. Identify the database server, database name, and authentication method for your new Web application.

For detailed instructions, see Create a Web application (SharePoint Foundation 2010) .

To move a site collection by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. Also verify that the user account has access to one of the servers on which Windows PowerShell 2.0 is running, and that the user account is a Farm Administrator and is a member of the SharePoint_Shell_Access role for the SQL Server source content database, administration content database, destination content database, and configuration database.

  2. Verify that the following conditions are true:

    • The destination content database exists.

    • The source content database and destination content database reside on the same instance of SQL Server.

    • The source content database and destination content database are attached to the same Web application.

  3. Determine the size of the source site collection and verify that the destination hard disk has at least three times the free space that is required for the site collection.

    Use the Get-SPSiteAdministration cmdlet to determine the size of a site collection. For more information, see Get-SPSiteAdministration.

  4. Use the Move-SPSite cmdlets to move a site collection from the source content database to the new content database. For more information, see Move-SPSite.

For detailed instructions, see Move site collections between databases (SharePoint Foundation 2010).


Rename a stand-alone server (SharePoint Foundation 2010)

This article describes how to rename a stand-alone server in Microsoft SharePoint Foundation 2010. If the server was configured to use alternate access mappings and other customizations, you might have to perform additional steps to make all sites on the server accessible to users after the server is renamed.

For example, some Web page images might use file paths or URLs that are no longer valid after you rename the server. You must rename those file paths to provide continued access to the content. If you have configured alerts on any Web applications that use public URLs, verify these alerts and change the public URLs to match the new public URLs. For more information, see Define managed paths (SharePoint Foundation 2010).

The required steps to rename a SharePoint Foundation 2010 server are as follows:

  1. Rename the server at the operating system level by using the System Properties dialog box in Control Panel.

    This article does not provide information about how to rename the actual computer. For more information about renaming the computer, see the Windows Server documentation.

  2. Restart the server.

  3. Use the procedure that is provided in this article to rename the server in SharePoint Foundation 2010.

  4. Run iisreset.

  5. Update Web site mappings as needed to ensure continued access to all sites.

In this article:

  • Rename a stand-alone server by using Windows Powershell

  • Update site access mappings

Rename a stand-alone server by using Windows Powershell

To rename a SharePoint Foundation 2010 stand-alone server, you must use a Windows PowerShell 2.0 cmdlet. There is no user interface option for this action.

To rename a stand-alone server 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Rename-SPServer [-Identity] <OriginalServerName> -Name <NewServerName>

    Where:

    • <OriginalServerName> is the original name of the stand-alone server.

    • <NewServerName> is the new name of the stand-alone server.

  6. To ensure that the rename operation is complete, run iisreset /noforce at a Windows command prompt. For more information, see Restarting IIS (IIS 6.0).

For more information, see Rename-SPServer.

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.

Update site access mappings

To verify that both the public URLs and internal URLs will work with the new server name, review the alternate access mapping settings for each Web application that is hosted on the server. If URLs use the original server name, you must update those URLs to use the new server name. If you do not change these URLs, user requests for content will not be directed to the server, and users will receive a "404" or similar error.

If the Central Administration URL is affected by renaming the server, the Central Administration site is unavailable after the server is renamed. In this case, you must change the Central Administration mapping by using Windows PowerShell 2.0. For more information, see New-SPAlternateUrl.

After updating the Central Administration Web site URL, you can remap other Web applications by using the Windows PowerShell 2.0 New-SPAlternateUrl cmdlet, or by using Central Administration.

If you are using alternate access mappings for Web sites other than Central Administration, including reverse proxies or load balancers that depend on those URLs, ensure that the reverse proxies and load balancers are updated with the new server name also.


Remove a server from the farm (SharePoint Foundation 2010)
See Also

There are three types of servers in a server farm running Microsoft SharePoint Foundation 2010: Web servers, application servers, and database servers.

You can remove a Web server or an application server from the server farm by uninstalling SharePoint Foundation 2010 from the server through Control Panel.

If a Web or application server is no longer available, or if uninstalling SharePoint Foundation 2010 from Control Panel is not possible, you can remove the Web server or application server from the farm by using the SharePoint Central Administration Web site. We highly recommend that you use the process described in Remove a Web server or an application server from a farm by using Control Panel to uninstall SharePoint Foundation 2010 instead of using Central Administration. Removing a server from the farm by using Central Administration does not uninstall SharePoint Foundation 2010 from that server, nor does it render any sites on that server inaccessible. Conversely, when you uninstall SharePoint Foundation 2010 by using Control Panel, you remove the program files and other information from the server. Removing the server from the farm by using Central Administration does not delete this information from the server. Use the Central Administration procedure for removing database servers only, or for removing a Web server or an application server from the farm when the server is no longer available to uninstall through Control Panel.

To remove a database server from a farm, you must first move any databases that are hosted by that server to another database server in the farm. You can then use Central Administration to remove the database server.

Before you remove a database server from a farm, make sure that you have moved any databases stored on that server to a different database server in your farm.

Important:

You cannot remove a database server if it is the only database server available in the farm, or if it is the database server that hosts the configuration database.

Membership in the Farm Administrators group and the Administrators group on the local server computer are the minimum requirements to complete the procedures described in this article.

In this article:

  • Remove a Web server or an application server from a farm by using Control Panel

  • Remove any kind of server from a farm by using Central Administration

Remove a Web server or an application server from a farm by using Control Panel

We recommend that you remove Web servers and application servers from a farm by using this procedure, instead of by using Central Administration.

Caution:

If you uninstall SharePoint Foundation 2010 from the server that is running Central Administration, you will not be able to administer the server farm until you configure another server in the farm to host the Central Administration site.

Make sure that the server that you want to remove is not running any important site components. If important services or components (such as a custom Web Part) are running on the server and are not available on another server in the farm, removing the server can damage sites in the farm. For example, if the server that you want to remove is the only application server in the farm that is running the Business Data Connectivity service, removing the server can make any sites that rely on that service stop working correctly.

Before you uninstall a server, you must stop the services that are running on that server. For information about how to determine which services are running on a specific server and stopping services, see Manage services on the server (SharePoint Foundation 2010).

To remove a Web server or an application server from a farm by using Control Panel

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local server computer.

  2. On the server that you want to remove from the farm, click Start, click Control Panel, and then double-click Programs and Features.

  3. In the list of currently installed programs, click SharePoint Foundation 2010, and then click Uninstall.

  4. Click Continue at the confirmation prompt to uninstall the program.

Remove any kind of server from a farm by using Central Administration

You can use this procedure to remove a Web server, application server, or database server from the farm.

To remove any kind of server from a server farm 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. On the SharePoint Central Administration Web site, in the System Settings section, click Manage servers in this farm.

  3. On the Servers in Farm page, locate the row that contains the name of the server that you want to remove, and then click Remove Server.

  4. In the warning that appears, click OK to remove the server or click Cancel to stop the operation.

    The page refreshes, and the server that you removed no longer appears in the list of servers.

See Also

Concepts

Server and server farm administration (SharePoint Foundation 2010)
Farm topology management (SharePoint Foundation 2010)


Migrate a farm deployed on a failover cluster environment (SharePoint Foundation 2010)

Published: December 16, 2010

This article provides information that you can use for the migration of a Windows SharePoint Services 3.0 farm or a Microsoft SharePoint Foundation 2010 farm that is deployed in a failover cluster environment to another cluster.

Although SharePoint Foundation is not cluster-aware and we do not support clusters running SharePoint Foundation, we recognize that some organizations do implement failover clusters at the operating system or database levels.

In this article:

  • Migration strategy

  • Migration resources

Migration strategy

If the environment uses failover clustering at the operating system level or the database server level (or both), you must develop a migration strategy that ensures that the SharePoint Foundation 2010 farm is highly available and not compromised in any way (for example, lost data and corrupted configurations).

Note:

Because SharePoint Foundation 2010 only supports a 64-bit operating system and 64-bit database environment, any migration strategy has to include this requirement.

Migration is typically done in order to upgrade the following cluster elements:

  • Windows Server 2003 or Windows Server 2008 to Windows Server 2008 R2

  • Microsoft SQL Server 2005 to Microsoft SQL Server 2008

The migration strategy will be based on the cluster elements that you want to work with. If your farm environment uses an operating system cluster and a database server cluster, we recommend that you complete the operating system migration first.

Windows Server clusters

In a Windows Server failover cluster environment, the cluster exists as a named server in the farm. When you migrate to a new cluster, you have to complete the following tasks:

  1. Add the new cluster as a different registered name.

  2. Move all the services to the new server cluster.

  3. Remove the existing server cluster as a named farm server.

In a scenario where SQL Server is hosted on a Windows Server cluster, database migration is fairly easy because you do not have to configure SQL Server connection strings.

Windows Server clusters expose one or more virtual server names, WINS entries, and DNS entries. The new cluster can use a virtual server name, WINS entry, or DNS entry that is available after the identifier is no longer registered with the existing cluster. Services are migrated as described in the Migrate an existing server farm to a 64-bit environment (Office SharePoint Server 2007) (http://go.microsoft.com/fwlink/p/?LinkId=207555) article, which also applies to SharePoint Foundation 2010.

SQL Server clusters

In a SQL Server failover cluster environment, cluster migration is complex and involves more downtime than the migration of the operating system cluster. The challenges that a database server migration poses exist because SharePoint Foundation uses server names to reference SQL Server, other farm servers, and itself. This differs from a Windows Server cluster, which uses virtual server names, WINS entries, and DNS entries.

Migration resources

The following resources are available to assist you with all aspects of cluster migration:

  • Migrating Clustered Services and Applications to Windows Server 2008 R2 Step-by-Step Guide (http://go.microsoft.com/fwlink/p/?LinkId=182155)

    This guide describes how to migrate clustered services and applications (formerly known as resource groups) to a failover cluster running Windows Server 2008 R2.

    Note:

    In a scenario where you are migrating from the 64-bit version of Windows Server 2003, you can use an in-place migration to upgrade the operating system to Windows Server 2008 R2. For more information, see In-Place Migration for a Two-Node Cluster (http://go.microsoft.com/fwlink/p/?LinkId=207557).

  • Migration Paths for Migrating to a Failover Cluster Running Windows Server 2008 R2 (http://go.microsoft.com/fwlink/p/?LinkId=182156)

    This article describes how to migrate or upgrade specific clustered services or applications to a cluster running Windows Server 2008 R2.

  • How to: Upgrade a SQL Server Failover Cluster Instance (Setup) (http://go.microsoft.com/fwlink/p/?LinkId=169111)

    This article describes how to upgrade an instance of a SQL Server failover cluster.


Availability configuration (SharePoint Foundation 2010)
See Also

This section describes how to configure availability for Microsoft SharePoint Foundation 2010. The articles assume that you are familiar with the concepts and terms presented in Plan for availability (SharePoint Foundation 2010).

In this section:

  • Configure availability by using SQL Server clustering (SharePoint Foundation 2010)

    This article describes how to use SQL Server clustering with SharePoint Foundation 2010.

  • Configure availability by using SQL Server database mirroring (SharePoint Foundation 2010)

    This article describes how to configure SQL Server database mirroring for use with SharePoint Foundation 2010.

  • Sample script for configuring SQL Server mirroring (SharePoint Foundation 2010)

    This article provides a script to use in configuring SQL Server database mirroring for use with SharePoint Foundation 2010 in a test environment. In a production environment, we recommend that a database professional configure mirroring.

See Also

Concepts

Plan for availability (SharePoint Foundation 2010)

Other Resources

Resource Center: Operations and Manageability for SharePoint Foundation 2010


Configure availability by using SQL Server clustering (SharePoint Foundation 2010)
See Also

Microsoft SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2 failover clustering can be used to configure availability within a farm for Microsoft SharePoint Foundation 2010. This article assumes that you are familiar with the concepts and terms presented in Plan for availability (SharePoint Foundation 2010).

Failover clustering provides availability support for an instance of SQL Server 2008 with SP1 and Cumulative Update 2. A failover cluster is a combination of one or more nodes or servers and two or more shared disks. A failover cluster instance appears as a single computer, but has functionality that provides failover from one node to another if the current node becomes unavailable.

SharePoint Foundation 2010 references the cluster as a whole; therefore, failover is automatic and seamless from the perspective of SharePoint Foundation 2010.

For detailed information about failover clustering, see Getting Started with SQL Server 2008 Failover Clustering (http://go.microsoft.com/fwlink/p/?LinkID=102837&clcid=0x409).

There are no instructions specific to setting up clustering for SharePoint Foundation 2010. For instructions on how to set up failover clustering, see Installing a SQL Server 2008 Failover Cluster (http://go.microsoft.com/fwlink/p/?LinkId=132112&clcid=0x409).

See Also

Other Resources

Resource Center: Business Continuity Management for SharePoint Foundation 2010


Configure availability by using SQL Server database mirroring (SharePoint Foundation 2010)
See Also

This article describes how to use high-availability database mirroring to configure availability within a farm for Microsoft SharePoint Foundation 2010. The article assumes that you are familiar with the concepts and terms presented in Plan for availability (SharePoint Foundation 2010).

Microsoft SQL Server database mirroring provides availability support by sending transactions directly from a principal database and server to a mirror database and server when the transaction log buffer for the principal database is written to disk. For availability within a Microsoft SharePoint Foundation 2010 farm, you use high-availability database mirroring, also known as high-safety mode with automatic failover. High-availability database mirroring involves three server instances: a principal, a mirror, and a witness. The witness server enables SQL Server to automatically fail over from the principal server to the mirror server. Failover from the principal database to the mirror database typically takes several seconds.

Within a SharePoint Foundation 2010 farm, mirroring can provide redundancy for the content and configuration databases, and for many service databases. Even if your databases are mirrored to the same server, each database fails over individually. The following figure shows how mirroring is configured to provide availability within a SharePoint Foundation 2010 farm.

Diagram of mirroring all databases within a farm

SharePoint Foundation 2010 is mirroring-aware. To use mirroring in your environment, first configure mirroring, and then set the failover database value in SharePoint Foundation.

In this article:

  • Before you begin

  • Security associated with database mirroring

  • Configure SharePoint 2010 Products to be aware of mirrored databases

  • User experience during a failover

Before you begin

Before you begin to configure mirroring, make sure that your database administrator is aware of the following requirements and supported topologies.

Database mirroring requirements

Become familiar with the recommendations in the following list, and ensure that your databases and system meet any requirements before you configure database mirroring for a SharePoint Foundation environment:

  • We recommend that your system have latency no more than 1 millisecond.

  • System bandwidth should preferably be 1 gigabyte (GB) per second.

  • Logs are copied in real time between the principal and the mirror servers, and copying can affect performance. Make sure that you have sufficient memory and bandwidth on both the principal and mirror server.

  • The principal server and mirror server must run the same version and edition of SQL Server, and they must run in the same language. Database mirroring is available only in the Standard, Developer, and Enterprise editions. The witness server can run any version of SQL Server, including SQL Server 2008 Express.

  • Mirroring works only with databases that use the full recovery model.

    By default, SharePoint Foundation 2010 databases are configured to use the simple recovery model. To configure database mirroring, the recovery model of the database must be set to Full. For information about how to set the recovery model for a database, see How to: View or Change the Recovery Model of a Database (SQL Server Management Studio) (http://go.microsoft.com/fwlink/p/?LinkId=132075&clcid=0x409).

  • If you plan to mirror databases, consider that the size of the transaction logs for these databases may become very large. To work around this, you can establish a recovery plan that truncates transaction logs as necessary. For more information, see the following article in the Microsoft Knowledge Base: How to stop the transaction log of a SQL Server database from growing unexpectedly (http://go.microsoft.com/fwlink/p/?LinkId=111458&clcid=0x409).

  • Every database mirroring session creates at least two threads for each database. Ensure that your database server has enough threads to allocate for mirroring all the supported databases. If you have insufficient threads, performance can decrease as more databases are added to a session.

For more information about performance for database mirroring, see Database mirroring best practices and performance considerations (http://go.microsoft.com/fwlink/p/?LinkId=185119).

Security associated with database mirroring

Database mirroring uses TCP sessions to transport the transaction log from one server to another and to monitor the current health of the system for automatic failovers. Authentication is performed at the session level when a port is opened for connection. Database mirroring supports both Windows authentication (NTLM or Kerberos) and certificates.

Unless the network is secure, the data transmitted during the session should be encrypted. Database mirroring supports both Advanced Encryption Standard (AES) and RC4 encryption algorithms. For more information about the security associated with database mirroring, see Database Mirroring Transport Security (http://go.microsoft.com/fwlink/p/?LinkId=83569&clcid=0x409).

SharePoint 2010 Products security and mirrored servers

When you set up a mirrored database, the SQL Server logins and permissions for the database to be used with a SharePoint farm are not automatically configured in the master and msdb databases on the mirror server. Instead, you must configure the permissions for the required logins. These include, but are not limited to, the following:

  • The Central Administration application pool account should be a member of the dbcreator and securityadmin fixed server roles.

  • All application pool accounts, the default content access accounts, and any accounts required for service applications should have SQL Server logins, although they should not be assigned to SQL Server fixed server or fixed database roles.

  • Members of the Farm Administrators SharePoint group should also have SQL Server logins and should be members of the same SQL Server roles as the Central Administration application pool account.

We recommend that you transfer your logins and permissions from the principal server to the mirror server by running a script. An example script is available in Knowledge Base article 918992 How to transfer the logins and the passwords between instances of SQL Server 2005 (http://go.microsoft.com/fwlink/p/?LinkId=122053&clcid=0x409). For more information about how to transfer SQL Server metadata between instances, see the SQL Server Books Online article Managing Metadata When Making a Database Available on Another Server Instance (http://go.microsoft.com/fwlink/p/?LinkId=122055&clcid=0x409).

Supported topologies

We recommend that you maintain a one-to-one mapping of principal server and database instance to mirror server and database instance to ensure compatibility with SharePoint Foundation 2010.

The supported topologies include mirroring all content databases, the configuration database, the Central Administration content database, and the service application databases except for the Web Analytics Staging database and the User Profile Synchronization database.

Note:

We do not recommend that you mirror the Usage and Health Data Collection Logging database. A SharePoint environment can continue to run if this database fails, and this data can be quickly regenerated.

Avoid topologies that do not have matching principal server and database instances and mirror server and database instances. Also, keep the configuration database and the administration content database on the same server.

Configure high-availability database mirroring

We recommend that a SQL Server database administrator configure high-availability mirroring for a production environment. For a test environment, we have provided Transact-SQL scripts that you can use to configure your environment. For more information, see Sample script for configuring SQL Server mirroring (SharePoint Foundation 2010).

Configure SharePoint 2010 Products to be aware of mirrored databases

To make SharePoint Foundation 2010 aware that failover mirrored databases exist, perform the following procedure for all configuration and content databases.

Note:

We recommend that you use Windows PowerShell cmdlets to set failover database values. Although you can use the Central Administration Web site to set some failover database values, you cannot use it for all databases.

To configure SharePoint 2010 Products to be aware of mirrored databases 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. At the Windows PowerShell command prompt, type the following commands, and then press ENTER:

    $db = get-spdatabase | where {$_.Name -eq "database name"}

    $db.AddFailoverServiceInstance("mirrored database name")

    $db.Update()

For more information, see Get-SPDatabase.

User experience during a failover

While SQL Server is switching to using a mirrored database, users of a SharePoint site that runs against the database may experience brief connectivity issues and data loss.

Monitoring and troubleshooting mirroring

To monitor the status and performance of mirroring within a farm, database administrators can use the Database Mirroring Monitor. Monitoring enables you to determine whether and how well data is flowing in the database mirroring session. Database Mirroring Monitor is also useful for troubleshooting the cause of reduced data flow. For more information, see Database Mirroring Monitor Overview (http://go.microsoft.com/fwlink/p/?LinkId=185068). Another resource to use in troubleshooting is the SQL Server Books Online article Troubleshooting Database Mirroring Setup (http://go.microsoft.com/fwlink/p/?LinkId=185069).

See Also

Other Resources

Database Mirroring
Resource Center: Business Continuity Management for SharePoint Foundation 2010


Sample script for configuring SQL Server mirroring (SharePoint Foundation 2010)

This article contains a series of sample scripts that you can use to set up Microsoft SQL Server mirroring for a test Microsoft SharePoint Foundation 2010 environment. We recommend that a SQL Server database administrator configure mirroring for a production environment.

To set up database mirroring with SharePoint Foundation 2010, you must work individually with each database that you want to mirror.

In this article:

  • Configure database mirroring with certificates and full recovery

  • Set up a witness server

  • Transfer permissions to the mirror server

The steps in the following section apply to the following server farm topology:

  • One or more front-end Web servers

  • Three servers that are running SQL Server 2008: principal server, mirror server, and witness server

  • One configuration database

  • Multiple content databases

  • One or more service application databases

Configure database mirroring with certificates and full recovery

Each step lists the server on which it should be performed. Use Transact-SQL to send these commands to SQL Server. Placeholder information is denoted by angle brackets (<>); replace this with information that is specific to your deployment.

To set up the principal server for outbound connections

  1. On the principal server, create a certificate and open a port for mirroring.

    Copy Code
    --On the master database, create the database master key, if needed
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<test1234->';
GO
-- Make a certificate for this server instance.
USE master;
CREATE CERTIFICATE <MASTER_HostA_cert>
   WITH SUBJECT = '<Master_HostA certificate>';
GO
--Create a mirroring endpoint for server instance by using the certificate
CREATE ENDPOINT Endpoint_Mirroring
   STATE = STARTED
   AS TCP (
      LISTENER_PORT=5024
      , LISTENER_IP = ALL
   )
   FOR DATABASE_MIRRORING (
      AUTHENTICATION = CERTIFICATE <MASTER_HostA_cert>
      , ENCRYPTION = REQUIRED ALGORITHM RC4
      , ROLE = ALL
   );
GO

  2. On the principal server, back up the certificate.

    Copy Code
    --Back up the HOST_A certificate.
BACKUP CERTIFICATE MASTER_HostA_cert TO FILE = '<c:\MASTER_HostA_cert.cer>';
GO

  3. On the principal server, back up the database. This example uses the configuration database. Repeat for all databases.

    Copy Code
    USE master;
--Ensure that SharePoint_Config uses the full recovery model.
ALTER DATABASE SharePoint_Config
   SET RECOVERY FULL;
GO
USE SharePoint_Config
BACKUP DATABASE SharePoint_Config
    TO DISK = '<c:\SharePoint_Config.bak>'
    WITH FORMAT
GO
BACKUP Log SharePoint_Config
    TO DISK = '<c:\SharePoint_Config_log.bak>'
    WITH FORMAT
GO

  4. Copy the backup file to the mirror server. Repeat for all databases.

  5. By using any secure copy method, copy the backup certificate file (C:\HOST_HostA_cert.cer, for example) to the mirror server.

  6. On the principal server, create a login and user for the mirror server, associate the certificate with the user, and grant the login connect permissions for the partnership.

    Copy Code
    --Create a login on HOST_A for HOST_B
USE master;
CREATE LOGIN <HOST_HostB_login> WITH PASSWORD = '<1234-test>';
GO
--Create a user for that login.
CREATE USER <HOST_HostB_user> FOR LOGIN <HOST_HostB_login>;
GO
--Associate the certificate with the user
CREATE CERTIFICATE <HOST_HostB_cert>
   AUTHORIZATION <HOST_HostB_user>
   FROM FILE = '<c:\HOST_HostB_cert.cer>' --do not use a network path, SQL Server will give an error about the key not being valid
GO
--Grant CONNECT permission on the login for the remote mirroring endpoint.
GRANT CONNECT ON ENDPOINT::Endpoint_Mirroring TO [<HOST_HostB_login>];
GO

To set up the mirror server for outbound connections

  1. On the mirror server, create a certificate and open a port for mirroring.

    Copy Code
    --On the master database, create the database master key, if needed.
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<1234-test>';
GO
-- Make a certificate on the HOST_B server instance.
CREATE CERTIFICATE <HOST_HostB>
   WITH SUBJECT = '<HOST_HostB certificate for database mirroring>';
GO
--Create a mirroring endpoint for the server instance on HOST_B.
CREATE ENDPOINT Endpoint_Mirroring
   STATE = STARTED
   AS TCP (
      LISTENER_PORT=5024
      , LISTENER_IP = ALL
   )
   FOR DATABASE_MIRRORING (
      AUTHENTICATION = CERTIFICATE <HOST_HostB>
      , ENCRYPTION = REQUIRED ALGORITHM RC4
      , ROLE = ALL
   );
GO

  2. On the mirror server, back up the certificate.

    Copy Code
    --Back up the HOST_B certificate.
BACKUP CERTIFICATE <HOST_HostB> TO FILE = '<C:\HOST_HostB_cert.cer>';
GO

  3. By using any secure copy method, copy the backup certificate file (C:\HOST_HostB_cert.cer, for example) to the principal server.

  4. On the mirror server, restore the database from the backup files. This example uses the configuration database. Repeat for all databases.

    Copy Code
    RESTORE DATABASE SharePoint_Config
    FROM DISK = '<c:\SharePoint_Config.bak>'
    WITH NORECOVERY
GO
RESTORE log SharePoint_Config
    FROM DISK = '<c:\SharePoint_Config_log.bak>'
    WITH NORECOVERY
GO

To set up the mirror server for inbound connections

  1. On the mirror server, create a login and user for the principal server, associate the certificate with the user, and grant the login connect permissions for the partnership.

    Copy Code
    --Create a login on HOST_B for HOST_A
USE master;
CREATE LOGIN <MASTER_HostA_login> WITH PASSWORD = '<test1234->';
GO
--Create a user for that login.
CREATE USER <MASTER_HostA_user> FOR LOGIN <MASTER_HostA_login>;
GO
--Associate the certificate with the user
CREATE CERTIFICATE <MASTER_HostA_cert>
   AUTHORIZATION <MASTER_HostA_user>
   FROM FILE = '<c:\MASTER_HostA_cert.cer>' --do not use a network path, SQL Server will give an error about the key not being valid
GO
--Grant CONNECT permission on the login for the remote mirroring endpoint.
GRANT CONNECT ON ENDPOINT::Endpoint_Mirroring TO [<MASTER_HostA_login>];
GO

To set up the principal server for inbound connections

  1. On the principal server, create a login and user for the mirror server, associate the certificate with the user, and grant the login connect permissions for the partnership.

    Copy Code
    --Create a login on HOST_A for HOST_B
USE master;
CREATE LOGIN <HOST_HostB_login> WITH PASSWORD = '<1234-test>';
GO
--Create a user for that login.
CREATE USER <HOST_HostB_user> FOR LOGIN <HOST_HostB_login>;
GO
--Associate the certificate with the user
CREATE CERTIFICATE <HOST_HostB_cert>
   AUTHORIZATION <HOST_HostB_user>
   FROM FILE = '<c:\HOST_HostB_cert.cer>' --do not use a network path, SQL Server will give an error about the key not being valid
GO
--Grant CONNECT permission on the login for the remote mirroring endpoint.
GRANT CONNECT ON ENDPOINT::Endpoint_Mirroring TO [<HOST_HostB_login>];
GO

To set up the mirroring partners

  1. On the principal server, set up the mirroring partnership. This example uses the configuration database. Repeat for all databases.

    Copy Code
    --At HOST_A, set the server instance on HOST_B as a partner (mirror server).
ALTER DATABASE SharePoint_Config
    SET PARTNER = '<TCP://databasemirror.adatum.com:5024>';
GO

  2. On the mirror server, set up the mirroring partnership. This example uses the configuration database. Repeat for all databases.

    Copy Code
    --At HOST_B, set the server instance on HOST_A as a partner (principal server):
ALTER DATABASE SharePoint_Config
    SET PARTNER = '<TCP://databasemaster.adatum.com:5024>';
GO

Set up a witness server

Each step lists the server on which it should be performed. Use Transact-SQL to send these commands to SQL Server. Placeholder information is denoted by angle brackets (<>); replace this with information that is specific to your deployment.

  1. On the witness server, set up the certificate and open the port.

    Copy Code
    --On the master database, create the database master key, if needed
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<1234test->';
GO
-- Make a certificate for this server instance.
USE master;
CREATE CERTIFICATE <WITNESS_HostC_cert>
   WITH SUBJECT = '<Witness_HostC certificate>';
GO
--Create a mirroring endpoint for server instance by using the certificate
CREATE ENDPOINT Endpoint_Mirroring
   STATE = STARTED
   AS TCP (
      LISTENER_PORT=5024
      , LISTENER_IP = ALL
   )
   FOR DATABASE_MIRRORING (
      AUTHENTICATION = CERTIFICATE <WITNESS_HostC_cert
      , ENCRYPTION = REQUIRED ALGORITHM RC4
      , ROLE = ALL
   );
GO

  2. On the witness server, back up the certificate.

    Copy Code
    --Back up the HOST_C certificate
BACKUP CERTIFICATE <WITNESS_HostC_cert> TO FILE = '<c:\ WITNESS_HostC_cert.cer>';
GO

  3. By using any secure copy method, copy the backup certificate file (C:\WITNESS_HOSTC_cert.cer, for example) to the principal server and the mirror server.

  4. On the witness server, create logins and users for the principal and mirror servers, associate the certificates with the users, and grant the logins connect permissions for the partnership.

    Copy Code
    --Create a login on witness HOST_C for principal HOST_A
USE master;
CREATE LOGIN <MASTER_HostA_login> WITH PASSWORD = '<test1234->';
GO
--Create a user for that login.
CREATE USER <MASTER_HostA_user> FOR LOGIN <MASTER_HostA_login>;
GO
--Associate the certificate with the user
CREATE CERTIFICATE <MASTER_HostA_cert>
   AUTHORIZATION <MASTER_HostA_user>
   FROM FILE = '<c:\MASTER_HostA_cert.cer>' --do not use a network path, SQL Server will give an error about the key not being valid
GO
--Grant CONNECT permission on the login for the remote mirroring endpoint.
GRANT CONNECT ON ENDPOINT::Endpoint_Mirroring TO [<MASTER_HostA_login>];
GO
--Create a login for the mirror Host_B
CREATE LOGIN <HOST_HostB_login> WITH PASSWORD = '<1234-test>';
GO
--Create a user for that login.
CREATE USER <HOST_HostB_user> FOR LOGIN <HOST_HostB_login>;
GO
--Associate the certificate with the user
CREATE CERTIFICATE <HOST_HostB_cert>
   AUTHORIZATION <HOST_HostB_user>
   FROM FILE = '<c:\HOST_HostB_cert.cer>' --do not use a network path, SQL Server will give an error about the key not being valid
GO
--Grant CONNECT permission on the login for the remote mirroring endpoint.
GRANT CONNECT ON ENDPOINT::Endpoint_Mirroring TO [<HOST_HostB_login>];
GO

  5. On the principal server, create a login and user for the witness server, associate the certificate with the user, and grant the login connect permissions for the partnership. Repeat for the mirror server.

    Copy Code
    --Create a login on master HostA for witness HostC
USE master;
CREATE LOGIN <WITNESS_HostC_login> WITH PASSWORD = '<1234test->';
GO
--Create a user for that login.
CREATE USER <WITNESS_HostC_user> FOR LOGIN <WITNESS_HostC_login>;
GO
--Associate the certificate with the user
CREATE CERTIFICATE <WITNESS_HostC_cert>
   AUTHORIZATION <WITNESS_HostC_user>
   FROM FILE = '<c:\WITNESS_HostC_cert.cer>' --do not use a network path, SQL Server will give an error about the key not being valid
GO
--Grant CONNECT permission on the login for the remote mirroring endpoint.
GRANT CONNECT ON ENDPOINT::Endpoint_Mirroring TO [<WITNESS_HostC_login>];
GO

  6. On the principal server, attach the witness server. This example uses the configuration database. Repeat for all databases.

    Copy Code
    --Set up the witness server
ALTER DATABASE SharePoint_Config
    SET WITNESS =
    '<TCP://databasewitness.adatum.com:5024>'
GO

Transfer permissions to the mirror server

When you set up a mirrored database, the SQL Server logins and permissions for the database that will be used with a SharePoint farm are not automatically configured in the master and msdb databases on the mirror server. Instead, you must configure the permissions for the required logins.

We recommend that you transfer your logins and permissions from the principal server to the mirror server by running a script. The script that we recommend that you use is available in Knowledge Base article 918992: How to transfer the logins and the passwords between instances of SQL Server 2005 (http://go.microsoft.com/fwlink/p/?LinkId=122053&clcid=0x409).

Removing mirroring from a server

To remove mirroring from a server, see How to: Remove Database Mirroring (Transact-SQL) (http://go.microsoft.com/fwlink/p/?LinkId=185070).


Track or block SharePoint Foundation 2010 installations

Published: June 10, 2010

Because deployments of Microsoft SharePoint 2010 Products are managed at the farm level, a single SharePoint deployment has no information about other SharePoint deployments that might exist in the same enterprise. Administrators need this information to manage and control all deployments in the enterprise. For example, administrators need to know whether a deployment was configured according to organizational requirements, or how many unauthorized deployments exist in the enterprise. SharePoint 2010 Products provides the ability to lock down, track, and even block random installations of Microsoft SharePoint Foundation 2010.

In this article:

  • Block installations

  • Track installations

Block installations

If you want to block users from installing SharePoint Foundation 2010 and related products, set the following registry key by using Group Policy in Active Directory directory services:

HKLM\Software\Policies\Microsoft\Shared Tools\Web Server Extensions\14.0\ SharePoint\DWORD DisableInstall

To block installations, set DWORD DisableInstall=00000001.

When this registry key is set, users who try to install SharePoint Foundation 2010 receive the following error message:

SharePoint installation is blocked in your organization. Please contact your network administrator for more details.

To set a registry value by using Group Policy, you can use an .admx file in Windows Server 2008 or a Windows PowerShell cmdlet in Windows Server 2008 R2. For more information about how to set registry values by using group policies in Windows Server 2008, see Group Policy ADMX Syntax Reference Guide (http://go.microsoft.com/fwlink/p/?LinkId=194348). For more information about how to set registry values by using group policies in Windows Server 2008 R2, see Set a registry key value from the command line using Group Policy PowerShell cmdlets (http://go.microsoft.com/fwlink/p/?LinkId=194345). For general information about group policies, see Group Policy (http://go.microsoft.com/fwlink/p/?LinkID=177635) on TechNet.

Track installations

An Active Directory Domain Services (AD DS) Marker called Service Connection Point identifies the SharePoint 2010 Products servers in an organization. To use this marker, create a container in AD DS and set the permissions for the container before you install any SharePoint 2010 Products in the environment. Then, when you or another user in your domain runs the SharePoint Products Configuration Wizard as part of installing SharePoint Foundation 2010, this marker is set, and can be tracked by using AD DS. You must set this marker for each domain that you have in your organization if you want to track installations in all domains. This marker is removed from AD DS when the last server is removed from a farm. You can also set the marker by using Windows PowerShell. The marker contains the URL for the Application Discovery and Load Balancer Service (also known as the topology service application) for the server farm.

You have to grant permission to write to this container to any user accounts or domain accounts that could run the SharePoint Products Configuration Wizard. If the account does not have permission to write to this container, the following warning will appear in the log file for the SharePoint Products Configuration Wizard:

Failed to add the service connection point for this farm

Unable to create a Service Connection Point in the current Active Directory domain. Verify that the SharePoint container exists in the current domain and that you have rights to write to it."

To create the container in Active Directory and set the permissions, you can use Active Directory Service Interfaces (ADSI) Edit.

To create a service connection point container to track installations

  1. On the domain controller, click Start, point to Administrative Tools, and then click ADSI Edit, or use a remote administration tool to connect to ADSI Edit from another computer.

  2. On the Action menu, click Connect to, and connect to the domain that you want to use.

  3. In the console tree, expand the connection, expand the domain name, and then click CN=System.

  4. In the details pane, right-click in the white area, click New, and then click Object.

  5. In the Create Object dialog box, in the Select a class box, click container and then click Next.

  6. In the Value box, type Microsoft SharePoint Products as the container name, and then click Next.

    This is the default name.

    Note:

    You can use other names. However, if you do use other names, you must create a Group Policy for the domain computers to set a string value ContainerDistinguishedName under the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\SharePoint. This makes it possible for the SharePoint Products Configuration Wizard to detect the new name.

  7. Click Finish.

    The container is created.

  8. Right click the container (CN=Microsoft SharePoint Products), and then click Properties.

  9. On the Security tab, click Add.

  10. In the Select Users, Computers, Service Accounts, or Groups box, add the users that you want to write to this container, and then click OK.

    Note that if a user who cannot write to this container installs SharePoint Foundation 2010, no new entry will be created. Consider giving all Authenticated Users the permission so that you can track all the objects.

  11. In the Group or user names box, select the names that you previously added, and then under the Permissions box, click Advanced.

  12. In the Permission entries box, select the names that you previously added, and then click Edit.

  13. In the Permission Entry for Microsoft SharePoint Products dialog box, in the Permissions box, select the Allow check box for Create serviceConnectionPoint objects, and then click OK.

To validate this process, install and provision a new SharePoint farm in the environment, and check whether the service connection point was created successfully. If everything works, you can find a new GUID object under the Microsoft SharePoint Product container. Right-click the object, and then click Properties. The URL for the server farm's Application Discovery and Load Balancer Service will be listed.

A script is available that lists all the SharePoint 2010 Products server names in a domain. To get the script, see List all SharePoint 2010 boxes in a domain by checking AD Marker in the Script Center.

Use the following procedure to add or update the service connection point for the current farm in AD DS.

To set a service connection point in AD DS 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. At the Windows PowerShell command prompt, type the following command.

    Copy Code
    Set-SPFarmConfig -ServiceConnectionPointBindingInformation StringwithBindingInformation

    Where:

    • StringwithBindingInformation is usually the URL for the Application Discovery and Load Balancer Service. Note that this variable can contain any valid string you prefer, such as the URL for Central Administration, instead.

      To get the URL for the Application Discovery and Load Balancer Service, run the following command.

      Copy Code
      Get-SPTopologyServiceApplication | select URI

      This returns the URL for the Application Discovery and Load Balancer Service. For more information, see Get-SPTopologyServiceApplication.

  6. When asked to confirm this action, type Y.

For more information, see Set-SPFarmConfig.

Use the following procedure to delete the service connection point for the current farm in AD DS.

To delete a service connection point in AD DS 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. At the Windows PowerShell command prompt, type the following command.

    Copy Code
    Set-SPFarmConfig -ServiceConnectionPointDelete

  6. When asked to confirm this action, type Y.

For more information, see Set-SPFarmConfig.

Use the following procedure to determine the service connection point information for the current farm in AD DS.

To find the service connection point for a farm 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. At the Windows PowerShell command prompt, type the following command.

    Copy Code
    Get-SPFarmConfig -ServiceConnectionPoint

For more information, see Get-SPFarmConfig.


Site and solution administration (SharePoint Foundation 2010)
See Also

This chapter describes how to configure administration settings for sites and solutions in a Microsoft SharePoint Foundation 2010 environment.

  • Site and site collection administration (SharePoint Foundation 2010)

    The topics in this section explain how to create and delete site collections, how to manage site collection administrators, how to use quota templates to manage site storage limits and determine when to lock sites, and how to delete unused Web sites. The topics in this section also explain how to configure security for Web parts pages and controls.

  • Sandboxed solutions administration (SharePoint Foundation 2010)

    The articles in this section provide instructions for managing sandboxed solutions that run in restricted execution environments within your enterprise.

  • Business Data Connectivity service administration (SharePoint Foundation 2010)

    The articles in this section provide descriptions of general administrative Business Data Connectivity service operations and operations related to the items that are stored and managed by using the service.

  • Workflow administration (SharePoint Foundation 2010)

    The articles in this section explain how to perform common workflow administration tasks.

See Also

Concepts

Server and server farm administration (SharePoint Foundation 2010)


Site and site collection administration (SharePoint Foundation 2010)
See Also

A Microsoft SharePoint Foundation 2010 site collection is a hierarchical site structure that is made up of one top-level site and sites below it. This top-level Web site can have multiple subsites, and each subsite can have multiple subsites, for as many levels as required. Top-level Web sites and subsites allow different levels of control over the features and settings for sites.

In this section:

  • Manage site collections (SharePoint Foundation 2010)

    These articles explain how to create and delete site collections, how to manage site collection administrators, and how to use quota templates to manage site collection storage limits.

  • Manage sites (SharePoint Foundation 2010)

    These articles explain how to determine when to lock or unlock sites, and how to use site usage data to determine whether an unused Web site should be deleted.

  • Manage Web Parts (SharePoint Foundation 2010)

    These articles help you prepare to manage security for Web Parts pages and controls.

See Also

Concepts

Operations for SharePoint Foundation 2010


Manage site collections (SharePoint Foundation 2010)
See Also

This section describes how to create and delete site collections, how to manage site collection administrators, and how to use quota templates to manage site collection storage limits.

  • Create a site collection (SharePoint Foundation 2010)

    This article explains how to create a site collection that is based on an existing Web application or how to create a Web application and then create a site collection within that application.

  • Delete a site collection (SharePoint Foundation 2010)

    This article explains how to delete the content, user information, and site hierarchy that comprise a site collection.

  • Restore a deleted site collection (SharePoint Foundation 2010)

    This article explains how to restore an accidentally deleted site collection using functionality introduced in Microsoft SharePoint Foundation 2010 with Service Pack 1 (SP1).

  • Configure a connection to a portal site (SharePoint Foundation 2010)

    This article describes how to configure a connection to a portal site. The portal site is added to the global breadcrumb navigation for the site collection.

  • View all site collections (SharePoint Foundation 2010)

    This article explains how to see the list of site collections.

  • Add or remove site collection administrators (SharePoint Foundation 2010)

    This article explains how to change primary and secondary site collection administrators.

  • Create, edit, and delete quota templates (SharePoint Foundation 2010)

    This article explains how to configure storage limit values that specify the maximum amount of data that can be stored in a site collection and the storage size that, when reached, triggers an e-mail alert to the site collection administrator.

  • Manage site collection storage limits (SharePoint Foundation 2010)

    This article explains how to update the warning and storage limits for a site collection by changing the quota template assigned to the site collection.

  • Manage blocked file types (SharePoint Foundation 2010)

    This article explains how to restrict files from being uploaded or downloaded based on their file name extension.

  • Lock or unlock site collections (SharePoint Foundation 2010)

    This article explains how to add or remove a lock from a site collection.

See Also

Concepts

Operations for SharePoint Foundation 2010


Delete a site collection (SharePoint Foundation 2010)
See Also

You might want to delete a site collection if it is no longer needed. For example, if you created a team site to track progress on a specific project, and the project has ended, you might decide to delete the site collection after a certain amount of time has passed.

When you delete a site collection, you are deleting a hierarchy of sites that comprise the collection. When you delete a site collection, you permanently destroy all content and user information, such as the following:

  • Documents and document libraries,

  • Lists and list data, including surveys, discussions, announcements, and events,

  • Site configuration settings,

  • Role and security information that is related to the Web site,

  • Subsites of the top-level Web site, their contents, and user information.

Note:

You should back up a site collection before you delete it. For more information about how to back up a site collection, see Plan for backup and recovery (SharePoint Foundation 2010).

Before you delete a site collection, ensure that the following prerequisites are available:

  • A backup copy of the site collection and all of its contents exists.

In this article:

  • Delete a site collection by using Central Administration

  • Delete a site collection by using Windows PowerShell

Delete a site collection by using Central Administration

After you perform this procedure, the site collection and all of its content and user information will be permanently destroyed.

To delete a site collection by using Central Administration

  1. Verify that you have the following administrative credentials:

    • To delete a site collection, the user account that is performing this procedure must be a member of the Farm Administrators SharePoint group.

  2. On the Central Administration Web site, on the Quick Launch, click Application Management

  3. On the Application Management page, in the Site Collections section, click Delete a site collection.

  4. On the Delete Site Collection page, in the Site Collection drop-down list, click the down arrow, and then click Change Site Collection.

    The Select Site Collection dialog box appears.

  5. In the Web Application drop-down list, click the down arrow, and then click Change Web Application.

    The Select Web Application dialog box appears.

  6. Click the name of the Web application that contains the site collection that you want to delete. Relative URLs of sites in the site collections of the Web application that you have selected appear on the Select Site Collection dialog box.

  7. Click the relative URL of the site collection that you want to delete, and then click OK.

  8. Read the Warning section and verify that the site collection information is correct.

  9. On the Delete Site Collection page, click Delete.

    The site collection that you select is deleted.

Delete a site collection by using Windows PowerShell

After you perform this procedure, the site collection and all of its content and user information will be permanently destroyed.

To delete 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 window (that is, PS C:\>), type the following command and press ENTER:

    Copy Code
    Remove-SPSite -Identity "<URL>" -GradualDelete

    Where:

    1. <URL> is the URL of the site collection you want to delete.

    This command removes the specified site collection and all subsites. Gradual deletion reduces the load on the system during the deletion process.

    The previous procedure illustrates a common way of using the Remove-SPSite cmdlet to delete a site collection. You can specify different parameters to configure this command differently. For more information, see Remove-SPSite.

    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.

See Also

Concepts

Create a site collection (SharePoint Foundation 2010)


Configure a connection to a portal site (SharePoint Foundation 2010)

Published: October 7, 2010

A portal site connection can be used to link one site collection to another site collection. For example, if you have a main site collection that you want to provide a link to, you can configure a portal site connection that points to the main site collection. The portal site is added to the global breadcrumb navigation for the current site collection. When site collection users click the up folder, the portal site is listed as the parent of the site collection. This enables users to navigate to the portal site more easily.

Configure a connection to a portal site

A portal site connection can help site collection users navigate to the portal site more easily. Users will see the portal site when they click the up folder.

To configure a connection to a portal site

  1. Verify that you meet the following minimum requirements:

    • You must be the site collection administrator.

  2. Browse to the site collection where you want to create a connection to a portal site.

  3. On the Site Actions menu, click Site Settings.

  4. On the Site Settings page, in the Site Collection Administration section, click Portal Site Connection.

  5. On the Portal Site Connection page, select Connect to portal site.

  6. In the Portal Web Address box, type the URL for the portal site.

    Tip:

    The portal site is the site collection that you want to create a link to. The portal site will be added to the global breadcrumb navigation for the current site collection.

  7. In the Portal Name box, type the name of the portal site.

  8. Click OK.


View all site collections (SharePoint Foundation 2010)

A site collection is a group of Web sites that have the same owner and share administration settings, for example, permissions. Site collections are created within a Web application. 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. The entire structure of the top-level site and all its subsites is called a site collection.

View the site collections in a Web application

Use the following procedures to view all the site collections in a Web application.

To view all site collections by using Central Administration

  1. Verify that you have the following administrative credentials:

    • To view all site collections, you must be a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.

  2. On the Central Administration home page, click Application Management.

  3. On the Application Management page, in the Site Collections section, click View all site collections.

    The Site Collection List page lists all the site collections in the Web application.

  4. To display more information about a site collection, in the URL column, click the site collection.

    The following information about the site collection appears in a table on the right side of the page.

    Item Description

    URL

    The URL of the site collection.

    Title

    The title that was provided when the site collection was created.

    Description

    The description that was provided when the site collection was created.

    Primary administrator

    The primary administrator for the site collection.

    E-mail address

    The e-mail address for the primary administrator.

    Database name

    The content database that is used by the site collection.

  5. If you want to change the selected Web application, click the Web Application box, and then click Change Web Application. Use the Select Web Application page to select another Web application.

To view all site collections 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Get-SPWebApplication "<WebApplicationURL>" | Get-SPSite | Format-Table -Property URL,ContentDatabase

    Where <WebApplicationURL> is the URL of the Web application whose site collections you want to view.

For more information, see Get-SPWebApplication and Get-SPSite.

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.


Add or remove site collection administrators (SharePoint Foundation 2010)

This article describes how to add and remove site collection administrators. A site collection administrator can configure the appearance and behavior of the site, configure search settings and site directory settings, and allocate storage space. A site collection can have one or two administrators.

In this article:

  • Add a site collection administrator

  • Remove a site collection administrator

Add a site collection administrator

Use this procedure when you want to make a user a site collection administrator for a specific site collection.

Caution:

A site collection can have only two administrators. The steps in this procedure describe how to change the secondary site collection administrator. This leaves the primary site collection administrator unchanged, and removes the previous secondary site collection administrator if there was a secondary site collection administrator.

To add a site collection administrator by using Central Administration

  1. Verify that you have the following administrative credentials:

    • To add a site collection administrator, you must be a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.

  2. On the home page of the SharePoint Central Administration Web site, select Application Management.

  3. On the Application Management page, under Site Collections, select Change site collection administrators.

  4. On the Site Collection Administrators page, click the arrow next to the site collection name and select Change Site Collection.

  5. If the site collection to which you want to add an administrator is listed, select the URL of the site collection and then click OK. If the site collection is not listed, click the arrow next to the Web application name; click Change Web Application; select the name of the Web application that contains the site collection; select the URL of the site collection; and then click OK.

  6. In the Secondary Site Collection Administrator area, either type the name of the user whom you want to add by using the format <domain>\<username> or select the user by using the address book.

  7. Click OK.

To add a site collection administrator 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. At the Windows PowerShell command prompt, type the following command to replace the secondary site collection administrator:

    Copy Code
    Set-SPSite -Identity "<SiteCollection>" -SecondaryOwnerAlias "<User>"

    Where:

    • <SiteCollection> is the URL of the site collection to which you want to add a site collection administrator.

    • <User> is name of the user whom you want to add in the format <domain>\<username>.

The previous procedure shows a common way to use the Set-SPSite cmdlet to add a site collection administrator. You can specify different parameters to configure different settings for a site collection. For more information, see Set-SPSite.

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.

Remove a site collection administrator

Use this procedure to specify the user to be removed from the site collection administrator list. This procedure does not remove the user from Active Directory Domain Services (AD DS).

To remove a site collection administrator by using Central Administration

  1. Verify that you have the following administrative credentials:

    • To remove a site collection administrator, you must be a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.

  2. On the home page of the SharePoint Central Administration Web site, select Application Management.

  3. On the Application Management page, under Site Collections, select Change site collection administrators.

  4. On the Site Collection Administrators page, click the arrow next to the site collection name and select Change Site Collection.

  5. If the site collection from which you want to remove an administrator is listed, select the URL of the site collection and then click OK. If the site collection is not listed, click the arrow next to the Web application name; click Change Web Application; select the name of the Web application that contains the site collection; select the URL of the site collection; and then click OK.

  6. Every site collection must have a primary site collection administrator. If you want to remove the primary site collection administrator, you must replace it with a different primary site collection administrator. To do so, select the current administrator's name; press the Delete key; and then either type the name of the replacement site collection administrator by using the format <domain>\<username> or select a replacement site collection administrator by using the address book.

  7. To remove the secondary site collection administrator, select the administrator's name, and then press the Delete key.

  8. Click OK.


Create, edit, and delete quota templates (SharePoint Foundation 2010)

A quota template consists of storage limit values that specify the maximum amount of data that can be stored in a site collection. When the storage limit is reached, a quota template can also trigger an e-mail alert to the site collection administrator. You can create a quota template that can be applied to any site collection in the farm.

Note:

When you apply a quota template to a site collection, the storage limit applies to the site collection as a whole. In other words, the storage limit applies to the sum of the content sizes for the top-level site and all subsites within the site collection.

For more information, see Create a site collection (SharePoint Foundation 2010) and Manage site collection storage limits (SharePoint Foundation 2010).

You can also apply quota templates to a site collection that contains sandboxed solutions. A sandbox is a restricted execution environment that enables programs to access only certain resources, and that keeps problems that occur in the sandbox from affecting the rest of the server environment. You can limit the maximum usage per day and send a warning e-mail message when the usage limit is approaching. If the maximum usage limit is reached, the sandboxed solution is disabled for the rest of the day, and an e-mail message is sent to the site collection administrator.

You can also modify existing quota templates. This allows you to modify storage limits for all of the site collections that use the same quota template. When you modify a quota template, you must then reapply it to existing site collections before the new storage limits are enforced.

You can delete a quota template if necessary. However, deleting a quota template will not delete quota values from sites that were created by using the quota template. If you want to remove quotas from all sites by using a specific quota template, you must use the object model or perform a SQL query.

Task requirements

Before you perform this procedure, confirm the following:

  • Your system is running either the Standard or Enterprise version of Microsoft SharePoint Foundation 2010.

  • Outgoing e-mail is configured.

    For more information, see Configure outgoing e-mail (SharePoint Foundation 2010).

  • The Disk Quota Warning timer job is running.

In this article:

  • Create a quota template

  • Edit a quota template

  • Delete a quota template

Create a quota template

You might want to create a quota template to apply to sites that have storage and performance requirements that differ from most other sites in the site collection.

To create a quota template

  1. Verify that you have the following administrative credentials:

    • You are a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.

  2. On the Central Administration home page, click Application Management.

  3. On the Application Management page, in the Site Collections section, click Specify quota templates.

  4. On the Quota Templates page, in the Template Name section, click Create a new quota template.

  5. In the New template name box, type the name of the new template.

    If you want to base your new template on an existing quota template, expand the Template to start from list, and then click the template that you want.

  6. In the Storage Limit Values section, set the values that you want to apply to the template.

    • If you want to restrict how much data that can be stored, click the Limit site storage to a maximum of check box and type the storage limit in megabytes into the box.

    • If you want an e-mail message to be sent to the site collection administrator when a certain storage threshold is reached, click the Send warning E-mail when Site Collection storage reaches check box and type the threshold in megabytes into the box.

  7. In the Sandboxed Solutions with Code Limits section, set the values for a template for sandboxed solutions.

    1. In the Limit maximum usage per day to box, type the daily usage in points.

    2. In the Send warning e-mail when usage per day reaches box, type the daily usage warning limit in points.

      A point is a relative measurement of resource usage, for example, CPU cycles, memory, or page faults. Points enable comparisons between measurements of resource usage that could not be compared otherwise.

      For more information, see Sandboxed solutions overview (SharePoint Foundation 2010).

      If you do not want to send a warning e-mail message, clear the Send warning e-mail when usage per day reaches check box.

  8. Click OK.

Edit a quota template

You might want to edit a quota template to increase the storage limit if you find that sites are exceeding the current storage limit on a regular basis.

To edit a quota template

  1. Verify that you have the following administrative credentials:

    • You are a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.

  2. On the Central Administration home page, click Application Management.

  3. On the Application Management page, in the Site Collections section, click Specify quota templates.

  4. On the Quota Templates page, in the Template Name section, expand the Template to modify list, and then click the template that you want to edit.

  5. Change the settings as necessary, and then click OK.

Delete a quota template

You might want to delete a quota template when the site collection that required those specific settings is deleted.

To delete a quota template

  1. Verify that you have the following administrative credentials:

    • You are a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.

  2. On the Central Administration home page, click Application Management.

  3. On the Application Management page, in the Site Collections section, click Specify quota templates.

  4. In the Template Name section, expand the Template to modify list, and then click the template that you want to delete.

  5. At the bottom of the Quota Templates page, click Delete, and then click OK.


Manage site collection storage limits (SharePoint Foundation 2010)
See Also

A quota specifies the storage limit values for the maximum amount of data that can be stored in a site collection. Quotas also specify the storage size that, when reached, triggers an e-mail alert to the site collection administrator. Quotas can be saved as quota templates, which can then be applied to any site collection in a SharePoint farm. Using quota templates rather than individual quotas can simplify setting storage limits on new site collections. For more information about how to plan quotas, see Plan quota management (SharePoint Foundation 2010).

Note:

The storage limit applies to the site collection as a whole. In other words, the storage limit applies to the total size of the content for the top-level site and for all subsites within the site collection. If versioning is enabled, the versions in a site and the content in the Recycle Bins count toward storage limits. You can also specify a percentage of storage limits for the second-stage Recycle Bin. For more information about Recycle Bin settings, see Configure Recycle Bin settings (SharePoint Foundation 2010).

When the site collection reaches the maximum storage level, an e-mail message that contains information about the issue is sent to the site collection administrator. The site collection administrator can either delete unused content from the site collection or ask a member of the Farm Administrators group to increase the limits. A farm administrator can do any of the following to change the limits:

  • Change the storage limit on the quota template that the site collection is using.

    Important:

    The modified quota template will not be automatically applied to any existing site collections that use the quota template. A member of the Farm Administrators group must manually apply all modified values to all existing sites that use the quota template.

  • Designate a new quota template that has a higher storage limit to the site collection. This automatically increases the limits for the site collection to the limits in the newly designated quota template. This is the preferred method, because the settings in the new quota template are automatically applied to the site collection and no additional action is needed.

  • Change the storage limit for the site collection manually. This overrides the limits set in the quota template that is currently applied to the site collection.

In this article:

  • Change the settings of a quota template

  • Change the quota template for a site collection

  • Change the storage limits for a site collection

Change the settings of a quota template

You must have already created one or more quota templates for these options to be available in Central Administration. The first time that you use this page, you will be given only the option to create a new template.

Note:

The modified quota template is not automatically applied to any existing site collections that use the quota template. A member of the Farm Administrators group must manually apply all modified values to all existing sites that use the quota template.

To change the settings of a quota template by using Central Administration

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators group.

  2. On the Central Administration home page, click Application Management.

  3. On the Application Management page, in the Site Collections section, click Specify quota templates.

  4. On the Quota Templates page, in the Template Name section, in the Template to modify list, select the template that you want to change.

  5. In the Storage Limit Values section, specify the values that you want to apply to the template.

    • If you want to modify the amount of data that can be stored in the database, leave the Limit site storage to a maximum of check box selected, and then type the new storage limit, in megabytes, in the box.

    • If you want an e-mail message to be sent to the site collection administrator when a storage threshold is reached, select the Send warning E-mail when site storage reaches check box, and then type the threshold, in megabytes, in the box.

  6. In the Sandboxed Solutions With Code Limits section, specify the values that you want to apply to the template.

    • If you want to limit the maximum resource usage points per day for sandboxed solutions that contain code, type the new limit in the Limit maximum usage per day to box. The default limit is 300 points.

    • If you want an e-mail message to be sent to the site collection administrator when the usage per day threshold is reached, select the Send warning e-mail when usage per day reaches check box, and then type the threshold, in points, in the box.

  7. Click OK.

Change the quota template for a site collection

If a site collection is close to exceeding its storage limits and you want to increase its size, you can change the quota template that is applied to the site collection to a quota template that has higher limits. This automatically updates the warning and storage limits for the site collection.

To change the quota template for a site collection by using Central Administration

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators group.

  2. On the Central Administration home page, click Application Management.

  3. On the Application Management page, in the Site Collections section, click Configure quotas and locks.

  4. On the Site Collection Quotas and Locks page, ensure that the correct site collection is displayed. If you want to change the site collection, expand the Site Collection list, and then click Change Site Collection. Use the Select Site Collection page to select a site collection.

  5. In the Site Quota Information section, expand the Current quota template list, and then select the new quota template to apply.

  6. Click OK.

To change the quota template for a site collection by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. Click Start, and then 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:

    Copy Code
    Set-SPSite -Identity "<Site>" -QuotaTemplate "<Template>"

    Where:

    • <Site> is the URL or GUID of the site collection whose quota template you want to change.

    • <Template> is the name or GUID of the replacement quota template.

For more information, see Set-SPSite.

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.

Change the storage limits for a site collection

Use these procedures to change the storage limits for a site collection.

To change the storage limits for a site collection by using Central Administration

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators group.

  2. On the Central Administration home page, click Application Management.

  3. On the Application Management page, in the Site Collections section, click Configure quotas and locks.

  4. On the Site Collection and Quota Locks page, ensure that the correct site collection is displayed. If you want to change the site collection, in the Site Collection section, expand the Site Collection list, and then click Change Site Collection. Use the Select Site Collection page to select a site collection.

  5. If the site collection currently uses a quota template, do the following to specify an individual quota:

    • On the Site Collection Quotas and Locks page, in the Site Quota Information section, expand the Current quota template list, and then select Individual Quota.

  6. Leave the Limit site storage to a maximum of check box selected, and then type the new maximum value in megabytes.

  7. If you want to send site storage notification e-mail messages to the site collection administrator, select the Send warning e-mail when site storage reaches check box, and then type the value in megabytes.

  8. If you want to limit the maximum resource usage points per day for sandboxed solutions, type the new limit in the Limit maximum usage per day to box. The default is 300 points.

  9. If you want an e-mail message to be sent to the site collection administrator when the usage per day threshold is reached, select the Send warning e-mail when usage per day reaches check box, and then type the threshold, in points, in the box. The default is 100 points.

  10. Click OK.

To change the storage limits for a site collection by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. Click Start, and then 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:

    Copy Code
    Set-SPSite -Identity "<Site>" -MaxSize <Limit>

    Where:

    • <Site> is the URL of the site collection whose storage limits you want to change.

    • <Limit> is the new storage limit for the site collection, in megabytes.

      Note:

      The new storage limit overrides the limit set in the quota template that is currently applied to the site collection.

      For more information about the Set-SPSite cmdlet, see Set-SPSite.

    For information about how to use Windows PowerShell and the SharePoint object model to set the maximum usage per day and the warning level threshold for sandboxed solutions, see "Using Windows PowerShell for Administration" in Chapter 4: Sandboxed Solutions (http://go.microsoft.com/fwlink/p/?LinkId=219528), an excerpt from the book Inside Microsoft SharePoint 2010 on MSDN.

See Also

Concepts

Create, edit, and delete quota templates (SharePoint Foundation 2010)


Manage blocked file types (SharePoint Foundation 2010)

You can restrict certain file types from being uploaded or downloaded. Each Web application maintains a list of blocked file types that is based on file name extensions. For example, you can block files that have the .exe extension because those files can be run on the client computer and can contain malicious code.

By default, many file types are blocked, including file types that are treated as executable by Internet Explorer. Files, whose names include braces, (for example, filename.{doc}) are also blocked by default.

The following table shows the file types that are blocked by default and their corresponding file name extensions.

File name extension | File type
.ade | Microsoft Access project extension
.adp | Microsoft Access project
.app | Application file
.asa | ASP declarations file
.ashx | ASP.NET Web handler file. Web handlers are software modules that handle raw HTTP requests received by ASP.NET.
.asmx | ASP.NET Web Services source file
.asp | Active Server Pages
.bas | Microsoft Visual Basic class module
.bat | Batch file
.cdx | Compound index
.cer | Certificate file
.chm | Compiled HTML Help file
.class | Java class file
.cmd | Microsoft Windows NT command script
.com | Microsoft MS-DOS program
.config | Configuration file
.cpl | Control Panel extension
.crt | Security certificate
.csh | Script file
.dll | Windows dynamic-link library
.exe | Program
.fxp | Microsoft Visual FoxPro compiled program
.hlp | Help file
.hta | HTML program
.htr | Script file
.htw | HTML document
.ida | Internet Information Services file
.idc | Internet database connector file
.idq | Internet data query file
.ins | Internet Naming Service
.isp | Internet Communication settings
.its | Internet Document Set file
.jse | JScript Encoded script file
.ksh | Korn Shell script file
.lnk | Shortcut
.mad | Shortcut
.maf | Shortcut
.mag | Shortcut
.mam | Shortcut
.maq | Shortcut
.mar | Shortcut
.mas | Microsoft Access stored procedure
.mat | Shortcut
.mau | Shortcut
.mav | Shortcut
.maw | Shortcut
.mda | Microsoft Access add-in program
.mdb | Microsoft Access program
.mde | Microsoft Access MDE database
.mdt | Microsoft Access data file
.mdw | Microsoft Access workgroup
.mdz | Microsoft Access wizard program
.msc | Microsoft Common Console document
.msh | Microsoft Agent script helper
.msh1 | Microsoft Agent script helper
.msh1xml | Microsoft Agent script helper
.msh2 | Microsoft Agent script helper
.msh2xml | Microsoft Agent script helper
.mshxml | Microsoft Agent script helper
.msi | Microsoft Windows Installer package
.msp | Windows Installer patch package file
.mst | Visual Test source files
.ops | Microsoft Office profile settings file
.pcd | Photo CD image or Microsoft Visual Test compiled script
.pif | Shortcut to MS-DOS program
.prf | System file
.prg | Program source file
.printer | Printer file
.pst | Microsoft Outlook personal folder file
.reg | Registration entries
.rem | ACT! database maintenance file
.scf | Windows Explorer command file
.scr | Screen saver
.sct | Script file
.shb | Windows shortcut
.shs | Shell Scrap object
.shtm | HTML file that contains server-side directives
.shtml | HTML file that contains server-side directives
.soap | Simple Object Access Protocol file
.stm | HTML file that contains server-side directives
.url | Uniform Resource Locator (Internet shortcut)
.vb | Microsoft Visual Basic Scripting Edition file
.vbe | VBScript Encoded Script file
.vbs | VBScript file
.ws | Windows Script file
.wsc | Windows Script Component
.wsf | Windows Script file
.wsh | Windows Script Host settings file

Add or remove blocked file types

Use this procedure when you want to prohibit files of a specific type from being saved or retrieved from any Web application on a server.

To add or remove blocked file types by using Central Administration

  1. Verify that you have the following administrative credentials.

    • You must be a farm administrator on the server.

  2. In Central Administration, click Security.

  3. On the Security page, in the General Security section, click Define blocked file types.

  4. On the Blocked File Types page, if you want to change the selected Web application, on the Web Application menu, click Change Web Application. Use the Select Web Application page to select a Web application.

  5. Do one of the following:

    • To block an additional file type, scroll to the bottom of the Type each file extension on a separate line text box, type the file extension you want to block, and then click OK.

      Note:

      You do not have to type a file extension in the list in alphabetical order. The next time you open the list, the file extension you added will be correctly sorted in alphabetical order.

    • To stop blocking a file type, select a file type from the list, press the Delete key, and then click OK.


Lock or unlock site collections (SharePoint Foundation 2010)

You can apply locks to a site collection to prevent users from updating content or you can temporarily prevent users from accessing the site collection.

The following table describes the locking options that are available in Microsoft SharePoint Foundation 2010.

Option | Description
Not locked | Unlocks the site collection and makes it available to users.
Adding content prevented | Prevents users from adding new content to the site collection. Updates and deletions are still allowed.
Read-only (prevents additions, updates, and deletions) | Prevents users from adding, updating, or deleting content.
No access | Prevents users from accessing the site collection and its content. Users who attempt to access the site receive an error.
Note:

If you want to limit the amount of content that can be stored in a site collection, you can apply a quota template to the site collection. When the content storage limit that is specified in the quota template is reached, the site collection is locked automatically until the storage limit quota has been increased or some content has been removed. For more information, see Create, edit, and delete quota templates (SharePoint Foundation 2010).

Follow these steps to lock or unlock a site collection.

To lock or unlock a site collection by using Central Administration

  1. Verify that you have the following administrative credentials.

    • You must be a member of the Site Collection Administrators group for the site collection.

  2. In Central Administration, click Application Management.

  3. On the Application Management page, in the Site Collections section, click Configure quotas and locks.

  4. If the site collection you want isn't already selected, in the Site Collection section, on the Site Collection menu, click Change Site Collection. Use the Select Site Collection page to select a site collection.

  5. On the Site Collection Quotas and Locks page, in the Site Lock Information section, select one of the following options:

    • Not locked to unlock the site collection and make it available to users.

    • Adding content prevented to prevent users from adding new content to the site collection. Updates and deletions are still allowed.

    • Read-only (blocks additions, updates, and deletions) to prevent users from adding, updating, or deleting content.

    • No access to prevent users from accessing the site collection and its content. Users who attempt to access the site receive an error.

  6. If you select Adding content prevented, Read-only (blocks additions, updates, and deletions), or No access, type a reason for the lock in the Additional lock information box.

  7. Click OK.

To lock or unlock 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Set-SPSite -Identity "<SiteCollection>" -LockState "<State>"

    Where:

    • <SiteCollection> is the URL of the site collection that you want to lock or unlock.

    • <State> is one of the following values:

      • Unlock to unlock the site collection and make it available to users.

      • NoAdditions to prevent users from adding new content to the site collection. Updates and deletions are still allowed.

      • ReadOnly to prevent users from adding, updating, or deleting content.

      • NoAccess to prevent users from accessing the site collection and its content. Users who attempt to access the site receive an error.

Note:

For more information about how to use the Set-SPSite cmdlet, see Set-SPSite.


Restore a deleted site collection (SharePoint Foundation 2010)

Published: June 28, 2011

This article describes new functionality of how to restore a deleted site collection in Microsoft SharePoint Foundation 2010 with Service Pack 1.

In prior versions of SharePoint Foundation 2010, if a site collection (that is, an SPSite object) was accidentally deleted, there was not a direct way of restoring a specific deleted site collection. The only method to restore a deleted site collection was to restore the entire farm from a backup. This was costly and time consuming, and typically was not performed.

When a site collection is accidentally deleted in SharePoint Foundation 2010 with SP1, the deleted site collection is stored in the SPDeletedSite object, not the SPSite object. Therefore, to restore a deleted site collection, you must use the Restore-SPDeletedSite Windows PowerShell cmdlet or programmatically access the object model.

For examples of how to use the SPDeletedSite cmdlets, see Site management cmdlets (SharePoint Foundation 2010).


Manage sites (SharePoint Foundation 2010)

This section describes how to manage Web sites in Microsoft SharePoint Foundation 2010.

  • Manage unused Web sites (SharePoint Foundation 2010)

    This article explains how to release, either automatically or in response to notification from a site collection administrator, the storage space allocated to inactive sites.

  • Restore a deleted site (SharePoint Foundation 2010)

    This article explains how to restore an accidentally deleted site using functionality introduced in Microsoft SharePoint Foundation 2010 with Service Pack 1 (SP1).


Manage unused Web sites (SharePoint Foundation 2010)
See Also

Site usage confirmation and deletion can help to free resources that are used by sites that are no longer needed. Site collections can be deleted automatically after a specified period of inactivity or can depend on the site collection owner's response to a notification.

Note:

To send e-mail notifications, you must configure outgoing e-mail settings. For more information, see Configure outgoing e-mail (SharePoint Foundation 2010).

Before completing the procedure in this topic, you should determine the following:

  • How long to wait before you check whether a site is inactive.

    The default time period for team sites or for project sites is 90 days after site creation. You can also set the time period that is given to site collection owners. You can give site collection owners a minimum of 30 days and a maximum of 365 days as the notice period.

  • How often to send e-mail notifications to site owners to see whether their sites are inactive.

    After the first e-mail notification, if the site owner does not respond, you can continue to send additional notices at daily, weekly, or monthly intervals.

  • Whether you want to automatically delete unused sites or delete a site if the site owner does not respond to multiple e-mail notifications.

    If you delete sites without an owner's approval, we recommend that you first back up the site. You can customize this functionality so that it automatically backs up a site before deletion by using the SharePoint 2010 Software Development Kit (SDK) (http://go.microsoft.com/fwlink/?LinkID=166675).

  • If you plan to automatically delete unused sites, how many e-mail notifications will you send to the site owner before you do so?

    By default, 28 daily notices are sent before site deletion. You can configure this number from a minimum of 28 notices to a maximum of 168 notices. For weekly notices, you can send a minimum of four notices and a maximum of 24 notices. For monthly notices, you can send a minimum of two notices and a maximum of six notices to site owners.

    The e-mail notification contains links to confirm whether a site collection is active or inactive. After an e-mail notification is sent to the site collection owner, there are three possible outcomes:

    • If the site collection owner confirms that the site collection is active by clicking the confirmation link in the e-mail notification, the certification date of the site is renewed.

    • The site collection owner continues to receive periodic e-mail notifications according to the interval specified by a member of the Farm Administrators group, until the site collection owner confirms that the site collection is active or deletes the site collection.

    • If the site collection is not active, and a member of the Farm Administrators group has turned on the automatic deletion feature, e-mail notifications are sent to the site collection owner for the specified number of times. If the site collection owner does not confirm the status of the site collection, the site collection is deleted automatically.

We recommend the following best practices to safeguard against the automatic deletion of a site:

  • Require a secondary site collection owner when users create site collections.

    By default, the site collection creator is listed as primary site collection owner. A site collection owner can also specify a secondary site collection owner. Confirmation notifications are automatically sent to the primary and the secondary site collection owners.

  • Keep the organization informed about vacations and leave a contingency plan.

    For example, if a site collection owner is unavailable for four weeks, and a member of the Farm Administrators group has set the site collection and deletion policy, after four missed weekly confirmations, the site could be deleted without giving the site collection owner an opportunity to confirm the usage of the site.

  • Ensure that there is a schedule to back up site collections regularly so that you can restore a recent copy if a site collection is deleted.

    Note:

    Automatic deletion permanently removes all the content and information from the site collection and any sites within the site collection.

Manage unused Web sites

Use this procedure to manage unused Web sites. You can follow these steps to determine the schedules for notifying owners of site inactivity before deleting unused sites.

To manage unused Web sites

  1. Verify that you meet the following minimum requirements:

    • You must be a member of the Farm Administrators group.

  2. On the Central Administration home page, click Application Management.

  3. On the Application Management page, in the Site Collections section, click Confirm site use and deletion.

  4. On the Site Use Confirmation and Deletion page, in the Web Application section, if the Web application that you want to configure is not listed, expand the Web Application list, and then click Change Web Application.

    On the Select Web Application dialog box, click the Web application that you want to configure.

  5. In the Confirmation and Automatic Deletion Settings section:

    • Select or clear the Send e-mail notification to owners of unused site collections check box.

      If you select this check box, type the number of days, after the site creation or after the site usage is confirmed, to start to send notifications. The minimum number of days is 30, and the maximum is 365.

    • Specify a daily, weekly, or monthly schedule for e-mail notifications. The default schedule is daily. You can also specify the exact time to run the check for the site usage. The default, time is midnight.

    • Select or clear the Automatically delete the site collection if use is not confirmed check box.

      If you select this check box, type the number of notifications to send before the site collection is deleted. By default, it is 28 notifications.

  6. Click OK.

See Also

Concepts

Restore a deleted site (SharePoint Foundation 2010)


Restore a deleted site (SharePoint Foundation 2010)

Published: June 28, 2011

This article describes new functionality of how to restore a deleted site in Microsoft SharePoint Foundation 2010 with Service Pack 1.

In prior versions of SharePoint Foundation 2010, if a site (that is, an SPWeb object) was accidentally deleted, there was not a direct way of restoring a specific deleted site. The only method to restore a deleted site was to restore the entire farm from a backup. This was costly and time consuming, and typically was not performed.

In Microsoft SharePoint Foundation 2010 with Service Pack 1 (SP1), a deleted site is not permanently deleted. Instead, it is stored in the second-stage Recycle Bin. By default, the Delete item in Recycle Bin setting is set for 30 days, which means a deleted site will be permanently removed from the farm after the time value expires. The value of the Delete item in Recycle Bin setting can be increased if more time is needed to retain the deleted site.

For more information, see Configure Recycle Bin settings (SharePoint Foundation 2010).

At any point before the default time value expires, a site collection administrator can simply use Central Administration to restore the deleted site.

Before you restore a site, be aware of the following known behaviors:

  • Any content types that were added while the site was in the Recycle Bin are skipped, so field definitions might not be up-to-date.

  • Content deployment will not work for a deleted site while in the Recycle Bin. To resolve it, scoped deployment must be run for this site.

  • When an update package or QFE is installed, the update package will skip the site while it is still located in the Recycle Bin. To resolve this issue, update the site afterwards.

To restore a deleted site from the second-stage Recycle Bin

  1. Verify that the user account that is performing this procedure has the Site Collection Administrator permission.

  2. In Central Administration, on the Home page, click Site Actions and then click Site Actions.

  3. On the Site Actions page, click Site Collection Administration.

  4. On the Site Collection Administration page, click Recycle Bin.

  5. On the Recycle Bin page, click the check box for the deleted site you want to restore.

  6. Click OK.


Manage Web Parts (SharePoint Foundation 2010)

Web Parts are modular elements that present information on pages of SharePoint sites. For more information about Web Parts, read the Web Parts in Windows SharePoint Services (http://go.microsoft.com/fwlink/p/?LinkId=184240) section of the SharePoint Foundation 2010 SDK.

This article helps you prepare to manage security for Web Parts pages and controls that are used with SharePoint Foundation 2010.

In Microsoft SharePoint Foundation, a Web Parts page is a collection of Web Parts that combines list data, timely information, or useful graphics into a dynamic Web page. The layout and content of a Web Parts page can be set for all users and optionally personalized for individual users. A site owner or a site member with the appropriate permissions can create and customize Web Parts pages by using a browser to add, reconfigure, or remove Web Parts.

Web Parts are not restricted to use only on Web Parts pages. They can be added directly to wiki pages, content pages, and publishing pages.

Web Parts in SharePoint Foundation can be configured to run in sandboxed solutions. Sandboxed solutions prevent the Web Part from accessing certain local or network resources, which protects other content and solutions on the SharePoint Foundation farm. By implementing sandboxed solutions, users can add their own Web Parts in a hosted environment, and developers can add Web Parts that have not yet been thoroughly tested for production use.

For more information about sandboxed solutions, see Sandboxed solutions planning (SharePoint Foundation 2010).

The Web Parts infrastructure in SharePoint Foundation exists on a layer above the ASP.NET Web Parts infrastructure. To effectively protect SharePoint sites, server administrators must be familiar with security guidelines and best practices for ASP.NET. For more information, see Security Guidelines: ASP.NET 2.0 (http://go.microsoft.com/fwlink/p/?LinkId=103423) in the MSDN Library Online.

Security for Web Parts pages and controls

Protecting Web Parts pages and controls is a collaborative effort. Developers, site administrators, and server administrators must work together to improve security for Web Parts and Web Parts pages. Developers should validate Web Part input to prevent server attacks. Server administrators must configure Internet Information Services (IIS) to use an appropriate authentication method.

Server administrators also configure and deploy Web Parts solutions to a Web server or Web farm. After the solution is deployed, site administrators or server administrators define the permission levels and permissions that allow access to Web Parts pages.

The following table shows the security roles responsible for configuring permissions on Web Parts pages and Web Parts.

Role Category Applies to Description Recommended guidelines

Developer

Input Validation

Web Part code

Input validation refers to how your application filters, scrubs, or rejects input before additional processing. This includes verification that the input that your application receives is valid and safe.

Building Secure ASP.NET Pages and Controls (http://go.microsoft.com/fwlink/p/?LinkId=103424) (MSDN Library Online)

Walkthrough: Creating a Basic SharePoint Web Part (http://go.microsoft.com/fwlink/p/?LinkId=103425) (MSDN Library Online)

Server administrator

Authentication

IIS

Authentication is the process where an entity validates the identity of another entity, typically through credentials such as a user name and password.

Plan authentication (SharePoint Foundation 2010)

Site administrator/ Server administrator

Authorization

Site collections

Authorization is the process that provides access controls for Web sites, lists, folders, or items by determining which users can perform specific actions on a given object. The authorization process assumes that the user has already been authenticated.

Authorization and Authentication (http://go.microsoft.com/fwlink/p/?LinkId=103428) (MSDN Library Online)

Server administrator

Configuration Management

.NET Framework configuration

Configuration management encompasses a broad range of settings that allow an administrator to manage the Web application and its environment. These settings are stored in XML configuration files, some of which control computer-wide settings, while others control application-specific configurations. You can define special security constraints in configuration files and computer-level code access security permissions.

"Code Access Security" in "Securing Your Web Server" (http://go.microsoft.com/fwlink/p/?LinkId=103431) (MSDN Library Online)

Microsoft Windows SharePoint Services and Code Access Security (http://go.microsoft.com/fwlink/p/?LinkId=103436) (MSDN Library Online)

Using Code Access Security with ASP.NET (http://go.microsoft.com/fwlink/p/?LinkId=103438) (MSDN Library Online)

In this section

Configure and deploy Web Parts (SharePoint Foundation 2010)


Configure and deploy Web Parts (SharePoint Foundation 2010)

This article provides information and procedures that are required to configure and deploy secure Web Parts to either the Bin directory or the .NET Framework Global Assembly Cache (GAC) on your server.

In this article:

  • Configuration options

  • Setting security attributes

  • Safe Controls list

  • Deploy and configure a Web Part

  • Add a component to the Web Part Gallery

Microsoft SharePoint Foundation includes a set of Web Parts that users can add to pages after installing the product. If an organization needs custom Web Parts, a developer can write custom ASP.NET Web Parts and ask you to install them to a deployment of SharePoint Foundation. This process typically requires testing and approval of the code before the Web Part can be deployed in a full-trust environment. A developer who uses Visual Studio 2010 can deploy a Web Part to SharePoint Foundation by right clicking the project and selecting Deploy. The destination for the Web Part is determined by the trust level established with the server that was running SharePoint when the developer created the project in Visual Studio 2010.

Microsoft SharePoint Foundation 2010 enables you to configure a sandboxed environment where site collection administrators, site administrators, or information workers can deploy and run partially trusted Web Parts and solutions in a sandboxed worker process. Web Parts and solutions that run in a sandboxed environment have limited permissions to access the server operating system and hardware, and they are isolated from other parts of the Web application.

For more information on using sandboxed solutions, see Sandboxed solutions administration (SharePoint Foundation 2010).

SharePoint Foundation uses some of the configuration management settings that are provided by the Microsoft .NET Framework. Some of these settings are stored in XML configuration files and provide a broad range of settings that enable server administrators to manage the Web application and its environment. For more information about ASP.NET configuration files, see Machine.Config and Web.Config Explained (http://go.microsoft.com/fwlink/p/?LinkId=103450&clcid=0x409) in "Securing Your ASP.NET Application and Web Services" in the MSDN Library Online.

Configuration options

System administrators can deploy ASP.NET Web Parts to a deployment of SharePoint Foundation in either of two locations:

  • Bin directory Stored in the bin folder under the root directory of your Web application.

  • Global Assembly Cache (GAC) All standard Web Parts are automatically installed in the GAC, where the common language runtime of the .NET Framework is located, at %windir%\assembly. Web Parts stored in the GAC can be shared across applications.

The following table describes the advantages and disadvantages of each location.

Deployment location Advantages Disadvantages

Bin directory

A partial-trust location. By default, code that runs from this directory has a low level of code access security permissions. If the Web Part requires access across applications or more access than the default permissions allow, the administrator must explicitly raise permissions that are granted to a Web Part so that it can function correctly. Administrators might prefer that assemblies run in the Bin directory, with a known minimum set of required code access security permissions.

Because the Bin directory is specific to a Web application, you can use this method if you want to isolate code to a single Web application.

To run your Web Part everywhere, you must deploy your assembly to the Bin directory on each server.

GAC

A global location where you can deploy signed assemblies, which can run with full trust by default. Because the assemblies are installed globally, they work in any Web application.

Generally, there are no code access security restrictions on code that is installed to the GAC; therefore, you lose the benefit of defense-in-depth security.

Additionally, it can be difficult to deploy your program database (.pdb) files to assemblies in the GAC.

Setting security attributes

ASP.NET Web Parts that are stored in the Bin directory have additional security attributes. You can decide whether to set these attributes for your Web Part, depending on how you plan to use it.

The Bin directory is a partial-trust location. Therefore, your Web Part is not automatically granted full trust code permissions when it is executed. Because the code that calls into your Web Part is granted only partial trust permissions, the Web Part developer must set the AllowPartiallyTrustedCallers attribute on your ASP.NET Web Part.

Marking a component as "safe" with the AllowPartiallyTrustedCallers attribute puts the responsibility for safe implementation on the development team.

By default, code access security permissions for the Bin directory are very low. You should test your Web Parts carefully to determine the correct level of permissions to assign, and to ensure that the Web Part does not present a security risk to your environment.

You can elevate permissions in either of two ways:

  • (Recommended) Create a trust policy file and point your Web.config file at the new file. This option is more complex, but it enables you to set precise permissions for your Web Parts. For more information about trust policy files, see Microsoft Windows SharePoint Services and Code Access Security (http://go.microsoft.com/fwlink/p/?LinkID=103436&clcid=0x409) in the MSDN Library Online.

  • Raise the overall trust level of the Bin directory. In the Web.config file in the root directory of your Web application, locate the trust element. The default value for the trust element's level attribute is WSS_Minimal. You can change this level to WSS_Medium. Although this option is simpler, it grants arbitrary new permissions that you might not need, and it is less secure than creating a trust policy file.

Safe Controls list

A fundamental assumption of SharePoint Products is that untrusted users can upload and create .aspx pages within the system on which SharePoint Foundation is running. These users should be prevented from adding server-side code within .aspx pages, but there should be a list of approved controls that those untrusted users can use. In SharePoint Foundation, this list is provided by the Safe Controls list.

The Safe Controls list contains the names of controls and Web Parts, specific to your SharePoint site, that server administrators can designate as safe for invocation on any .aspx page within a site. This list is part of the Web.config file in your Web application root.

Deploy and configure a Web Part

The method that you use to deploy a new Web Part will depend on the finished package that the developer provides. If the developer provided you with the Web Part as a single dynamic-link library (DLL) file, you can manually deploy the DLL by copying it to your Web application's Bin folder. If the developer provides you with a CAB file containing the Web Part, you can use Windows PowerShell to deploy the Web Part.

To manually deploy and configure a Web Part

  1. Verify that you have the following administrative credentials:

    • You must be a member of the local Administrators group on the server hosting SharePoint Foundation.

  2. Copy the <YourWebPartName>.dll assembly in the project's Bin directory to the Bin directory in your Web application root directory. For example: C:\inetpub\wwwroot\wss\VirtualDirectories\80\.

  3. Locate the Web.config file in your application root directory and open it for editing.

  4. Add the following safe-control entry for your custom assembly to the Web.config file:

    Copy Code
    <SafeControl Assembly="<YourWebPartName>, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null" Namespace="<YourWebPartNamespace>" TypeName="*" Safe="True" AllowRemoteDesigner="True"/>

    Where:

    1. <YourWebPartName> is the name of the Web Part that is being deployed.

    2. <YourWebPartNamespace> is the namespace that is associated with your Web Part.

An alternative to manually installing a Web Part to the Bin folder or manually changing the Web.config file is to use Windows PowerShell to install the Web Part package. For this process to work, a developer or system administrator must create a CAB solution package for the Web Part. For more information about creating a CAB package, see the Solutions and Web Part Packages (http://go.microsoft.com/fwlink/p/?LinkID=95855&clcid=0x409) documentation in the MSDN Library Online. After you create a CAB file, follow these steps to deploy the Web Part.

To deploy the Web Part 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. At the Windows PowerShell command prompt (PS C:\>), type the following command, and then press ENTER:

    Copy Code
    Install-SPWebPartPack -LiteralPath "<PathToCabFile>" -Name "<WebPartName>"

    Where:

    • <PathToCabFile> is the full path to the CAB file that is being deployed.

    • <WebPartName> is the name of the Web Part that is being deployed.

Note:

The previous procedure shows a common way to use Install-SPWebPartPack to deploy a Web Part. You can specify additional parameters to change the way the Web Part is deployed. For more information, see Install-SPWebPartPack.

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.

Add a component to the Web Part Gallery

Every Web Part should have a .webpart file, which is an XML file that describes the Web Part. The .webpart file also causes your Web Part to appear in the Web Part gallery. The following procedure is the easiest way to create a .webpart file after you deploy your Web Part and register it in the Safe Control list.

To add a component to the Web Part gallery

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators group.

  2. To create a .webpart file, navigate to http://<MyServer>/_layouts/newdwp.aspx, where <MyServer> is the name of the server on which your SharePoint site is deployed.

  3. Select the check box next to <YourWebPartNamespace>.<YourWebPartName>.

  4. Click Populate Gallery to add the YourWebPartName Web Part to the Team Site gallery.

  5. In the Web Part gallery, select Edit to edit the Web Part, and then click Import.

    You are prompted to specify a location for the .webpart file. You can also export ASP.NET Web Parts and import them to SharePoint sites.


Business Connectivity Services security operations (SharePoint Foundation 2010)
See Also

Published: September 9, 2010

This article describes security-related administrative tasks for your Business Data Connectivity service application.

In this article:

  • Assign administrators to a Business Data Connectivity service application

  • Set permissions on a metadata store

  • RevertToSelf authentication mode

  • Workflows and external lists

Assign administrators to a Business Data Connectivity service application

Farm administrators can delegate administration of a specific Business Data Connectivity service application to a service application administrator. The delegated administrator is given access to the Central Administration Web site and can perform administrative tasks that are related to that Business Data Connectivity service application.

Tip:

The delegated administrator is not given permissions to the metadata store.

To assign administrators to a Business Data Connectivity service application

  1. Verify that you have the following administrative credentials:

    • You must be a farm administrator.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. In the list of service applications, click the row that contains the Business Data Connectivity service application.

    Note:

    Do not select the row by clicking in the Name column. Clicking the name of the Business Data Connectivity service opens the Business Data Connectivity service management pages.

  4. In the Operations group of the ribbon, click Administrators.

  5. In the text box, type or select a user account or a group account, and then click Add.

  6. In the Permissions box, click Full Control, and then click OK.

Set permissions on a metadata store

Each Business Data Connectivity service application has a metadata store that includes all the models, external systems, external content types, methods, and method instances that have been defined for that store's purpose. You set permissions on a metadata store to specify who can edit items in the metadata store and who can set permissions on the metadata store.

We recommend that you give specific permissions to each user or group that needs it, in such a way that the credentials provide the least privilege that is necessary to perform the needed tasks. For more information about setting permissions, see Business Connectivity Service permissions overview in "Business Connectivity Services security overview (SharePoint Foundation 2010)".

To set permissions on a metadata store

  1. Verify that you have one of the following administrative credentials:

    • You must be a farm administrator.

    • You must be the Business Data Connectivity service application administrator and have Set Permissions permission to the metadata store.

  2. On the Central Administration Web site, in the Application Management section, click Manage service applications.

  3. Click in the Name column of the row that corresponds to the Business Data Connectivity service application.

  4. In the Permissions group of the ribbon, click Set Metadata Store Permissions.

  5. In the text box, type the user accounts, groups, or claims for which permissions will be granted, and then click Add.

    Note:

    The user account, group, or claim cannot have a vertical bar (|) in its name.

  6. Set the permissions for the account, group, or claim:

    Note:

    At least one user, group, or claim in the metadata object's access control list must have the Set Permissions permission.

    • Click Edit to allow the user, group, or claim to create external systems, to create models, to import models, and to export models.

      Security Note:

      The Edit permission should be considered highly privileged. With the Edit permission, a malicious user can steal credentials or corrupt a server farm. To help ensure a secure solution, we recommend that you use a test environment where the Edit permission can be assigned freely to developers and solution designers. When you deploy the tested solution to a production environment, remove the Edit permissions.

    • Click Execute to allow the user, group, or claim to execute operations (create, read, update, delete, or query) on external content types.

      Tip:

      The Execute permission is not applicable to the metadata store itself. This setting is used when you want to propagate the Execute permission to child objects in the metadata store.

    • Click Selectable In Clients to allow the user, group, or claim to create external lists of any external content types and to view the external content types in the external item picker.

      Tip:

      The Selectable In Clients permission is not applicable to the metadata store itself. This setting is used when you want to propagate the Selectable In Clients permission to child objects in the metadata store.

    • Click Set Permissions to allow the user, group, or claim to set permissions on the metadata store.

      Security Note:

      The Set Permissions permission should be considered highly privileged. With the Set Permissions permission, a user can grant Edit permission to the metadata store.

  7. To propagate permissions to all items in the metadata store, click Propagate permissions to all BDC Models, External Systems and External Content Types in the BDC Metadata Store. Doing so will overwrite existing permissions.

RevertToSelf authentication mode

Each external content type has an associated authentication mode. The authentication mode gives Business Connectivity Services information about how to process an incoming authentication request from a user and maps that request to a set of credentials that can be passed to the external system. By default, the RevertToSelf authentication mode (also called BDC Identity authentication mode) is not enabled. You cannot create or import models that use RevertToSelf when RevertToSelf authentication mode is not enabled.

RevertToSelf authentication mode uses the application pool account where the Business Connectivity Services is running to authenticate the logged-on user to the external system. For example, when a user opens an external list, the application pool account of the front-end Web server where the external list resides is used for authentication. The application pool account is a highly privileged account. By default, the application pool account has write permission to the farm configuration database. By using RevertToSelf mode, anyone who can create or edit a model that uses RevertToSelf mode has the power to make themselves an administrator of the SharePoint farm.

RevertToSelf authentication mode is not recommended for production environments. We recommend that you develop a custom, single sign-on provider.

If you must use RevertToSelf authentication mode in a production environment, consider the following:

  • Any users who can create or edit models, including SharePoint Designer users, should be considered equal to a farm administrator from a security perspective. You must be able to trust them as you would a farm administrator.

  • You must lock down the use of the application pool account as much as possible. Doing so can help to limit the damage a malicious user can do to the SharePoint farm and external systems.

Enable RevertToSelf authentication mode

After you enable RevertToSelf authentication mode, new models that use RevertToSelf can be created and imported.

Security Note:

We do not recommend RevertToSelf authentication mode for production environments. Before enabling RevertToSelf authentication mode, make sure that you have read and understood the implications of enabling RevertToSelf authentication mode.

Note:

RevertToSelf is not allowed in hosted environments.

To enable RevertToSelf authentication mode

  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. At the Windows PowerShell command prompt, type the following commands:

    1. To create a variable that contains the Business Data Connectivity service application object, type the following command:

      Copy Code
      $bdc = Get-SPServiceApplication | where {$_ -match "<ServiceName>"}

      Where <ServiceName> is the name of the Business Data Connectivity service application. This can also be a regular expression (for example, "BDC").

      Note:

      If the Business Data Connectivity service application is a shared service application, this command must be run on the farm where the service application is published.

    2. To enable RevertToSelf authentication mode, type the following command:

      Copy Code
      $bdc.RevertToSelfAllowed = $true

Disable RevertToSelf authentication mode

When RevertToSelf is disabled, new models that use RevertToSelf cannot be created or imported.

Note:

If you have existing models that use RevertToSelf, they will continue to work. You must delete the existing models if you want to remove all instances of RevertToSelf authentication from your farm.

To disable RevertToSelf authentication mode

  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. At the Windows PowerShell command prompt, type the following commands:

    1. To create a variable that contains the Business Data Connectivity service application, type the following command:

      Copy Code
      $bdc = Get-SPServiceApplication | where {$_ -match "<ServiceName>"}

      Where <ServiceName> is the name of the Business Data Connectivity service application. This can also be a regular expression (for example, "BDC").

      Note:

      If the Business Data Connectivity service application is a shared service application, this command must be run on the farm where the service application is published.

    2. To disable RevertToSelf authentication mode, type the following command:

      Copy Code
      $bdc.RevertToSelfAllowed = $false

Workflows and external lists

Additional configuration is required when you want to develop workflows that interact with external lists. The following sections describe requirements that can affect workflow behavior.

Note:

Workflows cannot interact with external lists in a hosted environment.

Workflows cannot be associated directly with an external list

Because the external data is not stored in SharePoint Foundation, the workflow cannot be notified when an item in the external list changes. Instead, you can create a site workflow or a list workflow, and then have the workflow read or update an external list. You can also use an external list item as a destination for a task process in SharePoint Designer; however, the link to the task will not display a title for the external list item.

Workflows sometimes run as the service account

Workflows run as the service account (typically, the application pool account) in the following scenarios:

  • Visual Studio workflows.

  • Declarative workflows that interact with external lists and are started automatically. This is true even when you use an impersonation step in your workflow.

In this case, you must give the service account Execute permission to the external content type that the external list is associated with and verify that the service account has the necessary permissions to access the external system.

Workflows and authentication

To support workflow activities, the external content type that the external list is associated with must use RevertToSelf or Secure Store Service for authentication.

Note:

These authentication mode restrictions do not apply if you are using a .NET Assembly connector or a custom connector.

  • Authenticate by using RevertToSelf

    RevertToSelf authentication mode (also known as BDC identity authentication mode) authenticates to the external system by using the application pool account of the front-end Web server where the external list resides. This means that the application pool account must have permission to access the external system. By default, RevertToSelf authentication is not enabled. You must enable RevertToSelf authentication mode before you can create or import models that use RevertToSelf authentication.

    Security Note:

    RevertToSelf authentication is not recommended for production environments.

    For more information about RevertToSelf authentication, see RevertToSelf authentication mode.

  • Authenticate by using a custom secure store provider

For more information about authentication modes, see Business Connectivity Services authentication overview in "Business Connectivity Services security overview (SharePoint Foundation 2010)."

See Also

Concepts

Business Connectivity Services security overview (SharePoint Foundation 2010)

Other Resources

Resource Center: Operations and Manageability for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=220234)


Workflow administration (SharePoint Foundation 2010)
See Also

This section explains how to perform common workflow administration tasks.

In this section:

  • Configure global workflow settings (SharePoint Foundation 2010)

  • Manage workflows (SharePoint Foundation 2010)

  • Monitor workflows (SharePoint Foundation 2010)

See Also

Concepts

Workflow deployment process (SharePoint Foundation 2010)


Manage workflows (SharePoint Foundation 2010)

You can modify the configuration settings for existing workflow associations, cancel running workflows, remove workflow associations, and uninstall or delete workflows from your site.

In this section:

  • Activate or deactivate a workflow (SharePoint Foundation 2010)

    Workflows that are deployed as a feature package must be activated to be available to use on lists, libraries, content types, or sites. This article describes how to activate or deactivate a workflow that has been deployed as a feature package.

  • Add a workflow association (SharePoint Foundation 2010)

    Before a workflow can be run, it must be associated with a list, library, content type, or site. This article describes how to associate a workflow template with a list, library, content type, or site.

  • Modify a workflow association (SharePoint Foundation 2010)

    This article describes how to modify the configurable options that are available for most for workflow associations.

  • Remove a workflow association (SharePoint Foundation 2010)

    Workflow templates must be associated with a list, library, content type, or site before it can be run. This article describes how to disassociate a workflow template from a list, library, content type, or site.

  • Start a workflow instance (SharePoint Foundation 2010)

    Workflows can be configured to start when a particular event occurs or can be started manually by a user. This article describes how to start a workflow manually.

  • Cancel or terminate a workflow instance (SharePoint Foundation 2010)

    If you do not want an instance of a workflow to complete you can cancel the workflow. You can terminate a workflow that cannot be cancelled either because it does not support cancellation or because the workflow has stopped responding. This article describes how to cancel or terminate a workflow.

  • Uninstall a workflow (SharePoint Foundation 2010)

    This article describes how to uninstall a workflow that is deployed as a feature.

  • Delete a SharePoint Designer workflow (SharePoint Foundation 2010)

    This article describes how to delete a workflow that was deployed using SharePoint Designer.


Activate or deactivate a workflow (SharePoint Foundation 2010)

An administrator can check the status of a feature that contains a workflow template and then activate or deactivate the feature to meet business requirements.

By default, many of the predefined workflows that Microsoft SharePoint Foundation 2010 includes as features are active when you create a site or site collection. Additionally, custom workflows that you create by using Microsoft SharePoint Designer 2010 or Visual Studio 2010 and deploy by using the one-click publishing method are automatically activated to the sites in which they are deployed. Because the features that contain workflow templates, such as the predefined workflows, can be deactivated, you can check the site or site collection to determine whether the feature that contains the workflow template that you want to use is active. Use the following procedures to determine whether the workflow that you want to use is active, and then activate the workflow as necessary.

By default, Microsoft SharePoint Foundation 2010 has only one predefined workflow, the Three-state workflow, which is active when you create a site or site collection in SharePoint Foundation 2010.

Tip:

Only activated workflows can be associated with a list, library, content type, or site.

Activate a workflow for a site collection

Use the following procedure to determine whether the feature for the workflow that you want to use is active so that you can activate it as necessary.

Note:

Workflows that are activated at the level of a site collection are available to all sites in the site collection.

To activate a workflow for a site collection

  1. Verify that you have the following administrative credentials:

    • You must be a member of the site collection administrators group on the site collection that you are configuring.

  2. On the top level of the site collection, on the Site Actions menu, click Site Settings.

  3. On the Site Settings page, in the Site Collection Administration section, click Site collection features.

  4. On the Features page, click Activate next to the workflow feature that you want to activate.

    The Status column displays "Active" to indicate that the feature is now active.

Note:

If you later decide that you want to deactivate a workflow feature, open the Site Features page again, click Deactivate next to the workflow feature that you want deactivate, and then click Deactivate this feature.


Add a workflow association (SharePoint Foundation 2010)

You add a workflow by associating it with a list, document library, site content type, or site.

In this article:

  • Associate a workflow with a list or document library

  • Associate a workflow with a list or library content type

  • Associate a workflow with a site content type

  • Associate a workflow from a feature package with a site

Before you begin

When you add a workflow association, you assign a task list and history list to use with the selected workflow. You can use the default task list, select another existing task list, or create a new one. Workflow participants can find and view their workflow tasks easily by using the My Tasks view of the Tasks list on the Quick Launch of the site collection.

Security Note:

If the tasks for this workflow might reveal sensitive or confidential data that you want to keep separate from the default tasks list, you should create a new task list.

As SharePoint lists grow, site performance might be adversely affected. If an organization will have many workflows, consider creating a separate task list and history list for each workflow to avoid potential performance problems.

Associate a workflow with a list or document library

Use the following steps to associate a workflow with a list or document library. Note that some workflows, such as the Three-state workflow, require you to create a column in your list in which the workflow can display status. For example, before you add the Three-state workflow to a list, we recommend that you first create a column of the "Choice" type and assign three choices to the column.

To associate a workflow with a list or document library

  1. Verify that you have the following administrative credentials:

    • You must be granted the Full Control permission-level on the list or library that you are configuring.

  2. Browse to the list or library to which you want to add a workflow.

  3. Do one of the following:

    • For a list, on the List Tools tab, click List.

    • In the Settings group, click Workflow Settings, and then click Add a workflow.

    • For a library, on the Library Tools tab, click Library.

    • In the Settings group, click Workflow Settings, and then click Add a workflow.

  4. On the Add a Workflow page, in the Workflow section, select the workflow template that you want to associate with this list or library.

  5. In the Name section, type the name that you want to use to identify this workflow to users of this list or library.

  6. In the Task List section, specify a task list to use with this workflow.

  7. In the History List section, select a history list to use with this workflow.

    The history list displays events that occur during each instance of the workflow.

    Important:

    You can use the default history list, select another existing history list, or create a new one. When SharePoint lists grow in size, site performance might be affected. If an organization will have many workflows, consider creating a separate history list for each workflow association to avoid potential performance problems.

  8. In the Start Options section, specify how (automatically or manually), when (item update, creation, or both), or by whom a workflow can be started.

    Note that the available start options are determined by the workflow template and differ from one workflow to another.

    Note:

    By default, users who have Edit Item permissions can start a workflow. If you specify that Require Manage List permissions are needed to start the workflow, only users who have Manage List or Web Designer permissions can start an instance of the workflow. Most workflows do not require this restriction. However, you can use this setting for workflows that include tasks, such as deleting documents, which only certain people should be able to perform.

  9. If the workflow that you selected has additional configuration options, click Next to customize settings that are specific to workflows, as necessary. Otherwise, go to the next step.

  10. When you have finished specifying your configuration options, click OK to apply your changes to the workflow association.

Associate a workflow with a list or library content type

Use the following steps to associate a workflow with a list or library content type.

Before you can perform the following steps, the list or library that you are configuring must first be configured to allow the management of content types.

To associate a workflow with a list or library content type

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Site Owners group on the SharePoint site that you are configuring.

  2. Open the list or library that contains the content type to which you want to associate a workflow.

  3. Do one of the following:

    • For a list, on the ListTools tab, click List.

    • In the Settings group of the ribbon, click List Settings.

    • For a library, on the LibraryTools tab, click Library.

    • In the Settings group of the ribbon, click Library Settings.

  4. In the Content Types section, in the Content Type column, click the name of the content type to which you want to associate a workflow.

    Note:

    If the list or library is not set up to allow for management of multiple content types, the Content Types section is not displayed. For more information, see Use content types to manage content on a SharePoint site (http://go.microsoft.com/fwlink/?LinkId=184651).

  5. On the List Settings or Document Library Settings page, in the Settings section, click Workflow settings.

  6. On the Workflow Settings page, click Add a workflow.

  7. On the Add a Workflow page, in the Workflow section, select the workflow template that you want to associate with this content type.

  8. In the Name section, type the name that you want to use to identify this workflow to site users.

  9. In the Task List section, specify a task list to use with this workflow.

  10. In the History List section, select a history list to use with this workflow.

    The history list displays all events that occur during each instance of the workflow.

    Important:

    You can use the default history list or you can create a new one. As SharePoint lists grow in size, site performance may be affected. If an organization will have many workflows, consider creating a separate history list for each workflow to avoid potential performance problems.

  11. In the Start Options section, specify how (automatically or manually), when (item update, creation, or both), or by whom a workflow can be started.

    Note that the available start options are determined by the workflow template and differ from one workflow to another.

    Note:

    By default, users who have Edit Item permissions can start a workflow. If you specify that Require Manage List permissions are needed to start the workflow, only users who have Manage List or Web Designer permissions can start an instance of the workflow. Most workflows do not require this restriction. However, you can use this setting for workflows that include tasks, such as deleting documents, which only certain people should be able to perform.

  12. If the workflow that you selected has additional configuration options, click Next to customize settings that are specific to workflows, as necessary. Otherwise, go to the next step.

  13. When you have finished specifying your configuration options, click OK or Save (depending on the workflow) to apply your changes to the workflow association.

Associate a workflow with a site content type

Use the following steps to associate a workflow with a site content type.

To associate a workflow with a site content type

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Site Owners group on the site on which you are performing this procedure.

  2. Browse to the site where you want to associate a workflow with a site content type.

    Note:

    Site content types that are inherited from another site, for example, the top-level site of a site collection, must be associated from the site from which they are inherited. In this case, go to the site from which the site content type is inherited to add the workflow association.

  3. On the home page for the site, on the Site Actions menu, click Site Settings.

  4. On the Site Settings page, in the Galleries section, click Site content types.

  5. On the Site Content Types page, in the Site Content Type column, click the content type to which you want to add a workflow association.

  6. On the Site Content Types page, in the Settings section, click Workflow settings.

  7. On the Workflow Settings page, click Add a workflow.

  8. On the Add a Workflow page, in the Workflow section, select the workflow that you want to add.

  9. In the Name section, type the name that you want to use to identify this workflow to site users.

  10. In the Task List section, specify a task list to use with this workflow.

  11. In the History List section, select a history list to use with this workflow.

    The history list displays all events that occur during each instance of the workflow.

    Note:

    You can use the default history list or you can create a new one. As SharePoint lists grow in size, site performance might be affected. If an organization will have many workflows, consider creating a separate history list for each workflow to avoid potential performance problems.

  12. In the Start Options section, specify how (automatically or manually), when (item update, creation, or both), or by whom a workflow can be started.

    Note that the available start options are determined by the workflow template and differ from one workflow to another.

    Note:

    By default, users who have Edit Item permissions can start a workflow. If you specify that Require Manage List permissions are needed to start the workflow, only users who have Manage List or Web Designer permissions can start an instance of the workflow. Most workflows do not require this restriction. However, you can use this setting for workflows with tasks, such as deleting documents, which only certain people should be able to perform.

  13. If the workflow that you selected has additional configuration options, click Next to customize settings that are specific to workflows, as necessary. Otherwise, go to the next step.

  14. When you have finished specifying your configuration options, click OK to apply your changes to the workflow association.

Associate a workflow from a feature package with a site

Use the following steps to associate a workflow (that is part of a feature package) with a site.

To associate a workflow with a site

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Site Owners group on the site on which you are performing this procedure.

  2. Browse to the site from which you want to add a workflow association.

  3. On the Site Actions menu, click Site Settings.

  4. On the Site Settings page, in the Site Administration section, click Workflow settings.

  5. On the Workflow Settings page, click Add a workflow.

  6. On the Add Workflow page, in the Workflow section, select the workflow template that you want to associate with this site.

  7. In the Name section, type the name that you want to use to identify this workflow to site users.

  8. In the Task List section, specify a task list to use with this workflow.

  9. In the History List section, select a history list to use with this workflow.

    The history list displays all events that occur during each instance of the workflow.

    Note:

    You can use the default history list or you can create a new one. As SharePoint lists grow in size, site performance might be affected. If an organization will have many workflows, consider creating a separate history list for each workflow to avoid potential performance problems.

  10. In the Start Options section, specify whether the workflow can be manually started by an authenticated user who has Participate Permissions and whether Manage Permissions are also required to start the workflow.

    Note that the available start options are determined by the workflow template and differ from one workflow to another.

    Note:

    By default, users who have the Edit Items Permissions can start a workflow. If you specify that Require Manage permissions are needed to start the workflow, only those who have been granted the at least the Designer level of permissions can start an instance of the workflow. Most workflows do not require this restriction. However, you can use this setting for workflows that have tasks, such as deleting documents, which only certain people should be able to perform.

  11. If the workflow that you selected has additional configuration options, click Next to customize settings that are specific to workflows, as necessary. Otherwise, go to the next step.

  12. When you have finished specifying your configuration options, click OK to apply your changes to the workflow association.


Modify a workflow association (SharePoint Foundation 2010)

After you associate (add) a workflow to a list, library, content type, or site, you can modify its configuration settings at any time. Configuration settings include the name of the workflow association, the start options, the participants, the task notification messages, the choice of lists to use for tracking workflow history and tasks (default or new), and completion options.

In this article:

  • Modify a workflow associated with a list or library

  • Modify a workflow associated with a list or library content type

  • Modify a workflow associated with a site content type

  • Modify a site workflow

Before you begin

When you add a workflow association, you assign a task list to use with the selected workflow. You can use the default task list, select another existing task list, or create a new one. If you use the default task list, workflow participants can find and view their workflow tasks easily by using the My Tasks view of the Tasks list.

Security Note:

If the tasks for this workflow might reveal sensitive or confidential data that you want to keep separate from the default tasks list, you should create a new task list.

Modify a workflow associated with a list or library

Use the following steps to modify the configuration settings for a workflow that is associated with a list or document library. Changes to configuration settings are only applied to workflow instances that start after the workflow association is modified.

To modify a workflow associated with a list or library

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Site Owners group on the list or library that you are configuring.

  2. Browse to the list or document library where the workflow is located.

  3. Do one of the following:

    • For a list, on the ListTools tab, click List.

    • In the Settings group, click List Settings.

    • For a library, on the LibraryTools tab, click Library.

    • In the Settings group, click Library Settings.

  4. On the List Settings or Library Settings page, in the Permissions and Management section, click Workflow Settings.

  5. On the Workflow Settings page, in the Workflows section, click the name of the workflow that you want to change.

  6. In the Name section, you can optionally type a new name for the workflow.

    This name will be used to identify the workflow to site users.

  7. In the Task List section, specify a task list to use with this workflow.

  8. In the History List section, select a history list to use with this workflow.

    The history list displays all events that occur during each instance of the workflow.

    Note:

    You can use the default history list or create a new one. When SharePoint lists grow in size, site performance may be impacted. If an organization will have many workflows, consider creating a separate history list for each workflow association to avoid potential performance problems.

  9. In the Start Options section, specify how (automatically or manually), when (item update, creation, or both), or by whom a workflow can be started.

    Note that the available start options are determined by the workflow template and differ from one workflow to another.

    Note:

    By default, users who have Edit Item permissions can start a workflow. If you specify that Require Manage List permissions are needed to start the workflow, only users who have Manage List or Web Designer permissions can start an instance of the workflow. Most workflows do not require this restriction. However, you can use this setting for workflows that include tasks, such as deleting documents, which only certain people should be able to perform.

  10. Click Next to customize settings that are specific to workflows, as necessary.

  11. After you have configured settings that are specific to workflows, click OK or Save (depending on the workflow) to apply changes to the workflow association.

Modify a workflow associated with a list or library content type

Use this procedure to modify a workflow association with a list or library content type.

Note:

This procedure assumes that Allow management of content types is set to Yes on the list or library.

To modify a workflow associated with a list or library content type

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Site Owners group on the SharePoint site that you are configuring.

  2. Browse to the document library or list on which the workflow is associated.

  3. Do one of the following:

    • For a list, on the ListTools tab, click List.

    • In the Settings group, click List Settings.

    • For a library, on the LibraryTools tab, click Library.

    • In the Settings group, click Library Settings.

  4. In the Content Types section, in the Content Type column, click the name of the content type to which the workflow that you want to modify is associated.

    Note:

    If the list or library is not set up to allow multiple content types, the Content Types section is not displayed. For more information, see Use content types to manage content on a SharePoint site (http://go.microsoft.com/fwlink/?LinkId=184651).

  5. On the List Settings or Library Settings page, in the Settings section, click Workflow Settings.

  6. On the Workflow Settings page, click the name of the workflow that you want to modify.

  7. On the Change a Workflow page, in the Name section, you can optionally type a new name for the workflow.

    This name identifies the workflow to site users.

  8. In the Task List section, specify a task list to use with this workflow.

  9. In the History List section, select a history list to use with this workflow.

    The history list displays all events that occur during each instance of the workflow.

    Note:

    You can use the default history list or you can create a new one. When SharePoint lists grow in size, site performance may be impacted. If an organization will have many workflows, consider creating a separate history list for each workflow to avoid potential performance problems.

  10. In the Start Options section, specify how (automatically or manually), when (item update, creation, or both), or by whom a workflow can be started.

    Note that available start options are determined by the workflow template and differ from one workflow to another.

    Note:

    By default, users who have Edit Item permissions can start a workflow. If you specify that Require Manage List permissions are needed to start the workflow, only list administrators (that is, anyone with Manage List or Web Designer permissions) can start an instance of the workflow. Most workflows do not require this restriction. However, you can use this setting for workflows with tasks, such as deleting documents, which only certain people should be able to perform.

  11. Depending on whether custom options are available for a workflow, click Next to configure settings that are specific to a workflow, or click OK to save the changes.

  12. After you have configured settings that are specific to a workflow, if applicable to the workflow you are modifying, click OK to apply the changes to the workflow association.

  13. On the Customize Workflow page, specify changes that you want to make to the workflow, and then click Save.

Modify a workflow associated with a site content type

Use this procedure to modify a workflow association with a site content type. When you modify a workflow that is associated with a site content type, you can choose whether to apply changes to inherited content types.

To modify a workflow associated with a site content type

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Site Owners group on the SharePoint site that you are configuring.

  2. Browse to the site where you want to modify a workflow that is associated with a content type.

    Note:

    Site content types that are inherited from another site, for example, the top-level site of a site collection, must be modified on the site from which they are inherited.

  3. On the top-level site of the site collection, on the Site Actions menu, click Site Settings.

  4. On the Site Settings page, in the Galleries section, click Site content types.

  5. On the Site Content Types Gallery page, in the Site Content Type column, click the content type for which you want to modify a workflow association.

  6. On the Site Content Types page, in the Settings section, click Workflow settings.

  7. On the Workflow Settings page, click the name of the workflow that you want to change.

  8. On the Change a Workflow page, in the Name section, you can optionally type a new name for the workflow.

    This name will be used to identify the workflow to site users.

  9. In the Task List section, specify a task list to use with this workflow.

  10. In the History List section, select a history list to use with this workflow.

    The history list displays all events that occur during each instance of the workflow.

    Note:

    You can use the default history list or create a new one. When SharePoint lists grow in size, site performance may be impacted. If an organization will have numerous workflows, consider creating a separate history list for each workflow association to avoid potential performance problems.

  11. In the Start Options section, specify how (automatically or manually), when (item update, creation, or both), or by whom a workflow can be started.

    Note that available start options are determined by the workflow template and differ from one workflow to another.

    Note:

    By default, users who have Edit Item permissions can start a workflow. If you specify that Require Manage List permissions are needed to start the workflow, only list administrators (that is, anyone with Manage List or Web Designer permissions) can start an instance of the workflow. Most workflows do not require this restriction. However, you can use this setting for workflows with tasks, such as deleting documents, which only certain people should be able to perform.

  12. In the Update List and Site Content Types section, specify whether you want to add this workflow to all content types that inherit from this content type.

  13. Depending on whether custom options are available for a workflow, click Next to configure settings that are specific to a workflow. After you have configured settings that are specific to a workflow, if applicable to the workflow that you are modifying, click OK or Save (depending on the workflow) to apply your changes to the workflow association.

Modify a site workflow

Use this procedure to modify a workflow association with a site content type. When you modify a workflow that is associated with a site content type, you can choose whether to apply changes to inherited content types.

To modify a site workflow

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Site Owners group on the SharePoint site that you are configuring.

  2. Browse to the site where you want to modify a site workflow.

    Note:

    Site workflows that are inherited from another site, for example, the top-level site of a site collection, must be modified on the site from which they are inherited.

  3. On the top-level site of the site collection, on the Site Actions menu, click Site Settings.

  4. On the Site Settings page, in the Site Administration section, click Workflow settings.

  5. On the Workflow settings page, click the workflow that you want to modify.

  6. On the Change a Workflow page, in the Name section, you can optionally type a new name for the workflow.

    This name identifies the workflow to site users.

  7. In the Task List section, specify a task list to use with this workflow.

  8. In the History List section, select a history list to use with this workflow.

    The history list displays all of the events that occur during each instance of the workflow.

    Note:

    You can use the default history list or create a new one. When SharePoint lists grow in size, site performance may be impacted. If an organization will have numerous workflows, consider creating a separate history list for each workflow association to avoid potential performance problems.

  9. In the Start Options section, specify how (automatically or manually), when (item update, creation, or both), or by whom a workflow can be started.

    Note that available start options are determined by the workflow template and differ from one workflow to another.

    Note:

    By default, users who have Edit Item permissions can start a workflow. If you select Require Manage List permissions to start the workflow, only list administrators (that is, anyone with Manage List or Web Designer permissions) can start an instance of the workflow. Most workflows do not require this restriction. However, you can use this setting for workflows with tasks, such as deleting documents, which only certain people should be able to perform.

  10. Depending on whether custom options are available for your workflow, click Next to configure settings that are specific to a workflow. After you have configured settings that are specific to a workflow, if applicable to the workflow that you are modifying, click OK or Finish (depending on the workflow) to apply your changes to the workflow association.


Remove a workflow association (SharePoint Foundation 2010)

You add a workflow by associating it with a list, document library, content type, or site. You remove a workflow by disassociating it from a list, document library, content type, or site. Optionally, you can prevent new instances of a workflow from starting but still let all running workflow instances to finish.

In this article:

  • Remove a workflow association from a list or document library

  • Remove a workflow association from a list or library content type

  • Remove a workflow association from a site content type

  • Remove a workflow association from a site

Remove a workflow association from a list or document library

Use the following steps to remove a workflow association from a list or document library.

To remove a workflow association from a list or document library

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Site Owners group on the SharePoint site that you are configuring.

  2. Browse to the list or library from which you want to remove a workflow.

  3. Do one of the following:

    • For a list, on the List Tools tab, click List.

    • In the Settings group, click List Settings.

    • For a library, on the Library Tools tab, click Library.

    • In the Settings group, click Library Settings.

  4. On the List Settings or Library Settings page, in the Permissions and Management section, click Workflow Settings.

  5. On the Workflow Settings page, click Remove a workflow.

    Note:

    The Remove a workflow link is not displayed if no workflows are associated with the list or library.

  6. On the Remove Workflows page, find the workflow that you want to remove and choose from the following options:

    • Select No New Instances to prevent new instances of this workflow from running but still allow for running instances to finish.

      After all running workflows are finished, you can return to this page to completely remove the workflow association.

    • Select Remove to prevent new instances of this workflow from running and remove all instances of this workflow. This option removes instances that are already running.

  7. Click OK.

Remove a workflow association from a list or library content type

Use the following steps to remove a workflow from a list or library content type.

To remove a workflow association from a list or library content type

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Site Owners group on the SharePoint site that you are configuring.

  2. Open the list or library that contains the content type from which you want to remove a workflow association.

  3. Do one of the following:

    • For a list, on the List Tools tab, click List.

    • In the Settings group, click List Settings.

    • For a library, on the Library Tools tab, click Library.

    • In the Settings group, click Library Settings.

  4. On the List Settings or Library Settings page, in the Content Types section, click the name of the content type for which you want to remove a workflow.

    Note:

    If the list or library is not set up to allow multiple content types, the Content Types section is not displayed. For more information, see Use content types to manage content on a SharePoint site (http://go.microsoft.com/fwlink/?LinkId=184651).

  5. On the List Settings or Library Settings page, in the Settings section, click Workflow settings.

  6. On the Workflow Settings page, click Remove a workflow.

    Note:

    The Remove a workflow link is not displayed if no workflows are associated with the selected content type.

  7. On the Remove Workflows page, find the workflow that you want to remove and choose from the following options:

    • Select No New Instances to prevent new instances of this workflow from running but still allow for running instances to finish.

      After all running workflows are finished, you can return to this page to completely remove the workflow association.

    • Select Remove to prevent new instances of this workflow from running and remove all instances of this workflow. This option removes instances that are already running.

  8. Click OK.

Remove a workflow association from a site content type

Use the following steps to remove a workflow from a site content type.

To remove a workflow association from a site content type

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Site Owners group on the SharePoint site that you are configuring.

  2. Browse to the site where you want to modify a workflow that is associated with a site content type.

    Note:

    Site content types that are inherited from another site, for example, the top-level site of a site collection, must be removed from the site from which they are inherited.

  3. On the home page for the site, on the Site Actions menu, click Site Settings.

  4. On the Site Settings page, in the Galleries section, click Site content types.

  5. On the Site Content Types page, in the Site Content Type column, click the content type from which you want to remove a workflow association.

    Note:

    You cannot modify site content types that are inherited from another site, such as the top-level site of a site collection. In this case, go to the site from which the site content type is inherited to remove the workflow association.

  6. On the Site Content Types page, in the Settings section, click Workflow settings.

  7. On the Workflow Settings page, click Remove a workflow.

    Note:

    The Remove a workflow link is not displayed if no workflows are associated with the selected site content type.

  8. On the Remove Workflows page, find the workflow that you want to remove and choose from the following options:

    • Select No New Instances to prevent new instances of this workflow but still allow for running instances to finish.

      After all running workflows are finished, you can return to this page to completely remove the workflow association.

    • Select Remove to remove all instances of this workflow. This option removes instances that are already running.

  9. Click OK.

  10. If the Apply changes to all content types inheriting from this type message appears, click OK.

Remove a workflow association from a site

Use the following steps to remove a workflow from a site.

To remove a workflow association from a site

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Site Owners group on the SharePoint site that you are configuring.

  2. Go to the site from which you want to remove a workflow.

  3. On the Site Actions menu, click Site Settings.

  4. On the Site Settings page, in the Site Administration section, click Workflow settings.

  5. On the Workflow Settings page, click Remove a workflow.

    Note:

    The Remove a workflow link is only displayed if a site workflow is currently associated with the site.

  6. On the Remove Workflows page, find the workflow that you want to remove and choose from the following options:

    • Select No New Instances to prevent new instances of this workflow but still allow for running instances to finish.

      After all running workflows are finished, you can return to this page to completely remove the workflow association.

    • Select Remove to remove all instances of this workflow. This option removes instances that are already running.

  7. Click OK.


Start a workflow instance (SharePoint Foundation 2010)

After you activate a workflow and add it to a list, document library, or content type, an authenticated user can run the workflow on an item in the list or a document in the library. After activating a site workflow on a site, users can run that workflow on the site. When you add a workflow, you specify whether you want the workflow to run automatically or manually. If a workflow is configured to start automatically, the settings that are specified in the workflow association are always used when the workflow begins. A user can modify the default settings of a workflow that is configured to start manually if the workflow specifies settings such as workflow participants and due date, as allowed by the workflow template. Workflows that are associated with a list, library, or content type run on items in the list or documents in the library with which the workflow is associated. Site workflows run on the site to which they are associated.

Permissions needed to start a workflow By default, users who have the Edit Items permission can start a workflow. If you specify that Manage List permissions are required to start the workflow, only list administrators (that is, anyone with Manage Lists permission or the Design permission-level) can start an instance of the workflow. Most workflows do not require this restriction. However, you can use the Manage Lists option for workflows that contain tasks, such as workflows that delete documents, which you want only certain people to perform.

The procedure for starting a workflow depends on whether it was configured to start manually or automatically. Choose one of the following procedures to start your workflow depending on its configuration and how you want to start it.

In this article:

  • Start a workflow automatically

  • Start a site workflow

  • Start a workflow manually in a list or library

Start a workflow automatically

If a workflow is set to start automatically, the workflow starts to run immediately when a trigger event, such as adding a document to a library, occurs.

Start a site workflow

Use this procedure to start a site workflow.

To start a site workflow

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Site Owners SharePoint group on the site that you are configuring.

  2. Browse to the home page of the site to which a site workflow is associated.

  3. In the Quick Launch, click All Site Content, and then click Site Workflows.

  4. On the Workflows page, in the Start a New Workflow section, click the name of the workflow that you want to start.

    Note:

    If workflows are not listed in the Start a New Workflow section, no workflows have been associated with the site.

  5. If a Start button appears, click Start.

Start a workflow manually in a list or library

Use this procedure to manually start a workflow that is associated with a list or library.

To start a workflow manually in a list or library

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Site Owners SharePoint group on the site that you are configuring.

  2. Browse to the site where you want to start a workflow that is associated with a list or library.

  3. Browse to the document library or list where you want to start the workflow.

  4. From the SharePoint document library or list, point to the item on which you want to start the workflow, click the arrow that appears, and then click Workflows.

  5. On the Workflows page, in the Start a New Workflow section, click the workflow that you want to start.

  6. If the Start button appears, specify required information, such as the participants and due date. Configure the other workflow-specific settings as necessary, and then click Start to start the workflow.


Cancel or terminate a workflow instance (SharePoint Foundation 2010)

There are two different ways that you can stop a workflow instance:

  • Cancel a workflow

  • Terminate a workflow

Note:

You cannot restart an instance of a workflow that has been cancelled or terminated. To reuse the workflow with the same list or library, you must start a new instance of the workflow. For more information, see Start a workflow instance (SharePoint Foundation 2010).

Cancel a workflow

When you cancel a workflow, the status of the workflow is set to Canceled and all tasks that the workflow created are canceled. Participants receive an e-mail message that the workflow has been canceled.

Note:

The option to cancel a workflow in progress is available only if the workflow template supports cancellation.

To cancel a workflow on a list or library

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Site Owners SharePoint group on the site that you are configuring.

  2. Browse to the list or library for which you want to cancel a workflow.

    If the name of the list or library does not appear, click View All Site Content, and then click the name of the list or library.

  3. Point to the document or item involved in the workflow, click the arrow that appears, and then click Workflows.

  4. On the Workflows page, in the Running Workflows section, click the name of the workflow that you want to cancel.

  5. On the Workflow Status page, in the Workflow Information section, click Cancel all <workflow name> tasks, where <workflow name> is the name of the workflow that you are cancelling.

    Note:

    The Cancel all <workflow name> tasks link is not available for workflows that do not support cancellation. In this case, you can either allow the workflow to complete or terminate the workflow as described later in this article.

  6. On the Modify Workflow page, click Yes.

To cancel a site workflow

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Site Owners SharePoint group on the site that you are configuring.

  2. Browse to the home page of the site for which you want to cancel a site workflow.

  3. In the Quick Launch, click All Site Content, and then click Site Workflows.

  4. On the Workflows page, in the My Running Workflows section, click the name of the workflow that you want to cancel.

  5. On the Workflow Status page, in the Workflow Information section, click Cancel.

    Note:

    The Cancel all <workflow name> tasks link is not available for workflows that do not support cancellation. In this case, you can either allow the workflow to complete or terminate the workflow as described later in this article.

  6. On the Modify Workflow page, click Yes.

Terminate a workflow

If a workflow error occurs or a workflow stops responding, you can terminate the workflow. You might also want to terminate a workflow that is not cancellable. Terminating a workflow sets the status of the workflow to Canceled and deletes all tasks created by the workflow but does not notify the participants.

To terminate a workflow in a list or library

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Site Owners SharePoint group on the site that you are configuring.

  2. Browse to the list or library for which you want to cancel a workflow.

    If the name of the list or library does not appear, click View All Site Content, and then click the name of your list or library.

  3. Point to the document or item involved in the workflow, click the arrow that appears, and then click Workflows.

  4. On the Workflows page, in the Running Workflows section, click the name of the workflow that you want to terminate.

  5. On the Workflow Status page, in the Workflow Information section, click Terminate this workflow now.

  6. In the dialog box that appears, click OK.

To terminate a site workflow

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Site Owners SharePoint group on the site that you are configuring.

  2. Browse to the home page of the site for which you want to terminate a site workflow.

  3. In the Quick Launch, click All Site Content, and then click Site Workflows.

  4. On the Workflows page, in the My Running Workflows section, click the name of the workflow that you want to cancel.

  5. On the Workflow Status page, in the Workflow Information section, click Terminate this workflow now.

  6. In the dialog box that appears, click OK.


Uninstall a workflow (SharePoint Foundation 2010)
See Also

When a workflow that was installed as a Feature is no longer needed, you can uninstall it by using the Uninstall-SPFeature cmdlet in the SharePoint 2010 Management Shell in the same manner that you uninstall any SharePoint Feature. For more information, see Uninstall-SPFeature.

Important:

To run Windows PowerShell, ensure that you have met the following minimum requirements:

  • See Add-SPShellAdmin.

Visual Studio workflows are always installed as Features and declarative workflows that have been packaged into wsp files can be deployed as a feature or as solutions in the Solution Gallery. Note that workflows that are deployed directly from Microsoft SharePoint Designer 2010 are not deployed as Features. To uninstall a declarative workflow that was published directly from SharePoint Designer, you delete the source files of the workflow from the site collection on which it is installed. For more information, see Delete a SharePoint Designer workflow (SharePoint Foundation 2010).

Before you can use the Uninstall-SPFeature cmdlet to uninstall a Feature, all workflow instances have to be completed, canceled, or terminated and the workflow must be deactivated. After you uninstall a Feature, the workflow that is in that Feature is no longer available from the user interface, to associate with lists, to associate with libraries, and so on. The source files are still on the server to make it possible to later reinstall the workflow. Use the Windows PowerShellInstall-SPFeature cmdlet to install the Feature again. For details, see Install-SPFeature.

See Also

Concepts

Cancel or terminate a workflow instance (SharePoint Foundation 2010)
Activate or deactivate a workflow (SharePoint Foundation 2010)


Delete a SharePoint Designer workflow (SharePoint Foundation 2010)

When a Microsoft SharePoint Designer 2010 workflow is no longer needed, you can delete it. Deleting a SharePoint Designer workflow permanently deletes the workflow source files from the site and makes the workflow unavailable to users on the site. The deleted workflow is automatically removed from the list or library with which it was associated when it was created.

Delete a SharePoint Designer workflow

Use the following steps to delete a SharePoint Designer workflow.

Note:

Deleting a SharePoint Designer workflow also deletes the history data for that workflow.

To delete a SharePoint Designer workflow

  1. Verify that you have the following administrative credentials:

    • To delete a workflow from a server, you must be granted the Designer permission-level on the site from which you are deleting the workflow. You also need access to SharePoint Designer 2010.

  2. Start SharePoint Designer 2010.

  3. In the Navigation pane, click Sites, and then click Open Site.

  4. In the Open Site dialog box, in the Site name box, type the URL of the SharePoint site that contains the workflow that you want to delete, and then click Open.

  5. In the Navigation pane, click Workflows.

  6. On the Workflows tab, in the Name column, right-click the workflow that you want to delete, and then click Delete.

  7. In the Confirm Delete dialog box, click Yes to confirm that you want to delete the workflow.


Monitor workflows (SharePoint Foundation 2010)

After a workflow has been started, you can check the general workflow status in the associated list or document library. For more information, see Check workflow status.

You can also view detailed reports that show workflow start time, the current task and person responsible to complete the task, the duration of each task within a workflow, and the duration of all activities in the workflow. For more information, see View workflow reports.

For help to diagnose error conditions that are associated with a workflow, see Troubleshoot workflow errors.


Check workflow status (SharePoint Foundation 2010)

You can check the general status of a workflow instance by viewing status information in the list or document library with which the workflow is associated. You can get detailed workflow status by viewing the Workflow Status page that is automatically created and maintained for all running workflows.

Important:

Before you check the status of a workflow instance for items in a list or document library, you must create an association between the workflow and the list or document library and ensure that the workflow has started. For more information, see Add a workflow association (SharePoint Foundation 2010) and Start a workflow instance (SharePoint Foundation 2010).

In this article:

  • Check general workflow status

  • Check detailed workflow status for items in a list or library

  • Check detailed workflow status for a site workflow

Check general workflow status

Use these steps to check general workflow status.

To check general workflow status

  1. Verify that you have the following administrative credentials:

    • You must be a user with Edit Items permissions on the list or library.

  2. Browse to the list or document library that contains the workflow for which you want to check status.

  3. Locate the item for which you want to check status and view the status information in the workflow status column.

    Note:

    The workflow status column is titled with the workflow's name.

Check detailed workflow status for items in a list or library

Use these steps to check detailed workflow status for items in a list or library.

To check detailed workflow status for items in a list or library

  1. Verify that you have the following administrative credentials:

    • You must be a user with Edit Items permissions on the list or library.

  2. Browse to the list or document library that contains the workflow for which you want to check status.

  3. In the row of the item for which you want to check status, click the link in the workflow status column.

    Note:

    The workflow status column is titled with the workflow's name.

  4. On the Workflow Status page, view the following information about the workflow:

    • Name of the person who initiated the workflow

    • Date and time the workflow started

    • Date and time the workflow was last run or resumed

    • Name and link to the document or item involved in the workflow

    • Current status of the workflow

    • If this workflow has a workflow visualization published with it, a Visio diagram type visualization of the workflow is displayed.

    • List of tasks assigned to the workflow participants

    • Lists of all events that have occurred in the history of this instance of the workflow thus far (for example, workflow initiation, task creation, task completion)

Depending on the type of workflow that you are viewing, the Workflow Status page might also contain links to modify, cancel, and terminate the workflow. For more information, see Manage workflows (SharePoint Foundation 2010).

Check detailed workflow status for a site workflow

Use these steps to check detailed workflow status for a site.

To check detailed workflow status for a site workflow

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Site Owners SharePoint group.

  2. Browse to the site for which you want workflow status.

  3. In the Quick Launch, click All Site Content, and then click Site Workflows.

  4. On the Workflows page, do one of the following:

    • To view the status of workflows that are running, in the My Running Workflows section, click the name of the workflow for which you want status.

    • To view the status of workflows that have completed, in the My Completed Workflows section, click the name of the workflow for which you want status.

  5. On the Workflow Status page, view the following information about the workflow:

    • Name of the person who initiated the workflow

    • Date and time the workflow started

    • Date and time the workflow was last run or resumed

    • Current status of the workflow

    • List of tasks assigned to the workflow participants.

    • List of all events that have occurred in the history of this instance of the workflow thus far (for example, workflow initiation, task creation, task completion) appear in the Workflow History section.


View workflow reports (SharePoint Foundation 2010)

Microsoft SharePoint Foundation 2010 provides individual and aggregate workflow reports to enable you to assess the efficiency of your workflows and related business processes. You can use these reports to locate problems with processes or to determine whether a group or individual is meeting performance targets for a particular business process.

This article contains:

  • View site collection workflow usage summary

  • View individual workflow reports

View site collection workflow usage summary

You can display a list of available workflows for the site collection, their usage summary (active or inactive), how many times these workflows have been associated, and how many instances of each active workflow are running.

To view the site collection workflow usage summary

  1. Verify that you have the following administrative credentials:

    • You must be a member of the site collection administrators group on the site collection that you are configuring.

  2. Browse to the top-level site of the site collection for which you want to view workflow reports.

  3. On the Site Actions menu, click Site Settings.

  4. On the Site Settings page, in the Site Administration section, click Workflows to display the Site Collection Workflows report.

View individual workflow reports

SharePoint Foundation 2010 provides two predefined Microsoft Excel reports that provide aggregate analysis of workflow history for each workflow instance: the Activity Duration Report and the Cancellation and Error Report. The Activity Duration Report provides data about how long each activity within a workflow takes to complete as well as how long it takes for all tasks in the workflow to complete. The Cancellation and Error Report shows the workflows that have been cancelled or encountered errors before completion. Each of these reports is provided as an Microsoft Excel formatted file.

Note:

If you are using custom workflows, the appropriate parameters must be specified in the workflow template in order to generate the data for these reports. For more information, see Developing Workflow Solutions with SharePoint Server 2007 and Windows Workflow Foundation (http://go.microsoft.com/fwlink/p/?LinkId=120912).

To view individual workflow reports

  1. Verify that you have the following credentials:

    • You must be a user with Edit Item permissions to view individual workflow reports.

  2. Browse to the list or document library that contains the workflow for which you want to view reports.

  3. Point to the item or document that is involved in the workflow, click the arrow that appears, and then click Workflows.

  4. On the Workflows page, in the Running Workflows section, click the name of the workflow for which you want status. If no workflows are listed in this section, no workflows are currently running on the selected item.

  5. On the Workflow Status page, in the Workflow History section, click View workflow reports.

  6. On the View Workflow Reports page, locate the workflow association for which you want to view the reports, and do either of the following:

    • To view information about how long it is taking for each activity within a workflow to be completed and how long it takes each instance of the workflow to be completed, click Activity Duration Report.

    • To view information about which workflows were canceled or encountered errors before completion, click Cancellation & Error Report.

    Note:

    Reports are listed in alphabetical order by workflow association name. Activity Duration reports only return history data that contains duration information. Cancellation and Error Reports only return history data that contains errors or cancellation events.

  7. In the File Location section, click Browse, specify the location to which you want to save the report, and then click OK.


Troubleshoot workflow errors (SharePoint Foundation 2010)

Workflows are affected by problems in the user environment, especially the state of list items that a workflow operates upon and the server settings that govern workflows. When a problem is detected, workflows fail. The most common reasons for workflow failure are a defect in the workflow design, network issues, or restricted user permissions. Because of the high dependency on all these factors and the complexity with which workflows are built, troubleshooting workflows can be challenging.

View workflow errors in the browser

A workflow can fail for many reasons. For example, a workflow may be designed to create a new item in a library, but the library might have been deleted. Another possibility is that user permissions may have been changed since the workflow was started. This prevents a user from accessing the site to complete a workflow task. When a workflow does not complete successfully, its final status appears in the column with that workflow's name, in the list with which the workflow is associated.

In addition to the Completed status, a final status that you might see in this column is Error Occurred, Stopped, Failed on start (retrying), or Failed on start.

Resolve common workflow errors

When the final status of a workflow is Error Occurred, the first step in troubleshooting the workflow is to determine the cause of the error. The troubleshooting method that you use depends on the type of workflow in which the error occurred: a predefined workflow, a Microsoft SharePoint Designer workflow, or a Visual Studio custom workflow.

For predefined workflows, the workflow history list is a good troubleshooting tool. The workflow history displays the current state and all the previous states for a running workflow. When an error occurs in a workflow, the last event in the workflow history list is titled Error. The list provides information about when the error occurred, but the list typically does not provide a description of the problem to avoid revealing sensitive information that could lead to a security issue. The most common errors are caused by connectivity problems, incorrect e-mail settings, or restricted user permissions.

For information about how to access the workflow history list, see View workflow reports (SharePoint Foundation 2010).

For Microsoft SharePoint Designer workflows, when you create the workflow, you can insert actions that write to the history list at any point in the workflow. This information helps you determine the last successful step that the workflow completed before the error occurred and also the step in which the error occurred.

For Visual Studio custom workflows, you can use all the debugging functionality available with Visual Studio and the troubleshooting options for predefined workflows.

Note:

For more information about how to debug workflows, see Step 5: Debug Your Workflow (http://go.microsoft.com/fwlink/p/?LinkID=107820) on the Microsoft SharePoint team blog.


Deploy a workflow as a WSP file (SharePoint Foundation 2010)

When you create a workflow and save it as a workflow template (.wsp file), you can use the template to deploy the workflow on multiple sites and site collections.

Deploy a workflow as a WSP file

Running time: 3:34

Play video Watch the "Deploy a workflow as a WSP file" video

Download video For an optimal viewing experience, download the "Deploy a workflow as a WSP file" video.

Right-click the link, and then click Save Target As to download a copy. Clicking the link will open a .wmv file in the default video viewer for full-resolution viewing.

To deploy a workflow as a .wsp file you do the following:

  • Download the WSP file

  • Upload the WSP file to a site collection

  • Activate the workflow feature on a site

Download the WSP file

Use the following procedure to open the Site Assets document library on the top-level site of the site collection that the workflow template was saved to and then download the workflow template as a .wsp file to a local folder on the server that is running Microsoft SharePoint Foundation 2010 or a network share. The downloaded file can then be uploaded to the Solutions Gallery of any site collection.

To download the WSP file to a file location

  1. On the top-level site, in the Quick Launch, click All Site Content.

  2. On the All Site Content page, in the Document Libraries section, click Site Assets.

  3. Point to the name of the workflow that you want to edit and click the arrow that appears.

  4. Point to Send To, and then click Download a Copy.

  5. In the File Download dialog box, click Save.

  6. In the Save As box, type the location to save the file, and then click Save.

  7. In the Download Complete dialog box, click Close.

Upload the WSP file to a site collection

Use one of the following procedures to upload the .wsp file to the Solution Gallery of a site collection. This will make the workflow template available as a feature which you will then activate on the site collection. This makes the workflow available as a feature on all sites in the site collection. However, this does not activate the feature on any sites in the site collection.

In this section:

  • To upload the WSP file to a site collection by using the user interface

  • To upload the WSP file to a site collection by using Windows PowerShell

To upload the WSP file to a site collection by using the user interface

  1. On the top-level site of the site collection, on the Site Actions menu, click Site Settings.

  2. On the Site Settings page, in the Galleries section, click Solutions.

  3. On the Solutions tab of the ribbon, in the New group, click Upload Solution.

  4. In the Solution Gallery - Upload Solution dialog box, click Browse.

  5. In the Choose File to Upload dialog box, select the file share, select the WSP file, and then click Open.

  6. In the Solution Gallery - Upload Solution dialog box, click OK.

    The Solution Gallery - Activate Solution dialog box appears.

  7. In the Solution Gallery - Activate Solution dialog box, click Activate.

    This makes the workflow available as a feature to all sites in this site collection. The name of the workflow now appears in the Solutions Gallery with Status set to Activated.

To upload the WSP file to a site collection 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 SharePoint_Shell_Access role on the content database. For more information, see Add-SPShellAdmin and Get-SPContentDatabase.

  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:

    Copy Code
    Add-SPUserSolution -LiteralPath <LiteralPath> -Site <SiteURL>

    Where:

    • <LiteralPath> is the full path that includes the name, of the WSP file.

    • <SiteURL> is the URL of the site collection.

    The workflow is now deployed as a feature. However, before you can use the workflow, you must activate it for the site collection.

  6. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Install-SPUserSolution -Identity <Solution> -Site <SiteURL>

    Where:

    • <Solution> is the name of the solution to activate.

    • <SiteURL> is the URL of the site collection.

For more information about the Add-SPUserSolution and Install-SPUserSolution cmdlets, see Install-SPUserSolution and Add-SPUserSolution.

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.

Activate the workflow feature on a site

Use one of the following procedures to activate the feature on any sites where you want to use the workflow.

In this section:

  • To activate the workflow feature on a site by using the user interface

  • To activate the feature on a site by using Windows PowerShell

To activate the workflow feature on a site by using the user interface

  1. Go to the site where you want to activate the feature and on the Site Actions menu, click Site Settings.

  2. On the Site Settings page, in the Site Actions section, click Manage site features.

    On the Features page for the site, you can see that the workflow template is available but not active.

  3. Click Activate.

    On the Features page, the workflow template Status now appears as Active.

To activate the feature on a site 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 SharePoint_Shell_Access role on the content database. For more information, see Add-SPShellAdmin and Get-SPContentDatabase.

  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:

    Copy Code
    Enable-SPFeature -Identity <Feature> -Url <URL>

    Where:

    • <Feature> is the name of the feature to activate.

      Note:

      The feature name is not the same name that you gave the workflow. Instead, the feature name is typically the workflow name with "ListInstances" appended to it.

      If you are not sure of the name of the feature that you want to activate, you can do the following to verify the feature name.

      1. Make a copy of the .wsp file and change the file name extension on the copied file to .cab.

      2. In Windows Explorer, right-click the .cab file, and then click Open.

      3. Select feature.xml.

        The feature name is listed in the Path column.

    • <URL> is the URL of the site.

For more information about the Enable-SPFeature cmdlet, see Enable-SPFeature.

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.


Mobile administration (SharePoint Foundation 2010)
See Also

Mobile views are enabled by default for most SharePoint lists and libraries. Users can access document libraries, lists, wikis, blogs, Web Parts pages, back-end business data, and sites from their mobile devices. Additional mobile features include:

  • Users can use the mobile search experience to find people, contact information, and content on SharePoint sites.

  • Users can subscribe to alerts that are sent by using Short Message Service (SMS). The alerts are sent to users' mobile devices when changes are made to a SharePoint list or item.

  • With Microsoft Office Web Apps, users can view Word, Excel, and PowerPoint documents in mobile browsers.

    Note:

    For more information about Office Web Apps, see Office Web Apps (Installed on SharePoint 2010 Products).

In this section:

  • Configure a mobile account (SharePoint Foundation 2010)

    This article discusses how to configure and manage a mobile account to enable users to subscribe to alerts that are sent by using SMS.

  • Configure mobile views (SharePoint Foundation 2010)

    This article discusses how administrators can configure mobile views for custom libraries and lists.

  • Configure external access for mobile devices (SharePoint Foundation 2010)

    This article describes the options for configuring external access to SharePoint sites for mobile devices.

See Also

Concepts

Plan for mobile devices (SharePoint Foundation 2010)

Other Resources

Resource Center: Security and Authentication for SharePoint Foundation 2010


Configure mobile views (SharePoint Foundation 2010)

A mobile view is a version of the SharePoint site that has been optimized for mobile devices. In Microsoft SharePoint Foundation, mobile views are enabled by default for most lists or libraries that were created by using default templates. Mobile views are not enabled by default for custom lists, custom libraries, or for lists or libraries that were created in previous versions of SharePoint that have been upgraded to SharePoint Foundation. Mobile views are not available for Datasheet and Gantt view types.

The browser definition file lists the mobile browsers and devices that are supported by SharePoint Foundation and is used to redirect mobile browsers to the mobile views. You can modify the browser definition file to change the redirect behavior of a mobile browser, or to add or delete entries from the list of supported mobile devices.

In this article:

  • Configure mobile views

  • Modify the browser definition file (compat.browser)

Configure mobile views

This section describes how to configure mobile views for custom lists, custom libraries, or for lists or libraries that were created in previous versions of SharePoint.

Note:

Mobile views are not available for Datasheet and Gantt view types.

To configure the mobile view for a list

  1. In the list for which you want to configure the mobile view, in List Tools, click the List tab on the ribbon.

  2. On the ribbon, in the Manage Views group, click Modify View.

  3. On the Edit <list type> View page, expand Mobile, and then configure the following settings according to your preferences:

    Note:

    Not all settings are available for all views.

    Enable this view for mobile access

    Make this view the default view for mobile access

    Number of items to display in list view web part for this view

    Field to display in mobile list simple view

To configure the mobile view for a library

  1. In the library for which you want to configure the mobile view, in Library Tools, click the Library tab on the ribbon.

  2. On the ribbon, in the Manage Views group, click Modify View.

  3. On the Edit View page, expand Mobile, and then configure the following settings according to your preferences:

    Note:

    Not all settings are available for all views.

    Enable this view for mobile access

    Make this view the default view for mobile access

    Number of items to display in list view web part for this view

    Field to display in mobile list simple view

Modify the browser definition file (compat.browser)

The browser definition file contains a list of the mobile browsers and devices that can access mobile views in SharePoint Foundation. When a user browses a SharePoint site from a mobile device, the mobile browser submits to the site an HTTP GET request that includes a user agent string. If the mobile browser and device model in the user agent string are listed in the browser definition file and the isMobileDevice setting for the mobile browser is set to true, SharePoint Foundation redirects the mobile browser to the mobile view of the site. Otherwise, a standard view of the site is shown in the mobile browser. You can modify the file to change the redirect behavior of a mobile browser.

The browser definition file lists the mobile browsers and devices that are supported by SharePoint Foundation. The file can be updated when product updates to SharePoint Foundation are released. You can also modify the file to add a mobile browser or device to the list.

Note:

There is a compat.browser file for each Internet Information Services (IIS) Web site.

To change the redirect behavior of a mobile browser

  1. Start IIS Manager by typing INETMGR at a command prompt.

  2. Right-click the IIS Web site where the SharePoint Web application is installed, and then click Explore.

  3. In Windows Explorer, double-click the App_Browsers folder.

  4. Open the compat.browser file in a text editor.

  5. Find the <browser> node that corresponds to the mobile browser or device that you want to modify.

  6. Find the <capability name="isMobileDevice" value="true" /> element.

  7. Set the value attribute to false to display a standard view of the site in the mobile browser.

  8. Save your changes to the compat.browser file.

  9. Restart IIS by entering the following command at the command prompt: iisreset /noforce.

To add a mobile browser or device, you create a <browser> node that identifies the mobile browser or device and defines its capabilities. For more information about what can be entered in the <browser> node, see Browser Definition File Schema (browsers Element) (http://go.microsoft.com/fwlink/p/?LinkID=146162).

To add a mobile browser and device model

  1. Start IIS Manager by typing INETMGR at a command prompt.

  2. Right-click the IIS Web site where the SharePoint Web application is installed, and then click Explore.

  3. In Windows Explorer, double-click the App_Browsers folder.

  4. Open the compat.browser file in a text editor.

  5. Find the <browsers> node.

  6. Add a new <browser> node to the end of the list of browsers.

  7. Save your changes to the compat.browser file.

  8. Restart IIS by entering the following command at the command prompt: iisreset /noforce.


Configure external access for mobile devices (SharePoint Foundation 2010)
See Also

Mobile device users can access a SharePoint site either by using a mobile browser or by using a rich client application such as Microsoft SharePoint Workspace Mobile 2010. This article describes how to make SharePoint sites accessible for mobile devices when the devices are used outside the corporate firewall. There are three methods for enabling external access:

  • Virtual private network server A virtual private network (VPN) server that supports Secure Sockets Layer (SSL), such as Microsoft Forefront Unified Access Gateway (UAG), enables you to publish SharePoint sites across the corporate firewall. The following steps summarize how to make a SharePoint site accessible from outside the corporate firewall when using a VPN server:

    • Set up the VPN server.

    • Publish the SharePoint site on the VPN server.

    • Configure an alternate access mapping for the SharePoint site.

    • Add the SharePoint site to a zone that allows cross-firewall access. For more information about cross-firewall access, see Configure cross-firewall access, later in this article.

    Note:

    Forefront UAG is the only VPN server that is supported by Microsoft Office Mobile on Windows Phone 7 and Windows Phone 6.5. For more information about how to configure Forefront UAG to support Microsoft Office Mobile, see Configure Forefront UAG for SharePoint Workspace Mobile, later in this article.

    For more information about Forefront UAG, see Forefront Unified Access Gateway (UAG) (http://go.microsoft.com/fwlink/p/?LinkID=196384), SharePoint publishing solution guide (http://go.microsoft.com/fwlink/p/?LinkId=206256), and Deploying Forefront UAG for mobile devices.

  • Mobile proxy server Mobile proxy servers, such as Microsoft System Center Mobile Device Center and Blackberry Enterprise Server, help mobile devices work within the IT infrastructure of a company. To access a SharePoint site from outside the corporate firewall, the mobile proxy server must pass the mobile browser's HTTP headers directly through to SharePoint Foundation.

  • Direct Internet access The SharePoint site can be placed on the extranet. This method supports only basic authentication. We recommend using a combination of technology and policy safeguards, such as SSL, with any Internet-facing servers.

In this article:

  • Configure cross-firewall access

  • Configure Forefront UAG for SharePoint Workspace Mobile

Configure cross-firewall access

After the SharePoint site is published outside the firewall, you must add the site to a zone that allows cross-firewall access. A cross-firewall access zone is used to generate external PC and mobile URLs in mobile alert messages, and enables users to send an externally accessible URL when they click the E-mail a link button on the ribbon.

To configure a cross-firewall access zone

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators group.

  2. In Central Administration, click System Settings.

  3. On the System Settings page, under Farm Management, click Configure cross firewall access zone.

  4. On the Cross Firewall Access Zone page, in Web Application, in the Web Application list box, select the Web application that is published across the firewall.

  5. In Cross Firewall Access Zone, in the Zone selection for cross firewall access list box, select the zone that is published across the firewall.

Configure Forefront UAG for SharePoint Workspace Mobile

Office Mobile users can connect to a SharePoint site by using the mobile browser or by using Microsoft SharePoint Workspace Mobile 2010. This section describes the overall procedure for publishing a SharePoint site so it can be accessed by mobile devices, and it also describes additional configuration required to support SharePoint Workspace Mobile.

  1. Publish the SharePoint site. For more information, see SharePoint publishing solution guide (http://go.microsoft.com/fwlink/p/?LinkId=206256).

    Note:

    We recommend that you use Forefront UAG with Service Pack 1 (SP1) installed.

  2. Publish the SharePoint site for mobile browsing. For more information, see Configuring Forefront UAG for mobile browsing (http://go.microsoft.com/fwlink/p/?LinkID=208322).

The SharePoint site can now be accessed by mobile browsers. To support connecting from SharePoint Workspace Mobile, you must also publish the SharePoint site for SharePoint Workspace Mobile on the Forefront UAG server. For more information, see Publishing SharePoint sites for SharePoint Workspace Mobile (http://go.microsoft.com/fwlink/p/?LinkId=206257).

SharePoint Workspace Mobile does not support directly connecting to sites in the Internet zone. When a user connects to the published site, Forefront UAG identifies the user agent that is sent by SharePoint Workspace Mobile and responds with an HTTP 401 challenge. SharePoint Workspace Mobile uses the user credentials that are configured in the Forefront UAG settings of the mobile device to authenticate to Forefront UAG by using Basic authentication. Forefront UAG then authenticates the user to the SharePoint site

Note:

A site that has a fully qualified domain name (for example, https://hrweb.contoso.com) is considered to be in the Internet zone by SharePoint Workspace Mobile.

The following procedures describe how configure the Forefront UAG settings on a Windows Phone device. Users must configure the Forefront UAG settings on their Windows Phone device before they can use SharePoint Workspace Mobile to access a SharePoint site. We recommend that you provide these procedures to users so they can configure their Windows Phone devices, and also provide them with their Forefront UAG server information.

To configure Forefront UAG settings on a Windows Phone 6.5 device (end users)

  1. On the mobile device, start SharePoint Workspace Mobile.

  2. Tap Menu, tap Settings, and then tap Configure Forefront UAG Server.

  3. In the Forefront UAG address box, type the URL of the UAG trunk.

  4. Enter the domain user name and password.

  5. Tap OK.

To configure Forefront UAG settings on a Windows Phone 7.0 device (end users)

  1. On Start, flick left to the App list, and then tap Office.

  2. Flick to SharePoint, and then tap All.

  3. Tap More, tap Settings, and then tap UAG server.

  4. On the UAG Server screen, do the following:

    1. Tap the UAG server address box, and then type the server address, beginning with https://.

    2. Tap the User name box, and then type your domain and user name. For example, if you log on to your computer by using domainName\userName, you would type domainName\userName in the box.

    3. Tap the Password box, and then type your password.

    4. Tap the Save password check box.

    5. Tap Done.

See Also

Other Resources

Resource Center: Installation and Deployment for SharePoint Foundation 2010


Building Windows Phone 7 applications with SharePoint 2010 Products and Unified Access Gateway (UAG): white paper

Published: April 21, 2011

This white paper describes how to build Windows Phone 7 applications with Microsoft SharePoint 2010 Products and Microsoft Forefront Unified Access Gateway (UAG). It provides business scenarios that can benefit from custom mobile applications that authenticate by using UAG and use the features of SharePoint 2010 Products for collaboration. It also introduces the concepts and code that are required to access SharePoint list data in a secure manner from a Windows Phone 7 device, and provides steps to install and configure a non-production instance of UAG for the purposes of developing and testing mobile applications for SharePoint 2010 Products.

Download this white paper as a Microsoft Word document (.doc). (http://go.microsoft.com/fwlink/p/?LinkID=216117)

Download this white paper as a PDF file (.pdf). (http://go.microsoft.com/fwlink/p/?LinkId=216118)


Sandboxed solutions administration (SharePoint Foundation 2010)
See Also

A sandbox is a restricted execution environment that enables programs to access only certain resources and keeps problems that occur in the sandbox from affecting the rest of the server environment. Solutions that you deploy into a sandbox, which are known as sandboxed solutions, cannot use certain computer and network resources and cannot access content outside the site collection they are deployed in.

In this section:

  • Enable sandboxed solutions on the farm (SharePoint Foundation 2010)

    Provides instructions for starting the sandboxed solutions service.

  • Configure load balancing for sandboxed solutions (SharePoint Foundation 2010)

    Provides instructions for selecting the load-balancing scheme for sandboxed solutions.

  • Block or unblock a sandboxed solution (SharePoint Foundation 2010)

    Provides instructions for blocking a sandboxed solution from running.

  • Configure sandboxed solutions service tiers (SharePoint Foundation 2010)

    Provides instructions for configuring the sandboxed solutions service.

  • Configure resource points for sandboxed solutions (SharePoint Foundation 2010)

    Provides instructions for configuring resource points for sandboxed solutions.

See Also

Concepts

Sandboxed solutions overview (SharePoint Foundation 2010)
Plan sandboxed solutions (SharePoint Foundation 2010)


Enable sandboxed solutions on the farm (SharePoint Foundation 2010)
See Also

A sandbox is a restricted execution environment that enables programs to access only certain resources and keeps problems that occur in the sandbox from affecting the rest of the server environment. Solutions that you deploy into a sandbox, which are known as sandboxed solutions, cannot use certain computer and network resources and cannot access content outside the site collection they are deployed in. Because sandboxed solutions cannot affect the whole server farm, they do not have to be deployed by a farm administrator. If sandboxed solutions have been enabled on at least one server in the farm, a site collection administrator can deploy solutions to a run in a sandbox on any server in the farm.

By default, sandboxed solutions are disabled. Enable sandboxed solutions on every application server on which you want to run sandboxed solutions.

For more information about sandboxed solutions, see Sandboxed solutions overview (SharePoint Foundation 2010).

Enable sandboxed solutions

Use the following procedure on each application server in your farm on which you want to enable sandboxed solutions.

To enable sandboxed solutions by using Central Administration

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.

  2. On the home page of the Central Administration Web site, in the System Settings section, click Manage services on server.

  3. On the Services on Server page, in the Server box, select the server on which you want to enable sandboxed solutions.

  4. In the Microsoft SharePoint Foundation Sandboxed Code Service row, in the Action column, click Start.

  5. Repeat steps 3 and 4 for each server on which you want to enable sandboxed solutions.

To enable sandboxed solutions by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. Click Start, and then 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:

    Copy Code
    Start-Service -Name SPUserCodeV4

  6. Repeat this procedure on every server on which you want to enable sandboxed solutions

See Also

Concepts

Sandboxed solutions overview (SharePoint Foundation 2010)
Plan sandboxed solutions (SharePoint Foundation 2010)
Configure load balancing for sandboxed solutions (SharePoint Foundation 2010)
Block or unblock a sandboxed solution (SharePoint Foundation 2010)
Configure sandboxed solutions service tiers (SharePoint Foundation 2010)
Configure resource points for sandboxed solutions (SharePoint Foundation 2010)


Configure load balancing for sandboxed solutions (SharePoint Foundation 2010)
See Also

A sandbox is a restricted execution environment that enables programs to access only certain resources and keeps problems that occur in the sandbox from affecting the rest of the server environment. Solutions that you deploy into a sandbox, which are known as sandboxed solutions, cannot use certain computer and network resources and cannot access content outside the site collection they are deployed in.

You can select one of two load-balancing schemes for sandboxed solutions. Based on the load-balancing scheme, Microsoft SharePoint Foundation 2010 determines which server to run the solution on. If load balancing is local, the solution runs on the same server that is servicing the request. If load balancing is remote, the server that the solution runs on is selected based on the server that most recently ran the solution (this is known as solution affinity). In either case, the server must be running the sandboxed solutions service. By default, SharePoint Foundation uses remote load balancing.

The more you isolate sandboxed solutions, the better your ability to protect the main part of your SharePoint Foundation 2010 site from code that might consume too many resources. You can increase isolation by using remote load balancing and by running the sandboxed solution service only on specific servers.

For more information about sandboxed solutions, see Sandboxed solutions overview (SharePoint Foundation 2010).

Configure load balancing

Load balancing directly affects the response time of sandboxed solutions. To change the load balancing scheme that is used in your farm, use the following procedure.

To configure load balancing by using Central Administration

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.

  2. On the home page of the Central Administration Web site, click System Settings.

  3. On the System Settings page, in the Farm Management section, click Manage user solutions.

  4. On the Sandboxed Solution Management page, in the Load Balancing section, select one of the following options:

    • All sandboxed code runs on the same machine as a request. This load-balancing scheme runs sandboxed code on the same server that handles the rest of the request.

    • Requests to run sandboxed code are routed by solution affinity. This load-balancing scheme selects the server on which to run sandboxed code based on solution affinity.

  5. Click OK.

See Also

Concepts

Sandboxed solutions overview (SharePoint Foundation 2010)
Plan sandboxed solutions (SharePoint Foundation 2010)
Block or unblock a sandboxed solution (SharePoint Foundation 2010)
Enable sandboxed solutions on the farm (SharePoint Foundation 2010)
Configure sandboxed solutions service tiers (SharePoint Foundation 2010)
Configure resource points for sandboxed solutions (SharePoint Foundation 2010)


Block or unblock a sandboxed solution (SharePoint Foundation 2010)
See Also

A sandbox is a restricted execution environment that enables programs to access only certain resources and keeps problems that occur in the sandbox from affecting the rest of the server environment. Solutions that you deploy into a sandbox, which are known as sandboxed solutions, cannot use certain computer and network resources and cannot access content outside the site collection they are deployed in.

A farm administrator can block a sandboxed solution. A solution that is blocked does not run. Each sandboxed solution is identified by a hash result of the solution code. If the solution code is changed and redeployed, it will be seen as a new sandboxed solution and will be allowed to run even if the original is still blocked.

For more information about sandboxed solutions, see Sandboxed solutions overview (SharePoint Foundation 2010).

In this article:

  • Block a sandboxed solution

  • Unblock a sandboxed solution

Block a sandboxed solution

You might need to block a sandboxed solution if it exceeds its typical resource usage or if it poses a security risk. To block a sandboxed solution, use the following procedure.

To block a sandboxed solution by using Central Administration

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.

  2. On the home page of the Central Administration Web site, click System Settings.

  3. On the System Settings page, in the Farm Management section, click Manage user solutions.

  4. On the Sandboxed Solution Management page, in the Solution Restrictions section, in the File box, either type the full path of the file that contains the solution to block or use the Browse button to browse for the file to block.

  5. Optionally, type a message in the Message box. This message will be displayed when a user tries to use the solution.

  6. Click Block.

    The solution is added to the list in the Blocked Solutions box.

  7. To block additional solutions, repeat steps 4 through 6.

  8. Click OK.

Unblock a sandboxed solution

If the situation that caused a sandboxed solution to be blocked has changed and you want to unblock the solution, use the following procedure.

To unblock a sandboxed solution by using Central Administration

  1. Verify that you have the following administrative credentials:

    • You must be a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration Web site.

  2. On the home page of the Central Administration Web site, click System Settings.

  3. On the System Settings page, in the Farm Management section, click Manage user solutions.

  4. On the Sandboxed Solution Management page, in the Solution Restrictions section, in the Blocked Solutions box, select the solution to unblock, and then click Remove.

  5. To unblock additional solutions, repeat step 4.

  6. Click OK.

See Also

Concepts

Sandboxed solutions overview (SharePoint Foundation 2010)
Plan sandboxed solutions (SharePoint Foundation 2010)
Enable sandboxed solutions on the farm (SharePoint Foundation 2010)
Configure load balancing for sandboxed solutions (SharePoint Foundation 2010)
Configure sandboxed solutions service tiers (SharePoint Foundation 2010)
Configure resource points for sandboxed solutions (SharePoint Foundation 2010)


Configure sandboxed solutions service tiers (SharePoint Foundation 2010)
See Also

Published: June 9, 2011

Based on the average amount of resources per request that sandboxed solutions use, they can be grouped into tiers in the sandboxed solutions service. A tier consists of one or more worker processes that contain one or more application domains in which sandboxed solutions run. By default, all solutions run in the sandboxed solutions service in one tier. You can configure additional tiers within the sandboxed solutions service to separate sandboxed solutions for performance, security, and reliability. For more information about tiers, see Sandboxed solutions overview (SharePoint Foundation 2010) and Sandbox Tiers (http://go.microsoft.com/fwlink/p/?LinkId=217145). For information about how to plan for tiers, see Plan sandboxed solutions (SharePoint Foundation 2010).

The sandboxed solutions service provides the environment for sandboxed solutions to run on your Microsoft SharePoint Foundation 2010 farm. You can use the SharePoint Central Administration Web site to start and stop the service, but you must use Windows PowerShell to configure tiers and most other features of the service.

In this article:

  • Configure sandboxed solutions service tiers

  • Display the sandboxed solutions service configuration settings

  • Restart the sandboxed solutions service

Configure sandboxed solutions service tiers

You can use this procedure to configure tiers for the sandboxed solutions service and to configure the worker processes, application domains, and other properties for each tier. You can use the code sample in this procedure as a stand-alone script, or you can combine it with the sample scripts in the other procedures in this article to configure the tiers and their properties, display the settings, and restart the service. For more information about the properties for tiers, see Using Execution Tiers to Protect Well-Behaved Sandboxed Solutions(http://go.microsoft.com/fwlink/p/?LinkID=220258).

To configure tiers

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. Copy the following code and paste it into a text editor, such as Notepad:

    Copy Code
    #Initialize the SPUserCodeService variable
$uc=[Microsoft.SharePoint.Administration.SPUserCodeService]::local

#Delete any existing default tiers first
foreach($tier in $uc.Tiers)
{
     $tier.Delete()
}
$uc.Tiers.Add("Tier1")
$uc.Tiers["Tier1"].MaximumWorkerProcesses = 5
$uc.Tiers["Tier1"].MaximumConnectionsPerProcess = 10
$uc.Tiers["Tier1"].MaximumAppDomainsPerProcess = 10
$uc.Tiers["Tier1"].PriorityPerProcess = [int] ([System.Diagnostics.ProcessPriorityClass]::Normal)
$uc.Tiers["Tier1"].ResourceMaxValue = 0.1
$uc.Tiers["Tier1"].Update()

$uc.Tiers.Add("Tier2")
$uc.Tiers["Tier2"].MaximumWorkerProcesses = 5
$uc.Tiers["Tier2"].MaximumConnectionsPerProcess = 10
$uc.Tiers["Tier2"].MaximumAppDomainsPerProcess = 10
$uc.Tiers["Tier1"].PriorityPerProcess = [int] ([System.Diagnostics.ProcessPriorityClass]::BelowNormal)
$uc.Tiers["Tier2"].ResourceMaxValue = 10
$uc.Tiers["Tier2"].Update()

  3. Save the file, naming it ConfigureTiers.ps1.

  4. On the Start menu, click All Programs.

  5. Click Microsoft SharePoint 2010 Products.

  6. Click SharePoint 2010 Management Shell.

  7. Change to the directory where you saved the file.

  8. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    ./ConfigureTiers.ps1

  9. Restart the SharePoint 2010 User Code Host service on the server.

Display the sandboxed solutions service configuration settings

You can use this procedure to display the tiers that have been configured for the sandboxed solutions service and to display the worker processes, application domains and other properties that are currently configured for each tier. You can append this script to the script in the previous procedure, or you can use it as a stand-alone script.

To display the existing configuration

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. Copy the following code and paste it into a text editor, such as Notepad:

    Copy Code
    #Loop through and show the user what exactly has been created

$uc=[Microsoft.SharePoint.Administration.SPUserCodeService]::Local

Write-Host "The following tiers have been created"
Write-Host "***********************************************************"

foreach($tier in $uc.Tiers)
{
     Write-Host "Tier Name: $($tier.Name)"
     Write-Host "Tier MaximumWorkerProcess: $($tier.MaximumWorkerProcesses)"
     Write-Host "Tier MaximumConnectionsPerProcess: $($tier.MaximumConnectionsPerProcess)"
     Write-Host "Tier MaximumAppDomainsPerProcess: $($tier.MaximumAppDomainsPerProcess)"
     Write-Host "Tier PriorityPerProcess: $($tier.PriorityPerProcess)"
     Write-Host "Tier ResourceMaxValue: $($tier.ResourceMaxValue)"

     Write-Host "***********************************************************"
}

  3. Save the file, naming it DisplayTiers.ps1.

  4. On the Start menu, click All Programs.

  5. Click Microsoft SharePoint 2010 Products.

  6. Click SharePoint 2010 Management Shell.

  7. Change to the directory where you saved the file.

  8. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    ./DisplayTiers.ps1

Restart the sandboxed solutions service

Many of the changes that you can make to the configuration of the sandboxed solutions service take effect only after the service is restarted. This procedure creates a script that you can use to restart the sandboxed solutions service. You can append this script to other configuration scripts to automatically restart the service whenever you change its configuration.

To restart the sandboxed solutions service by using Windows PowerShell

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. Copy the following code and paste it into a text editor, such as Notepad:

    Copy Code
    #Recycle the UserCode Service
$server = [Microsoft.Sharepoint.Administration.SPServer]::local

$userCodeServiceInstance
$getChildMethod
$type = $server.GetType()

foreach($method in $type.GetMethods())
{
     if( $method.Name -eq "GetChild")
     {
          $getChildMethod = $method
     }
}

$genericMethod = $getChildMethod.MakeGenericMethod([microsoft.sharepoint.administration.spusercodeserviceinstance])
$userCodeServiceInstance = $genericMethod.Invoke($server, $null)
$userCodeServiceInstance.Provision()

  3. Save the file, naming it RestartService.ps1.

  4. On the Start menu, click All Programs.

  5. Click Microsoft SharePoint 2010 Products.

  6. Click SharePoint 2010 Management Shell.

  7. Change to the directory where you saved the file.

  8. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    ./RestartService.ps1

See Also

Concepts

Sandboxed solutions overview (SharePoint Foundation 2010)
Plan sandboxed solutions (SharePoint Foundation 2010)
Enable sandboxed solutions on the farm (SharePoint Foundation 2010)
Block or unblock a sandboxed solution (SharePoint Foundation 2010)
Configure load balancing for sandboxed solutions (SharePoint Foundation 2010)
Configure resource points for sandboxed solutions (SharePoint Foundation 2010)


Configure resource points for sandboxed solutions (SharePoint Foundation 2010)
See Also

Published: June 9, 2011

To restrict the resources that your sandboxed solutions consume, you define resource points. Resource points correspond to specific levels of resource usage that you can define for up to 15 system resources that you want to monitor. Each of these resource measures accumulates points based on a single sandboxed solution's use of that resource, and those points are aggregated toward a quota that has been set for the whole site collection. If the number of accrued resource points exceeds the quota set for the site collection, all sandboxed solutions in the site collection are stopped. For a list of the individual resource measures and the minimum threshold, absolute limit, and resources per point for each resource, see Resource Usage Limits on Sandboxed Solutions in SharePoint 2010 (http://go.microsoft.com/fwlink/p/?LinkId=217149).

Quotas are managed through the SharePoint Central Administration Web site as a single number that controls the aggregate total of the resource points allowed per day for all sandboxed solutions in a site collection. For more information about quotas, see Sandboxed solutions overview (SharePoint Foundation 2010). For information about how to set the maximum resource quota for a site collection, see Change the storage limits for a site collection in Manage site collection storage limits (SharePoint Foundation 2010).

You can fine-tune the resource point distribution by using Windows PowerShell, as described in this article. When these Windows PowerShell commands are added to a script, you can configure the individual resource point distribution within the sandboxed solution quota for a site collection. For more information about quotas and resource points, see Sandboxed solutions overview (SharePoint Foundation 2010).

In this article:

  • Display resource point allocations for sandboxed solutions

  • Configure resource points for sandboxed solutions

Note:

To perform the following procedures, you must be logged on to the server that hosts the site collection that you are modifying. The sandboxed solutions service must be running on this server.

Display resource point allocations for sandboxed solutions

The following procedure enables you to display the current resource point allocations for sandboxed solutions on the current SharePoint Foundation server. You can use Windows PowerShell commands to display the current resource point allocation in a script that alters the point distribution, and you can also use these commands to verify the current allocation.

To display resource point allocations for sandboxed solutions

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. You must be a member of the farm administrators group.

  2. Copy the following code and paste it into a text editor, such as Notepad:

    Copy Code
    $uc=[Microsoft.SharePoint.Administration.SPUserCodeService]::Local
$uc.ResourceMeasures | Select-Object Name,ResourcesPerPoint,AbsoluteLimit

  3. Save the file, naming it DisplayQuotas.ps1.

  4. On the Start menu, click All Programs.

  5. Click Microsoft SharePoint 2010 Products.

  6. Click SharePoint 2010 Management Shell.

  7. Change to the directory where you saved the file.

  8. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    ./DisplayQuotas.ps1

Configure resource points for sandboxed solutions

You can use Windows PowerShell to modify the distribution of sandboxed solution resource points to fine-tune resource usage for specific SharePoint Foundation site collections.

To configure specific resource points

  1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  2. Copy the following code and paste it into a text editor, such as Notepad:

    Copy Code
    $uc=[Microsoft.SharePoint.Administration.SPUserCodeService]::Local
$uc.ResourceMeasures["CPUExecutionTime"].AbsoluteLimit = <LimitValue>
$uc.ResourceMeasures["CPUExecutionTime"].ResourcesPerPoint = <PointValue>
$uc.ResourceMeasures["CPUExecutionTime"].Update()
$uc.Update()

    Where:

    • <LimitValue> is the new maximum limit value.

    • <PointValue> is the new number of resources per resource point.

  3. Save the file, naming it ConfigurePoints.ps1.

  4. On the Start menu, click All Programs.

  5. Click Microsoft SharePoint 2010 Products.

  6. Click SharePoint 2010 Management Shell.

  7. Change to the directory where you saved the file.

  8. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    ./ConfigurePoints.ps1

See Also

Concepts

Sandboxed solutions overview (SharePoint Foundation 2010)
Plan sandboxed solutions (SharePoint Foundation 2010)
Enable sandboxed solutions on the farm (SharePoint Foundation 2010)
Block or unblock a sandboxed solution (SharePoint Foundation 2010)
Configure load balancing for sandboxed solutions (SharePoint Foundation 2010)
Configure sandboxed solutions service tiers (SharePoint Foundation 2010)


Document management administration (SharePoint Foundation 2010)

Published: August 12, 2010

This section includes topics administrators can use in configuring document management solutions in Microsoft SharePoint Foundation 2010.

In this section:

  • Co-authoring administration (SharePoint Foundation 2010)

  • Configure Information Rights Management (SharePoint Foundation 2010)


Co-authoring administration (SharePoint Foundation 2010)
See Also

Published: August 12, 2010

Co-authoring simplifies collaboration by enabling multiple users to work productively on the same document without intruding on one another's work or locking one another out. By default, co-authoring functionality is enabled in Microsoft SharePoint Foundation 2010 and does not require any additional steps configure. Articles in this section describe tasks administrators can use in configuring co-authoring for their particular organization. Administrators can also choose to disable co-authoring, either on the server side by using server properties, or on the client side by using Group Policy.

In this section:

  • Configure versioning for co-authoring (SharePoint Foundation 2010)

  • Configure the co-authoring versioning period (SharePoint Foundation 2010)

  • Configure the maximum number of co-authoring authors (SharePoint Foundation 2010)

  • Disable co-authoring (SharePoint Foundation 2010)

See Also

Concepts

Co-authoring overview (SharePoint Foundation 2010)


Configure versioning for co-authoring (SharePoint Foundation 2010)
See Also

Published: August 12, 2010

This article describes how to configure document library versioning settings for co-authoring functionality in Microsoft SharePoint Foundation 2010.

In this article:

  • Configure versioning for co-authoring

  • Configure Require Check Out

Configure versioning for co-authoring

By default, document libraries in SharePoint Foundation 2010 have versioning disabled. It is recommended that this feature be enabled for document libraries where users will be co-authoring documents by using PowerPoint 2010 and Word 2010. For document libraries with OneNote notebooks, minor versions should not be enabled. Minor versioning can result in synchronization errors that prevent edits from being saved.

When multiple authors work on the same document, edits are retained on the server as document versions. Administrators can limit the number of versions retained in order to limit server storage usage. If major versioning is enabled in a document library with OneNote notebooks, we recommend that the maximum number of versions be specified in order to make more efficient use of disk space.

To enable versioning

  1. Browse to the document library you want to configure.

  2. In the toolbar, under Library Tools, click Library.

  3. In the toolbar, click Library Settings.

  4. In General Settings, click Versioning Settings.

  5. In Document Version History, select Create major versions.

  6. To specify a version retention limit, select Keep the following number of major versions and in the text box, type the number of versions.

Configure Require Check Out

When a document is checked out of a document library, the document is locked, making it unavailable for co-authoring. The Require Check Out setting should not be enabled in document libraries that are used for co-authoring. By default, for SharePoint Foundation document libraries, this setting is not enabled.

To disable Require Check Out

  1. Browse to the document library you want to configure.

  2. In the toolbar, under Library Tools, click Library.

  3. In the toolbar, click Library Settings.

  4. In General Settings, click Versioning Settings.

  5. In Require Check Out, select No (default).

See Also

Concepts

Configure the co-authoring versioning period (SharePoint Foundation 2010)


Configure the co-authoring versioning period (SharePoint Foundation 2010)
See Also

Published: August 12, 2010

This article describes how to configure the co-authoring versioning period in Microsoft SharePoint Foundation 2010 by using Windows PowerShell 2.0.

Configure the co-authoring versioning period

When versioning is turned on, SharePoint Foundation takes periodic snapshots of documents, saving them for later reference. This information can provide an edit trail that may be useful for seeing who changed a document, rolling back to an earlier version, or for compliance reasons.

The coAuthoringVersionPeriod property specifies how often SharePoint stores a version of a document that is being edited, measured in minutes. You can configure this property by using the Windows PowerShell. If the value is set to 0, SharePoint Foundation will capture every change made by a new user in a different version of the document. If the value is set to a very large number, SharePoint Foundation will create one version for the whole editing session. This latter behavior matches the behavior of files that are not co-authored and files in previous versions of SharePoint Foundation.

Note:

Some procedures in this task require using Windows PowerShell or SharePoint 2010 Management Shell to run cmdlets. To run SharePoint 2010 cmdlets in Windows PowerShell, you must add the Microsoft.SharePoint.PowerShell snap-in by using the Add-PSSnapin cmdlet, or you can run the SharePoint 2010 cmdlets by using SharePoint 2010 Management Shell. By default, the Microsoft.SharePoint.PowerShell snap-in is already registered, and the snap-in is added to the SharePoint 2010 Management Shell. To run SharePoint 2010 cmdlets, you must be a member of the SharePoint_Shell_Access role on the configuration database and a member of the WSS_ADMIN_WPG local group on the computer where SharePoint 2010 Products is installed.

For more information about the Add-PSSnapin cmdlet, see Add-PSSnapin. For more information about how to use Windows PowerShell with SharePoint 2010 Products, see SharePoint 2010 Products administration by using Windows PowerShell.

To configure the co-authoring versioning period by using Windows PowerShell

  1. Using Notepad, open a new a text file and then copy and paste the following script into the file.

    Copy Code
    $siteurl ="<ServerName>"
$mysite=new-object Microsoft.SharePoint.SPSite($siteurl)
$mysite.WebApplication.WebService.CoauthoringVersionPeriod = minutes
$mysite.WebApplication.WebService.Update()

  2. Specify the following parameters:

    Parameter Value

    $siteurl

    Server name

    CoauthoringVersionPeriod

    Number in minutes

  3. Save the file with a .ps1 file name extension to a folder where you run scripts (typically C:\scripts).

  4. From the Windows PowerShell command prompt (that is, PS C:\>), type the following command and press ENTER:

    C:\<path>\<filename>.ps1

See Also

Concepts

Configure versioning for co-authoring (SharePoint Foundation 2010)


Configure the maximum number of co-authoring authors (SharePoint Foundation 2010)
See Also

Published: August 12, 2010

This article describes how to configure the maximum number of users that can co-author a document at the same time in Microsoft SharePoint Foundation 2010.

Configure the maximum number of co-authoring authors

Administrators can limit the number of users that can co-author a document at the same time by setting the CoauthoringMaxAuthors property. This property only applies to Microsoft PowerPoint 2010 presentations and Microsoft Word 2010 documents. There is no upper limit to the number of users who can co-author Microsoft OneNote notebooks.

To configure the maximum number of co-authoring users for Word documents and PowerPoint presentations by using Windows PowerShell

  1. Verify that you meet the following minimum requirements:

    • See Add-SPShellAdmin.

    • You must read about_Execution_Policies (http://go.microsoft.com/fwlink/p/?LinkId=193050).

  2. Copy the following code and paste it into a text editor, such as Notepad:

    Copy Code
    $siteurl = "<ServerName>"
$mysite=new-object Microsoft.SharePoint.SPSite($siteurl)
$mysite.WebApplication.WebService.CoauthoringMaxAuthors = <MaxAuthors>
$mysite.WebApplication.WebService.Update()

  3. Replace:

    • <ServerName> with the name of the server.

    • <MaxAuthors> with the maximum number of authors to allow.

  4. Save the file, naming it SetMaxCoAuthors.ps1.

    Note:

    You can use a different file name, but you must save the file as an ANSI-encoded text file whose extension is .ps1.

  5. On the Start menu, click All Programs.

  6. Click Microsoft SharePoint 2010 Products.

  7. Click SharePoint 2010 Management Shell.

  8. Change to the directory where you saved the file.

  9. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    ./SetMaxCoAuthors.ps1

See Also

Concepts

Co-authoring overview (SharePoint Foundation 2010)


Disable co-authoring (SharePoint Foundation 2010)
See Also

Published: August 12, 2010

This article describes how to disable co-authoring functionality in Microsoft SharePoint Foundation 2010 by using Group Policy or by using Windows PowerShell 2.0.

Disable co-authoring

When a document is checked out from a document library, it becomes unavailable for co-authoring. Users can individually check out documents as a way to lock them so other users cannot co-author with them. Co-authoring requires that check-out not be required on any document library used for co-authoring documents. Requiring check-out in a document library is one way to disable co-authoring for the whole library. Co-authoring functionality can also be disabled on the client side using Group Policy.

Procedures in this task:

  • To disable co-authoring by using Group Policy

  • To disable co-authoring for Word documents and PowerPoint presentations at the Web Service level by using Windows PowerShell

  • To disable co-authoring for Word documents and PowerPoint presentations at the Web Application level by using Windows PowerShell

To disable co-authoring by using Group Policy

  1. On the server, click Start, click Administrative Controls, and then click Group Policy Management.

  2. In Group Policy Management, expand the Forest and Domain nodes for the domain where you want to set the policy, and then expand Group Policy Objects.

  3. Right-click the Group Policy Object where your co-authoring settings are configured, and then click Edit.

  4. For Word 2010, expand User Configuration, Administrative Templates, Microsoft Word 2010, Collaboration Settings, Co-authoring, and then double-click Prevent Co-authoring.

    For PowerPoint 2010, expand User Configuration, Administrative Templates, Microsoft PowerPoint 2010, Collaboration Settings, Co-authoring, and then double-click Prevent Co-authoring.

  5. In the Prevent Co-authoring Properties dialog box, select Enabled, and then click OK.

You can also disable co-authoring for Word and PowerPoint documents on the server by setting the DisableCoauthoring server property using Windows PowerShell.

Note:

Some procedures in this task require using Windows PowerShell or SharePoint 2010 Management Shell to run cmdlets. To run SharePoint 2010 cmdlets in Windows PowerShell, you must add the Microsoft.SharePoint.PowerShell snap-in by using the Add-PSSnapin cmdlet, or you can run the SharePoint 2010 cmdlets by using SharePoint 2010 Management Shell. By default, the Microsoft.SharePoint.PowerShell snap-in is already registered, and the snap-in is added to the SharePoint 2010 Management Shell. To run SharePoint 2010 cmdlets, you must be a member of the SharePoint_Shell_Access role on the configuration database and a member of the WSS_ADMIN_WPG local group on the computer where SharePoint 2010 Products is installed.

For more information about the Add-PSSnapin cmdlet, see Add-PSSnapin. For more information about how to use Windows PowerShell with SharePoint 2010 Products, see SharePoint 2010 Products administration by using Windows PowerShell.

To disable co-authoring for Word documents and PowerPoint presentations at the Web Service level by using Windows PowerShell

  1. Using Notepad, open a new a text file and then copy and paste the following script into the file.

    Copy Code
    $siteurl = "<servername>" $mysite=new-object Microsoft.SharePoint.SPSite($siteurl)
$mysite.WebApplication.WebService.DisableCoauthoring = $true;
$mysite.WebApplication.WebService.Update();

  2. Specify the following parameters:

    Parameter Value

    $siteurl

    Server name

  3. Save the file with a .ps1 file name extension to a folder where you run scripts (typically C:\scripts).

  4. From the Windows PowerShell command prompt (that is, PS C:\>), type the following command and press ENTER:

    C:\<path>\<filename>.ps1

To disable co-authoring for Word documents and PowerPoint presentations at the Web Application level by using Windows PowerShell

  1. Using Notepad, open a new a text file and then copy and paste the following script into the file.

    Copy Code
    $siteurl = "<servername>" $mysite=new-object Microsoft.SharePoint.SPSite($siteurl)
$mysite.WebApplication.DisableCoauthoring = $true;
$mysite.WebApplication.Update();

  2. Specify the following parameters:

    Parameter Value

    $siteurl

    Server name

  3. Save the file with a .ps1 file name extension to a folder where you run scripts (typically C:\scripts).

  4. From the Windows PowerShell command prompt (that is, PS C:\>), type the following command and press ENTER:

    C:\<path>\<filename>.ps1

See Also

Concepts

Co-authoring administration (SharePoint Foundation 2010)


Configure Information Rights Management (SharePoint Foundation 2010)

Published: October 18, 2011

Information Rights Management (IRM) enables content creators to centrally control which actions users can take on documents that have been downloaded from document libraries in Microsoft SharePoint Foundation 2010. IRM encrypts the downloaded files and limits the set of users and programs that are allowed to decrypt these files. IRM can also limit the rights of the users who are allowed to read files, so that they cannot take actions such as print copies of the files or copy text from them.

For more information about IRM as it is implemented by Rights Management Services (RMS), see RMS FAQ (http://go.microsoft.com/fwlink/p/?LinkId=230459).

Important:

Before using IRM, you must have a Windows Rights Management Services (RMS) server to connect to. In addition, you must have installed the Windows Rights Management Services Client Service Pack 2 on every front-end Web server in the farm running SharePoint Foundation 2010.

To configure Information Rights Management

  1. On the SharePoint Central Administration Web site, in the Quick Launch, click Security.

  2. On the Security page, in the Information Policy section, click Configure information rights management.

  3. On the Information Rights Management page, in the Information Rights Management section, select one of the following options:

    1. Do not use IRM on this server Select this option if you do not want to use IRM.

    2. Use the default RMS server specified in Active Directory Select this option if your organization has specified an RMS server in Active Directory Domain Services (AD DS).

    3. Use this RMS server If you select this option, type a URL that includes the protocol and the RMS server name in the corresponding box (for example, type http://rms_server).

  4. Click OK.


Security and protection for SharePoint Foundation 2010

This section provides information and best practices about how to make the Microsoft SharePoint Foundation 2010 system more secure and how to help protect data.

In this section:

  • Security planning for sites and content (SharePoint Foundation 2010)

  • Plan authentication methods (SharePoint Foundation 2010)

  • Initial deployment administrative and service accounts (SharePoint Foundation 2010)

  • Security and permissions (SharePoint Foundation 2010)

  • User permissions and permission levels (SharePoint Foundation 2010)

Security Note:

SharePoint Foundation 2010 uses several Windows encryption algorithms for computing hash values that do not comply with Federal Information Processing Standard (FIPS) 140-2, Security Requirements for Cryptographic Modules. These algorithms are not used for security purposes; they are used for internal processing. For example, SharePoint Foundation 2010 uses MD5 to create hash values that are used as unique identifiers.

Because SharePoint Foundation 2010 uses these algorithms, it does not support the Windows security policy setting that requires FIPS compliant algorithms for encryption and hashing. This Windows security policy is managed through the FIPSAlgorithmPolicy registry key in Windows, which is described in the "Configure FIPS policy for a mixed environment" section of the following topic:

  • Additional System Countermeasures (http://go.microsoft.com/fwlink/p/?LinkId=209130)

When you enable the FIPS compliant mode in Windows, you see errors that are described in the following Microsoft Knowledge Base article:

  • KB 2000371: You receive an error message when you try to start a workflow with FIPS enabled (http://go.microsoft.com/fwlink/p/?LinkId=209131)

FIPS 140-2 defines security standards that the United States and Canadian governments use to validate security levels for products that implement cryptography. For more information about FIPS 140-2, see the following references:

  • FIPS 140 Evaluation (http://go.microsoft.com/fwlink/p/?LinkId=209132)

  • FIPS Publications (http://go.microsoft.com/fwlink/p/?LinkId=209157)

The goal of FIPS is to provide a standardized way to ensure the security and privacy of sensitive information in computer systems of the United States and Canadian governments. Using a FIPS compliant algorithm for encryption of data over an open network is a key requirement for FISMA certification. The Windows FIPSAlgorithmPolicy registry key is neither necessary nor sufficient for FISMA certification, it is a useful enforcement tool for many solutions, but not SharePoint Foundation 2010.

The FIPS contribution to FISMA certification is the strength of encryption used for security purposes. Security-related encryption within SharePoint Foundation 2010 is performed by using FIPS-compliant cipher suites.

For additional information about FISMA, FISMA certification, and reverse proxy see the following articles:

  • Federal Information Security Management Act (FISMA) Implementation Project (http://go.microsoft.com/fwlink/?LinkId=242329)

  • Microsoft Office 365(http://go.microsoft.com/fwlink/?LinkId=215509)

  • Microsoft News Center (http://go.microsoft.com/fwlink/?LinkId=242330)

  • http://go.microsoft.com/fwlink/?LinkId=242339 (http://go.microsoft.com/fwlink/?LinkId=242339)


Troubleshooting (SharePoint Foundation 2010)

Published: March 24, 2011

This section provides information to help IT pros troubleshoot Microsoft SharePoint Foundation 2010. The troubleshooting information is organized according to the logical areas interesting to the SharePoint administrator.

We encourage you to give us your feedback. Your comments, suggestions, and troubleshooting tips can be incorporated into future versions of this content. You can send your feedback to us at ITSPDOCS@microsoft.com.

In this section:

  • Mobile device troubleshooting (SharePoint Foundation 2010)


Mobile device troubleshooting (SharePoint Foundation 2010)
See Also

Published: March 24, 2011

This article helps you troubleshoot issues that you might encounter with mobile devices.

In this article:

  • Apple iPad users are not redirected to the mobile view

Apple iPad users are not redirected to the mobile view

The SharePoint standard view is not supported on Apple iPad devices. Instead, users can use the mobile view to view SharePoint content on their iPad devices. By default, iPad users are redirected to the standard view of SharePoint sites. This is because the iPad user agent is not included in the browser definition file (compat.browser). To change the default view for iPad users, you must add the iPad user agent string to the compat.browser file and set isMobileDevice to true. This redirects iPad users to the mobile view of a SharePoint site.

The following example shows a user agent string that can be used for iPad devices.

Copy Code
<!-- iPad Safari Browser -->
<!-- sample UA "Mozilla/5.0 (iPad; U; CPU OS 4_2_1 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148 Safari/6533.18.5" -->
<browser id="iPadSafari" parentID="AppleSafari">
<identification>
<userAgent match="iPad" />
<userAgent match="Mobile" />
</identification>
<capabilities>
<capability name="isMobileDevice" value="true" />
<capability name="canInitiateVoiceCall" value="true" />
<capability name="optimumPageWeight" value="1500" />
<capability name="requiresViewportMetaTag" value="true" />
<capability name="supportsTouchScreen" value="true" />
<capability name="telephoneNumberDetectionDisabled" value="true" />
</capabilities>
</browser>

For more information about how to update the compat.browser file, see the Modify the browser definition file (compat.browser) section in Configure mobile views (SharePoint Foundation 2010). For more information about how to use iPad devices with SharePoint 2010 Products, see SharePoint 2010 and Apple iPad (http://go.microsoft.com/fwlink/p/?LinkID=214218).

See Also

Concepts

Plan for mobile devices (SharePoint Foundation 2010)
Mobile administration (SharePoint Foundation 2010)


Office Web Apps troubleshooting (Installed on SharePoint 2010 Products)

Published: May 16, 2012

This article contains information to help IT pros troubleshoot Microsoft Office Web Apps.

We encourage you to give us your feedback. Your comments, suggestions, and troubleshooting tips can be incorporated into future versions of this content. You can send your feedback to us at ITSPDOCS@microsoft.com.

When the SharePoint administrator installs and configures Microsoft Office Web Apps, he or she, or end users, might encounter any of the following error messages or issues:

  • End users cannot view or edit Office 2010 documents in the browser

  • Office 2010 documents open in the client application instead of in the browser

  • An end user cannot open an Office 2010 document in the client application by using the button on the toolbar

  • When you try to uninstall Office Web Apps, you receive an error that it has already been uninstalled

  • When you attempt to reinstall SharePoint Server 2010 on a computer, you receive an error that there is a conflict with SharePoint 2010 Products that were previously installed

The following sections describe possible causes and how to fix these issues.

End users cannot view or edit Office 2010 documents in the browser

After the SharePoint administrator has installed, configured, and activated Office Web Apps, end users might receive an error message when they try to view or edit Microsoft Word, Microsoft Excel, Microsoft PowerPoint, or Microsoft OneNote documents in the browser.

The error messages might include, but are not limited to, the following:

  • Unable to process the request.

  • An unexpected error has occurred.

  • PowerPoint Web App encountered an error. Please try again.

  • Word Web App cannot open this document due to an unknown error. If the problem persists, try opening the file in Microsoft Word.

  • OneNote Web App cannot open this notebook because the Office Web Apps Feature isn't activated on this site collection. Try opening the file in Microsoft OneNote.

  • The file that you selected could not be found. Check the spelling of file name and verify that the location is correct. Make sure that the file has not been renamed, moved, or deleted.

These errors might occur for one or more of the following reasons:

  • The SharePoint administrator has run Office Web Apps Setup, which configures the default open behavior for SharePoint to open Microsoft Word, Excel, PowerPoint, and OneNote documents in the browser by using their associated Web application. However, the SharePoint administrator has not yet started the services, created the service applications, and activated the Office Web Apps feature.

  • The Office Web Apps services are not started on the Web front-end server.

  • The Office Web Apps service applications and proxies have not been created.

  • The Office Web Apps service applications proxies are not associated with the proxy group of the Web application that the site collection belongs to.

  • There might be a problem with the permissions for the service account that is used to run the Web application or one of the Office Web Apps services: Excel Calculation Services, PowerPoint Service, or Word Viewing Service. The Web application and service applications must have the appropriate permissions to access the content databases and the configuration database.

To resolve these errors, apply the following solutions:

  • The SharePoint administrator can avoid end users' seeing error messages while he or she finishes additional deployment tasks to deploy Office Web Apps on a live production server. We recommended that you enable the OpenInClient feature on existing site collections before you run Setup. For more information, see Configure the default open behavior for browser-enabled documents (Office Web Apps).

  • Activate the Office Web Apps feature for the site collection. For information about how to activate the Office Web Apps feature for a site collection, see Activate the Office Web Apps feature in Deploy Office Web Apps (Installed on SharePoint 2010 Products).

  • Verify that the services have been created and check the status of the services on the servers in the farm by doing the following:

    1. On the Central Administration Web site, in Application Management, click Manage services on server.

    2. On the Services on Server page, do the following:

      1. In the list of services on the selected server, verify that Excel Calculation Services, PowerPoint Service, and Word Viewing Service exist and are started. If a service is not started, click Start.

      2. Click the Server button at the top, click Change Server, and then in the Select Server dialog box, click a different server name.

      3. Repeat these steps until you have verified that the services exist and are started on all servers in the farm.

  • Verify that the Office Web Apps service applications and proxies have been created by doing the following:

    1. On the Central Administration Web site, in Application Management, click Manage service applications.

    2. On the Manage Service Applications page, verify that there the following kinds of service applications exist:

      • Excel Services Application Web service application

      • PowerPoint service application

      • Word Viewing service application

    Verify that the service applications have been created. For information about how to create service applications, see Create the service applications and the service application proxies in Deploy Office Web Apps (Installed on SharePoint 2010 Products).

  • Verify that the Office Web Apps service applications and proxies are associated with the proxy group of the Web application that the site collection belongs to by doing the following:

    1. On the Central Administration Web site, in Application Management, click Manage web applications.

    2. On the Web Applications Management page, select the Web applications that the site collection belongs to, and then click Service Connections.

    3. On the Configure Service Application Associations page, verify that the following kinds of service application proxies are associated with the Web application:

      • Excel Services Application Web service application proxy

      • PowerPoint service application proxy

      • Word Viewing service application proxy

      For information about how to add service application connections to a Web application, see Add or remove a service application connection to a Web application (SharePoint Server 2010) or Add or remove a service application connection to a Web application (SharePoint Foundation 2010).

  • Verify that the service account permissions for the Web application and the Office Web Apps services are appropriate. The Web application and service applications must have the appropriate permissions to access the content databases and the configuration database. For information about the appropriate service account permissions for the Web application and the Office Web Apps services, see Account permissions and security settings (SharePoint Server 2010).

Office 2010 documents open in the client application instead of in the browser

Except for Excel, the default open behavior for a site collection is to open Office 2010 documents in the client application, if the client application is installed. If the SharePoint administrator installs Office Web Apps and then the Office Web Apps feature is activated for a site collection, the default open behavior is set to open Office 2010 documents in the browser.

If the documents do not open in the browser, it could be for the following reasons:

  • The Office Web Apps feature is not activated for the site collection in which the document resides.

  • The Open Documents in Client Applications by Default feature is activated for the site collection in which the document resides.

To resolve this error, do the following:

  • Verify that the Office Web Apps feature is activated for the site collection in which the document resides. For information about how to activate the Office Web Apps feature for the site in which the document resides, see Activate the Office Web Apps feature in Deploy Office Web Apps (Installed on SharePoint 2010 Products).

  • Verify that the Open Documents in Client Applications by Default feature is not activated for the site collection in which the document resides. For information about the Open Documents in Client Applications by Default feature, see Configure the default open behavior for browser-enabled documents (Office Web Apps).

An end user cannot open an Office 2010 document in the client application by using the button on the toolbar

While using Office Web Apps, an end user clicks the Open in Word, Open in PowerPoint, Open in Excel, or Open in OneNote button on the toolbar and receives a message that states that the file cannot be opened in the client application.

This error might occur for one or more of the following reasons:

  • The user is running a 64-bit version of Internet Explorer.

  • The ActiveX control necessary for opening the file in the Office client application is not installed or is not running in the browser.

  • Microsoft Office is not installed on the client computer.

  • The version of Office that is installed is earlier than Office 2003.

  • Security settings in Internet Explorer prevent ActiveX controls from running.

  • The browser does not support ActiveX.

  • The client browser is Firefox, but the plug-in that enables Firefox to open Office documents is not installed.

When you try to uninstall Office Web Apps, you receive an error that it has already been uninstalled

If you uninstall SharePoint Server 2010 before you uninstall Office Web Apps and then attempt to uninstall Office Web Apps by using Control Panel, you will receive an error that Office Web Apps has already been uninstalled. This situation does not apply to Microsoft SharePoint Foundation 2010.

To resolve this error, see You cannot use Programs and Features within Control Panel to remove Office Web Apps from Windows Server 2008 (http://go.microsoft.com/fwlink/p/?LinkId=215534).

When you attempt to reinstall SharePoint Server 2010 on a computer, you receive an error that there is a conflict with SharePoint 2010 Products that were previously installed

You might encounter an error if you uninstall SharePoint Server 2010 but do not uninstall Office Web Apps, and then attempt to reinstall SharePoint Server 2010 on the same server. In this situation, you will receive an error that there is a conflict with a previously installed Microsoft Office 2010 Server product.

To resolve this error, see You cannot use Programs and Features within Control Panel to remove Office Web Apps from Windows Server 2008 (http://go.microsoft.com/fwlink/p/?LinkId=215534).


Technical reference for SharePoint Foundation 2010
See Also

Technical reference includes information about Windows PowerShell for Microsoft SharePoint Foundation 2010 and other useful reference information about general settings, security, and tools.

In this section:

  • Windows PowerShell for SharePoint Foundation 2010

  • System Center Operations Manager knowledge articles (SharePoint Foundation 2010)

  • Installation reference (SharePoint Foundation 2010)

  • User permissions and permission levels (SharePoint Foundation 2010)

  • Database types and descriptions (SharePoint Foundation 2010)

  • User experience on read-only sites (SharePoint Foundation 2010)

  • Language packs (SharePoint Foundation 2010)

  • SharePoint 2010 Administration Toolkit (SharePoint Foundation 2010)

  • Peoplepicker-peopleeditoronlyresolvewithinsitecollection: Stsadm property (SharePoint Foundation 2010)

See Also

Other Resources

Stsadm command-line tool (Windows SharePoint Services)


Windows PowerShell for SharePoint Foundation 2010
See Also

Windows PowerShell can be used with Microsoft SharePoint Foundation 2010 to perform both simple and complex administrative tasks. Information about cmdlets in SharePoint Foundation 2010 is currently accessible using command-line Help. For information about Windows PowerShell in general, visit the Windows PowerShell Technology Center (http://go.microsoft.com/fwlink/p/?LinkId=167152).

In this section:

  • SharePoint 2010 Products administration by using Windows PowerShell

  • Windows PowerShell for SharePoint Foundation 2010 reference

  • Index of SharePoint Foundation 2010 Windows PowerShell cmdlets

  • Updates to Windows PowerShell cmdlets (SharePoint Foundation 2010)

  • Stsadm to Windows PowerShell mapping (SharePoint Foundation 2010)

  • Microsoft Press: Using Windows PowerShell to Perform and Automate Farm Administrative Tasks

See Also

Other Resources

Resource Center: What's New in SharePoint Foundation 2010


SharePoint 2010 Products administration by using Windows PowerShell

This article describes how to use Windows PowerShell with Microsoft SharePoint 2010 Products and provides an overview of basic Windows PowerShell cmdlets and concepts necessary to get the most benefit from this powerful functionality.

In this article:

  • Overview

  • Accessing Windows PowerShell for SharePoint 2010 Products

  • Permissions

  • Scripts and execution policies

  • Learning Windows PowerShell

Overview

Windows PowerShell is a command-line scripting tool that provides an administrator full access to applicable application programming interfaces (APIs), along with the ability to unlock the capability to interact directly with SharePoint 2010 Products to manipulate Web applications, site collections, sites, lists and much more. In addition, the administrator has the ability to script cmdlets (pronounced "command-lets"), which makes for an improved experience from past product versions.

Windows PowerShell 2.0 is a pre-requisite for installing SharePoint 2010 Products. It will be installed, if necessary, when you run the Microsoft SharePoint Products Preparation Tool. By default, Windows PowerShell is located at the following path: <%SystemRoot%>\System32\WindowsPowerShell\v1.0\PowerShell.exe.

Note:

Windows PowerShell 2.0 is backward compatible with Windows PowerShell 1.0 and subsequently installs to the v1.0 folder.

For a list of new features for Windows PowerShell version 2.0, see About Windows PowerShell 2.0 (http://go.microsoft.com/fwlink/p/?LinkId=113247).

For an interactive tool and guide that helps you learn Windows PowerShell syntax, see Windows PowerShell Command Builder Tool and Getting Started Guide.

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.

Accessing Windows PowerShell for SharePoint 2010 Products

After installing SharePoint 2010 Products, the applicable Windows PowerShell cmdlets are available by using the SharePoint 2010 Management Shell, or by using the Windows PowerShell console. With the management shell, you can manage every aspect of SharePoint 2010 Products. You can create new site collections, Web applications, user accounts, service applications, proxies, and more. The commands from the management shell output SharePoint objects based on the Microsoft .NET Platform. These objects can be applied as input to subsequent commands or stored in local variables for later use.

With the management shell, you do not have to register the snap-in that contains the cmdlets. Registration of the Microsoft.SharePoint.PowerShell.dll module for SharePoint 2010 cmdlets is automatic, as a result of the line Add-PSSnapin Microsoft.SharePoint.PowerShell in the SharePoint.ps1 file located in %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\14\Config\PowerShell\Registration. If you choose to use the Windows PowerShell console, you must register this snap-in manually.

Whether you are using the management shell or the Windows PowerShell console, you can also load additional snap-ins. For more information, see Customizing Profiles (http://go.microsoft.com/fwlink/p/?LinkId=183166).

To access the SharePoint 2010 Management Shell

  1. On the Start menu, click All Programs.

  2. Click Microsoft SharePoint 2010 Products.

  3. Click SharePoint 2010 Management Shell.

Note:

The SharePoint 2010 Management Shell and the Windows PowerShell console also differ in the use of the ReuseThread option, which defines how the threading model is used. The management shell's use is defined by this line, {Host.Runspace.ThreadOptions = "ReuseThread"}, which is in the SharePoint.ps1 file. For more information, see PS Thread Options (http://go.microsoft.com/fwlink/p/?LinkId=183145).

Permissions

Before you can use the management shell and the Windows PowerShell cmdlets, verify that you meet the following minimum requirements: See Add-SPShellAdmin.

If you do not have membership in the SharePoint_Shell_Access role or WSS_Admin_WPG local group, use the Add-SPShellAdmin cmdlet. When the Add-SPShellAdmin cmdlet is used, the user is added to the WSS_Admin_WPG group in all front-end Web servers and is added to the SharePoint_Shell_Access role. If the target database does not have a SharePoint_Shell_Access role, the role is automatically created. Once the Add-SPShellAdmin cmdlet has been run, the user can run SharePoint 2010 Windows PowerShell cmdlets in a multiple-server farm environment.

When you run the Add-SPShellAdmin cmdlet to add a user to the SharePoint_Shell_Access role, you must have the following security permissions:

  • Securityadmin server role access on the SQL instance and the db_owner role in a database.

  • Administrative permission on the local computer.

Note:

Typically, the person that will use the Add-SPShellAdmin cmdlet must be associated with the user account that was used for Setup.

You must run the Add-SPShellAdmin cmdlet for all databases to which you want to grant access. If no database is specified, the farm configuration database is used. If you do specify a database, the farm content database will be included in addition to the farm configuration database you specify.

To see a list of all of the *SPShellAdmin cmdlets, from a Windows PowerShell command prompt, type Get-Command -Noun SPShellAdmin.

Scripts and execution policies

Although you can use Windows PowerShell to perform a single administrative task, the real benefit of using Windows PowerShell cmdlets is the ability to use a script to automate a series of tasks. A script is a plain text file that contains one or more Windows PowerShell commands. Windows PowerShell scripts have a .ps1 file name extension.

When using a script, be aware that the minimum required execution policy for SharePoint 2010 Products is RemoteSigned, while the default policy for Windows PowerShell is Restricted. If the policy is left as Restricted, the SharePoint 2010 Management Shell will change the policy for Windows PowerShell to RemoteSigned. This means the SharePoint 2010 Management Shell must be launched with elevated administrative permission by selecting Run as administrator. This change will apply to all Windows PowerShell sessions.

For additional information about scripts and execution polices, see about_scripts and about_Execution_Policies respectively.

Learning Windows PowerShell

There are several Windows PowerShell learning resources for SharePoint IT professionals who are not familiar with Windows PowerShell.

TechNet Scripting Center

The TechNet Scripting Center includes many resources for learning the basics of using Windows PowerShell. It also contains script repositories with samples of scripts commonly used with various Microsoft products. The following table shows the main learning resources.

Page | Description
Windows PowerShell Documentation on TechNet (http://go.microsoft.com/fwlink/p/?LinkId=187813) | This section of the TechNet Library contains Web copies of the core Windows PowerShell Get-Help topics. The section also has Web copies of the Windows PowerShell Getting Started document, the PowerShell.exe help, and a Windows PowerShell primer.
Scripting With Windows PowerShell (http://go.microsoft.com/fwlink/p/?LinkId=187815) | The home page for Windows PowerShell scripting learning resources.
Windows PowerShell Owner's Manual (http://go.microsoft.com/fwlink/p/?LinkId=187817) | Web-based guide for getting started with Windows PowerShell.
Windows PowerShell Quick Reference (http://go.microsoft.com/fwlink/p/?LinkId=187819) | Downloadable copy of the Quick Reference document installed with Windows PowerShell.

Windows PowerShell documents

Windows PowerShell installs the following documents in the Windows PowerShell 1.0 program group. They can also be installed after downloading the Windows PowerShell 1.0 Documentation Pack (http://go.microsoft.com/fwlink/p/?LinkId=187822).

File | Description
GettingStarted.rtf | Describes how to start using Windows PowerShell.
UsersGuide.rtf | A primer for the Windows PowerShell environment and language.
QuadFold.rtf | A printable quick reference document for the commonly used Windows PowerShell syntax and commands. Also available as a download from the TechNet Scripting Center.

As you read these resources, consider that the following concepts and cmdlets are useful ones to learn before using Windows PowerShell for SharePoint 2010 Products:

  • Get-Command (http://go.microsoft.com/fwlink/p/?LinkId=171069)

  • Get-Member (http://go.microsoft.com/fwlink/p/?LinkId=171070)

  • Get-Help (http://go.microsoft.com/fwlink/p/?LinkId=171068).

  • Aliasing (http://go.microsoft.com/fwlink/p/?LinkId=113207)

  • Piping and the Pipeline in Windows PowerShell (http://go.microsoft.com/fwlink/?LinkId=187808)

  • Cmdlet Parameter Sets (http://go.microsoft.com/fwlink/p/?LinkId=187810)

  • Foreach-Object (http://go.microsoft.com/fwlink/p/?LinkId=187812)

  • Where-Object (http://go.microsoft.com/fwlink/p/?LinkId=187811)


Windows PowerShell for SharePoint Foundation 2010 reference

The following articles list Windows PowerShell cmdlets for Microsoft SharePoint Foundation 2010 by functionality:

  • Backup and recovery cmdlets (SharePoint Foundation 2010)

  • Business Connectivity Services cmdlets (SharePoint Foundation 2010)

  • Database cmdlets (SharePoint Foundation 2010)

  • Farm cmdlets (SharePoint Foundation 2010)

  • Features and solutions cmdlets (SharePoint Foundation 2010)

  • General cmdlets (SharePoint Foundation 2010)

  • Health monitoring cmdlets (SharePoint Foundation 2010)

  • Import and export cmdlets (SharePoint Foundation 2010)

  • Logging and events cmdlets (SharePoint Foundation 2010)

  • Performance cmdlets (SharePoint Foundation 2010)

  • Security cmdlets (SharePoint Foundation 2010)

  • Service application cmdlets (SharePoint Foundation 2010)

  • SharePoint Foundation 2010 Search cmdlets (SharePoint Foundation 2010)

  • Site collection cmdlets (SharePoint Foundation 2010)

  • Site management cmdlets (SharePoint Foundation 2010)

  • Timer jobs cmdlets (SharePoint Foundation 2010)

  • Upgrade and migration cmdlets (SharePoint Foundation 2010)

  • Web application cmdlets (SharePoint Foundation 2010)

  • Workflow management cmdlets (SharePoint Foundation 2010)


Backup and recovery cmdlets (SharePoint Foundation 2010)
See Also

A backup is a copy of data that is used to restore and recover that data after a system failure. Maintaining backups of data is useful for routine purposes, such as copying a database from one server to another, setting up database mirroring, archiving for governmental purposes, and disaster recovery.

In Microsoft SharePoint Foundation 2010, you can use Windows PowerShell functionality to perform a backup or restore process for the following items:

  • Farm

  • Site collection

  • Configuration database

  • Services

  • List or document

Cmdlet name | Description
Backup-SPConfigurationDatabase | Performs a farm-level configuration-only backup.
Backup-SPFarm | Creates a backup of an individual database, Web application, or the entire farm.
Restore-SPFarm | Restores one or more items from a backup.
Backup-SPSite | Performs a backup of a site collection.
Restore-SPSite | Restores a site collection.
Get-SPBackupHistory | Returns a history of backup and restore operations.

See Also

Other Resources

Resource Center: Windows PowerShell for SharePoint Foundation 2010


Backup-SPConfigurationDatabase
See Also Example
[image]

Published: May 12, 2010

Performs a farm-level configuration-only backup.

Backup-SPConfigurationDatabase -Directory <String> [-AssignmentCollection <SPAssignmentCollection>] [-DatabaseCredentials <PSCredential>] [-DatabaseName <String>] [-DatabaseServer <String>] [-Item <String>]
Backup-SPConfigurationDatabase -ShowTree <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>] [-DatabaseCredentials <PSCredential>] [-DatabaseName <String>] [-DatabaseServer <String>] [-Item <String>]

Parameters

1

Parameter

Required

Type

Description

Directory

Required

System.String

Specifies the path where SharePoint 2010 Products stores the backup package it generates. If you have a computer on which Microsoft SQL Server 2008 and an instance of SharePoint 2010 Products are installed, you can use local drive paths. This includes a basic installation. However, if SQL Server 2008 and SharePoint 2010 Products are installed on multiple computers or if you have multiple servers running SharePoint 2010 Products, you must use Universal Naming Convention (UNC) share paths so that the SQL Server database and search components are written to the same location; for example, \\computer_name\volume\Backup).

Multiple backup packages can be stored in the same location. This is the same path that you pass to the Directory parameter of the Restore-SPFarm cmdlet.

The type must be either of the valid paths:

- C:\folder_name

- \\server_name\folder_name

Note:

The spbr* folders are automatically created.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

DatabaseCredentials

Optional

System.Management.Automation.PSCredential

Specifies the ID and password that corresponds to the administrator user name for the SQL Server database.

This parameter should only be specified if SQL authentication is used to connect to the database. If Windows authentication is used to connect to the database, then this parameter should not be specified.

DatabaseName

Optional

System.String

Specifies the configuration database name.

DatabaseServer

Optional

System.String

Specifies the SQL database server that contains the configuration database. The default value is the local computer name.

The type must be a valid database server; for example, DS.

Item

Optional

System.String

Indicates the part of the farm to back up. You may use the full farm path notation as displayed by the ShowTree parameter or the name of the target component in the path if the component has a unique name. If multiple items match the name, the full path must be provided. Surround the item or path in quotation marks if it contains a space.

If the Item parameter is not specified, the entire farm configuration is backed up.

2

Parameter

Required

Type

Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

DatabaseCredentials

Optional

System.Management.Automation.PSCredential

Specifies the ID and password that corresponds to the administrator user name for the SQL Server database.

This parameter should only be specified if SQL authentication is used to connect to the database. If Windows authentication is used to connect to the database, then this parameter should not be specified.

DatabaseName

Optional

System.String

Specifies the configuration database name.

DatabaseServer

Optional

System.String

Specifies the SQL database server that contains the configuration database. The default value is the local computer name.

The type must be a valid database server; for example, DS.

Item

Optional

System.String

Indicates the part of the farm to back up. You may use the full farm path notation as displayed by the ShowTree parameter or the name of the target component in the path if the component has a unique name. If multiple items match the name, the full path must be provided. Surround the item or path in quotation marks if it contains a space.

If the Item parameter is not specified, the entire farm configuration is backed up.

ShowTree

Optional

System.Management.Automation.SwitchParameter

Displays which objects in the farm will be backed up based on the other parameters passed to the backup cmdlet, namely the Item parameter. Items that will be excluded from the backup based on the other parameters passed to the Backup-SPConfigurationDatabase cmdlet will be preceded with an asterisk character (*). Items that cannot be backed up will be enclosed in square brackets ([ ]). A backup will not be performed if the ShowTree parameter is present.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Backup-SPConfigurationDatabase cmdlet performs a configuration-only backup of the current farm or a configuration-only backup of a separate configuration database which is not attached to the current farm. If you wish to perform a configuration-only backup of the current farm, there is no need to specify the DatabaseServer and DatabaseName parameters. However, using the Backup-SPFarm cmdlet with the ConfigurationOnly parameter is recommended for such a scenario.

An example of a configuration backup is an administrator creates a farm configuration template which then can be applied to other SharePoint farms by performing a restore using the Restore-SPFarm cmdlet.

Input Types

Return Types

Example

-------------------EXAMPLE 1--------------------

Copy Code
Backup-SPConfigurationDatabase -DatabaseName SharePoint_Config -DatabaseServer SqlServer1 -Directory \\server\share\Backup -ShowTree

This example displays components that are available for inclusion in a configuration-only backup.

-------------------EXAMPLE 2--------------------

Copy Code
Backup-SPConfigurationDatabase -DatabaseName SharePoint_Config -DatabaseServer SqlServer1 -Directory \\server\share\Backup -Verbose

This example performs a configuration-only backup with verbose output.

See Also

Reference

Connect-SPConfigurationDatabase
Disconnect-SPConfigurationDatabase
New-SPConfigurationDatabase
Remove-SPConfigurationDatabase
Restore-SPFarm


Backup-SPFarm
See Also Example
[image]

Published: May 12, 2010

Creates a backup of an individual database, Web application, or the entire farm.

Backup-SPFarm -BackupMethod <String> -Directory <String> [-AssignmentCollection <SPAssignmentCollection>] [-BackupThreads <Int32>] [-ConfigurationOnly <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-Item <String>] [-Percentage <Int32>] [-WhatIf [<SwitchParameter>]]
Backup-SPFarm -ShowTree <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>] [-ConfigurationOnly <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-Item <String>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

BackupMethod

Required

System.String

Specifies the type of backup file to be created.

If a backup is performed with the -ShowTree parameter, then the BackupMethod parameter is not used.

A full backup is a backup of all the selected data. A differential backup is a backup of all the selected data that has changed since the last full backup. If an item does not support differential backup, then a full backup is performed for that item instead.

The type must be either of the following:

- Full

- Differential

Directory

Required

System.String

Specifies the path where SharePoint 2010 Products stores the backup package it generates. If you have a computer on which Microsoft SQL Server 2008 and an instance of SharePoint 2010 Products are installed, you can use local drive paths. This includes a basic installation. However, if SQL Server 2008 and SharePoint 2010 Products are installed on multiple computers or if you have multiple servers running SharePoint 2010 Products, you must use Universal Naming Convention (UNC) share paths so that the SQL Server database and search components are written to the same location; for example, \\computer_name\volume\Backup).

Multiple backup packages can be stored in the same location. This is the same path that you pass to the Directory parameter of the Restore-SPFarm cmdlet.

The type must be either of the valid paths:

- C:\folder_name

- \\server_name\folder_name

Note:

The spbr* folders are automatically created.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

BackupThreads

Optional

System.Int32

Specifies the number of threads to be used during the backup. The fewer the threads, the easier the backup log file is to read and understand. The more the threads, the more components that can be backed up in parallet, potentially resulting in a faster backup operation. The minimum value is 1 and the maximum value is 10.

The default value is 3.

If a backup is performed with the -ShowTree parameter, then the BackupMethod parameter is not used.

ConfigurationOnly

Optional

System.Management.Automation.SwitchParameter

If set, the backup will contain configuration settings only (no data) for each of the objects to be backed up.

Force

Optional

System.Management.Automation.SwitchParameter

Specifies to proceed with a backup operation even if the estimation is that the backup directory does not have sufficient space to hold the entire backup.

If a backup is performed with the ShowTree parameter, then the Force parameter is not used.

Item

Optional

System.String

Indicates the part of the farm to back up. You might use the full farm path notation as displayed by the ShowTree parameter or the name of the target component in the path if the component has a unique name. If multiple items are included in the same match, the full path must be provided. By default, the top node is selected. Surround the item or path in quotation marks if it contains a space. If this parameter is not specified, the entire farm is backed up.

The type must be a valid item; for example, Farm\Microsoft SharePoint Foundation Web Application\SharePoint - 80.

Percentage

Optional

System.Int32

Requests progress updates about the backup operation to be displayed in increments of that percentage; for example, a value of 5 displays backup progress updates at every 5 percent completed, and a value of 10 displays backup progress updates at every 10 percent completed. To have progress outputs displayed, you must specify the Verbose parameter.

Note:

This percentage is not precise and the actual progress updates might be lower or higher than requested. Progress updates are always recorded in the backup log file.

The percentage value is not prcesie and the actual progress updates might be lower or higher than requested.

The default value is 5. For a very large database, 1 is the recommended value.

Valid values are an integer value between 1 and 100.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

ShowTree

Required

System.Management.Automation.SwitchParameter

Displays which objects in the farm will be backed up based on the other parameters passed to the Backup-SPFarm cmdelt, namely the Item parameter. Items that will be excluded from the backup based on the other parameters passed to the Backup-SPFarm cmdlet will be preceded with an asterisk character (*). Items that cannot be backed up will be enclosed in square brackets ([ ]). A backup will not be performed if the ShowTree parameter is present.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

ConfigurationOnly

Optional

System.Management.Automation.SwitchParameter

If set, the backup will contain configuration settings only (no data) for each of the objects to be backed up.

Item

Optional

System.String

Indicates the part of the farm to back up. You might use the full farm path notation as displayed by the ShowTree parameter or the name of the target component in the path if the component has a unique name. If multiple items are included in the same match, the full path must be provided. By default, the top node is selected. Surround the item or path in quotation marks if it contains a space. If this parameter is not specified, the entire farm is backed up.

The type must be a valid item; for example, Farm\Microsoft SharePoint Foundation Web Application\SharePoint - 80.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Backup-SPFarm cmdlet creates a backup for the entire farm or individual components within the farm. It can also be used to back up just the configuration settings of a farm to be used as a farm template for other SharePoint farms. If you want to back up a single site collection, use the Backup-SPSite cmdlet.

Input Types

Return Types

Example

--------------------EXAMPLE 1---------------------

Copy Code
Backup-SPFarm -Directory \\file_server\share\Backup -BackupMethod full -ConfigurationOnly

This example backs up the configuration settings of the farm to the \\file_server\share\Backup directory.

--------------------EXAMPLE 2---------------------

Copy Code
Backup-SPFarm -ShowTree -Item "Microsoft SharePoint Foundation Web Application" -Verbose

This example shows which components of the farm would be backed up under the "Microsoft SharePoint Foundation Web Application" node, but do not actually back them up.

--------------------EXAMPLE 3---------------------

Copy Code
Backup-SPFarm -Directory C:\Backup -BackupMethod full -BackupThreads 10 -Force

This example performs a backup of a farm using 10 threads and forces the backup to be saved to the C:\Backup directory even though SharePoint estimates that it does not have sufficient space available.

See Also

Reference

Backup-SPConfigurationDatabase
Get-SPBackupHistory
Restore-SPFarm


Backup-SPSite
See Also Example
[image]

Published: May 12, 2010

Performs a backup of a site collection.

Backup-SPSite [-Identity] <SPSitePipeBind> -Path <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-NoSiteLock <SwitchParameter>] [-UseSqlSnapshot <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Specifies the URL or GUID of the site collection to be backed up.

For example, a valid URL, such as http://server_name/sites/site_name or a GUID such as, "01234567-89ab-cdef-0123-456789abcdef"

Path

Required

System.String

Specifies the full path to the backup file (that is, C:\Backup\site_name.bak.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Specify to overwrite an existing backup file if it already exists.

NoSiteLock

Optional

System.Management.Automation.SwitchParameter

Specifies the site collection to remain read and write during the backup.

If the NoSiteLock parameter is not specified, then a site collection that has a site collection lock setting of "none" or "no additions" will be temporarily set to "read only" while the site collection backup is performed. Once the backup has completed, the site collection lock will return to its original state. The backup package will record the original site collection lock state so that it is restored to that state.

If users are writing to the site collection while the site collection is being backed up, then the NoSiteLock parameter is not recommended for potential impact to backup integrity

UseSqlSnapshot

Optional

System.Management.Automation.SwitchParameter

Specifies a SQL Database Snapshot will be created when the backup begins, and all site collection data will be retrieved directly from the database snapshot. This snapshot will be deleted automatically when the backup completes

The UseSqlSnapshot parameter is recommended if the database server hosting your content database supports database snapshots such as SQL Server Enterprise Edition and SQL Server Developer Edition. This is because it will ensure a valid backup while allowing users to continue reading and writing to the site collection during the backup. It is not necessary to specify the NoSiteLock parameter when specifying the UseSqlSnapshot parameter.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Backup-SPSite cmdlet performs a backup of the site collection when the Identity parameter is used.

By default, the site collection will be set to read-only for the duration of the backup to reduce the potential for user activity during the backup operation to corrupt the backup. If you have SQL Server Enterprise Edition, we recommend that UseSqlSnapshot parameter be used because this ensures a valid backup while it allows users to continue reading and writing to the site collection during the backup.

Input Types

Return Types

Example

-------------------EXAMPLE 1--------------------

Copy Code
Backup-SPSite http://server_name/sites/site_name -Path C:\Backup\site_name.bak

This example backs up a site collection at http://server_name/sites/site_name to the C:\Backup\site_name.bak file.

-------------------EXAMPLE 2--------------------

Copy Code
Get-SPSiteAdministration http://server_name/sites/site_name | Backup-SPSite -Path C:\Backup\site_name.bak

This example backs up a site collection at http://server_name/sites/site_name to the C:\Backup\site_name.bak file. Same result as Example 1, but a different way of performing the operation.

-------------------EXAMPLE 3--------------------

Copy Code
Backup-SPSite http://server_name/sites/site_name -Path C:\Backup\site_name.bak -UseSqlSnapshot

This example backs up a site collection using database snapshots to ensure backup integrity.

See Also

Reference

Get-SPSite
Move-SPSite
Restore-SPSite
Set-SPSite
Get-SPSiteAdministration


Get-SPBackupHistory
See Also Example
[image]

Published: May 12, 2010

Returns a history of backup and restore operations.

Get-SPBackupHistory -Directory <String> [-AssignmentCollection <SPAssignmentCollection>] [-ShowBackup <SwitchParameter>] [-ShowRestore <SwitchParameter>]

Parameters

Parameter Required Type Description

Directory

Required

System.String

Specifies the path where the SharePoint 2010 Products backup packages generated from a farm backup have been stored.

The type must be a valid path in either of the following forms:

- C:\folder_name

- \\server_name\folder_name

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

ShowBackup

Optional

System.Management.Automation.SwitchParameter

Filters the output so that the history of backup operations only is displayed. If both the ShowBackup and the ShowRestore parameters are not specified, the history of both backup and restore operations is displayed.

ShowRestore

Optional

System.Management.Automation.SwitchParameter

Filters the output so that the history of restore operations only is displayed. If both the ShowBackup and the ShowRestore parameters are absent, the history of both backup and restore operations is displayed.

Detailed Description

The Get-SPBackupHistory cmdlet reads a history of backup and restore operations that have been run. Specifies whether you want to display only the backup history, only the restore history, or all of the history.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE 1-----------------

Copy Code
Get-SPBackupHistory -Directory \\file_server\share\Backup

This example returns all farm backup and restore operations that have been run for the \\file_server\share\Backup directory.

------------------EXAMPLE 2-----------------

Copy Code
Get-SPBackupHistory -Directory C:\Backup -ShowBackup

This example returns all of the farm backup operations that have been run for the C:\Backup directory.

------------------EXAMPLE 3-----------------

Copy Code
(Get-SPBackupHistory -Directory C:\Backup -ShowBackup)[0].SelfId | Restore-SPFarm -Directory C:\Backup -RestoreMethod overwrite

This example gets all of the farm backup operations that have been run for the C:\Backup directory, finds the most recent backup, and then passes its backup GUID to the Restore-SPFarm cmdlet. The Restore-SPFarm cmdlet will then perform an overwrite restore from that backup package.

See Also

Reference

Backup-SPFarm
Backup-SPConfigurationDatabase
Restore-SPFarm


Restore-SPFarm
See Also Example
[image]

Published: May 12, 2010

Restores one or more items from a backup.

Restore-SPFarm -Directory <String> -RestoreMethod <String> [-AssignmentCollection <SPAssignmentCollection>] [-BackupId <Guid>] [-ConfigurationOnly <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-FarmCredentials <PSCredential>] [-Force <SwitchParameter>] [-Item <String>] [-NewDatabaseServer <String>] [-Percentage <Int32>] [-RestoreThreads <Int32>] [-WhatIf [<SwitchParameter>]]
Restore-SPFarm -Directory <String> -ShowTree <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>] [-BackupId <Guid>] [-ConfigurationOnly <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-Item <String>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Directory

Optional

System.String

Specifies the path where SharePoint 2010 Products stored the backup package. If you have a computer on which Microsoft SQL Server 2008 and an instance of SharePoint 2010 Products are installed, you can use local drive paths. This includes a basic installation. However, if SQL Server 2008 and SharePoint 2010 Products are installed on multiple computers, you must use Universal Naming Convention (UNC) share paths so that the SQL Server 2008 and SharePoint 2010 Products can read from the same location (for example, \\computer_name \volume\Backup).

The type must be either of the valid paths:

- C:\folder_name

- \\server_name\folder_name

Note:

The spbr* folders are created automatically.

RestoreMethod

Optional

System.String

Specifies the method of restore to perform.

The valid values are:

- New; Specifies a new location to restore the content and is intended to be used when restoring to a different farm. Additional prompts will be presented to specify the new settings.

- Overwrite; Restores content and settings to their original locations and is intended to be used when restoring to the same farm it was backed up from. If the Overwrite parameter is used, a confirmation prompt is displayed. If you want the confirmation prompt suppressed, use the Force parameter.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

BackupId

Optional

System.Guid

Specifies the GUID of the backup package that is to be restored. Each backup package has a unique GUID associated with it. The GUID can be seen by using the Get-SPBackupHistory cmdlet to view the backup history. If this parameter is not specified, the most recent backup package in the path that is specified with the Directory parameter is used.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890abcdef.

ConfigurationOnly

Optional

System.Management.Automation.SwitchParameter

Specifies settings only (no data) will be restored from the backup package and applied to objects on the destination farm.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

FarmCredentials

Optional

System.Management.Automation.PSCredential

Specifies the credentials that will be used for all components being restored. For example, the application pool credentials for Web applications being restored. If an application pool being restored already exists in the farm, the credentials specified by the FarmCredentials parameter is ignored when restoring that application pool.

Force

Optional

System.Management.Automation.SwitchParameter

Suppresses the prompt warning that you will overwrite components when you perform an overwrite restore operation.

Item

Optional

System.String

Indicates the part of the backup package to be restored. You can use the full farm path notation as displayed by the ShowTree parameter or the name of the target component in the path if it has a unique name. If multiple items match the name, the full path must be provided. Surround the item or path in double quotation marks if it contains a space. If this parameter is absent, the entire backup package is restored.

The type must be a valid item, such as:

Farm\Microsoft SharePoint Foundation Web Application\SharePoint - 80

NewDatabaseServer

Optional

System.String

Specifies a valid SQL Database Server name. If specified, will be used as a default Database Server name for all databases within the restore operation.

This parameter is only valid when restoring as new. It is not valid for overwrite restores.

Percentage

Optional

System.Int32

Requests that progress updates about the restore operation be displayed in increments of that percentage. For example, a value of 5 displays restore progress updates at every 5 percent completed, and a value of 10 displays restore progress updates at every 10 percent completed.

Note: Progress will only be displayed in the output if the -Verbose parameter is specified. Otherwise, you may see the progress in the restore log file.

This percentage is not precise and the actual progress updates might be lower or higher than requested.

For a very large database, 1 is the recommended value.

The type must be an integer value between 1 and 100.

The default value is 5.

RestoreThreads

Optional

System.Int32

The number of threads that should be used during the restore.

The fewer the restore threads, the easier it is to understand the restore log. However, the more restore threads, the more components can be restored in parallel, potentially resulting in a faster restore.

The valid range is between 1 and 10. The default value is 3.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Directory

Optional

System.String

Specifies the path where SharePoint 2010 Products stored the backup package. If you have a computer on which Microsoft SQL Server 2008 and an instance of SharePoint 2010 Products are installed, you can use local drive paths. This includes a basic installation. However, if SQL Server 2008 and SharePoint 2010 Products are installed on multiple computers, you must use Universal Naming Convention (UNC) share paths so that the SQL Server 2008 and SharePoint 2010 Products can read from the same location (for example, \\computer_name \volume\Backup).

The type must be either of the valid paths:

- C:\folder_name

- \\server_name\folder_name

Note:

The spbr* folders are created automatically.

ShowTree

Optional

System.Management.Automation.SwitchParameter

Displays which objects in the farm will be restored based on the other parameters passed to the Restore-SPFarm cmdlet namely the Item and ConfigurationOnly parameters. Items that will be excluded from the restore based on the other parameters passed to the Restore-SPFarm cmdlet will be preceded with an asterisk (*). Items that cannot be restored will be enclosed in square brackets ([ ]). A restore operation will not be performed if the ShowTree parameter is present.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

BackupId

Optional

System.Guid

Specifies the GUID of the backup package that is to be restored. Each backup package has a unique GUID associated with it. The GUID can be seen by using the Get-SPBackupHistory cmdlet to view the backup history. If this parameter is not specified, the most recent backup package in the path that is specified with the Directory parameter is used.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890abcdef.

ConfigurationOnly

Optional

System.Management.Automation.SwitchParameter

Specifies settings only (no data) will be restored from the backup package and applied to objects on the destination farm.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Item

Optional

System.String

Indicates the part of the backup package to be restored. You can use the full farm path notation as displayed by the ShowTree parameter or the name of the target component in the path if it has a unique name. If multiple items match the name, the full path must be provided. Surround the item or path in double quotation marks if it contains a space. If this parameter is absent, the entire backup package is restored.

The type must be a valid item, such as:

Farm\Microsoft SharePoint Foundation Web Application\SharePoint - 80

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Restore-SPFarm cmdlet restores one or more items from a backup such as an individual database, Web application, or the entire farm. This cmdlet can also be used to apply a farm template to the entire farm.

Input Types

Return Types

Example

-------------------EXAMPLE 1-----------------------

Copy Code
Restore-SPFarm -Directory \\file_server\share\Backup -BackupId 12345678-90ab-cdef-1234-567890abcdef -RestoreMethod new -ConfigurationOnly

This example restores the configuration settings from the backup package in the \\file_server\share\Backup directory to the farm.

-------------------EXAMPLE 2-----------------------

Copy Code
Restore-SPFarm -ShowTree -Directory \\file_server\share\Backup -BackupId 12345678-90ab-cdef-1234-567890abcdef -Item "Microsoft SharePoint Foundation Web Application" -Verbose

This example show which components of the farm would be restored under the Microsoft SharePoint Foundation Web Application node, but does not actually restore them.

-------------------EXAMPLE 3-----------------------

Copy Code
Restore-SPFarm -Directory C:\Backup -BackupId 12345678-90ab-cdef-1234-567890abcdef  -RestoreMethod overwrite -RestoreThreads 10 -Force

This example restores a farm by using 10 threads and suppresses the overwrite warning.

See Also

Reference

Backup-SPFarm
Backup-SPConfigurationDatabase
Get-SPBackupHistory


Restore-SPSite
See Also Example
[image]

Published: May 12, 2010

Restores a site collection.

Restore-SPSite [-Identity] <String> -Path <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-ContentDatabase <SPContentDatabasePipeBind>] [-Force <SwitchParameter>] [-GradualDelete <SwitchParameter>] [-HostHeaderWebApplication <String>] [-WhatIf [<SwitchParameter>]]
Restore-SPSite [-Identity] <String> -Path <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DatabaseName <String>] [-DatabaseServer <String>] [-Force <SwitchParameter>] [-GradualDelete <SwitchParameter>] [-HostHeaderWebApplication <String>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

System.String

Specifies the URL location to which the site collection is restored.

A site collection does not have to already exist at the URL location to perform a restore. However, you must specify a valid URL location that a site collection can be created. If a site collection already exists at the specified URL location, you must specify the Force parameter to overwrite it.

The type must be a valid URL, in the form http://server_name/sites/site_name.

Path

Required

System.String

Specifies a valid path to the location of the backup. For example, C:\Backup\site_name.bak.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

ContentDatabase

Optional

Microsoft.SharePoint.PowerShell.SPContentDatabasePipeBind

Specifies the SQL Server content database where the site collection data will be stored. If no content database is specified, the content database with the greatest unused site collection capacity and whose database status is ready will be used.

Force

Optional

System.Management.Automation.SwitchParameter

Specifies that the existing site collection at the URL location is to be overwritten by this restoration.

GradualDelete

Optional

System.Management.Automation.SwitchParameter

Specifies that the site collection being overwritten with the Force parameter should be gradually deleted over time by a timer job instead of all at once, which reduces its impact on SharePoint 2010 Products and SQL Server performance. This option is recommended for large site collections.

HostHeaderWebApplication

Optional

System.String

A valid URL assigned to the Web application by using alternate access mapping, such as http://server_name

Restores a site collection as a host-named site collection instead of a path-based site collection. When the HostHeaderWebApplication parameter is present, the value of the Identity parameter is the URL of the host-named site collection and the value of the HostHeaderWebApplication parameter is the URL of the Web application that will hold the host-named site collection.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

System.String

Specifies the URL location to which the site collection is restored.

A site collection does not have to already exist at the URL location to perform a restore. However, you must specify a valid URL location that a site collection can be created. If a site collection already exists at the specified URL location, you must specify the Force parameter to overwrite it.

The type must be a valid URL, in the form http://server_name/sites/site_name.

Path

Required

System.String

Specifies a valid path to the location of the backup. For example, C:\Backup\site_name.bak.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DatabaseName

Optional

System.String

Specifies the SQL Server content database where the site collection data will be stored. If no content database is specified, the content database with the greatest unused site collection capacity and whose database status is ready will be used.

The type must be a valid database name, in the form SQLDB1.

DatabaseServer

Optional

System.String

Specifies the name of the SQL Server containing the content database specified by the DatabaseName parameter.

The type must be a valid database server name, in the form SQLBE1 and needs to be used in conjunction with the DatabaseName parameter.

Force

Optional

System.Management.Automation.SwitchParameter

Specifies that the existing site collection at the URL location is to be overwritten by this restoration.

GradualDelete

Optional

System.Management.Automation.SwitchParameter

Specifies that the site collection being overwritten with the Force parameter should be gradually deleted over time by a timer job instead of all at once, which reduces its impact on SharePoint 2010 Products and SQL Server performance. This option is recommended for large site collections.

HostHeaderWebApplication

Optional

System.String

A valid URL assigned to the Web application by using alternate access mapping, such as http://server_name

Restores a site collection as a host-named site collection instead of a path-based site collection. When the HostHeaderWebApplication parameter is present, the value of the Identity parameter is the URL of the host-named site collection and the value of the HostHeaderWebApplication parameter is the URL of the Web application that will hold the host-named site collection.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Restore-SPSite cmdlet performs a restoration of the site collection to a location specified by the Identity parameter. A content database may only contain one copy of a site collection. If a site collection is backed up and restored to a different URL location within the same Web application, an additional content database must be available to hold the restored copy of the site collection.

Important:

The SharePoint 2010 Service Pack 1 (SP1) upgrade process alters the schema of all content databases. Because of these changes, you might need to take additional steps to restore a backup that you made before the farm was upgraded to SP1 to the farm after it is upgraded to SP1. For more information about doing this, see Restore pre-SP1 backups to an SP1 farm (SharePoint Server 2010) or Restore pre-SP1 backups to an SP1 farm (SharePoint Foundation 2010).

Return Types

Example

----------------------EXAMPLE 1----------------------

Copy Code
Restore-SPSite http://server_name/sites/site_name -Path C:\Backup\site_name.bak

This example restores a site collection from the backup file C:\Backup\site_name.bak to the site collection URL http://server_name/sites/site_name.

----------------------EXAMPLE 2----------------------

Copy Code
Restore-SPSite http://server_name/sites/site_name -Path C:\Backup\site_name.bak -Force -DatabaseServer SQLBE1 -DatabaseName SQLDB1

This example restores a site collection backup from the backup file C:\Backup\site_name.bak, but overwrites the existing site collection at http://server_name/sites/site_name while specifying that the site collection must be stored in a specific content database.

----------------------EXAMPLE 3----------------------

Copy Code
Restore-SPSite http://www.example.com -Path \\file_server\share\site_name.bak -HostHeaderWebApplication http://server_name

This example restores a site collection backup from the backup file \\file_server\share\site_name.bak to the host-named site collection http://www.example.com on the Web application http://server_name.

See Also

Reference

Backup-SPSite
Get-SPSite
Move-SPSite
New-SPSite
Remove-SPSite
Set-SPSite


Business Connectivity Services cmdlets (SharePoint Foundation 2010)

Published: June 24, 2010

You can use Windows PowerShell cmdlets to administer Business Connectivity Services in a Microsoft SharePoint Foundation 2010 farm.

Cmdlet name | Description
Clear-SPSiteSubscriptionBusinessDataCatalogConfig | Deletes all data from the Business Data Connectivity Metadata Store for a specified partition.
Copy-SPBusinessDataCatalogAclToChildren | Copies a set of permissions of a Business Data Connectivity Metadata Store metadata object to its child objects.
Disable-SPBusinessDataCatalogEntity | Deactivates an external content type in the Business Data Connectivity Metadata Store.
Enable-SPBusinessDataCatalogEntity | Activates an external content type in the Business Data Connectivity Metadata Store.
Export-SPBusinessDataCatalogModel | Exports a Business Data Connectivity Model.
Export-SPSiteSubscriptionBusinessDataCatalogConfig | Exports all data from the Business Data Connectivity Metadata Store associated with a partition.
Get-SPBusinessDataCatalogMetadataObject | Returns a Business Data Connectivity Metadata Store metadata object.
Grant-SPBusinessDataCatalogMetadataObject | Grants a right to a principal for the specified Business Data Connectivity Metadata Store metadata object.
Import-SPBusinessDataCatalogDotNetAssembly | Imports data that is associated with the Business Data Connectivity Metadata Store for a partition.
Import-SPBusinessDataCatalogModel | Imports a Business Data Connectivity Model.
New-SPBusinessDataCatalogServiceApplication | Creates a new Business Data Connectivity service application in the farm.
New-SPBusinessDataCatalogServiceApplicationProxy | Creates a new Business Data Connectivity service application proxy in the farm.
Remove-SPBusinessDataCatalogModel | Deletes a Business Data Connectivity Model.
Revoke-SPBusinessDataCatalogMetadataObject | Revokes a right to a principal in the specified Business Data Connectivity Metadata Store metadata object.
Set-SPBusinessDataCatalogMetadataObject | Sets the value of a property or attribute of a Business Data Connectivity Metadata Store metadata object.
Set-SPBusinessDataCatalogServiceApplication | Sets global properties for a Business Data Connectivity service application in the farm.
Import-SPSiteSubscriptionBusinessDataCatalogConfig | Imports data associated with an exported file that contains all data associated with the Business Data Connectivity Metadata Store for a given partition.
Remove-SPSiteSubscriptionBusinessDataCatalogConfig | Removes the Business Data Connectivity Metadata Store for a partition.


Clear-SPSiteSubscriptionBusinessDataCatalogConfig
See Also Example
[image]

Published: May 12, 2010

Deletes all data from the Business Data Connectivity Metadata Store for a specified partition.

Clear-SPSiteSubscriptionBusinessDataCatalogConfig -ServiceContext <SPServiceContextPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

ServiceContext

Required

Microsoft.SharePoint.PowerShell.SPServiceContextPipeBind

Specifies the service context for which the Business Data Connectivity models are deleted.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Clear-SPSiteSubscriptionBusinessDataCatalogConfig cmdlet deletes all models and data from the Business Data Connectivity Metadata Store for a specified service partition.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Clear-SPSiteSubscriptionBusinessDataCatalogConfig -ServiceContext http://contoso

This example deletes all data from the Business Data Connectivity Metadata Store for the specified site.

See Also

Reference

Export-SPSiteSubscriptionBusinessDataCatalogConfig
Import-SPSiteSubscriptionBusinessDataCatalogConfig


Copy-SPBusinessDataCatalogAclToChildren
See Also Example
[image]

Published: May 12, 2010

Copies a set of permissions of a Business Data Connectivity Metadata Store metadata object to its child objects.

Copy-SPBusinessDataCatalogAclToChildren -MetadataObject <MetadataObject> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

MetadataObject

Required

Microsoft.SharePoint.BusinessData.Administration.MetadataObject

Specifies the Business Data Connectivity metadata object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Copy-SPBusinessDataCatalogAclToChildren cmdlet copies a set of rights of a Business Data Connectivity metadata object to its child objects.

Any principals and their rights will be lost from the child metadata objects. Make sure that the parent metadata object has the final permissions you want, or make sure to append them to the child object again after you run this cmdlet.

Running this cmdlet on a BdcObjectType BdcCatalog (Business Data Connectivity Metadata Store) will propagate to:

- BDC Models

- External Systems

- External Content Types

- Methods

- Method Instances

Running this cmdlet on a BdcObjectType Model (Business Data Connectivity Model) will propagate to:

- Nothing; this type has no child metadata objects

Running this cmdlet on a BdcObjectType LobSystem (External System) will propagate to:

- External Content Types

- Methods

- Method Instances

Running this cmdlet on a BdcObjectType Entity (External Content Type) will propagate to:

- Methods

- Method Instances

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
$ExternalSystem = Get-SPBusinessDataCatalogMetadataObject -BdcObjectType "LobSystem" -ServiceContext http://contoso -Name "ContosoDatabase"

This example looks at the principals (users) and their corresponding rights given for the External System metadata object, and overwrites the permissions of its child metadata objects with these same principals and rights.

Any principals and their rights will be lost from the child metadata objects. Make sure that the parent metadata object has the final permissions you want, or make sure to append them to the child object again after you run this cmdlet.

See Also

Reference

Get-SPBusinessDataCatalogMetadataObject
Grant-SPBusinessDataCatalogMetadataObject


Disable-SPBusinessDataCatalogEntity
See Also Example
[image]

Published: May 12, 2010

Deactivates an External Content type in the Business Data Connectivity Metadata Store.

Disable-SPBusinessDataCatalogEntity -Identity <Entity> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.BusinessData.Administration.Entity

Specifies the External Content type in the Business Data Connectivity Metadata Store to deactivate.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Disable-SPBusinessDataCatalogEntity cmdlet deactivates an External Content type in the Business Data Connectivity Metadata Store.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
$entityToDisable = Get-SPBusinessDataCatalogMetadataObject -Namespace "Contoso" -Name "Customer" -BdcObjectType "Entity" -ServiceContext http://contoso
Copy Code
Disable-SPBusinessDataCatalogEntity -Identity $entityToDisable

This example deactivates the External Content type of the name Customer in the Contoso. Note that the terms External Content type and Entity refer to the same object type, and the term Disable refers to the same action as the Business Data Connectivity term Deactivate.

See Also

Reference

Enable-SPBusinessDataCatalogEntity


Enable-SPBusinessDataCatalogEntity
See Also Example
[image]

Published: May 12, 2010

Activates an External Content type in the Business Data Connectivity Metadata Store.

Enable-SPBusinessDataCatalogEntity -Identity <Entity> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.BusinessData.Administration.Entity

Specifies the External Content type in the Business Data Connectivity Metadata Store to activate.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Enable-SPBusinessDataCatalogEntity cmdlet activates an External Content type in the Business Data Connectivity Metadata Store.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
$entityToEnable = Get-SPBusinessDataCatalogMetadataObject -Namespace "Contoso" -Name "Customer" -BdcObjectType "Entity" -ServiceContext http://contoso
Copy Code
Enable-SPBusinessDataCatalogEntity -Identity $entityToEnable

This example activates the External Content type with the name Customer in the Contoso namespace on the site http://contoso. Note that the terms External Content type and Entity refer to the same object type.

See Also

Reference

Disable-SPBusinessDataCatalogEntity


Export-SPBusinessDataCatalogModel
See Also Example
[image]

Published: May 12, 2010

Exports a Business Data Connectivity Model.

Export-SPBusinessDataCatalogModel -Identity <MetadataObject> -Path <String> [-AssignmentCollection <SPAssignmentCollection>] [-Force <SwitchParameter>] [-LocalizedNamesIncluded <SwitchParameter>] [-ModelsIncluded <SwitchParameter>] [-PermissionsIncluded <SwitchParameter>] [-PropertiesIncluded <SwitchParameter>] [-ProxiesIncluded <SwitchParameter>] [-SettingId <String>]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.BusinessData.Administration.MetadataObject

Specifies the Business Data Connectivity Metadata Store metadata object from which to export the Business Data Connectivity Model.

Path

Required

System.String

Specifies the path and name to use to create the export file.

The type must be a valid path in either of the following forms:

- C:\folder_name \file.bdcm

- \\server_name\folder_name \file.bdcm

- …\folder_name\file.bdcm

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Force

Optional

System.Management.Automation.SwitchParameter

Overwrites the output file if the file exists.

LocalizedNamesIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that names for business data fields in multiple languages are exported.

ModelsIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that models are included in the exported Business Data Connectivity Model file. A model contains the base XML metadata for a system.

PermissionsIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that permissions from the Business Data Connectivity Model are exported.

PropertiesIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that properties from the application definition are exported.

ProxiesIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that proxies for Business Data Connectivity Service applications are exported.

SettingId

Optional

System.String

Specifies the custom environment settings model slice to export.

The type must be a valid string that identifies a model slice; for example, ModelSlice1.

Detailed Description

The Export-SPBusinessDataCatalogModel cmdlet exports a Business Data Connectivity Model. There are two types of Business Data Connectivity models: Model type (.bdcm) and Resource type (.bdcr). The Model type contains the base XML metadata, and can also include resource properties. The Resource type includes only resource properties.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
$Model = Get-SPBusinessDataCatalogMetadataObject -BdcObjectType "Model" -Name "ContosoModel" -ServiceContext http://contoso
Copy Code
Export-SPBusinessDataCatalogModel -Identity $Model -Path "C:\folder\model.bdcm"

This example gets a Business Data Connectivity Model from the Business Data Connectivity Metadata Store and exports it to the location specified with the name model and using the bdcm file extension.

See Also

Reference

Import-SPBusinessDataCatalogModel
Remove-SPBusinessDataCatalogModel


Export-SPSiteSubscriptionBusinessDataCatalogConfig
See Also Example
[image]

Published: May 12, 2010

Exports all data from the Business Data Connectivity Metadata Store associated with a partition.

Export-SPSiteSubscriptionBusinessDataCatalogConfig -Path <String> -ServiceContext <SPServiceContextPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-LocalizedNamesIncluded <SwitchParameter>] [-ModelsIncluded <SwitchParameter>] [-PermissionsIncluded <SwitchParameter>] [-PropertiesIncluded <SwitchParameter>] [-ProxiesIncluded <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Path

Required

System.String

Specifies the path and name to use to create the export file.

The type must be a valid path in either of the following forms:

- C:\folder_name\file.xml

- \\server_name\folder_name\file.xml

- …\folder_name\file.xml

ServiceContext

Required

Microsoft.SharePoint.PowerShell.SPServiceContextPipeBind

Specifies the service context of the data to be exported.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a service context (for example, http://ServiceContext1); or an instance of a valid SPServiceContext object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Overwrites the output file if the file exists.

LocalizedNamesIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that names for business data fields in multiple languages are exported.

ModelsIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that Business Data Connectivity models are included in the exported file.

PermissionsIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that permissions from the Business Data Connectivity Models are exported.

PropertiesIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that properties from the Business Data Connectivity Models are exported.

ProxiesIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that proxies for Business Data Connectivity Service applications are exported.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The SPSiteSubscriptionBusinessDataCatalogConfig cmdlet exports all data from the Business Data Connectivity Metadata Store associated with a specified partition.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Export-SPSiteSubscriptionBusinessDataCatalogConfig -ServiceContext http://contoso -Path "C:\folder\exportedFile.xml"

This example exports the data file named exportedFile.xml.

See Also

Reference

Import-SPSiteSubscriptionBusinessDataCatalogConfig
Clear-SPSiteSubscriptionBusinessDataCatalogConfig


Get-SPBusinessDataCatalogMetadataObject
See Also Example
[image]

Published: May 12, 2010

Returns a Business Data Connectivity Metadata Store metadata object.

Get-SPBusinessDataCatalogMetadataObject -BdcObjectType <Catalog | Model | LobSystem | LobSystemInstance | Entity> -ServiceContext <SPServiceContextPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-ContainingLobSystem <String>] [-Name <String>] [-Namespace <String>]

Parameters

Parameter Required Type Description

BdcObjectType

Required

Microsoft.SharePoint.BusinessData.SharedService.SPGetSPBusinessDataCatalogMetadataObjectCmdlet+PSBdcObjectType

Specifies the type of the metadata object to return.

The type must be one of the following valid metadata object types: BdcCatalog, Model, LobSystem, LobSystemInstance, or Entity.

ServiceContext

Required

Microsoft.SharePoint.PowerShell.SPServiceContextPipeBind

Specifies the service context of the Business Data Connectivity Metadata Store metadata object to return.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Name

Optional

System.String

Specifies the name of the metadata object.

Namespace

Optional

System.String

Specifies the namespace of the metadata object.

Detailed Description

The Get-SPBusinessDataCatalogMetadataObject cmdlet reads a Business Data Connectivity Metadata Store metadata object from a Business Data Connectivity Service application. Output for this cmdlet can be a series of objects.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
$Model = Get-SPBusinessDataCatalogMetadataObject -BdcObjectType "Model" -Name "ContosoModel" -ServiceContext http://contoso

This example gets a metadata object of type Model with the name ContosoModel from the Business Data Connectivity Metadata Store on the given site.

See Also

Reference

Set-SPBusinessDataCatalogMetadataObject
Grant-SPBusinessDataCatalogMetadataObject
Revoke-SPBusinessDataCatalogMetadataObject


Grant-SPBusinessDataCatalogMetadataObject
See Also Example
[image]

Published: May 12, 2010

Grants a right to a principal for the specified Business Data Connectivity Metadata Store metadata object.

Grant-SPBusinessDataCatalogMetadataObject -Identity <MetadataObject> -Principal <SPClaim> -Right <Execute | Edit | SetPermissions | SelectableInClients> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-SettingId <String>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.BusinessData.Administration.MetadataObject

Specifies the Business Data Connectivity Metadata Store metadata object that contains the principal.

Principal

Required

System.String

Specifies the principal to whom the rights apply.

The type must be a claim.

Right

Required

Microsoft.SharePoint.BusinessData.SharedService.SPGrantSPBusinessDataCatalogMetadataObjectCmdlet+PSBdcRight

Specifies the right to grant the principal.

The type must be one of the following valid PSBdcRight object types: All, Execute, Edit, SetPermissions, or SelectableInClients.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

SettingId

Optional

System.String

Specifies the model slice for which to grant the right.

The type must be a valid string that identifies a model slice; for example, ModelSlice1.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Grant-SPBusinessDataCatalogMetadataObject cmdlet grants the right to a specified principal (user) for a Business Data Connectivity Metadata Store metadata object. This cmdlet checks to verify that the Identity parameter is a valid IndividuallySecurableMetadata object.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
$claimJohn = New-SPClaimsPrincipal -Identity "CONTOSO\johndoe" -IdentityType WindowsSamAccountName
Copy Code
$Model = Get-SPBusinessDataCatalogMetadataObject -BdcObjectType "Model" -ServiceContext http://contoso -Name "ContosoModel"
Copy Code
Grant-SPBusinessDataCatalogMetadataObject -Identity $Model -Principal $claimJohn -Right Edit

This example gives Edit permissions to the user with the identity johndoe on domain CONTOSO, for the model metadata object with the name ContosoModel.

See Also

Reference

Set-SPBusinessDataCatalogMetadataObject
Get-SPBusinessDataCatalogMetadataObject
Revoke-SPBusinessDataCatalogMetadataObject


Import-SPBusinessDataCatalogDotNetAssembly
Example
[image]

Published: May 12, 2010

Imports a .NET Connectivity assembly.

Import-SPBusinessDataCatalogDotNetAssembly -LobSystem <LobSystem> -Path <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DependentAssemblyPaths <String[]>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

LobSystem

Required

Microsoft.SharePoint.BusinessData.Administration.LobSystem

Specifies the LobSystem that the assembly corresponds to.

Path

Required

System.String

Specifies the path to the primary assembly.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DependentAssemblyPaths

Optional

System.String[]

Specifies a list of paths to dependent assemblies.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Import-SPBusinessDataCatalogDotNetAssembly cmdlet imports a .NET Connectivity Assembly that corresponds to a .NET Assembly Connector and LobSystem in the metadata store.

Input Types

Return Types

Example

-----------------EXAMPLE 1----------------

Copy Code
Import-SPBusinessDataCatalogDotNetAssembly -LobSystem $ContosoDB -Path "c:\Folder\Assembly.dll"

This example imports the assembly Assembly.

-----------------EXAMPLE 2----------------

Copy Code
Import-SPBusinessDataCatalogDotNetAssembly -LobSystem $ContosoDB -Path "c:\Folder\Assembly.dll" -DependentAssemblyPaths "c:\Folder\Assembly2.dll","c:\Folder\Assembly3.dll"

This example imports the assembly Assembly, and also imports the dependent assemblies Assembly2 and Assembly3.


Import-SPBusinessDataCatalogModel
See Also Example
[image]

Published: May 12, 2010

Imports a Business Data Connectivity Model.

Import-SPBusinessDataCatalogModel -Identity <MetadataObject> -Path <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-LocalizedNamesIncluded <SwitchParameter>] [-ModelsIncluded <SwitchParameter>] [-PermissionsIncluded <SwitchParameter>] [-PropertiesIncluded <SwitchParameter>] [-SettingId <String>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.BusinessData.Administration.MetadataObject

Specifies the Business Data Connectivity Metadata Store metadata object to import to.

Path

Required

System.String

Specifies the path and name to use.

The type must be a valid path in either of the following forms:

- C:\folder_name\file.bdcm

- \\server_name\folder_name\file.bdcm

- …\folder_name\file.bdcm

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Overwrites the Business Data Connectivity Model if the file exists.

LocalizedNamesIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that names for business data fields in multiple languages are imported.

ModelsIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that models are included in the imported Business Data Connectivity Model file. A model contains the base XML metadata for a system.

PermissionsIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that permissions from the Business Data Connectivity Model are imported.

PropertiesIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that properties from the Business Data Connectivity Model are imported.

SettingId

Optional

System.String

Specifies the custom environment settings model slice to import.

The type must be a valid string that identifies a model slice; for example, ModelSlice1.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Import-SPBusinessDataCatalogModel cmdlet imports a Business Data Connectivity Model. There are two types of Business Data Connectivity models: Model type (.bdcm) and Resource type (.bdcr). The Model type contains the base XML metadata, and can also include resource properties. The Resource type includes only resource properties.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
$MetadataStore = Get-SPBusinessDataCatalogMetadataObject -BdcObjectType "Catalog" -ServiceContext http://contoso
Copy Code
Import-SPBusinessDataCatalogModel -Path "C:\folder\model.bdcm" -Identity $MetadataStore

This example gets the Business Data Connectivity Metadata Store and then imports a Business Data Connectivity Model of Model type to it from the path specified with the name model.

See Also

Reference

Export-SPBusinessDataCatalogModel
Remove-SPBusinessDataCatalogModel


New-SPBusinessDataCatalogServiceApplication
See Also Example
[image]

Published: May 12, 2010

Creates a new Business Data Connectivity service application in the farm.

New-SPBusinessDataCatalogServiceApplication -ApplicationPool <SPIisWebServiceApplicationPoolPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DatabaseCredentials <PSCredential>] [-DatabaseName <String>] [-DatabasePassword <SecureString>] [-DatabaseServer <String>] [-DatabaseUsername <String>] [-FailoverDatabaseServer <String>] [-Name <String>] [-PartitionMode <SwitchParameter>] [-Sharing <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

ApplicationPool

Required

Microsoft.SharePoint.PowerShell.SPIisWebServiceApplicationPoolPipeBind

Specifies the IIS application pool to use for the new Business Data Connectivity service application.

DatabaseName

Required

System.String

Specifies the name for the Business Data Connectivity database.

DatabaseServer

Required

System.String

Specifies the name of the host server for the database specified in DatabaseName.

The type must be a valid SQL Server host name; for example, SERVER\Database.

Name

Required

System.String

Specifies a display name for the new Business Data Connectivity service application.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DatabaseCredentials

Optional

System.Management.Automation.PSCredential

Specifies the PSCredential object that contains the user name and password to be used for database SQL Server Authentication.

The type must be a valid PSCredential object.

DatabasePassword

Optional

System.Security.SecureString

Specifies the password for the user specified in DatabaseUserName. Use this parameter only if SQL Server Authentication is used to access the Business Data Connectivity database.

The type must be a valid password.

DatabaseUsername

Optional

System.String

Specifies the user name to use for connecting to the database. Use this parameter only if SQL Server Authentication is used to access the Business Data Connectivity database.

FailoverDatabaseServer

Optional

System.String

Specifies the name of the host server for the failover database server.

PartitionMode

Required

System.Management.Automation.SwitchParameter

Specifies that the service application restricts data by subscription ID. This property cannot be changed after the service application is created.

Sharing

Required

System.Management.Automation.SwitchParameter

Specifies that the Business Data Connectivity application is published and shared across the farm.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The New-SPBusinessDataCatalogServiceApplication cmdlet creates a new Business Data Connectivity service application in the farm.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE------------------

Copy Code
New-SPBusinessDataCatalogServiceApplication -ApplicationPool "SharePoint Web Services Default" -DatabaseName "ContosoBdcDB" -DatabaseServer "CONTOSO\SharePoint" -Name "ContosoServiceApp"

This example creates a Business Data Connectivity service application named ContosoServiceApp. In this process it uses the SharePoint Web Services Default application pool and creates a database named ContosoBdcDB.

See Also

Reference

Set-SPBusinessDataCatalogServiceApplication
New-SPBusinessDataCatalogServiceApplicationProxy


New-SPBusinessDataCatalogServiceApplicationProxy
See Also Example
[image]

Published: May 12, 2010

Creates a new Business Data Connectivity service application proxy in the farm.

New-SPBusinessDataCatalogServiceApplicationProxy -Uri <Uri> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DefaultProxyGroup <SwitchParameter>] [-Name <String>] [-PartitionMode <SwitchParameter>] [-WhatIf [<SwitchParameter>]]
New-SPBusinessDataCatalogServiceApplicationProxy -ServiceApplication <SPServiceApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DefaultProxyGroup <SwitchParameter>] [-Name <String>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Name

Required

System.String

Specifies a display name for the new Business Data Connectivity service application proxy.

Uri

Required

System.Uri

Specifies the URI of a remote service application to which to connect.

The type must be a valid URI, in the form file:\\server_name\sitedocs.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DefaultProxyGroup

Required

System.Management.Automation.SwitchParameter

Specifies that the service application proxy is added to the default proxy group for the farm.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Name

Required

System.String

Specifies a display name for the new Business Data Connectivity service application proxy.

ServiceApplication

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationPipeBind

Specifies the Business Data Connectivity service application associated with the new proxy.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DefaultProxyGroup

Required

System.Management.Automation.SwitchParameter

Specifies that the service application proxy is added to the default proxy group for the farm.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The New-SPBusinessDataCatalogServiceApplicationProxy cmdlet creates a new Business Data Connectivity service application proxy for a Business Data Connectivity service application in the farm.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE------------------

Copy Code
New-SPBusinessDataCatalogServiceApplicationProxy -Name "ContosoServiceAppProxy" -ServiceApplication $serviceApplication

This example creates a new Business Data Connectivity service application proxy with the name ContosoServiceAppProxy for the given service application.

See Also

Reference

New-SPBusinessDataCatalogServiceApplication
Set-SPBusinessDataCatalogServiceApplication


Remove-SPBusinessDataCatalogModel
See Also Example
[image]

Published: May 12, 2010

Deletes a Business Data Connectivity Model.

Remove-SPBusinessDataCatalogModel -Identity <MetadataObject> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.BusinessData.Administration.MetadataObject

Specifies the Business Data Connectivity Metadata Store metadata object to remove.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPBusinessDataCatalogModel cmdlet deletes a Business Data Connectivity Model.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
$modelFile = Get-SPBusinessDataCatalogMetadataObject -Name "ContosoModel" -BdcObjectType Model -ServiceContext http://contoso
Copy Code
Remove-SPBusinessDataCatalogModel -Identity $modelFile

This example removes the Business Data Connectivity Model file named ContosoModel.

See Also

Reference

Import-SPBusinessDataCatalogModel
Export-SPBusinessDataCatalogModel


Revoke-SPBusinessDataCatalogMetadataObject
See Also Example
[image]

Published: May 12, 2010

Revokes a right to a principal in the specified Business Data Connectivity Metadata Store metadata object.

Revoke-SPBusinessDataCatalogMetadataObject -Identity <MetadataObject> -Principal <SPClaim> -Right <Execute | Edit | SetPermissions | SelectableInClients> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-SettingId <String>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.BusinessData.Administration.MetadataObject

Specifies the Business Data Connectivity Metadata Store metadata object that contains the principal.

Principal

Required

System.String

Specifies the principal to whom the rights apply.

The type must be a claim.

Right

Required

Microsoft.SharePoint.BusinessData.SharedService.SPGrantSPBusinessDataCatalogMetadataObjectCmdlet+PSBdcRight

Specifies the right to revoke the principal.

The type must be one of the following valid PSBdcRight object types: All, Execute, Edit, SetPermissions, or SelectableInClients.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

SettingId

Optional

System.String

Specifies the custom environment settings model slice for which to revoke the right.

The type must be a valid string that identifies a model slice; for example, ModelSlice1.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Revoke-SPBusinessDataCatalogMetadataObject cmdlet revokes a right granted to a principal user in the specified Business Data Connectivity Metadata Store metadata object.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
$claimJohn = New-SPClaimsPrincipal -Identity "CONTOSO\johndoe" -IdentityType WindowsSamAccountName
Copy Code
$MetadataObject = Get-SPBusinessDataCatalogMetadataObject -BdcObjectType "LobSystem" -ServiceContext http://contoso -Name "ContosoDatabase"
Copy Code
Revoke-SPBusinessDataCatalogMetadataObject -Identity $MetadataObject -Principal $claimJohn -Right "Execute"

This example removes the execute right from the External System with the name ContosoDatabase for the user with the identity of johndoe on the domain CONTOSO.

See Also

Reference

Set-SPBusinessDataCatalogMetadataObject
Get-SPBusinessDataCatalogMetadataObject
Grant-SPBusinessDataCatalogMetadataObject


Set-SPBusinessDataCatalogMetadataObject
See Also Example
[image]

Published: May 12, 2010

Sets the value of a property or attribute of a Business Data Connectivity Metadata Store metadata object.

Set-SPBusinessDataCatalogMetadataObject -Identity <MetadataObject> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-PropertyName <String>] [-PropertyValue <PSObject>] [-Remove <SwitchParameter>] [-SettingId <String>] [-WhatIf [<SwitchParameter>]]

Set-SPBusinessDataCatalogMetadataObject -Identity <MetadataObject> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DisplayName <String>] [-Remove <SwitchParameter>] [-SettingId <String>] [-WhatIf [<SwitchParameter>]]

Set-SPBusinessDataCatalogMetadataObject -Identity <MetadataObject> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-PropertyName <String>] [-Remove <SwitchParameter>] [-Remove <SwitchParameter>] [-SettingId <String>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.BusinessData.Administration.MetadataObject

Specifies the Business Data Connectivity Metadata Store metadata object to update.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

PropertyName

Optional

System.String

Specifies the name of the property to update.

PropertyValue

Optional

System.Management.Automation.PSObject

Sets the new value of the property specified in the PropertyName parameter.

Remove

Optional

System.Management.Automation.SwitchParameter

Removes the property specified in the PropertyName parameter.

SettingId

Optional

System.String

Specifies the custom environment settings model slice for which the property applies.

The type must be a valid string that identifies a model slice; for example, ModelSlice1.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.BusinessData.Administration.MetadataObject

Specifies the Business Data Connectivity Metadata Store metadata object to update.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DisplayName

Optional

System.String

Specifies the display name of the Business Data Connectivity Metadata Store metadata object.

Remove

Optional

System.Management.Automation.SwitchParameter

Removes the property specified in the PropertyName parameter.

SettingId

Optional

System.String

Specifies the custom environment settings model slice for which the property applies.

The type must be a valid string that identifies a model slice; for example, ModelSlice1.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

3

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.BusinessData.Administration.MetadataObject

Specifies the Business Data Connectivity Metadata Store metadata object to update.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

PropertyName

Optional

System.String

Specifies the name of the property to update.

Remove

Optional

System.Management.Automation.SwitchParameter

Removes the property specified in the PropertyName parameter.

SettingId

Optional

System.String

Specifies the custom environment settings model slice for which the property applies.

The type must be a valid string that identifies a model slice; for example, ModelSlice1.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Set-SPBusinessDataCatalogMetadataObject cmdlet sets the value of a property or attribute of a Business Data Connectivity Metadata Store metadata object.

Input Types

Return Types

Example

------------------EXAMPLE 1------------------

Copy Code
$objectToSetOn = Get-SPBusinessDataCatalogMetadataObject -Namespace "ContosoDatabase" -Name "ContosoDatabase" -BdcObjectType "LobSystemInstance" -ServiceContext http://contoso
Copy Code
Set-SPBusinessDataCatalogMetadataObject -Identity $objectToSetOn -PropertyName "ShowInSearchUI" -PropertyValue "True"

This example creates a property on the LobSystemInstance (External System Instance) of name ContosoDatabase. The property has the name ShowInSearchUI and a value of True.

See Also

Reference

Get-SPBusinessDataCatalogMetadataObject
Revoke-SPBusinessDataCatalogMetadataObject
Grant-SPBusinessDataCatalogMetadataObject


Set-SPBusinessDataCatalogServiceApplication
See Also Example
[image]

Published: May 12, 2010

Sets global properties for a Business Data Connectivity service application in the farm.

Set-SPBusinessDataCatalogServiceApplication -Identity <SPServiceApplicationPipeBind> [-ApplicationPool <SPIisWebServiceApplicationPool>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DatabaseCredentials <PSCredential>] [-DatabaseName <String>] [-DatabasePassword <SecureString>] [-DatabaseServer <String>] [-DatabaseUsername <String>] [-FailoverDatabaseServer <String>] [-Name <String>] [-Sharing <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

ApplicationPool

Optional

Microsoft.SharePoint.Administration.SPIisWebServiceApplicationPool

Specifies the IIS application pool to use for the new Business Data Connectivity service application.

DatabaseCredentials

Optional

System.Management.Automation.PSCredential

Specifies the PSCredential object that contains the user name and password to be used for database SQL Server Authentication.

The type must be a valid PSCredential object.

DatabaseName

Optional

System.String

Specifies the name of the Business Data Connectivity database.

The type must be a valid name of a SQL Server database; for example, UsageLogDB1.

DatabasePassword

Optional

System.Security.SecureString

Specifies the password for the user specified in DatabaseUserName. Use this parameter only if SQL Server Authentication is used to access the Business Data Connectivity database.

The type must be a valid password.

DatabaseServer

Optional

System.String

Specifies the name of the Business Data Connectivity database.

The type must be a valid name of a SQL Server database; for example, UsageLogDB1.

DatabaseUsername

Optional

System.String

Specifies the user name to use for connecting to the catalog database. Use this parameter only if SQL Server Authentication is used to access the Business Data Connectivity database.

The type must be a valid user name; for example, UserName1.

FailoverDatabaseServer

Optional

System.String

Specifies the name of the host server for the failover database server.

The type must be a valid SQL Server host name; for example, SQLServerHost1.

Identity

Optional

Microsoft.SharePoint.PowerShell.SPServiceApplicationPipeBind

Specifies the Business Data Connectivity service application associated with the new proxy.

Name

Optional

System.String

Specifies a display name for the new Business Data Connectivity service application proxy.

Sharing

Optional

System.Management.Automation.SwitchParameter

Specifies that the Business Data Connectivity service application is published and shared across the farm.

AssignmentColletion

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Set-SPBusinessDataCatalogServiceApplication cmdlet sets global properties for a Business Data Connectivity service application in the farm.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE------------------

Copy Code
Set-SPBusinessDataCatalogServiceApplication -Identity $serviceApplication -FailoverDatabaseServer "CONTOSO\Backup"

This example sets the failover database server to CONTOSO\Backup for the given service application.

See Also

Reference

New-SPBusinessDataCatalogServiceApplication
New-SPBusinessDataCatalogServiceApplicationProxy


Import-SPSiteSubscriptionBusinessDataCatalogConfig
See Also Example
[image]

Published: May 12, 2010

Imports data associated with an exported file that contains all data associated with the Business Data Connectivity Metadata Store for a given partition.

Import-SPSiteSubscriptionBusinessDataCatalogConfig -Path <String> -ServiceContext <SPServiceContextPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-LocalizedNamesIncluded <SwitchParameter>] [-ModelsIncluded <SwitchParameter>] [-PermissionsIncluded <SwitchParameter>] [-PropertiesIncluded <SwitchParameter>] [-ProxiesIncluded <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Path

Required

System.String

Specifies the path and name to use to create the export file.The type must be a valid path in either of the following forms:

C:\folder_name

\\server_name\folder_name

..\folder_name\file.xml

ServiceContext

Required

Microsoft.SharePoint.PowerShell.SPServiceContextPipeBind

Specifies the service context of the data to be exported.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a service context (for example, http://ServiceContext1); or an instance of a valid SPServiceContext object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

LocalizedNamesIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that names for business data fields in multiple languages be imported.

ModelsIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that Business Data Connectivity models be included in the imported file.

PermissionsIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that permissions from the Business Data Connectivity model be exported.

PropertiesIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that properties from the Business Data Connectivity model be imported.

ProxiesIncluded

Optional

System.Management.Automation.SwitchParameter

Specifies that proxies for Business Data Connectivity Service Applications be exported.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

Use the Import-SPSiteSubscriptionBusinessDataCatalogConfig cmdlet to import a data file that contains Business Data Connecitivity models and all data associated with the Business Data Connectivity Metadata Store for a given partition.

Input Types

Return Types

Example

---------------------EXAMPLE---------------------------

Copy Code
Import-SPSiteSubscriptionBusinessDataCatalogConfig -Path "C:\folder\importFile.xml" -ServiceContext http://contoso

This example imports the data file named importFile.xml.

See Also

Reference

Clear-SPSiteSubscriptionBusinessDataCatalogConfig
Export-SPSiteSubscriptionBusinessDataCatalogConfig
Remove-SPSiteSubscriptionBusinessDataCatalogConfig


Remove-SPSiteSubscriptionBusinessDataCatalogConfig
See Also Example
[image]

Published: May 12, 2010

Removes the Business Data Connectivity Metadata Store for a partition.

Remove-SPSiteSubscriptionBusinessDataCatalogConfig -ServiceContext <SPServiceContextPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

ServiceContext

Required

Microsoft.SharePoint.PowerShell.SPServiceContextPipeBind

Specifies the service context of the Business Data Connectivity Metadata Store to remove.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a service context (for example, http://ServiceContext1); or an instance of a valid SPServiceContext object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPSiteSubscriptionBusinessDataCatalogConfig cmdlet removes the Business Data Connectivity Metadata Store and all associated data for a specified partition. To completely remove a partition and the data that it contains, run the Clear-SPSiteSubscriptionBusinessDataCatalogConfig cmdlet to remove the data from the Business Data Connectivity Metadata Store, and then run the Remove-SPSiteSubscriptionBusinessDataCatalogConfig cmdlet.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Remove-SPSiteSubscriptionBusinessDataCatalogConfig -ServiceContext http://contoso

This example removes the Business Data Connectivity Metadata Store for the partition http://contoso.

See Also

Reference

Export-SPSiteSubscriptionBusinessDataCatalogConfig
Import-SPSiteSubscriptionBusinessDataCatalogConfig


Database cmdlets (SharePoint Foundation 2010)
See Also

You can use Windows PowerShell cmdlets to manage databases in a Microsoft SharePoint Foundation 2010 farm.

Cmdlet name | Description
Connect-SPConfigurationDatabase | Connects the local server computer to a farm.
Disconnect-SPConfigurationDatabase | Disconnects the local server computer from the farm.
Move-SPBlobStorageLocation | Copies a Windows SharePoint Services 3.0 database by using Remote BLOB Storage (RBS).
New-SPConfigurationDatabase | Creates a new configuration database.
Remove-SPConfigurationDatabase | Permanently removes a configuration database.
Dismount-SPContentDatabase | Detaches a content database from the Web application it is currently associated with.
Get-SPContentDatabase | Returns one or more content databases.
Mount-SPContentDatabase | Attaches an existing content database to the farm.
New-SPContentDatabase | Creates a new content database and attaches it to the specified Web application.
Remove-SPContentDatabase | Deletes a content database.
Set-SPContentDatabase | Sets global properties of a SharePoint content database.
Test-SPContentDatabase | Tests a content database.
Get-SPDatabase | Retrieves all properties of a database.

See Also

Other Resources

Resource Center: Windows PowerShell for SharePoint Foundation 2010


Connect-SPConfigurationDatabase
See Also Example
[image]

Published: May 12, 2010

Connects the local server computer to a farm.

Connect-SPConfigurationDatabase [-DatabaseName] <String> [-Passphrase] <SecureString> -DatabaseServer <String> [-AssignmentCollection <SPAssignmentCollection>] [-DatabaseCredentials <PSCredential>]

Parameters

Parameter Required Type Description

DatabaseName

Required

System.String

Specifies the name of the configuration database to which to connect the server.

The type must be a valid database name; for example, DB1.

DatabaseServer

Required

A valid database server, such as "DS"

Specifies the server on which to create the configuration database. The default value is the local computer name.

Passphrase

Required

System.Security.SecureString

Specifies the secure password phrase for connecting the current server to the configuration database.

The type must be a valid secure string; for example, MyBDCApp1serverkey.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

DatabaseCredentials

Optional

System.Management.Automation.PSCredential

Specifies the PSCredential object that contains the user name and password to be used for database SQL authentication. If this parameter is not specified, the current user is used.

The type must be a valid PSCredential object.

Detailed Description

The Connect-SPConfigurationDatabase cmdlet connects the current server to the specified configuration database.

Essentially, this cmdlet connects the server to the farm. If the current computer cannot be connected to a farm, the following error message is displayed:

"This machine is already connected to a SharePoint farm. See: Dismount-SPConfigurationDatabase"

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Connect-SPConfigurationDatabase -DatabaseServer "ServerName\InstanceName" -DatabaseName "SharePointConfigurationDatabaseName" -Passphrase (ConvertTo-SecureString "MyP@ssw0rd" -AsPlainText -Force
Copy Code
Start-Service SPTimerv4

This example joins the local server computer to a farm that is configured to use the database SharePointConfigurationDatabase on an instance of SQL Server by using the name ServerName\InstanceName with the passphrase MyP@ssw0rd.

See Also

Reference

Backup-SPConfigurationDatabase
Disconnect-SPConfigurationDatabase
Dismount-SPContentDatabase
New-SPConfigurationDatabase
Remove-SPConfigurationDatabase


Disconnect-SPConfigurationDatabase
See Also Example
[image]

Published: May 12, 2010

Disconnects the local server computer from the farm.

Disconnect-SPConfigurationDatabase [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Disconnect-SPConfigurationDatabase cmdlet disconnects the active server computer from the SharePoint configuration database. This operation removes the server computer from the farm. The configuration database must be disconnected before the database can be removed.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE------------------

Copy Code
Disconnect-SPConfigurationDatabase -Confirm:$false

This example removes the local server computer from a farm without prompting for user confirmation.

See Also

Reference

New-SPConfigurationDatabase
Remove-SPConfigurationDatabase
Connect-SPConfigurationDatabase
Backup-SPConfigurationDatabase


Move-SPBlobStorageLocation
Example
[image]

Published: May 12, 2010

Copies a Windows SharePoint Services 3.0 content database by using Remote BLOB Storage (RBS).

Move-SPBlobStorageLocation [-SourceDatabase] <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DestinationDatabase <String>] [-DestinationDataSourceInstance <String>] [-Dir <String>] [-VerboseMod <$true | $false>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

SourceDatabase

Required

System.String

Specifies the name of the Windows Internal Database.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DestinationDatabase

Optional

System.String

Specifies the name of the migrated database. If the DestinationDatabase parameter is not specified, the SourceDatabase parameter is used.

DestinationDataSourceInstance

Optional

System.String

Specifies the destination database instance name. The value in the SourceDatabase parameter is migrated to this instance. The database instance name should be Microsoft SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2 version or higher. If the DestinationDataSourceInstance parameter is not specified, the local host name is used.

Dir

Optional

System.String

Used for all disk operations, including storing temporary backups and database (.mdf) files of a migrated database. If the Dir parameter is not specified, a default directory of the destination SQL Server instance is used. The free space in this directory should be at least two times the size of the source database.

VerboseMod

Optional

System.Boolean

Generates verbose log output to be displayed in the Command Prompt window. If the VerboseMod parameter is not specified, no output is displayed.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

Use the Move-SPBlobStorageLocation cmdlet to copy a Windows SharePoint Services 3.0 content database into a Microsoft SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2 database instance by using Remote BLOB Storage (RBS). The database size limitation for SQL Server 2008 with SP1 and Cumulative Update 2 is 4 gigabyes (GB). If a Windows SharePoint Services 3.0 content database is greater than 4 GB, the database cannot be copied directly into a SQL Server 2008 with SP1 and Cumulative Update 2 database instance. The Move-SPBlobStorageLocation cmdlet uses the advantage of RBS and copies databases larger than 4 GB. RBS stores the data on the local hard disk and keeps the links to the data in the database, which results in a smaller database.

Input Types

Return Types

Example

-------------------EXAMPLE 1-----------------------

Copy Code
Move-SPBlobStorageLocation WSS_Content

This example copies the content database named WSS_Content from the Windows Internal Database to the same database name in Microsoft SQL Server 2008 Express by using RBS.

-------------------EXAMPLE 2-----------------------

Copy Code
Move-SPBlobStorageLocation WSS_Content -DestinationDatabase WSS_V4_Content -BackupDatabase WSSBackupDB -VerboseMod:$true

This example copies the content database named WSS_Content from the Windows Internal Database to a database in SQL Server 2008 Express. The name of the new database will be WSS_V4_Content. During the move, the backup file name will be WSSBackupDB. The output of this command displays log information to the Command Prompt window.


New-SPConfigurationDatabase
See Also Example
[image]

Published: May 12, 2010

Creates a new configuration database.

New-SPConfigurationDatabase [-DatabaseName] <String> [-DatabaseServer] <String> [[-DirectoryDomain] <String>] [[-DirectoryOrganizationUnit] <String>] [[-AdministrationContentDatabaseName] <String>] [[-DatabaseCredentials] <PSCredential>] [-FarmCredentials] <PSCredential> [-Passphrase] <SecureString> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

DatabaseName

Required

System.String

Specifies the name of the new configuration database.

DatabaseServer

Required

System.String

Specifies the database server on which to create the configuration database. If no value is specified, the default value is used.

DirectoryDomain

Optional

System.String

Specifies the directory domain for the new farm. If no domain is specified, the domain in which the local computer is located is used.

DirectoryOrganizationUnit

Optional

System.String

Specifies the directory organizational unit for the new configuration database. If no organizational unit is specified, the organizational unit in which the local computer is located is used.

AdministrationContentDatabaseName

Required

System.String

Specifies the name for the Central Administration content database for the new farm. If no name is specified, a default name is used.

DatabaseCredentials

Optional

System.Management.Automation.PSCredential

Specifies the Credential object for the database user. Use this parameter if you use SQL Server Authentication. If no database credentials are provided, Windows authentication is used.

FarmCredentials

Required

System.Management.Automation.PSCredential

Specifies credentials for the Farm Administrator account.

Passphrase

Required

System.Security.SecureString

Specifies the secure password phrase for the new farm. This passphrase is used to join other machines to this farm.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The New-SPConfigurationDatabase cmdlet creates a new configuration database on the specified database server. This is the central database for a new SharePoint farm.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
New-SPConfigurationDatabase -DatabaseName "SharePointConfigDB1" -DatabaseServer "SQL-01" -Passphrase (ConvertTo-SecureString "MyPassword" -AsPlainText -force) -FarmCredentials (Get-Credential)

This example prompts the user to provide user credentials for the default Farm Administrator account.

See Also

Reference

Backup-SPConfigurationDatabase
Disconnect-SPConfigurationDatabase
Connect-SPConfigurationDatabase
Remove-SPConfigurationDatabase
Dismount-SPContentDatabase


Remove-SPConfigurationDatabase
See Also Example
[image]

Published: May 12, 2010

Permanently removes a configuration database.

Remove-SPConfigurationDatabase [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPConfigurationDatabase cmdlet permanently removes the farm's configuration database. The configuration database must be already dismounted from any associated farm.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Remove-SPConfigurationDatabase

This example permanently deletes a configuration database from a farm.

See Also

Reference

Backup-SPConfigurationDatabase
Disconnect-SPConfigurationDatabase
Connect-SPConfigurationDatabase
Dismount-SPContentDatabase
New-SPConfigurationDatabase


Dismount-SPContentDatabase
See Also Example
[image]

Published: May 12, 2010

Detaches a content database from its currently associated Web application.

Dismount-SPContentDatabase [-Identity] <SPContentDatabasePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPContentDatabasePipeBind

Specifies the content database to detach.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SharePoint content database (for example, SPContentDB1); or an instance of a valid SPContentDatabase object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

Use the Dismount-SPContentDatabase cmdlet to detatch the given content database from its currently associated Web application. This cmdlet will not delete the content database. Use the Remove-SPContentDatabase cmdlet to delete a content database.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

--------------EXAMPLE 1------------

Copy Code
Dismount-SPContentDatabase 12345678-90ab-cdef-1234-567890abcdef

This example detaches the content database with the GUID 12345678-90ab-cdef-1234-567890abcdef from its current parent Web application.

--------------EXAMPLE 2------------

Copy Code
Get-SPContentDatabase -WebApplication http://sitename | Dismount-SPContentDatabase -WhatIf

This example detaches all content databases from the Web application on port 80 of the local machine. Remove the WhatIf parameter to perform the operation.

See Also

Reference

Get-SPContentDatabase
Set-SPContentDatabase
New-SPContentDatabase
Remove-SPContentDatabase
Mount-SPContentDatabase
Test-SPContentDatabase


Get-SPContentDatabase
See Also Example
[image]

Published: May 12, 2010

Returns one or more content databases.

Get-SPContentDatabase [[-Identity] <SPContentDatabasePipeBind>] [-AssignmentCollection <SPAssignmentCollection>]
Get-SPContentDatabase -WebApplication <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>]
Get-SPContentDatabase -Site <SPSitePipeBind> [-AssignmentCollection <SPAssignmentCollection>]
Get-SPContentDatabase -ConnectAsUnattachedDatabase <SwitchParameter> -DatabaseName <String> -DatabaseServer <String> [-AssignmentCollection <SPAssignmentCollection>] [-DatabaseCredentials <PSCredential>]

Parameters

1

Parameter

Required

Type

Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPContentDatabasePipeBind

Specifies a specific content database to get.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SharePoint content database (for example, SPContentDB1); or an instance of a valid SPContentDatabase object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

2

Parameter

Required

Type

Description

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Returns the content databases for the specified Web application.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of SharePoint Web application (for example, MyOfficeApp1); or an instance of a valid SPWebApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

3

Parameter

Required

Type

Description

Site

Required

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Returns the content database for the specified site collection.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid URL, in the form http://server_name; or an instance of a valid SPSite object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

4

Parameter

Required

Type

Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

ConnectAsUnattachedDatabase

Optional

System.Management.Automation.SwitchParameter

Specifies that only unattached databases in the farm are returned.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Get-SPContentDatabase cmdlet returns the specified content databases.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

----------------EXAMPLE 1------------

Copy Code
Get-SPContentDatabase -webapplication http://sitename

This example returns all content databases used by the sitename Web application.

----------------EXAMPLE 2------------

Copy Code
Get-SPContentDatabase -site http://contoso.com

This example returns the content database that contains the site collection at http://contoso.com.

See Also

Reference

Set-SPContentDatabase
New-SPContentDatabase
Remove-SPContentDatabase
Mount-SPContentDatabase
Test-SPContentDatabase
Upgrade-SPContentDatabase


Mount-SPContentDatabase
See Also Example
[image]

Published: May 12, 2010

Attaches an existing content database to the farm.

Mount-SPContentDatabase [-Name] <String> [-WebApplication] <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-AssignNewDatabaseId <SwitchParameter>] [-ChangeSyncKnowledge <SwitchParameter>] [-ClearChangeLog <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-DatabaseCredentials <PSCredential>] [-DatabaseServer <String>] [-MaxSiteCount <Int32>] [-UpdateUserExperience <SwitchParameter>] [-WarningSiteCount <Int32>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Name

Required

System.String

Specifies the existing content database to attach to the farm.

The type must be a valid name of a SharePoint content database; for example, SPContentDB1.

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Attaches the content database to the specified SharePoint Web application.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of SharePoint Web application (for example, MyOfficeApp1); or an instance of a valid SPWebApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

AssignNewDatabaseId

Optional

System.Management.Automation.SwitchParameter

Creates a new database ID automatically when the content database is attached.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

ClearChangeLog

Optional

System.Management.Automation.SwitchParameter

Clears any pending changes from the change log in the content database.

DatabaseCredentials

Optional

System.Management.Automation.PSCredential

Specifies the PSCredential object that contains the user name and password to be used for database SQL Authentication.

The type must be a valid PSCredential object.

DatabaseServer

Optional

Microsoft.SharePoint.PowerShell.SPServerPipeBind

Specifies the name of the host server for the content database specified in the Name parameter.

The type must be a valid SQL Server host name; for example, SQLServerHost1.

MaxSiteCount

Optional

System.Int32

Specifies the maximum number of Web sites that can use the content database.

The type must be a positive integer.

UpdateUserExperience

Optional

System.Management.Automation.SwitchParameter

Determines whether the content databases should upgrade to the latest user interface. By default, the user interface will not change during upgrade.

WarningSiteCount

Optional

System.Int32

Specifies the number of sites that can be created before a warning event is generated and the owner of the site collection is notified.

The type must be a positive integer.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Mount-SPContentDatabase cmdlet attaches an existing content database to the farm. If the database being mounted requires an upgrade, this cmdlet will cause the database to be upgraded.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

-----------------EXAMPLE---------------------

Copy Code
Mount-SPContentDatabase "MyDatabase" -DatabaseServer "MyServer" -WebApplication http://sitename

This example mounts an already existing database to the sitename Web application.

See Also

Reference

Get-SPContentDatabase
Set-SPContentDatabase
Remove-SPContentDatabase
Upgrade-SPContentDatabase
Dismount-SPContentDatabase
Get-SPServer


New-SPContentDatabase
Example
[image]

Published: May 12, 2010

Creates a new content database and attaches it to the specified Web application.

New-SPContentDatabase [-Name] <String> [-WebApplication] <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-AssignNewDatabaseId <SwitchParameter>] [-ChangeSyncKnowledge <SwitchParameter>] [-ClearChangeLog <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-DatabaseCredentials <PSCredential>] [-DatabaseServer <String>] [-MaxSiteCount <Int32>] [-WarningSiteCount <Int32>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Name

Required

System.String

Specifies the new content database to create within the farm.

The type must be a valid name of a SharePoint content database; for example, SPContentDB1.

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Attaches the content database to the specified SharePoint Web application.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of SharePoint Web application (for example, MyOfficeApp1); or an instance of a valid SPWebApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

AssignNewDatabaseId

Optional

System.Management.Automation.SwitchParameter

Creates a new database ID automatically when the content database is attached.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

ClearChangeLog

Optional

System.Management.Automation.SwitchParameter

Clears any pending changes from the change log in the content database.

DatabaseCredentials

Optional

System.Management.Automation.PSCredential

Specifies the PSCredential object that contains the user name and password to be used for database SQL Server Authentication.

The type must be a valid PSCredential object.

DatabaseServer

Optional

Microsoft.SharePoint.PowerShell.SPServerPipeBind

Specifies the name of the host server for the content database specified in the Name parameter.

The type must be a valid SQL Server host name; for example, SQLServerHost1.

MaxSiteCount

Optional

System.Int32

Specifies the maximum number of Web sites that can use the content database.

The type must be a positive integer.

WarningSiteCount

Optional

System.Int32

Specifies the number of sites that can be created before a warning event is generated and the owner of the site collection is notified.

The type must be a positive integer.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The New-SPContentDatabase cmdlet creates a new content database and attaches it to the specified Web application.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

--------------EXAMPLE--------------------

Copy Code
New-SPContentDatabase "MyDatabase" -DatabaseServer "MyServer" -WebApplication http://sitename

This example creates a new content database for the sitename Web application.


Remove-SPContentDatabase
See Also Example
[image]

Published: May 12, 2010

Deletes a content database.

Remove-SPContentDatabase [-Identity] <SPContentDatabasePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPContentDatabasePipeBind

Specifies the content database to delete.

The type must be a valid GUID, such as 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SharePoint content database (for example, SPContentDB1); or an instance of a valid SPContentDatabase object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPContentDatabase cmdlet deletes a content database permanently from Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, or SQL Server 2005 with SP3 and Cumulative Update 3. In situations where data needs to be persisted, use the Dismount-SPContentDatabase cmdlet. This will remove the content database from SharePoint 2010 Products but not from SQL Server 2008 R2, SQL Server 2008 with SP1 and Cumulative Update 2, or SQL Server 2005 with SP3 and Cumulative Update 3.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

-----------------EXAMPLE---------------------

Copy Code
Get-SPContentDatabase 12345678-90ab-cdef-1234-567890abcdef | Remove-SPContentDatabase

This example deletes the specified content database.

See Also

Reference

Get-SPContentDatabase
New-SPContentDatabase
Set-SPContentDatabase
Upgrade-SPContentDatabase
Test-SPContentDatabase


Set-SPContentDatabase
See Also Example
[image]

Published: May 12, 2010

Sets global properties of a SharePoint content database.

Set-SPContentDatabase [-Identity] <SPContentDatabasePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-MaxSiteCount <Int32>] [-Status <Online | Disabled | Offline | Unprovisioning | Provisioning | Upgrading>] [-WarningSiteCount <Int32>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPContentDatabasePipeBind

Specifies the content database to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SharePoint content database (for example, SPContentDB1); or an instance of a valid SPContentDatabase object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

MaxSiteCount

Optional

System.Int32

Specifies the maximum number of site collections that this database can host.

The type must be a positive integer. Set to $null to clear this value.

Status

Optional

Microsoft.SharePoint.Administration.SPObjectStatus

Specifies the status of the SQL Server database. Set this parameter to Ready to make the database available to host new sites. Set this parameter to Offline to make the database unavailable to host new sites.

The type must be either of the following: Ready or Offline

WarningSiteCount

Optional

System.Int32

Specifies the number of site collections that can be created before a warning event is generated and the owner of the site collection is notified.

The type must be a positive integer. Set to $null to clear this value.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Set-SPContentDatabase cmdlet sets global properties of a SharePoint content database.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

---------------EXAMPLE 1---------------

Copy Code
Get-SPContentDatabase http://contoso.com | Set-SPContentDatabase -MaxSiteCount 1

This example sets the MaxSiteCount for the content database that contains contoso.com to 1.

---------------EXAMPLE 2---------------

Copy Code
Get-SPContentDatabase -WebApplication http://sitename | Set-SPContentDatabase -WarningSiteCount $null

This example clears the WarningSiteCount for all databases in the sitename Web application.

See Also

Reference

Get-SPContentDatabase
New-SPContentDatabase
Remove-SPContentDatabase
Upgrade-SPContentDatabase
Dismount-SPContentDatabase
Test-SPContentDatabase


Test-SPContentDatabase
See Also Example
[image]

Published: May 12, 2010

Tests a content database.

Test-SPContentDatabase [-Identity] <SPContentDatabasePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-DatabaseCredentials <PSCredential>] [-ServerInstance <SPDatabaseServiceInstancePipeBind>] [-ShowRowCounts <SwitchParameter>]
Test-SPContentDatabase -Name <String> -WebApplication <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-DatabaseCredentials <PSCredential>] [-ServerInstance <SPDatabaseServiceInstancePipeBind>] [-ShowRowCounts <SwitchParameter>]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPContentDatabasePipeBind

Specifies an existing connected Microsoft SharePoint 2010 Products content database to one of the two parameter sets in the form of a GUID or database name if it is unique.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

DatabaseCredentials

Optional

System.Management.Automation.PSCredential

Specifies the PSCredential object that contains the user name and password to be used for database SQL Server Authentication.

The type must be a valid PSCredential object.

ServerInstance

Optional

Microsoft.SharePoint.PowerShell.SPDatabaseServiceInstancePipeBind

Specifies the instance of the database service to use to test the specified content database.

The type must be a valid GUID, such as 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SQL Server instance (for example, DBSvrInstance1); or an instance of a valid SPDatabaseServiceInstance object.

ShowRowCounts

Optional

System.Management.Automation.SwitchParameter

Returns database statistics which are row counts for tables in the content database.

2

Parameter

Required

Type

Description

Name

Required

System.String

Specifies the existing content database to test.

The type must be a valid name of a SharePoint content database; for example, SPContentDB1.

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the SharePoint Web application to use to test the content database.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of SharePoint Web application (for example, MyOfficeApp1); or an instance of a valid SPWebApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

DatabaseCredentials

Optional

System.Management.Automation.PSCredential

Specifies the PSCredential object that contains the user name and password to be used for database SQL Server Authentication.

The type must be a valid PSCredential object.

ServerInstance

Optional

Microsoft.SharePoint.PowerShell.SPDatabaseServiceInstancePipeBind

Specifies the instance of the database service to use to test the specified content database.

The type must be a valid GUID, such as 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SQL Server instance (for example, DBSvrInstance1); or an instance of a valid SPDatabaseServiceInstance object.

ShowRowCounts

Optional

System.Management.Automation.SwitchParameter

Returns database statistics which are row counts for tables in the content database.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

Use the Test-SPContentDatabase cmdlet to test a content database against a Web application to verify all customizations referenced within the content database are also installed in the web application. This cmdlet can be issued against a content database currently attached to the farm, or a content database that is not connected to the farm. It can be used to test content databases from SharePoint 2010 Products and from SharePoint Products and Technologies.

Note:

The Test-SPContentDatabase cmdlet does not change any of the data or structure of the content database, but can cause load on the database while the checks are in progress, which could temporarily block use of the content database. This cmdlet should only be used against a content database that is currently under low or no usage.

Input Types

Return Types

Example

----------------------------EXAMPLE 1-----------------------

Copy Code
Test-SPContentDatabase -name WSS_Content_DB -webapplication http://sitename

This example tests the WSS_Content_DB content database against the sitename Web application, and returns a list of issues.

----------------------------EXAMPLE 2-----------------------

Copy Code
$DB = Get-SPContentDatabase -site http://contoso.com
Copy Code
Test-SPContentDatabase $DB -showrowcounts

This example gets the content database that contains the site collection at http://contoso.com, and then tests the database against the Web application that hosts it to determine issues. Together with displaying the list of issues, by specifying the ShowRowCounts parameter, this also returns the table size metrics from the content database.

See Also

Reference

Get-SPContentDatabase
New-SPContentDatabase
Set-SPContentDatabase
Remove-SPContentDatabase
Mount-SPContentDatabase
Upgrade-SPContentDatabase


Get-SPDatabase
See Also Example
[image]

Published: May 12, 2010

Retrieves all properties of a database.

Get-SPDatabase [[-Identity] <SPDatabasePipeBind>] [-AssignmentCollection <SPAssignmentCollection>]
Get-SPDatabase -ServerInstance <SPDatabaseServiceInstancePipeBind> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

1

Parameter

Required

Type

Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPDatabasePipeBind

Specifies the name of the database to display public properties.

The type must be a valid GUID, in the form 1234-3456-567kg.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

2

Parameter

Required

Type

Description

ServerInstance

Required

Microsoft.SharePoint.PowerShell.SPDatabaseServiceInstancePipeBind

Specifies the name of the SQL instance that contains the database in either the form "Server" for a default SQL instance or "Server\Instance" for a named SQL instance.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Get-SPDatabase cmdlet displays all public properties of a database to the current window. If the Identity parameter is specified, only properties of that ID are displayed.

Input Types

Return Types

Example

--------------------EXAMPLE---------------------

Copy Code
Get-SPDatabase -ServerInstance "ServerA\SharePoint"

This example gets all databases on a specific named SQL Server Express instance.

See Also

Reference

Get-SPContentDatabase
New-SPContentDatabase
Set-SPContentDatabase


Farm cmdlets (SharePoint Foundation 2010)

Published: June 24, 2010

You can use Windows PowerShell cmdlets to administer a Microsoft SharePoint Foundation 2010 farm.

Cmdlet name | Description
Get-SPFarmConfig | Returns a global property or a collection of global properties for the local farm.
Get-SPProcessAccount | Returns a system account or a managed account.
Get-SPWebTemplate | Displays all globally installed site templates that match the given identity.
Install-SPWebTemplate | Installs the given site template.
New-SPCentralAdministration | Creates a new SharePoint Central Administration Web application.
Set-SPCentralAdministration | Sets the port for the SharePoint Central Administration Web site.
Set-SPFarmConfig | Sets a global property or a collection of global properties for the local farm.
Set-SPPassPhrase | Sets the passphrase to a new value.
Set-SPWebTemplate | Changes the title and description of an installed site template.
Start-SPAdminJob | Immediately starts any waiting administrative job on the local computer.
Uninstall-SPWebTemplate | Uninstalls the given site template.


Get-SPFarmConfig
See Also Example
[image]

Published: May 12, 2010

Returns a global property or a collection of global properties for the local farm.

Get-SPFarmConfig [-AssignmentCollection <SPAssignmentCollection>] [-ServiceConnectionPoint <SwitchParameter>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

ServiceConnectionPoint

Optional

System.Management.Automation.SwitchParameter

Gets the information stored in the current farm's service connection point in Active Directory.

Detailed Description

The Get-SPFarmConfig cmdlet retrieves global settings for the local farm that are not members of the SPFarm object. This cmdlet creates a new PSCustomObject object from the collection of properties returned from the local farm, and then adds this object to the pipeline. The PSCustomObject object can be read, or modified and passed to the Set-SPFarmConfig cmdlet to change parameter values.

The properties collected in the PSCustomObject object must be farm-wide settings, and must be configurable only once for the entire farm. The parameter name added to the PSCustomObject object must match exactly the input parameter name for the Set-SPFarmConfig cmdlet.

Input Types

Return Types

Example

-------------EXAMPLE----------------

Copy Code
$a = Get-SPFarmConfig
Copy Code
$a.AjaxTimeout = 200
Copy Code
$a | Set-SPFarmConfig

This example uses the Get-SPFarmConfig cmdlet to add the Ajax Timeout setting to the PSCustomObject object, sets the value for Ajax Timeout, and then passes PSCustomObject to the Set-SPFarmConfig cmdlet to change the Ajax Timeout setting. Ajax Timeout, a farm-wide setting, is a member of the SPWebService object and cannot be accessed with a Windows PowerShell cmdlet.

You can perform the same operations with either of the following commands.

Copy Code
Set-SPFarmConfig -AjaxTimeout 200
Copy Code
Get-SPFarmConfig | Select AjaxTimeout 200

See Also

Reference

Set-SPFarmConfig


Get-SPProcessAccount
Example
[image]

Published: May 12, 2010

Returns a system account or a managed account.

Get-SPProcessAccount [-AssignmentCollection <SPAssignmentCollection>] [-NetworkService <SwitchParameter>]
Get-SPProcessAccount [-AssignmentCollection <SPAssignmentCollection>] [-LocalSystem <SwitchParameter>]
Get-SPProcessAccount [-AssignmentCollection <SPAssignmentCollection>] [-LocalService <SwitchParameter>]

Parameters

1

Parameter

Required

Type

Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

NetworkService

Optional

System.Management.Automation.SwitchParameter

Returns the NetworkService account.

2

Parameter

Required

Type

Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

LocalSystem

Optional

System.Management.Automation.SwitchParameter

Returns the LocalSystem account.

3

Parameter

Required

Type

Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

LocalService

Optional

System.Management.Automation.SwitchParameter

Returns the LocalService account.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Get-SPProcessAccount cmdlet returns a system account or a managed account and creates the SPProcessAccountPipeBind object. All operations that can accept an account can accept the SPProcessAccountPipeBind in place of the SPManagedAccountPipeBind.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE 1-----------------------

Copy Code
Get-SPProcessAccount -NetworkService

This example creates the SPProcessAccountPipeBind type by using the NetworkService account.

------------------EXAMPLE 2-----------------------

Copy Code
Get-SPProcessAccount -NetworkService | New-SPServiceApplicationPool -Account $_

This example creates an SPServiceApplicationPool account by using the NetworkService account returned by the Get-SPProcessAccount cmdlet.


Get-SPWebTemplate
See Also Example
[image]

Published: May 12, 2010

Displays all globally installed site templates that match the given identity.

Get-SPWebTemplate [[-Identity] <SPWebTemplatePipeBind>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the name of the Web template to display.

The type must be the ID or full or partial name of the Web template.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPWebTemplate cmdlet displays all installed site templates that match the full or partial identity that was given.

Input Types

Return Types

Example

--------------EXAMPLE 1-----------------

Copy Code
$template = Get-SPWebTemplate "STS#0"
Copy Code
New-SPSite http://contoso.com -OwnerAlias "DOMAIN\JDOE" -Template $template

This example creates a site collection by using the team site Web template (ID=STS#0).

--------------EXAMPLE 2-----------------

Copy Code
Get-SPWebTemplate "STS*"

This example displays basic information about all the STS templates.

See Also

Reference

Set-SPWebTemplate
Install-SPWebTemplate
Uninstall-SPWebTemplate


Install-SPWebTemplate
See Also Example
[image]

Published: May 12, 2010

Installs the given site template.

Install-SPWebTemplate [-Path] <String> -Name <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Description <String>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Path

Required

System.String

Specifies the path to the site template package.

The type must be a valid path; for example, <example of path>.

Name

Required

System.String

Specifies the name of the template.

The type must be a valid name; for example, MyTemplate.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Description

Optional

System.String

Specifies the template description.

The type must be a valid description; for example, Joe's Template.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Install-SPWebTemplate cmdlet installs the given site template using the name provided (title) as the unique ID.

Input Types

Return Types

Example

--------------EXAMPLE-----------------

Copy Code
Install-SPWebTemplate -path "mytemplate.cab" -name "My Template" -description "TestFarm"

This example installs the mytemplate.cab file as My Template with the description "TestFarm" on the farm.

See Also

Reference

Get-SPWebTemplate
Set-SPWebTemplate
Uninstall-SPWebTemplate


New-SPCentralAdministration
See Also Example
[image]

Published: May 12, 2010

Creates a new SharePoint Central Administration Web application.

New-SPCentralAdministration [[-Port] <Int32>] [[-WindowsAuthProvider] <String>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Port

Optional

System.Int32

Specifies the port number for Central Administration. If no port is specified, a nonconflicting port number is auto-generated.

The type must be a valid port number.

Important:

If you specify a port number that has already been assigned, IIS does not start the new site until you change either the port number of the new site or the port number of the old site.

WindowsAuthProvider

Optional

System.String

Specifies the authorization provider for this Web application. If no authentication provider is specified, the default value NTLM is used.

The type must be one of two values: Kerberos, orNTLM.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The New-SPCentralAdministration cmdlet creates a new Central Administration Web application and starts the central administration service on the local computer. Central Administration is available only on computers where this service runs.

Input Types

Return Types

None.

Example

------------------EXAMPLE-----------------------

Copy Code
New-SPCentralAdministration -Port 3000

This example creates the Central Administration site at port 3000 on the local farm.

See Also

Reference

Set-SPCentralAdministration


Set-SPCentralAdministration
See Also Example
[image]

Published: May 12, 2010

Sets the port for the SharePoint Central Administration Web site.

Set-SPCentralAdministration -Port <Int32> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Port

Required

System.Int32

Specifies the administration port for the Central Administration site.

The type must be a valid port number; for example, 8080.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Set-SPCentralAdministration cmdlet sets the port for the Central Administration site.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Set-SPCentralAdministration -Port 8282

This example sets the port for the Central Administration web application on the local farm to 8282.

See Also

Reference

New-SPCentralAdministration


Set-SPFarmConfig
See Also Example
[image]

Published: May 12, 2010

Sets a global property or a collection of global properties for the local farm.

Set-SPFarmConfig [-ASPScriptOptimizationEnabled <$true | $false>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DataFormWebPartAutoRefreshEnabled <$true | $false>] [-Force <SwitchParameter>] [-InstalledProductsRefresh <SwitchParameter>] [-ServiceConnectionPointBindingInformation <String>] [-ServiceConnectionPointDelete <SwitchParameter>] [-WhatIf [<SwitchParameter>]] [-WorkflowBatchSize <Int32>] [-WorkflowEventDeliveryTimeout <Int32>] [-WorkflowPostponeThreshold <Int32>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DataFormWebPartAutoRefreshEnabled

Optional

System.Boolean

Specifies whether any DataFormWebPart on any page in this farm is allowed to periodically refresh its contents asynchronously (after the page has finished rendering). When set to false, all DataFormWebParts will ignore the automatic refresh interval provided in Web Part properties.

Force

Optional

System.Management.Automation.SwitchParameter

Forces the deletion or updating of the service connection point.

InstalledProductsRefresh

Optional

System.Management.Automation.SwitchParameter

Updates the current machine license state with the list of products that are installed in the farm.

ServiceConnectionPointBindingInformation

Optional

System.String

Adds or updates the service connection point for the current farm in Active Directory Domain Service (AD DS).

The type must be an array of strings that are key value pairs that will be added to the service connection point.

ServiceConnectionPointDelete

Optional

System.Management.Automation.SwitchParameter

Delete the service connection point for the current farm in AD DS.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

WorkflowBatchSize

Optional

System.Int32

Specifies the paging size for events delivered to a single workflow instance. For each request, the events are streamed out 100 at a time.

Batch size is the number of events processed for a single workflow instance, which can have many events queued at the same time. Throttle will override batch size; if the workflow instance cannot be started or restarted because there are too many instances running across all front-end Web servers, none of the events will be fetched, regardless of the batch size.

WorkflowEventDeliveryTimeout

Optional

System.Int32

Specifies the time as an integer in which a workflow job must run without the job timing out. If the workflow job does time out, it gets put back in the queue to be run again.

For example, if the value is set to 5, the workflow job must run within 5 minutes are the workflow job will time out. Any workflow job that does time out is placed back in the queue to run again.The default value is 5.

WorkflowPostponeThreshold

Optional

System.Int32

Specifies the number of workflows that can be running in IIS against a content database at a time before new workflow instances get postponed into a queue.

Detailed Description

The Set-SPFarmConfig cmdlet updates a collection of global settings for the local farm that are not members of the SPFarm object. Use the Get-SPFarmConfig cmdlet to read global settings for the local farm and to create a new PSCustomObject object from the collection of properties returned from the local farm, and then add this object to the pipeline. Modify the PSCustomObject object and pass it to the Set-SPFarmConfig cmdlet to change the parameter values.

The properties collected in the PSCustomObject object must be farm-wide settings, and must be configurable only once for the entire farm. The parameter name added to the PSCustomObject object must match exactly the input parameter name for the Set-SPFarmConfig cmdlet.

Input Types

Return Types

Example

---------------------EXAMPLE--------------------------

Copy Code
$a = Get-SPFarmConfig
Copy Code
$a.AjaxTimeout = 200
Copy Code
$a | Set-SPFarmConfig

This example uses the Get-SPFarmConfig cmdlet to add the Ajax Timeout setting to the PSCustomObject object, sets the value for Ajax Timeout, and then passes PSCustomObject to the Set-SPFarmConfig cmdlet to change the Ajax Timeout setting. Ajax Timeout, a farm-wide setting, is a member of the SPWebService object and cannot be accessed by using a Windows PowerShell cmdlet.

You can perform the same operations with either of the following commands.

Copy Code
Set-SPFarmConfig -AjaxTimeout 200

See Also

Reference

Get-SPFarmConfig


Set-SPPassPhrase
Example
[image]

Published: May 12, 2010

Sets the pass phrase to a new value.

Set-SPPassPhrase -ConfirmPassPhrase <SecureString> -PassPhrase <SecureString> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]
Set-SPPassPhrase -PassPhrase <SecureString> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-LocalServerOnly <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

LocalServerOnly

Optional

System.Management.Automation.SwitchParameter

Scopes the Passphrase change to the local server only. If this parameter is not used, the Passphrase change is performed farm-wide.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Set-SPPassPhrase cmdlet sets the Passphrase to a new Passphrase value. If the LocalServerOnly parameter is not used, the farm encryption key is re-encrypted with the new value and attempts to propagate this value to all other servers in the farm. If the LocalServerOnly parameter is used, this is updated on the local machine only, and the farm encryption key is not changed. The Passphrase value must be the same on all servers in the farm if the farm is to function correctly. So if the Passphrase fails to propagate to all servers, the LocalServerOnly parameter can be used to set the remaining servers to the new Passphrase value manually.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
$passphrase = ConvertTo-SecureString -asPlainText -Force
Copy Code
Set-SPPassPhrase -PassPhrase $passphrase -Confirm

This example queries for a string to use as a passphrase, and sets the farm passphrase to a new value.


Set-SPWebTemplate
See Also Example
[image]

Published: May 12, 2010

Changes the title and description of an installed site template.

Set-SPWebTemplate [-Identity] <SPWebTemplatePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Description <String>] [-Name <String>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPWebTemplatePipeBind

Specifies the name of the Web template to be changed.

The type must the ID or full name of the Web template.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Description

Optional

System.String

Specifies the new description.

The type must be a valid description; for example, This is template.

Name

Optional

System.String

Specifies the new name for the template.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Set-SPWebTemplate cmdlet changes the title and description of an installed site template.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Get-SPSiteTemplate "ATH#0" | Set-SPSiteTemplate -name "Athletics Site"
Copy Code
Set-SPSiteTemplate "ATH#0" -name "Athletics Site"

This examples change the ATH#0 template title to Athletics Site.

See Also

Reference

Get-SPWebTemplate
Install-SPWebTemplate
Uninstall-SPWebTemplate


Start-SPAdminJob
See Also Example
[image]

Published: May 12, 2010

Immediately starts any waiting administrative job on the local computer.

Start-SPAdminJob [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

Use the Start-SPAdminJob cmdlet to execute all administrative timer jobs immediately rather than waiting for the timer job to run.

When the service account for the SharePoint 2010 Administration service (SPAdminV4)) is disabled (necessary in some installations for security reasons), the Start-SPAdminJob cmdlet must be run on all computers to perform administrative task like provisioning.

When you run this cmdlet in person (not in script), use the Verbose parameter to see the individual administrative operations that are run.

Input Types

Return Types

none

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE-----------------------

Copy Code
Start-SPAdminJob -Verbose

This example runs all waiting administrative jobs and shows verbose output to the administrator.

See Also

Reference

Get-SPTimerJob
Set-SPTimerJob
Enable-SPTimerJob
Disable-SPTimerJob


Uninstall-SPWebTemplate
See Also Example
[image]

Published: May 12, 2010

Uninstalls the given site template.

Uninstall-SPWebTemplate [-Identity] <SPWebTemplatePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Language <UInt32>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPWebTemplatePipeBind

Specifies the ID or full name of the site template to remove.

A valid site template; for example, MYTEMP#0.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Language

No

System.Int32

Specifies the language of the file to remove. If this parameter is not provided, all the languages of given template are removed. The default value is ALL.

The type must be a valid language locale ID. For English, use 1033.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Uninstall-SPWebTemplate cmdlet uninstalls the given site template by providing a full identity.

Input Types

Return Types

None.

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE-----------------------

Copy Code
Uninstall-SPWebTemplate "mytemplate"
Copy Code
Get-SPWebTemplate "mytemplate" | Uninstall-SPWebTemplate

This example removes a site template named mytemplate.

See Also

Reference

Get-SPWebTemplate
Install-SPWebTemplate
Set-SPWebTemplate


Features and solutions cmdlets (SharePoint Foundation 2010)
See Also

You can use Windows PowerShell cmdlets to manage features and solutions in a Microsoft SharePoint Foundation 2010 farm.

Cmdlet name | Description
Add-SPSiteSubscriptionFeaturePackMember | Adds a feature to a SharePoint feature set.
Add-SPSolution | Uploads a SharePoint solution package to the farm.
Add-SPUserSolution | Uploads a new sandboxed solution to the solution gallery.
Disable-SPFeature | Disables an installed SharePoint feature at a given scope.
Enable-SPFeature | Enables an installed SharePoint feature at the given scope.
Get-SPFeature | Returns the SharePoint features based on a given scope.
Get-SPSiteSubscriptionFeaturePack | Retrieves available SharePoint feature sets or the Feature set assigned to a given site subscription.
Get-SPSolution | Returns a specified SharePoint solution.
Get-SPUserSolution | Returns a specified sandboxed solution.
Install-SPFeature | Installs a SharePoint feature by using the Feature.xml file.
Install-SPSolution | Deploys an installed SharePoint solution in the farm.
Install-SPUserSolution | Activates a sandboxed solution in a site collection.
New-SPSiteSubscriptionFeaturePack | Creates a new SharePoint feature set that can be used to limit the features available to a site subscription.
Remove-SPSiteSubscriptionFeaturePack | Removes a SharePoint feature set from a site subscription.
Remove-SPSiteSubscriptionFeaturePackMember | Removes a feature definition from the provided SharePoint feature set.
Remove-SPSolution | Removes a SharePoint solution from a farm.
Remove-SPUserSolution | Removes a sandboxed solution from the solution gallery.
Remove-SPSolutionDeploymentLock | Removes the solution deployment lock for a server.
Uninstall-SPFeature | Uninstalls an installed feature definition.
Uninstall-SPUserSolution | Deactivates a sandboxed solution in a site collection.
Uninstall-SPSolution | Retracts a deployed SharePoint solution.
Update-SPSolution | Upgrades a deployed SharePoint solution.
Update-SPUserSolution | Upgrades an activated sandboxed solution in a farm.

See Also

Other Resources

Resource Center: Windows PowerShell for SharePoint Foundation 2010


Add-SPSiteSubscriptionFeaturePackMember
See Also Example
[image]

Published: May 12, 2010

Adds a feature to a SharePoint Feature set.

Add-SPSiteSubscriptionFeaturePackMember [-Identity] <SPSiteSubscriptionFeaturePackPipeBind> -FeatureDefinition <SPFeatureDefinitionPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPFeatureSetPipeBind

Specifies the Feature set object or GUID to which the given SharePoint Feature is added.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of a Feature set (for example, FeatureSet1); or an instance of a valid SPFeatureSet object.

FeatureDefinition

Required

Microsoft.SharePoint.PowerShell.SPFeatureDefinitionPipeBind

Specifies the Feature definition, name, or GUID to add to the Feature set.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Add- SPSiteSubscriptionFeaturePackMember cmdlet adds features to the provided SharePoint Feature set. Feature sets are an Allow List of SharePoint Features that can be associated with any site subscription. If a Feature set is assigned to a site subscription, only the SPFeatures object in that Feature set are available for use on the site collections and Web sites that are members of the site subscription. Feature sets contain a list of the GUIDs of each Feature that are on the Allow List for associated site subscriptions.

Input Types

Return Types

Example

-------------EXAMPLE----------------

Copy Code
$fs = New-SPFeatureSet
Copy Code
Get-SPFeature -limit all | Where{ $_.Scope -eq "WEB" } | Add-SPSiteSubscriptionFeaturePackMember -id $fs
Copy Code
$fs = Get-SPFeatureSet $fs

This example creates a Feature set and adds all Web site scoped Features to the set.

The Feature set is refreshed in the last line so that the local object has the correct values.

See Also

Reference

Remove-SPSiteSubscriptionFeaturePackMember


Add-SPSolution
See Also Example
[image]

Published: May 12, 2010

Uploads a SharePoint solution package to the farm.

Add-SPSolution [-LiteralPath] <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Language <UInt32>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

LiteralPath

Required

System.String

Specifies the path to the solution package.

The type must be a valid path in either of the following forms:

- C:\folder_name

- \\server_name\folder_name

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Language

Optional

System.UInt32

Specifies the language pack to install with the solution package.

The type must be a valid language identifier; for example, 1033.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Add-SPSolution cmdlet adds a SharePoint solution package to the farm. This cmdlet does not deploy the uploaded SharePoint solution. Use the Install-SPSolution cmdlet to deploy the SharePoint solution in the farm.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE------------------

Copy Code
Add-SPSolution -LiteralPath c:\contoso_solution.wsp

This example adds the SharePoint solution in the file contoso_solution.wsp to the farm.

See Also

Reference

Get-SPSolution
Update-SPSolution
Uninstall-SPSolution
Remove-SPSolution
Install-SPSolution
Remove-SPSolutionDeploymentLock


Add-SPUserSolution
See Also Example
[image]

Published: May 12, 2010

Uploads a new sandboxed solution to the solution gallery.

Add-SPUserSolution [-LiteralPath] <String> -Site <SPSitePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

LiteralPath

Required

System.String

Specifies the path to the sandboxed solution package.

The type must be a valid path in either of the following forms:

- C:\folder_name

- \\server_name\folder_name

Site

Required

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Specifies the site collection where the sandboxed solution is to be added.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid URL, in the form http://server_name; or an instance of a valid SPSiteobject.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Add-SPUserSolution cmdlet uploads a new sandboxed solution package to the solution gallery. This cmdlet does not activate the uploaded sandboxed solution; to activate the solution in the site collection, use the Install-SPUserSolution cmdlet.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

-------------------EXAMPLE---------------------

Copy Code
Add-SPUserSolution -LiteralPath c:\contoso_solution.wsp -Site http://sitename

This example adds the sandboxed solution c:\contoso_solution.wsp to the site http://sitename.

See Also

Reference

Update-SPUserSolution
Install-SPUserSolution
Uninstall-SPUserSolution
Remove-SPUserSolution
Get-SPUserSolution


Disable-SPFeature
See Also Example
[image]

Published: May 12, 2010

Disables an installed SharePoint Feature at a given scope.

Disable-SPFeature [-Identity] <SPFeatureDefinitionPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-Url <String>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPFeatureDefinitionPipeBind

Specifies the name of the Feature or GUID to disable.

The type must be the name of the Feature folder located in the 14\Template\Features folder or GUID, in the format 21d186e1-7036-4092-a825-0eb6709e9281.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Forces a Feature to be disabled.

Url

Optional

System.String

Specifies the URL of the Web application, site collection, or Web site to which the Feature is being disabled.

The type must be a valid URL, such as http://server_name.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Disable-SPFeature cmdlet disables a SharePoint Feature at the given scope. If the scope of the Feature is the farm, the URL is not needed. Otherwise, provide the URL at which this Feature is to be deactivated (explicit scope is not needed).

Input Types

Return Types

none

Example

--------------EXAMPLE 1-----------------

Copy Code
Disable-SPFeature -identity "MyCustom" -URL http://somesite

This example disables the "MyCustom" Web site scoped feature at http://somesite.

--------------EXAMPLE 2-----------------

Copy Code
$w = Get-SPWeb http://somesite/myweb | ForEach{ $_.URL }
Copy Code
Get-SPFeature -Web $w |%{ Disable-SPFeature -Identity $_ -URL $w}

This example disables all features in the subsite at http://somesite/myweb.

You do not need to use the SPAssignment cmdlets in this case because the Web object is not stored — only the string value for the URL.

See Also

Reference

Install-SPFeature
Enable-SPFeature
Get-SPFeature
Uninstall-SPFeature


Enable-SPFeature
See Also Example
[image]

Published: May 12, 2010

Enables an installed SharePoint Feature at the given scope.

Enable-SPFeature [-Identity] <SPFeatureDefinitionPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-PassThru <SwitchParameter>] [-Url <String>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPFeatureDefinitionPipeBind

Specifies the name of the Feature or GUID to uninstall.

The type must be the name of the Feature folder located in the 14\Template\Features folder or GUID, in the form 21d186e1-7036-4092-a825-0eb6709e9281.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Forces the activation of a Feature. This causes any custom code associated with the Feature to rerun.

PassThru

Optional

System.Management.Automation.SwitchParameter

If provided, the cmdlet outputs the Feature definition object after enable.

Url

Optional

System.String

Specifies the URL of the Web application, site collection, or Web site for which the Feature is being activated.

The type must be a valid URL; for example, http://server_name.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Enable-SPFeature cmdlet enables an installed feature at the given scope. If the feature is a farm feature, no URL is needed. Otherwise, provide the URL where the feature is to be enabled and it will be enabled at the proper scope based on the Feature definition.

This cmdlet has no output unless the PassThru parameter is provided, in which case the SPFeatureDefinition object for the newly enabled feature is returned.

Note:

If you try to use the Url parameter on a farm-scoped feature, you receive the following error message:

The feature '<feature name>' applies to the entire farm; the Url parameter cannot be used with farm-scoped features.

Input Types

Return Types

Example

--------------EXAMPLE 1-----------------

Copy Code
Enable-SPFeature -identity "MyCustom" -URL http://somesite

This example enables the "MyCustom" site scoped SharePoint Feature at http://somesite.

--------------EXAMPLE 2-----------------

Copy Code
$w = Get-SPWeb http://somesite/myweb | ForEach{ $_.URL }
Copy Code
Get-SPFeature -Web $w |%{ Enable-SPFeature -Identity $_ -URL $w}

This example enables all SharePoint Features in the subsite at http://somesite/myweb.

See Also

Reference

Disable-SPFeature
Install-SPFeature
Uninstall-SPFeature
Get-SPFeature


Get-SPFeature
See Also Example
[image]

Published: May 12, 2010

Returns the SharePoint Features based on a given scope.

Get-SPFeature [[-Identity] <SPFeatureDefinitionPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-Limit <String>]
Get-SPFeature [[-Identity] <SPFeatureDefinitionPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-Farm <SwitchParameter>] [-Limit <String>]
Get-SPFeature [[-Identity] <SPFeatureDefinitionPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-Limit <String>] [-Sandboxed <SwitchParameter>] [-Site <SPSitePipeBind>]
Get-SPFeature [[-Identity] <SPFeatureDefinitionPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-Limit <String>] [-Web <SPWebPipeBind>]
Get-SPFeature [[-Identity] <SPFeatureDefinitionPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-Limit <String>] [-WebApplication <SPWebApplicationPipeBind>]

Parameters

1

Parameter

Required

Type

Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPFeatureDefinitionPipeBind

Specifies the name of the Feature to retrieve.

The type must be the full or partial name, in the form Feature1, or a GUID, in the form 1234-4567-9879, of the Feature to get .

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Limit

Optional

System.String

Limits the display results. If "All" is specified, all Features are displayed.

The type must be a valid number greater than 0. The default value is 200.

2

Parameter

Required

Type

Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPFeatureDefinitionPipeBind

Specifies the name of the Feature to retrieve.

The type must be the full or partial name, in the form Feature1, or a GUID, in the form 1234-4567-9879, of the Feature to get .

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Farm

Optional

System.Management.Automation.SwitchParameter

Specifies that if this parameter is used, only enabled farm Features are displayed.

Limit

Optional

System.String

Limits the display results. If "All" is specified, all Features are displayed.

The type must be a valid number greater than 0. The default value is 200.

3

Parameter

Required

Type

Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPFeatureDefinitionPipeBind

Specifies the name of the Feature to retrieve.

The type must be the full or partial name, in the form Feature1, or a GUID, in the form 1234-4567-9879, of the Feature to get .

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Limit

Optional

System.String

Limits the display results. If "All" is specified, all Features are displayed.

The type must be a valid number greater than 0. The default value is 200.

Site

Optional

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Specifies the name of the site collection from which to get enabled Features.

The type must be a valid URL for a site collection, in the form http://server_name .

4

Parameter

Required

Type

Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPFeatureDefinitionPipeBind

Specifies the name of the Feature to retrieve.

The type must be the full or partial name, in the form Feature1, or a GUID, in the form 1234-4567-9879, of the Feature to get .

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Limit

Optional

System.String

Limits the display results. If "All" is specified, all Features are displayed.

The type must be a valid number greater than 0. The default value is 200.

Web

Optional

Microsoft.SharePoint.PowerShell.SPWebPipeBind

Specifies the URL or GUID of the Web.

The type must be a valid URL, in the form http://server_name , or a GUID, in the form 1234-5678-9876-0987.

5

Parameter

Required

Type

Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPFeatureDefinitionPipeBind

Specifies the name of the Feature to retrieve.

The type must be the full or partial name, in the form Feature1, or a GUID, in the form 1234-4567-9879, of the Feature to get .

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Limit

Optional

System.String

Limits the display results. If "All" is specified, all Features are displayed.

The type must be a valid number greater than 0. The default value is 200.

Web

Optional

Microsoft.SharePoint.PowerShell.SPWebPipeBind

Specifies the URL or GUID of the Web.

The type must be a valid URL, in the form http://server_name , or a GUID, in the form 1234-5678-9876-0987.

WebApplication

Optional

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the name of the Web application from which to get enabled Features.

The type must be a valid URL to the Web application in the form http://server_name .

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

All parameter sets take the Identity parameter, which can be either the relative path of the SharePoint Feature (considered the feature name) or the GUID of a Feature definition. If the Identity parameter is provided, the cmdlets attempt to find the given Feature definition or instance for the given scope. If no parameters are specified, all installed features are returned.

The Get-SPFeature cmdlet behaves differently at each scope, returning the enabled Features at each level. If no scope is provided, all installed Features are returned.

Input Types

Return Types

Example

--------------EXAMPLE 1-----------------

Copy Code
Get-SPFeature -Limit ALL | Where-Object {$_.Scope -eq "SITE"}

This example returns a list of all installed SITE scoped Features.

--------------EXAMPLE 2-----------------

Copy Code
Get-SPSite http://somesite | Get-SPWeb -Limit ALL |%{ Get-SPFeature -Web $_ } | Select DisplayName,ID -Unique

This example returns the name and identifier (ID) of each uniquely enabled Feature on every SPWeb object in the site collection at http://somesite.

See Also

Reference

Install-SPFeature
Enable-SPFeature
Disable-SPFeature
Uninstall-SPFeature


Get-SPSiteSubscriptionFeaturePack
See Also Example
[image]

Published: May 12, 2010

Retrieves available SharePoint Feature sets or the Feature set assigned to a given site subscription.

Get-SPSiteSubscriptionFeaturePack [[-Identity] <SPSiteSubscriptionFeaturePackPipeBind>] [-AssignmentCollection <SPAssignmentCollection>]
Get-SPSiteSubscriptionFeaturePack [-AssignmentCollection <SPAssignmentCollection>] [-SiteSubscription <SPSiteSubscriptionPipeBind>]

Parameters

1

Parameter

Required

Type

Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPFeatureSetPipeBind

Specifies a valid name or GUID of the Feature set.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

2

Parameter

Required

Type

Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

SiteSubscription

Optional

Microsoft.SharePoint.PowerShell.SPSiteSubscriptionPipeBind

If provided, ensures that the returned Feature set is the Feature set that is currently assigned to the given site subscription.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Get-SPSiteSubscriptionFeaturePack cmdlet retrieves available SharePoint Feature sets or the Feature set assigned to a given site subscription.

Warning:

Be careful when you assign Feature sets to variables because changes to the Feature set are not reflected until the variable is refreshed.

Input Types

Return Types

Example

------------------EXAMPLE 1------------------

Copy Code
Get- SPSiteSubscriptionFeaturePack

This example returns all defined Feature sets in the local farm.

------------------EXAMPLE 2------------------

Copy Code
Get-SPSiteSubscriptionFeaturePack -SiteSubscription http://contoso.com | ForEach{ $_.FeatureDefinitions }

This example returns the list (name, ID, and scope) of all Features allowed in the Feature set that is currently assigned to the site subscription of http://contoso.com.

See Also

Reference

New-SPSiteSubscriptionFeaturePack
Remove-SPSiteSubscriptionFeaturePack
Add-SPSiteSubscriptionFeaturePackMember


Get-SPSolution
See Also Example
[image]

Published: May 12, 2010

Returns a specified SharePoint solution.

Get-SPSolution [[-Identity] <SPSolutionPipeBind>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPSolutionPipeBind

Specifies the SharePoint solution to get.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SharePoint solution (for example, SPSolution1); or an instance of a valid SPSolution object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPSolution cmdlet returns a specified SharePoint solution. If the Identity parameter is not specified, this cmdlet returns the collection of all installed SharePoint solutions in the farm.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE------------------

Copy Code
Get-SPSolution

This example returns the collection of all installed SharePoint solutions in the farm.

See Also

Reference

Get-SPSolution
Add-SPSolution
Update-SPSolution
Uninstall-SPSolution
Remove-SPSolution
Install-SPSolution
Remove-SPSolutionDeploymentLock


Get-SPUserSolution
See Also Example
[image]

Published: May 12, 2010

Returns a specified sandboxed solution.

Get-SPUserSolution [[-Identity] <SPUserSolutionPipeBind>] -Site <SPSitePipeBind> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPUserSolutionPipeBind

Specifies the sandboxed solution to get.

The type must be a valid name of a user solution (for example, UserSolution1); or an instance of a valid SPUserSolution object.

Site

Required

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Specifies the site collection that contains the sandboxed solution.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid URL, in the form http://server_name; or an instance of a valid SPSite object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPUserSolution cmdlet returns a specified sandboxed solution. If the Identity parameter is not specified, this cmdlet returns the collection of sandboxed solutions in the site collection. A user solution is a sandboxed solution.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

-----------------EXAMPLE---------------------

Copy Code
Get-SPUserSolution -Site http://sitename

This example displays information about sandboxed solutions in the site http://sitename.

See Also

Reference

Update-SPUserSolution
Install-SPUserSolution
Uninstall-SPUserSolution
Remove-SPUserSolution
Add-SPUserSolution


Install-SPFeature
See Also Example
[image]

Published: May 12, 2010

Installs a SharePoint Feature by using the Feature.xml file.

Install-SPFeature [-Path] <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-WhatIf [<SwitchParameter>]]
Install-SPFeature -AllExistingFeatures <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-SolutionId <String>] [-WhatIf [<SwitchParameter>]]
Install-SPFeature -ScanForFeatures <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-SolutionId <String>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Path

Required

System.String

Specifies a valid file path; for example, MyFeature.

Path to feature must be a literal path to the 14\Template\Features directory. Can be any standard character that the Windows system supports for a file name. The feature.xml filename is implied and does not need to be provided.

If the feature file is not found on disk, the following error message is displayed: "Failed to find the XML file at location 14\Template\Features\<file path>."

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Forces the installation of an already installed feature.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

AllExistingFeatures

Required

System.Management.Automation.SwitchParameter

Scans for existing, but unregistered features, and then registers them with the farm.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Forces the installation of an already installed feature.

SolutionId

Optional

System.String

Specifies the solution id of the features. If the SolutionId parameter is not provided, all solution ids are scanned.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

3

Parameter

Required

Type

Description

ScanForFeatures

Required

System.Management.Automation.SwitchParameter

Scans and then displays a feature. The ScanForFeatures parameter does not install a feature.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Forces the installation of an already installed feature.

SolutionId

Optional

System.String

Specifies the solution id of the features. If the SolutionId parameter is not provided, all solution ids are scanned.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Install-SPFeature cmdlet installs a specific SPFeature object by providing in the Identity parameter the relative path from the folder "$env:ProgramFiles\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES\ to the feature. The SharePoint Feature's files must already be put in the proper directory, either manually or by using a solution installer.

If the AllExistingFeatures parameter is provided, the file system is scanned and any new features are installed. This is generally only used during deployment and upgrade.

Input Types

Return Types

Example

--------------EXAMPLE 1-----------------

Copy Code
Install-SPFeature -path "MyCustomFeature"

This example installs a new feature at $env:ProgramFiles\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES\MyCustomFeature/feature.xml.

--------------EXAMPLE 2-----------------

Copy Code
Install-SPFeature -AllExistingFeatures -Whatif

This example shows the unregistered features, available on the file system, that are installed if this command is run without the WhatIf parameter. This is commonly done after an upgrade process.

See Also

Reference

Get-SPFeature
Enable-SPFeature
Disable-SPFeature
Uninstall-SPFeature


Install-SPSolution
See Also Example
[image]

Published: May 12, 2010

Deploys an installed SharePoint solution in the farm.

Install-SPSolution [-Identity] <SPSolutionPipeBind> [-AllWebApplications <SwitchParameter>] [-AssignmentCollection <SPAssignmentCollection>] [-CASPolicies <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-GACDeployment <SwitchParameter>] [-Language <UInt32>] [-Local <SwitchParameter>] [-Time <String>] [-WebApplication <SPWebApplicationPipeBind>] [-WhatIf [<SwitchParameter>]]
Install-SPSolution [[-Identity] <SPSolutionPipeBind>] -Synchronize <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Language <UInt32>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSolutionPipeBind

Specifies the SharePoint solution to deploy.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SharePoint solution (for example, SPSolution1); or an instance of a valid SPSolution object.

AllWebApplications

Optional

System.Management.Automation.SwitchParameter

Specifies that the new SharePoint solution is deployed for all SharePoint Web applications in the farm.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

CASPolicies

Optional

System.Management.Automation.SwitchParameter

Specifies that code access security (CAS) policies can be deployed for the new SharePoint solution.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Forces the deployment of the new SharePoint solution.

GACDeployment

Optional

System.Management.Automation.SwitchParameter

Specifies that global assembly cache (GAC) can be deployed for the new SharePoint solution.

Language

Optional

System.UInt32

Specifies a language for the solution when a solution language package is deployed. If this parameter is not specified, zero ("0") is assumed. Use zero for solutions that are valid for all languages.

Local

Optional

System.Management.Automation.SwitchParameter

Deploys the solution on the active server computer.

Time

Optional

System.String

Specifies when the solution will be deployed. The default value is immediate deployment.

The type must be a valid DateTime value, in the form 2010, 5, 1.

WebApplication

Optional

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Deploys the SharePoint solution for the specified SharePoint Web application.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of SharePoint Web application (for example, MyOfficeApp1); or an instance of a valid SPWebApplication object.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSolutionPipeBind

Specifies the SharePoint solution to deploy.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SharePoint solution (for example, SPSolution1); or an instance of a valid SPSolution object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Language

Optional

System.UInt32

Specifies a language for the solution when a solution language package is deployed. If this parameter is not specified, zero ("0") is assumed. Use zero for solutions that are valid for all languages.

Synchronize

Optional

System.Management.Automation.SwitchParameter

Synchronizes all solutions or the specified solution in the local farm.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Install-SPSolution cmdlet deploys an installed SharePoint solution in the farm. Use the Add-SPSolution cmdlet to install a SharePoint solution package io the farm.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE------------------

Copy Code
Install-SPSolution -Identity contoso_solution.wsp -GACDeployment

This example deploys the installed SharePoint solution contoso_solution.wsp in the farm and specifies that GAC can be deployed for the new SharePoint solution.

See Also

Reference

Get-SPSolution
Add-SPSolution
Update-SPSolution
Uninstall-SPSolution
Remove-SPSolution
Remove-SPSolutionDeploymentLock


Install-SPUserSolution
See Also Example
[image]

Published: May 12, 2010

Activates a sandboxed solution in a site collection.

Install-SPUserSolution [-Identity] <SPUserSolutionPipeBind> -Site <SPSitePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPUserSolutionPipeBind

Specifies the sandboxed solution to activate.

The type must be a valid name of a sandboxed solution (for example, UserSolution1); or an instance of a valid SPUserSolution object.

Site

Required

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Activates the sandboxed solution for the specified site collection.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid URL, in the form http://server_name; or an instance of a valid SPSite object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Install-SPUserSolution cmdlet activates a sandboxed solution in a site collection. A user solution is a sandboxed solution.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

-------------------EXAMPLE---------------------

Copy Code
Install-SPUserSolution -Identity contoso_solution.wsp -Site http://sitename

This example activates the sandboxed solution contoso_solution.wsp in the site http://sitename.

See Also

Reference

Update-SPUserSolution
Uninstall-SPUserSolution
Remove-SPUserSolution
Get-SPUserSolution
Add-SPUserSolution


New-SPSiteSubscriptionFeaturePack
See Also Example
[image]

Published: May 12, 2010

Creates a new SharePoint Feature set that can be used to limit the features available to a site subscription.

New-SPSiteSubscriptionFeaturePack [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

Use the New- SPSiteSubscriptionFeaturePack cmdlet to create a new SharePoint Feature set that limits the Features available to a specified site subscription.

SharePoint Feature sets are on an Allow List of SharePoint Features that can be associated with any site subscription. If a Feature set is assigned to a site subscription, only SPFeatures objects in that Feature set are available for use on the site collections and Webs that are members of the site subscription. Feature sets contain a list of the GUIDs of each Feature that is on an Allow List for associated site subscriptions.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
$fs = New- SPSiteSubscriptionFeaturePack

This example creates a new SharePoint Feature set and stores it in a variable.

See Also

Reference

Get-SPSiteSubscriptionFeaturePack
Add-SPSiteSubscriptionFeaturePackMember
New-SPSiteSubscriptionFeaturePack
Add-SPSiteSubscriptionFeaturePackMember


Remove-SPSiteSubscriptionFeaturePack
See Also Example
[image]

Published: May 12, 2010

Removes a SharePoint Feature set from a site subscription.

Remove-SPSiteSubscriptionFeaturePack [-Identity] <SPSiteSubscriptionFeaturePackPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPFeatureSetPipeBind

Specifies the Feature set object to delete.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of a feature set (for example, FeatureSet1); or an instance of a valid SPFeatureSet object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove- SPSiteSubscriptionFeaturePack cmdlet removes a SharePoint Feature set by specifying the GUID or Feature set object.

Input Types

Return Types

Example

-----------------EXAMPLE------------------------

Copy Code
Remove-SPFeatureSet -Identity "30daa535-b0fe-4d10-84b0-fb04029d161a"

This example removes a SharePoint Feature set that has the ID 30daa535-b0fe-4d10-84b0-fb04029d161a.

See Also

Reference

Get-SPSiteSubscriptionFeaturePack
New-SPSiteSubscriptionFeaturePack
Remove-SPSiteSubscriptionFeaturePack
Add-SPSiteSubscriptionFeaturePackMember


Remove-SPSiteSubscriptionFeaturePackMember
See Also Example
[image]

Published: May 12, 2010

Removes a feature definition from the provided SharePoint Feature set.

Remove-SPSiteSubscriptionFeaturePackMember [-Identity] <SPSiteSubscriptionFeaturePackPipeBind> -FeatureDefinition <SPFeatureDefinitionPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]
Remove-SPSiteSubscriptionFeaturePackMember [-Identity] <SPSiteSubscriptionFeaturePackPipeBind> -AllFeatureDefinitions <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPFeatureSetPipeBind

Specifies the Feature set from which to remove a feature.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of a feature set (for example, FeatureSet1); or an instance of a valid SPFeatureSet object.

FeatureDefinition

Required

Microsoft.SharePoint.PowerShell.SPFeatureDefinitionPipeBind

Specifies the feature definition to be removed.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPFeatureSetPipeBind

Specifies the Feature set from which to remove a feature.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of a feature set (for example, FeatureSet1); or an instance of a valid SPFeatureSet object.

AllFeatureDefinitions

Required

System.Management.Automation.SwitchParameter

Clears all features from the Feature set.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Remove-SPSiteSubscriptionFeaturePackMember cmdlet removes the provided FeatureDefintion parameter from the feature set specified by the Identity parameter. If the AllFeatureDefinitions flag is provided, all feature definitions are removed from the given Feature set.

Input Types

Return Types

Example

------------------EXAMPLE 1-----------------------

Copy Code
$FS = Get-SPSiteSubscriptionFeaturePack "30daa535-b0fe-4d10-84b0-fb04029d161a"
Copy Code
Remove-SPSiteSubscriptionFeaturePackMember -Identity $fs -FeatureDefinition (Get-SPFeature "PublishingSite")

This example removes the PublishingSite feature from the Feature set that has ID 30daa535-b0fe-4d10-84b0-fb04029d161a.

------------------EXAMPLE 2-----------------------

Copy Code
Get-SPSiteSubscriptionFeaturePack "30daa535-b0fe-4d10-84b0-fb04029d161a" | Remove-SPSiteSubscriptionFeaturePackMember -AllFeatureDefinitions

This example removes all features from the Feature set 30daa535-b0fe-4d10-84b0-fb04029d161a.

See Also

Reference

Add-SPSiteSubscriptionFeaturePackMember
Get-SPSiteSubscriptionFeaturePack
Remove-SPSiteSubscriptionFeaturePack


Remove-SPSolution
See Also Example
[image]

Published: May 12, 2010

Removes a SharePoint solution from a farm.

Remove-SPSolution [-Identity] <SPSolutionPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-Language <UInt32>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSolutionPipeBind

Specifies the SharePoint solution to remove.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SharePoint solution (for example, SPSolution1); or an instance of a valid SPSolution object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Forces the removal of the SharePoint solution. You can use this parameter to remove SharePoint solutions that have been added to the server, even if they have not been deployed by using the Install-SPSolution cmdlet.

Language

Optional

System.UInt32

Removes the language pack for the specified language.

The type must be a valid language identifier; for example, 1033.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPSolution cmdlet deletes a SharePoint solution from a farm. Before you use this cmdlet, you must use the Uninstall-SPSolution cmdlet to retract the solution files from the front-end Web server.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE------------------

Copy Code
Remove-SPSolution -Identity contoso_solution.wsp

This example removes the SharePoint solution contoso_solution.wsp.

See Also

Reference

Get-SPSolution
Add-SPSolution
Update-SPSolution
Uninstall-SPSolution
Install-SPSolution


Remove-SPUserSolution
See Also Example
[image]

Published: May 12, 2010

Removes a sandboxed solution from the solution gallery.

Remove-SPUserSolution [-Identity] <String> -Site <SPSitePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPUserSolutionPipeBind

Specifies the sandboxed solution to remove.

The type must be a valid name of a sandboxed solution (for example, UserSolution1); or an instance of a valid SPUserSolution object.

Site

Required

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Remove the sandboxed solution from the specified site collection.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid URL, in the form http://server_name; or an instance of a valid SPSite object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPUserSolution cmdlet completely removes a sandboxed solution from the solution gallery. Before you can remove the sandboxed solution from the solution gallery, you must deactivate it by using the Uninstall-SPUserSolution cmdlet.

Input Types

Return Types

Example

----------------EXAMPLE----------------------

Copy Code
Remove-SPUserSolution -Identity contoso_solution.wsp -Site http://sitename

This example removes the sandboxed solution contoso_solution.wsp from the site http://sitename.

See Also

Reference

Update-SPUserSolution
Install-SPUserSolution
Uninstall-SPUserSolution
Get-SPUserSolution
Add-SPUserSolution


Remove-SPSolutionDeploymentLock
See Also Example
[image]

Published: May 12, 2010

Removes the solution deployment lock for a server.

Remove-SPSolutionDeploymentLock [[-Identity] <SPServerPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPServerPipeBind

Specifies the server for which the solution deployment lock is to be removed.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; the IP address of a server computer, in the form 208.77.188.166; a valid name of a SQL Server host service (for example, SQLServerHost1); or an instance of a valid SPServer object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPSolutionDeploymentLock cmdlet removes the solution deployment lock for a server. If the Identity parameter is not specified, this cmdlet removes the solution deployment lock for all servers in the farm.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE------------------

Copy Code
Remove-SPSolutionDeploymentLock

This example removes the solution deployment lock for all servers in the farm.

See Also

Reference

Remove-SPSolution
Get-SPSolution
Add-SPSolution
Update-SPSolution
Uninstall-SPSolution
Install-SPSolution


Uninstall-SPFeature
See Also Example
[image]

Published: May 12, 2010

Uninstalls an installed feature definition.

Uninstall-SPFeature [-Identity] <SPFeatureDefinitionPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Parameter

Microsoft.SharePoint.PowerShell.SPFeatureDefinitionPipeBind

Specifies the name of the feature or GUID to uninstall.

The type must be the name of the feature folder located in the <drive>:\program files\common files\Microsoft Shared\Web server extensions\14\template\features folder, or must be a GUID, in the form 21d186e1-7036-4092-a825-0eb6709e9281.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

No

System.Management.Automation.SwitchParameter

Forces the uninstallation of a feature that is already installed.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Uninstall-SPFeature cmdlet removes the specified feature definition from the collection of feature definitions in the farm.

Input Types

Return Types

none

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE-----------------------

Copy Code
Uninstall-SPFeature -path "MyCustomFeature"

This example uninstalls the feature at $env:ProgramFiles\Common Files\Microsoft Shared Debug\Web Server Extensions\14\TEMPLATE\FEATURES\MyCustomFeature/feature.xml.

See Also

Reference

Get-SPFeature
Enable-SPFeature
Disable-SPFeature
Install-SPFeature


Uninstall-SPUserSolution
See Also Example
[image]

Published: May 12, 2010

Deactivates a sandboxed solution in a site collection.

Uninstall-SPUserSolution [-Identity] <SPUserSolutionPipeBind> -Site <SPSitePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPUserSolutionPipeBind

Specifies the sandboxed solution to deactivate.

The type must be a valid name of a sandboxed solution (for example, UserSolution1); or an instance of a valid SPUserSolution object.

Site

Required

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Deactivates the sandboxed solution for the specified site collection.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid URL, in the form http://server_name; or an instance of a valid SPSite object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Uninstall-SPUserSolution cmdlet deactivates a sandboxed solution in a site collection so that you can delete it by using the Remove-SPUserSolution cmdlet. A user solution is a sandboxed solution.

Input Types

Return Types

Example

------------------EXAMPLE---------------

Copy Code
Uninstall-SPUserSolution -Identity contoso_solution.wsp -Site http://sitename

This example deactivates the sandboxed solution contoso_solution.wsp on the site http://sitename.

See Also

Reference

Update-SPUserSolution
Install-SPUserSolution
Remove-SPUserSolution
Get-SPUserSolution
Add-SPUserSolution


Uninstall-SPSolution
See Also Example
[image]

Published: May 12, 2010

Retracts a deployed SharePoint solution.

Uninstall-SPSolution [-Identity] <SPSolutionPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Language <UInt32>] [-Local <SwitchParameter>] [-Time <String>] [-WhatIf [<SwitchParameter>]]
Uninstall-SPSolution [-Identity] <SPSolutionPipeBind> -WebApplication <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Language <UInt32>] [-Local <SwitchParameter>] [-Time <String>] [-WhatIf [<SwitchParameter>]]
Uninstall-SPSolution [-Identity] <SPSolutionPipeBind> -AllWebApplications <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Language <UInt32>] [-Local <SwitchParameter>] [-Time <String>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSolutionPipeBind

Specifies the SharePoint solution to uninstall.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SharePoint solution (for example, SPSolution1); or an instance of a valid SPSolution object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Language

Optional

System.UInt32

Uninstalls the language pack for the specified language.

The type must be a valid language identifier; for example, 1033.

Local

Optional

System.Management.Automation.SwitchParameter

Uninstalls the solution from the active server computer.

Time

Optional

System.String

Specifies when the solution will be uninstalled. The default value is immediate retraction.

The type must be a valid DateTime value, in the form 2010,12,05.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSolutionPipeBind

Specifies the SharePoint solution to uninstall.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SharePoint solution (for example, SPSolution1); or an instance of a valid SPSolution object.

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Uninstalls the SharePoint solution for the specified SharePoint Web application.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of a SharePoint Web application (for example, MyOfficeApp1); or an instance of a valid SPWebApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Language

Optional

System.UInt32

Uninstalls the language pack for the specified language.

The type must be a valid language identifier; for example, 1033.

Local

Optional

System.Management.Automation.SwitchParameter

Uninstalls the solution from the active server computer.

Time

Optional

System.String

Specifies when the solution will be uninstalled. The default value is immediate retraction.

The type must be a valid DateTime value, in the form 2010,12,05.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

3

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSolutionPipeBind

Specifies the SharePoint solution to uninstall.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SharePoint solution (for example, SPSolution1); or an instance of a valid SPSolution object.

AllWebApplications

Required

System.Management.Automation.SwitchParameter

Specifies that the new SharePoint solution will be uninstalled for all SharePoint Web applications in the farm.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Language

Optional

System.UInt32

Uninstalls the language pack for the specified language.

The type must be a valid language identifier; for example, 1033.

Local

Optional

System.Management.Automation.SwitchParameter

Uninstalls the solution from the active server computer.

Time

Optional

System.String

Specifies when the solution will be uninstalled. The default value is immediate retraction.

The type must be a valid DateTime value, in the form 2010,12,05.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Uninstall-SPSolution cmdlet retracts a deployed SharePoint solution in preparation for removing it from the farm entirely. This cmdlet removes files from the front-end Web server. Use the Remove-SPSolution cmdlet to delete the solution package from the solution store of the farm; be sure to use the Remove-SPSolution cmdlet only after you have run Uninstall-SPSolution.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Uninstall-SPUserSolution -Identity contoso_solution.wsp

This example retracts the deployed SharePoint solution contoso_solution.wsp.

See Also

Reference

Get-SPSolution
Add-SPSolution
Update-SPSolution
Remove-SPSolution
Install-SPSolution
Remove-SPSolutionDeploymentLock


Update-SPSolution
See Also Example
[image]

Published: May 12, 2010

Upgrades a deployed SharePoint solution.

Update-SPSolution [-Identity] <SPSolutionPipeBind> -LiteralPath <String> [-AssignmentCollection <SPAssignmentCollection>] [-CASPolicies <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-GACDeployment <SwitchParameter>] [-Local <SwitchParameter>] [-Time <String>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSolutionPipeBind

Specifies the SharePoint solution to deploy.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SharePoint solution (for example, SPSolution1); or an instance of a valid SPSolution object.

LiteralPath

Required

System.String

Specifies the path to the solution package.

The type must be a valid path in either of the following forms:

- C:\folder_name

- \\server_name\folder_name

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

CASPolicies

Optional

System.Management.Automation.SwitchParameter

Specifies that Code Access Security (CAS) policies can be deployed for the new SharePoint solution.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Forces the deployment of the new SharePoint solution.

GACDeployment

Optional

System.Management.Automation.SwitchParameter

Specifies that the new SharePoint solution can be deployed to the global assembly cache (GAC).

Local

Optional

System.Management.Automation.SwitchParameter

Deploys the solution on the local computer only.

Time

Optional

System.String

Specifies when the solution will be deployed. The default value is immediate deployment.

The type must be a valid DateTime value, in the form 2010, 5, 1.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Update-SPSolution cmdlet upgrades a deployed SharePoint solution in the farm. Use this cmdlet only if a new solution contains the same set of files and features as the deployed solution. If files and features are different, the solution must be retracted and redeployed by using the Uninstall-SPSolution and Install-SPSolution cmdlets, respectively.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Update-SPSolution -Identity contoso_solution.wsp -LiteralPath c:\contoso_solution_v2.wsp -GACDeployment

This example upgrades the deployed SharePoint solution contoso_solution.wsp to the solution c:\contoso_solution_v2.wsp.

See Also

Reference

Get-SPSolution
Add-SPSolution
Uninstall-SPSolution
Remove-SPSolution
Install-SPSolution
Remove-SPSolutionDeploymentLock


Update-SPUserSolution
See Also Example
[image]

Published: May 12, 2010

Upgrades an activated sandboxed solution in a farm.

Update-SPUserSolution [-Identity] <SPUserSolutionPipeBind> -Site <SPSitePipeBind> -ToSolution <SPUserSolutionPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPUserSolutionPipeBind

Specifies the sandboxed solution to upgrade.

The type must be a valid name of a sandboxed solution (for example, UserSolution1); or an instance of a valid SPUserSolution object.

Site

Required

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Upgrade the sandboxed solution for the specified site collection.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid URL, in the form http://server_name; or an instance of a valid SPSite object.

ToSolution

Required

Microsoft.SharePoint.PowerShell.SPUserSolutionPipeBind

Specifies the sandboxed solution you want to upgrade to.

The type must be a valid name of a sandboxed solution (for example, UserSolution1); or an instance of a valid SPUserSolution object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Update-SPUserSolution cmdlet upgrades a sandboxed solution that has already been activated in a specified site collection. A user solution is a sandboxed solution. Before you use this cmdlet to upgrade the activated solution, use the Add-SPUserSolution cmdlet to upload the upgraded solution to the solution gallery.

Input Types

Return Types

Example

------------------EXAMPLE---------------------

Copy Code
Update-SPUserSolution -Identity contoso_solution.wsp -Site http://sitename -ToSolution contoso_solution_v2.wsp

This example upgrades the sandboxed solution contoso_solution.wsp in the site http://sitename to the sandboxed solution contoso_solution_v2.wsp.

See Also

Reference

Install-SPUserSolution
Uninstall-SPUserSolution
Remove-SPUserSolution
Get-SPUserSolution
Add-SPUserSolution


General cmdlets (SharePoint Foundation 2010)
See Also

You can use Windows PowerShell cmdlets for general administration of a Microsoft SharePoint Foundation 2010 farm.

Cmdlet name | Description
Get-SPBrowserCustomerExperienceImprovementProgram | Returns the current opt-in state for the browser Customer Experience Improvement Program.
Get-SPHelpCollection | Returns Help collection files.
Install-SPHelpCollection | Installs the provided Help site collection files in the current farm.
Set-SPBrowserCustomerExperienceImprovementProgram | Turns on or off the browser Customer Experience Improvement Program.
Start-SPAssignment | Initiates a new assignment store.
Stop-SPAssignment | Disposes of objects in the provided assignment collection.
Uninstall-SPHelpCollection | Removes Help collection files.
Update-SPInfoPathUserFileUrl | Runs a Microsoft InfoPath 2010 .xsn/.udc fix-up on SharePoint Foundation 2010

See Also

Other Resources

Resource Center: Windows PowerShell for SharePoint Foundation 2010


Get-SPBrowserCustomerExperienceImprovementProgram
See Also Example
[image]

Published: May 12, 2010

Returns the current opt-in state for the browser Customer Experience Improvement Program.

Get-SPBrowserCustomerExperienceImprovementProgram -Farm <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>]
Get-SPBrowserCustomerExperienceImprovementProgram -WebApplication <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>]
Get-SPBrowserCustomerExperienceImprovementProgram -SiteSubscription <SPSiteSubscriptionPipeBind> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

1

Parameter

Required

Type

Description

Farm

Required

System.Management.Automation.SwitchParameter

Specifies that the opt-in state for the farm is returned by this cmdlet.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

2

Parameter

Required

Type

Description

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Returns the opt-in state for the specified SharePoint Web application.

The type must be a valid URL, in the form http://server_name; a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of SharePoint Web application (for example, MyOfficeApp1); or an instance of a valid SPWebApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

3

Parameter

Required

Type

Description

SiteSubscription

Required

Microsoft.SharePoint.PowerShell.SPSiteSubscriptionPipeBind

Returns the opt-in state for the specified site subscription.

The type must be a valid URL, in the form http://server_name; a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a site subscription (for example, SiteSubscription1); or an instance of a valid SiteSubscription object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Get-SPBrowserCustomerExperienceImprovementProgram cmdlet reads the current opt-in state for the browser Customer Experience Improvement Program.

Input Types

Return Types

Example

------------------EXAMPLE 1-----------------------

Copy Code
Get-SPBrowserCustomerExperienceImprovementProgram -WebApplication http://WebAppexample1

This example returns the current Customer Experience Improvement Program opt-in state for the Web application, WebAppexample1.

------------------EXAMPLE 2-----------------------

Copy Code
Get-SPSiteSubscription http://SiteSubscription1 | Get- SPBrowserCustomerExperienceImprovementProgram

The following example returns the Customer Experience Improvement Program opt-in state for the site subscription, SiteSubscription1.

See Also

Reference

Set-SPBrowserCustomerExperienceImprovementProgram


Get-SPHelpCollection
See Also Example
[image]

Published: May 12, 2010

Returns Help collection files.

Get-SPHelpCollection [-AssignmentCollection <SPAssignmentCollection>] [-Name <String>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Name

Optional

System.String

Specifies the name of the Help collection files to get.

The type must be a valid name of a Help collection folder; for example, HelpDocs1.

Detailed Description

The Get-SPHelpCollection cmdlet reads the specified Help collection files. If the Name parameter is not specified, this cmdlet returns all installed Help collection files.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE------------------

Copy Code
Get-SPHelpCollection

This example gets all installed Help collection files.

See Also

Reference

Install-SPHelpCollection
Uninstall-SPHelpCollection


Install-SPHelpCollection
See Also Example
[image]

Published: May 12, 2010

Installs the provided Help site collection files in the current farm.

Install-SPHelpCollection -LiteralPath <String> [-AssignmentCollection <SPAssignmentCollection>]
Install-SPHelpCollection -All <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

1

Parameter

Required

Type

Description

LiteralPath

Optional

System.String

Specifies the exact path to a specific custom Help file in the Help site collection cab file.

The type must be a valid path in either of the following forms:

- C:\folder_name

- \\server_name\folder_name

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

2

Parameter

Required

Type

Description

All

Required

System.Management.Automation.SwitchParameter

If the LiteralPath parameter is not specified, specifies that all Help Collection CABs under %Program Files%\Common Files\Microsoft Shared\Web Server Extensions\14\HCCab\<LCID> in the Help site collection are installed, and existing Help collections are overwritten.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Install-SPHelpCollection cmdlet installs the Help site collection files for SharePoint 2010 Products in the current farm. Use the LiteralPath parameter to install specific custom Help collection files. If the LiteralPath parameter is not specified, all available Help in the Help site collection is installed and existing Help collection files are overwritten.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Install-SPHelpCollection -LiteralPath 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\HCCab\1033\OSSAdmin.cab'

This example installs the specified help collection in the current farm.

See Also

Reference

Get-SPHelpCollection
Uninstall-SPHelpCollection


Set-SPBrowserCustomerExperienceImprovementProgram
See Also Example
[image]

Published: May 12, 2010

Turns on or off the browser Customer Experience Improvement Program.

Set-SPBrowserCustomerExperienceImprovementProgram -Farm <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Enable <SwitchParameter>] [-WhatIf [<SwitchParameter>]]
Set-SPBrowserCustomerExperienceImprovementProgram -WebApplication <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Enable <SwitchParameter>] [-WhatIf [<SwitchParameter>]]
Set-SPBrowserCustomerExperienceImprovementProgram -SiteSubscription <SPSiteSubscriptionPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Enable <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Farm

Required

System.Management.Automation.SwitchParameter

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Enable

Optional

System.Management.Automation.SwitchParameter

Turns on the browser Customer Experience Improvement Program. The default value is True.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Sets the Customer Experience Improvement Program opt-in state for the specified SharePoint Web application.

The type must be a valid URL, in the form http://server_name; a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of SharePoint Web application (for example, MyOfficeApp1); or an instance of a valid SPWebApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Enable

Optional

System.Management.Automation.SwitchParameter

Turns on the browser Customer Experience Improvement Program. The default value is True.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

3

Parameter

Required

Type

Description

SiteSubscription

Required

Microsoft.SharePoint.PowerShell.SPSiteSubscriptionPipeBind

Sets the Customer Experience Improvement Program opt-in state for the specified site subscription.

The type must be a valid URL, in the form http://server_name; a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a site subscription (for example, SiteSubscription1); or an instance of a valid SiteSubscription object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Enable

Optional

System.Management.Automation.SwitchParameter

Turns on the browser Customer Experience Improvement Program. The default value is True.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Set-SPBrowserCustomerExperienceImprovementProgram cmdlet turns on or off the browser Customer Experience Improvement Program for collecting software quality metrics.

Input Types

Return Types

Example

------------------EXAMPLE 1-----------------------

Copy Code
Set-SPBrowserCustomerExperienceImprovementProgram -Farm -Enable

This example turns on the browser Customer Experience Improvement Program for the farm.

------------------EXAMPLE 2-----------------------

Copy Code
Set-SPBrowserCustomerExperienceImprovementProgram -Farm -Enable:$False

This example turns off the browser Customer Experience Improvement Program for the farm.

------------------EXAMPLE 3-----------------------

Copy Code
Set-SPWebApplication http://MyOfficeApp1 | Get- SPBrowserCustomerExperienceImprovementProgram -Enable

This example turns on the browser Customer Experience Improvement Program for the Web application, MyOfficeApp1.

See Also

Reference

Get-SPBrowserCustomerExperienceImprovementProgram


Start-SPAssignment
See Also Example
[image]

Published: May 12, 2010

Initiates a new assignment store.

Start-SPAssignment [-AssignmentCollection <SPAssignmentCollection>] [-Global <SwitchParameter>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Global

Optional

System.Management.Automation.SwitchParameter

If you use this parameter, all objects are assigned to the lifetime of the script and are disposed of when the Stop-SPAssignment cmdlet is called.

If you do not use this parameter, you must assign the output of this cmdlet to a variable and then dispose of objects by using the Identity parameter of the Stop-SPAssignment cmdlet.

Detailed Description

The Start-SPAssignment cmdlet properly disposes of objects used with variable assignments.

Large amounts of memory are often required when SPWeb, SPSite, or SPSiteAdminsitration objects are used. So the use of these objects, or lists of these objects, in Windows PowerShell scripts requires proper memory management. By default, all Get commands dispose of these objects immediately after the pipeline finishes, but by using SPAssignment, you can assign the list of objects to a variable and dispose of the objects after they are no longer needed. You can also ensure that the objects remain as long as you need them, even throughout multiple iterations of commands.

There are three levels of assignment:

-- No assignment — The object is not assigned to a variable and is disposed of after each iteration of the command.

-- Simple assignment — All objects are assigned to the global assignment store. This is done by using the Global parameter. When using this level, all objects are assigned to a global store and are disposed of when the Stop-SPAssignment cmdlet is called.

-- Advanced assignment — Objects are assigned to named stores for disposal. You can dispose of objects by using the Identity parameter with the Stop-SPAssignment cmdlet.

Note:

Regardless of the assignment level used, all objects are disposed of when the Windows PowerShell run space is closed.

Input Types

Return Types

SPAssignmentCollection

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE 1-----------------------

Copy Code
Start-SPAssignment -global
Copy Code
$w = Get-SPWeb http://MyWeb
Copy Code
$w | Set-SPWeb -title "Accounting"
Copy Code
Stop-SPAssignment -global

This example uses simple assignment. Although it is easier to use simple assignment, it is not a good idea to run commands that iterate through multiple SPSite or SPWeb objects while simple assignment is enabled. Ensure that you run Stop-SPAssignment before you attempt any iterations of multiple objects.

------------------EXAMPLE 2-----------------------

Copy Code
$gc = Start-SPAssignment
Copy Code
$web = $gc | Get-SPWeb http://MyWeb
Copy Code
$web | Set-SPWeb -title "Accounting"
Copy Code
Stop-SPAssignment -Identity $gc

This example sets the title of the SPWeb object in multiple lines and controls the rate of disposal. This is an advanced example. Only developers are advised to use it.

See Also

Reference

Stop-SPAssignment


Stop-SPAssignment
See Also Example
[image]

Published: May 12, 2010

Disposes of objects in the provided assignment collection.

Stop-SPAssignment [[-SemiGlobal] <SPAssignmentCollection>] [-AssignmentCollection <SPAssignmentCollection>] [-Global <SwitchParameter>]

Parameters

Parameter Required Type Description

SemiGlobal

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentColletion

Provides the assignment collector from which to dispose of objects.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Global

Optional

System.Management.Automation.SwitchParameter

Stops the global assignment collector from storing objects, and disposes of any objects contained by the global assignment collector.

Detailed Description

The Stop-SPAssignment cmdlet disposes of objects in the provided assignment collection. Use the Global parameter to dispose of all objects in the global assignment collector and to stop the global store from collecting additional objects. Provide a SemiGlobal assignment collector to dispose of all contained objects.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE------------------

Copy Code
Start-SPAssignment -global
Copy Code
$w = Get-SPWeb http://MyWeb
Copy Code
$w | Set-SPWeb -title "Accounting"
Copy Code
Stop-SPAssignment -global

This example uses simple assignment. While easier to use simple assignment, running commands that iterate through multiple SPSite or SPWeb objects while simple assignment is enabled is not recommended. Ensure that Stop-SPAssignment is run before attempting any iterations of multiple objects.

See Also

Reference

Start-SPAssignment


Uninstall-SPHelpCollection
See Also Example
[image]

Published: May 12, 2010

Removes Help collection files.

Uninstall-SPHelpCollection -Name <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Name

Required

System.String

Specifies the name of the Help collection files to uninstall.

The type must be a valid name of a Help collection; for example, HelpDocs1.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Uninstall-SPHelpCollection cmdlet removes the specified Help collection files from the product Help library in the current farm.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Uninstall-SPHelpCollection - Name "OSSAdmin.1033"

This example uninstalls a Help collection. The folder name of the Help collection to uninstall is OSSAdmin.1033.

See Also

Reference

Get-SPHelpCollection
Install-SPHelpCollection


Update-SPInfoPathUserFileUrl
Example
[image]

Published: May 12, 2010

Updates InfoPath form templates (.xsn files) and universal data connections (.udcx files).

Update-SPInfoPathUserFileUrl [-WebApplication] <SPWebApplicationPipeBind> -Find <Uri> -Replace <Uri> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Scan <SwitchParameter>] [-WhatIf [<SwitchParameter>]]
Update-SPInfoPathUserFileUrl [-ContentDatabase] <SPContentDatabasePipeBind> -Find <Uri> -Replace <Uri> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Scan <SwitchParameter>] [-WhatIf [<SwitchParameter>]]
Update-SPInfoPathUserFileUrl [-Site] <SPSitePipeBind> -Find <Uri> -Replace <Uri> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Scan <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the parent SharePoint Web application where the update will start.

The type must be a valid URL, in the form http://server_name; a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of SharePoint Web application (for example, MyOfficeApp1); or an instance of a valid SPWebApplication object

Find

Required

System.Uri

Specifies the URL to find.

The type must be a valid URL, in the form http://previous_server_name.

Replace

Required

System.Uri

Specifies the URL to find.

The type must be a valid URL, in the form http://server_name.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Scan

Optional

System.Management.Automation.SwitchParameter

Run the tool and log the actions that can be taken. No content is changed as a result of the scan.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

ContentDatabase

Required

Microsoft.SharePoint.PowerShell.SPContentDatabasePipeBind

Specifies the parent content database where the update will start.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a content database (for example, SPContent DB1); or an instance of a valid SPContentDatabase object.

Find

Required

System.Uri

Specifies the URL to find.

The type must be a valid URL, in the form http://previous_server_name.

Replace

Required

System.Uri

Specifies the URL to find.

The type must be a valid URL, in the form http://server_name.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Scan

Optional

System.Management.Automation.SwitchParameter

Run the tool and log the actions that can be taken. No content is changed as a result of the scan.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

3

Parameter

Required

Type

Description

Site

Required

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Specifies the parent site collection where the update will start.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid URL, in the form http://sites/example; or an instance of a valid SPSite object.

Find

Required

System.Uri

Specifies the URL to find.

The type must be a valid URL, in the form http://previous_server_name.

Replace

Required

System.Uri

Specifies the URL to find.

The type must be a valid URL, in the form http://server_name.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Scan

Optional

System.Management.Automation.SwitchParameter

Run the tool and log the actions that can be taken. No content is changed as a result of the scan.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Update-SPInfoPathAdminFileUrl cmdlet updates data connections in InfoPath form templates (.xsn files) and universal data connections (.udcx files). This allows for InfoPath data connections that reference the current farm to be updated when content is migrated to a different farm URL.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Get-SPWebApplication http://contoso2010 | Update-SPInfoPathUserFileUrl
-find "http://contoso2007"
-replace "http://contoso2010"

This example updates data connections in InfoPath form templates and universal data connection files, for all content under the Web application http://contoso2010. Data connections that reference http://contoso2007 are updated to reference http://contoso2010.


Health monitoring cmdlets (SharePoint Foundation 2010)

Published: March 31, 2011

You can use Windows PowerShell cmdlets to create and manage health analyzer rules in a Microsoft SharePoint Foundation 2010 farm.

The SPHealthAnalysisRule cmdlets were first introduced in the February 2011 Cumulative Update, which is available for download here: Description of the SharePoint Foundation 2010 Cumulative Update Server Hotfix Package (SharePoint Foundation server-package)

Cmdlet name | Description
Disable-SPHealthAnalysisRule | Disables a health analyzer rule.
Enable-SPHealthAnalysisRule | Enables a health analyzer rule.
Get-SPHealthAnalysisRule | Gets a health analyzer rule.


Disable-SPHealthAnalysisRule
See Also Example
[image]

Published: March 31, 2011

Disables health analyzer rules.

Disable-SPHealthAnalysisRule [-Identity] <SPHealthAnalysisRuleInstancePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPHealthAnalysisRuleInstancePipeBind

Specifies the name or GUID of the health analyzer rule to disable.

The type must be a valid name; an instance of a valid SPHealthAnalysisRule object, or a valid GUID (for example, 12345678-90ab-cdef-1234-567890bcdefgh).

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

Use the Disable-SPHealthAnalysisRule cmdlet to disable a health analyzer rule.

Note:

The SPHealthAnalysisRule cmdlets were first introduced in the February 2011 Cumulative Update, which is available for download as follows:

  • Description of the SharePoint Foundation 2010 Cumulative Update Server Hotfix Package (SharePoint Foundation server-package)

  • Description of the SharePoint Server 2010 Cumulative Update Server Hotfix Package (MOSS server-package

Input Types

Return Types

Example

---------------------EXAMPLE 1---------------------------

Copy Code
Disable-SPHealthAnalysisRule -Identity "CustomRule"

This example disables the health analyzer rule named CustomRule.

See Also

Reference

Enable-SPHealthAnalysisRule
Get-SPHealthAnalysisRule


Enable-SPHealthAnalysisRule
See Also Example
[image]

Published: March 31, 2011

Enables a health analyzer rule.

Enable-SPHealthAnalysisRule [-Identity] <SPHealthAnalysisRuleInstancePipeBind> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPHealthAnalysisRuleInstancePipeBind

Specifies the name or GUID of the health analyzer rule to enable.

The type must be a valid name, an instance of a valid SPHealthAnalysisRule object, or a valid GUID (for example, 12345678-90ab-cdef-1234-567890bcdefgh).

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

Use the Enable-SPHealthAnalysisRule cmdlet to enable a health analyzer rule.

Note:

The SPHealthAnalysisRule cmdlets were first introduced in the February 2011 Cumulative Update, which is available for download as follows:

  • Description of the SharePoint Foundation 2010 Cumulative Update Server Hotfix Package (SharePoint Foundation server-package)

  • Description of the SharePoint Server 2010 Cumulative Update Server Hotfix Package (MOSS server-package

Input Types

Return Types

Example

---------------------EXAMPLE 1---------------------------

Copy Code
Enable-SPHealthAnalysisRule -Identity "CustomRule"

This example enables the health analyzer rule named CustomRule.

See Also

Reference

Disable-SPHealthAnalysisRule
Get-SPHealthAnalysisRule


Get-SPHealthAnalysisRule
See Also Example
[image]

Published: March 31, 2011

Gets a health analyzer rule.

Get-SPHealthAnalysisRule [-AssignmentCollection <SPAssignmentCollection>]
Get-SPHealthAnalysisRule [-Identity] <SPHealthAnalysisRuleInstancePipeBind> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

1

Parameter

Required

Type

Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPHealthAnalysisRuleInstancePipeBind

Specifies the name or GUID of the health analyzer rule to get.

The type must be a valid name, an instance of a valid SPHealthAnalysisRule object, or a valid GUID (for example, 12345678-90ab-cdef-1234-567890bcdefgh).

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

Use the Get-SPHealthAnalysisRule cmdlet to return a list of a health analyzer rules. To return a specify health analyzer rule, use the Identity parameter; otherwise, all health analyzer rules will be returned.

The SPHealthAnalysisRule cmdlets were first introduced in the February 2011 Cumulative Update, which is available for download as follows:

  • Description of the SharePoint Foundation 2010 Cumulative Update Server Hotfix Package (SharePoint Foundation server-package)

  • Description of the SharePoint Server 2010 Cumulative Update Server Hotfix Package (MOSS server-package

Input Types

Return Types

Example

---------------------EXAMPLE 1---------------------------

Copy Code
Get-SPHealthAnalysisRule -Identity "CustomRule"

This example returns the health analyzer rule named CustomRule.

See Also

Reference

Disable-SPHealthAnalysisRule
Enable-SPHealthAnalysisRule


Import and export cmdlets (SharePoint Foundation 2010)
See Also

You can use Windows PowerShell to import or export a site collection, Web application, list, or library.

Cmdlet name | Description
Import-SPWeb | Imports a site collection, Web application, list, or library.
Export-SPWeb | Exports a site collection, Web application, list, or library.

See Also

Other Resources

Resource Center: Windows PowerShell for SharePoint Foundation 2010


Import-SPWeb
See Also Example
[image]

Published: May 12, 2010

Imports a web, list, or library.

Import-SPWeb [-Identity] <SPWebPipeBind> -Path <String> [-ActivateSolutions <SwitchParameter>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-HaltOnError <SwitchParameter>] [-HaltOnWarning <SwitchParameter>] [-IncludeUserCustomAction <None | All>] [-IncludeUserSecurity <SwitchParameter>] [-NoFileCompression <SwitchParameter>] [-NoLogFile <SwitchParameter>] [-UpdateVersions <Append | Overwrite | Ignore>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPWebPipeBind

Specifies the URL or GUID of the Web to import into.

The type must be a valid URL, GUID, or object; for example, a valid URL, in the form http://server_name, or a GUID, in the form, 1234-4567-5678a.

Path

Required

System.String

Specifies the name of the import file.

If the NoFileCompression parameter is used, a directory must be specified; otherwise, any file format is valid.

ActivateSolutions

Optional

System.Management.Automation.SwitchParameter

Specifies whether user solutions are activated during import.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Forcefully overwrites the export package if it already exists.

The type must be either of the following values

-True

-False

The default value is False.

HaltOnError

Optional

System.Management.Automation.SwitchParameter

Stops the import process when an error occurs.

HaltOnWarning

Optional

System.Management.Automation.SwitchParameter

Stops the import process when a warning occurs.

IncludeUserCustomAction

Optional

Microsoft.SharePoint.Deployment.SPIncludeUserCustomAction

Specifies whether User Custom Actions are included during import.

IncludeUserSecurity

Optional

System.Management.Automation.SwitchParameter

Preserves the user security settings except for SPLists that have broken inheritance and item level permissions set.

NoFileCompression

Optional

System.Management.Automation.SwitchParameter

Either enables or disables file compression in the import package. The import package is stored in the folder specified by the Path parameter or Identity parameter. We recommend that you use this parameter for performance reasons. If compression is enabled, the import process can increase by approximately 30 percent.

NoLogFile

Optional

System.Management.Automation.SwitchParameter

Suppresses the generation of an import log file. If this parameter is absent, the Import-SPWeb cmdlet will generate an export log file in the same location as the export package. The log file uses Unified Logging Service (ULS).

We recommend that you use this parameter. However, for performance reasons, you might not want to generate a log file.

UpdateVersions

No

Microsoft.SharePoint.Deployment.SPUpdateVersions

Indicates how to resolve situations where a file to be imported to a site already exists in that site. If the UpdateVersions parameter is absent, the import operation by default uses a value of 1.

The type must be any one of the following:

-Add new versions to the current file

-Overwrite the file and all of its versions (delete then insert)

-Ignore the file if it exists on the destination

The default value is Add new versions to the current file.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Import-SPWeb cmdlet imports a web, list, or library. The capability to import from a library is a new feature in SharePoint 2010 Products.

Input Types

Return Types

Example

---------------------EXAMPLE----------------------

Copy Code
Import-SPWeb http://site -Path export.cmp -UpdateVersions -Overwrite

This example imports the contents of export.cmp into a site at http://site, overwriting the versioned content on the site with the contents of the export.cmp file.

See Also

Reference

Export-SPWeb
Get-SPWeb
New-SPWeb
Remove-SPWeb
Set-SPWeb


Export-SPWeb
See Also Example
[image]

Published: May 12, 2010

Exports a site, list, or library.

Export-SPWeb [-Identity] <SPWebPipeBind> -Path <String> [-AssignmentCollection <SPAssignmentCollection>] [-CompressionSize <Int32>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-HaltOnError <SwitchParameter>] [-HaltOnWarning <SwitchParameter>] [-IncludeUserSecurity <SwitchParameter>] [-IncludeVersions <LastMajor | CurrentVersion | LastMajorAndMinor | All>] [-ItemUrl <String>] [-NoFileCompression <SwitchParameter>] [-NoLogFile <SwitchParameter>] [-UseSqlSnapshot <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPWebPipeBind

Specifies the URL or GUID of the Web to be exported.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SharePoint site (for example, MySPSite1); or an instance of a valid SPWeb object.

Path

Required

System.String

Specifies the name of the export file.

If the NoFileCompression parameter is used, a directory must be specified; otherwise, any file format is valid.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

CompressionSize

Optional

System.Int32

Sets the maximum file size for the compressed export files. If the total size of the exported package is greater than this size, the exported package will be split into multiple files.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Forcefully overwrites the export package if it already exists.

The type must be either of the following values:

-True

-False

The default value is False.

HaltOnError

Optional

System.Management.Automation.SwitchParameter

Stops the export process when an error occurs.

HaltOnWarning

Optional

System.Management.Automation.SwitchParameter

Stops the export process when a warning occurs.

IncludeUserSecurity

Optional

System.Management.Automation.SwitchParameter

Preserves the user security settings except for SPLists that have broken inheritance and item level permissions set.

IncludeVersions

Optional

Microsoft.SharePoint.Deployment.SPIncludeVersions

Indicates the type of file and list item version history to be included in the export operation. If the IncludeVersions parameter is absent, the Export-SPWeb cmdlet by default uses a value of 1.

The type must be any one of the following versions:

-Last major version for files and list items (default)

-The current version, either the last major version or the last minor version

-Last major and last minor version for files and list items

-All versions for files and list items

ItemUrl

Optional

System.string

Specifies the URL of the Web application, GUID, or object to be exported.

The type must be a valid URL; for example, http://server_name.

NoFileCompression

Optional

System.Management.Automation.SwitchParameter

Either enables or disables file compression in the export package. The export package is stored in the folder specified by the Path parameter or Identity parameter. We recommend that you use this parameter for performance reasons. If compression is enabled, the export process can increase by approximately 30 percent.

NoLogFile

Optional

System.Management.Automation.SwitchParameter

Suppresses the generation of an export log file. If this parameter is not specified, the Export-SPWeb cmdlet will generate an export log file in the same location as the export package. The log file uses Unified Logging Service (ULS).

It is recommended to use this parameter. However, for performance reasons, you might not want to generate a log file.

UseSqlSnapshot

Optional

System.Management.Automation.SwitchParameter

Specifies a SQL Database Snapshot will be created when the export process begins, and all exported data will be retrieved directly from the database snapshot. This snapshot will be automatically deleted when export completes.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Export-SPWeb cmdlet exports a site, list, or library. The capability to export from a library is a new feature in SharePoint 2010 Products.

Input Types

Return Types

Example

--------------------EXAMPLE-----------------------.

Copy Code
Export-SPWeb http://site -Path "site export.cmp"

This example exports the site at http://site/ to a file called site export.cmp in the current directory.

See Also

Reference

Get-SPWeb
New-SPWeb
Set-SPWeb
Import-SPWeb
Remove-SPWeb


Logging and events cmdlets (SharePoint Foundation 2010)
See Also

You can use Windows PowerShell cmdlets to log system events and perform diagnostics.

Cmdlet name | Description
Clear-SPLogLevel | Resets the Windows trace logging and event logging levels to their default values.
Get-SPLogLevel | Returns a list of objects or diagnostic levels.
Set-SPLogLevel | Sets the trace and event level for a set of categories.
Get-SPLogEvent | Returns results from a Unified Logging Service (ULS) trace log.
Get-SPDiagnosticConfig | Retrieves ULS diagnostic configuration values of the farm.
Get-SPDiagnosticsProvider | Returns a diagnostics provider.
Merge-SPLogFile | Combines trace log entries from all farm computers into a single log file on the local computer.
New-SPLogFile | Creates a new log file.
New-SPUsageLogFile | Starts a new usage log file on the current server computer.
Set-SPDiagnosticConfig | Sets diagnostic configuration settings on the farm.
Set-SPDiagnosticsProvider | Enables a diagnostics provider and updates its retention policy.

See Also

Other Resources

Resource Center: Windows PowerShell for SharePoint Foundation 2010


Clear-SPLogLevel
See Also Example
[image]

Published: May 12, 2010

Resets the Windows trace logging and event logging levels to their default values.

Clear-SPLogLevel [-AssignmentCollection <SPAssignmentCollection>] [-Identity <String[]>] [-InputObject <PSObject>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Identity

Optional

System.String[]

Specifies the name(s) of the category or set of categories to set the throttle for; for example, "Unified Logging Service". If the Identity parameter is not specified, the event throttling setting is applied to all categories in the farm.

Providing an invalid category is a non-terminating error and will be ignored.

InputObject

Optional

System.Management.Automation.PSObject

Specifies the result of the InputObject parameter to be piped. The value can be a string in a format identical to the Identity parameter, or can be an SPDiagnosticsCategory object. The user can retrieve one or more categories from the Get-SPLogLevel cmdlet, modify their values, and then pipe the results to the Set-SPLogLevel cmdlet.

Detailed Description

The Clear-SPLogLevel cmdlet resets the Windows event logging and trace logging levels for the specified categories to the default values. If the Identity parameter is not provided, all categories are affected.

Input Types

Return Types

Example

--------------EXAMPLE 1-----------------

Copy Code
Clear-SPLogLevel -Identity Cat1

This example resets the log levels for a single category.

--------------EXAMPLE 2-----------------

Copy Code
"Cat1", "Cat2", "Cat3" | Clear-SPLogLevel

This example resets the log levels for multiple categories.

--------------EXAMPLE 3-----------------

Copy Code
Get-SPLogLevel | Clear-SPLogLevel

This example resets the log levels for all categories.

See Also

Reference

Get-SPLogLevel
Set-SPLogLevel


Get-SPLogLevel
See Also Example
[image]

Published: May 12, 2010

Returns a list of objects or diagnostic levels.

Get-SPLogLevel [-AssignmentCollection <SPAssignmentCollection>] [-Identity <String[]>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Identity

Optional

System.String[]

Specifies a valid category name; for example, Backup and Restore, or Administration.

Detailed Description

The Get-SPLogLevel cmdlet displays a list of objects or diagnostic levels based on the criteria specified. If no parameter is specified, a list of all diagnostic levels for all categories is returned.

Input Types

Return Types

Example

--------------EXAMPLE 1-----------------

Copy Code
Get-SPLogLevel

This example displays throttle levels for all categories.

--------------EXAMPLE 2-----------------

Copy Code
Get-SPLogLevel -Identity "Category1"

This example displays the throttle level for the Category1 category.

--------------EXAMPLE 3-----------------

Copy Code
"Cat1", "Cat2", "Cat3" | Get-SpLogLevel

This example displays the throttle level for multiple categories.

--------------EXAMPLE 4-----------------

Copy Code
Get-SPLogLevel -Identity "Area:*"

This example displays the throttle level for all categories in one area.

See Also

Reference

Set-SPLogLevel
Clear-SPLogLevel


Set-SPLogLevel
See Also Example
[image]

Published: May 12, 2010

Sets the trace and event level for a set of categories.

Set-SPLogLevel [-AssignmentCollection <SPAssignmentCollection>] [-EventSeverity <String>] [-Identity <String[]>] [-InputObject <PSObject>] [-TraceSeverity <String>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

EventSeverity

Optional

System.String

Specifies the category level to be set. The category level is any one of the following values:

- None

- ErrorCritical

- Error

- Warning

- Information

- Verbose

Identity

Optional

System.String[]

Specifies the name(s) of the category or set of categories to set the throttle for; for example, "Unified Logging Service". If the Identity parameter is not specified, the event-throttling setting is applied to all categories in the farm.

InputObject

Optional

System.Management.Automation.PSObject

The InputObject is pipelined to the cmdlet and can be a string in a format identical to the Identity parameter, or can be an SPDiagnosticsCategory object. The user can retrieve one or more categories from the Get-SPLogLevel cmdlet, modify the category values, and then pipeline them into the Set-SPLogLevel cmdlet.

TraceSeverity

Optional

System.String

Specifies trace throttle to set the specified categor(ies) to. The trace log files are text files that are written to the trace log path that is defined on the Diagnostic Logging Settings page on the SharePoint Central Administration site. The type must be any one of the following values:

- None (no traces are written to the trace log)

- Unexpected

- Monitorable

- High

- Medium

- Verbose

- VerboseEx

Detailed Description

The Set-SPLogLevel cmdlet sets the Windows event logging and trace logging levels for one or more diagnostic logging categories registered in the farm. If an event or trace associated with a category occurs, but is less severe than that category's logging level, the event or trace is not written to the event log or the trace log. If an event or trace associated with a category occurs and is equally severe or more severe than that category's logging level, the event or trace is written to the event log or the trace log.

Input Types

Return Types

Example

------------------EXAMPLE 1-----------------------

Copy Code
set-sploglevel -TraceSeverity Monitorable

This example sets the TraceSeverity values for all categories to Monitorable.

------------------EXAMPLE 2-----------------------

Copy Code
Set-SPLogLevel -TraceSeverity High -EventSeverity Warning -Identity "Cat1"

This example sets the EventSeverity and TraceSeverity values for a single category.

------------------EXAMPLE 3-----------------------

Copy Code
"Cat1", "Cat2", "Cat3" | Set-SPLogLevel -EventSeverity Error

This example sets the EventSeverity values for multiple categories.

------------------EXAMPLE 4-----------------------

Copy Code
Set-SPLogLevel -EventSeverity Warning -Identity "AreaName:*"

This example sets the EventSeverity values for all categories in the same area.

See Also

Reference

Get-SPLogLevel
Clear-SPLogLevel


Get-SPLogEvent
See Also Example
[image]

Published: May 12, 2010

Returns results from a Unified Logging Service (ULS) trace log.

Get-SPLogEvent [-AssignmentCollection <SPAssignmentCollection>] [-AsString <SwitchParameter>] [-ContextKey <String[]>] [-Directory <String>] [-EndTime <DateTime>] [-MinimumLevel <String>] [-StartTime <DateTime>]
Get-SPLogEvent [-AssignmentCollection <SPAssignmentCollection>] [-AsString <SwitchParameter>] [-ContextKey <String[]>] [-EndTime <DateTime>] [-File <String>] [-MinimumLevel <String>] [-StartTime <DateTime>]

Parameters

1

Parameter

Required

Type

Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentColletion

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

AsString

Optional

System.Management.Automation.SwitchParameter

Returns each record as a separate string

ContextKey

Optional

System.String[]

Specifies that context data should be added to the results for the specified Context Keys, for example: -ContextKey @("UserName", "SiteName").

Directory

Optional

System.String

Lists log files from an alternate directory (any directory other than the configured LogLocation directory).

MinimumLevel

Optional

System.String

Returns records at or above the specified level. The valid values are Error or Warning.

EndTime

Optional

System.DateTime

The type must be a valid DateTime format that is culture-specific to the administrative language, such as 2/16/2007 12:15:12 for English-US.

StartTime

Optional

System.DateTime

The type must be a valid DateTime format that is culture-specific to the administrative language, such as 2/16/2007 12:15:12 for English-US.

2

Parameter

Required

Type

Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentColletion

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

AsString

Optional

System.Management.Automation.SwitchParameter

Returns each record as a separate string

ContextKey

Optional

System.String[]

Specifies that context data should be added to the results for the specified Context Keys, for example: -ContextKey @("UserName", "SiteName").

MinimumLevel

Optional

System.String

Returns records at or above the specified level. The valid values are Error or Warning.

EndTime

Optional

System.DateTime

The type must be a valid DateTime format that is culture-specific to the administrative language, such as 2/16/2007 12:15:12 for English-US.

File

Optional

System.String

Specifies a specific file to query records from.

StartTime

Optional

System.DateTime

The type must be a valid DateTime format that is culture-specific to the administrative language, such as 2/16/2007 12:15:12 for English-US.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Get-SPLogEvent cmdlet returns records from a ULS trace log file that match the criteria. If no parameters are specified, all records from all log files are returned. Use the StartTime and EndTime parameters to filter on a time range. The use of these parameters is recommended to optimize performance of this cmdlet.

Input Types

Return Types

Example

--------------EXAMPLE 1-----------------

Copy Code
Get-SPLogEvent -MinimumLevel "Warning"

This example returns all log entries equal to or more severe than Warning from the default log directory.

--------------EXAMPLE 2-----------------

Copy Code
Get-SPLogEvent -Directory "C:\Logs" | Where-Object {$_.Level -eq "Warning"}

This example returns all warning entries from log files in the C:\Logs directory.

--------------EXAMPLE 3-----------------

Copy Code
Get-SPLogEvent -StartTime "12/04/2007 17:00" -EndTime "12/04/2007 18:00"

This example returns error entries that occurred during a particular time range, which is culture-specific to the United States.

--------------EXAMPLE 4-----------------

Copy Code
Get-SPLogEvent -ContextKey @("UserName" ,"SiteName")

This example returns the contents of the most recent log file and adds the specified context key data.

--------------EXAMPLE 5-----------------

Copy Code
Get-SPLogEvent | Where-Object {$_.Level -eq "Error" -and {$_.Area -eq "SharePoint Foundation "}

This example returns all error entries related to SharePoint Foundation.

--------------EXAMPLE 6-----------------

Copy Code
Get-SPLogEvent -ContextKey @("Name") | %{$_.ToString() + "'t" + $_.Context["Name"]}

This example returns the contents of the log file and adds context data.

See Also

Reference

New-SPLogFile
Get-SPLogLevel


Get-SPDiagnosticConfig
See Also Example
[image]

Published: May 12, 2010

Retrieves ULS diagnostic configuration values of the farm.

Get-SPDiagnosticConfig [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPDiagnoticConfig cmdlet retrieves ULS diagnostic configuration values of the farm.

Input Types

Return Types

Example

--------------EXAMPLE-----------------

Copy Code
Get-SPDiagnosticConfig

This example returns all diagnostic configuration values.

See Also

Reference

Set-SPDiagnosticConfig


Get-SPDiagnosticsProvider
See Also Example
[image]

Published: May 12, 2010

Returns a diagnostics provider.

Get-SPDiagnosticsProvider [[-Identity] <SPDiagnosticsProviderPipeBind>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPDiagnosticsProviderPipeBind

Specifies the diagnostics provider to get.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a diagnostic provider (for example, DiagnosticsProv1); or an instance of a valid SPDiagnosticsProvider object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPDiagnosticsProvider cmdlet reads the specified diagnostics provider. If the Identity parameter is not specified, this cmdlet returns the collection diagnostics providers in the farm.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Get-SPDiagnosticsProvider

This example returns all the diagnostics providers in the farm.

------------------EXAMPLE 2-----------------------

Copy Code
Get-SPDiagnosticsProvider job-diagnostics-event-log-provider

This example returns the event log diagnostics provider.

See Also

Reference

Set-SPDiagnosticsProvider


Merge-SPLogFile
See Also Example
[image]

Published: May 12, 2010

Combines trace log entries from all farm computers into a single log file on the local computer.

Merge-SPLogFile -Path <String> [-Area <String[]>] [-AssignmentCollection <SPAssignmentCollection>] [-Category <String[]>] [-ContextFilter <String[]>] [-Correlation <Guid[]>] [-EndTime <DateTime>] [-EventID <String[]>] [-ExcludeNestedCorrelation <SwitchParameter>] [-Level <String>] [-Message <String[]>] [-Overwrite <SwitchParameter>] [-Process <String[]>] [-StartTime <DateTime>] [-ThreadID <UInt32[]>]

Parameters

Parameter Required Type Description

Path

Required

System.String

Specifies the path and file name to which to write the merged log file. Relative paths are supported.

Area

Optional

System.String[]

Specifies the area name to filter on.

The type must be a valid name; for example, SharePoint Foundation.

The use of wildcards is supported.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Category

Optional

System.String[]

Specifies the category ID to filter on.

The type must be a valid category name; for example, category1.

The use of wildcards is supported.

ContextFilter

Optional

System.String[]

Specifies a filter for trace entries in a particular context in the form key=value, for example, user=contoso\joeuser.

Correlation

Optional

System.Guid[]

Specifies the correlation ID to filter on. The type must be a valid GUID, in the form F0BB0790-4323-A153-096F-ABCDC80E24D4.

EndTime

Optional

System.DateTime

Specifies the end time of the log entries returned.

The type must be a valid DateTime format that is culture-specific to the administrative language, such as 2/16/2007 12:15:12 for English-US.

EventID

Optional

System.String[]

Specifies the Event ID to filter on. The use of wildcards is supported.

ExcludeNestedCorrelation

Optional

System.Management.Automation.SwitchParameter

Excludes nested correlation values in the results. This parameter is only used when filtering results by using the ContextFilter parameter

By default, records returned from the ContextFilter parameter include all related records in addition to the records that match the filter. Specifying this option includes only the records that match the filter and excludes any related records.

Level

Optional

System.String

Specifies the level name to filter on.

Results include the specified level and everything more severe.

Message

Optional

System.String[]

Specifies the message text to filter on.

The type must be valid text. Text with spaces should be enclosed with quotation marks; for example, "This is a test."

The use of wildcards is supported.

Overwrite

No

System.Management.Automation.SwitchParameter

Overwrites the log file if it already exists at the specified path.

The type must be either of the following values:

- $True

- $False

The default value is $False.

Process

Optional

System.String[]

Specifies the process name to filter on.

The use of wildcards is supported.

StartTime

Optional

System.DateTime

Specifies the start time of the log entries returned.

The type must be a valid DateTime format that is culture-specific to the administrative language, such as 2/16/2007 12:15:12 for English-US.

The default is one hour prior to the current time on the local computer.

ThreadID

Optional

System.UInt32[]

Specifies the thread ID to filter on.

The type must be a valid integer from 0 through 4,294,967,295.

Detailed Description

The Merge-SPLogFile cmdlet returns records from Unified Logging Service (ULS) trace log files on each farm server that match the criteria, and writes the results to a new log file on the local computer. If no results are returned, a warning is written to the Windows PowerShell console window.

We recommend that you filter by using the StartTime and EndTime parameters to optimize performance of this cmdlet. Some filtering parameters such as Process, Area, Category, EventID and Message support wildcards.

Input Types

Return Types

Example

--------------EXAMPLE 1-----------------

Copy Code
Merge-SPLogFile -Path "C:\Logs\FarmMergedLog.log" -Overwrite

This example merges the last hour of log data from all farm computers with no filtering.

--------------EXAMPLE 2-----------------

Copy Code
Merge-SPLogFile -Path "C:\Logs\FarmMergedLog.log" -Overwrite -Area Search

This example merges the last hour of log data from the Search area.

--------------EXAMPLE 3-----------------

Copy Code
Merge-SPLogFile -Path "C:\Logs\FarmMergedLog.log" -Overwrite -Area "SharePoint Foundation","Web Analytics Services"

This example merges the last hour of log data from the SharePoint Foundation and Web Analytics Services areas.

--------------EXAMPLE 4-----------------

Copy Code
Merge-SPLogFile -Path "C:\Logs\FarmMergedLog.log" -Overwrite -Level High

This example merges the log data of level High or higher.

--------------EXAMPLE 5-----------------

Copy Code
Merge-SPLogFile -Path "C:\Logs\FarmMergedLog.log" -Overwrite -StartTime "06/09/2008 16:00" - EndTime "06/09/2008 16:15"

This example merges the log data for events in a particular time range, which is culture-specific to the United States.

--------------EXAMPLE 6-----------------

Copy Code
Merge-SPLogFile -Path "C:\Logs\FarmMergedLog.log" -Overwrite -Message "*permission changed*"

This example merges the log data for events with permission changed in the message text.

--------------EXAMPLE 7-----------------

Copy Code
Merge-SPLogFile -Overwrite -Path d:\1.log -ContextFilter "name=timer job*" -Area "*search*"

This example merges the log data for all search timer jobs.

--------------EXAMPLE 8-----------------

Copy Code
Merge-SPLogFile -Overwrite -Path d:\2.log -ContextFilter "user=contoso?joeuser"

This example shows how to merge the log data for all user names that have a contoso\joeuser or Contoso/joeuser format.

See Also

Reference

New-SPLogFile


New-SPLogFile
See Also Example
[image]

Published: May 12, 2010

Creates a new log file.

New-SPLogFile [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The New-SPLogFile cmdlet ends the current log file and starts a new log file.

Input Types

Return Types

Example

--------------EXAMPLE-----------------

Copy Code
New-SPLogFile

This example ends the current log file and starts a new log file.

See Also

Reference

Merge-SPLogFile


New-SPUsageLogFile
Example
[image]

Published: May 12, 2010

Starts a new usage log file on the current server computer.

New-SPUsageLogFile [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The New-SPUsageLogFile cmdlet starts a new usage log file on the current server computer. The usage data in memory is flushed to the current usage log file before the new log file is created.

Input Types

Return Types

Example

-------------------EXAMPLE-------------------

Copy Code
New-SPUsageLogFile

This example terminates the current usage log file and creates a new one.


Set-SPDiagnosticConfig
See Also Example
[image]

Published: May 12, 2010

Sets diagnostic configuration settings on the farm.

Set-SPDiagnosticConfig [-AllowLegacyTraceProviders <SwitchParameter>] [-AssignmentCollection <SPAssignmentCollection>] [-CustomerExperienceImprovementProgramEnabled <SwitchParameter>] [-DaysToKeepLogs <Int32>] [-DownloadErrorReportingUpdatesEnabled <SwitchParameter>] [-ErrorReportingAutomaticUploadEnabled <SwitchParameter>] [-ErrorReportingEnabled <SwitchParameter>] [-EventLogFloodProtectionEnabled <SwitchParameter>] [-EventLogFloodProtectionNotifyInterval <Int32>] [-EventLogFloodProtectionQuietPeriod <Int32>] [-EventLogFloodProtectionThreshold <Int32>] [-EventLogFloodProtectionTriggerPeriod <Int32>] [-InputObject <PSObject>] [-LogCutInterval <Int32>] [-LogDiskSpaceUsageGB <Int32>] [-LogLocation <String>] [-LogMaxDiskSpaceUsageEnabled <SwitchParameter>] [-ScriptErrorReportingDelay <Int32>] [-ScriptErrorReportingEnabled <SwitchParameter>] [-ScriptErrorReportingRequireAuth <SwitchParameter>]

Parameters

Parameter Required Type Description

AllowLegacyTraceProviders

Optional

System.Management.Automation.SwitchParameter

Specifies that trace providers built for previous versions of SharePoint Products and Technologies can write to the trace session for SharePoint 2010 Products.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

CustomerExperienceImprovementProgramEnabled

Optional

System.Management.Automation.SwitchParameter

Specifies whether participation in the Customer Experience Improvement Program (CEIP) is enabled.

The CEIP is designed to improve the quality, reliability, and performance of Microsoft products and technologies. With your permission, anonymous information about your server is sent to Microsoft to help improve SharePoint 2010 Products.

The type must be either of the following values:

- $True

- $False

The default value is $True.

DaysToKeepLogs

Optional

System.Int32

Specifies the number of days to keep trace log files. The type must be a valid number between 1 and 366. The default value is 14 days..

DownloadErrorReportingUpdatesEnabled

Optional

System.Management.Automation.SwitchParameter

Specifies whether the error reporting remote control file is downloaded.

The type must be either of the following values:

- $True

- $False

The default value is $True.

ErrorReportingAutomaticUploadEnabled

Optional

System.Management.Automation.SwitchParameter

Specifies whether error reports are uploaded to Microsoft automatically.

Error reports include the following: information regarding the condition of the server when a problem occurs; the operating system version and computer hardware in use; and the digital product ID, which can be used to identify your license. The IP address of your computer is also sent because you are connecting to an online service to send error reports; however, the IP address is used only to generate aggregate statistics.

The type must be either of the following values:

- $True

- $False

The default value is $True.

ErrorReportingEnabled

Optional

System.Management.Automation.SwitchParameter

Specifies whether collection of error reports is enabled.

Error reports are created when your system encounters hardware or software problems. Microsoft and its partners actively use these reports to improve the reliability of the software. Error reports include the following: information regarding the condition of the server when the problem occurs; the operating system version and computer hardware in use; and the digital product ID, which can be used to identify your license. The IP address of your computer is also sent because you are connecting to an online service to send error reports; however, the IP address is used only to generate aggregate statistics.

The type must be either of the following values:

- $True

- $False

The default value is $True.

EventLogFloodProtectionEnabled

Optional

System.Management.Automation.SwitchParameter

Specifies whether the Event log flood protection feature is enabled.

If multiple similar events are written to the event log, some duplicate messages are suppressed. Then, after a period of time, a summary message is written that shows how many events were suppressed.

The type must be either of the following values:

- $True

- $False

The default value is $True.

EventLogFloodProtectionNotifyInterval

Optional

System.Int32

Specifies in minutes how often to write a summary event indicating how many events were suppressed due to flood protection.

The integer range is between 1 and 1440. The default value is 5.

EventLogFloodProtectionQuietPeriod

Optional

System.Int32

Specifies in minutes how much time must pass without an event firing to exit flood protection.

The integer range is between 1 and 1440. The default value is 2.

EventLogFloodProtectionThreshold

Optional

System.Int32

Specifies the number of events allowed in a given timeframe before an event is considered to be flooding the event log.

The integer range is between 1 and 100. The default value is 5.

EventLogFloodProtectionTriggerPeriod

Optional

System.Int32

Specifies in minutes the timeframe to watch for events that may be flooding.

The integer range is between 1 and 1440. The default value is 2.

InputObject

Optional

System.Management.Automation.PSObject

Use the result from the Get-SPDiagnosticConfig cmdlet, make modifications, and then pipeline the object into Set-SPDiagnosticConfig cmdlet to update the content database.

LogCutInterval

Optional

System.Int32

Specifies a time period to roll over to the next log file.

The type must be a valid number between 0 and 1440.

The default value is 30.

LogDiskSpaceUsageGB

Optional

System.Int32

Specifies the maximum amount of storage to use for trace log files, in gigabytes (GB).

The default value is 1000 and only takes effect when the LogMaxDiskSpaceusageEnabled cmdlet is set to True.

The type must be a valid number between 1 and 1000.

LogLocation

Optional

System.String

Specifies the path of where to log files will reside.

The type must be a valid path, in the form C:\Logs.

The default location is %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\14\Logs.

LogMaxDiskSpaceUsageEnabled

Optional

System.Management.Automation.SwitchParameter

Specifies whether to restrict the maximum space to use for trace log files.

The type must be either of the following values:

- $True

- $False

The default value is $False.

ScriptErrorReportingDelay

Optional

System.Int32

Specifies the time (in minutes) between script error reports.

The type must be a valid integer between 0 and 1440. The value is specified in minutes.

The default value is 30.

ScriptErrorReportingEnabled

Optional

System.Management.Automation.SwitchParameter

Specifies whether error reporting is enabled for client script errors.

The type must be either of the following values:

- $True

- $False

The default value is $True.

ScriptErrorReportingRequireAuth

Optional

System.Management.Automation.SwitchParameter

Specifies whether script error reporting requires authentication.

The type must be either of the following values:

- $True

- $False

The default value is $True.

Detailed Description

Use the Set-SPDiagnosticConfig cmdlet to set diagnostic configuration settings on the entire farm.

Input Types

Return Types

Example

------------------EXAMPLE 1-----------------------

Copy Code
set-spdiagnosticconfig -errorReportingEnable -DownloadErrorReportingUpdatesEnabled:$false -DaysToKeepLog  60

This example enables ErrorReporting, disables DownloadErrorReportingUpdatesEnable, and sets DaysToKeepLog to 60.

------------------EXAMPLE 2-----------------------

Copy Code
$L = get-spdiagnosticconfig
Copy Code
$L.CustomerExperienceImprovementProgramEnabled = $false
Copy Code
$L.LogCutInterval = 60
Copy Code
$L | Set-SPDiagnosticConfig

This example disables CEIP and sets LogCutInterval to 60 minutes.

See Also

Reference

Get-SPDiagnosticConfig


Set-SPDiagnosticsProvider
See Also Example
[image]

Published: May 12, 2010

Enables a diagnostics provider and updates its retention policy.

Set-SPDiagnosticsProvider [-Identity] <SPDiagnosticsProviderPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DaysRetained <Int32>] [-Enable <SwitchParameter>] [-MaxTotalSizeInBytes <Int64>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPDiagnosticsProviderPipeBind

Specifies the diagnostics provider to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a diagnostic provider (for example, DiagnosticProv1); or an instance of a valid SPDiagnosticsProvider object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DaysRetained

Optional

System.Int32

Specifies the number of days to retain the data collected by a diagnostics provider.

The type must be a valid integer value in the range of 1 to 14.

Enable

Optional

System.Management.Automation.SwitchParameter

Turns on or off the specified diagnostics provider.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Set-SPDiagnosticsProvider cmdlet enables a diagnostics provider and updates its retention policy.

Input Types

Return Types

Example

------------------EXAMPLE 1-----------------------

Copy Code
Get-SPDiagnosticsProvider job-diagnostics-event-log-provider | Set-SPDiagnosticsProvider -Enable:$false
Copy Code
Get-SPDiagnosticsProvider job-diagnostics-event-log-provider

This example disables the event log diagnostics provider.

------------------EXAMPLE 2-----------------------

Copy Code
Get-SPDiagnosticsProvider job-diagnostics-event-log-provider | Set-SPDiagnosticsProvider -Enable -DaysRetained 10
Copy Code
Get-SPDiagnosticsProvider job-diagnostics-event-log-provider

This example enables the event log diagnostics provider and changes its retention policy to 10 days.

See Also

Reference

Get-SPDiagnosticsProvider


Performance cmdlets (SharePoint Foundation 2010)
See Also

You can use Windows PowerShell cmdlets to manage performance for a Microsoft SharePoint Foundation 2010 farm.

Cmdlet name | Description
Add-SPDiagnosticsPerformanceCounter | Adds an instance of a performance counter.
Get-SPDiagnosticsPerformanceCounter | Returns a collection of performance counters.
Remove-SPDiagnosticsPerformanceCounter | Removes an instance of a performance counter.
Disable-SPWebApplicationHttpThrottling | Turns off network throttling for a Web application.
Enable-SPWebApplicationHttpThrottling | Turns on network throttling for a Web application.
Get-SPBusinessDataCatalogThrottleConfig | Returns the throttling configuration for a Business Data Connectivity Service application.
Set-SPBusinessDataCatalogThrottleConfig | Sets the throttling configuration for a Business Data Connectivity Service application.
Get-SPWebApplicationHttpThrottlingMonitor | Reads all counters for network throttling on a Web application.
Set-SPWebApplicationHttpThrottlingMonitor | Sets the Health Score bucket values for an existing network throttling performance counter for a specified Web application.

See Also

Other Resources

Resource Center: Windows PowerShell for SharePoint Foundation 2010


Add-SPDiagnosticsPerformanceCounter
See Also Example
[image]

Published: May 12, 2010

Adds a new instance of a performance counter to a Web front end computer or a database server.

Add-SPDiagnosticsPerformanceCounter [-Category] <String> -Counter <String> [-AllInstances <SwitchParameter>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DatabaseServer <SwitchParameter>] [-WebFrontEnd <SwitchParameter>] [-WhatIf [<SwitchParameter>]]
Add-SPDiagnosticsPerformanceCounter [-Category] <String> -Instance <String> [-AllInstances <SwitchParameter>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Counter <String>] [-DatabaseServer <SwitchParameter>] [-WebFrontEnd <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Category

Required

System.String

Specifies the category of performance counter to add to the target Web front end computer or database server.

The type must be a valid name of a category of performance counters; for example, ASP.NET, PhysicalDisk, or Processor.

Counter

Required

System.String

Specifies the type of counter to add to the target Web front end computer or database server.

The type must be a valid name of counter type; for example, Requests Queued, Avg. Disk Queue Length, and % Processor Time.

AllInstances

Optional

System.Management.Automation.SwitchParameter

Collects all instances of a counter category and type on the target Web front end computer or database server.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DatabaseServer

Optional

System.Management.Automation.SwitchParameter

Adds the specified performance counter to all database servers in the farm.

WebFrontEnd

Optional

System.Management.Automation.SwitchParameter

Adds the specified performance counter to all Web front end computers in the farm.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Category

Required

System.String

Specifies the category of performance counter to add to the target Web front end computer or database server.

The type must be a valid name of a category of performance counters; for example, ASP.NET, PhysicalDisk, or Processor.

Counter

Required

System.String

Specifies the type of counter to add to the target Web front end computer or database server.

The type must be a valid name of counter type; for example, Requests Queued, Avg. Disk Queue Length, and % Processor Time.

Instance

Required

System.String

Specifies the display name of the new performance counter.

The type must be a valid name of a performance counter instance; for example Total_PerfCounter.

AllInstances

Optional

System.Management.Automation.SwitchParameter

Collects all instances of a counter category and type on the target Web front end computer or database server.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DatabaseServer

Optional

System.Management.Automation.SwitchParameter

Adds the specified performance counter to all database servers in the farm.

WebFrontEnd

Optional

System.Management.Automation.SwitchParameter

Adds the specified performance counter to all Web front end computers in the farm.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Add-SPDiagnosticsPerformanceCounter cmdlet adds a performance counter to a front end Web server or a database server. A performance counter is read and recorded in the usage database. By default, the new performance counter is added to the database servers in the farm.

Input Types

Return Types

Example

------------------EXAMPLE 1------------------

Copy Code
Add-SPDiagnosticsPerformanceCounter -category ASP.NET -Counter "Requests Queued"

This example adds the counter that has the name ASP.NET\Requests Queued on front end Web servers.

------------------EXAMPLE 2------------------

Copy Code
Add-SPDiagnosticsPerformanceCounter -category PhysicalDisk -counter "Avg. Disk Queue Length" -allinstances

This example adds all instances of the counter PhysicalDisk in the category Avg. Disk Queue Length on front end Web servers.

------------------EXAMPLE 3------------------

Copy Code
Add-SPDiagnosticsPerformanceCounter -category Processor -counter "% Processor Time" -instance "_Total" -databaseserver

This example adds the _Total instance of the counter % Processor Time in the category Processor on database servers.

See Also

Reference

Get-SPDiagnosticsPerformanceCounter
Remove-SPDiagnosticsPerformanceCounter


Get-SPDiagnosticsPerformanceCounter
See Also Example
[image]

Published: May 12, 2010

Returns a collection of performance counters.

Get-SPDiagnosticsPerformanceCounter [-AssignmentCollection <SPAssignmentCollection>] [-DatabaseServer <SwitchParameter>] [-WebFrontEnd <SwitchParameter>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

DatabaseServer

Optional

System.Management.Automation.SwitchParameter

Returns performance counters collected for the database servers in the farm.

WebFrontEnd

Optional

System.Management.Automation.SwitchParameter

Returns performance counters collected for the front end Web servers in the farm.

Detailed Description

The Get-SPDiagnosticsPerformanceCounter cmdlet returns the collection of performance counters that are read and recorded in the usage database. If neither the DatabaseServer or WebFrontEnd parameters are specified, this cmdlet returns the performance counters on the front end Web servers and database servers in the farm.

To distinguish counters that are collected on database servers and counters that are collected on front end Web servers, note that counters that are collected on database servers have a Provider Name of job-diagnostics-performance-counter-sql-provider, and counters that are collected on front end Web servers have a Provider Name of job-diagnostics-performance-counter-wfe-provider.

Note:

The Get-SPDiagnosticsPerformanceCounter cmdlet is only available by using Windows PowerShell. There is no user interface.

Input Types

Return Types

Example

------------------EXAMPLE 1------------------

Copy Code
Get- SPDiagnosticsPerformanceCounter

This example gets the performance counter settings for front end Web servers and database servers.

------------------EXAMPLE 2------------------

Copy Code
Get- SPDiagnosticsPerformanceCounter -WebFrontEnd

This example gets the performance counter settings for front end Web servers.

------------------EXAMPLE 3------------------

Copy Code
Get- SPDiagnosticsPerformanceCounter -DatabaseServer

This example gets the performance counter settings for database servers.

See Also

Reference

Add-SPDiagnosticsPerformanceCounter
Remove-SPDiagnosticsPerformanceCounter


Remove-SPDiagnosticsPerformanceCounter
See Also Example
[image]

Published: May 12, 2010

Removes an instance of a performance counter.

Remove-SPDiagnosticsPerformanceCounter [-Category] <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Counter <String>] [-DatabaseServer <SwitchParameter>] [-Instance <String>] [-WebFrontEnd <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Category

Required

System.String

Specifies the category of performance counters to remove.

The type must be a valid name of a category of performance counters; for example, ASP.NET, PhysicalDisk, or Processor.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Counter

Optional

System.String

Specifies the type of counter to remove. If this parameter is not specified, this cmdlet removes all performance counters of the specified category.

The type must be a valid name of counter type; for example, Requests Queued, Avg. Disk Queue Length, and % Processor Time.

DatabaseServer

Optional

System.Management.Automation.SwitchParameter

Removes the specified performance counters that are collected on the database servers in the farm.

Instance

Optional

System.String

Specifies the instance name of the performance counter to remove. If this parameter is not specified, this cmdlet removes all instances of the specified performance counter.

The type must be a valid name of a performance counter instance; for example Total_PerfCounter.

WebFrontEnd

Optional

System.Management.Automation.SwitchParameter

Removes performance counters that are collected on the front end Web servers in the farm.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPDiagnosticsPerformanceCounter cmdlet removes performance counters from the collection of performance counters that are read and recorded in the usage database. This cmdlet can also be used to remove entire categories and types of counters from the collection. If either the DatabaseServer or WebFrontEnd parameters are not specified, this cmdlet removes the specified performance counters on the front end Web servers in the farm.

Note:

The Remove-SPDiagnosticsPerformanceCounter cmdlet is only available by using Windows PowerShell. There is no user interface.

Input Types

Return Types

Example

------------------EXAMPLE 1------------------

Copy Code
Remove-SPDiagnosticsPerformanceCounter -category ASP.NET

This example removes all the counters in the category ASP.NET on front end Web servers.

------------------EXAMPLE 2------------------

Copy Code
Remove-SPDiagnosticsPerformanceCounter -category ASP.NET -Counter "Requests Queued"

This example removes the counters in the category ASP.NET that have requests queued on front end Web servers.

------------------EXAMPLE 3------------------

Copy Code
Remove-SPDiagnosticsPerformanceCounter -category Processor -counter "% Processor Time" -instance "_Total" -databaseserver

This example removes the counters of the _Total instance, with the counter % Processor Time in the category Processor on database servers.

See Also

Reference

Add-SPDiagnosticsPerformanceCounter
Get-SPDiagnosticsPerformanceCounter


Disable-SPWebApplicationHttpThrottling
See Also Example
[image]

Published: May 12, 2010

Turns off network throttling for a Web application.

Disable-SPWebApplicationHttpThrottling [-Identity] <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Turns off network throttling on the specified SharePoint Web application.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of a SharePoint Web application (for example, MyOfficeApp1); or an instance of a valid SPWebApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Disable-SPWebApplicationHttpThrottling cmdlet turns off network throttling for a Web application. This operation prompts you to confirm that you want to turn off network throttling.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Disable-SPWebApplicationHTTPThrottling http://sitename

This example disables network throttling on the Web application http://sitename.

See Also

Reference

Get-SPWebApplicationHttpThrottlingMonitor
Enable-SPWebApplicationHttpThrottling
Set-SPWebApplicationHttpThrottlingMonitor


Enable-SPWebApplicationHttpThrottling
See Also Example
[image]

Published: May 12, 2010

Turns on network throttling for a Web application.

Enable-SPWebApplicationHttpThrottling [-Identity] <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Turns on network throttling on the specified SharePoint Web application.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of a SharePoint Web application (for example, MyOfficeApp1); or an instance of a valid SPWebApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Enable-SPWebApplicationHttpThrottling cmdlet turns on network throttling for a Web application. This operation prompts you to confirm that you want to turn on network throttling.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Enable-SPWebApplicationHttpThrottling http://sitename

This example enables network throttling on the http://sitename Web application.

See Also

Reference

Get-SPWebApplicationHttpThrottlingMonitor
Disable-SPWebApplicationHttpThrottling
Set-SPWebApplicationHttpThrottlingMonitor


Get-SPBusinessDataCatalogThrottleConfig
See Also Example
[image]

Published: May 12, 2010

Returns the throttling configuration for a Business Data Connectivity Service application.

Get-SPBusinessDataCatalogThrottleConfig -Scope <Global | Database | WebService | Wcf | Custom> -ServiceApplicationProxy <SPServiceApplicationProxyPipeBind> -ThrottleType <None | Items | Size | Connections | Timeout> [-AssignmentCollection <SPAssignmentCollection>]
Get-SPBusinessDataCatalogThrottleConfig -FileBacked <SwitchParameter> -Scope <Global | Database | WebService | Wcf | Custom> -ThrottleType <None | Items | Size | Connections | Timeout> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

1

Parameter

Required

Type

Description

Scope

Required

Microsoft.BusinessData.SystemSpecific.ThrottleScope

Returns the throttling configuration for the specified the scope.

The type must be one of the following: Wcf, WebService, Database, Global, or Custom.

ServiceApplicationProxy

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationProxyPipeBind

Specifies the Business Data Connectivity Service application proxy that contains the throttling configuration to get.

ThrottleType

Required

Microsoft.BusinessData.SystemSpecific.ThrottleType

Returns the throttling configuration for the specified throttle type.

The type must be one of the following: None, Items, Size, Connections, or Timeout.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

2

Parameter

Required

Type

Description

FileBacked

Required

System.Management.Automation.SwitchParameter

Requests the throttling configuration for file backed metadata catalogs.

Scope

Required

Microsoft.BusinessData.SystemSpecific.ThrottleScope

Returns the throttling configuration for the specified the scope.

The type must be one of the following: Wcf, WebService, Database, Global, or Custom.

ThrottleType

Required

Microsoft.BusinessData.SystemSpecific.ThrottleType

Returns the throttling configuration for the specified throttle type.

The type must be one of the following: None, Items, Size, Connections, or Timeout.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Get-SPBusinessDataCatalogThrottleConfig cmdlet reads the throttling configuration for a Business Data Connectivity Service application.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Get-SPBusinessDataCatalogThrottleConfig -Scope Database -ThrottleType Items -ServiceApplicationProxy $contosoServAppProxy

This example returns the throttling information that is related to database items for the given service application.

See Also

Reference

Set-SPBusinessDataCatalogThrottleConfig


Set-SPBusinessDataCatalogThrottleConfig
See Also Example
[image]

Published: May 12, 2010

Sets the throttling configuration for a Business Data Connectivity Service application.

Set-SPBusinessDataCatalogThrottleConfig -Default <Int32> -Identity <ThrottleConfig> -Maximum <Int32> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]
Set-SPBusinessDataCatalogThrottleConfig -Enforced <SwitchParameter> -Identity <ThrottleConfig> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Default

Required

System.Int32

Specifies the default setting of the throttle configuration.

Identity

Required

Microsoft.SharePoint.BusinessData.SharedService.ThrottleConfig

Specifies the throttle configuration to update.

Maximum

Required

System.Int32

Specifies the maximum value of the throttling configuration setting.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Enforced

Required

System.Management.Automation.SwitchParameter

Specifies that the throttle configuration setting cannot be overridden.

Identity

Required

Microsoft.SharePoint.BusinessData.SharedService.ThrottleConfig

Specifies the throttle configuration to update.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Set-SPBusinessDataCatalogThrottleConfig cmdlet sets the throttling configuration for a Business Data Connectivity Service application.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Get-SPBusinessDataCatalogThrottleConfig -Scope Database -ThrottleType Items -ServiceApplicationProxy $contosoServAppProxy | Set-SPBusinessDataCatalogThrottleConfig -Maximum 1000000000 -Default 500000

This example sets the database item throttling to values of 1000000000 maximum and 500000 default for the given service application.

See Also

Reference

Get-SPBusinessDataCatalogThrottleConfig


Get-SPWebApplicationHttpThrottlingMonitor
See Also Example
[image]

Published: May 12, 2010

Returns all counters and their associated Health Score bucket values for network throttling on a Web application.

Get-SPWebApplicationHttpThrottlingMonitor [-Identity] <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Returns throttling performance counter settings for the specified SharePoint Web application.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of SharePoint Web application (for example, MyOfficeApp1); or an instance of a valid SPWebApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPWebApplicationHttpThrottlingMonitor cmdlet reads all counters for network throttling on a Web application. This cmdlet returns a list that contains all of the performance counters and their associated Health Score bucket values.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
$s = get-SPWebApplicationHTTPThrottlingMonitors http://sharepoint

This example gets all performance counters that are being read in the network throttling monitor for the http://sharepoint Web application.

See Also

Reference

Set-SPWebApplicationHttpThrottlingMonitor
Enable-SPWebApplicationHttpThrottling
Disable-SPWebApplicationHttpThrottling


Set-SPWebApplicationHttpThrottlingMonitor
See Also Example
[image]

Published: May 12, 2010

Sets the Health Score bucket values for an existing network throttling performance counter for a specified Web application.

Set-SPWebApplicationHttpThrottlingMonitor [-Identity] <SPWebApplicationPipeBind> [-Category] <String> [-Counter] <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-HealthScoreBuckets <Double[]>] [-Instance <String>] [-IsDESC <SwitchParameter>] [-LowerLimit <Double>] [-UpperLimit <Double>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the SharePoint Web application to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SharePoint Web application (for example, MyOfficeApp1); or an instance of a valid SPWebApplication object.

Category

Required

System.String

Specifies the name of the performance counter category.

The type must be a valid performance counter category in the throttling monitor. Use the Get-SPWebApplicationHttpThrottlingMonitor cmdlet to return a list of performance counter categories in the throttling monitor.

Counter

Required

System.String

Specifies the name of the performance counter.

The type must be a valid performance counter in the throttling monitor. Use the Get-SPWebApplicationHttpThrottlingMonitor cmdlet to return a list of performance counters in the throttling monitor.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

HealthScoreBuckets

Optional

System.Double[]

Specifies bucket ranges to use in determining the calculation of the server Health Score for this counter.

Instance

Optional

System.String

Specifies the instance of the performance counter. The default value is empty. If the specified value is invalid, this cmdlet will not run.

IsDESC

Optional

System.Management.Automation.SwitchParameter

Specifies that this counter is interpreted in descending order.

If this parameter is set, Health Score bucket values are interpreted in descending order; for example, set this parameter by using the Memory category and Available Mbytes counter to monitor available memory.

LowerLimit

Optional

System.Double

Specifies the lower limit of the numerical threshold of the specified performance counter. The lower limit is the lowest value in the Health Score bucket values.

UpperLimit

Optional

System.Double

Specifies the upper limit of the numerical threshold of the specified performance counter. The upper limit is the highest value in the Health Score bucket values.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Set-SPWebApplicationHttpThrottlingMonitor cmdlet sets the Health Score bucket values for an existing network throttling performance counter for a specified Web application.

Input Types

Return Types

Example

------------------EXAMPLE 1------------------

Copy Code
$buckets=(2000,1000,500,300,200,100,50,30,20,10)
Set-SPWebApplicationHttpThrottlingMonitor http://sharepoint -
Category Memory -Counter 'Available Mbytes' -IsDesc -HealthScoreBuckets $buckets

This example sets the Health Score bucket values for the Memory\Available Mbytes counter to the array listed for the http://sharepoint Web application.

------------------EXAMPLE 2------------------

Copy Code
Set-SPWebApplicationHttpThrottlingMonitor http://sharepoint
0 -Category Memory -Counter 'Available Mbytes' -IsDesc -UpperLimit 3000

This example sets the upper limit for the Memory\Available Mbytes counter, the highest value in the Health Score buckets, to 3000 for the the http://sharepoint Web application.

See Also

Reference

Get-SPWebApplicationHttpThrottlingMonitor
Enable-SPWebApplicationHttpThrottling
Disable-SPWebApplicationHttpThrottling


Security cmdlets (SharePoint Foundation 2010)
See Also

You can use Windows PowerShell cmdlets to administer security for Microsoft SharePoint Foundation 2010.

Cmdlet name | Description
Add-SPShellAdmin | Adds a user to the SharePoint_Shell_Access role for the specified database.
Get-SPShellAdmin | Returns the names of all users who have the SharePoint_Shell_Access role.
Remove-SPShellAdmin | Removes a user from the SharePoint_Shell_Access role.
Add-SPClaimTypeMapping | Adds a claim mapping to a trusted security token service (STS) identity provider.
Get-SPAuthenticationProvider | Returns an authentication provider.
Get-SPCertificateAuthority | Returns the SharePoint certificate authority (CA).
Get-SPClaimProvider | Returns a claim provider.
Get-SPClaimProviderManager | Returns a claim provider manager.
Get-SPManagedAccount | Retrieves accounts registered in the configuration database.
Get-SPManagedPath | Returns all managed paths that match the given criteria.
Get-SPSecurityTokenServiceConfig | Returns the security token service (STS) for the farm.
Get-SPServiceApplicationSecurity | Returns the SPObjectSecurity object for a service application.
Get-SPTrustedIdentityTokenIssuer | Returns an identity provider.
Get-SPTrustedRootAuthority | Returns a trusted root authority.
Get-SPTrustedServiceTokenIssuer | Returns the object that represents the farm trust.
Grant-SPObjectSecurity | Adds a new security principal to an SPObjectSecurity object.
Initialize-SPResourceSecurity | Enforces resource security on the local server.
New-SPAuthenticationProvider | Creates a new authentication provider in the farm.
New-SPClaimProvider | Registers a new claim provider in the farm.
New-SPClaimsPrincipal | Creates a new claims principal.
New-SPClaimTypeMapping | Creates a claim mapping rule for a security token service (STS) identity provider.
New-SPManagedAccount | Registers a new managed account.
New-SPManagedPath | Creates a new managed path for the given Web application for all host header site collections.
New-SPTrustedIdentityTokenIssuer | Creates an identity provider in the farm.
New-SPTrustedRootAuthority | Creates a trusted root authority.
New-SPTrustedServiceTokenIssuer | Creates a trust with a SharePoint farm.
Remove-SPClaimProvider | Unregisters a claim provider.
Remove-SPClaimTypeMapping | Deletes a claim type mapping rule for a security token service (STS) identity provider.
Remove-SPManagedAccount | Removes a managed account registration from the farm.
Remove-SPManagedPath | Deletes the specified managed path from the specified host header or Web application.
Remove-SPTrustedIdentityTokenIssuer | Deletes a security token service (STS) identity provider from the farm.
Remove-SPTrustedRootAuthority | Deletes a trusted root authority.
Remove-SPTrustedServiceTokenIssuer | Deletes the object that represents the farm trust.
Repair-SPManagedAccountDeployment | Repairs the local managed account credential deployment.
Revoke-SPObjectSecurity | Removes a security principal from a SPObjectSecurity object.
Set-SPClaimProvider | Updates registration of a claims provider.
Set-SPManagedAccount | Configures the managed account.
Set-SPSecurityTokenServiceConfig | Updates the settings of the SharePoint security token service (STS) identity provider.
Set-SPServiceApplicationSecurity | Updates the SPObjectSecurity object for a service application.
Set-SPTrustedIdentityTokenIssuer | Sets the identity providers of a Web application.
Set-SPTrustedRootAuthority | Creates a new trusted root authority.
Set-SPTrustedServiceTokenIssuer | Updates a trust with the farm.
Update-SPFarmEncryptionKey | Changes the value of the farm encryption key and, using the new key, re-encrypts all the data.

See Also

Other Resources

Resource Center: Windows PowerShell for SharePoint Foundation 2010


Add-SPShellAdmin
See Also Example
[image]

Published: May 12, 2010

Adds a user to the SharePoint_Shell_Access role for the specified database.

Add-SPShellAdmin [-UserName] <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-database <SPDatabasePipeBind>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

UserName

Required

System.String

Specifies the name of the user to add to the SharePoint_Shell_Access role in the target database.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

database

Optional

Microsoft.SharePoint.PowerShell.SPDatabasePipeBind

Specifies the GUID of the database or the Database object that includes the SharePoint_Shell_Access role to which you want to add the user. If the database parameter is not specified, the configuration database is used. The farm configuration database is always included, even if you specify another database.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

Important:

When you run this cmdlet to add a user to the SharePoint_Shell_Access role, you must have membership in the securityadmin fixed server role on the SQL Server instance, membership in the db_owner fixed database role on all affected databases, and local administrative permission on the local computer.

This cmdlet is intended only to be used with a database that uses Windows authentication. There is no need to use this cmdlet for databases that use SQL authentication; in fact, doing so may result in an error message.

Use the Add-SPShellAdmin cmdlet to add a user to the SharePoint_Shell_Access role as follows:

  • If you specify only the user, the user is added to the role for the farm configuration database.

  • If you use the database parameter, the user is added to the role on the farm configuration database, the Central Administration content database, and the specified database. Using the database parameter is the preferred method because most of the administrative operations require access to the Central Administration content database.

The user is added to the WSS_Admin_WPG group on all Web servers when the user is added to the SharePoint_Shell_Access role. If the target database does not have a SharePoint_Shell_Access role, the role is automatically created.

Important:

In order to use Windows PowerShell for SharePoint 2010 Products, a user must be a member of the SharePoint_Shell_Access role on the configuration database and a member of the WSS_ADMIN_WPG local group on the computer where SharePoint 2010 Products is installed. However, the result of running this cmdlet is that the user specified with the UserName parameter will have the dbo_owner role access on the affected databases as described above. Therefore, you should carefully plan which users are given this access.

Input Types

Return Types

Example

-------------------EXAMPLE 1-------------------------

Copy Code
Add-SPShellAdmin -UserName CONTOSO\User1

This example adds a new user named User1 to the SharePoint_Shell_Access role in the farm configuration database only, and also ensures the user is added to the WSS_Admin_WPG local group on each server in the farm.

-------------------EXAMPLE 2-------------------------

Copy Code
Add-SPShellAdmin -UserName CONTOSO\User1 -database 4251d855-3c15-4501-8dd1-98f960359fa6

This example adds a new user named User1 to the SharePoint_Shell_Access role in both the specified content database and the configuration database by passing a database GUID to the cmdlet.

-------------------EXAMPLE 3-------------------------

Copy Code
Get-SPDatabase | Where-Object {$_.WebApplication -like "SPAdministrationWebApplication"} | Add-SPShellAdmin CONTOSO\User1

This example adds a new user named User1 to the SharePoint_Shell_Access role in both the specified Central Administration content database and the configuration database.

-------------------EXAMPLE 4-------------------------

Copy Code
Get-SPDatabase | ?{$_.Name -eq "WSS_Content"} | Add-SPShellAdmin -Username CONTOSO\User1

This example adds a new user named User1 to the SharePoint_Shell_Access role of both the specified content database and the configuration database by passing the name of the database to the cmdlet.

See Also

Reference

Get-SPShellAdmin
Remove-SPShellAdmin


Get-SPShellAdmin
See Also Example
[image]

Published: May 12, 2010

Returns the names of all users who have the SharePoint_Shell_Access role.

Get-SPShellAdmin [[-database] <SPDatabasePipeBind>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

database

Optional

Microsoft.SharePoint.PowerShell.SPDatabasePipeBind

Specifies the GUID of the database or the Databse Object that includes includes the SharePoint_Shell_Access role whose user names you want to display. If the database parameter is not specified, the configuration database is used.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

Use the Get-SPShellAdmin cmdlet to return the names of all users who have the SharePoint_Shell_Access role in a database.

Input Types

Return Types

Example

--------------------EXAMPLE----------------------

Copy Code
Get-SPShellAdmin -database 4251d855-3c15-4501-8dd1-98f960359fa6

This example returns the name of each user who has the SharePoint_Shell_Access role in the database specified.

See Also

Reference

Add-SPShellAdmin
Remove-SPShellAdmin


Remove-SPShellAdmin
See Also Example
[image]

Published: May 12, 2010

Removes a user from the SharePoint_Shell_Access role.

Remove-SPShellAdmin [-UserName] <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-database <SPDatabasePipeBind>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

UserName

Required

System.String

Specifies the name of the user you want to remove from the SharePoint_Shell_Access role in the specified database.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

database

Optional

Microsoft.SharePoint.PowerShell.SPDatabasePipeBind

Specifies the GUID of the database or the Databse Object that includes the SharePoint_Shell_Access role from which the user is to be removed. If the database parameter is not specified, the configuration database is used.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

Use the Remove-SPShellAdmin cmdlet to remove a user from the SharePoint_Shell_Access role in a specified database.

When you use this cmdlet to remove a user from the role, you do not remove the user from the WSS_ADMIN_WPG group in the target database.

When you run this cmdlet to add a user to the SharePoint_Shell_Access role, the user must have the following security permissions:

- Security_Admin role access on the instance of SQL Server and the db_owner role in the database.

- Administrative permission to the local computer.

Input Types

Return Types

Example

-----------------------EXAMPLE-----------------------------

Copy Code
Remove-SPShellAdmin -UserName CONTOSO\User1 -database 4251d855-3c15-4501-8dd1-98f960359fa6

This example removes an existing user named User1 from the SharePoint_Shell_Access role in the database specified.

See Also

Reference

Add-SPShellAdmin
Get-SPShellAdmin


Add-SPClaimTypeMapping
See Also Example
[image]

Published: May 12, 2010

Adds a claim mapping to a trusted security token service (STS) identity provider.

Add-SPClaimTypeMapping [-Identity] <SPClaimMappingPipeBind> [-TrustedIdentityTokenIssuer] <SPTrustedIdentityTokenIssuerPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Force <SwitchParameter>]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPClaimMappingPipeBind

Specifies the STS for the farm that will issue the security token for the identity provider.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of a claim mapping rule (for example, ClaimMap1); or an instance of a valid SPClaimMapping object.

TrustedIdentityTokenIssuer

Required

Microsoft.SharePoint.PowerShell.SPTrustedIdentityTokenIssuerPipeBind

Specifies the farm trust Token Issuer (STS authentication provider).

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of an authentication provider (for example, MyIDprovider1); or an instance of a valid SPTrustedIdentityTokenIssuer object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Force

Optional

System.Management.Automation.SwitchParameter

Overwrites the claim mapping rule if it exists.

Detailed Description

The Add-SPClaimTypeMapping cmdlet adds a claim type mapping rule to a security token service (STS) identity provider from a farm trust STS authentication provider.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Get-SPTrustedIdentityProvider -Name "LiveIDSTS" | Add-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" -IncomingClaimTypeDisplayName "PUID" -LocalClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/thumbprint"

This example adds a claim mapping to a trusted identity token issuer.

See Also

Reference

New-SPClaimTypeMapping
Remove-SPClaimTypeMapping


Get-SPAuthenticationProvider
See Also Example
[image]

Published: May 12, 2010

Returns an authentication provider.

Get-SPAuthenticationProvider [[-Identity] <SPAuthenticationProviderPipeBind>] [-WebApplication] <SPWebApplicationPipeBind> [-Zone] <Default | Intranet | Internet | Custom | Extranet> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPAuthenticationProviderPipeBind

Specifies the authentication provider to get.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SharePoint authentication provider (for example, NTLM); or an instance of a valid SPAuthenticationProvider object.

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Returns the content databases for the specified Web application.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of SharePoint Web application (for example, MyOfficeApp1); or an instance of a valid SPWebApplication object.

Zone

Required

Microsoft.SharePoint.Administration.SPUrlZone

Specifies the Web application zone or zones for which to return the authentication provider.

The type must be any one of the valid zones: Default, Intranet, Internet, Extranet, or Custom.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPAuthenticationProvider cmdlet returns an authentication provider on a specified Web application zone. The following are the standard authentication providers available for SharePoint 2010 Products: NTLM, Classic NTLM, Negotiate, and Classic Negotiate.

Input Types

Return Types

Example

-----------------EXAMPLE1-----------------

Copy Code
New-SPWebApplication http://sharepointonline.com -AuthenticationProvider (Get- SPAuthenticationProvider "LiveID STS")

This example registers the LiveID STS authentication provider for the new Web application.

-----------------EXAMPLE2-----------------

Copy Code
New-SPWebApplication http://contoso.com -AuthenticationProvider (New- SPAuthenticationProvider -ASPNetMembershipProvider "myMembershipProvider" -ASPNetRoleProvider "myRoleProvider")

This example registers ASPNet for the new Web application. Note that ASPNET memberships are not persisted and must be re-created every use.

-----------------EXAMPLE3-----------------

Copy Code
New-SPWebApplication http://contoso.com -AuthenticationProvider (Get- SPAuthenticationProvider "NTLM")

This example registers the NTLM authentication provider for the new Web application. This command is equivalent to the command New-SPWebApplication http://contoso.com; NTLM is default authentication provider.

-----------------EXAMPLE4-----------------

Copy Code
$ip = @( (Get- SPAuthenticationProvider "LiveID STS"), (New- SPAuthenticationProvider -ASPNetMembershipProvider "myMembershipProvider" -ASPNetRoleProvider "myRoleProvider"), (Get-SPAuthenticationProvider "NTLM")) )
New-SPWebApplication http://contoso.com -AuthenticationProvider $ip

This example registers the NTLM, ASPNet, and LiveID STS authentication providers for the new Web application.

-----------------EXAMPLE5-----------------

Copy Code
New-SPWebApplication http://contoso.com -AuthenticationProvider (Get- SPAuthenticationProvider "Legacy NTLM")

This example registers the Legacy NTLM authentication provider for the new Web application.

See Also

Reference

New-SPAuthenticationProvider


Get-SPCertificateAuthority
Example
[image]

Published: May 12, 2010

Returns the SharePoint certificate authority (CA).

Get-SPCertificateAuthority [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPCertificateAuthority cmdlet returns the SharePoint certificate authority (CA).

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
$signingCert = (Get-SPServiceApplication | where $_.Name -eq 'SecurityTokenServiceApplication').SigningCertificate

This example gets the security token service (STS) identity provider signing certificate.


Get-SPClaimProvider
See Also Example
[image]

Published: May 12, 2010

Returns a claim provider.

Get-SPClaimProvider [[-Identity] <SPClaimProviderPipeBind>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPClaimProviderPipeBind

Specifies the claim provider to get.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a claim provider (for example, MyClaimProvider1); or an instance of a valid SPClaimProvider object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPClaimProvider cmdlet returns a claim provider.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Get-SPClaimProvider -Identity "MyClaimProvider" | Set-SPClaimProvider -Enabled $false

This example disables the claim provider MyClaimProvider.

See Also

Reference

New-SPClaimProvider
Set-SPClaimProvider
Remove-SPClaimProvider
Get-SPClaimProviderManager


Get-SPClaimProviderManager
See Also Example
[image]

Published: May 12, 2010

Returns a claim provider manager.

Get-SPClaimProviderManager [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPClaimProviderManager cmdlet reads a claim provider manager.

Input Types

Return Types

Example

Add code example.

Copy Code

  See Also
Reference
Get-SPClaimProvider
New-SPClaimProvider
Set-SPClaimProvider


Get-SPManagedAccount
See Also Example
[image]

Published: May 12, 2010

Retrieves accounts registered in the configuration database.

Get-SPManagedAccount [[-Identity] <SPManagedAccountPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-Service <SPServicePipeBind>]
Get-SPManagedAccount [[-Identity] <SPManagedAccountPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-WebApplication <SPWebApplicationPipeBind>]
Get-SPManagedAccount [[-Identity] <SPManagedAccountPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-Server <SPServerPipeBind>]

Parameters

1

Parameter

Required

Type

Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPManagedAccountPipeBind

Specifies the full name or partial name of the managed accounts to retrieve.

The type must be a valid account name, in the form Domain\User, or a GUID, in the form 1234-3456-09876.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Service

Optional

Microsoft.SharePoint.PowerShell.SPServicePipeBind

Specifies the scope to a service.

2

Parameter

Required

Type

Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPManagedAccountPipeBind

Specifies the full name or partial name of the managed accounts to retrieve.

The type must be a valid account name, in the form Domain\User, or a GUID, in the form 1234-3456-09876.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

WebApplication

Optional

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the scope to a Web application.

3

Parameter

Required

Type

Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPManagedAccountPipeBind

Specifies the full name or partial name of the managed accounts to retrieve.

The type must be a valid account name, in the form Domain\User, or a GUID, in the form 1234-3456-09876.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Server

Optional

Microsoft.SharePoint.PowerShell.SPServerPipeBind

Specifies the scope to a server.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Get-SPManagedAccount cmdlet returns the managed accounts that match the given scope. The scope can be any one of the following values: Web application, service, or server.

Input Types

Return Types

Example

--------------EXAMPLE-----------------

Copy Code
Get-SPManagedAccount

This example displays all the managed accounts in the farm.

See Also

Reference

New-SPManagedAccount
Set-SPManagedAccount
Remove-SPManagedAccount


Get-SPManagedPath
See Also Example
[image]

Published: May 12, 2010

Returns all managed paths that match the given criteria.

Get-SPManagedPath [[-Identity] <SPPrefixPipeBind>] -WebApplication <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>]
Get-SPManagedPath [[-Identity] <SPPrefixPipeBind>] -HostHeader <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

1

Parameter

Required

Type

Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPPrefixPipeBind

Specifies the URL or GUID of the managed path to return.

The type must be a valid URL, in the http://server_name or a valid GUID (for example, 12345678-90ab-cdef-1234-567890bcdefgh).

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the URL or GUID of the Web application from which to get the managed path.

The type must be a valid URL, in the form http://server_name, or a valid GUID (for example, 12345678-90ab-cdef-1234-567890bcdefgh).

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

2

Parameter

Required

Type

Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPPrefixPipeBind

Specifies the URL or GUID of the managed path to return.

The type must be a valid URL, in the http://server_name or a valid GUID (for example, 12345678-90ab-cdef-1234-567890bcdefgh).

HostHeader

Required

System.Management.Automation.SwitchParameter

If provided, the managed paths returned are for the HostHeader sites in the farm.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Get-SPManagedPath cmdlet returns the SharePoint managed path that matches the provided Identity for either a Web application, site collection or for all HostHeader site collections. If an Identity parameter is not provided, all managed paths for the given scope are returned.

HostHeader sites (no matter the Web application in which they are contained) share a single set of managed paths. Use the HostHeader parameter to return host header managed paths.

Input Types

Return Types

Example

--------------EXAMPLE 1-----------------

Copy Code
Get-SPManagedPath -WebApplication http://sitename

This example returns all managed paths for the specified Web application.

--------------EXAMPLE 2-----------------

Copy Code
Get-SPManagedPath -identity "Sites" -HostHeader

This example gets the Sites managed path from the HostHeader managed paths.

See Also

Reference

New-SPManagedPath
Remove-SPManagedPath


Get-SPSecurityTokenServiceConfig
See Also Example
[image]

Published: May 12, 2010

Returns the security token service (STS) for the farm.

Get-SPSecurityTokenServiceConfig [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPSecurityTokenServiceConfig cmdlet reads the security token service (STS) for the farm. An STS authenticates security tokens in incoming SOAP messages.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Set-SPSecurityTokenServiceConfig -ServiceTokenLifetime 1000

This example gets the security token service (STS) for the farm and sets the expiration for the service token cache to 1000 minutes.

See Also

Reference

Set-SPSecurityTokenServiceConfig


Get-SPServiceApplicationSecurity
See Also Example
[image]

Published: May 12, 2010

Returns the SPObjectSecurity object for a service application.

Get-SPServiceApplicationSecurity [-Identity] <SPServiceApplicationPipeBind> [-Admin <SwitchParameter>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationPipeBind

Specifies the service application to get.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a service application (for example, SearchServiceApp1); or an instance of a valid SPServiceApplication object.

Admin

Optional

System.Management.Automation.SwitchParameter

Returns the access control list (ACL) that contains the administrators list of the service application.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPServiceApplicationSecurity cmdlet returns a security object for the specified service application. Use this cmdlet with the Grant-SPObjectSecurity and Set-SPServiceApplicationSecurity cmdlets to manage security for a service application.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
$security = Get-SPServiceApplicationSecurity $serviceApp -Admin
Grant-SPObjectSecurity $security $principal "Full Control"
Set-SPServiceApplicationSecurity $serviceApp -Admin $security

This example retrieves the SPObjectSecurity object corresponding to the administrator ACL on a service application, and adds a new user principal to that ACL. The new user is an administrator for the service application $serviceApp.

See Also

Reference

Set-SPServiceApplicationSecurity
Grant-SPObjectSecurity
Revoke-SPObjectSecurity


Get-SPTrustedIdentityTokenIssuer
See Also Example
[image]

Published: May 12, 2010

Returns an identity provider.

Get-SPTrustedIdentityTokenIssuer [[-Identity] <SPTrustedIdentityTokenIssuerPipeBind>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPIdentityProviderPipeBind

Specifies the identity provider to get.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of identity provider (for example, LiveID STS); or an instance of a valid SPIdentityProvider object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPTrustedIdentityTokenIssuer cmdlet returns an identity provider.

Input Types

Return Types

Example

--------------------------EXAMPLE 1------------------------

Copy Code
$trustedsts = get - SPTrustedIdentityTokenIssuer "LiveIDSTS"

This example gets a trusted identity token issuer.

See Also

Reference

Set-SPTrustedIdentityTokenIssuer
New-SPTrustedIdentityTokenIssuer
Remove-SPTrustedIdentityTokenIssuer


Get-SPTrustedRootAuthority
See Also Example
[image]

Published: May 12, 2010

Returns a trusted root authority.

Get-SPTrustedRootAuthority [[-Identity] <SPTrustedRootAuthorityPipeBind>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPTrustedRootAuthorityPipeBind

Specifies the trusted root authority to get.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a trusted root authority (for example, WFEFarm1); or an instance of a valid SPTrustedRootAuthority object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPTrustedRootAuthority cmdlet returns a trusted root authority. If a certificate file is used, it must have only one X509 certificate without private keys, otherwise an exception is raised.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
$rootauthority = Get-SPTrustedRootAuthority -Identity "WFEFarm1"

This example creates a new trusted root authority, WFEFarm1.

See Also

Reference

New-SPTrustedRootAuthority
Set-SPTrustedRootAuthority
Remove-SPTrustedRootAuthority


Get-SPTrustedServiceTokenIssuer
See Also Example
[image]

Published: May 12, 2010

Returns the object that represents the farm trust.

Get-SPTrustedServiceTokenIssuer [[-Identity] <SPTrustedServiceTokenIssuerPipeBind>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPTrustedServiceTokenIssuerPipeBind

Specifies the trusted service token issuer to get.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a trusted service token issuer (for example, WFEFarm1); or an instance of a valid SPTrustedRootAuthority object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPTrustedServiceTokenIssuer cmdlet returns the object that represents the farm trust.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Get-SPTrustedServiceTokenIssuer "WFEFarm1"

This example gets the trusted services token issuer WFEFarm1.

See Also

Reference

Set-SPTrustedServiceTokenIssuer
New-SPTrustedServiceTokenIssuer
Remove-SPTrustedServiceTokenIssuer


Grant-SPObjectSecurity
See Also Example
[image]

Published: May 12, 2010

Adds a new security principal to an SPObjectSecurity object.

Grant-SPObjectSecurity [-Identity] <SPObjectSecurity> [-Principal] <SPClaim> [-Rights] <String[]> [-AssignmentCollection <SPAssignmentCollection>] [-Replace <SwitchParameter>]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.Administration.AccessControl.SPObjectSecurity

Specifies the SPObjectSecurity object to which the new security principal is added. You can use the Get-SPServiceApplicationSecurity cmdlet to get a SPObjectSecurity object .

Principal

Required

Microsoft.SharePoint.Administration.Claims.SPClaim

Specifies the principal to whom the rights apply.

The type must a valid name a principal; for example, Full Control.

Rights

Required

System.String[]

Specifies the rights granted to the principal.

The type must a valid array of strings that represents the rights granted to the principal.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Replace

Optional

System.Management.Automation.SwitchParameter

Replaces the existing rights on the SPObjectSecurity object with the new rights specified. If this parameter is not specified, the new rights are added to the existing rights.

Detailed Description

The Grant-SPObjectSecurity cmdlet adds a new security principal, such as a user, to a SPObjectSecurity object. An SPObjectSecurity object is a common object that is used to represent the security access control list (ACL) of SharePoint administrative objects, in particular, service applications.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
$security = Get-SPServiceApplicationSecurity $serviceApp -Admin
Grant-SPObjectSecurity $security $principal "Full Control"
Set-SPServiceApplicationSecurity $serviceApp -Admin $security

This example retrieves the SPObjectSecurity object corresponding to the administrator ACL on a service application, and adds a new user principal to that ACL. The new user is an administrator for the service application $serviceApp.

See Also

Reference

Revoke-SPObjectSecurity
Get-SPServiceApplicationSecurity


Initialize-SPResourceSecurity
Example
[image]

Published: May 12, 2010

Enforces resource security on the local server.

Initialize-SPResourceSecurity [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Initialize-SPResourceSecurity cmdlet enforces resource security on the local server. This cmdlet enforces security for all resources, including files, folders, and registry keys.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Initialize-SPResourceSecurity

This example enforces resource security on the local server.


New-SPAuthenticationProvider
See Also Example
[image]

Published: May 12, 2010

Creates a new Authentication provider in the farm.

New-SPAuthenticationProvider [-AllowAnonymous <SwitchParameter>] [-AssignmentCollection <SPAssignmentCollection>] [-DisableKerberos <SwitchParameter>] [-UseBasicAuthentication <SwitchParameter>] [-UseWindowsIntegratedAuthentication <SwitchParameter>]
New-SPAuthenticationProvider -ASPNETMembershipProvider <String> -ASPNETRoleProviderName <String> [-AssignmentCollection <SPAssignmentCollection>]
New-SPAuthenticationProvider -TrustedIdentityTokenIssuer <SPTrustedIdentityTokenIssuerPipeBind> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

1

Parameter

Required

Type

Description

AllowAnonymous

Optional

System.Management.Automation.SwitchParameter

Specifies whether the Web application allows anonymous access.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

DisableKerberos

Optional

System.Management.Automation.SwitchParameter

Specifies whether the Web application disables Kerberos authentication.

UseBasicAuthentication

Optional

System.Management.Automation.SwitchParameter

Specifies whether the Web application uses basic authentication.

UseWindowsIntegratedAuthentication

Optional

System.Management.Automation.SwitchParameter

Specifies whether the Web application uses Windows Integrated Authentication.

2

Parameter

Required

Type

Description

ASPNETMembershipProvider

Required

System.String

Specifies the name of the membership provider.

The type must be a valid name of an ASPNet membership provider; for example, myMembershipProvider.

ASPNETRoleProviderName

Required

System.String

Specifies the name of the role provider.

The type must be a valid name of an ASPNet role provider; for example, myRoleProvider.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

3

Parameter

Required

Type

Description

TrustedIdentityTokenIssuer

Required

Microsoft.SharePoint.PowerShell.SPTrustedIdentityTokenIssuerPipeBind

Specifies the identity of the authentication provider.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a TrustedIdentityTokenIssuer (for example, myRoleProvider); or an instance of a valid SPTrustedIdentityTokenIssuer object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The New-SPAuthenticationProvider cmdlet creates a new Authentication provider in the farm.

NTLM, Classic NTLM, Negotiate, and Classic Negotiate can be set only in a Web Application.

For ASP.NET Membership Provider or Role providers, no objects are persisted. The object is created and used for setting this type of Authentication provider in a Web application.

For STS Authentication providers, an object is created and persisted in the SPFarm object.

Using classic NTLM with any claims based authentication type is not allowed.

Input Types

Return Types

Example

---------------------------EXAMPLE1------------------

Copy Code
$ap = New - SPAuthenticationProvider -UseWindowsIntegratedAuthentication
Copy Code
Set-SPWebApplication -Name "Claims Windows Web App" -ApplicationPool "Claims App Pool" -ApplicationPoolAccount "redmond\appool" -Url http://servername -Port 80 -AuthenticationProvider $ap

This example creates a Windows-claims authentication provider

---------------------------EXAMPLE2------------------

Copy Code
$ap = New-SPAuthenticationProvider -ASPNETMembershipProvider "membership" -ASPNETRoleProviderName "rolemanager"
Copy Code
Set-SPWebApplication -Name "Claims Windows Web App" -ApplicationPool "Claims App Pool" -ApplicationPoolAccount "redmond\appool" -Url http://servername -Port 80 -AuthenticationProvider $ap

This example creates an ASP.net membership role provider authentication provider.

---------------------------EXAMPLE3------------------

Copy Code
$ap = New - SPAuthenticationProvider -TrustedIdentityTokenIssuer | Get-SPTrustedIdentityTokenIssuer "LiveIDSTS"
Copy Code
Set-SPWebApplication -Name "Claims Windows Web App" -ApplicationPool "Claims App Pool" -ApplicationPoolAccount "redmond\appool" -Url http://servername -Port 80 -AuthenticationProvider $ap

This example creates a trusted token issuer authentication provider.

See Also

Reference

New-SPAuthenticationProvider


New-SPClaimProvider
See Also Example
[image]

Published: May 12, 2010

Registers a new claim provider in the farm.

New-SPClaimProvider -AssemblyName <String> -Description <String> -DisplayName <String> -Type <String> [-AssignmentCollection <SPAssignmentCollection>] [-Default <SwitchParameter>] [-Enabled <SwitchParameter>]

Parameters

Parameter Required Type Description

AssemblyName

Required

System.String

The type must be a valid name of an assembly; for example, ClaimAssembly1.

Specifies the name of the assembly with the claim provider.

Description

Required

System.String

Specifies the description of the claim provider.

The type must be a valid name of an assembly; for example, ClaimAssembly1.

DisplayName

Required

System.String

Specifies the display name of the new claim provider.

The type must be a valid name of a claim provider; for example, ClaimProvider1.

Type

Required

System.String

Specifies the type of the claim.

The type must be a valid name of a claim type; for example MyClaimProvider.Providers.CustomProvider.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Default

Optional

System.Management.Automation.SwitchParameter

Specifies that the claim provider applies to all Web applications and zones.

Enabled

Optional

System.Management.Automation.SwitchParameter

Turns on the claim provider.

Detailed Description

The New-SPClaimProvider cmdlet registers a new claim provider in the farm.

Input Types

Return Types

Example

------------------EXAMPLE 1------------------

Copy Code
New-SPClaimProvider -Name "MyClaimProvider" -Type "MyClaimProvider.Providers.CustomProvider" -AllWebApplications

This example registers a claim provider in the farm.

------------------EXAMPLE 2------------------

Copy Code
New-SPClaimProvider -Name "MyClaimProvider" -Type "MyClaimProvider.Providers.CustomProvider" -Scope (Get-SPWebApplication http://test)

This example registers a claim provider scoped to a given Web application.

See Also

Reference

Get-SPClaimProvider
Set-SPClaimProvider
Remove-SPClaimProvider


New-SPClaimsPrincipal
Example
[image]

Published: May 12, 2010

Creates a claims principal.

New-SPClaimsPrincipal [-Identity] <String> [-IdentityType] <WindowsSamAccountName | WindowsSecurityGroupName | WindowsSecurityGroupSid | FormsUser | FormsRole | EncodedClaim> [-AssignmentCollection <SPAssignmentCollection>]
New-SPClaimsPrincipal [-Identity] <String> [-TrustedIdentityTokenIssuer] <SPTrustedIdentityTokenIssuerPipeBind> [-AssignmentCollection <SPAssignmentCollection>]
New-SPClaimsPrincipal [-ClaimValue] <String> [[-ClaimType] <String>] [-TrustedIdentityTokenIssuer] <SPTrustedIdentityTokenIssuerPipeBind> [[-IdentifierClaim] <SwitchParameter>] [-AssignmentCollection <SPAssignmentCollection>]
New-SPClaimsPrincipal [-EncodedClaim] <String> [-AssignmentCollection <SPAssignmentCollection>]
New-SPClaimsPrincipal [-ClaimValue] <String> [-ClaimType] <String> [-ClaimProvider] <SPClaimProvider> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

System.String

Specifies the name of the new claims principal.

The type must be a valid name of a claims principal.

IdentityType

Required

Microsoft.SharePoint.Administration.Claims.SPIdentifierTypes

Specifies the type of the new claims principal.

The type must be one of the following: WindowsSamAccountName, WindowsSecurityGroupSid, FormsUser, FormsRole, or EncodedClaim.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

2

Parameter

Required

Type

Description

Identity

Required

System.String

Specifies the name of the new claims principal.

The type must be a valid name of a claims principal.

TrustedIdentityTokenIssuer

Required

Microsoft.SharePoint.PowerShell.SPTrustedIdentityTokenIssuerPipeBind

Specifies the ID of the authentication provider.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of an Authentication provider (for example, MyAuthprovider1); or an instance of a valid SPTrustedIdentityTokenIssuer object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

3

Parameter

Required

Type

Description

ClaimValue

Required

System.String

Specifies the claim value of the claims object. The claims value specifies the user, group, or computer that the claim is authenticating.

The type must be a valid claim value; for example, john@contoso.com.

ClaimType

Required

System.String

Specifies the type of claim to create. The value I indicates a unique user identity claim, and the value C indicates all other claims.

The type must be either of the following values: I or C.

TrustedIdentityTokenIssuer

Required

Microsoft.SharePoint.PowerShell.SPTrustedIdentityTokenIssuerPipeBind

Specifies the ID of the authentication provider.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of an Authentication provider (for example, MyAuthprovider1); or an instance of a valid SPTrustedIdentityTokenIssuer object.

IdentifierClaim

Optional

System.Management.Automation.SwitchParameter

Specifies if the new claim is an identity claim.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

4

Parameter

Required

Type

Description

EncodedClaim

Required

System.String

Converts a simple claim to a full encoded claim.

The type must be a valid claim value; for example, i:001w|redmond\user.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

5

Parameter

Required

Type

Description

ClaimValue

Required

System.String

Specifies the claim value of the claims object. The claims value specifies the user, group, or computer that the claim is authenticating.

The type must be a valid claim value; for example, john@contoso.com.

ClaimType

Required

System.String

Specifies the type of claim to create. The value I indicates a unique user identity claim, and the value C indicates all other claims.

The type must be either of the following values: I or C.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The New-SPClaimsPrincipal cmdlet creates a claims principal.

Input Types

Return Types

Example

-------------------------EXAMPLE 1-----------------------------

Copy Code
New-SPSite http://sitename/sites/newsite -owner (New-SPClaimsPrincipal contoso\johndoe -TrustedIdentityTokenIssuer "NTLM")

This example creates a claim principal for a Windows user.

-------------------------EXAMPLE 2-----------------------------

Copy Code
New-SPSite http://localhost/sites/newsite -owner (New-SPClaimsPrincipal contoso\allusers -TrustedIdentityTokenIssuer "NTLM")

This example creates a claim principal for a Windows group.

-------------------------EXAMPLE 3-----------------------------

Copy Code
New-SPSite http://sitename/sites/newsite -owner (New-SPClaimsPrincipal -ClaimValue "john@contoso.com" -ClaimType Email -TrustedIdentityTokenIssuer "LiveID STS" -IdentifierClaim Yes)

This example creates a claim principal for a trusted identity token issuer claim.

-------------------------EXAMPLE 4-----------------------------

Copy Code
$ip = New-SPIdentityProvider -ASPNetMembershipProvider "myMembershipProvider" -ASPNetRoleProvider "myRoleProvider"
Copy Code
New-SPSite http://sitename/sites/newsite -owner (New-SPClaimsPrincipal "john@contoso.com" -TrustedIdentityTokenIssuer $ip)

This example creates a claim principal for a ASPNet Membership User.

-------------------------EXAMPLE 5-----------------------------

Copy Code
New-SPSite http://sitename/sites/newsite -owner (New-SPClaimsPrincipal "Sales Manager Role" -IdentityProvider "myRoleProvider")

This example creates a claim principal for a ASPNet Role.

-------------------------EXAMPLE 6-----------------------------

Copy Code
 $cp = New-SPClaimsPrincipal -Identity "redmond\SiteOwner" -IdentityType 1
Copy Code
New-SPSite http://servername:port -OwnerAlias $cp.ToEncodedString() -Template "STS#0"

This example creates a claim principal for a Basic Claim Role, which is also called an encoded claim).


New-SPClaimTypeMapping
See Also Example
[image]

Published: May 12, 2010

Creates a claim mapping rule for a security token service (STS) identity provider.

New-SPClaimTypeMapping [-IncomingClaimType] <String> [-IncomingClaimTypeDisplayName] <String> [[-LocalClaimType] <String>] [-AssignmentCollection <SPAssignmentCollection>] [-SameAsIncoming <SwitchParameter>]

Parameters

Parameter Required Type Description

IncomingClaimType

Required

System.String

Specifies the URI of the incoming claim type.

The type must be a valid URI, in the form http://schemas.microsoft.com/email.

IncomingClaimTypeDisplayName

Required

System.String

Specifies the display name of the incoming claim type.

The type must be a valid name of an incoming claim type; for example, Email.

LocalClaimType

Optional

System.String

Specifies the URI of the local claim type. If the SameAsIncoming parameter is False, this is a required parameter.

The type must be a valid URI, in the form http://schemas.microsoft.com/email.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

SameAsIncoming

Optional

System.Management.Automation.SwitchParameter

Specifies that the claim type specified in the IncomingClaimType parameter is used for the LocalClaimType parameter.

Detailed Description

The New-SPClaimTypeMapping cmdlet creates a claim mapping rule for a security token service (STS) identity provider.

Input Types

Return Types

Example

--------------------EXAMPLE 1----------------------------

Copy Code
$map1 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
Copy Code
$map2 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" -IncomingClaimTypeDisplayName "PUID" -LocalClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/thumbprint"
Copy Code
New-SPTrustedIdentityTokenIssuer -Name "LiveIDSTS" -Description "LiveID Provider" -Realm "urn:domain.company.com" -ImportTrustCertificate $cert -ClaimsMappings $map1[,$map2..] -SignInUrl "https://login.live.com/login.srf" -IdentifierClaim $map2.InputClaimType

This example creates a claim map from an incoming token to a SharePoint token.

See Also

Reference

Add-SPClaimTypeMapping
Remove-SPClaimTypeMapping


New-SPManagedAccount
See Also Example
[image]

Published: May 12, 2010

Registers a new managed account.

New-SPManagedAccount [-Credential] <PSCredential> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Credential

Required

System.Management.Automation.PSCredential

Indicates the Credential object that specifies the credentials of the new managed account. If you use Credential, you cannot specify Username and Password.

Password

Required

System.Security.SecureString

Specifies the password for the user specified in Username. If you use Credential, you cannot specify Username and Password.

Username

Required

System.String

Specifies the user name of the new managed account. If you use Credential, you cannot specify Username and Password.

The type must be a valid user name, in the form domain\username.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The New-SPManagedAccount cmdlet registers a new managed account for the specified Credential or Username, and Password.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
$cred = Get-Credential
Copy Code
New-SPManagedAccount -Credential $cred

This example adds a new managed account to the farm by using credentials that are prompted.

See Also

Reference

Get-SPManagedAccount
Set-SPManagedAccount
Remove-SPManagedAccount


New-SPManagedPath
See Also Example
[image]

Published: May 12, 2010

Creates a new managed path for the given Web application for all host header site collections.

New-SPManagedPath [-RelativeURL] <String> -WebApplication <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Explicit <SwitchParameter>] [-WhatIf [<SwitchParameter>]]
New-SPManagedPath [-RelativeURL] <String> -HostHeader <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Explicit <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

RelativeURL

Required

System.String

Specifies the relative URL for the new managed path.

The type must be a valid partial URL such as site or sites/teams/.

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the Web application group to add this path.

The type must be a valid URL, in the form http://server_name, or a GUID, in the form 1234-5678-0987645a.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Explicit

Optional

System.Management.Automation.SwitchParameter

Specifies whether the managed path is explicit or wildcard.

If not provided, the managed path is a wildcard path.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

RelativeURL

Required

System.String

Specifies the relative URL for the new managed path.

The type must be a valid partial URL such as site or sites/teams/.

HostHeader

Required

System.Management.Automation.SwitchParameter

If this parameter is provided, this managed path applies to all host header site collections.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Explicit

Optional

System.Management.Automation.SwitchParameter

Specifies whether the managed path is explicit or wildcard.

If not provided, the managed path is a wildcard path.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The New-SPManagedPath cmdlet adds a new managed path to a given Web application or for use with all host header site collections. If the HostHeader switch is provided, the managed path is shared among all host header site collections; otherwise, a Web application must be specified to create this managed path within. The relative URL is a partial URL that represents the managed path. When the slash mark (/) is used, the root is defined. If the Explicit parameter is not provided, the new managed path is a wildcard path.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
New-SPManagedPath "Teams" -WebApplication "http://somesite"

This example creates a Teams managed path for a given Web application (http://somesite).

See Also

Reference

Get-SPManagedPath
Remove-SPManagedPath


New-SPTrustedIdentityTokenIssuer
See Also Example
[image]

Published: May 12, 2010

Creates an identity provider in the farm.

New-SPTrustedIdentityTokenIssuer -ClaimsMappings <SPClaimMappingPipeBind[]> -Description <String> -IdentifierClaim <String> -Name <String> -Realm <String> -SignInUrl <String> [-AssignmentCollection <SPAssignmentCollection>] [-ClaimProvider <SPClaimProviderPipeBind>] [-ImportTrustCertificate <X509Certificate2>] [-UseWReply <SwitchParameter>]

Parameters

Parameter Required Type Description

ClaimsMappings

Required

Microsoft.SharePoint.PowerShell.SPClaimMappingPipeBind[]

Specifies the mapping of the claims from the original token to the SharePoint token.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of a claim mapping rule (for example, Email); or an instance of a valid SPClaimMapping object.

Description

Required

System.String

Specifies a description for the new identity provider.

The type must be a valid string; for example, LiveID STS.

IdentifierClaim

Required

System.String

Specifies which claim type from the trusted STS will be used for the new identity provider.

The type must be a valid claim type from the trusted STS; for example, http://schemas.microsoft.com/2007/05/Claims/Puid.

Name

Required

System.String

Specifies the name of the new identity provider.

The type must be a valid name of an identity provider; for example, LiveIDSTS.

Realm

Required

System.String

Specifies the realm, or resource partition, associated with this trust.

The type must be a name of a valid realm; for example, MD_REALM.

SignInUrl

Required

System.String

Specifies the sign-in URLs for this trusted STS identity provider.

The type must be a valid URL, in the form http://int.live.com/.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

ClaimProvider

Optional

Microsoft.SharePoint.PowerShell.SPClaimProviderPipeBind

Specifies the IP STS that can resolve and search claims for claims people picker.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of identity provider (for example, MyIDprovider1); or an instance of a valid SPIdentityProvider object.

ImportTrustCertificate

Optional

System.Security.Cryptography.X509Certificates.X509Certificate2

Specifies the X.509 certificate object from trusted authentication provider farm.

The type must be a name of a valid X.509 certificate; for example, Certificate1.

UseWReply

Optional

System.Management.Automation.SwitchParameter

Includes a WReply with the token request. WReply is a URL at the relying party to which the requestor is redirected once sign-out processing is complete.

Detailed Description

The New-SPTrustedIdentityTokenIssuer cmdlet creates an identity provider in the farm. This object is created and used only for setting this type of identity provider in a Web application. The specified claim type cannot be NTLM, Classic NTLM, Negotiate, or Classic Negotiate. For ASP.NET Membership provider or Role providers, no objects are persisted. For security token service (STS) identity providers, this cmdlet creates and persists the identity provider object in the SPFarm object.

Input Types

Return Types

Example

----------------------- EXAMPLE---------------------------

Copy Code
New-SPTrustedIdentityTokenIssuer -Name "LiveIDSTS" - Description "LiveID STS" -Certificate (Get-ChildItem"cert:Certificates (LocalComputer)\Personal\Certificates -Name "LiveID Cert") -SignInUrl http://int.contoso.com/ -IdentifierClaim "http://schemas.contoso.com/2007/05/Claims/Puid"
Copy Code
Set -SPWebApplication http://contoso.com -IdentityProvider (Get-SPTrustedIdentityTokenIssuer "LiveIDSTS")

This example creates a new identity provider in the farm named LiveIDSTS.

See Also

Reference

Get-SPTrustedIdentityTokenIssuer
Set-SPTrustedIdentityTokenIssuer
Remove-SPTrustedIdentityTokenIssuer


New-SPTrustedRootAuthority
See Also Example
[image]

Published: May 12, 2010

Creates a trusted root authority.

New-SPTrustedRootAuthority [-Name] <String> -Certificate <X509Certificate2> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Name

Required

System.String

Specifies the name of the trusted root authority to create.

The type must be a valid name of a trusted root authority; for example, WFEFarm1.

Certificate

Required

System.Security.Cryptography.X509Certificates.X509Certificate2

Specifies the X.509 certificate of the trusted root authority.

The type must be a name of a valid X.509 certificate; for example, Certificate1.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The New-SPTrustedRootAuthority cmdlet creates a trusted root authority. If a certificate file is used, it must have only one X509 certificate without private keys, otherwise an exception is raised.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
$cert = Get-PfxCertificate C:\LiveIDSigningCert.pfx
New-SPTrustedRootAuthority -Name "WFEFarm1" -Certificate $cert

This example creates a new trusted root authority, WFEFarm1.

See Also

Reference

Get-SPTrustedRootAuthority
Set-SPTrustedRootAuthority
Remove-SPTrustedRootAuthority


New-SPTrustedServiceTokenIssuer
See Also Example
[image]

Published: May 12, 2010

Creates a trust with a SharePoint farm.

New-SPTrustedServiceTokenIssuer [-Name] <String> -Certificate <X509Certificate2> [-AssignmentCollection <SPAssignmentCollection>] [-Description <String>]

Parameters

Parameter Required Type Description

Name

Required

System.String

Specifies the name of the trust.

The type must be a valid name of a trusted service issuer; for example, WFEFarmTrust1.

Certificate

Required

System.Security.Cryptography.X509Certificates.X509Certificate2

The type must be a name of a valid X.509 certificate; for example, Certificate1.

Specifies the X.509 certificate object from trusted authentication provider farm.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Description

Optional

System.String

Specifies a description for the trust.

The type must be a valid string; for example, WFE Farm Trust1.

Detailed Description

The New-SPTrustedServiceTokenIssuer cmdlet creates a trust with a SharePoint farm. If a certificate file is used, it must have only one X509 certificate without private keys, otherwise an exception is raised.

Input Types

Return Types

Example

------------------EXAMPLE 1------------------

Copy Code
$cert = Get-PfxCertificate C:\LiveIDSigningCert.pfx
Copy Code
New-SPTrustedServiceTokenIssuer -Name "WFEFarm1" -Description "WFE Farm 1" -Certificate $cert

This example shows how to create a new SharePoint Farm trust using the trust certificate from a file.

See Also

Reference

Get-SPTrustedServiceTokenIssuer
Set-SPTrustedServiceTokenIssuer
Remove-SPTrustedServiceTokenIssuer


Remove-SPClaimProvider
See Also Example
[image]

Published: May 12, 2010

Unregisters a claim provider.

Remove-SPClaimProvider [-Identity] <SPClaimProviderPipeBind> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPClaimProviderPipeBind

Specifies the claim provider to unregister.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a claim provider (for example, MyClaimProvider1); or an instance of a valid SPClaimProvider object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Remove-SPClaimProvider cmdlet unregisters a claim provider. If the unregistered claim provider was assigned to a trusted identity token issuer, the trusted token issuer will use the default (system) claim provider.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Remove - SPClaimProvider -Identity "12345678-90ab-cdef-1234-567890bcdefgh"

This example removes a claim provider from the farm

See Also

Reference

Get-SPClaimProvider
New-SPClaimProvider
Set-SPClaimProvider


Remove-SPClaimTypeMapping
See Also Example
[image]

Published: May 12, 2010

Deletes a claim type mapping rule for a security token service (STS) identity provider.

Remove-SPClaimTypeMapping [-Identity] <SPClaimMappingPipeBind> [-TrustedIdentityTokenIssuer] <SPTrustedIdentityTokenIssuerPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPClaimMappingPipeBind

Specifies the claim mapping to delete.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of a claim mapping rule (for example, Email); or an instance of a valid SPClaimMapping object.

IdentityProvider

Required

Microsoft.SharePoint.PowerShell.SPIdentityProviderPipeBind

Specifies the farm trust identity provider STS that contains the claim mapping rule.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of identity provider (for example, LiveIDSTS); or an instance of a valid SPIdentityProvider object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Remove-SPClaimMapping cmdlet deletes a claim type mapping rule from a farm trust STS identity provider.

Input Types

Return Types

Example

--------------------EXAMPLE-------------------------

Copy Code
Remove-SPClaimMapping "Email" | Get-SPIdentityProvider "LiveIDSTS"

This example removes an identity provider named LiveIDSTS.

See Also

Reference

Add-SPClaimTypeMapping
New-SPClaimTypeMapping


Remove-SPManagedAccount
See Also Example
[image]

Published: May 12, 2010

Removes a managed account registration from the farm.

Remove-SPManagedAccount [-Identity] <SPManagedAccountPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]
Remove-SPManagedAccount [-Identity] <SPManagedAccountPipeBind> -NewPassword <SecureString> [-AssignmentCollection <SPAssignmentCollection>] [-ChangePassword <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPManagedAccountPipeBind

Specifies the full name or partial name of the managed accounts to retrieve.

The type must be a valid account name, in the form Domain\User, or a GUID, in the form 1234-3456-09876.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPManagedAccountPipeBind

Specifies the full name or partial name of the managed accounts to retrieve.

The type must be a valid account name, in the form Domain\User, or a GUID, in the form 1234-3456-09876.

NewPassword

Required

System.Security.SecureString

Specifies a secure string for the new password (that is, $MySecureString).Works in conjunction with the ChangePassword parameter.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

ChangePassword

Optional

System.Management.Automation.SwitchParameter

Specifies whether a password is to be changed. Works in conjunction with the NewPassword parameter. When the ChangePassword value is set, a secure string value is required for the NewPassword parameter (that is, $MySecureString).

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Remove-SPManagedAccount cmdlet removes account registration from the configuration database within the farm.

Input Types

Return Types

Example

----------------------EXAMPLE-------------------

Copy Code
Remove-SPManagedAccount -Identity DOMAIN\ServiceAcct

This example removes the DOMAIN\ServiceAcct managed account from the farm.

See Also

Reference

Get-SPManagedAccount
New-SPManagedAccount
Set-SPManagedAccount


Remove-SPManagedPath
See Also Example
[image]

Published: May 12, 2010

Deletes the specified managed path from the specified host header or Web application.

Remove-SPManagedPath [-Identity] <SPPrefixPipeBind> -WebApplication <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]
Remove-SPManagedPath [-Identity] <SPPrefixPipeBind> -HostHeader <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPPrefixPipeBind

Specifies the name of the managed path to delete. For example, in the URL http://sitename/sites/site1, "sites" is the name of the managed path.

WebApplication

Required

Microsoft.SharePoint.PowerShell.WebApplicationPipeBind

Specifies the identity of the Web application that hosts the managed path to delete. The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid Web application name (for example, WebApplication1212); or a valid name, in the form WebApp2423.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPPrefixPipeBind

Specifies the name of the managed path to delete. For example, in the URL http://sitename/sites/site1, "sites" is the name of the managed path.

HostHeader

Required

System.Management.Automation.SwitchParameter

Specifies that the Identity is a host header managed path.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Remove-SPManagedPath cmdlet deletes the managed path specified by the Identity parameter from the host header or the Web application. The Identity must be the partial URL of the managed path to be deleted.

If you are using host headers, specify the HostHeader parameter. To delete a HostHeader managed path, provide the HostHeader switch. Otherwise, you must specify the Web application that contains the managed path to be deleted.

Input Types

Return Types

Example

----------------------EXAMPLE 1----------------------------

Copy Code
Remove-SPManagedPath "sites" -HostHeader

This example removes the sites managed path from the list of HostHeader managed paths.

Depending on the confirmation level of the local system, the preceding example can prompt prior to execution.

------------------EXAMPLE 2-----------------------

Copy Code
Get-SPWebApplication | Remove-SPManagedPath "personal" -confirm:$false

This example removes the personal managed path from all Web applications in the farm. This command does not prompt for confirmation.

See Also

Reference

Get-SPManagedPath
New-SPManagedPath


Remove-SPTrustedIdentityTokenIssuer
See Also Example
[image]

Published: May 12, 2010

Deletes a security token service (STS) identity provider from the farm.

Remove-SPTrustedIdentityTokenIssuer [-Identity] <SPTrustedIdentityTokenIssuerPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPTrustedIdentityTokenIssuerPipeBind

Specifies the identity provider to remove.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of identity provider (for example, LiveID STS); or an instance of a valid SPIdentityProvider object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPTrustedIdentityTokenIssuer cmdlet deletes a security token service (STS) identity provider from the farm.

Input Types

Return Types

Example

-----------------------------EXAMPLE----------------------------

Copy Code
Remove-SPTrustedIdentityTokenIssuer "LiveIDSTS"

This example removes an identity provider named LiveIDSTS from the farm.

See Also

Reference

Get-SPTrustedIdentityTokenIssuer
Set-SPTrustedIdentityTokenIssuer
New-SPTrustedIdentityTokenIssuer


Remove-SPTrustedRootAuthority
See Also Example
[image]

Published: May 12, 2010

Deletes a trusted root authority.

Remove-SPTrustedRootAuthority [-Identity] <SPTrustedRootAuthorityPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPTrustedRootAuthorityPipeBind

Specifies the trusted root authority to delete.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a trusted root authority (for example, WFEFarm1); or an instance of a valid SPTrustedRootAuthority object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Remove-SPTrustedRootAuthority cmdlet deletes a trusted root authority from a signing certificate store.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Remove - SPTrustedRootAuthority -Name "WFEFarm1"

This example removes the trusted root authority WFEFarm1.

See Also

Reference

New-SPTrustedRootAuthority
Get-SPTrustedRootAuthority
Set-SPTrustedRootAuthority


Remove-SPTrustedServiceTokenIssuer
See Also Example
[image]

Published: May 12, 2010

Deletes the object that represents the farm trust.

Remove-SPTrustedServiceTokenIssuer [-Identity] <SPTrustedServiceTokenIssuerPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPTrustedServiceTokenIssuerPipeBind

Specifies the trusted service token issuer to delete.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a trusted service token issuer (for example, WFEFarm1); or an instance of a valid SPTrustedRootAuthority object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Remove-SPTrustedServiceTokenIssuer cmdlet deletes the object that represents the farm trust.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Remove - SPTrustedServiceTokenIssuer "WFE Farm 2"

This example deletes the trusted service token issuer WFE Farm 2.

See Also

Reference

Set-SPTrustedServiceTokenIssuer
New-SPTrustedServiceTokenIssuer
Get-SPTrustedServiceTokenIssuer


Repair-SPManagedAccountDeployment
Example
[image]

Published: May 12, 2010

Repairs the local managed account credential deployment.

Repair-SPManagedAccountDeployment [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

Use the Repair-SPManagedAccountDeployment cmdlet to repair the local deployment of managed account credentials deployment on a server for the rare cases that the managed accounts service credentials are in a broken state. It re-deploys each local service and Web applications credentials and also determines if the passphrase is not correct on the server and repairs provides warnings accordingly. The Repair-SPManagedAccountDeployment cmdlet should not be used as part of the regular credential update process, but should be one of the first troubleshooting steps, specifically if a servers' services are failing to start when other servers' services are working correctly.

Input Types

Return Types

Example

----------EXAMPLE-----------

Copy Code
Repair-SPManagedAccountDeployment

This example repairs the deployment of credentials on all services and Web application associated with managed account (s) on the local server.


Revoke-SPObjectSecurity
See Also Example
[image]

Published: May 12, 2010

Removes a security principal from a SPObjectSecurity object.

Revoke-SPObjectSecurity [-Identity] <SPObjectSecurity> [-Principal] <SPClaim> [[-Rights] <String[]>] [-AssignmentCollection <SPAssignmentCollection>]
Revoke-SPObjectSecurity [-Identity] <SPObjectSecurity> -All <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.Administration.AccessControl.SPObjectSecurity

Specifies the SPObjectSecurity object from which the security principal is removed. You can use the Get-SPServiceApplicationSecurity cmdlet to get a SPObjectSecurity object .

Principal

Required

Microsoft.SharePoint.Administration.Claims.SPClaim

Specifies the principal for whom the rights are removed.

The type must a valid name a principal; for example, Full Control.

Rights

Optional

System.String[]

Specifies the rights of the principal to revoke.

The type must a valid array of strings that represents the rights of the principal to revoke.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.Administration.AccessControl.SPObjectSecurity

Specifies the SPObjectSecurity object from which the security principal is removed. You can use the Get-SPServiceApplicationSecurity cmdlet to get a SPObjectSecurity object .

All

Required

System.Management.Automation.SwitchParameter

Specifies that all security principals are removed from the specified SPObjectSecurity object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Revoke-SPObjectSecurity cmdlet to remove a security principal, such as a user, from a SPObjectSecurity object. An SPObjectSecurity object is a common object that is used to represent the security access control list (ACL) of SharePoint administrative objects, in particular service applications.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
$security = Get-SPServiceApplicationSecurity $serviceApp -Admin
Revoke-SPObjectSecurity $security "domain\user"
Set-SPServiceApplicationSecurity $serviceApp -Admin $security

This example retrieves the SPObjectSecurity object corresponding to the administrator ACL on a service application, and removes a user from that ACL. The removed an administrator for the service application $serviceApp.

See Also

Reference

Grant-SPObjectSecurity
Get-SPServiceApplicationSecurity


Set-SPClaimProvider
See Also Example
[image]

Published: May 12, 2010

Updates registration of a claims provider.

Set-SPClaimProvider [-Identity] <SPClaimProviderPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Default <SwitchParameter>] [-Enabled <SwitchParameter>]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPClaimProviderPipeBind

Specifies the claim provider to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a claim provider (for example, MyClaimProvider1); or an instance of a valid SPClaimProvider object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Default

Optional

System.Management.Automation.SwitchParameter

Specifies that the claim provider applies to all Web applications and zones.

Enabled

Optional

System.Management.Automation.SwitchParameter

Turns on the claim provider.

Detailed Description

The Set-SPClaimProvider cmdlet updates registration of a claims provider.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Set-SPClaimProvider -Identity "12345678-90ab-cdef-1234-567890bcdefgh"

This example turns off the specified claim provider.

See Also

Reference

Get-SPClaimProvider
Remove-SPClaimProvider
New-SPClaimProvider


Set-SPManagedAccount
See Also Example
[image]

Published: May 12, 2010

Configures the managed account.

Set-SPManagedAccount [-Identity] <SPManagedAccountPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-EmailNotification <Int32>] [-PreExpireDays <Int32>] [-Schedule <String>] [-WhatIf [<SwitchParameter>]]
Set-SPManagedAccount [-Identity] <SPManagedAccountPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-AutoGeneratePassword <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-EmailNotification <Int32>] [-PreExpireDays <Int32>] [-Schedule <String>] [-WhatIf [<SwitchParameter>]]
Set-SPManagedAccount [-Identity] <SPManagedAccountPipeBind> -Password <SecureString> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-EmailNotification <Int32>] [-PreExpireDays <Int32>] [-Schedule <String>] [-WhatIf [<SwitchParameter>]]
Set-SPManagedAccount [-Identity] <SPManagedAccountPipeBind> -ConfirmPassword <SecureString> -NewPassword <SecureString> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-EmailNotification <Int32>] [-PreExpireDays <Int32>] [-Schedule <String>] [-SetNewPassword <SwitchParameter>] [-WhatIf [<SwitchParameter>]]
Set-SPManagedAccount [-Identity] <SPManagedAccountPipeBind> -ExistingPassword <SecureString> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-EmailNotification <Int32>] [-PreExpireDays <Int32>] [-Schedule <String>] [-UseExistingPassword <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPManagedAccountPipeBind

Specifies the full name or partial name of the managed accounts to retrieve.

The type must be a valid account name, in the form Domain\User, or a GUID, in the form 1234-3456-09876.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

EmailNotification

Optional

System.Int32

Specifies the number of days before password change to begin e-mail notifications.

The default value is 5.

PreExpireDays

Optional

System.Int32

Specifies the number of days before expiration to schedule password change.

The default value is 2.

Schedule

Optional

System.String

Specifies the new schedule on which the password change job is to run.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPManagedAccountPipeBind

Specifies the full name or partial name of the managed accounts to retrieve.

The type must be a valid account name, in the form Domain\User, or a GUID, in the form 1234-3456-09876.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

AutoGeneratePassword

Optional

System.Management.Automation.SwitchParameter

Automatically generates a new password.

The type must be either of the following values:

- True

- False

The default value is False.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

EmailNotification

Optional

System.Int32

Specifies the number of days before password change to begin e-mail notifications.

The default value is 5.

PreExpireDays

Optional

System.Int32

Specifies the number of days before expiration to schedule password change.

The default value is 2.

Schedule

Optional

System.String

Specifies the new schedule on which the password change job is to run.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

3

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPManagedAccountPipeBind

Specifies the full name or partial name of the managed accounts to retrieve.

The type must be a valid account name, in the form Domain\User, or a GUID, in the form 1234-3456-09876.

Password

Required

System.Security.SecureString

Sets a password for the managed account.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

EmailNotification

Optional

System.Int32

Specifies the number of days before password change to begin e-mail notifications.

The default value is 5.

PreExpireDays

Optional

System.Int32

Specifies the number of days before expiration to schedule password change.

The default value is 2.

Schedule

Optional

System.String

Specifies the new schedule on which the password change job is to run.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

4

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPManagedAccountPipeBind

Specifies the full name or partial name of the managed accounts to retrieve.

The type must be a valid account name, in the form Domain\User, or a GUID, in the form 1234-3456-09876.

ConfirmPassword

Required

System.Security.SecureString

Confirms the new password for this managed account.

NewPassword

Required

System.Security.SecureString

Sets a new password for the managed account

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

EmailNotification

Optional

System.Int32

Specifies the number of days before password change to begin e-mail notifications.

The default value is 5.

PreExpireDays

Optional

System.Int32

Specifies the number of days before expiration to schedule password change.

The default value is 2.

Schedule

Optional

System.String

Specifies the new schedule on which the password change job is to run.

SetNewPassword

Optional

System.Management.Automation.SwitchParameter

Sets the password to the new value that is passed in, and changes the value in AD DS.

The type must be either of the following values:

- True

- False

The default value is False.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

5

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPManagedAccountPipeBind

Specifies the full name or partial name of the managed accounts to retrieve.

The type must be a valid account name, in the form Domain\User, or a GUID, in the form 1234-3456-09876.

ExistingPassword

Required

System.Security.SecureString

Sets the password for this managed account to an existing value that has already been changed in Active Directory Domain Services (AD DS).

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

EmailNotification

Optional

System.Int32

Specifies the number of days before password change to begin e-mail notifications.

The default value is 5.

PreExpireDays

Optional

System.Int32

Specifies the number of days before expiration to schedule password change.

The default value is 2.

Schedule

Optional

System.String

Specifies the new schedule on which the password change job is to run.

UseExistingPassword

Optional

System.Management.Automation.SwitchParameter

Sets the password to a new value passed in where the value is already changed in AD DS.

The type must be either of the following values:

- True

- False

The default value is False.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Set-SPManagedAccount cmdlet sets the properties on the given managed account.

You can use this cmdlet to change the password expiration and notification settings for the managed account: Use the default parameter set. Additionally, you can use this cmdlet to change the password for the managed account to automatically generated passwords on a set schedule: Use the parameter set that includes the AutoGeneratePassword parameter. You can also use this cmdlet to change the password for the managed account to a new value, known to the administrator: Use the parameter set that includes the SetNewPassword parameter. Finally, you can use this cmdlet to change the password for the managed account to an existing value that has been already been changed in Active Directory Domain Services (AD DS): Use the parameter set that includes the UseExistingPassword parameter.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
$m = Get-SPManagedAccount -Identity "DOMAINx\UserY"
Copy Code
Set-SPManagedAccount -Identity $m -AutoGeneratePassword true

This example displays an explicit managed account if it exists, and then attempts to update it to use automatically generated passwords.

See Also

Reference

Get-SPManagedAccount
New-SPManagedAccount
Remove-SPManagedAccount


Set-SPSecurityTokenServiceConfig
See Also Example
[image]

Published: May 12, 2010

Updates the settings of the SharePoint security token service (STS) identity provider.

Set-SPSecurityTokenServiceConfig [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-FormsTokenLifetime <Int32>] [-ImportSigningCertificate <X509Certificate2>] [-MaxLogonTokenCacheItems <Int32>] [-MaxServiceTokenCacheItems <Int32>] [-ServiceTokenCacheExpirationWindow <Int32>] [-ServiceTokenLifetime <Int32>] [-WhatIf [<SwitchParameter>]] [-WindowsTokenLifetime <Int32>]
Set-SPSecurityTokenServiceConfig -SigningCertificateThumbprint <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-FormsTokenLifetime <Int32>] [-MaxLogonTokenCacheItems <Int32>] [-MaxServiceTokenCacheItems <Int32>] [-ServiceTokenCacheExpirationWindow <Int32>] [-ServiceTokenLifetime <Int32>] [-SigningCertificateStoreName <String>] [-WhatIf [<SwitchParameter>]] [-WindowsTokenLifetime <Int32>]

Parameters

1

Parameter

Required

Type

Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

FormsTokenLifetime

Optional

System.Int32

Specifies the expiration time, in minutes, for tokens issued to ASP.NET Membership Provider and Role providers. The default value is 1380.

The type must be a valid integer.

ImportSigningCertificate

Optional

System.Security.Cryptography.X509Certificates.X509Certificate2

Specifies the X.509 certificate object from trusted authentication provider farm.

The type must be a name of a valid X.509 certificate; for example, Certificate1.

MaxLogonTokenCacheItems

Optional

System.Int32

Specifies the maximum number of entries for the in-memory logon token cache. The default value is 10000 entries.

The type must be a valid integer.

MaxServiceTokenCacheItems

Optional

System.Int32

Specifies the maximum number of entries for the in-memory service token cache. The default value is 10000 entries.

The type must be a valid integer.

ServiceTokenCacheExpirationWindow

Optional

System.Int32

Specifies the interval, in minutes, for automatically renewing the token in the cache. The default value is 2 minutes.

The type must be a valid integer.

ServiceTokenLifetime

Optional

System.Int32

Specifies the expiration time, in minutes, for the security token service cache. The default value is 15 minutes.

The type must be a valid integer.

WindowsTokenLifetime

Optional

System.Int32

Specifies the expiration time, in minutes, for tokens issued to Windows users. The default value is 1380 minutes.

The type must be a valid integer.

2

Parameter

Required

Type

Description

SigningCertificateThumbprint

Required

System.String

Specifies the thumbrpint of the signing certificate.

The type must be a valid identity of a signing certificate; for example 2796BAE63F1801E277261BA0D77770028F20EEE4.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

FormsTokenLifetime

Optional

System.Int32

Specifies the expiration time, in minutes, for tokens issued to ASP.NET Membership Provider and Role providers. The default value is 1380.

The type must be a valid integer.

MaxLogonTokenCacheItems

Optional

System.Int32

Specifies the maximum number of entries for the in-memory logon token cache. The default value is 10000 entries.

The type must be a valid integer.

MaxServiceTokenCacheItems

Optional

System.Int32

Specifies the maximum number of entries for the in-memory service token cache. The default value is 10000 entries.

The type must be a valid integer.

ServiceTokenCacheExpirationWindow

Optional

System.Int32

Specifies the interval, in minutes, for automatically renewing the token in the cache. The default value is 2 minutes.

The type must be a valid integer.

ServiceTokenLifetime

Optional

System.Int32

Specifies the expiration time, in minutes, for the security token service cache. The default value is 15 minutes.

The type must be a valid integer.

SigningCertificateStoreName

Optional

System.String

Specifies the certificate store where the signing certificate resides. The identity store for an identity provider can be a SQL database table, an Active Directory Domain Services (AD DS), or Active Directory Lightweight Directory Service (AD LDS).

The type must be a valid identity of a signing certificate store; for example IdentityStore1.

WindowsTokenLifetime

Optional

System.Int32

Specifies the expiration time, in minutes, for tokens issued to Windows users. The default value is 1380 minutes.

The type must be a valid integer.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Set-SPSecurityTokenServiceConfig cmdlet updates the settings of the SharePoint security token service (STS) identity provider. If a certificate file is used, the certificate must be an X509 certificate with private keys, otherwise an exception is raised.

Note:

This cmdlet operates only with certificates that can be exported. To create a certificate which can be used in this cmdlet specify the X509KeyStorageFlags.Exportable bit in the keyStorageFlags parameter of the x509Certificate2 object constructor.

Input Types

Return Types

Example

------------------EXAMPLE 1------------------

Copy Code
Set-SPSecurityTokenServiceConfig -SigningCertificateThumbprint "2796BAE63F1801E277261BA0D77770028F20EEE4"

This example updates the signing certificate of the SharePoint security token service (STS) identity provider with a certificate that has been deployed in the certificate store.

------------------EXAMPLE 2------------------

Copy Code
$stsCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 "c:\sts.pfx","a",20
Copy Code
Set-SPSecurityTokenServiceConfig -ImportSigningCertificate $stsCert

This example imports the signing certificate for the SharePoint STS identity provider.

See Also

Reference

Get-SPSecurityTokenServiceConfig


Set-SPServiceApplicationSecurity
See Also Example
[image]

Published: May 12, 2010

Updates the SPObjectSecurity object for a service application.

Set-SPServiceApplicationSecurity [-Identity] <SPServiceApplicationPipeBind> [-ObjectSecurity] <SPObjectSecurity> [-Admin <SwitchParameter>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationPipeBind

Specifies the service application that contains the SPObjectSecurity object to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a service application (for example, ServiceApp1); or an instance of a valid SPServiceApplication object.

ObjectSecurity

Required

Microsoft.SharePoint.Administration.AccessControl.SPObjectSecurity

Specifies the SPObjectSecurity object to update.

Admin

Optional

System.Management.Automation.SwitchParameter

Updates the access control list (ACL) that contains the administrators list of the service application.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Set-SPServiceApplicationSecurity cmdlet updates a security object for the specified service application. Use this cmdlet with the Grant-SPObjectSecurity and Get-SPServiceApplicationSecurity cmdlets to manage security for a service application.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
$security = Get-SPServiceApplicationSecurity $serviceApp -Admin
Grant-SPObjectSecurity $security $principal "Full Control"
Set-SPServiceApplicationSecurity $serviceApp -Admin $security

This example retrieves the SPObjectSecurity object corresponding to the administrator ACL on a service application, and adds a new user principal to that ACL. The new user is an administrator for the service application $serviceApp.

See Also

Reference

Get-SPServiceApplicationSecurity
Grant-SPObjectSecurity
Revoke-SPObjectSecurity


Set-SPTrustedIdentityTokenIssuer
See Also Example
[image]

Published: May 12, 2010

Sets the identity providers of a Web application.

Set-SPTrustedIdentityTokenIssuer [-Identity] <SPTrustedIdentityTokenIssuerPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-ClaimProvider <SPClaimProviderPipeBind>] [-ClaimsMappings <SPClaimMappingPipeBind[]>] [-Description <String>] [-ImportTrustCertificate <X509Certificate2>] [-Realm <String>] [-SignInUrl <String>] [-UseWReply <SwitchParameter>]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPTrustedIdentityTokenIssuerPipeBind

Specifies the identity provider to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of identity provider (for example, LiveID STS); or an instance of a valid SPIdentityProvider object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

ClaimProvider

Optional

Microsoft.SharePoint.PowerShell.SPClaimProviderPipeBind

Specifies the IP STS that can resolve and search claims for claims people picker.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of a claim provider (for example, MyIDprovider1); or an instance of a valid SPClaimProvider object.

ClaimsMappings

Optional

Microsoft.SharePoint.PowerShell.SPClaimMappingPipeBind[]

Specifies the mapping of the claims from the original token to the SharePoint token.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or a valid name of a claim mapping rule (for example, Email); or an instance of a valid SPClaimMapping object.

Description

Optional

System.String

Specifies a description for the new identity provider.

The type must be a valid string; for example, LiveID STS.

ImportTrustCertificate

Optional

System.Security.Cryptography.X509Certificates.X509Certificate2

Specifies the X.509 certificate object from trusted authentication provider farm.

The type must be a name of a valid X.509 certificate; for example, Certificate1.

Realm

Optional

System.String

Specifies the realm, or resource partition, associated with this trust.

The type must be a name of a valid realm; for example, MD_REALM.

SignInUrl

Optional

System.String

Specifies the sign-in URLs for this trusted identity provider STS.

The type must be a valid URL, in the form http://int.live.com/.

UseWReply

Optional

System.Management.Automation.SwitchParameter

Includes a WReply with the token request. Wreply is a URL at the relying party to which the requestor is redirected once sign-out processing is complete.

Detailed Description

The Set-SPTrustedIdentityTokenIssuer cmdlet sets the identity providers of a Web application or extended Web application. For the ASP.NET Membership provider and Role provider, this cmdlet changes the identity provider only if the result is piped to a variable and passed to a Web application. For security token service (STS) identity providers, this cmdlet changes the persisted identity provider object in the SPFarm object.

Input Types

Return Types

Example

-------------------------EXAMPLE 1----------------------

Copy Code
Set-SPTrustedIdentityTokenIssuer "LiveIDSTS" -Certificate (Get-ChildItem"cert:Certificates (LocalComputer)\Personal\Certificates -Name "LiveID Cert")

This example sets the identity provider to LiveIDSTS.

-------------------------EXAMPLE 2----------------------

Copy Code
$ip = @( (Get-SPTrustedIdentityTokenIssuer "LiveID STS"), (New-SPTrustedIdentityTokenIssuer -ASPNetMembershipProvider "myMembershipProvider" -ASPNetRoleProvider "myRoleProvider"), (Get-SPTrustedIdentityTokenIssuer "NTLM")) )
New-SPWebApplication http://contoso.com -IdentityProvider $ip

This example sets the identity provider using the .ASPNetMembership and Role parameters. When these parameters are used, a variable must be set; otherwise, the values do not take effect.

See Also

Reference

Get-SPTrustedIdentityTokenIssuer
New-SPTrustedIdentityTokenIssuer
Remove-SPTrustedIdentityTokenIssuer


Set-SPTrustedRootAuthority
See Also Example
[image]

Published: May 12, 2010

Creates a new trusted root authority.

Set-SPTrustedRootAuthority [-Identity] <SPTrustedRootAuthorityPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Certificate <X509Certificate2>]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPTrustedRootAuthorityPipeBind

Specifies the trusted root authority to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a trusted root authority (for example, WFEFarm1); or an instance of a valid SPTrustedRootAuthority object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Certificate

Optional

System.Security.Cryptography.X509Certificates.X509Certificate2

Specifies the X.509 certificate of the trusted root authority.

The type must be a name of a valid X.509 certificate; for example, Certificate1.

Detailed Description

The Set-SPTrustedRootAuthority cmdlet creates a new trusted root authority. If a certificate file is used, the certificate must be an X509 certificate with private keys, otherwise an exception is raised.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
$cert = Get-PfxCertificate C:\LiveIDSigningCert.pfx
Get - SPTrustedRootAuthority -Name "WFEFarm1" | Set- SPTrustedRootAuthority -Certificate $cert

This example updates the certificate of the trusted root authority WFEFarm1.

See Also

Reference

Remove-SPTrustedRootAuthority
New-SPTrustedRootAuthority
Get-SPTrustedRootAuthority


Set-SPTrustedServiceTokenIssuer
See Also Example
[image]

Published: May 12, 2010

Updates a trust with the farm.

Set-SPTrustedServiceTokenIssuer [-Identity] <SPTrustedServiceTokenIssuerPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Certificate <X509Certificate2>] [-Description <String>]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPTrustedServiceTokenIssuerPipeBind

Specifies the trusted service token issuer to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a trusted service token issuer (for example, WFEFarm1); or an instance of a valid SPTrustedRootAuthority object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Certificate

Optional

System.Security.Cryptography.X509Certificates.X509Certificate2

Specifies the X.509 certificate object from trusted authentication provider farm.

The type must be a name of a valid X.509 certificate; for example, Certificate1.

Description

Optional

System.String

Specifies a description for the trust.

The type must be a valid string; for example, WFE Farm Trust1.

Detailed Description

The Set-SPTrustedServiceTokenIssuer cmdlet updates a trust with a SharePoint farm. If a certificate file is used, it must have only one X509 certificate without private keys, otherwise an exception is raised.

Input Types

Return Types

Example

------------------EXAMPLE 1------------------

Copy Code
$cert = Get-PfxCertificate C:\LiveIDSigningCert.pfx
Set - SPTrustedServiceTokenIssuer "WFEFarm1" - Description "WFE Farm 1" - ImportTrustCertificate $cert

This example updates a SharePoint Farm trust using the trust certificate from a file.

------------------EXAMPLE 2------------------

Copy Code
Set - SPTrustedServiceTokenIssuer "WFEFarm1" - Description "WFE Farm 1" -FederationMetadataUrl "https://liveid.com/STS/2007/03/fedmetadata.xml"

This example updates a SharePoint farm trust using the trust certificate from the federation metadata endpoint URL.

See Also

Reference

Get-SPTrustedServiceTokenIssuer
New-SPTrustedServiceTokenIssuer
Remove-SPTrustedServiceTokenIssuer


Update-SPFarmEncryptionKey
Example
[image]

Published: May 12, 2010

Changes the value of the farm encryption key and, using the new key, re-encrypts all the data.

Update-SPFarmEncryptionKey [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Resume <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Resume

Optional

System.Management.Automation.SwitchParameter

Resumes re-encryption of data with the new farm encryption key if a previous attempt failed.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Update-SPFarmEncryptionKey cmdlet changes the farm encryption key to a new randomly generated value. When the new key is used, all the data is re-encrypted.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE-----------------------

Copy Code
Update-SPFarmEncryptionKey -confirm

This example changes the farm encryption key to a new value and re-encrypts all the data.


Service application cmdlets (SharePoint Foundation 2010)
See Also

You can use Windows PowerShell cmdlets to administer service applications in a Microsoft SharePoint Foundation 2010 farm.

Cmdlet name | Description
Add-SPServiceApplicationProxyGroupMember | Adds a member to the service application proxy group.
Get-SPServiceApplication | Returns the specified service application.
Get-SPServiceApplicationEndpoint | Returns the endpoint of a service application.
Get-SPServiceApplicationPool | Returns the specified Internet Information Services (IIS) application pool.
Get-SPServiceApplicationProxy | Returns an instance of the specified service application proxy.
Get-SPServiceApplicationProxyGroup | Returns the proxy group for the specified service application.
Get-SPServiceContext | Returns a service context.
Get-SPServiceHostConfig | Returns the common Web service settings.
Get-SPServiceInstance | Returns the services instance for a specific server or the entire farm.
Get-SPTopologyServiceApplication | Displays properties of the topology service application for the current farm.
Get-SPTopologyServiceApplicationProxy | Retrieves the topology service application proxy.
Get-SPUsageApplication | Returns a specified usage application.
Get-SPUsageDefinition | Returns a usage definition object.
Get-SPUsageService | Returns a usage service.
Grant-SPServiceApplication | Grants a user account access to the service application.
Install-SPService | Installs and provisions services on a farm.
New-SPServiceApplicationPool | Creates a new Web service application pool.
New-SPServiceApplicationProxyGroup | Creates a new service application proxy group.
New-SPSubscriptionSettingsServiceApplication | Creates a new subscription settings service application.
New-SPSubscriptionSettingsServiceApplicationProxy | Creates an application proxy to a subscription settings service application.
New-SPUsageApplication | Creates a new usage application.
Publish-SPServiceApplication | Shares the specified local service application outside the farm.
Receive-SPSharedServiceApplicationInfo | Configures this farm to receive service information from another farm.
Remove-SPServiceApplication | Deletes the specified service application on the local server.
Remove-SPServiceApplicationPool | Completely deletes the specified Web service application pool.
Remove-SPServiceApplicationProxy | Deletes the specified service application proxy.
Remove-SPServiceApplicationProxyGroup | Completely deletes the specified service application proxy group.
Remove-SPServiceApplicationProxyGroupMember | Removes one or more proxies from the specified service application proxy group.
Remove-SPSiteSubscriptionBusinessDataCatalogConfig | Removes the Business Data Connectivity Metadata Store for a partition.
Remove-SPUsageApplication | Removes a usage application from the local farm.
Revoke-SPServiceApplication | Revokes a user's access to a service application.
Set-SPServiceApplication | Sets properties of a service application.
Set-SPServiceApplicationEndpoint | Sets the host of an endpoint for a service application.
Set-SPServiceApplicationPool | Changes the account used for the Identity of the specified application pool.
Set-SPServiceHostConfig | Configures one or more common settings for all Web services.
Set-SPTopologyServiceApplication | Sets the properties on the topology service application of the local farm.
Set-SPTopologyServiceApplicationProxy | Sets the proxy properties of the topology service application.
Set-SPUsageApplication | Sets properties of a usage application.
Set-SPUsageDefinition | Sets the retention period for a usage provider.
Set-SPUsageService | Sets the properties of a usage service.
Start-SPServiceInstance | Starts the service instance for a service on a specific server or the farm.
Stop-SPServiceInstance | Stops the service instance for a service.
Unpublish-SPServiceApplication | Stops sharing the specified service application outside the farm.

See Also

Other Resources

Resource Center: Windows PowerShell for SharePoint Foundation 2010


Add-SPServiceApplicationProxyGroupMember
See Also Example
[image]

Published: May 12, 2010

Adds a member to the service application proxy group.

Add-SPServiceApplicationProxyGroupMember [-Identity] <SPServiceApplicationProxyGroupPipeBind> [-Member] <SPServiceApplicationProxyPipeBind[]> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

SPServiceApplicationProxyGroupPipeBind.

Specifies the service application proxy group to which to add the member.

Member

Required

SPServiceApplicationProxyPipeBind[]

Specifies an array of members to add to the service application proxy group.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Add-SPServiceApplicationProxyGroupMember cmdlet adds a member to the service application proxy group.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Add-SPServiceApplicationProxyGroupMember RemoteProxyGroup -Member babab30e-8e3a-428b-8ff4-4d5c8f455e6d

This example adds a select service application proxy to the service application proxy group named RemoteProxyGroup.

The service application proxy group GUID is unique to every farm. You can run Get-SPServiceApplicationProxyGroup | Select Name,Id to see the GUID of the serviceapplication proxy groups. Use this result for any other SPServiceApplicationProxyGroup cmdlets.

See Also

Reference

Remove-SPServiceApplicationProxyGroupMember


Get-SPServiceApplication
See Also Example
[image]

Published: May 12, 2010

Returns the specified service application.

Get-SPServiceApplication [[-Identity] <SPServiceApplicationPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-Name <String>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPServiceApplicationPipeBind

Specifies the GUID of the service application to get.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPServiceApplication cmdlet returns the service application specified by the Identity parameter. If no parameter is specified, the cmdlet returns all service applications in the farm.

Input Types

Return Types

Example

------------------EXAMPLE----------------------

Copy Code
Get-SPServiceApplication

This example returns all service applications in the farm.

See Also

Reference

Set-SPServiceApplication
Grant-SPServiceApplication
Revoke-SPServiceApplication
Get-SPServiceApplicationProxy


Get-SPServiceApplicationEndpoint
See Also Example
[image]

Published: May 12, 2010

Returns the endpoint of a service application.

Get-SPServiceApplicationEndpoint [-Identity] <SPServiceEndpointPipeBind> [-AssignmentCollection <SPAssignmentCollection>]
Get-SPServiceApplicationEndpoint -ServiceApplication <SPServiceApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Name <String>]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceEndpointPipeBind

Specifies the service endpoint to get.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid URI of an endpoint address, in the form http://sitename:8003/servicemodelsamples/service; or an instance of a valid SPServiceEndpoint object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

2

Parameter

Required

Type

Description

ServiceApplication

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationPipeBind

Specifies the service application to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a subscription settings service application (for example, SubscriptionSettingsApp1); or an instance of a valid SPServiceApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Name

Optional

System.String

Specifies the name of the service application endpoint.

The type must be a valid name of an service application endpoint; for example, SvcAppEndpoint1.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Get-SPServiceApplicationEndpoint cmdlet sets the host of a service endpoint. Use the second parameter set and do not specify the Name parameter to return a collection of all endpoints for the specified service application.

Input Types

Return Types

Example

-------------------EXAMPLE--------------------

Copy Code
Get- SPServiceApplicationEndpoint -ServiceApplication "ServiceSubApp1"

This example returns the SPServiceEndpoint object based on the specified service application.

See Also

Reference

Set-SPServiceApplicationEndpoint


Get-SPServiceApplicationPool
See Also Example
[image]

Published: May 12, 2010

Returns the specified Internet Information Services (IIS) application pool.

Get-SPServiceApplicationPool [[-Identity] <SPIisWebServiceApplicationPoolPipeBind>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPIisWebServiceApplicationPoolPipeBind

Specifies the name or identifier (ID) of the application pool to get.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPServiceApplicationPool cmdlet returns the IIS application pool specified by the Identity parameter, or returns all application pools if the Identity parameter is not specified.

Input Types

Return Types

Example

--------------EXAMPLE-----------------

Copy Code
Get-SPServiceApplicationPool

This example returns all the service application pools in the farm.

See Also

Reference

New-SPServiceApplicationPool
Set-SPServiceApplicationPool
Remove-SPServiceApplicationPool


Get-SPServiceApplicationProxy
See Also Example
[image]

Published: May 12, 2010

Returns an instance of the specified service application proxy.

Get-SPServiceApplicationProxy [[-Identity] <SPServiceApplicationProxyPipeBind>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPServiceApplicationProxyPipeBind

Specifies the GUID of the service application proxy to return.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Get-SPServiceApplicationProxy cmdlet returns an instance of the service application proxy specified by the Identity parameter.

Input Types

Return Types

Example

--------------EXAMPLE-----------------

Copy Code
Get-SPServiceApplicationProxy

This example retrieves all the service application proxies in the farm.

See Also

Reference

Remove-SPServiceApplicationProxy
New-SPServiceApplicationProxyGroup
Remove-SPServiceApplicationProxyGroup
Get-SPServiceApplicationProxyGroup


Get-SPServiceApplicationProxyGroup
See Also Example
[image]

Published: May 12, 2010

Returns the proxy group for the specified service application.

Get-SPServiceApplicationProxyGroup [[-Identity] <SPServiceApplicationProxyGroupPipeBind>] [-AssignmentCollection <SPAssignmentCollection>]
Get-SPServiceApplicationProxyGroup -Default <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

1

Parameter

Required

Type

Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPServiceApplicationProxyGroupPipeBind

Specifies the name or the GUID of the proxy group.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

2

Parameter

Required

Type

Description

Default

Required

System.Management.Automation.SwitchParameter

Returns the default sevice proxy group for the farm.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPServiceApplicationProxyGroup cmdlet displays a list of the proxy groups in the farm. To display a specific proxy group, use the Identity parameter. If no parameter value is specified, a list of all proxy groups is displayed.

Input Types

Return Types

Example

--------------EXAMPLE-----------------

Copy Code
Get-SPServiceApplicationProxyGroup

This example retrieves all of the service application proxy groups in the farm.

See Also

Reference

New-SPServiceApplicationProxyGroup
Remove-SPServiceApplicationProxyGroup
Add-SPServiceApplicationProxyGroupMember


Get-SPServiceContext
Example
[image]

Published: May 12, 2010

Returns a service context.

Get-SPServiceContext [-Site] <SPSitePipeBind> [-AssignmentCollection <SPAssignmentCollection>]
Get-SPServiceContext -SiteSubscription <SPSiteSubscriptionPipeBind> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

1

Parameter

Required

Type

Description

Site

Required

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Returns the service context for only the Web application that contains the specified site collection.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid URL, in the form http://server_name; or an instance of a valid SPSite object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

2

Parameter

Required

Type

Description

Site

Required

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Returns the service context for only the Web application that contains the specified site collection.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid URL, in the form http://server_name; or an instance of a valid SPSite object.

SiteSubscription

Required

Microsoft.SharePoint.PowerShell.SPSiteSubscriptionPipeBind

Returns all of the service contexts for all Web applications in which the specified site subscription has site collections.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a site subscription (for example, SiteSubscriptionConfig1); or an instance of a valid SiteSubscription object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Get-SPServiceContext cmdlet returns a service context or a collection of service contexts. Specify the Site parameter to return an individual service context, or specify the SiteSubscription parameter to return a collection of service contexts.

Input Types

Return Types

Example

----------------EXAMPLE---------------

Copy Code
$sitesub = Get-SPSiteSubscription http://my.contoso.com/
Copy Code
Get-SPServiceContext $sitesub

This example returns the service context for a site in a hosted environment.


Get-SPServiceHostConfig
See Also Example
[image]

Published: May 12, 2010

Returns the common Web service settings.

Get-SPServiceHostConfig [-AssignmentCollection <SPAssignmentCollection>] [-Default <SwitchParameter>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Default

Optional

System.Management.Automation.SwitchParameter

This parameter has no effect.

Detailed Description

The Get-SPServiceHostConfig returns the common Web service settings.

Input Types

Return Types

Example

--------------EXAMPLE-------------------

Copy Code
Get- SPServiceHostConfig

This example displays the Web service settings.

See Also

Reference

Set-SPServiceHostConfig


Get-SPServiceInstance
See Also Example
[image]

Published: May 12, 2010

Returns the services instance for a specific server or the entire farm.

Get-SPServiceInstance [[-Identity] <SPServiceInstancePipeBind>] [-All <SwitchParameter>] [-AssignmentCollection <SPAssignmentCollection>]
Get-SPServiceInstance -Server <SPServerPipeBind> [-All <SwitchParameter>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

1

Parameter

Required

Type

Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPServiceInstancePipeBind

Specifies the GUID of the service instance.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

2

Parameter

Required

Type

Description

Server

Required

Microsoft.SharePoint.PowerShell.SPServerPipeBind

Specifies the server from which to return the service instance.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Get-SPServiceInstance cmdlet returns the services instance specified by the Identity parameter for a specific server. If the Server parameter is not specified, the Get-SPServiceInstance cmdlet returns results for the entire farm.

Input Types

Return Types

Example

--------------EXAMPLE-----------------

Copy Code
Get-SPServiceInstance -Server ServerA

This example displays the service instances from a given server.

See Also

Reference

Start-SPServiceInstance
Stop-SPServiceInstance


Get-SPTopologyServiceApplication
See Also Example
[image]

Published: May 12, 2010

Displays properties of the topology service application for the current farm.

Get-SPTopologyServiceApplication [[-Identity] <SPTopologyWebServiceApplicationPipeBind>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPTopologyWebServiceApplicationPipeBind

Specifies the GUID of the application.

The type must be a valid GUID, in the form 1234-4567-098jhj.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPTopologyServiceApplication cmdlet displays the advanced properties of an application when the Identity parameter is used.

Input Types

Return Types

Example

--------------EXAMPLE-----------------

Copy Code
Get-SPTopologyServiceApplication

This example displays properties of the topology service application for the current farm.

See Also

Reference

Set-SPTopologyServiceApplication
Get-SPTopologyServiceApplicationProxy


Get-SPTopologyServiceApplicationProxy
See Also Example
[image]

Published: May 12, 2010

Retrieves the topology service application proxy.

Get-SPTopologyServiceApplicationProxy [[-Identity] <SPTopologyWebServiceProxyPipeBind>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPTopologyWebServiceProxyPipeBind

Specifies the GUID of the application proxy.

The type must be a valid GUID, in the form 1234-4567-098jhj.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPTopologyServiceApplicationProxy cmdlet retrieves the local topology service application proxy.

Input Types

Return Types

Example

--------------EXAMPLE-----------------

Copy Code
Get-SPTopologyServiceApplicationProxy

This example displays the topology service application proxy in the farm.

See Also

Reference

Set-SPTopologyServiceApplicationProxy
Set-SPTopologyServiceApplication


Get-SPUsageApplication
See Also Example
[image]

Published: May 12, 2010

Returns a specified usage application.

Get-SPUsageApplication [[-Identity] <SPUsageApplicationPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-UsageService <SPUsageServicePipeBind>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPUsageApplicationPipeBind

Specifies the usage application to get. If the Identity parameter is not specified, the cmdlet returns the local usage application.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a usage application (for example, UsageApplication1); or an instance of a valid SPUsageApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

UsageService

Optional

Microsoft.SharePoint.PowerShell.SPUsageServicePipeBind

Filters to return the usage application with the specified parent SPUsageService object.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a usage service (for example, UsageService1); or an instance of a valid SPUsageService object.

Detailed Description

The Get-SPUsageApplication cmdlet return a specified usage application. If the Identity parameter is not specified, the cmdlet returns the local usage application.

Input Types

Return Types

Example

---------------EXAMPLE------------------

Copy Code
Get-SPUsageApplication -Identity "Usage and Health data collection"

This example returns the usage application named, Usage and Health data collection

See Also

Reference

New-SPUsageApplication
Set-SPUsageApplication
Remove-SPUsageApplication


Get-SPUsageDefinition
See Also Example
[image]

Published: May 12, 2010

Returns a usage definition object.

Get-SPUsageDefinition [[-Identity] <SPUsageDefinitionPipeBind>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPUsageDefinitionPipeBind

Specifies the usage definition object to get.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a usage definition (for example, SiteSubscriptionConfig1); or an instance of a valid SPUsageDefinition object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPUsageDefinition cmdlet reads a usage definition object. If the Identity parameter is not specified, this cmdlet returns the collection of usage definitions in the farm. A usage definition object defines a specific type of usage.

Input Types

Return Types

Example

-----------------EXAMPLE-----------------

Copy Code
Get-SPUsageDefinition -Identity "Page Requests"

This example returns the SPRequestUsage provider on the local farm.

See Also

Reference

Set-SPUsageDefinition


Get-SPUsageService
See Also Example
[image]

Published: May 12, 2010

Returns a usage service.

Get-SPUsageService [[-Identity] <SPUsageServicePipeBind>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPUsageServicePipeBind

Specifies the usage service to get. If the Identity parameter is not specified, the cmdlet returns the local usage service.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a usage service (for example, UsageService1); or an instance of a valid SPUsageService object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPUsageService cmdlet returns the specified usage service. If the Identity parameter is not specified, the cmdlet returns the local usage service.

Input Types

Return Types

Example

-------------------EXAMPLE-------------------------

Copy Code
Get-SPUsageService -Identity 57055d99-9914-4af6-a3bf-7b76e3f231c2

This example returns a SPUsageService object of the specified ID.

See Also

Reference

Set-SPUsageService


Grant-SPServiceApplication
See Also Example
[image]

Published: May 12, 2010

Grants a user account access to the service application.

Grant-SPServiceApplication -Identity <SPServiceApplicationPipeBind> -UserPrincipal <String> -Rights <String[]> -Type <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationPipeBind

Specifies the GUID of the service application to which to grant access.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh.

UserPrincipal

Required

System.String

Specifies the identity to grant access to the service application.

The type must be a valid user principal name, in the form DOMAIN\user, or a claim, in the form CA:NTLM:Identity-username:domain\user.

Rights

Required

System.String[]

Specifies the rights to grant the user. By default, the following right exists - 'full' for both the admin and access types. Service applications can define their own rights.

The type must be a string array with valid user rights entries.

Type

Required

System.String

Specifies whether to grant the principal administrator rights or access rights.

Either Admin or Access.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Grant-SPServiceApplication cmdlet grants the specified level of access to the specified user accounts to the specified service application with the specified permissions.

Input Types

Return Types

Example

------------------EXAMPLE---------------------

Copy Code
Grant-SPServiceApplication 053c34be-d251-488c-8e94-644eae94da26 -UserPrincipal testdomin\tester1 -Rights Full Control -Type Admin

This example grants Full Control administrative access to the given user principal for the selected service application.

The service application GUID is unique to every farm. You can run the Get-SPServiceApplication cmdlet to see the GUID of the service applications, and then use the result from the Get-SPServiceApplication cmdlet for other SPServiceApplication cmdlets; for example, Grant-SPServiceApplication or Publish-SPServiceApplication.

See Also

Reference

Set-SPServiceApplication
Get-SPServiceApplication
Publish-SPServiceApplication
Revoke-SPServiceApplication
Remove-SPServiceApplication


Install-SPService
Example
[image]

Published: May 12, 2010

Installs and provisions services on a farm.

Install-SPService [-AssignmentCollection <SPAssignmentCollection>] [-Provision <SwitchParameter>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Provision

Optional

System.Management.Automation.SwitchParameter

Specifies default settings when installing a standalone service application.

Detailed Description

The Install-SPService cmdlet installs and optionally provisions services on a farm. This cmdlet installs all services, service instances, and service proxies specified in the registry on the local server computer. Use this cmdlet in a script that you build to install and deploy a SharePoint farm or to install a custom developed service.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Install-SPService

This example installs all services, service instances and service proxies specified in the registry on the local server computer.


New-SPServiceApplicationPool
See Also Example
[image]

Published: May 12, 2010

Creates a new Web service application pool.

New-SPServiceApplicationPool [-Name] <String> [-Account] <SPProcessAccountPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Name

Required

System.String

Specifies the name of the new Web service application pool.

Account

Required

Microsoft.SharePoint.PowerShell.SPProcessAccountPipeBind

Specifies the credentials that will be the identity of the new application pool.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The New-SPServiceApplicationPool cmdlet creates a new Web service application pool in Internet Information Services (IIS).

Input Types

Return Types

Example

--------------------EXAMPLE-----------------------

Copy Code
New-SPServiceApplicationPool -Name TestServiceWebApplicationPool -Account testdomain\testuser1

This example creates a new Web service application pool.

For the Account parameter, the name of a managed account in the farm can be given. Use the Get-SPManagedAccount cmdlet to view the existing managed account in the farm. Also, a process account from the output of the Get-SPProcessAccount cmdlet can be used.

See Also

Reference

Get-SPServiceApplicationPool
Set-SPServiceApplicationPool
Remove-SPServiceApplicationPool


New-SPServiceApplicationProxyGroup
See Also Example
[image]

Published: May 12, 2010

Creates a new service application proxy group.

New-SPServiceApplicationProxyGroup [-Name] <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Name

Required

System.String

Specifies the name of the new service application proxy group.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The New-SPServiceApplicationProxyGroup cmdlet creates a new service application proxy group specified by the Name parameter.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
New-SPServiceApplicationProxyGroup -Name RemoteProxyGroup

This example creates a new service application proxy with the name RemoteProxyGroup.

See Also

Reference

Get-SPServiceApplicationProxyGroup
Add-SPServiceApplicationProxyGroupMember
Remove-SPServiceApplicationProxyGroup


New-SPSubscriptionSettingsServiceApplication
See Also Example
[image]

Published: May 12, 2010

Creates a new subscription settings service application.

New-SPSubscriptionSettingsServiceApplication -ApplicationPool <SPIisWebServiceApplicationPoolPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DatabaseCredentials <PSCredential>] [-DatabaseName <String>] [-DatabaseServer <String>] [-FailoverDatabaseServer <String>] [-Name <String>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

ApplicationPool

Required

Microsoft.SharePoint.PowerShell.SPIisWebServiceApplicationPoolPipeBind

Specifies the IIS application pool to use for the new subscription settings application.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of an application pool (for example, AppPoolName1); or an instance of a valid IISWebServiceApplicationPool object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DatabaseCredentials

Optional

System.Management.Automation.PSCredential

Specifies the PSCredential object that contains the user name and password to be used for database SQL Server Authentication.

The type must be a valid PSCredential object.

DatabaseName

Optional

System.String

Specifies the name of the subscription settings database.

If not provided, one will be generated.

The type must be a valid name of a SQL Server database; for example, SubscriptionSettingsApp1.

DatabaseServer

Optional

Microsoft.SharePoint.PowerShell.SPServerPipeBind

Specifies the name of the host SQL Server instance for the database specified in the DatabaseName parameter. If not provided, the default database server will be used

The type must be a valid SQL Server instance name; for example, SQLServerHost1.

The type must be a valid name of a SQL Server database; for example, SubscriptionSettingsApp1.

FailoverDatabaseServer

Optional

Microsoft.SharePoint.PowerShell.SPServerPipeBind

Specifies the name of the host SQL Server instance for the failover database server.

The type must be a valid SQL Server instance name; for example, SQLServerHost1.

Name

Optional

System.String

Specifies the friendly name of the new subscription settings service.

The type must be a valid name of a subscription settings service application; for example, SubscriptionSettingsApp1.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

Use the New-SPSubscriptionSettingsServiceApplication cmdlet to create a subscription settings service application that can be used to store settings that are shared across all site collections in a single site subscription. This cmdlet is used only in an environment where site subscriptions are used to delegate administration or partition services that are used for storing settings that are shared across all site collections in a single site subscription. This cmdlet is used only in an environment where site subscriptions are used to delegate administration or partition services.

Input Types

Return Types

Example

-------------EXAMPLE---------------

Copy Code
$AppPool = New-SPServiceApplicationPool -Name SettingsServiceAppPool -Account (Get-SPManagedAccount DOMAIN\jdoe)
Copy Code
$App = New-SPSubscriptionSettingsServiceApplication -ApplicationPool $appPool -Name SettingsServiceApp -DatabaseName SettingsServiceDB
Copy Code
$proxy = New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $App
Copy Code
Get-SPServiceInstance | where{$_.TypeName -eq "Microsoft SharePoint Foundation Subscription Settings Service"} | Start-SPServiceInstance

This example creates an application pool, a new subscription settings service application, a subscription settings service application proxy, and starts the service instance on the local machine. This example assumes that a managed account for DOMAIN\jdoe already exists.

See Also

Reference

Set-SPSubscriptionSettingsServiceApplication
New-SPSubscriptionSettingsServiceApplicationProxy


New-SPSubscriptionSettingsServiceApplicationProxy
See Also Example
[image]

Published: May 12, 2010

Creates an application proxy to a subscription settings service application.

New-SPSubscriptionSettingsServiceApplicationProxy -Uri <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]
New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication <SPServiceApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Uri

Required

System.String

Specifies the address of the subscription settings service application to associate the new application proxy with.

The type must be a valid URI, in the form file:\\server_name\sitedocs.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

ServiceApplication

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationPipeBind

Specifies the subscription settings service application associated with the new proxy.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a subscription settings service application (for example, SubscriptionSettingsApp1); or an instance of a valid SPServiceApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

Use the New-SPSubscriptionSettingsServiceApplicationProxy cmdlet to create an application proxy to a subscription settings service application. This is required for the local farm to consume a subscription settings service application.

Input Types

Return Types

Example

--------------------EXAMPLE---------------------------

Copy Code
$AppPool = New-SPIisWebServiceApplicationPool -Name SettingsServiceAppPool -Account (Get-SPManagedAccount DOMAIN\jdoe)
Copy Code
$App = New-SPSubscriptionSettingsServiceApplication -ApplicationPool $appPool -Name SettingsServiceApp -DatabaseName SettingsServiceDB
Copy Code
$proxy = New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $App
Copy Code
Get-SPServiceInstance | where{$_.TypeName -eq "Microsoft SharePoint Foundation Subscription Settings Service"} | Start-SPServiceInstance

This example creates an application pool, a new settings service application, a settings service application proxy, and then starts the service instance on the local machine. This example assumes that a managed account for DOMAIN\jdoe already exists.

See Also

Reference

New-SPSubscriptionSettingsServiceApplication
Set-SPSubscriptionSettingsServiceApplication


New-SPUsageApplication
Example
[image]

Published: May 12, 2010

Creates a new usage application.

New-SPUsageApplication [[-Name] <String>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DatabaseName <String>] [-DatabasePassword <SecureString>] [-DatabaseServer <String>] [-DatabaseUsername <String>] [-FailoverDatabaseServer <String>] [-UsageService <SPUsageServicePipeBind>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Name

Optional

System.String

Specifies the friendly name of the new usage application.

The type must be a valid name of a usage application; for example, UsageApplication1.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DatabaseName

Optional

System.String

Specifies the name of the logging database. If the logging database does not exist, a logging database is automatically created.

The type must be a valid name of a SQL Server database; for example, UsageLogDB1.

DatabasePassword

Optional

System.Security.SecureString

Specifies the password for the user specified in DatabaseUserName. Use this parameter only if SQL Server Authentication is used to access the logging database.

The type must be a valid password.

DatabaseServer

Optional

Microsoft.SharePoint.PowerShell.SPServerPipeBind

Specifies the SPServer object where the logging database is created.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; the IP address of a server computer, in the form 208.77.188.166; a valid name of a SQL Server host service (for example, SQLServerHost1); or an instance of a valid SPServer object.

DatabaseUsername

Optional

System.String

Specifies the user name to use for connecting to the logging database. Use this parameter only if SQL Server Authentication is used to access the logging database.

The type must be a valid user name; for example, UserName1.

FailoverDatabaseServer

Optional

System.String

Specifies the name of the host SQL Server instance for the failover database server.

The type must be a valid SQL Server instance name; for example, SQLServerHost1.

UsageService

Optional

Microsoft.SharePoint.PowerShell.SPUsageServicePipeBind

Filters to return the usage application with the specified parent SPUsageService object.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a usage service (for example, UsageService1); or an instance of a valid SPUsageService object.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The New-SPUsageApplication cmdlet creates a new usage application in the local farm.

Input Types

Return Types

Example

-------------------EXAMPLE-------------------------

Copy Code
New-SPUsageApplication -Name "Usage Application For Farm ABC"

This example creates a new usage application for the specified name.


Publish-SPServiceApplication
See Also Example
[image]

Published: May 12, 2010

Shares the specified local service application outside the farm.

Publish-SPServiceApplication [-Identity] <SPServiceApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Description <String>] [-InfoLink <Uri>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationPipeBind

Specifies the GUID of the service application to share outside the farm.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Description

Optional

System.String

Describes the service application to share outside the farm. If no value is specified, the value is left blank.

InfoLink

Optional

System.Uri

Specifies the link to more information about the service application to share outside the farm. If no link is specified, no link is made available.

The type must be a valid URL, in the form http://server_name/Site_Name/page_name.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Publish-SPServiceApplication cmdlet publishes the local service application, specified by the Identity parameter, outside the farm.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Publish-SPServiceApplication 053c34be-d251-488c-8e94-644eae94da26 -Description "Connect to this TestServiceApplcation of you want to use FeatureA in your farm" -InfoLink http://testurl

This example publishes a service application to another farm.

The service application GUID is unique to every farm. You can run the Get-SPServiceApplication cmdlet to see the GUID of the service applications, and then use the result from the Get-SPServiceApplication cmdlet for other SPServiceApplication cmdlets; for example, Grant-SPServiceApplication.

See Also

Reference

Get-SPServiceApplication
Set-SPServiceApplication
Remove-SPServiceApplication
Grant-SPServiceApplication


Receive-SPSharedServiceApplicationInfo
Example
[image]

Published: May 12, 2010

Configures this farm to receive service information from another farm.

Receive-SPSharedServiceApplicationInfo [-FarmUrl] <Uri> [-AssignmentCollection <SPAssignmentCollection>] [-Filter <String>]

Parameters

Parameter Required Type Description

FarmUrl

Required

System.Uri

Specifies the URL of the farm from which to receive service application information.

The type must be a valid URL, in the form http://server_name.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Filter

Optional

System.String

Detailed Description

The Receive-SPSharedServiceApplicationInfo cmdlet retrieves the list of service applications published by another farm.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Receive-SPSharedServiceApplicationInfo -FarmUrl http://FarmB/topology/topology.svc

This example retreives a list of service applications published by a given farm.

The FarmURL parameter can be obtained by the Get-SPTopologyWebServiceApplication cmdlet.


Remove-SPServiceApplication
See Also Example
[image]

Published: May 12, 2010

Deletes the specified service application on the local server.

Remove-SPServiceApplication [-Identity] <SPServiceApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-RemoveData <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationPipeBind

Specifies the GUID of the service application to remove.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

RemoveData

Optional

SwitchParameter

Deletes all databases and other data associated with the service application.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPServiceApplication cmdlet deletes the specified service application from the farm.

Input Types

Return Types

Example

--------------------EXAMPLE---------------------------

Copy Code
Remove-SPServiceApplication 053c34be-d251-488c-8e94-644eae94da26
-removedata

This example deletes the service application and its database.

The service application GUID is unique to every farm. You can run the Get-SPServiceApplication cmdlet to see the GUID of the service applications, and then use the result from the Get-SPServiceApplication cmdlet for other SPServiceApplication cmdlets; for example, Grant-SPServiceApplication or Publish-SPServiceApplication.

See Also

Reference

Get-SPServiceApplication
Set-SPServiceApplication
Publish-SPServiceApplication
Grant-SPServiceApplication


Remove-SPServiceApplicationPool
See Also Example
[image]

Published: May 12, 2010

Completely deletes the specified Web service application pool.

Remove-SPServiceApplicationPool [-Identity] <SPIisWebServiceApplicationPoolPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPIisWebServiceApplicationPoolPipeBind

Specifies the identity of the Web service application pool to delete.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPServiceApplicationPool cmdlet completely deletes the specified Web service application pool.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Remove-SPServiceApplicationPool TestServiceWebApplicationPool

This example deletes the selected service application pool.

See Also

Reference

Get-SPServiceApplicationPool
Set-SPServiceApplicationPool
Remove-SPServiceApplicationPool


Remove-SPServiceApplicationProxy
See Also Example
[image]

Published: May 12, 2010

Deletes the specified service application proxy.

Remove-SPServiceApplicationProxy [-Identity] <SPServiceApplicationProxyPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-RemoveData <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationProxyPipeBind

Specifies the GUID of the service application proxy to remove.

The type must be a GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh.

RemoveData

Optional

System.Management.Automation.SwitchParameter

Deletes all databases and other data associated with the service application proxy.

AssignmentColletion

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentColletion

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPServiceApplicationProxy cmdlet deletes the service application proxy specified by the Identity parameter.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Remove-SPServiceApplicationProxy babab30e-8e3a-428b-8ff4-4d5c8f455e6d

This example deletes the given service application proxy.

The service application GUID is unique to every farm. You can run the Get-SPServiceApplication cmdlet to see the GUID of the service applications, and then use the result from the Get-SPServiceApplication cmdlet for other SPServiceApplication cmdlets; for example, Grant-SPServiceApplication or Publish-SPServiceApplication.

See Also

Reference

Get-SPServiceApplicationProxy
New-SPServiceApplicationProxyGroup
Remove-SPServiceApplicationProxy


Remove-SPServiceApplicationProxyGroup
See Also Example
[image]

Published: May 12, 2010

Completely deletes the specified service application proxy group.

Remove-SPServiceApplicationProxyGroup [-Identity] <SPServiceApplicationProxyGroupPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationProxyGroupPipeBind

The identity of the service application proxy group to delete.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

Completely deletes the specified service application proxy group.

Input Types

Return Types

Example

--------------------EXAMPLE-------------------------

Copy Code
Remove-SPServiceApplicationProxyGroup RemoteProxyGroup

This example deletes the service application proxy group named RemoteProxyGroup.

The service application proxy group GUID is unique to every farm. You can run Get-SPServiceApplicationProxyGroup | Select Name,Id to see the GUID of the service application proxy groups. Use this result for any other SPServiceApplicationProxyGroup cmdlets.

See Also

Reference

Get-SPServiceApplicationProxyGroup
New-SPServiceApplicationProxyGroup


Remove-SPServiceApplicationProxyGroupMember
See Also Example
[image]

Published: May 12, 2010

Removes one or more proxies from the specified service application proxy group.

Remove-SPServiceApplicationProxyGroupMember [-Identity] <SPServiceApplicationProxyGroupPipeBind> [-Member] <SPServiceApplicationProxyPipeBind[]> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationProxyGroupPipeBind

Specifies the identity of the service application proxy group from which to remove the member or members.

Member

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationProxyPipeBind[]

Specifies the member or members to remove from the service application proxy group.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPServiceApplicationProxyGroupMember cmdlet removes one or more proxies from the specified service application proxy group.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Remove-SPServiceApplicationProxyGroupMember RemoteProxyGroup -Member babab30e-8e3a-428b-8ff4-4d5c8f455e6d

This example removes a service application proxy from the selected service application proxy group named RemoteProxyGroup.

The service application proxy group GUID is unique to every farm. You can run Get-SPServiceApplicationProxyGroup | Select Name,Id to see the GUID of the service application proxy groups. Use this result for any other SPServiceApplicationProxyGroup cmdlets.

See Also

Reference

Add-SPServiceApplicationProxyGroupMember


Remove-SPUsageApplication
See Also Example
[image]

Published: May 12, 2010

Removes a usage application from the local farm.

Remove-SPUsageApplication [-Identity] <SPUsageApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-RemoveData <SwitchParameter>] [-UsageService <SPUsageServicePipeBind>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPUsageApplicationPipeBind

Specifies the usage application to delete.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a usage application (for example, UsageApplication1); or an instance of a valid SPUsageApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

RemoveData

Optional

System.Management.Automation.SwitchParameter

Specifies that the logging database is also removed.

UsageService

Optional

Microsoft.SharePoint.PowerShell.SPUsageServicePipeBind

Reserved for future use.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPUsageApplication cmdlet deletes a usage application from the local farm.

Input Types

Return Types

Example

-------------------EXAMPLE--------------------

Copy Code
Remove-SPUsageApplication -Identity "Usage and Health data collection" -RemoveData

This example removes the existing usage application and the associated logging DB.

See Also

Reference

Get-SPUsageApplication
Set-SPUsageApplication
New-SPUsageApplication


Revoke-SPServiceApplication
See Also Example
[image]

Published: May 12, 2010

Revokes a user's access to a service application.

Revoke-SPServiceApplication -Identity <SPServiceApplicationPipeBind> -UserPrincipal <String> -Type <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationPipeBind

Specifies the GUID of the service application to which to revoke access.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh.

UserPrincipal

Required

System.String

Specifies the identity to revoke access to the service application.

The type must be a valid user principal name, in the form DOMAIN\user, or a claim, in the form CA:NTLM:Identity-username:domain\user.

Type

Required

System.String

Specifies the type of rights to revoke.

The type must be either Admin or Access.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Revoke-SPServiceApplication cmdlet revokes the specified user's access to the specified service application.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Revoke-SPServiceAppliaion 053c34be-d251-488c-8e94-644eae94da26 -UserPrincipal testdomin\tester1 -Type Admin

This example revokes the administrative access given to the specified user for the selected service application.

The service application GUID is unique to every farm. You can run the Get-SPServiceApplication cmdlet to see the GUID of the service applications, and then use the result from the Get-SPServiceApplication cmdlet for other SPServiceApplication cmdlets; for example, Grant-SPServiceApplication or Publish-SPServiceApplication.

See Also

Reference

Get-SPServiceApplication
Set-SPServiceApplication
Publish-SPServiceApplication
Grant-SPServiceApplication


Set-SPServiceApplication
See Also Example
[image]

Published: May 12, 2010

Sets properties of a service application.

Set-SPServiceApplication [-Identity] <SPServiceApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DefaultEndpoint <SPServiceEndpointPipeBind>] [-IisWebServiceApplicationPool <SPIisWebServiceApplicationPoolPipeBind>] [-ServiceApplicationProxyGroup <SPServiceApplicationProxyGroupPipeBind>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationPipeBind

Specifies the service application to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a subscription settings service application (for example, SubSettingsApp1); or an instance of a valid SPServiceApplication object.

DefaultEndpoint

Optional

Microsoft.SharePoint.PowerShell.SPServiceEndpointPipeBind

Specifies the address of the default endpoint of the service application.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

IisWebServiceApplicationPool

Optional

Microsoft.SharePoint.PowerShell.SPIisWebServiceApplicationPoolPipeBind

Specifies the name or identity of the application pool used by the service application.

The IisWebServiceApplicationPool parameter only applies to Web Service applications.

ServiceApplicationProxyGroup

Optional

Microsoft.SharePoint.PowerShell.SPServiceApplicationProxyGroupPipeBind

Specifies a custom service application proxy group for the Web application to use. The Web application will use the proxies in this proxy group to connect to service applications. If the ServiceApplicationProxyGroup parameter is not specified, the farm's default proxy group is used.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

Use the Set-SPServiceApplication cmdlet to set various properties of a service application such as the default endpoint, and the application pool used by the service application.

Input Types

Return Types

Example

---------------------EXAMPLE----------------

Copy Code
$serviceapp = Get-SPServiceApplication "My Service App"
Copy Code
Set-SPServiceApplication $serviceapp -DefaultEndpoint https

This example sets the default endpoint of the service application to be https.

See Also

Reference

Get-SPServiceApplication
Revoke-SPServiceApplication
Publish-SPServiceApplication
Remove-SPServiceApplication


Set-SPServiceApplicationEndpoint
See Also Example
[image]

Published: May 12, 2010

Sets the host of an endpoint for a service application.

Set-SPServiceApplicationEndpoint [-Identity] <SPServiceEndpointPipeBind> -HostName <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]
Set-SPServiceApplicationEndpoint [-Identity] <SPServiceEndpointPipeBind> -ResetHostName <SwitchParameter> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceEndpointPipeBind

Specifies the service endpoint to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid URI of an endpoint address, in the form http://sitename:8003/servicemodelsamples/service; or an instance of a valid SPServiceEndpoint object.

HostName

Required

System.String

Specifies the default host of the service endpoint.

The type must be a valid full load balanced URL, in the form http://server_name.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceEndpointPipeBind

Specifies the service endpoint to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid URI of an endpoint address, in the form http://sitename:8003/servicemodelsamples/service; or an instance of a valid SPServiceEndpoint object.

ResetHostName

Required

System.Management.Automation.SwitchParameter

Removes the current host of the service endpoint and uses the default host.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Set- SPServiceApplicationEndpoint cmdlet sets the host of a service endpoint. Use the second parameter set to reset the host of the service endpoint to use the default endpoint.

Input Types

Return Types

Example

--------------------EXAMPLE-------------------

Copy Code
Set-SPServiceApplicationEndpoint -Identity "ServiceApp1" -HostName http://sitename -ResetHostName $true

This example associates the SPServiceEndpoint object with the specified identity and resets the hostname.

See Also

Reference

Get-SPServiceApplicationEndpoint


Set-SPServiceApplicationPool
See Also Example
[image]

Published: May 12, 2010

Changes the account used for the Identity of the specified application pool.

Set-SPServiceApplicationPool [-Identity] <SPIisWebServiceApplicationPoolPipeBind> [[-Account] <SPProcessAccountPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPIisWebServiceApplicationPoolPipeBind

Specifies the identity of the Web service application pool to configure.

Account

Optional

Microsoft.SharePoint.PowerShell.SPProcessAccountPipeBind

Specifies the credentials that will be the new Identity of the application pool.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Set-SPServiceApplicationPool cmdlet changes the account used for the Identity of the specified application pool.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Set-SPServiceApplicationPool  TestServiceWebApplicationPool -Account testdomain\testuser1

This example changes the identity of the selected service application pool.

For the Account parameter, the name of a managed account in the farm can be given. Use the Get-SPManagedAccount cmdlet to view the existing managed account in the farm. Also, a process account from the output of the Get-SPProcessAccount cmdlet can be used.

See Also

Reference

Get-SPServiceApplicationPool
New-SPServiceApplicationPool
Remove-SPServiceApplicationPool


Set-SPServiceHostConfig
See Also Example
[image]

Published: May 12, 2010

Configures one or more common settings for all Web services.

Set-SPServiceHostConfig [-Identity] <SPIisWebServiceSettings> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-HttpPort <Int32>] [-HttpsPort <Int32>] [-ImportSslCertificate <X509Certificate2>] [-NetTcpPort <Int32>] [-NoWait <SwitchParameter>] [-WhatIf [<SwitchParameter>]]
Set-SPServiceHostConfig [-Identity] <SPIisWebServiceSettings> -SslCertificateThumbprint <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-HttpPort <Int32>] [-HttpsPort <Int32>] [-NetTcpPort <Int32>] [-NoWait <SwitchParameter>] [-SslCertificateStoreName <String>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.Administration.SPIisWebServiceSettings

Specifies the identity of the Web service application to configure.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

HttpPort

Optional

System.Int32

Specifies the new port for the Web service.

HttpsPort

Optional

System.Int32

Specifies the new secure port for the Web service.

ImportSslCertificate

Optional

System.Security.Cryptography.X509Certificates.X509Certificate2

Specifies the SSL Certificate to use for secure protocols.

NetTcpPort

Optional

System.Int32

Sets the TCP port for the Web service.

NoWait

Optional

System.Management.Automation.SwitchParameter

For more information, see TechNet.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.Administration.SPIisWebServiceSettings

Specifies the identity of the Web service application to configure.

SslCertificateThumbprint

Required

System.String

Specifies the thumbprint of the SSL certificate to retrieve for secure protocols.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

HttpPort

Optional

System.Int32

Specifies the new port for the Web service.

HttpsPort

Optional

System.Int32

Specifies the new secure port for the Web service.

NetTcpPort

Optional

System.Int32

Sets the TCP port for the Web service.

NoWait

Optional

System.Management.Automation.SwitchParameter

For more information, see TechNet.

SslCertificateStoreName

Optional

System.String

Specifies the thumbprint of the SSL certificate to retrieve for secure protocols.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Set- SPServiceHostConfig cmdlet configures one or more common settings for all Web services.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Set-SPServiceHostConfig -Port 12345

This example sets the HTTP port for the Web services.

See Also

Reference

Get-SPServiceHostConfig


Set-SPTopologyServiceApplication
See Also Example
[image]

Published: May 12, 2010

Sets the properties on the topology service application of the local farm.

Set-SPTopologyServiceApplication [-Identity] <SPTopologyWebServiceApplicationPipeBind> -LoadBalancerUrl <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPTopologyWebServiceApplicationPipeBind

Specifies the GUID of the application to be set.

The type must be a valid GUID, in the form 1234-456-854gh.

LoadBalancerUrl

Required

System.String

Specifies an external physical load balancer.

The type must be a valid URL, in the form http://search.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Set-SPTopologyServiceApplication cmdlet sets the advanced properties of an application when the Identity parameter is used.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Set-SPTopologyServiceApplication 67877d63-bff4-4521-867a-ef4979ba07ce -LoadBalancedURL "https://testurl"

This example sets the load-balanced URL for the topology service application.

The topology service application GUID is unique to every farm. You can run the Get-SPTopologyServiceApplication cmdlet to retrieve the GUID.

See Also

Reference

Get-SPTopologyServiceApplication
Set-SPTopologyServiceApplicationProxy


Set-SPTopologyServiceApplicationProxy
See Also Example
[image]

Published: May 12, 2010

Sets the proxy properties of the topology service application.

Set-SPTopologyServiceApplicationProxy [-Identity] <SPTopologyWebServiceProxyPipeBind> -BadListPeriod <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPTopologyWebServiceProxyPipeBind

Specifies the GUID of the application proxy.

The type must be a valid GUID, in the form 1234-4567-098jhj.

BadListPeriod

Required

System.String

Specifies the time period that a node is kept in a bad list.

The type must be a valid value between 1 and 28800 (in seconds).

The default value is 10.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Set-SPTopologyServiceApplicationProxy cmdlet sets the properties of the local topology service application proxy and the default load balancer.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Set-SPTopologyServiceApplicationProxy 67877d63-bff4-4521-867a-ef4979ba07ce -BadListPeriod 1234

This example sets the bad list period for the given topology service application proxy.

The topology service application GUID is unique to every farm. You can run the Get-SPTopologyServiceApplication cmdlet to retrieve the GUID.

See Also

Reference

Get-SPTopologyServiceApplicationProxy
Get-SPTopologyServiceApplication


Set-SPUsageApplication
See Also Example
[image]

Published: May 12, 2010

Sets properties of a usage application.

Set-SPUsageApplication [-Identity] <SPUsageApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DatabaseName <String>] [-DatabasePassword <SecureString>] [-DatabaseServer <String>] [-DatabaseUsername <String>] [-EnableLogging <SwitchParameter>] [-FailoverDatabaseServer <String>] [-UsageService <SPUsageServicePipeBind>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPUsageApplicationPipeBind

Specifies the usage application to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh, a valid name of a usage application (for example; UsageApp1); or an instance of a valid SPServiceApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DatabaseName

Optional

System.String

Specifies the name of the logging database.

The type must be a valid name of a SQL Server database; for example, UsageLogDB1.

If the logging database does not exist, a logging database will be automatically created.

DatabasePassword

Optional

System.Security.SecureString

Specifies the password for the user specified in DatabaseUserName. Use this parameter only if SQL Server Authentication is used to access the logging database.

The type must be a valid password.

DatabaseServer

Optional

System.String

Specifies the name of the host server for the database specified in DatabaseName.

The type must be a valid SQL Server host name; for example, SQLServerHost1.

DatabaseUsername

Optional

System.String

Specifies the user name to use for connecting to the logging database. Use this parameter only if SQL Server Authentication is used to access the logging database.

The type must be a valid user name; for example, UserName1.

EnableLogging

Optional

System.Management.Automation.SwitchParameter

Specifies that this usage application collects usage data.

FailoverDatabaseServer

Optional

System.String

UsageService

Optional

Microsoft.SharePoint.PowerShell.SPUsageServicePipeBind

Specifies the SPUsageService object that is the parent of the usage application.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a usage service (for example, UsageService1); or an instance of a valid SPUsageService object.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Set-SPUsageApplication cmdlet sets properties of a usage application.

Input Types

Return Types

Example

-------------------EXAMPLE----------------------

Copy Code
Set-SPUsageApplication -Identity "Usage and Health data collection" -DatabaseServer "Server Name" -DatabaseName "New Logging DB

This example changes the database server and database name used by the usage logging service to store logging data.

See Also

Reference

Get-SPUsageApplication
New-SPUsageApplication
Remove-SPUsageApplication


Set-SPUsageDefinition
See Also Example
[image]

Published: May 12, 2010

Sets the retention period for a usage provider.

Set-SPUsageDefinition [-Identity] <SPUsageDefinitionPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DaysRetained <Int32>] [-Enable <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPUsageDefinitionPipeBind

Specifies the usage definition object to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a usage definition (for example, SiteSubscriptionConfig1); or an instance of a valid SPUsageDefinition object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DaysRetained

Optional

System.Int32

Specifies the number of days that usage data for the usage provider is retained in the usage service database. The default value is 14.

The type must be an integer between 0 and 31.

Enable

Optional

System.Management.Automation.SwitchParameter

Turns on the specified usage provider.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Set-SPUsageDefinition cmdlet sets the retention period for a specified usage provider. A usage definition object defines a specific type of usage provider.

Input Types

Return Types

Example

-----------------EXAMPLE--------------------

Copy Code
Set-SPUsageDefinition -Identity "Page Requests" -DaysRetained 31

This example sets the number of days that stores page requests usage data to 31.

See Also

Reference

Get-SPUsageDefinition


Set-SPUsageService
See Also Example
[image]

Published: May 12, 2010

Sets the properties of a usage service.

Set-SPUsageService [[-Identity] <SPUsageServicePipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-LoggingEnabled <Nullable>] [-UsageLogCutTime <UInt32>] [-UsageLogLocation <String>] [-UsageLogMaxSpaceGB <UInt32>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPUsageServicePipeBind

Specifies the usage service to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a usage service (for example, UsageService1); or an instance of a valid SPUsageService object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

LoggingEnabled

Optional

System.Nullable

Specifies that usage data is logged to usage files.

UsageLogCutTime

Optional

System.UInt32

Specifies the time, in minutes, of usage data collected per usage log file. The default time is 5 minutes.

The type must be an integer in the range of 1 to 1440.

UsageLogLocation

Optional

System.String

Specifies the path on every computer in the farm where usage log files are created.

The type must be a valid path in either of the following forms:

- C:\folder_name

- \\server_name\folder_name

UsageLogMaxSpaceGB

Optional

System.UInt32

Specifies the amount in megabytes (MB) of space that can be used by usage log files. The valid range is 500 to 20,000 MB.

The default value is 5,000.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Set-SPUsageService cmdlet updates the properties of a usage service. If the Identity parameter is not specified, the cmdlet applies the changes to the local usage service.

Input Types

Return Types

Example

--------------------EXAMPLE-----------------

Copy Code
Set-SPUsageService -LoggingEnabled $false
Copy Code
Set-SPUsageService -UsageLogLocation "d:\\testusagelogdir
Copy Code
Set-SPUsageService -UsageLogCutTime 5

The examples disable usage logging, change the directory where usage files are stored, and creates a new usage log file every 5 minutes.

See Also

Reference

Get-SPUsageService


Start-SPServiceInstance
See Also Example
[image]

Published: May 12, 2010

Starts the service instance for a service on a specific server or the farm.

Start-SPServiceInstance [-Identity] <SPServiceInstancePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceInstancePipeBind

Specifies the GUID of the service instance to get.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

Use the Start-SPServiceInstance cmdlet to start the service instance for a service on a specific server or on the farm.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE-----------------------

Copy Code
Start-SPServiceInstance 67877d63-bff4-4521-867a-ef4979ba07ce

This example starts the given service instance on the server.

The service instance GUID is unique to every farm. You can run the Get-SPServiceInstance cmdlet to see the GUID of the service instances, and then use the result from the SPServiceInstance cmdlet for other cmdlets.

See Also

Reference

Get-SPServiceInstance


Stop-SPServiceInstance
See Also Example
[image]

Published: May 12, 2010

Stops the service instance for a service.

Stop-SPServiceInstance [-Identity] <SPServiceInstancePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceInstancePipeBind

Specifies the GUID of the service instance to get.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

Stops the service instance for a service on the specified server or for the farm.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE-----------------------

Copy Code
Stop-SPServiceInstance 67877d63-bff4-4521-867a-ef4979ba07ce

This example stops the service instance in the given server.

The service instance GUID is unique to every farm. You can run the Get-SPServiceInstance cmdlet to see the GUID of the service instances, and then use the result from the SPServiceInstance cmdlet for other cmdlets.

See Also

Reference

Get-SPServiceInstance
Start-SPServiceInstance


Unpublish-SPServiceApplication
See Also Example
[image]

Published: May 12, 2010

Stops sharing the specified service application outside the farm.

Unpublish-SPServiceApplication [-Identity] <SPServiceApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationPipeBind

Specifies the GUID of the service application to stop sharing outside the farm.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

Use the Unpublish-SPServiceApplication cmdlet to stop publishing the service application, specified by the Identity parameter, outside the farm.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE-----------------------

Copy Code
UnPublish-SPServiceApplication 053c34be-d251-488c-8e94-644eae94da26

This example stops publishing of the specified service application outside the farm.

The service application GUID is unique to every farm. You can run the Get-SPServiceApplication cmdlet to see the GUID of the service applications, and then use the result from the Get-SPServiceApplication cmdlet for other SPServiceApplication cmdlets; for example, Grant-SPServiceApplication or Publish-SPServiceApplication.

See Also

Reference

Get-SPServiceApplication
Set-SPServiceApplication
Publish-SPServiceApplication
Revoke-SPServiceApplication
Grant-SPServiceApplication


SharePoint Foundation 2010 Search cmdlets (SharePoint Foundation 2010)
See Also

Search for Microsoft SharePoint Foundation 2010 provides embedded search for site collections. Typically, Search for SharePoint Foundation 2010 is scoped to a single site collection and does not crawl external data sources. Most search capabilities are configured automatically, and search crawls happen automatically without scheduling and without administrator control.

Cmdlet name | Description
Get-SPSearchService | Returns a search service.
Set-SPSearchService | Sets properties of a search service.
Get-SPSearchServiceInstance | Returns an instance of a search service.
Set-SPSearchServiceInstance | Sets properties of a search service instance.

See Also

Other Resources

Resource Center: Windows PowerShell for SharePoint Foundation 2010


Get-SPSearchService
See Also Example
[image]

Published: May 12, 2010

Returns a search service.

Get-SPSearchService [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPSearchService cmdlet reads the SPSearch object when the cmdlet updates a search service.

Input Types

Return Types

Example

--------------------EXAMPLE--------------------

Copy Code
$searchService = Get-SPSearchService

This example obtains a reference to the search service object.

See Also

Reference

Set-SPSearchService
Get-SPSearchServiceInstance
Set-SPSearchServiceInstance


Set-SPSearchService
See Also Example
[image]

Published: May 12, 2010

Sets properties of a search service.

Set-SPSearchService [[-Identity] <SPSearchServicePipeBind>] [-AddStartAddressForNonNTZone <String>] [-AssignmentCollection <SPAssignmentCollection>] [-CrawlAccount <String>] [-CrawlPassword <SecureString>] [-MaxBackupDuration <String>] [-PerformanceLevel <String>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.Search.Cmdlet.SPSearchServicePipeBind

Specifies the search service instance to set.

The type must be a valid GUID, such as 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a search service instance, such as SearchServiceInstance1; or an instance a valid SearchServiceInstance object

AddStartAddressForNonNTZone

Optional

System.String

Specifies to add start address for Web applications that do not have a Windows NT zone.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

CrawlAccount

Optional

System.String

Specifies the user account or service account to use for crawling.

The type must be a valid administrator account, such as MyAdminAcct1.

CrawlPassword

Optional

System.Security.SecureString

Provides the password for the service account that is specified in CrawlAccount.

The type must be a valid password, such as UserIDPassword.

MaxBackupDuration

Optional

System.String

Specifies the interval, in minutes, from the time the backup operation started for the search service in the Microsoft SharePoint Foundation 2010 content index and the time the search services will resume.

PerformanceLevel

Optional

System.String

Specifies the relative number of threads for the indexer performance:

Reduced: Total number of threads = number of processors, Max Threads/host = number of processors

PartlyReduced: Total number of threads = 4 times the number of processors , Max Threads/host = 16 times the number of processors

Maximum: Total number of threads = number of processors

The type must be any of the following values: Reduced, PartlyReduced, orMaximum

Detailed Description

The Set-SPSearchService cmdlet modifies the SearchService object properties.

Input Types

Return Types

Example

--------------------EXAMPLE--------------------

Copy Code
Set-SPSearchService -MaxBackupDuration 120

This example sets the maximum time, in minutes, between the start of a backup and the resumption of search services.

See Also

Reference

Get-SPSearchService
Get-SPSearchServiceInstance
Set-SPSearchServiceInstance


Get-SPSearchServiceInstance
See Also Example
[image]

Published: May 12, 2010

Returns an instance of a search service.

Get-SPSearchServiceInstance [[-Identity] <SPSearchServiceInstancePipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-Local <SwitchParameter>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.Search.Cmdlet.SPSearchServiceInstancePipeBind

Specifies the search service to update.

The type must be a valid GUID, such as 12345678-90ab-cdef-1234-567890bcdefgh a valid name of a search service, such as MySearch1; or an instance a valid SearchService object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Local

Optional

System.Management.Automation.SwitchParameter

Specifies to return the search service instance for the current search server.

Detailed Description

The Get-SPSearchServiceInstance cmdlet reads an SPSearchServiceInstance object when the cmdlet updates an instance of a search service that runs on one or more servers in the server farm.

Input Types

Return Types

Example

--------------------EXAMPLE--------------------

Copy Code
Get-SPSearchServiceInstance -Local

This example obtains a reference to the search service instance object that runs on the local computer.

See Also

Reference

Set-SPSearchService
Get-SPSearchService
Set-SPSearchServiceInstance


Set-SPSearchServiceInstance
See Also Example
[image]

Published: May 12, 2010

Sets properties of a search service instance.

Set-SPSearchServiceInstance [-Identity] <SPSearchServiceInstancePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-ProxyType <String>]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.Search.Cmdlet.SPSearchServiceInstancePipeBind

Specifies the search service instance to set.

The type must be a valid GUID, such as 12345678-90ab-cdef-1234-567890bcdefgh, or a valid name of a search service instance, such as SearchServiceInstance1, or an instance a valid SearchServiceInstance object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

ProxyType

Optional

System.String

Defines whether crawler uses default, direct, or proxy connection parameters. Valid values are default, direct, and proxy. The default value is default.

The type must be a valid name of a proxy type, such as default.

Detailed Description

The Set-SPSearchServiceInstance cmdlet modifies the SearchServiceInstance object.

Input Types

Return Types

Example

--------------------EXAMPLE--------------------

Copy Code
Get-SPSearchServiceInstance -Local | Set-SPSearchServiceInstance -ProxyType proxy

This example sets the local search service instance proxy type to proxy.

See Also

Reference

Set-SPSearchService
Get-SPSearchService
Get-SPSearchServiceInstance


Site collection cmdlets (SharePoint Foundation 2010)

Published: June 24, 2010

You can use Windows PowerShell cmdlets for site collection administration for Microsoft SharePoint Foundation 2010.

Cmdlet name | Description
Get-SPWebPartPack | Returns the Web Part packages that were installed for the specified scope.
Install-SPWebPartPack | Installs the specified Web Part package to the specified location.
Uninstall-SPWebPartPack | Uninstalls the specified Web Part package.


Get-SPWebPartPack
See Also Example
[image]

Published: May 12, 2010

Returns the Web Part packages that were installed for the specified scope.

Get-SPWebPartPack [[-Identity] <String>] [-AssignmentCollection <SPAssignmentCollection>] [-GlobalOnly <SwitchParameter>] [-WebApplication <SPWebApplicationPipeBind>]

Parameters

Parameter Required Type Description

Identity

Optional

System.String

Specifies the full or partial name of the Web Part package from the configuration database.

The type must be a valid name of a Web Part package; for example, MyWebPartPackage.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

GlobalOnly

Optional

System.Management.Automation.SwitchParameter

Returns only Web Part packages that are installed in the global assembly cache (GAC).

WebApplication

Optional

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the Web application from which to list Web Part packages. If no Web application is specified, the specified Web Part packages will be returned from all Web applications.

Detailed Description

The Get-SPWebPartPack cmdlet returns the installed Web Part packages that match the Identity parameter. The scope of results can be narrowed by using the optional WebApplication parameter. The scope does not include any Web Part packages installed in the global assembly cache (GAC) unless the GlobalOnly parameter is used. If this parameter is used, only Web Part packages that have been installed in the GAC are returned.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Get-SPWebPartPack -WebApplication http://zsharepoint2:80

This example returns all Web Part packages that have been installed on the Web application on port 80 in local farm.

See Also

Reference

Install-SPWebPartPack
Uninstall-SPWebPartPack


Install-SPWebPartPack
See Also Example
[image]

Published: May 12, 2010

Installs the specified Web Part package to the specified location.

Install-SPWebPartPack [-LiteralPath] <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-GlobalInstall <SwitchParameter>] [-Language <UInt32>] [-WebApplication <SPWebApplicationPipeBind>] [-WhatIf [<SwitchParameter>]]
Install-SPWebPartPack [-Name] <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-GlobalInstall <SwitchParameter>] [-Language <UInt32>] [-WebApplication <SPWebApplicationPipeBind>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

LiteralPath

Required

System.String

Specifies the exact path to the Web Part package.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Overwrites any existing Web Part package with the same name or installed in the same location.

GlobalInstall

Optional

System.Management.Automation.SwitchParameter

Installs the Web Part package in the global assembly cache (GAC) rather than in the /bin directory of each Web application. This installation makes the Web Part globally accessible on the servers.

Language

Optional

System.UInt32

Specifies the language ID for the Web Part package.

WebApplication

Optional

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the Web application on which to install the Web Part pack. If no Web application is specified, the Web Part pack is installed on all Web applications.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Name

Required

System.String

Specifies the name of the Web Part package to install.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Overwrites any existing Web Part package with the same name or installed in the same location.

GlobalInstall

Optional

System.Management.Automation.SwitchParameter

Installs the Web Part package in the global assembly cache (GAC) rather than in the /bin directory of each Web application. This installation makes the Web Part globally accessible on the servers.

Language

Optional

System.UInt32

Specifies the language ID for the Web Part package.

WebApplication

Optional

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the Web application on which to install the Web Part pack. If no Web application is specified, the Web Part pack is installed on all Web applications.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Install-SPWebPartPack cmdlet installs the Web Part package, at the LiteralPath parameter location, in the local farm. The Web Part package can be installed in a specific Web application by using the WebApplication parameter. If a Web application is not specified, the Web Part package is installed in all Web applications.

Use the Language parameter to specify a package language.

Use the GlobalInstall parameter to install the package to the global assembly cache (GAC). Assemblies in the GAC are granted FullTrust permission, which gives this package full access to all system-wide resources.

Use the Force parameter to install the package to overwrite any existing Web Part package with the same name or installed in the same location.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Install-SPWebPartPack "MyCustomWebPartPack" -LiteralPath "c:/mywebpart.wpp" -GlobalInstall

This example installs the Web Part Package with the name MyCustomWebPartPack globally in the farm from the path c:/mywebpart.wpp.

See Also

Reference

Uninstall-SPWebPartPack
Get-SPWebPartPack


Uninstall-SPWebPartPack
See Also Example
[image]

Published: May 12, 2010

Uninstalls the specified Web Part package.

Uninstall-SPWebPartPack [-Identity] <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Language <UInt32>] [-WebApplication <SPWebApplicationPipeBind>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

System.String

Specifies the Web Part package in the farm's configuration database.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Language

Optional

System.Int32

Specifies the language ID of the Web Part package to delete. If no language is specified, the Web Part package is uninstalled for all languages.

The type must be a valid language identifier, in the form 1033.

WebApplication

Optional

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the Web application from which to uninstall the Web Part package. If no Web application is specified, the Web Part package is uninstalled from all Web applications.

The type must be a valid name, in the form WebApplication-1212, or a URL, in the form http://server_name/WebApplication-1212.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Uninstall-SPWebPartPack cmdlet uninstalls the Web Part package specified by the Identity parameter.

Input Types

Return Types

None

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------------EXAMPLE1------------------

Copy Code
Uninstall-SPWebPartPack  "mypart.wpp" -WebApplication http://portal

This example uninstalls mypart.wpp to from the Web application http://portal.

------------------EXAMPLE2------------------

Copy Code
Get-SPWebPartPack -WebApplication http://portal | Uninstall-SPWebPartPack

This example uninstalls all Web part packages from the Web application http://portal.

See Also

Reference

Get-SPWebPartPack
Install-SPWebPartPack


Site management cmdlets (SharePoint Foundation 2010)
See Also

You can use Windows PowerShell cmdlets to manage sites in a Microsoft SharePoint Foundation 2010 farm.

Cmdlet name | Description
Get-SPCustomLayoutsPage | Returns a mapping to a custom layout page.
Get-SPUser | Returns the user account or accounts that match a given search criteria.
Get-SPWeb | Returns all subsites that match the given criteria.
Get-SPWebApplication | Returns all Web applications that match the given criteria.
Get-SPFarm | Returns the local SharePoint farm.
Get-SPProduct | Returns a list of the SharePoint-related products installed in the farm and the versions of all updates installed for each product.
Get-SPServer | Returns the server or servers in the farm that match the given identity.
Get-SPDeletedSite | Gets a list of deleted site collections. This cmdlet was introduced in Microsoft SharePoint Foundation 2010 with Service Pack 1 (SP1).
Get-SPSite | Returns all site collections that match the given criteria.
Get-SPSiteAdministration | Returns a site administration object that farm administrators can use to view certain information about site collections to which they might not have access.
Get-SPSiteSubscription | Returns the site subscription for the given URL or all site subscriptions in the local farm.
Get-SPSiteSubscriptionConfig | Returns the configuration properties of a site subscription.
Move-SPSite | Moves site collections from one content database to another.
Move-SPUser | Migrates a user account in SharePoint 2010 Products.
New-SPSite | Creates a new site collection at the specified URL.
New-SPSiteSubscription | Creates a new site subscription.
New-SPUser | Adds an existing user to a SharePoint site with the designated permissions.
New-SPWeb | Creates a new site in an existing site collection.
New-SPWebApplication | Creates a new Web application within the local farm.
New-SPWebApplicationExtension | Creates a new zone instance for the Web application.
Remove-SPDeletedSite | Removes a deleted site collection. This cmdlet was introduced in SharePoint Foundation 2010 with SP1.
Remove-SPSite | Completely deletes an existing site collection and all subsites.
Remove-SPSiteSubscription | Removes data stored in a subscription settings service application for a set of site subscriptions.
Remove-SPSiteSubscriptionSettings | Removes the settings service data for a specified site subscription, or finds and removes orphaned data.
Remove-SPUser | Removes a user from a Web site.
Remove-SPWeb | Completely deletes the specified Web.
Remove-SPWebApplication | Deletes the specified Web application.
Rename-SPServer | Renames a server that is currently connected to the farm.
Restore-SPDeletedSite | Restores a deleted site collection. This cmdlet was introduced in SharePoint Foundation 2010 with SP1.
Set-SPSite | Configures the specified site collection.
Set-SPSiteAdministration | Allows farm administrators to configure any site collection.
Set-SPSiteSubscriptionConfig | Sets the configuration properties of a site subscription.
Set-SPSubscriptionSettingsServiceApplication | Sets properties of a subscription settings service application.
Set-SPUser | Configures properties on an existing user.
Set-SPWebApplication | Configures the specified Web application.
Set-SPWeb | Configures the specified subsite.
Export-SPSiteSubscriptionSettings | Creates a backup file of site subscription data.
Import-SPSiteSubscriptionSettings | Restores a backup of subscription site settings to the given subscription identifier.

See Also

Other Resources

Resource Center: Windows PowerShell for SharePoint Foundation 2010


Get-SPCustomLayoutsPage
Example
[image]

Published: May 12, 2010

Returns a mapping to a custom layout page.

Get-SPCustomLayoutsPage -WebApplication <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Identity <None | AccessDenied | Confirmation | Error | Login | RequestAccess | Signout | WebDeleted>]

Parameters

Parameter Required Type Description

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the SharePoint Web application that contains the custom layout page.

The type must be a valid URL, in the form http://server_name; a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of SharePoint Web application (for example, MyOfficeApp1); or an instance of a valid SPWebApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Identity

Optional

Microsoft.SharePoint.Administration.SPWebApplication+SPCustomPage

Specifies the custom layout page to get.

The type must be one of the following: None, AccessDenied, Confirmation, Error, Login, RequestAccess, Signout, or WebDeleted.

Detailed Description

The Get-SPCustomLayoutsPagecmdlet cmdlet returns a mapping to a custom layout page in a Web application. If the Identity parameter is not specified, this cmdlet returns the collection of mappings for all custom layout pages.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Get-SPCustomLayoutsPage -Identity "_layouts/accessdenied.aspx" -WebApplication "http://server_name/mywebapp"

This example returns the mapping of the AccessDenied layout page in the Web application.


Get-SPUser
See Also Example
[image]

Published: May 12, 2010

Returns the user account or accounts that match a given search criteria.

Get-SPUser [[-Identity] <SPUserPipeBind>] -Web <SPWebPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Group <SPGroupPipeBind>] [-Limit <String>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPUserPipeBind

Specifies the GUID or login name of the user to be returned.

The type must be a valid URL, in the form http://server_name, or GUID, in the form1234-5678-9807.

Web

Required

Microsoft.SharePoint.PowerShell.SPWebPipeBind

Specifies the Web site to be used as a scope.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a Microsoft SharePoint Foundation 2010 Web site (for example, MySPSite1); or an instance of a valid SPWeb object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Group

Optional

Microsoft.SharePoint.PowerShell.SPGroupPipeBind

Specifies the user group to which the new user belongs.

Limit

Optional

System.String

Specifies the maximum number of users to return. The default value is 500.

Detailed Description

The Get-SPUser cmdlet returns all SharePoint user accounts that match the scope given by the Identity, Web, or Group parameters.

The Identity parameter can use the alias of a user for returning exact matches. However, a scope must be provided if the Get-SPUser cmdlet is to work.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Get-SPUser -Web "http://zsharepoint2" -Group "Viewers"

This example returns all members of the group Viewers on the Web site http://zsharepoint2.

See Also

Reference

Move-SPUser
New-SPUser
Set-SPUser
Remove-SPUser


Get-SPWeb
See Also Example
[image]

Published: May 12, 2010

Returns all subsites that match the given criteria.

Get-SPWeb [[-Identity] <SPWebPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Filter <ScriptBlock>] [-Limit <String>] [-Regex <SwitchParameter>] [-Site <SPSitePipeBind>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPWebPipeBind

Specifies the name or full or partial URL of the subsite. If you use a relative path, you must specify the Site parameter.

A valid URL in the form http://server_name or a relative path in the form of /SubSites/MySubSite.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Filter

Optional

System.Management.Automation.ScriptBlock

Specifies the server-side filter to use for the specified scope.

The type must be a valid filter in the form {filterName <operator> "filterValue"}.

Limit

Optional

System.String

Limits the maximum number of subsites to return. The default value is 200. To return all sites, enter ALL

The type must be a valid number greater than 0 or ALL.

Regex

Optional

System.Management.Automation.SwitchParameter

Specifies the URL that is provided by the Identity parameter is treated as a regular expression.

Site

Optional

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Specifies the URL or GUID of the site collection from which to list subsites.

The type must be a valid URL, in the form of http://server_name; a GUID, in the form 1234-5678-9807, or an SPSite object.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Get-SPWeb cmdlet returns all subsites that match the scope given by the Identity parameter. All subsites that meet the criteria are returned.

The Identity can be either the full URL or a relative path. If you specify a relative path, you must also specify the Site parameter to identify the site collection from which to return the subsite.

The Identity parameter also supports providing a partial URL that ends in a wildcard character (*). All subsites that match this partial URL for the specified scope are returned. Additionally, if the Regex parameter is provided, the Identity parameter is treated as a regular expression and any subweb with a URL provided in the given scope that matches the expression is returned.

The Filter parameter is a server-side filter for certain subsite properties that are stored in the content database; without the Filter parameter, filtering on these properties is a slow process. These subsite properties are Template and Title. The Filter parameter is a script block that uses the same syntax as a Where-Object statement, but is run server-side for faster results.

It is important to note that every site collection returned by the Get-SPWeb cmdlet is automatically disposed of at the end of the pipeline. To store the results of Get-SPWeb in a local variable, the Start-SPAssignment and Stop-SPAssignment cmdlets must be used to avoid memory leaks.

Input Types

Return Types

Example

--------------------EXAMPLE 1----------------------

Copy Code
Get-SPWeb -site http://sitename/sites/site1

This example returns all the subwebs in a given site collection.

--------------------EXAMPLE 2----------------------

Copy Code
Get-SPWeb -Site http://sitename/sites/site1  -filter {$_.Template -eq "STS#0"}

This example displays all subsites that use the "STS#0" template.

--------------------EXAMPLE 3----------------------

Copy Code
Start-SPAssignment -Global
Copy Code
$w = Get-SPWeb http://sitename
Copy Code
$w.set_SiteLogoUrl("http://PathToImage/test.jpg")
Copy Code
$w.Update()
Copy Code
Stop-SPAssignment -Global

This example demonstrates how to save a subsite as a variable and to call object model methods on the SPAssignment object.

See Also

Reference

New-SPWeb
Set-SPWeb
Remove-SPWeb
Import-SPWeb


Get-SPWebApplication
See Also Example
[image]

Published: May 12, 2010

Returns all Web applications that match the given criteria.

Get-SPWebApplication [[-Identity] <SPWebApplicationPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-IncludeCentralAdministration <SwitchParameter>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the name, URL, or GUID of the Web application.

The type must be a valid URL, in the form http://server_name; a GUID, in the form 1234-5678-9876-0987; or a valid name, in the form SPWebApplication - 1212.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

IncludeCentralAdministration

Optional

System.Management.Automation.SwitchParameter

Includes the Central Administration Web application in the collection of Web applications that can be returned. The IncludeCentral Administration parameter must still meet any other filters provided.

Detailed Description

The Get-SPWebApplication cmdlet returns all Web applications that match the scope given by the Identity parameter. The Identity can be the name of the name, URL, or GUID of the Web application. If no Identity is specified, all Web applications are returned.

The Central Administration Web application is only returned if its exact identity is provided or the IncludeCentralAdministration flag is provided.

Input Types

Return Types

Example

------------------EXAMPLE 1----------------------

Copy Code
$w = Get-SPWebApplication http://sitename

This example gets the Web application for http://sitename and stores it in a variable.

------------------EXAMPLE 2-----------------------

Copy Code
Get-SPWebApplication -IncludeCentralAdministration | Where { $_.DefaultServerComment -eq "SharePoint Central Administration v4"} | Format-List *

This example displays all public properties on the SharePoint Central Administration Web application in list format.

See Also

Reference

Get-SPWebApplicationHttpThrottlingMonitor


Get-SPFarm
See Also Example
[image]

Published: May 12, 2010

Returns the local SharePoint farm.

Get-SPFarm [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPFarm cmdlet returns the local SharePoint farm. No parameters are used.

Input Types

Return Types

SPFarm

Example

Copy Code
$f = Get-SPFarm

This example stores the local farm in a variable.

See Also

Reference

Get-SPFarmConfig
Set-SPFarmConfig
Backup-SPFarm
Restore-SPFarm


Get-SPProduct
Example
[image]

Published: May 12, 2010

Returns a list of the SharePoint-related products installed in the farm and the versions of all updates installed for each product.

Get-SPProduct [-AssignmentCollection <SPAssignmentCollection>] [-Local <SwitchParameter>]
Get-SPProduct [-AssignmentCollection <SPAssignmentCollection>] [-Server <SPServerPipeBind>]

Parameters

1

Parameter

Required

Type

Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Local

Optional

System.Management.Automation.SwitchParameter

Returns product and update information for only the local computer. If you use the Local parameter, you cannot use the Server parameter.

2

Parameter

Required

Type

Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Server

Optional

Microsoft.SharePoint.PowerShell.SPServerPipeBind

Returns product and update information for a specified server. If you use the Server parameter, you cannot use the Local parameter.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Get-SPProduct cmdlet returns a list of the SharePoint-related products installed in the farm and the versions of all updates installed for each product. By default this cmdlet returns the list of SharePoint-related products installed in the farm. Use the Local parameter to get only information about the local server or for a specific server to get the list, use the Server parameter.

Input Types

Return Types

Example

--------------EXAMPLE-----------------

Copy Code
Get-SPProduct -Local

This example displays the SharePoint-related products installed on the local server.


Get-SPServer
See Also Example
[image]

Published: May 12, 2010

Returns the server or servers in the farm that match the given identity.

Get-SPServer [[-Identity] <SPServerPipeBind>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPServerPipeBind

Specifies the address of the server to return.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPServer cmdlet returns the SPServer object for the given identity (if it exists in the farm). If no parameters are specified, the cmdlet returns all servers in the farm.

Input Types

Return Types

Example

--------------EXAMPLE 1-----------------

Copy Code
Get-SPServer

This example returns all servers in the local farm in a list.

--------------EXAMPLE 2-----------------

Copy Code
Get-SPServer | Where{ $_.NeedsUpgrade -eq $TRUE}

This example returns a list of all servers in the farm that need an upgrade.

See Also

Reference

Rename-SPServer


Get-SPSite
See Also Example
[image]

Published: May 12, 2010

Returns all site collections that match the given criteria.

Get-SPSite [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Filter <ScriptBlock>] [-Limit <String>] [-WebApplication <SPWebApplicationPipeBind>] [-WhatIf [<SwitchParameter>]]
Get-SPSite [-Identity] <SPSitePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Filter <ScriptBlock>] [-Limit <String>] [-Regex <SwitchParameter>] [-WhatIf [<SwitchParameter>]]
Get-SPSite -ContentDatabase <SPContentDatabasePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Filter <ScriptBlock>] [-Limit <String>] [-WhatIf [<SwitchParameter>]]
Get-SPSite -SiteSubscription <SPSiteSubscriptionPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Filter <ScriptBlock>] [-Limit <String>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Filter

Optional

System.Management.Automation.ScriptBlock

Specifies the script block of the server-side filter to apply.

The type must be a valid filter name and value in the form {$_PropertyName <operator> "filterValue"}.

Valid operators are: EQ, NE, LIKE, NOTLIKE.

Limit

Optional

System.String

Limits the maximum number of site collections to return. The default value is 200.

The type must be a valid non-negative number. Specify ALL to return all site collections for the given scope.

WebApplication

Optional

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the URL, GUID, or name of the Web application from which to list sites.

The type must be a valid URL, in the form http://server_name, a valid GUID (for example, 12345678-90ab-cdef-1234-567890bcdefgh); or the Web application name (for example, WebApplication1212).

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Specifies the URL or GUID of the site collection to get.

The type must be a valid URL, in the form http://server_name or http://server_name/sites/sitename, or a valid GUID (for example, 12345678-90ab-cdef-1234-567890bcdefgh).

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Filter

Optional

System.Management.Automation.ScriptBlock

Specifies the script block of the server-side filter to apply.

The type must be a valid filter name and value in the form {$_PropertyName <operator> "filterValue"}.

Valid operators are: EQ, NE, LIKE, NOTLIKE.

Limit

Optional

System.String

Limits the maximum number of site collections to return. The default value is 200.

The type must be a valid non-negative number. Specify ALL to return all site collections for the given scope.

Regex

Optional

System.Management.Automation.SwitchParameter

When used, the URL provided for the Identity parameter to be treated as a regular expression.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

3

Parameter

Required

Type

Description

ContentDatabase

Required

Microsoft.SharePoint.PowerShell.SPContentDatabasePipeBind

Specifies the GUID of the content database from which to list site collections.

The type must be a valid database name, in the form SPContentDB01, or a valid GUID (for example, 12345678-90ab-cdef-1234-567890bcdefgh).

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Filter

Optional

System.Management.Automation.ScriptBlock

Specifies the script block of the server-side filter to apply.

The type must be a valid filter name and value in the form {$_PropertyName <operator> "filterValue"}.

Valid operators are: EQ, NE, LIKE, NOTLIKE.

Limit

Optional

System.String

Limits the maximum number of site collections to return. The default value is 200.

The type must be a valid non-negative number. Specify ALL to return all site collections for the given scope.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

4

Parameter

Required

Type

Description

SiteSubscription

Required

Microsoft.SharePoint.PowerShell.SPSiteSubscriptionPipeBind

Specifies the site subscription from which to get site collections.

The type must be a valid URL, in the form http://server_name or a valid GUID (for example, 12345678-90ab-cdef-1234-567890bcdefgh).

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Filter

Optional

System.Management.Automation.ScriptBlock

Specifies the script block of the server-side filter to apply.

The type must be a valid filter name and value in the form {$_PropertyName <operator> "filterValue"}.

Valid operators are: EQ, NE, LIKE, NOTLIKE.

Limit

Optional

System.String

Limits the maximum number of site collections to return. The default value is 200.

The type must be a valid non-negative number. Specify ALL to return all site collections for the given scope.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Get-SPSite cmdlet returns either a single site that matches the Identity parameter, or all the sites that match the Filter parameter for the specified scope. The scopes are the WebApplication, ContentDatabase , and SiteSubscription parameters. If none of these scopes is provided, the scope is the farm. If the scope is specified with no Filter parameter, all sites in that scope are returned.

The Identity parameter supports providing a partial URL that ends in a wildcard character (*). All site collections that match this partial URL for the specified scope are returned. Additionally, if the Regex parameter is provided, the Identity parameter is treated as a regular expression and any site collection with a URL provided in the given scope that matches the expression is returned.

The Filter parameter is a server-side filter for certain site collection properties that are stored in the content database; without the Filter parameter, filtering on these properties is a slow process. These site collection properties are Owner, SecondaryOwner, and LockState. The Filter parameter is a script block that uses the same syntax as a Where-Object statement, but is run server-side for faster results.

Valid values for LockState are, Unlock, NoAdditions, ReadOnly, NoAccess.

It is important to note that every site collection returned by the Get-SPSite cmdlet is automatically disposed of at the end of the pipeline. To store the results of Get-SPSite in a local variable, the Start-SPAssignment and Stop-SPAssignment cmdlets must be used to avoid memory leaks.

Input Types

None

Return Types

Example

------------------EXAMPLE 1---------------------

Copy Code
Get-SPSite 'http://sitename' | Get-SPWeb -Limit All | Select Title

This example gets the collection of subweb titles in site collection at http://sitename.

------------------EXAMPLE 2---------------------

Copy Code
Get-SPSite -ContentDatabase "b399a366-d899-4cff-8a9b-8c0594ee755f" | Format-Table -Property Url, Owner, SecondaryOwner

This example gets a subset of data from all of the sites in the content database b399a366-d899-4cff-8a9b-8c0594ee755f.

------------------EXAMPLE 3---------------------

Copy Code
Start-SPAssignment -Global
Copy Code
$s = Get-SPSite -Identity http://MyApp/Sites/Site1
Copy Code
$s.Url
Copy Code
Stop-SPAssignment -Global

This example gets the sites specified by the Identity parameter and inserts the results in the variable s

The previous example uses the Global method of assignment collection. The Global method is easier to use but the contents of this object grows quickly. Be careful not to run a Get-SPSite command that returns many results while global assignment is enabled.

------------------EXAMPLE 4---------------------

Copy Code
$GC = Start-SPAssignment
Copy Code
$Sites = $GC | Get-SPSite -Filter {$_.Owner -eq "DOMAIN\JDoe"} -Limit 50
Copy Code
Stop-SPAssignment $GC

This example gets the first 50 sites owned by user DOMAIN\JDoe by using a server-side query, and assigns them to a local variable.

This example uses advanced assignment collection methods.

------------------EXAMPLE 5---------------------

Copy Code
Get-SPWebApplication http://sitename | Get-SPSite -Limit All |ForEach-Object {$sum=0}{ $sum+=$_.Usage.Storage }{$sum}

This example shows a command that returns the sum of the disk space usage for all sites in a given Web application.

------------------EXAMPLE 6---------------------

Copy Code
Get-SPSite -Identity "http://localserver/(my|personal)/sites" -Regex

This example returns all sites that match the given regular expression.

The Quotes on the Identity parameter are required when the Regex parameter is used.

------------------EXAMPLE 7---------------------

Copy Code
Get-SPSite http://sitename/sites/teams/* -Limit 100

This example gets up to 100 of the sites under the URL http://sitename/sites/teams.

------------------EXAMPLE 8---------------------

Copy Code
Get-SPSite | select url, @{Expression={$_.Usage.Storage}}

This example gets the amount of storage used by a site collection, by using the storage field of the .UsageInfo property.

See Also

Reference

Backup-SPSite
Move-SPSite
New-SPSite
Remove-SPSite
Restore-SPSite
Set-SPSite


Get-SPSiteAdministration
See Also Example
[image]

Published: May 12, 2010

Returns a site administration object that allows farm administrators to view certain information about site collections to which they might not have access.

Get-SPSiteAdministration [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Filter <ScriptBlock>] [-Limit <String>] [-WebApplication <SPWebApplicationPipeBind>] [-WhatIf [<SwitchParameter>]]
Get-SPSiteAdministration [-Identity] <SPSiteAdministrationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Filter <ScriptBlock>] [-Limit <String>] [-Regex <SwitchParameter>] [-WhatIf [<SwitchParameter>]]
Get-SPSiteAdministration -ContentDatabase <SPContentDatabasePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Filter <ScriptBlock>] [-Limit <String>] [-WhatIf [<SwitchParameter>]]
Get-SPSiteAdministration -SiteSubscription <SPSiteSubscriptionPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Filter <ScriptBlock>] [-Limit <String>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Filter

Optional

System.Management.Automation.ScriptBlock

Specifies the script block of the server-side filter to apply.

The type must be a valid filter name and a value in the form { $_ PropertyName <operator > "filterValue"}}

Limit

Optional

System.String

Limits the maximum number of site collections to return. The default value is 200.

The type must be a valid non-negative number. Provide ALL to return all site collections for the given scope.

WebApplication

Optional

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the URL, GUID, or name of the Web application from which to list sites.

The type must be a valid URL, in the form http://server_name; a valid GUID (for example, 12345678-90ab-cdef-1234-567890bcdefgh); or the Web application name (for example, WebApplication1212).

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSiteAdministrationPipeBind

Specifies the URL (full or partial) or GUID of the site collection to retrieve.

The type must be a valid URL, in the form http://server_name, or a GUID, in the form 1234-456-987fg.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Filter

Optional

System.Management.Automation.ScriptBlock

Specifies the script block of the server-side filter to apply.

The type must be a valid filter name and a value in the form { $_ PropertyName <operator > "filterValue"}}

Limit

Optional

System.String

Limits the maximum number of site collections to return. The default value is 200.

The type must be a valid non-negative number. Provide ALL to return all site collections for the given scope.

Regex

Optional

System.Management.Automation.SwitchParameter

Enabling this switch causes the URL provided for the Identity parameter to be treated as a regular expression.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

3

Parameter

Required

Type

Description

ContentDatabase

Required

Microsoft.SharePoint.PowerShell.SPContentDatabasePipeBind

Specifies the URL (full or partial) or GUID of the site collection to retrieve.

The type must be a valid URL, in the form http://server_name, or a GUID, in the form, 1234-456-987fg.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Filter

Optional

System.Management.Automation.ScriptBlock

Specifies the script block of the server-side filter to apply.

The type must be a valid filter name and a value in the form { $_ PropertyName <operator > "filterValue"}}

Limit

Optional

System.String

Limits the maximum number of site collections to return. The default value is 200.

The type must be a valid non-negative number. Provide ALL to return all site collections for the given scope.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

4

Parameter

Required

Type

Description

SiteSubscription

Required

Microsoft.SharePoint.PowerShell.SPSiteSubscriptionPipeBind

Specifies the site group from which to get site collections.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; an SPSite (object or URL) of a site collection that is a member of the site subscription; or an instance of a valid SiteSubscription object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Filter

Optional

System.Management.Automation.ScriptBlock

Specifies the script block of the server-side filter to apply.

The type must be a valid filter name and a value in the form { $_ PropertyName <operator > "filterValue"}}

Limit

Optional

System.String

Limits the maximum number of site collections to return. The default value is 200.

The type must be a valid non-negative number. Provide ALL to return all site collections for the given scope.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Get-SPSiteAdminitration cmdlet returns a site administration object that allows farm administrators to view certain information about site collections to which they might not have access.

Input Types

Return Types

Example

------------------EXAMPLE 1------------------

Copy Code
Get-SPSiteAdministration | Select -Property Url, OwnerLoginName, @{Name="Storage";Expression={$_.Quota.StorageMaximumLevel}}

This example gets a subset of data from all of the sites in the content database with the URL b399a366-d899-4cff-8a9b-8c0594ee755f (farm administrator does not require access). This command uses the calculated property Storage to display the maximum storage value for the content database.

------------------EXAMPLE 2------------------

Copy Code
Start-SPAssignment -Global
$s = Get-SPSiteAdministration -Identity http://MyApp/Sites/Site1
$s.Url
Stop-SPAssignment -Global

This example gets the site collections specified by the Identity parameter and inserts the results into the variable s. This example uses the Global method of garbage collection. This method is easier to use but grows quickly. Do not run a Get-SPSite command that returns many results while global assignment is on.

------------------EXAMPLE 3------------------

Copy Code
$GC = Start-SPAssignment
$Sites = $GC | Get-SPSiteAdministration -Filter {$_.Owner -eq "DOMAIN\JDoe"} -Limit 50
Stop-SPAssignment $GC

This example gets the first 50 sites owned by user DOMAIN\JDoe by using a server-side query, and assigns the returned sites to a local variable. This command uses advanced assignment collection methods.

------------------EXAMPLE 4------------------

Copy Code
Get-SPWebApplication http://sitename | Get-SPSiteAdministration -Limit All |ForEach-Object {$sum=0}{ $sum+=$_.DiskUsed }{$sum}

This command returns the sum of the disk space usage for all sites in the specified Web application.

------------------EXAMPLE 5------------------

Copy Code
Get-SPWebApplication http://sitename | Get-SPSiteAdministration -Limit ALL | Select URL

This example gets the URLs for all site collections in a Web application.

------------------EXAMPLE 6------------------

Copy Code
Get-SPSiteAdministration -identity "http://localserver/(my|personal)/sites" -Regex

This example returns all sites that match the given regular expression. The quotation marks around the value specified for the Identity parameter are required when using the Regex flag.

------------------EXAMPLE 7------------------

Copy Code
Get-SPSite "http://sitename/sites/teams/*" -Limit 100

This example gets up to 100 of the sites under the URL http://sitename/sites/teams.

See Also

Reference

Set-SPSiteAdministration


Get-SPSiteSubscription
See Also Example
[image]

Published: May 12, 2010

Returns the site subscription for the given URL or all site subscriptions in the local farm.

Get-SPSiteSubscription [[-Identity] <SPSiteSubscriptionPipeBind>] [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPSiteSubscriptionPipeBind

Specifies the ID of the subscription.

The type must be a valid URL, in the form http://server_name.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPSiteSubscription cmdlet returns the site subscription for the given URL when the Identity parameter is used. If no parameter is specified, all unique site subscriptions in the farm are listed.

Input Types

Return Types

Example

------------------EXAMPLE----------------------

Copy Code
$SiteSub = Get-SPSiteSubscription http://Contoso.com
Copy Code
$SiteSub = Get-SPSite http://contoso.com | Get-SPSiteSubscription

This example retrieves the site subscription for http://Contoso.com.

See Also

Reference

New-SPSiteSubscription
Remove-SPSiteSubscription


Get-SPSiteSubscriptionConfig
Example
[image]

Published: May 12, 2010

Returns the configuration properties of a site subscription.

Get-SPSiteSubscriptionConfig [-Identity] <SPSiteSubscriptionPipeBind> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSiteSubscriptionPipeBind

Specifies the site subscription configuration to get.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; an SPSite (object or URL) of a site collection that is a member of the site subscription; or an instance of a valid SiteSubscription object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPSiteSubscriptionConfig cmdlet returns the configuration properties of a site subscription.

Input Types

Return Types

Example

---------------EXAMPLE---------------

Copy Code
Get-SPSiteSubscriptionConfig http://contoso.com | Select FeatureSet

This example gets the feature set ID for the site subscription that contains the Web site http://contoso.com.


Move-SPSite
See Also Example
[image]

Published: May 12, 2010

Moves site collections from one content database to another.

Move-SPSite [-Identity] <SPSitePipeBind> -DestinationDatabase <SPContentDatabasePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-RbsProviderMapping <Hashtable>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Specifies the identity of the site collection to be moved. For example, http://servername/sites/sitename.

DestinationDatabase

Required

Microsoft.SharePoint.PowerShell.SPContentDatabasePipeBind

Specifies the content database that the site collection should be moved to. For example, ContentDB2.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

RbsProviderMapping

Optional

System.Collections.Hashtable

Note:

This parameter was added in Microsoft SharePoint Server 2010 with Service Pack 1 (SP1) and Microsoft SharePoint Foundation 2010 with Service Pack 1 (SP1).

Used to move an RBS-enabled site collection from one RBS-enabled content database to another RBS-enabled content database without moving the underlying BLOB content. If the content database has more than one RBS provider associated with it, you must specify all providers. The same providers must be enabled on the target content database and the source content database.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Move-SPSite cmdlet moves the data in the specified site collection from its current content database to the content database specified by the DestinationDatabase parameter. A no-access lock is applied to the site collection to prevent users from altering data within the site collection while the move is taking place. Once the move is complete, the site collection is returned to its original lock state. The destination content database specified must already exist, must be attached to the same SQL Server as the site collection's current content database, and must be attached to the site collection's current Web application.

Input Types

Return Types

Example

---------------------EXAMPLE 1-----------------------

Copy Code
Move-SPSite http://servername/sites/sitename -DestinationDatabase ContentDb2

This example moves the site collection http://servername/sites/sitename to the content database ContentDb2.

---------------------EXAMPLE 2-----------------------

Copy Code
Get-SPSite -ContentDatabase ContentDb1 | Move-SPSite -DestinationDatabase ContentDb2

This example moves all site collections in ContentDb1 to ContentDb2.

---------------------EXAMPLE 3-----------------------

Copy Code
Get-SPSiteAdministration | where { $_.OwnerLoginName -eq "DOMAIN\username" } | Move-SPSite -DestinationDatabase ContentDb2

This example moves all site collections where DOMAIN\username is the site collection owner to ContentDb2. The Get-SPSiteAdministration cmdlet is used instead of the Get-SPSite cmdlet because you must have permission within the site collection to access the properties of the SPSite object. You can access the properties of the SPSiteAdministration object as a SharePoint farm administrator.

---------------------EXAMPLE 4-----------------------

Copy Code
Move-SPSite -Identity siteUrl -DestinationDatabase databaseName -RbsProviderMapping
       @{"sourceProvider1"="targetProvider1", "sourceProvider2"="targetProvider2"}

This example moves an RBS-enabled site collection from one RBS-enabled content database to another RBS-enabled content database, sourceProvider1 is the source RBS provider and targetProvider1 is the target RBS provider.

See Also

Reference

Backup-SPSite
Get-SPSite
Restore-SPSite
Get-SPSiteAdministration


Move-SPUser
See Also Example
[image]

Published: May 12, 2010

Migrates a user account in SharePoint 2010 Products.

Move-SPUser [-Identity] <SPUserPipeBind> -NewAlias <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-IgnoreSID <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPUserPipeBind

Specifies the GUID or login name of the user to be returned.

The type must be a valid login name or GUID of the user, in the form DOMAIN\username or 1234-5678-9876-0987.

NewAlias

Required

System.String

Specifies the new login name of the user account.

The type must be a valid login name, in the form DOMAIN\username.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

IgnoreSID

Optional

System.Management.Automation.SwitchParameter

Indicates (if present) that Active Directory will not be queried for the SID history attribute to ensure that the new login name is correspondent to the old login name.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Move-SPUser cmdlet migrates user access from one domain user account to another. If an entry for the new login name already exists, the entry is marked for deletion to make way for the migration.

Input Types

Return Types

Errors

Error | Description

Example

------------------EXAMPLE------------------

Copy Code
Move-SPUser -Identity "DOMAIN\JaneDoe" -NewAlias "Domain\JaneSmith"

This example migrates DOMAIN\JaneDoe to the new account of DOMAIN\JaneSmith.

See Also

Reference

New-SPUser
Set-SPUser
Remove-SPUser
Get-SPUser


New-SPSite
See Also Example
[image]

Published: May 12, 2010

Creates a new site collection at the specified URL.

New-SPSite [-Url] <String> -OwnerAlias <SPUserPipeBind> [-AdministrationSiteType <None | TenantAdministration>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-ContentDatabase <SPContentDatabasePipeBind>] [-Description <String>] [-HostHeaderWebApplication <SPWebApplicationPipeBind>] [-Language <UInt32>] [-Name <String>] [-OwnerEmail <String>] [-QuotaTemplate <SPQuotaTemplatePipeBind>] [-SecondaryEmail <String>] [-SecondaryOwnerAlias <SPUserPipeBind>] [-SiteSubscription <SPSiteSubscriptionPipeBind>] [-Template <SPWebTemplatePipeBind>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Url

Required

System.String

Specifies the URL that the new site collection uses. If the URL is not a host header site, the URL must start with the the Web application URL.

OwnerAlias

Required

System.String

Specifies the user login name of the site owner.

The type must be a valid user alias, in the form Domain\username.

AdministrationSiteType

Optional

Microsoft.SharePoint.SPAdministrationSiteType

Specifies the site type.

Valid values are None or TentantAdministration.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

ContentDatabase

Optional

Microsoft.SharePoint.PowerShell.SPContentDatabasePipeBind

Specifies the name or GUID of the content database in which to create the new site. If no content database is specified, the site collection is selected automatically.

The type must be a valid database name, in the form SiteContent1212, or a GUID, in the form 1234-5678-9807.

Description

Optional

System.String

Describes the new site. If no value is specified, the value is left blank.

HostHeaderWebApplication

Optional

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies that if the URL provided is a host header, the HostHeaderWebApplication parameter must be the name, URL, GUID, or SPWebApplication object for the Web application in which this site collection is created. If no value is specified, the value is left blank.

The type must be a valid name, in the form WebApplication-1212; a URL (for example, http://server_name); or a GUID (for example, 1234-5678-9876-0987).

Language

Optional

System.Int32

Specifies the language ID for the new site collection. If no language is specified, the site collection is created with the same language that was specified when the product was installed.

This must be a valid language identifier (LCID).

Name

Optional

System.String

Specifies the title of the new site collection. If no name is specified, the default name is applied.

OwnerEmail

Optional

System.String

Specifies the e-mail address of site owner. If no value is specified, the value is left blank.

The type must be a valid e-mail address in the form, someone@example.com.

QuotaTemplate

Optional

Microsoft.SharePoint.PowerShell.SPQuotaTemplatePipeBind

Specifies the quota template for the new site. The template must exist already. If no template is specified, no quota is applied.

SecondaryEmail

Optional

System.String

Specifies the e-mail address of the secondary site owner. If no value is specified, the value is left blank.

The type must be a valid e-mail address, in the form someone@example.com.

SecondaryOwnerAlias

Optional

System.String

Specifies the user login credentials of the secondary site owner. If no value is specified, the value is left blank.

The type must be a valid user alias, in the form Domain\username.

SiteSubscription

Optional

Microsoft.SharePoint.PowerShell.SPSiteSubscriptionPipeBind

Specifies the Site Group to get site collections.

Template

Optional

Microsoft.SharePoint.PowerShell.SPWebTemplatePipeBind

Specifies the Web template for the root Web of the new site collection. The template must be already installed. If no template is specified, no template is provisioned.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The New-SPSite cmdlet creates a new site collection by using the URL and owner specified by the Url and OwnerAlias parameters.

Input Types

Return Types

Example

------------------EXAMPLE 1-----------------------

Copy Code
New-SPSite http://sitename/sites/test -OwnerAlias "DOMAIN\JDoe" -Language 1033

This example creates an English site collection at http://sitename/sites/test that is owned by user DOMAIN\Jdoe.

------------------EXAMPLE 2-----------------------

Copy Code
$w = Get-SPWebApplication http://sitename
Copy Code
New-SPSite http://www.contoso.com -OwnerAlias "DOMAIN\jdoe" -HostHeaderWebApplication $w -Name "Contoso" -Template "STS#0"

This example creates a host header site collection. Because the template is provided, the root Web of this site collection will be created.

------------------EXAMPLE 3-----------------------

Copy Code
Get-SPWebTemplate | Where{ $_.Title -eq "Team Site" } | ForEach-Object{ New-SPSite http://sitename/sites/test -OwnerAlias DOMAIN\jdoe -Template $_ }

This example creates a site collection by using the "Team Site" Web template.

See Also

Reference

Get-SPSite
Set-SPSite
Backup-SPSite
Move-SPSite
Restore-SPSite


New-SPSiteSubscription
See Also Example
[image]

Published: May 12, 2010

Creates a new site subscription.

New-SPSiteSubscription [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The New-SPSiteSubscription cmdlet creates a new subscription to which the SPSites object can belong. Sites that are members of a site subscription can share settings and configuration information. A site collection can be a member of only one site subscription and, once set, cannot be changed.

Site subscriptions are not persisted in a database until used in conjunction with either an SPSite or the Site Subscription Settings Service. After a site subscription is applied to any site collection in the farm, the site subscription can be retrieved by using the Get-SPSiteSubscription cmdlet.

Input Types

Return Types

Example

------------------EXAMPLE 1-----------------------

Copy Code
New-SPSiteSubscription |%{ New-SPSite http://contoso.com/sites/admin -SiteSubscription $_ -Template "TenantAdmin#0"}
Copy Code

This example creates a new site subscription and applies it to a new Tenant Administration site collection.
------------------EXAMPLE 2-----------------------
    Copy Code
$s = New-SPSiteSubscription

    Copy Code
Get-SPSite http://sitename | Set-SPSite -SiteSubscription $s

    Copy Code
Set-SPSite http://sitename -SiteSubscription {New-SPSiteSubscription}

This example adds a new subscription to an existing site collection at http://sitename.
  See Also
Reference
Get-SPSiteSubscription
Remove-SPSiteSubscription


New-SPUser
See Also Example
[image]

Published: May 12, 2010

Adds an existing user to a SharePoint site with the designated permissions.

New-SPUser [-UserAlias] <String> -Web <SPWebPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DisplayName <String>] [-Email <String>] [-Group <SPGroupPipeBind>] [-MobileNumber <String>] [-PermissionLevel <String[]>] [-SiteCollectionAdmin <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

UserAlias

Required

System.String

Web

Required

Microsoft.SharePoint.PowerShell.SPWebPipeBind

Specifies the URL or GUID of the Web on which to create this user.

The type must be a valid URL, in the form http://server_name, or a GUID, in the form 1234-5678-9876-0987.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DisplayName

Optional

System.String

Specifies a string that contains the display name of the user.

The type must be a valid user name; for example, Joe.

Email

Optional

System.String

Specifies the e-mail address of the new user.

The type must be a valid e-mail address, in the form someone@example.com.

Group

Optional

Microsoft.SharePoint.PowerShell.SPGroupPipeBind

Specifies the user group to which the new user belongs.

MobileNumber

Optional

System.String

Specifies the user e-mail address of the new user.

The type must be a valid e-mail address, in the form someone@example.com.

PermissionLevel

Optional

System.String[]

Adds a user to a permission level.

The type must be a valid permission level for the Web application; for example, Full Control, Read, Contribute, or All.

SiteCollectionAdmin

Optional

System.Management.Automation.SwitchParameter

Specifies whether to add the user as an administrator to the site collection.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The New-SPUser cmdlet adds an existing user to a SharePoint Web site with the designated permissions. This user has the given permissions in all subsites that inherit permissions. The user account must already exist in the user directory.

If your environment is in Active Directory mode, the user must already exist in Active Directory Domain Services (AD DS) and only the UserAlias parameter is required; all other fields are pulled from AD DS. If only an alias is given and the farm is in Active Directory Account Create mode, the Email parameter is also required.

Input Types

Return Types

Example

------------------EXAMPLE 1----------------------

Copy Code
PS> New-SPUser - UserAlias 'Contoso\Jdoe'-displayname 'John Doe' -web http://contoso.com

This example adds a new user named John Doe to the Contoso domain.

------------------EXAMPLE 2----------------------

Copy Code
Get-SPWeb http://sitename | New-SPUser -UserAlias Contoso\Jdoe

This example adds Contoso\Jdoe to all Webs in the http://sitename site collection. Because this site collection uses inherited permissions, only the top-level Web site needs to be touched.

See Also

Reference

Get-SPUser
Set-SPUser
Move-SPUser
Remove-SPUser


New-SPWeb
See Also Example
[image]

Published: May 12, 2010

Creates a new site in an existing site collection.

New-SPWeb [-Url] <String> [-AddToQuickLaunch <SwitchParameter>] [-AddToTopNav <SwitchParameter>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Description <String>] [-Language <UInt32>] [-Name <String>] [-Template <SPWebTemplatePipeBind>] [-UniquePermissions <SwitchParameter>] [-UseParentTopNav <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Url

Required

System.String

Specifies the URL where the new site is to be created. The URL must be inside an existing site collection. The URL must be a valid URL, in the form http://server_name/site1.

Language

Optional

System.UInt32

Specifies the language template identifier for the new site. If no language is specified, the site is created with the same language that was specified when the product was installed.

The type must be a valid language identifier (LCID).

Template

Optional

SPWebTemplatePipeBind

Specifies the Web template for the new site. The template must already exist. If no template is specified, no template is applied and a template can be selected later.

Name

Optional

System.String

Specifies the title of the new site. If no title is specified, the default title is applied. The default title is configured for each template.

Description

Optional

System.String

Describes the new site. If no description is specified, the entry is left blank.

AddToQuickLaunch

Optional

System.Management.Automation.SwitchParameter

Adds this site to the Quick Launch.

UniquePermissions

Optional

System.Management.Automation.SwitchParameter

Specifies that this site is to be created with unique permissions.

AddToTopNav

Optional

System.Management.Automation.SwitchParameter

Adds this site to the top-level navigation bar.

UseParentTopNav

Optional

System.Management.Automation.SwitchParameter

Specifies that the same top-level navigation bar as the parent site is to be used for this site.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The New-SPWeb cmdlet creates a new site in the existing site collection specified by the Url parameter. You can create a site with a specific default language by specifying the Language parameter. If no language is specified, the site is created with the same language that was specified when the product was installed. You can create a site from a specific template by specifying the Template parameter. If no template is specified, the site is created and the template can be provided later or by the first user to log on.

Input Types

none

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
New-SPWeb http://somesite/subweb1 -Template "STS#0"

This example creates a new subsite by using the Team Site template at the provided URL (http://somesite/subweb1). The Team Site template is a value referenced as the variable STS#0 for the Template parameter.

See Also

Reference

Get-SPWeb
Set-SPWeb
Remove-SPWeb
Import-SPWeb


New-SPWebApplication
See Also Example
[image]

Published: May 12, 2010

Creates a new Web application within the local farm.

New-SPWebApplication -ApplicationPool <String> -Name <String> [-AdditionalClaimProvider <SPClaimProviderPipeBind[]>] [-AllowAnonymousAccess <SwitchParameter>] [-ApplicationPoolAccount <SPProcessAccountPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-AuthenticationMethod <String>] [-AuthenticationProvider <SPAuthenticationProviderPipeBind[]>] [-Confirm [<SwitchParameter>]] [-DatabaseCredentials <PSCredential>] [-DatabaseName <String>] [-DatabaseServer <String>] [-HostHeader <String>] [-Path <String>] [-Port <UInt32>] [-SecureSocketsLayer <SwitchParameter>] [-ServiceApplicationProxyGroup <SPServiceApplicationProxyGroupPipeBind>] [-SignInRedirectProvider <SPTrustedIdentityTokenIssuerPipeBind>] [-SignInRedirectURL <String>] [-Url <String>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

ApplicationPool

Required

System.String

Specifies the name of an application pool to use; for example, SharePoint - 1213. If an application pool with the name provided does not exist, the ApplicationPoolAccount parameter must be provided and a new application pool will be created. If no value is specified, the default application pool will be used.

Name

Required

System.String

Specifies the name of the new Web application.

AdditionalClaimProvider

Optional

Microsoft.SharePoint.PowerShell.SPClaimProviderPipeBind[]

Adds a specific claim provider to the defined Web application.

AllowAnonymousAccess

Optional

System.Management.Automation.SwitchParameter

Allows anonymous access to the Web application.

ApplicationPoolAccount

Optional

Microsoft.SharePoint.PowerShell.SPProcessAccountPipeBind

Specifies the user account that this application pool will run as. Use the Get-SPIisWebServicApplicationPool cmdlet to use a system account.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

AuthenticationMethod

Optional

System.String

Uses Kerberos or NTLM to specify the authentication method. If no value is specified, the default NTLM is applied.

AuthenticationProvider

Optional

Microsoft.SharePoint.PowerShell.SPAuthenticationProviderPipeBind[]

Specifies the authentication provider or providers that apply to a Web application.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DatabaseCredentials

Optional

System.Management.Automation.PSCredential

Specifies the Windows PowerShell Credential object for the database user account.

DatabaseName

Optional

System.String

Specifies the name of the initial content database for the new Web application.

The type must be a valid database name; for example, ContentDB1. If no value is specified, a value in the format WSS_Content_<GUID> is auto-generated.

DatabaseServer

Optional

System.String

Specifies the database server name. The type must be a valid database server name, in the form SQL1; where named instances are used, the format can appear as server\server. The default SQL server instance is used if a value is not provided.

HostHeader

Optional

System.String

Specifies a valid URL assigned to the Web application that must correlate to the alternate access mapping configuration, in the form server_name.

When the HostHeader parameter is present, the value of this field is the internal URL for the Web application. The Url parameter is used to specify the public URL.If no value is specified, the value is left blank.

Path

Optional

System.String

Specifies the physical directory for the new Web application in the virtual directories folder. The type is a valid path, in the form C:\Inutepub\wwwroot\MyWebApplication. If no value is specified, the value %wwwroot%\wss\VirtualDirectories\<portnumber> is applied.

Port

Optional

System.UInt32

Specifies the port on which this Web application can be accessed. This can be any valid port number. If no port is specified, a nonconflicting port number is automatically generated.

Important:

If you specify a port number that has already been assigned, IIS does not start the new site until you change either the port number of the new site or the port number of the old site.

SecureSocketsLayer

Optional

System.Management.Automation.SwitchParameter

Enables Secure Sockets Layer (SSL) encryption for this Web application. If you choose to use SSL, you must add the certificate on each server by using the IIS administration tools. Until this is done, the Web application will be inaccessible from this IIS Web site.

ServiceApplicationProxyGroup

Optional

Microsoft.SharePoint.PowerShell.SPServiceApplicationProxyGroupPipeBind

Specifies a custom service application proxy group for the Web application to use. The Web application will use the proxies in this proxy group to connect to service applications. If this parameter is not specified, the default proxy group for the farm is used.

SignInRedirectProvider

Optional

Microsoft.SharePoint.PowerShell.SPTrustedIdentityTokenIssuerPipeBind

Sets the sign-in redirect URL to point to the URL that is defined in the specified authentication provider.

SignInRedirectURL

Optional

System.String

Specifies the sign-in redirect URL for the Web application.

Url

Optional

System.String

Specifies the load-balanced URL for the Web application.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

Creates a new Web application specified by the Name parameter. The user specified by the DatabaseCredentials parameter must be a member of the dbcreator fixed server role on the database server.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
New-SPWebApplication -Name "Contoso Internet Site" -Port 80 -HostHeader sharepoint.contoso.com -URL "https://www.contoso.com" -ApplicationPool "ContosoAppPool" -ApplicationPoolAccount (Get-SPManagedAccount "DOMAIN\jdoe")

This example creates a new Web application by using an internal host header of sharepoint.contoso.com and a public URL of https://www.contoso.com.

See Also

Reference

Get-SPWebApplication
Set-SPWebApplication
Get-SPWebApplication


New-SPWebApplicationExtension
See Also Example
[image]

Published: May 12, 2010

Creates a new zone instance for the Web application.

New-SPWebApplicationExtension [-Identity] <SPWebApplicationPipeBind> -Name <String> -Zone <Default | Intranet | Internet | Custom | Extranet> [-AdditionalClaimProvider <SPClaimProviderPipeBind[]>] [-AllowAnonymousAccess <SwitchParameter>] [-AssignmentCollection <SPAssignmentCollection>] [-AuthenticationMethod <String>] [-AuthenticationProvider <SPAuthenticationProviderPipeBind[]>] [-Confirm [<SwitchParameter>]] [-HostHeader <String>] [-Path <String>] [-Port <UInt32>] [-SecureSocketsLayer <SwitchParameter>] [-SignInRedirectProvider <SPTrustedIdentityTokenIssuerPipeBind>] [-SignInRedirectURL <String>] [-Url <String>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the Web application to extend.

Name

Required

System.String

Specifies the name of the new IIS Web site in the Web application.

Zone

Required

System.String

Specifies one of the five zones with which the internal URL of this new extension is to be associated. This zone cannot already be in use..

The type must be any one of the following values: Default, Intranet, Internet, Extranet, or Custom

AdditionalClaimProvider

Optional

Microsoft.SharePoint.PowerShell.SPClaimProviderPipeBind[]

Adds a specific claim provider to the defined Web application.

AllowAnonymousAccess

Optional

System.Management.Automation.SwitchParameter

Allows anonymous access to the Web application zone.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

AuthenticationMethod

Optional

String

Uses Kerberos or NTLM to specify the authentication method.

AuthenticationProvider

Optional

Microsoft.SharePoint.PowerShell.SPAuthenticationProviderPipeBind[]

Specifies the authentication provider(s) that applies to a Web apllication.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

HostHeader

Optional

System.String

Specifies a valid URL assigned to the Web application by that must correlate to the alternate access mapping configuration, in the form http://server_name.

When the HostHeader parameter is present, the value of this field is the internal URL for the Web application. The Url parameter is used to specify the public URL.

Path

Optional

System.String

Specifies the physical directory for the new Web site (in the virtual directories folder). The type is a valid path, in the form C:\Inetpub\wwwroot\MyWebApplication.

Port

Optional

System.UInt32

Specifies the application port. Can be any valid port number.

If no port is specified, a nonconflicting port number is automatically generated.

Important:

If you specify a port number that is already assigned, IIS does not start the new site until you change either the port number of the new site or the port number of the old site.

SecureSocketsLayer

Optional

System.Management.Automation.SwitchParameter

Enables Secure Sockets Layer (SSL) encryption for this Web application. If you use SSL, you must add the certificate on each server by using the IIS administration tools. Until this is done, the Web application is inaccessible from this IIS Web site.

SignInRedirectProvider

Optional

Microsoft.SharePoint.PowerShell.SPTrustedIdentityTokenIssuerPipeBind

Sets the sign-in redirect URL to point to the URL that is defined in the specified authentication provider.

SignInRedirectURL

Optional

System.String

Specifies the sign-in redirect URL for the Web application.

Url

Optional

System.String

Specifies the load-balanced URL for the Web application zone.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The New-SPWebApplicationExtension cmdlet creates a new zone instance for the Web application. This is also known as extending a Web application and allows alternate permissions to be configured for the same content that is available in the existing Web application.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Get-SPWebApplication http://sitename | New-SPWebApplicationExtension -Name "ExtranetSite" -SecureSocketsLayer -Zone "Extranet" -URL "https://extranet.sitename.com"

This example extends the given Web application at http://sitename to the Extranet zone for SSL use.

See Also

Reference

Get-SPWebApplication
Set-SPWebApplication


Remove-SPSite
See Also Example
[image]

Published: May 12, 2010

Completely deletes an existing site collection and all subsites.

Remove-SPSite [-Identity] <SPSitePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DeleteADAccounts <SwitchParameter>] [-GradualDelete <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Specifies the identity of the site to delete. The identity can be either a valid URL, in the form http://server_name; a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or an SPSite object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DeleteADAccounts

Optional

System.Management.Automation.SwitchParameter

Forces deletion of user accounts from Active Directory Domain Services (AD DS). This applies when in AD DS account creation mode and the value of this parameter is True, AD DS accounts associated with the site collection are also deleted from AD DS.

GradualDelete

Optional

System.Management.Automation.SwitchParameter

If provided, occurs gradually to use less system load. This operation is strongly recommended for deleting very large sites.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPSite cmdlet completely deletes an existing site collection and all subsites. This operation cannot be undone.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Remove-SPSite -Identity "http://sitename" -GradualDelete -Confirm:$False

This example removes the given site collection and all included sites by using GradualDelete; confirmation has been suppressed.

See Also

Reference

Get-SPSite
Set-SPSite
New-SPSite
Backup-SPSite
Remove-SPSite
Move-SPSite
Restore-SPSite


Remove-SPSiteSubscription
See Also Example
[image]

Published: May 12, 2010

Removes data stored in a subscription settings service application for a set of site subscriptions.

Remove-SPSiteSubscription [-Identity] <SPSiteSubscriptionPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Specifies the name of the site subscription to remove.

Specifies the site subscription settings service application that contains the service data to delete.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a subscription settings service application (for example, SubscriptionSettingsApp1); or an instance of a valid SPSubscriptionSettingsServiceApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Forces the removal of a site subscription and is the only way to stop this command from prompting for confirmation.

The type must be either of the following values:

- True

- False

The default value is False.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPSiteSubscription cmdlet removes a site subscription along with all contained site collections and settings.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Remove-SPSiteSubscription "http://contoso.com"

This example removes all data for the contoso.com site subscription (site collections, site subscription, and settings).

See Also

Reference

Get-SPSiteSubscription
New-SPSiteSubscription
Remove-SPSiteSubscription


Remove-SPSiteSubscriptionSettings
See Also Example
[image]

Published: May 12, 2010

Removes the settings service data for a specified site subscription, or finds and removes orphaned data.

Remove-SPSiteSubscriptionSettings [-Identity] <SPServiceApplicationPipeBind> -SiteSubscriptions <Guid[]> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]
Remove-SPSiteSubscriptionSettings [-Identity] <SPServiceApplicationPipeBind> -FindAllOrphans <SwitchParameter> [-AlternativeSiteSubscriptions <Guid[]>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationPipeBind

Specifies the site subscription settings service application that contains the service data to delete.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a subscription settings service application (for example, SubscriptionSettingsApp1); or an instance of a valid SPSubscriptionSettingsServiceApplication object.

SiteSubscriptions

Required

System.Guid[]

Specifies the site subscriptions with the settings service data to delete.

The type must be an array of valid GUIDs.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationPipeBind

Specifies the site subscription settings service application that contains the service data to delete.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a subscription settings service application (for example, SubscriptionSettingsApp1); or an instance of a valid SPSubscriptionSettingsServiceApplication object.

FindAllOrphans

Required

System.Management.Automation.SwitchParameter

Specifies that orphaned settings stores in the service application are deleted.

AlternativeSiteSubscriptions

Optional

System.Guid[]

Specifies the complete collection or comma-separated list of site subscriptions that should exist in the settings service application. Any data not matching the items in this list will be removed.

This parameter is important when the FindAllOrphans parameter is used. The value specified for AlternativeSiteSubscriptions parameter is stating that any site subscriptions not on the local farm will be deleted, unless an alternate list of site subscriptions is given.

The type must be an array of valid GUIDs.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Automatically bypasses the secondary warning provided by the cmdlet prior to the operation.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Remove-SPSiteSubscriptionSettings cmdlet deletes site subscription stored data for the specified site subscription. If the FindAllOrphans parameter is specified, this cmdlet locates any data in the service application that does not exist in the list of local site subscriptions or the alternate list of subscriptions.

The set of site subscriptions can be specified directly, or discovered by comparing data in the service application to the set of existing site subscriptions which finds the data set that corresponds to nonexistent site subscriptions.

Important:

If this cmdlet is run on a federated service application without specifying the complete list of site subscription IDs for the AlternativeSiteSubscriptions parameter, data loss can result.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

------------EXAMPLE 1--------------

Copy Code
Remove-SPSiteSubscriptionSettings -FindAllOrphans -Whatif

This example finds all orphans and displays them on the screen. Remove the WhatIf parameter to remove these extra settings.

------------EXAMPLE 2--------------

Copy Code
Remove-SPSubscriptionSettingsServiceApplication -FindAllOrphans -AlternativeSiteSubscriptions $SubscriptionList

Use this example if the service application is consumed by a remote farm and you want the clean orphaned site subscription settings data (an array of all site subscriptions whose data must remain in the service application is assigned to the $SubscriptionList variable.

See Also

Reference

Import-SPSiteSubscriptionSettings
Export-SPSiteSubscriptionSettings


Remove-SPUser
See Also Example
[image]

Published: May 12, 2010

Removes a user from a Web site.

Remove-SPUser [-Identity] <SPUserPipeBind> -Web <SPWebPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Group <SPGroupPipeBind>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPUserPipeBind

Specifies the GUID, the user name, or SPUser object to remove.

The type must be a valid GUID of the user, in the form 1234-5678-9876-0987.

Web

Required

Microsoft.SharePoint.PowerShell.SPWebPipeBind

Specifies the name of the URL or GUID from which the user is to be removed. This parameter is needed only if the identity provided is the user name.

The type must be a valid URL, in the form http://server_name, or a GUID, in the form 1234-5678-9807.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Group

Optional

Microsoft.SharePoint.PowerShell.SPGroupPipeBind

The user only gets removed from that group. Otherwise, the user gets removed from the site.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPUser cmdlet specifies the identity and user group from which a user is to be removed. The Remove-SPUser cmdlet does not remove the user from Active Directory Domain Services (AD DS).

Input Types

Return Types

Example

------------------EXAMPLE 1-----------------------

Copy Code
Remove-SPUser "Contoso \jdoe" -web http://test/web1
Copy Code
Get-SPWeb "http://test/web1" | Remove-SPUser "Contoso\jdoe"

This example removes the user (Contoso\jdoe) from the Web application http://test/web1.

------------------EXAMPLE 2-----------------------

Copy Code
Get-SPSite http://contoso.com |Get-SPWeb |Remove-SPUser "Contoso\jdoe"

This syntax removes the user (Contoso\Jdoe) from every Web in a site collection located at http://contoso.com.

See Also

Reference

Get-SPUser
Set-SPUser
New-SPUser
Remove-SPUser


Remove-SPWeb
See Also Example
[image]

Published: May 12, 2010

Completely deletes the specified Web.

Remove-SPWeb [-Identity] <SPWebPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Recycle <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPWebPipeBind

Specifies the identity of the Web to delete.

The type must be a valid full URL, in the form http://server_name/site_name, or an SPWeb object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPWeb cmdlet completely deletes the Web specified by the Identity parameter.

Important:

Deleting the top level Web site of a site collection causes the entire site collection to be removed.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Remove-SPWeb http://sitename/subsite

This example completely deletes a subsite.

See Also

Reference

Get-SPWeb
Set-SPWeb
Remove-SPWeb
New-SPWeb
Import-SPWeb


Remove-SPWebApplication
See Also Example
[image]

Published: May 12, 2010

Deletes the specified Web application.

Remove-SPWebApplication [-Identity] <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DeleteIISSite <SwitchParameter>] [-RemoveContentDatabases <SwitchParameter>] [-WhatIf [<SwitchParameter>]]
Remove-SPWebApplication [-Identity] <SPWebApplicationPipeBind> -Zone <Default | Intranet | Internet | Custom | Extranet> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DeleteIISSite <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the URL or name of the Web application to delete.

The type must be a valid URL, in the form http://server_name, or a valid name, in the form WebApplication-1212.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DeleteIISSite

Optional

System.Management.Automation.SwitchParameter

Deletes the associated IIS Web sites. If this parameter is not provided, the IIS site is not removed.

RemoveContentDatabases

Optional

System.Management.Automation.SwitchParameter

Permanently deletes all associated content databases. If this parameter is not provided, no content databases are removed.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the URL or name of the Web application to delete.

The type must be a valid URL, in the form http://server_name, or a valid name, in the form WebApplication-1212.

Zone

Required

System.String

Specifies one of the five zones to be removed. If this parameter is not provided, all Web application zones are removed.

The type must be any one of the following values: Default, Intranet, Internet, Extranet, or Custom.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DeleteIISSite

Optional

System.Management.Automation.SwitchParameter

Deletes the associated IIS Web sites. If this parameter is not provided, the IIS site is not removed.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Remove-SPWebApplication cmdlet deletes the Web application specified by the Identity and Zone parameters. If no zone is provided, the entire Web application and all zones are removed.

Input Types

Return Types

Example

------------------EXAMPLE 1-----------------------

Copy Code
Get-SPWebApplication http://sitename | Remove-SPWebApplication -Zone "Internet" -Confirm

This example prompts and then removes the Internet zone Web application extension on the Web application at http://sitename. This command does not remove the content databases or the IIS Web site.

------------------EXAMPLE 2-----------------------

Copy Code
Remove-SPWebApplication http://sitename -Confirm -DeleteIISSite -RemoveContentDatabases

This example permanently removes the Web application, all content databases, and the IIS Web site at http://sitename

See Also

Reference

Get-SPWebApplication
Set-SPWebApplication
New-SPWebApplication


Rename-SPServer
See Also Example
[image]

Published: May 12, 2010

Renames a server that is currently connected to the farm.

Rename-SPServer [-Identity] <SPServerPipeBind> -Name <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServerPipeBind

Specifies the original name of the server.

The type must be a URL, in the form http://server_name, or a GUID, in the form 1234-4567-987gb.

Name

Required

System.String

Specifies the new name of the server.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Rename-SPServer cmdlet changes the name of the server for internal use within SharePoint 2010 Products. The server itself must be manually renamed.

Input Types

Return Types

Example

------------------EXAMPLE------------------

Copy Code
Rename-SPServer -Identity "wfb1" -Name "WFE1"

This example changes the name of the SharePoint server wfb1 to WFE1.

See Also

Reference

Get-SPServer


Set-SPSite
See Also Example
[image]

Published: May 12, 2010

Configures the specified sites.

Set-SPSite [-Identity] <SPSitePipeBind> [-AdministrationSiteType <None | TenantAdministration>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-LockState <String>] [-MaxSize <Int64>] [-OwnerAlias <SPUserPipeBind>] [-QuotaTemplate <SPQuotaTemplatePipeBind>] [-SecondaryOwnerAlias <SPUserPipeBind>] [-Template <SPWebTemplatePipeBind>] [-Url <String>] [-UserAccountDirectoryPath <String>] [-WarningSize <Int64>] [-WhatIf [<SwitchParameter>]]
Set-SPSite [-Identity] <SPSitePipeBind> [-AdministrationSiteType <None | TenantAdministration>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-SiteSubscription <SPSiteSubscriptionPipeBind>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Specifies the URL or GUID of the site collection to configure, or refers to an SPSite object that contains sites to configure.

The type must be a valid URL, in the form http://server_name; a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or an SPSite object.

AdministrationSiteType

Optional

Microsoft.SharePoint.SPAdministrationSiteType

Specifies the site type.

Valid values are None or TentantAdministration.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

LockState

Optional

System.String

Sets the lock state of this site collection. The valid lock states are

Unlock Unlocks the site collection and makes it available to users

NoAdditions Prevents users from adding new content to the site collection. Updates and deletions are still allowed

ReadOnly Prevents users from adding, updating, or deleting content.

NoAccess Prevents access to content completely. Users who attempt to access the site receive an access-denied message.

MaxSize

Optional

System.Int32

Sets the maximum storage size for the site collection in megabytes.

The integer value must be larger than the WarningSize value. You cannot use this parameter if the site collection is using a quota template.

OwnerAlias

Optional

System.String

Specifies the alias name of the site collection administrator.

The type must be a valid e-mail alias, in the form domain\username.

QuotaTemplate

Optional

Microsoft.SharePoint.PowerShell.SPQuotaTemplatePipeBind

Specifies the new quota template for this site collection.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890abcdef or a string

SecondaryOwnerAlias

Optional

System.String

Sets the alias of the secondary site collection administrator.

The type must be a valid e-mail alias, in the form domain\username.

Template

Optional

Microsoft.SharePoint.PowerShell.SPWebTemplatePipeBind

Specifies the template for this site collection.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890abcdef.

Url

Optional

System.String

Specifies the URL of the new site.

UserAccountDirectoryPath

Optional

String

Sets an organization unit to which to scope user accounts.

WarningSize

Optional

System.Int32

Sets the storage warning level for the site collection.

The integer value must be between 0 and the MaxSize value. You cannot use this parameter if the site collection is using a quota template.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Specifies the URL or GUID of the site collection to configure, or refers to an SPSite object that contains sites to configure.

The type must be a valid URL, in the form http://server_name; a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or an SPSite object.

AdministrationSiteType

Optional

Microsoft.SharePoint.SPAdministrationSiteType

Specifies the site type.

Valid values are None or TentantAdministration.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Suppresses confirmation messages involved in setting the site subscription. This parameter is used in conjunction with the SiteSubscription parameter.

SiteSubscription

Optional

Microsoft.SharePoint.PowerShell.SPSiteSubscriptionPipeBind

Specifies the Site Group to get site collections.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Set-SPSite cmdlet configures the site collection that is specified by the Identity parameter. If a parameter is not used, the value is not changed.

Note:

The QuotaTemplate parameter is mutually exclusive to the MaxSize parameter and WarningSize parameter.

Input Types

Return Types

Example

------------------EXAMPLE 1---------------------

Copy Code
Get-SPSite http://sitename/sites/teams/* | Set-SPSite -SecondaryOwner "DOMAIN\Jdoe"

This example sets the secondary owner on a set of site collections to DOMAIN\Jdoe.

------------------EXAMPLE 2---------------------

Copy Code
Set-SPSite -identity "http://sitename" -MaxSize 4000000 -WarningSize 2000000

This example configures the Quota settings for the site collection http://sitename.

See Also

Reference

Get-SPSite
New-SPSite
Restore-SPSite
Remove-SPSite
Move-SPSite
Restore-SPSite


Set-SPSiteAdministration
See Also Example
[image]

Published: May 12, 2010

Allows farm administrators to configure any site collection.

Set-SPSiteAdministration [-Identity] <SPSiteAdministrationPipeBind> [-AdministrationSiteType <None | TenantAdministration>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-LockState <String>] [-MaxSize <Int64>] [-OwnerAlias <SPUserPipeBind>] [-SecondaryOwnerAlias <SPUserPipeBind>] [-Template <SPWebTemplatePipeBind>] [-WarningSize <Int64>] [-WhatIf [<SwitchParameter>]]
Set-SPSiteAdministration [-Identity] <SPSiteAdministrationPipeBind> [-AdministrationSiteType <None | TenantAdministration>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-SiteSubscription <SPSiteSubscriptionPipeBind>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSiteAdministrationPipeBind

Specifies the URL (full or partial) or GUID of the site collection.

The type must be a valid URL, in the form http://server_name, or a GUID, in the form 1234-456-987fg.

AdministrationSiteType

Optional

Microsoft.SharePoint.SPAdministrationSiteType

Specifies the site type.

Valid values are None or TentantAdministration.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

LockState

Optional

System.String

Specifies the lock state for the given site collection.

The type must be any of the following values:

- Unlock: Sets the site collection to unlock.

- Content: No new content can be added. Updates and deletions are allowed.

- Readonly: Sets the site collection to read-only.

- Noaccess: Sets the site collection to unavailable to all users.

MaxSize

Optional

System.Int32

Sets the maximum storage size of the site collection.

The type must be a valid number greater than or equal to 0. .

Set to 0 for unlimited.

OwnerAlias

Optional

System.String

Sets the owner of this site collection.

The type must be a valid user alias.

SecondaryOwnerAlias

Optional

System.String

Sets the secondary owner of this site collection.

The type must be a valid user alias.

Template

Optional

Microsoft.SharePoint.PowerShell.SPWebTemplatePipeBind

Specifies the Web template for the top-level Web site of this site collection. This can only be given if the template has not already been configured.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890abcdef, or an SPWebTemplate object.

WarningSize

Optional

System.Int64

Specifies the site collection warning size limit.

The type must be a valid number greater than or equal to 0. Set to 0 for unlimited.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSiteAdministrationPipeBind

Specifies the URL (full or partial) or GUID of the site collection.

The type must be a valid URL, in the form http://server_name, or a GUID, in the form 1234-456-987fg.

AdministrationSiteType

Optional

Microsoft.SharePoint.SPAdministrationSiteType

Specifies the site type.

Valid values are None or TentantAdministration.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

Optional

System.Management.Automation.SwitchParameter

Suppresses confirmation messages involved in setting the site subscription. This parameter is used in conjunction with the SiteSubscription parameter.

SiteSubscription

Optional

Microsoft.SharePoint.PowerShell.SPSiteSubscriptionPipeBind

Specifies the Site Group to get site collections.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Set-SPSiteAdministration cmdlet allows a farm administrator to configure particular settings on a site collection even if the farm administrator is not granted explicit permissions. Any parameter that is not provided is not changed.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Set-SPSiteAdministration http://sitename -OwnerAlias "DOMAIN\NewOwner"

This example allows farm administrators to change the ownership of a site collection to which they do not have access.

See Also

Reference

Get-SPSiteAdministration
Get-SPSite


Set-SPSiteSubscriptionConfig
Example
[image]

Published: May 12, 2010

Sets the configuration properties of a site subscription.

Set-SPSiteSubscriptionConfig [-Identity] <SPSiteSubscriptionPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-FeaturePack <SPSiteSubscriptionFeaturePackPipeBind>] [-PassThru <SwitchParameter>] [-UserAccountDirectoryPath <String>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSiteSubscriptionPipeBind

Specifies the site subscription configuration to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; an SPSite (object or URL) of a site collection that is a member of the site subscription; or an instance of a valid SiteSubscription object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

PassThru

Optional

System.Management.Automation.SwitchParameter

Specifies the output object can be passed through the pipeline.

FeatureSet

Optional

Microsoft.SharePoint.PowerShell.SPFeatureSetPipeBind

Specifies the feature set that is associated with the site subscription.

Specifies a null value to clear the current association.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; or an instance of a valid SPFeatureSetobject.

UserAccountDirectoryPath

Optional

System.String

Sets the site user account directory path to a specific organizational unit (OU) that is in the same domain as the site subscription.

The type must be a name of a distinguished OU; for example, OU=Contoso1, DC=OSGCorp,DC=local.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Set-SPSiteSubscriptionConfig cmdlet sets the configuration properties of a site subscription.

Input Types

Return Types

Example

------------EXAMPLE---------------

Copy Code
Set-SPSiteSubscription http://contoso.com -FeatureSet 12345678-90ab-cdef-1234-567890abcdef

This example sets the Feature set of the entire site subscription that contains http://contoso.com with a Feature set GUID.


Set-SPSubscriptionSettingsServiceApplication
See Also Example
[image]

Published: May 12, 2010

Sets properties of a subscription settings service application.

Set-SPSubscriptionSettingsServiceApplication [-Identity] <SPServiceApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DatabaseCredentials <PSCredential>] [-DatabaseName <String>] [-DatabaseServer <String>] [-FailoverDatabaseServer <String>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPServiceApplicationPipeBind

Specifies the settings service application to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a subscription settings service application (for example, SubscriptionSettingsApp1); or an instance of a valid SPSubscriptionSettingsServiceApplication object.

ApplicationPool

Optional

Microsoft.SharePoint.PowerShell.SPIisWebServiceApplicationPoolPipeBind

Specifies the Internet Information Services (IIS) application pool to use for the new subscription settings application.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of an application pool (for example, AppPoolName1); or an instance of a valid IISWebServiceApplicationPool object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DatabaseCredentials

Optional

System.Management.Automation.PSCredential

Specifies the PSCredential object that contains the user name and password to be used for database SQL Server Authentication.

The type must be a valid PSCredential object.

DatabaseName

Optional

System.String

Specifies the name of the subscription settings database.

The type must be a valid name of a SQL Server database; for example, SubscriptionSettingsAppDB1.

DatabaseServer

Optional

Microsoft.SharePoint.PowerShell.SPServerPipeBind

Specifies the name of the host SQL Server instance for the database specified in DatabaseName parameter.

The type must be a valid SQL Server instance name; for example, SQLServerHost1.

FailoverDatabaseServer

Optional

System.String

Specifies the name of the host SQL Server instance for the failover database server.

The type must be a valid SQL Server instance name; for example, SQLServerHost1.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

Use the Set-SPSubscriptionSettingsServiceApplication cmdlet to set properties on a subscription settings service application.

Input Types

Return Types

Example

---------------------EXAMPLE--------------------------

Copy Code
$applicationPool = GetServiceApplicationPool SettingsApplicationPool
Copy Code
Get-SPServiceApplication -Name SettingsServiceApp | Set-SPSubscriptionSettingsServiceApplication -ApplicationPool $applicationPool

This example changes the application pool of the subscription settings service application. This command assumes that a subscription settings service application named SettingsServiceApp exists and that an application pool named SettingsApplicationPool exists

See Also

Reference

New-SPSubscriptionSettingsServiceApplication
New-SPSubscriptionSettingsServiceApplicationProxy


Set-SPUser
See Also Example
[image]

Published: May 12, 2010

Configures properties on an existing user.

Set-SPUser [-Identity] <SPUserPipeBind> [-AddPermissionLevel <String[]>] [-AssignmentCollection <SPAssignmentCollection>] [-ClearPermissions <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-DisplayName <String>] [-Email <String>] [-Group <SPGroupPipeBind>] [-IsSiteCollectionAdmin <SwitchParameter>] [-MobileNumber <String>] [-PassThru <SwitchParameter>] [-RemovePermissionLevel <String[]>] [-SyncFromAD <SwitchParameter>] [-Web <SPWebPipeBind>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPUserPipeBind

Specifies the GUID, login name, or SPUser object of the user to be returned.

The type must be a valid GUID of the user, in the form 1234-5678-9876-0987.

AddPermissionLevel

Optional

System.String[]

Specifies the permission level to add to the user.

The type must be any one of the following types:

-- Contribute - Can view, add, update, and delete list items and documents.

-- Design - Can view, add, update, delete, approve, and customize documents.

-- Full Control - Has full control to all documents.

-- Limited Access - Can view specific lists, document libraries, list items, folders, or documents when permissions are granted.

-- Read - Can view pages and list items and download documents.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

ClearPermissions

Optional

System.Management.Automation.SwitchParameter

Clears all given permissions from the user. If Clear and Add values are given, the permissions are first cleared, then the new permissions are given.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DisplayName

Optional

System.String

Specifies the new display name of the user.

The type must be a valid name.

Email

Optional

System.String

Specifies the new e-mail address of the user.

Group

Optional

Microsoft.SharePoint.PowerShell.SPGroupPipeBind

Adds the user to the specified named group of the given site.

IsSiteCollectionAdmin

Optional

none

Specifies whether to set the user as a site collection administrator.

MobileNumber

Optional

System.String

Sets the new mobile number for the user.

PassThru

Optional

none

If not provided, indicates that this cmdlet has no output. If provided, this parameter indicates that the SPUser object for this user is to be returned.

RemovePermissionLevel

Optional

System.String[]

Removes the permission level from the user.

SyncFromAD

Optional

System.Management.Automation.SwitchParameter

If provided, specifies that user information will be synchronized from the user directory store.

Web

Optional

Microsoft.SharePoint.PowerShell.SPWebPipeBind

Specifies the name of the URL or GUID to be used as a scope. This parameter is not needed if the SPUser object is provided as the identity.

The type must be a valid URL, in the form http://server_name, or GUID, in the form 1234-5678-9807.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Set-SPUser cmdlet configures properties on an existing user.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Set-SPUser -Identity 'Contoso\jdoe' -Web http://test -AddPermissionLevel "Contributor"

This example sets a user (Contoso\jdoe) to be a contributor on http://test.

See Also

Reference

Get-SPUser
New-SPUser
Remove-SPUser
Move-SPUser


Set-SPWebApplication
See Also Example
[image]

Published: May 12, 2010

Configures the specified Web application.

Set-SPWebApplication [-Identity] <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DefaultQuotaTemplate <String>] [-DefaultTimeZone <Int32>] [-Force <SwitchParameter>] [-ServiceApplicationProxyGroup <SPServiceApplicationProxyGroupPipeBind>] [-WhatIf [<SwitchParameter>]]
Set-SPWebApplication [-Identity] <SPWebApplicationPipeBind> -Zone <Default | Intranet | Internet | Custom | Extranet> [-AdditionalClaimProvider <SPClaimProviderPipeBind[]>] [-AssignmentCollection <SPAssignmentCollection>] [-AuthenticationMethod <String>] [-AuthenticationProvider <SPAuthenticationProviderPipeBind[]>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-SignInRedirectProvider <SPTrustedIdentityTokenIssuerPipeBind>] [-SignInRedirectURL <String>] [-WhatIf [<SwitchParameter>]]
Set-SPWebApplication [-Identity] <SPWebApplicationPipeBind> -SMTPServer <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-OutgoingEmailAddress <String>] [-ReplyToEmailAddress <String>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the name or URL of the Web application.

The type must be a valid name, in the form WebApplication-1212, or URL, in the form http://server_name/WebApplicaiton-1212.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

DefaultQuotaTemplate

Optional

System.String

Specifies the new default site quota template for this Web application.

DefaultTimeZone

Optional

System.Int32

Specifies the default time zone for new site collections in this Web application.

ServiceApplicationProxyGroup

Optional

Microsoft.SharePoint.PowerShell.SPServiceApplicationProxyGroupPipeBind

Specifies a custom service application proxy group for the Web application to use. The Web application will use the proxies in this proxy group to connect to service applications. If this parameter is not specified, the farm's default proxy group is used.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the name or URL of the Web application.

The type must be a valid name, in the form WebApplication-1212, or URL, in the form http://server_name/WebApplicaiton-1212.

Zone

Required

Microsoft.SharePoint.Administration.SPUrlZone

When configuring zone-specific settings, the zone to configure must be specified. This zone must already exist.

The type must be any one of the following values: Default, Intranet, Internet, Extranet, or Custom.

AdditionalClaimProvider

Optional

Microsoft.SharePoint.PowerShell.SPClaimProviderPipeBind[]

Adds a specific claim provider to the defined Web application.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

AuthenticationProvider

Optional

Microsoft.SharePoint.PowerShell.SPAuthenticationProviderPipeBind[]

Defines the authentication provider(s) that applies to the Web application.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

SignInRedirectProvider

Optional

Microsoft.SharePoint.PowerShell.SPTrustedIdentityTokenIssuerPipeBind

Sets the sign-in redirect URL to point to the URL that is defined in the specified authentication provider.

SignInRedirectURL

Optional

System.String

Specifies the sign-in redirect URL for the Web application.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

3

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the name or URL of the Web application.

The type must be a valid name, in the form WebApplication-1212, or URL, in the form http://server_name/WebApplicaiton-1212.

OutgoingEmailAddress

Optional

System.String

Specifies the new outgoing e-mail address for e-mail messages sent from this Web application. The type must be a valid address; for example, someone@example.com.

ReplyToEmailAddress

Optional

System.String

Configures the reply e-mail address.

The type must be a valid address; for example, someone@example.com.

SMTPServer

Required

System.String

Specifies the new outbound SMTP server that this Web application will use.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Set-SPWebApplication cmdlet configures the Web application specified by the Identity parameter. For any settings that are zone-specific (for the Zone parameter set), the zone to configure must be provided. The provided zone must already exist.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Get-SPWebApplication http://somesite | Set-SPWebApplication -Zone "Extranet" -HostHeader "http://www.contoso.com" - AllowAnonymousAccess

This example sets the HostHeader URL for the Extranet zone of the given Web application as http://www.contoso.com and enables anonymous access.

See Also

Reference

Get-SPWebApplication
New-SPWebApplication
Remove-SPWebApplication


Set-SPWeb
See Also Example
[image]

Published: May 12, 2010

Configures the specified subsite.

Set-SPWeb [-Identity] <SPWebPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Description <String>] [-RelativeUrl <String>] [-Template <SPWebTemplatePipeBind>] [-Theme <String>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPWebPipeBind

The URL of the Web or SPWeb object that represents the Web.

The type must be a valid URL, in the form http://server_name, or an SPWeb object.

Name

Optional

String

Specifies the new name of the Web.

Description

Optional

System.String

Specifies the new description of the Web.

RelativeUrl

Optional

System.String

Specifies the new relative URL for the Web. This is the URL path after the site collection URL.

Theme

Optional

System.String

Specifies the new theme to apply to the Web.

Template

Optional

Microsoft.SharePoint.PowerShell.SPWebTemplatePipeBind

Specifies the new template to apply to the Web. This cannot be done if the template is already applied.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Set-SPWeb cmdlet configures the subsite specified by the Identity parameter. Settings for any parameters that are not provided are not changed.

Input Types

Return Types

one

Example

------------------EXAMPLE-----------------------

Copy Code
Get-SPWeb http://sitename/subweb | Set-SPWeb -Title "My Site Title"

This example sets the title of an existing subsite.

See Also

Reference

Get-SPWeb
New-SPWeb
Remove-SPWeb
Export-SPWeb
Import-SPWeb


Export-SPSiteSubscriptionSettings
See Also Example
[image]

Published: May 12, 2010

Creates a backup file of site subscription data.

Export-SPSiteSubscriptionSettings [-Identity] <SPSiteSubscriptionPipeBind> -Path <String> [-AdminProperties <SwitchParameter>] [-AssignmentCollection <SPAssignmentCollection>] [-Force <SwitchParameter>]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSiteSubscriptionPipeBind

Specifies the ID of the site subscription from which to back up data.

The type must be a valid URL, in the form http://server_name or a GUID in the form 1234-4567-985tg.

Path

Required

System.String

Specifies the location of the output file.

The type must be a valid path; for example, C:/backupfile.back..

AdminProperties

Optional

System.Management.Automation.SwitchParameter

Specifies that only administrator subscription properties are exported. If this parameter is not set, only non-administrator subscription properties are exported.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Force

No

System.Management.Automation.SwitchParameter

Forces the output backup file (if provided) to overwrite any existing file at the given path.

Detailed Description

The Export-SPSiteSubscriptionSettings cmdlet generates a backup file of all settings in the subscription data store for the given site subscription.

Input Types

Return Types

Example

--------------EXAMPLE-----------------

Copy Code
Get-SPSiteSubscription http://contoso.com | Backup-SPSiteSubscriptionSettings -path "c:/backups"

The example backs up the subscription settings store of http://www.contoso.com.

See Also

Reference

Import-SPSiteSubscriptionSettings
Remove-SPSiteSubscriptionSettings


Import-SPSiteSubscriptionSettings
See Also Example
[image]

Published: May 12, 2010

Restores a backup of subscription site settings to the given subscription identifier.

Import-SPSiteSubscriptionSettings [-Identity] <SPSiteSubscriptionPipeBind> -Path <String> [-AdminProperties <SwitchParameter>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Force <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPSiteSubscriptionPipeBind

Specifies the ID of the subscription to restore .

The type must be a valid URL, in the form http://server_name, or a GUID, in the form 1234-4567-985tg.

Path

Required

System.String

Specifies the location of the input file.

The type must be a valid path, in the form C:\filename.bak.

AdminProperties

Optional

System.Management.Automation.SwitchParameter

Specifies that only administrator subscription properties are imported. If this parameter is not set, only non-administrator subscription properties are imported.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Force

No

System.Management.Automation.SwitchParameter

If a setting key already exists, determines whether the value must be overwritten with the value in the backup file.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Import-SPSiteSubscriptionSettings cmdlet restores a backup of subscription site settings to the given subscription identifier when the Identity parameter is used. To overwrite existing settings, use the Force parameter.

Input Types

Return Types

Example

--------------EXAMPLE-----------------

Copy Code
Get-SPSiteSubscription http://contoso.com | Import-SPSiteSubscriptionSettings -path "c:/backups/contoso_settings_file.bak" -force

This example restores the subscription settings store of contoso.com.

See Also

Reference

Export-SPSiteSubscriptionSettings
Remove-SPSiteSubscriptionSettings


Get-SPDeletedSite
See Also Example
[image]

Published: June 28, 2011

Gets a list of deleted site collections.

Get-SPDeletedSite [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-ContentDatabase <SPContentDatabasePipeBind>] [-DateTimeFrom <String>] [-DateTimeTo <String>] [-Limit <String>] [-SiteSubscription <SPSiteSubscriptionPipeBind>] [-WebApplication <SPWebApplicationPipeBind>] [-WhatIf [<SwitchParameter>]]
Get-SPDeletedSite [-Identity] <SPDeletedSitePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-ContentDatabase <SPContentDatabasePipeBind>] [-DateTimeFrom <String>] [-DateTimeTo <String>] [-Limit <String>] [-SiteSubscription <SPSiteSubscriptionPipeBind>] [-WebApplication <SPWebApplicationPipeBind>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

ContentDatabase

Optional

Microsoft.SharePoint.PowerShell.SPContentDatabasePipeBind

Specifies the GUID of the content database from which to list site collections.

The type must be a valid database name in the form SPContentDB01 or a valid GUID, for example, 12345678-90ab-cdef-1234-567890bcdefgh.

DateTimeFrom

Optional

System.String

The type must be a valid DateTime format that is culture-specific to the administrative language, such as 2/16/2007 12:15:12 for English-US.

DateTimeTo

Optional

System.String

The type must be a valid DateTime format that is culture-specific to the administrative language, such as 2/16/2007 12:15:12 for English-US.

Limit

Optional

System.String

Limits the maximum number of site collections to return. The default value is 1000.

The type must be a valid non-negative number. Specify ALL to return all site collections for the given scope.

SiteSubscription

Optional

Microsoft.SharePoint.PowerShell.SPSiteSubscriptionPipeBind

Specifies the site subscription from which to get site collections.

The type must be a valid URL in the form http://server_name or a valid GUID, for example, 12345678-90ab-cdef-1234-567890bcdefgh.

WebApplication

Optional

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the URL, GUID, or name of the Web application from which to list sites.

The type must be a valid URL in the form http://server_name; a valid GUID, for example, 12345678-90ab-cdef-1234-567890bcdefgh; or the Web application name, for example, WebApplication1212.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPDeletedSitePipeBind

Specifies the URL or GUID of the site collection to get.

The identity can be either a valid server-relative URL in the form /sites/site_name or a valid GUID, for example, 12345678-90ab-cdef-1234-567890bcdefgh.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

ContentDatabase

Optional

Microsoft.SharePoint.PowerShell.SPContentDatabasePipeBind

Specifies the GUID of the content database from which to list site collections.

The type must be a valid database name in the form SPContentDB01 or a valid GUID, for example, 12345678-90ab-cdef-1234-567890bcdefgh.

DateTimeFrom

Optional

System.String

The type must be a valid DateTime format that is culture-specific to the administrative language, such as 2/16/2007 12:15:12 for English-US.

DateTimeTo

Optional

System.String

The type must be a valid DateTime format that is culture-specific to the administrative language, such as 2/16/2007 12:15:12 for English-US.

Limit

Optional

System.String

Limits the maximum number of site collections to return. The default value is 1000.

The type must be a valid non-negative number. Specify ALL to return all site collections for the given scope.

SiteSubscription

Optional

Microsoft.SharePoint.PowerShell.SPSiteSubscriptionPipeBind

Specifies the site subscription from which to get site collections.

The type must be a valid URL in the form http://server_name or a valid GUID, for example, 12345678-90ab-cdef-1234-567890bcdefgh.

WebApplication

Optional

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the URL, GUID, or name of the Web application from which to list sites.

The type must be a valid URL in the form http://server_name; a valid GUID, for example, 12345678-90ab-cdef-1234-567890bcdefgh; or the Web application name, for example, WebApplication1212.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

This cmdlet was introduced in Microsoft SharePoint Server 2010 with Service Pack 1 (SP1) and Microsoft SharePoint Foundation 2010 with Service Pack 1 (SP1).

Use the Get-SPDeletedSite cmdlet to display a list of deleted site collections by using the Identity parameter. If no parameter is specified, then all deleted site collections in the farm are displayed.

Unlike the Get-SPSite cmdlet that uses the host name and scheme for the Identity parameter (that is, http://server_name), the value of the identity parameter for all SPDeletedSite cmdlets use a server-relative URL. Typically, the forward slash character (/) begins the relative URL and also denotes the root site.

For additional information about a server-relative URL or understanding general concepts about absolute and relative URLs, see Server-relative URL Property or Understanding Absolute and Relative URL Addresses.

Input Types

Return Types

Example

------------------EXAMPLE 1---------------------

Copy Code
Get-SPDeletedSite -Identity 610857cb-8414-4a89-8bf3-ad3628f6c86c

This example gets a specific deleted site collection by using a site ID.

------------------EXAMPLE 2---------------------

Copy Code
Get-SPDeletedSite "/"

This example gets a deleted site collection from the root site.

------------------EXAMPLE 3---------------------

Copy Code
Get-SPDeletedSite '/Site/cat*'

This example matches a deleted site collection that contains any combination with the string "cat". The asterisk (*) wildcard character requests a match for multiple characters.

See Also

Reference

Remove-SPDeletedSite
Restore-SPDeletedSite


Remove-SPDeletedSite
See Also Example
[image]

Published: June 28, 2011

Removes a deleted site collection.

Remove-SPDeletedSite [-Identity] <SPDeletedSitePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-ContentDatabase <SPContentDatabasePipeBind>] [-WebApplication <SPWebApplicationPipeBind>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPDeletedSitePipeBind

Specifies the identity of the deleted site collection to permanently delete. The identity can be either a valid server-relative URL in the form /sites/site_name; a valid GUID in the form 12345678-90ab-cdef-1234-567890bcdefgh; or an SPDeletedSite object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

ContentDatabase

Optional

Microsoft.SharePoint.PowerShell.SPContentDatabasePipeBind

Specifies the GUID of the content database from which to list site collections.

The type must be a valid database name in the form SPContentDB01 or a valid GUID, for example, 12345678-90ab-cdef-1234-567890bcdefgh.

WebApplication

Optional

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the URL, GUID, or name of the Web application from which to list sites.

The type must be a valid URL in the form http://server_name; a valid GUID, for example, 12345678-90ab-cdef-1234-567890bcdefgh; or the Web application name, for example, WebApplication1212.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet was introduced in Microsoft SharePoint Server 2010 with Service Pack 1 (SP1) and Microsoft SharePoint Foundation 2010 with Service Pack 1 (SP1).

Use the Remove-SPDeletedSite cmdlet to permanently remove a deleted site collection from the farm.

Unlike the Remove-SPSite cmdlet that uses the host name and scheme for the Identity parameter (that is, http://server_name), the value of the identity parameter for all SPDeletedSite cmdlets use a server-relative URL. Typically, the forward slash character (/) begins the relative URL and also denotes the root site.

For additional information about a server-relative URL or understanding general concepts about absolute and relative URLs, see Server Relative URL Property or Understanding Absolute and Relative URL Addresses.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Remove-SPDeletedSite -Identity 610857cb-8414-4a89-8bf3-ad3628f6c86c

This example permanently removes a specific deleted site collection by using a site ID.

See Also

Reference

Get-SPDeletedSite
Restore-SPDeletedSite


Restore-SPDeletedSite
See Also Example
[image]

Published: June 28, 2011

Restores a deleted site collection.

Restore-SPDeletedSite [-Identity] <SPDeletedSitePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-ContentDatabase <SPContentDatabasePipeBind>] [-WebApplication <SPWebApplicationPipeBind>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPDeletedSitePipeBind

Specifies the identity of the deleted site collection to be restored. The identity can be either a valid server-relative URL in the form /sites/site_name; a valid GUID in the form 12345678-90ab-cdef-1234-567890bcdefgh; or an SPDeletedSite object

A site collection must not already exist at the URL location to perform a restore.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

ContentDatabase

Optional

Microsoft.SharePoint.PowerShell.SPContentDatabasePipeBind

Specifies the SQL Server content database where the site collection data will be stored. If no content database is specified, the content database with the greatest unused site collection capacity and whose database status is ready will be used.

WebApplication

Optional

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the URL, GUID, or name of the Web application from which to list sites.

The type must be a valid URL in the form http://server_name; a valid GUID, for example, 12345678-90ab-cdef-1234-567890bcdefgh; or the Web application name, for example, WebApplication1212.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet was introduced in Microsoft SharePoint Server 2010 with Service Pack 1 (SP1) and Microsoft SharePoint Foundation 2010 with Service Pack 1 (SP1).

Use the Restore-SPDeletedSite cmdlet to restore a previously deleted site collection.

Unlike the Restore-SPSite cmdlet that uses the host name and scheme for the Identity parameter (that is, http://server_name), the value of the identity parameter for all SPDeletedSite cmdlets use a server-relative URL. Typically, the forward slash character (/) begins the relative URL and also denotes the root site.

For additional information about a server-relative URL or understanding general concepts about absolute and relative URLs, see Server-relative URL Property or Understanding Absolute and Relative URL Addresses.

Input Types

Return Types

Example

----------------------EXAMPLE 1----------------------

Copy Code
Restore-SPDeletedSite -Identity 610857cb-8414-4a89-8bf3-ad3628f6c86c

This example restores a specific deleted site collection by using the site ID.

See Also

Reference

Get-SPDeletedSite
Remove-SPDeletedSite


Timer jobs cmdlets (SharePoint Foundation 2010)
See Also

You can use Windows PowerShell cmdlets to manage timer jobs in a Microsoft SharePoint Foundation 2010 farm.

Cmdlet name | Description
Disable-SPTimerJob | Disables a timer job.
Enable-SPTimerJob | Enables a timer job.
Get-SPTimerJob | Returns timer jobs.
Set-SPTimerJob | Sets the schedule for running a timer job.
Start-SPTimerJob | Runs a timer job once.

See Also

Other Resources

Resource Center: Windows PowerShell for SharePoint Foundation 2010


Disable-SPTimerJob
See Also Example
[image]

Published: May 12, 2010

Disables a timer job.

Disable-SPTimerJob [-Identity] <SPTimerJobPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPTimerJobPipeBind

Specifies the timer job to disable.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a timer job (for example, TimerJob1); or an instance of a valid SPTimerJob object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Disable-SPTimerJob cmdlet disables a timer job.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

--------------------EXAMPLE-----------------------

Copy Code
Get-SPTimerJob job-ceip-datacollection | Disable-SPTimerJob

This example disables the timer job named job-ceip-datacollection.

See Also

Reference

Get-SPTimerJob
Enable-SPTimerJob
Set-SPTimerJob
Start-SPTimerJob


Enable-SPTimerJob
See Also Example
[image]

Published: May 12, 2010

Enables a timer job.

Enable-SPTimerJob [-Identity] <SPTimerJobPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPTimerJobPipeBind

Specifies the timer job to enable.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a timer job (for example, TimerJob1); or an instance of a valid SPTimerJob object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Enable-SPTimerJob cmdlet enables a timer job. A timer job must be enabled before it can be started.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

-------------------EXAMPLE---------------------

Copy Code
Get-SPTimerJob job-ceip-datacollection | Enable-SPTimerJob

This example enables the timer job named job-ceip-datacollection.

See Also

Reference

Get-SPTimerJob
Set-SPTimerJob
Start-SPTimerJob
Disable-SPTimerJob


Get-SPTimerJob
See Also Example
[image]

Published: May 12, 2010

Returns timer jobs.

Get-SPTimerJob [[-Identity] <SPTimerJobPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-Type <String>] [-WebApplication <SPWebApplicationPipeBind>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPTimerJobPipeBind

Specifies the timer job to get.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a timer job (for example, TimerJob1); or an instance of a valid SPTimerJob object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Type

Optional

System.String

Filters to return timer jobs of a specified type.

The type must be a name of a valid timer job type; for example, TimerJob1.

WebApplication

Optional

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Filters to return timer jobs defined for the scope of a specified SharePoint Web application.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a SharePoint Web application (for example, MyOfficeApp1); or an instance of a valid SPWebApplication object.

Detailed Description

The Get-SPTimerJob cmdlet reads a specified timer job, timer jobs of a specified type, or timer jobs defined for a specified scope. If no parameters are specified, this cmdlet returns all timer job definitions for the farm.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

---------------------EXAMPLE---------------------

Copy Code
Get-SPTimerJob -WebApplication "http://servername" | select Name, DisplayName

This example displays all timer jobs for a specified Web application.

See Also

Reference

Set-SPTimerJob
Start-SPTimerJob
Disable-SPTimerJob
Enable-SPTimerJob


Set-SPTimerJob
See Also Example
[image]

Published: May 12, 2010

Sets the schedule for running a timer job.

Set-SPTimerJob [-Identity] <SPTimerJobPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Schedule <String>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPTimerJobPipeBind

Specifies the timer job to update.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a timer job (for example, TimerJob1); or an instance of a valid SPTimerJob object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Schedule

Required

System.String

Specifies the schedule for running the timer job.

The type must be a valid SharePoint Timer service (SPTimer) schedule in the form of any one of the following schedules:

- Every 5 minutes between 0 and 59

- Hourly between 0 and 59

- Daily at 15:00:00

- Weekly between Fri 22:00:00 and Sun 06:00:00

- Monthly at 15 15:00:00

- Yearly at Jan 1 15:00:00

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Set-SPTimerJob cmdlet sets the schedule for running a specified timer job.

Input Types

Return Types

Errors

Error | Description

Exceptions

Exceptions | Description

Example

-------------------EXAMPLE------------------------

Copy Code
Get-SPTimerJob job-recycle-bin-cleanup | Set-SPTimerJob -Schedule "weekly at sat 5:00"

This example sets the schedule to run the job-recylce-bin-cleanup timer job to weekly at sat 5:00.

See Also

Reference

Get-SPTimerJob
Start-SPTimerJob
Disable-SPTimerJob
Enable-SPTimerJob


Start-SPTimerJob
See Also Example
[image]

Published: May 12, 2010

Runs a timer job once.

Start-SPTimerJob [-Identity] <SPTimerJobPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPTimerJobPipeBind

Specifies the timer job to run.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of a timer job (for example, TimerJob1); or an instance of a valid SPTimerJob object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Start-SPTimerJob cmdlet runs a timer job once on each front-end Web server where the parent service is provisioned.

Input Types

Return Types

Example

-----------------EXAMPLE----------------

Copy Code
Get-SPTimerJob job-recycle-bin-cleanup | Start-SPTimerJob

This example starts the timer job named, job-recycle-bin-cleanup.

See Also

Reference

Get-SPTimerJob
Set-SPTimerJob
Disable-SPTimerJob
Enable-SPTimerJob


Upgrade and migration cmdlets (SharePoint Foundation 2010)
See Also

You can use Windows PowerShell cmdlets to help perform an upgrade from an earlier version of Microsoft SharePoint Foundation 2010.

Cmdlet name | Description
Test-SPContentDatabase | Tests a content database.
Upgrade-SPContentDatabase | Upgrades a content database.

See Also

Other Resources

Resource Center: Windows PowerShell for SharePoint Foundation 2010


Upgrade-SPContentDatabase
See Also Example
[image]

Published: May 12, 2010

Resumes a failed database upgrade or begins a build to build database upgrade.

Upgrade-SPContentDatabase [-Identity] <SPContentDatabasePipeBind> [[-ForceDeleteLock] <SwitchParameter>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-ServerInstance <SPDatabaseServiceInstancePipeBind>] [-UpdateUserExperience <SwitchParameter>] [-WhatIf [<SwitchParameter>]]
Upgrade-SPContentDatabase [[-ForceDeleteLock] <SwitchParameter>] -Name <String> -WebApplication <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-ServerInstance <SPDatabaseServiceInstancePipeBind>] [-UpdateUserExperience <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPContentDatabasePipeBind

Specifies the content database to upgrade.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh or an instance of a valid SPContentDatabase object.

ForceDeleteLock

Optional

System.Management.Automation.SwitchParameter

Forces deletion of locks on the database before the upgrade starts.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

ServerInstance

Optional

Microsoft.SharePoint.PowerShell.SPDatabaseServiceInstancePipeBind

The SQL Server instance that hosts the attached content database.

UpdateUserExperience

Optional

System.Management.Automation.SwitchParameter

Determines whether the content databases should upgrade to the latest user interface. By default, the user interface will not change during upgrade.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

ForceDeleteLock

Optional

System.Management.Automation.SwitchParameter

Forces deletion of locks on the database before the upgrade starts.

Name

Required

System.String

Specifies the name of attached content database.

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the Web application that hosts the attached content database.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

ServerInstance

Optional

Microsoft.SharePoint.PowerShell.SPDatabaseServiceInstancePipeBind

The SQL Server instance that hosts the attached content database.

UpdateUserExperience

Optional

System.Management.Automation.SwitchParameter

Determines whether the content databases should upgrade to the latest user interface. By default, the user interface will not change during upgrade.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

Use the Upgrade-SPContentDatabase cmdlet to resume a failed database upgrade or begin a build to build database upgrade against a SharePoint content database. When the Upgrade-SPContentDatabase cmdlet is run, an upgrade of an existing content database attached to the current farm is initiated. This cmdlet begins a new upgrade session, which can be used either to resume a failed version-to-version or build-to-build upgrade of a content database or to begin a build-to-build upgrade of a content database.

Input Types

Return Types

Example

--------------------------EXAMPLE------------------------------

Copy Code
$contentdb = Get-SPContentDatabase | Where-Object {$_.Name -match "SQLSERVER1\WSS_Content"}
Copy Code
Upgrade-SPContentDatabase -Identity $contentdb

This example selects a specific content database that is currently attached to the farm, and then initiates an upgrade session. This process continues until the upgrade is complete and might take some time, depending upon the amount of changes that have to be made during the upgrade.

See Also

Reference

Dismount-SPContentDatabase
Get-SPContentDatabase
Mount-SPContentDatabase
New-SPContentDatabase
Remove-SPContentDatabase
Set-SPContentDatabase
Test-SPContentDatabase


Web application cmdlets (SharePoint Foundation 2010)

Published: June 24, 2010

You can use Windows PowerShell cmdlets to administer Web applications in a Microsoft SharePoint Foundation 2010 farm.

Cmdlet name | Description
Get-SPAlternateURL | Returns all alternate URLs that match a given set of criteria.
Get-SPMobileMessagingAccount | Retrieves mobile messaging accounts for the specified Web application.
Install-SPApplicationContent | Copies shared application data to existing Web application folders.
New-SPAlternateUrl | Creates a new public or internal URL for the specified Web application zone or resource.
Remove-SPAlternateUrl | Completely deletes the specified alternate URL.
Set-SPAlternateUrl | Configures the specified alternate URL.
Set-SPMobileMessagingAccount | Configures the specified mobile messaging account.


Get-SPAlternateURL
See Also Example
[image]

Published: May 12, 2010

Returns all alternate URLs that match a given set of criteria.

Get-SPAlternateURL [[-Identity] <SPAlternateUrlPipeBind>] [-AssignmentCollection <SPAssignmentCollection>] [-Zone <Default | Intranet | Internet | Custom | Extranet>]
Get-SPAlternateURL [[-Identity] <SPAlternateUrlPipeBind>] -WebApplication <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Zone <Default | Intranet | Internet | Custom | Extranet>]
Get-SPAlternateURL [[-Identity] <SPAlternateUrlPipeBind>] -ResourceName <String> [-AssignmentCollection <SPAssignmentCollection>] [-Zone <Default | Intranet | Internet | Custom | Extranet>]

Parameters

1

Parameter

Required

Type

Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPAlternateUrlPipeBind

Specifies the URL or GUID of the alternate URL to get.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh, or a valid URL, in the form http://server_name.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Zone

Optional

System.String

Specifies one of the five zones with which the alternate URLs is associated.

Must be a valid zone: Default, Intranet, Internet, Extranet, or Custom

2

Parameter

Required

Type

Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPAlternateUrlPipeBind

Specifies the URL or GUID of the alternate URL to get.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh, or a valid URL, in the form http://server_name.

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the Web application from which to list alternate URLs.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Zone

Optional

System.String

Specifies one of the five zones with which the alternate URLs is associated.

Must be a valid zone: Default, Intranet, Internet, Extranet, or Custom

3

Parameter

Required

Type

Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPAlternateUrlPipeBind

Specifies the URL or GUID of the alternate URL to get.

The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh, or a valid URL, in the form http://server_name.

ResourceName

Required

System.String

Specifies the name of the resource from which to list alternate URLs.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Zone

Optional

System.String

Specifies one of the five zones with which the alternate URLs is associated.

Must be a valid zone: Default, Intranet, Internet, Extranet, or Custom

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Get-SPAlternateURL cmdlet returns all alternate URLs that match the scope given by either the optional Identity parameter or by a combination of the optional WebApplication, Zone, or Resource parameters. Each criterion that is added narrows the scope. If no criteria are specified then all alternate URLs are returned.

If the Identity parameter is used, only the specific matching alternate URL is returned. If no alternate URL with the given identity exists at the given scope, nothing is returned.

Input Types

Return Types

Example

--------------EXAMPLE 1-----------------

Copy Code
Get-SPAlternateURL -WebApplication http://sitename

This example displays all the alternate URLs on a given Web application.

--------------EXAMPLE 2-----------------

Copy Code
Get-SPAlternateURL -ResourceName "MyResource"

This example displays all the alternate URLs for a given resource.

See Also

Reference

New-SPAlternateUrl
Set-SPAlternateUrl
Remove-SPAlternateUrl


Get-SPMobileMessagingAccount
See Also Example
[image]

Published: May 12, 2010

Retrieves mobile messaging accounts for the specified Web application.

Get-SPMobileMessagingAccount [[-Identity] <SPMobileMessagingAccountPipeBind>] -WebApplication <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

Identity

Optional

Microsoft.SharePoint.PowerShell.SPMobileMessagingAccountPipeBind

Specifies whether to return either Short Message Service (SMS) or Multimedia Messaging Service (MMS) account information. Valid values are:SMS and MMS. If you do not specify this parameter, account information is returned for both SMS and MMS.

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the identity of the Web application to delete. The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid Web application name (for example, WebApplication1212); or a valid name (for example, WebApp2423).

You either must specify WebApplication or must use the HostHeader switch and specify the full URL in the Identity parameter.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPMobileMessagingAccount cmdlet retrieves the specified mobile messaging accounts for the specified Web application.

Input Types

Return Types

Example

--------------EXAMPLE-----------------

Copy Code
Get-SPMobileMessagingAccount -WebApplication http://sitename

This example retrieves the current mobile account settings information of the Web application http://sitename.

See Also

Reference

Set-SPMobileMessagingAccount


Install-SPApplicationContent
Example
[image]

Published: May 12, 2010

Copies shared application data to existing Web application folders.

Install-SPApplicationContent [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Install-SPApplicationContent cmdlet copies shared application data to existing Web application folders.

This cmdlet does not take any parameters.

Input Types

Return Types

Example

---------------------EXAMPLE--------------------

Copy Code
Install-SPApplicationContent

This example copies data to a Web application in the existing folders.


New-SPAlternateUrl
See Also Example
[image]

Published: May 12, 2010

Creates a new public or internal URL for the specified Web application zone or resource.

New-SPAlternateUrl [-Url] <String> -WebApplication <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Internal <SwitchParameter>] [-WhatIf [<SwitchParameter>]] [-Zone <Default | Intranet | Internet | Custom | Extranet>]
New-SPAlternateUrl [-Url] <String> -ResourceName <String> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Internal <SwitchParameter>] [-WhatIf [<SwitchParameter>]] [-Zone <Default | Intranet | Internet | Custom | Extranet>]

Parameters

1

Parameter

Required

Type

Description

Url

Required

System.String

Specifies the public URL that users access to sign in to the Web application.

The type must be a valid URL, in the form http://server_name.

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the name, URL, or GUID of the Web application for which to create the mapping.

The type must be a valid name, URL, in the form WebApplication-1212, http://server_name, or GUID, in the form 1234-5678-9876-0987.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Internal

Optional

System.Management.Automation.SwitchParameter

Makes this alternate URL an internal URL. If this parameter is not provided, the URL is a public URL.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Zone

Optional

System.String

Specifies one of the five zones with which the alternate URL is associated.

The type must be a valid zone: Default, Intranet, Internet, Extranet, or Custom.

2

Parameter

Required

Type

Description

Url

Required

System.String

Specifies the public URL that users access to sign in to the Web application.

The type must be a valid URL, in the form http://server_name.

ResourceName

Required

System.String

Specifies the resource name, if the alternate URL is for an external resource. If no value is specified, the value is left blank.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

Internal

Optional

System.Management.Automation.SwitchParameter

Makes this alternate URL an internal URL. If this parameter is not provided, the URL is a public URL.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Zone

Optional

System.String

Specifies one of the five zones with which the alternate URL is associated.

The type must be a valid zone: Default, Intranet, Internet, Extranet, or Custom.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The New-SPAlternateUrl cmdlet creates a new public or internal URL for the specified Web application zone or resource. Use the ResourceName parameter if the alternate URL is for an external resource.

Each Web application can be associated with a collection of mappings between internal and public URLs. Both internal and public URLs consist of the protocol and domain portion of the full URL; for example, https://www.fabrikam.com. Users type a public URL to get to the SharePoint site, and that URL appears in the links on the pages. Internal URLs are in the URL requests that are sent to the SharePoint site. Many internal URLs can be associated with a single public URL in multiserver farms; for example, when a load balancer routes requests to specific IP addresses to various servers in the load-balancing cluster.

Each Web application supports five collections of mappings per URL; the five collections correspond to five zones (default, intranet, extranet, Internet, and custom). When the Web application receives a request for an internal URL in a particular zone, links on the pages returned to the user have the public URL for that zone.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
#create the public URL
New-SPAlternateURL https://www.contoso.com -Zone "Internet"
Copy Code
#create the internal URL
New-SPAlternateURL http://sharepoint.contoso.com -Zone "Internet" -internal

This example translates incoming requests for https://www.contoso.com into http://sharepoint.contoso.com (on the Internet zone).

When a reverse proxy is being set up to handle public URL SSL termination, alternate access mappings must be configured to handle the URL translation.

See Also

Reference

Set-SPAlternateUrl
Get-SPAlternateURL
Remove-SPAlternateUrl


Remove-SPAlternateUrl
See Also Example
[image]

Published: May 12, 2010

Completely deletes the specified alternate URL.

Remove-SPAlternateUrl [-Identity] <SPAlternateUrlPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPAlternateUrlPipeBind

Specifies the identity of the alternate URL to delete. The identity can be either a valid URL, in the form http://server_name, or a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Remove-SPAlternateUrl cmdlet completely deletes the alternate URL specified by the Identity parameter.

Input Types

Return Types

Example

------------------EXAMPLE 1-----------------------

Copy Code
Remove-SPAlternateURL -WebApplication http://sitename -Zone Extranet

This example deletes the extranet URL for the given Web application.

------------------EXAMPLE 2-----------------------

Copy Code
Get-SPWebApplication |%{ Get-SPAlternateURL -WebApplication $_ -Zone "Extranet" } | Remove-SPAlternateURL

This example removes all extranet alternate URLs in the farm.

See Also

Reference

New-SPAlternateUrl
Get-SPAlternateURL
Set-SPAlternateUrl


Set-SPAlternateUrl
See Also Example
[image]

Published: May 12, 2010

Configures the specified alternate URL.

Set-SPAlternateUrl [-Identity] <SPAlternateUrlPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Url <String>] [-WhatIf [<SwitchParameter>]] [-Zone <Default | Intranet | Internet | Custom | Extranet>]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPAlternateUrlPipeBind

Specifies the URL or GUID of the alternate URL to change.

The type must be a valid URL, in the form http://server_name/WebApplication/site, or a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh.

Url

Required

System.String

Specifies the new alternate URL.

Zone

Required

System.String

Sets the supplied alternate URL as one of the five zones.

The type must be any one of the following values: Default, Intranet, Internet, Extranet, or Custom.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Set-SPAlternateUrl cmdlet changes the URL or zone of the alternate URL specified by the Identity parameter. This cmdlet can be used to change only the zone of internal URLs, and cannot be used to change the zone of public URLs.

Input Types

Return Types

Example

------------------EXAMPLE 1------------------

Copy Code
Set-SPAlternateURL -Identity https://www.contoso.com -Zone "Internet"

This example changes the zone of the alternate URL https://www.contoso.com.

------------------EXAMPLE 2------------------

Copy Code
Set-SPAlternateURL -Identity https://www.contoso.com -Url https://sharepoint.contoso.com -Zone "Default"

This example changes the URL and zone of the alternate URL https://www.contoso.com.

------------------EXAMPLE 3------------------

Copy Code
Get-SPAlternateURL https://www.contoso.com | Set-SPAlternateURL -Zone "Internet"

This example changes the zone of the alternate URL https://www.contoso.com.

------------------EXAMPLE 4------------------

Copy Code
Get-SPWebApplication |%{ Get-SPAlternateURL -WebApplication $_ -Zone "Extranet" } | Set-SPAlternateURL -Zone "Intranet"

This example changes the zone of the alternate URL for the specified Web application from Extranet to Intranet.

See Also

Reference

Get-SPAlternateURL
New-SPAlternateUrl
Remove-SPAlternateUrl


Set-SPMobileMessagingAccount
See Also Example
[image]

Published: May 12, 2010

Configures the specified mobile messaging account.

Set-SPMobileMessagingAccount [-Identity] <SPMobileMessagingAccountPipeBind> -WebApplication <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Password <String>] [-ServiceName <String>] [-ServiceUrl <String>] [-UserId <String>]

Parameters

Parameter Required Type Description

Identity

Required

Microsoft.SharePoint.PowerShell.SPMobileMessagingAccountPipeBind

Specifies whether to return either Short Message Service (SMS) or Multimedia Messaging Service (MMS) account information. Valid values are SMS and MMS. If you do not specify this parameter account, information is returned for both SMS and MMS.

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the identity of the Web application that hosts the managed path to delete. The type must be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid Web application name (for example, WebApplication1212); or a valid name (for example, WebApp2423).

You either must specify WebApplication or must use the HostHeader switch and specify the full URL in the Identity parameter.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Password

Optional

System.String

Specifies the password, if credentials are required for the account.

ServiceName

Optional

System.String

Specifies the name of the SMS service.

ServiceUrl

Optional

System.String

Specifies the URL of the SMS service.

UserId

Optional

System.String

Specifies the user name, if credentials are required for the account.

Detailed Description

The Set-SPMobileMessagingAccount cmdlet configures the specified mobile messaging account.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Set-SPMobileMessagingAccount -WebApplication http://sitename -Identity SMS -ServiceName SMSLink -ServiceUrl https://www.adatum.com/Service/MessagingService.asmx-UserId someone@example.com -Password password1

This example changes the SMS mobile account settings of the Web application, http://sitename, to the following values:service name: SMSLink; service URL: https://www.adatum.com/Service/MessagingService.asmx; user ID: someone@example.com; and password: password1.

See Also

Reference

Get-SPMobileMessagingAccount


Workflow management cmdlets (SharePoint Foundation 2010)
See Also

You can use Windows PowerShell cmdlets to manage workflows in a Microsoft SharePoint Foundation 2010 farm.

Cmdlet name | Description
Get-SPWorkflowConfig | Returns workflow settings for the specified Web application.
Set-SPWorkflowConfig | Configures the workflow settings for the specified Web application.
Get-SPDesignerSettings | Displays Microsoft SharePoint Designer 2010 features.
Set-SPDesignerSettings | Sets Microsoft SharePoint Designer 2010 features.

See Also

Other Resources

Resource Center: Windows PowerShell for SharePoint Foundation 2010


Get-SPWorkflowConfig
See Also Example
[image]

Published: May 12, 2010

Returns workflow settings for the specified Web application.

Get-SPWorkflowConfig [-WebApplication] <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>]
Get-SPWorkflowConfig [-SiteCollection] <SPSitePipeBind> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

1

Parameter

Required

Type

Description

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the name or URL of the Web application.

The type must be a valid name, in the form WebApplication-1212, or a URL, in the form http://server_name/WebApplication-1212.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

2

Parameter

Required

Type

Description

SiteCollection

Required

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Specifies the name or URL of the site collection.

The only other parameter that is used with the SiteCollection parameter is the DeclarativeWorkflowsEnabled parameter. No other parameters are used.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Get-SPWorkflowConfig cmdlet returns workflow settings for the Web application specified by the WebApplication parameter.

Input Types

Return Types

Example

--------------EXAMPLE-----------------

Copy Code
Get-SPWorkFlowConfig -webapplication http://sitename

This example gets workflow settings for the specified Web application (http://sitename).

To get farm-level workflow settings for event delivery time-out, postpone threshold, and batch size, use the Get-SPFarmConfig cmdlet.

See Also

Reference

Set-SPWorkflowConfig


Set-SPWorkflowConfig
See Also Example
[image]

Published: May 12, 2010

Configures the workflow settings for the specified Web application.

Set-SPWorkflowConfig [-WebApplication] <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-DeclarativeWorkflowsEnabled <$true | $false>] [-EmailNoPermissionParticipantsEnabled <$true | $false>] [-SendDocumentToExternalParticipants <$true | $false>]
Set-SPWorkflowConfig [-SiteCollection] <SPSitePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-DeclarativeWorkflowsEnabled <$true | $false>] [-EmailNoPermissionParticipantsEnabled <$true | $false>] [-SendDocumentToExternalParticipants <$true | $false>]

Parameters

1

Parameter

Required

Type

Description

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the name or URL of the Web application.

The type must be a valid name or GUID, in the form WebApplication-1212, or a URL, in the form http://server_name/WebApplication-1212.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

DeclarativeWorkflowsEnabled

Optional

System.Boolean

Sets whether declarative workflows are allowed to run in the Web application.

The type must be either 1 for True or 0 for False.

EmailNoPermissionParticipantsEnabled

Optional

System.Boolean

Sets whether workflows send task e-mail messages to users who do not have permissions to the site in which the workflows are running.

The type must be either 1 for True or 0 for False.

SendDocumentToExternalParticipants

Optional

System.Boolean

Sets whether workflows automatically send a copy of the document as an e-mail attachment to participants who do not have access to the site or who are not in any linked directory other than Active Directory Domain Services (AD DS).

The type must be either 1 for True or 0 for False.

2

Parameter

Required

Type

Description

SiteCollection

Required

Microsoft.SharePoint.PowerShell.SPSitePipeBind

Specifies the name or URL of the site collection.

The only other parameter that is used with the SiteCollection parameter is the DeclarativeWorkflowsEnabled parameter. No other parameters are used.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

DeclarativeWorkflowsEnabled

Optional

System.Boolean

Sets whether declarative workflows are allowed to run in the Web application.

The type must be either 1 for True or 0 for False.

EmailNoPermissionParticipantsEnabled

Optional

System.Boolean

Sets whether workflows send task e-mail messages to users who do not have permissions to the site in which the workflows are running.

The type must be either 1 for True or 0 for False.

SendDocumentToExternalParticipants

Optional

System.Boolean

Sets whether workflows automatically send a copy of the document as an e-mail attachment to participants who do not have access to the site or who are not in any linked directory other than Active Directory Domain Services (AD DS).

The type must be either 1 for True or 0 for False.

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

Use the Set-SPWorkflowConfig cmdlet to configure the workflow settings for the specified Web application.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Set-SPWorkflowConfig -webapplication http://sitename DeclarativeWorkflowsEnabled $true -EmailNoPermissionParticipantsEnabled $true -SendDocumentToExternalParticipants $false

This example sets the workflow settings for the specified Web application to turn on declarative workflows, turn on e-mail to participants who do not have permissions to the site, and turn off the functionality to send e-mail messages as attachments to external participants.

No return values. Use the Get-SPWorkflowConfig cmdlet to see values. To set farm-level workflow settings for event-delivery time-out and to postpone threshold and batch size, use Set-SPFarmConfig.

See Also

Reference

Get-SPWorkflowConfig


Get-SPDesignerSettings
See Also Example
[image]

Published: May 12, 2010

Displays Microsoft SharePoint Designer 2010 features.

Get-SPDesignerSettings [-WebApplication] <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>]

Parameters

Parameter Required Type Description

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the Web application in which the settings apply.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Detailed Description

The Get-SPDesignerSettings cmdlet determines whether SharePoint Designer 2010 features are enabled on the specified Web application.

Input Types

Return Types

Example

---------------------EXAMPLE------------------------

Copy Code
Get-SPDesignerSettings -webapplication http://contoso

This example retrieves the SharePoint Designer 2010 settings for the Web application, http://contoso.

See Also

Reference

Set-SPDesignerSettings


Set-SPDesignerSettings
See Also Example
[image]

Published: May 12, 2010

Sets Microsoft SharePoint Designer 2010 features.

Set-SPDesignerSettings [-WebApplication] <SPWebApplicationPipeBind> [-AllowDesigner <$true | $false>] [-AllowMasterPageEditing <$true | $false>] [-AllowRevertFromTemplate <$true | $false>] [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-ShowURLStructure <$true | $false>] [-WhatIf [<SwitchParameter>]]

Parameters

Parameter Required Type Description

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the Web application in which the settings will apply.

AllowDesigner

Optional

System.Boolean

Specifies whether to allow users to edit sites in a web application by using Microsoft SharePoint Designer 2010. The default value is True

AllowMasterPageEditing

Optional

System.Boolean

Specifies whether to allow site administrators to customize master pages and layout pages using Microsoft SharePoint Designer 2010. The default value is True.

AllowRevertFromTemplate

Optional

System.Boolean

Specifies whether to allow site administrators to detach pages from the original site definition using Microsoft SharePoint Designer 2010. The default value is True.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

ShowURLStructure

Optional

System.Boolean

Specifies whether to allow site administrators to manage the URL structure of their Web sites by using Microsoft SharePoint Designer 2010. The default value is True.

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

The Set-SPDesignerSettings cmdlet sets SharePoint Designer 2010 features on a specified Web application when the WebApplicaton is used.

Input Types

Return Types

Example

-------------------EXAMPLE--------------------

Copy Code
Set-SPDesignerSettings -WebApplication http://constoso -AllowRevertFromTemplate $False -AllowMasterPageEditing $False

This example disables the ability to detach pages from existing site definitions and to edit master pages and page layouts.

See Also

Reference

Get-SPDesignerSettings


Index of SharePoint Foundation 2010 Windows PowerShell cmdlets

This article contains lists of Windows PowerShell cmdlets that are included with Microsoft SharePoint Foundation 2010 in verb order and noun order.

In this article:

  • SharePoint Foundation 2010 cmdlets in verb order

  • SharePoint Foundation 2010 cmdlets in noun order

SharePoint Foundation 2010 cmdlets in verb order

Cmdlet name | Description
Add-SPClaimTypeMapping | Adds a claim mapping to a trusted security token service (STS) identity provider.
Add-SPDiagnosticsPerformanceCounter | Adds an instance of a performance counter.
Add-SPServiceApplicationProxyGroupMember | Adds a member to the service application proxy group.
Add-SPShellAdmin | Adds a user to the SharePoint_Shell_Access role for the specified database.
Add-SPSiteSubscriptionFeaturePackMember | Adds a feature to a SharePoint feature set.
Add-SPSolution | Uploads a SharePoint solution package to the farm.
Add-SPUserSolution | Uploads a new sandboxed solution to the solution gallery.
Backup-SPConfigurationDatabase | Performs a farm-level configuration-only backup.
Backup-SPFarm | Creates a backup of an individual database, Web application, or the entire farm.
Backup-SPSite | Performs a backup of a site collection.
Clear-SPLogLevel | Resets the Windows trace logging and event logging levels to their default values.
Clear-SPSiteSubscriptionBusinessDataCatalogConfig | Deletes all data from the Business Data Connectivity Metadata Store for a specified partition.
Connect-SPConfigurationDatabase | Connects the local server computer to a farm.
Copy-SPBusinessDataCatalogAclToChildren | Copies a set of permissions of a Business Data Connectivity Metadata Store metadata object to its child objects.
Disable-SPBusinessDataCatalogEntity | Deactivates an external content type in the Business Data Connectivity Metadata Store.
Disable-SPFeature | Disables an installed SharePoint feature at a given scope.
Disable-SPTimerJob | Disables a timer job.
Disable-SPWebApplicationHttpThrottling | Turns off network throttling for a Web application.
Disconnect-SPConfigurationDatabase | Disconnects the local server computer from the farm.
Dismount-SPContentDatabase | Detaches a content database from the Web application it is currently associated with.
Enable-SPBusinessDataCatalogEntity | Activates an external content type in the Business Data Connectivity Metadata Store.
Enable-SPFeature | Enables an installed SharePoint feature at the given scope.
Enable-SPTimerJob | Enables a timer job.
Enable-SPWebApplicationHttpThrottling | Turns on network throttling for a Web application.
Export-SPBusinessDataCatalogModel | Exports a Business Data Connectivity Model.
Export-SPSiteSubscriptionBusinessDataCatalogConfig | Exports all data from the Business Data Connectivity Metadata Store associated with a partition.
Export-SPSiteSubscriptionSettings | Creates a backup file of site subscription data.
Export-SPWeb | Exports a site collection, Web application, list, or library.
Get-SPAlternateURL | Returns all alternate URLs that match a given set of criteria.
Get-SPAuthenticationProvider | Returns an authentication provider.
Get-SPBackupHistory | Returns a history of backup and restore operations.
Get-SPBrowserCustomerExperienceImprovementProgram | Returns the current opt-in state for the browser Customer Experience Improvement Program.
Get-SPBusinessDataCatalogMetadataObject | Returns a Business Data Connectivity Metadata Store metadata object.
Get-SPBusinessDataCatalogThrottleConfig | Returns the throttling configuration for a Business Data Connectivity Service application.
Get-SPCertificateAuthority | Returns the SharePoint certificate authority (CA).
Get-SPClaimProvider | Returns a claim provider.
Get-SPClaimProviderManager | Returns a claim provider manager.
Get-SPContentDatabase | Returns one or more content databases.
Get-SPCustomLayoutsPage | Returns a mapping to a custom layout page.
Get-SPDatabase | Retrieves all properties of a database.
Get-SPDesignerSettings | Displays Microsoft SharePoint Designer 2010 features.
Get-SPDiagnosticConfig | Retrieves ULS diagnostic configuration values of the farm.
Get-SPDiagnosticsPerformanceCounter | Returns a collection of performance counters.
Get-SPDiagnosticsProvider | Returns a diagnostics provider.
Get-SPFarm | Returns the local SharePoint farm.
Get-SPFarmConfig | Returns a global property or a collection of global properties for the local farm.
Get-SPFeature | Returns the SharePoint features based on a given scope.
Get-SPHelpCollection | Returns Help collection files.
Get-SPLogEvent | Returns results from a Unified Logging Service (ULS) trace log.
Get-SPLogLevel | Returns a list of objects or diagnostic levels.
Get-SPManagedAccount | Retrieves accounts registered in the configuration database.
Get-SPManagedPath | Returns all managed paths that match the given criteria.
Get-SPMobileMessagingAccount | Retrieves mobile messaging accounts for the specified Web application.
Get-SPProcessAccount | Returns a system account or a managed account.
Get-SPProduct | Returns a list of the SharePoint-related products installed in the farm and the versions of all updates installed for each product.
Get-SPSearchService | Returns a search service.
Get-SPSearchServiceInstance | Returns an instance of a search service.
Get-SPSecurityTokenServiceConfig | Returns the security token service (STS) for the farm.
Get-SPServer | Returns the server or servers in the farm that match the given identity.
Get-SPServiceApplication | Returns the specified service application.
Get-SPServiceApplicationEndpoint | Returns the endpoint of a service application.
Get-SPServiceApplicationPool | Returns the specified Internet Information Services (IIS) application pool.
Get-SPServiceApplicationProxy | Returns an instance of the specified service application proxy.
Get-SPServiceApplicationProxyGroup | Returns the proxy group for the specified service application.
Get-SPServiceApplicationSecurity | Returns the SPObjectSecurity object for a service application.
Get-SPServiceContext | Returns a service context.
Get-SPServiceHostConfig | Returns the common Web service settings.
Get-SPServiceInstance | Returns the services instance for a specific server or the entire farm.
Get-SPShellAdmin | Returns the names of all users who have the SharePoint_Shell_Access role.
Get-SPSite | Returns all site collections that match the given criteria.
Get-SPSiteAdministration | Returns a site administration object that farm administrators can use to view certain information about site collections to which they might not have access.
Get-SPSiteSubscription | Returns the site subscription for the given URL or all site subscriptions in the local farm.
Get-SPSiteSubscriptionConfig | Returns the configuration properties of a site subscription.
Get-SPSiteSubscriptionFeaturePack | Retrieves available SharePoint feature sets or the Feature set assigned to a given site subscription.
Get-SPSolution | Returns a specified SharePoint solution.
Get-SPTimerJob | Returns timer jobs.
Get-SPTopologyServiceApplication | Displays properties of the topology service application for the current farm.
Get-SPTopologyServiceApplicationProxy | Retrieves the topology service application proxy.
Get-SPTrustedIdentityTokenIssuer | Returns an identity provider.
Get-SPTrustedRootAuthority | Returns a trusted root authority.
Get-SPTrustedServiceTokenIssuer | Returns the object that represents the farm trust.
Get-SPUsageApplication | Returns a specified usage application.
Get-SPUsageDefinition | Returns a usage definition object.
Get-SPUsageService | Returns a usage service.
Get-SPUser | Returns the user account or accounts that match a given search criteria.
Get-SPUserSolution | Returns a specified sandboxed solution.
Get-SPWeb | Returns all subsites that match the given criteria.
Get-SPWebApplication | Returns all Web applications that match the given criteria.
Get-SPWebApplicationHttpThrottlingMonitor | Reads all counters for network throttling on a Web application.
Get-SPWebPartPack | Returns the Web Part packages that were installed for the specified scope.
Get-SPWebTemplate | Displays all globally installed site templates that match the given identity.
Get-SPWorkflowConfig | Returns workflow settings for the specified Web application.
Grant-SPBusinessDataCatalogMetadataObject | Grants a right to a principal for the specified Business Data Connectivity Metadata Store metadata object.
Grant-SPObjectSecurity | Adds a new security principal to an SPObjectSecurity object.
Grant-SPServiceApplication | Grants a user account access to the service application.
Import-SPBusinessDataCatalogDotNetAssembly | Imports data that is associated with the Business Data Connectivity Metadata Store for a partition.
Import-SPBusinessDataCatalogModel | Imports a Business Data Connectivity Model.
Import-SPSiteSubscriptionSettings | Restores a backup of subscription site settings to the given subscription identifier.
Import-SPWeb | Imports a site collection, Web application, list, or library.
Initialize-SPResourceSecurity | Enforces resource security on the local server.
Install-SPApplicationContent | Copies shared application data to existing Web application folders.
Install-SPFeature | Installs a SharePoint feature by using the Feature.xml file.
Install-SPHelpCollection | Installs the provided Help site collection files in the current farm.
Install-SPService | Installs and provisions services on a farm.
Install-SPSolution | Deploys an installed SharePoint solution in the farm.
Install-SPUserSolution | Activates a sandboxed solution in a site collection.
Install-SPWebPartPack | Installs the specified Web Part package to the specified location.
Install-SPWebTemplate | Installs the given site template.
Merge-SPLogFile | Combines trace log entries from all farm computers into a single log file on the local computer.
Mount-SPContentDatabase | Attaches an existing content database to the farm.
Move-SPBlobStorageLocation | Copies a Windows SharePoint Services 3.0 database by using Remote BLOB Storage (RBS).
Move-SPSite | Moves site collections from one content database to another.
Move-SPUser | Migrates a user account in SharePoint 2010 Products.
New-SPAlternateUrl | Creates a new public or internal URL for the specified Web application zone or resource.
New-SPAuthenticationProvider | Creates a new authentication provider in the farm.
New-SPBusinessDataCatalogServiceApplication | Creates a new Business Data Connectivity service application in the farm.
New-SPBusinessDataCatalogServiceApplicationProxy | Creates a new Business Data Connectivity service application proxy in the farm.
New-SPCentralAdministration | Creates a new SharePoint Central Administration Web application.
New-SPClaimProvider | Registers a new claim provider in the farm.
New-SPClaimsPrincipal | Creates a new claims principal.
New-SPClaimTypeMapping | Creates a claim mapping rule for a security token service (STS) identity provider.
New-SPConfigurationDatabase | Creates a new configuration database.
New-SPContentDatabase | Creates a new content database and attaches it to the specified Web application.
New-SPLogFile | Creates a new log file.
New-SPManagedAccount | Registers a new managed account.
New-SPManagedPath | Creates a new managed path for the given Web application for all host header site collections.
New-SPServiceApplicationPool | Creates a new Web service application pool.
New-SPServiceApplicationProxyGroup | Creates a new service application proxy group.
New-SPSite | Creates a new site collection at the specified URL.
New-SPSiteSubscription | Creates a new site subscription.
New-SPSiteSubscriptionFeaturePack | Creates a new SharePoint feature set that can be used to limit the features available to a site subscription.
New-SPSubscriptionSettingsServiceApplication | Creates a new subscription settings service application.
New-SPSubscriptionSettingsServiceApplicationProxy | Creates an application proxy to a subscription settings service application.
New-SPTrustedIdentityTokenIssuer | Creates an identity provider in the farm.
New-SPTrustedRootAuthority | Creates a trusted root authority.
New-SPTrustedServiceTokenIssuer | Creates a trust with a SharePoint farm.
New-SPUsageApplication | Creates a new usage application.
New-SPUsageLogFile | Starts a new usage log file on the current server computer.
New-SPUser | Adds an existing user to a SharePoint site with the designated permissions.
New-SPWeb | Creates a new site in an existing site collection.
New-SPWebApplication | Creates a new Web application within the local farm.
New-SPWebApplicationExtension | Creates a new zone instance for the Web application.
Publish-SPServiceApplication | Shares the specified local service application outside the farm.
Receive-SPSharedServiceApplicationInfo | Configures this farm to receive service information from another farm.
Remove-SPAlternateUrl | Completely deletes the specified alternate URL.
Remove-SPBusinessDataCatalogModel | Deletes a Business Data Connectivity Model.
Remove-SPClaimProvider | Unregisters a claim provider.
Remove-SPClaimTypeMapping | Deletes a claim type mapping rule for a security token service (STS) identity provider.
Remove-SPConfigurationDatabase | Permanently removes a configuration database.
Remove-SPContentDatabase | Deletes a content database.
Remove-SPDiagnosticsPerformanceCounter | Removes an instance of a performance counter.
Remove-SPManagedAccount | Removes a managed account registration from the farm.
Remove-SPManagedPath | Deletes the specified managed path from the specified host header or Web application.
Remove-SPServiceApplication | Deletes the specified service application on the local server.
Remove-SPServiceApplicationPool | Completely deletes the specified Web service application pool.
Remove-SPServiceApplicationProxy | Deletes the specified service application proxy.
Remove-SPServiceApplicationProxyGroup | Completely deletes the specified service application proxy group.
Remove-SPServiceApplicationProxyGroupMember | Removes one or more proxies from the specified service application proxy group.
Remove-SPShellAdmin | Removes a user from the SharePoint_Shell_Access role.
Remove-SPSite | Completely deletes an existing site collection and all subsites.
Remove-SPSiteSubscription | Removes data stored in a subscription settings service application for a set of site subscriptions.
Remove-SPSiteSubscriptionBusinessDataCatalogConfig | Removes the Business Data Connectivity Metadata Store for a partition.
Remove-SPSiteSubscriptionFeaturePack | Removes a SharePoint feature set from a site subscription.
Remove-SPSiteSubscriptionFeaturePackMember | Removes a feature definition from the provided SharePoint feature set.
Remove-SPSiteSubscriptionSettings | Removes the settings service data for a specified site subscription, or finds and removes orphaned data.
Remove-SPSolution | Removes a SharePoint solution from a farm.
Remove-SPSolutionDeploymentLock | Removes the solution deployment lock for a server.
Remove-SPTrustedIdentityTokenIssuer | Deletes a security token service (STS) identity provider from the farm.
Remove-SPTrustedRootAuthority | Deletes a trusted root authority.
Remove-SPTrustedServiceTokenIssuer | Deletes the object that represents the farm trust.
Remove-SPUsageApplication | Removes a usage application from the local farm.
Remove-SPUser | Removes a user from a Web site.
Remove-SPUserSolution | Removes a sandboxed solution from the solution gallery.
Remove-SPWeb | Completely deletes the specified Web.
Remove-SPWebApplication | Deletes the specified Web application.
Rename-SPServer | Renames a server that is currently connected to the farm.
Repair-SPManagedAccountDeployment | Repairs the local managed account credential deployment.
Restore-SPFarm | Restores one or more items from a backup.
Restore-SPSite | Restores a site collection.
Revoke-SPBusinessDataCatalogMetadataObject | Revokes a right to a principal in the specified Business Data Connectivity Metadata Store metadata object.
Revoke-SPObjectSecurity | Removes a security principal from a SPObjectSecurity object.
Revoke-SPServiceApplication | Revokes a user's access to a service application.
Set-SPAlternateUrl | Configures the specified alternate URL.
Set-SPBrowserCustomerExperienceImprovementProgram | Turns on or off the browser Customer Experience Improvement Program.
Set-SPBusinessDataCatalogMetadataObject | Sets the value of a property or attribute of a Business Data Connectivity Metadata Store metadata object.
Set-SPBusinessDataCatalogServiceApplication | Sets global properties for a Business Data Connectivity service application in the farm.
Set-SPBusinessDataCatalogThrottleConfig | Sets the throttling configuration for a Business Data Connectivity Service application.
Set-SPCentralAdministration | Sets the port for the SharePoint Central Administration Web site.
Set-SPClaimProvider | Updates registration of a claims provider.
Set-SPContentDatabase | Sets global properties of a SharePoint content database.
Set-SPCustomLayoutsPage | Maps a new path for a custom layout page.
Set-SPDesignerSettings | Sets Microsoft SharePoint Designer 2010 features.
Set-SPDiagnosticConfig | Sets diagnostic configuration settings on the farm.
Set-SPDiagnosticsProvider | Enables a diagnostics provider and updates its retention policy.
Set-SPFarmConfig | Sets a global property or a collection of global properties for the local farm.
Set-SPLogLevel | Sets the trace and event level for a set of categories.
Set-SPManagedAccount | Configures the managed account.
Set-SPMobileMessagingAccount | Configures the specified mobile messaging account.
Set-SPPassPhrase | Sets the passphrase to a new value.
Set-SPSearchService | Sets properties of a search service.
Set-SPSearchServiceInstance | Sets properties of a search service instance.
Set-SPSecurityTokenServiceConfig | Updates the settings of the SharePoint security token service (STS) identity provider.
Set-SPServiceApplication | Sets properties of a service application.
Set-SPServiceApplicationEndpoint | Sets the host of an endpoint for a service application.
Set-SPServiceApplicationPool | Changes the account used for the Identity of the specified application pool.
Set-SPServiceApplicationSecurity | Updates the SPObjectSecurity object for a service application.
Set-SPServiceHostConfig | Configures one or more common settings for all Web services.
Set-SPSite | Configures the specified site collection.
Set-SPSiteAdministration | Allows farm administrators to configure any site collection.
Set-SPSiteSubscriptionConfig | Sets the configuration properties of a site subscription.
Set-SPSubscriptionSettingsServiceApplication | Sets properties of a subscription settings service application.
Set-SPTimerJob | Sets the schedule for running a timer job.
Set-SPTopologyServiceApplication | Sets the properties on the topology service application of the local farm.
Set-SPTopologyServiceApplicationProxy | Sets the proxy properties of the topology service application.
Set-SPTrustedIdentityTokenIssuer | Sets the identity providers of a Web application.
Set-SPTrustedRootAuthority | Creates a new trusted root authority.
Set-SPTrustedServiceTokenIssuer | Updates a trust with the farm.
Set-SPUsageApplication | Sets properties of a usage application.
Set-SPUsageDefinition | Sets the retention period for a usage provider.
Set-SPUsageService | Sets the properties of a usage service.
Set-SPUser | Configures properties on an existing user.
Set-SPWeb | Configures the specified subsite.
Set-SPWebApplication | Configures the specified Web application.
Set-SPWebApplicationHttpThrottlingMonitor | Sets the Health Score bucket values for an existing network throttling performance counter for a specified Web application.
Set-SPWebTemplate | Changes the title and description of an installed site template.
Set-SPWorkflowConfig | Configures the workflow settings for the specified Web application.
Start-SPAdminJob | Immediately starts any waiting administrative job on the local computer.
Start-SPAssignment | Initiates a new assignment store.
Start-SPServiceInstance | Starts the service instance for a service on a specific server or the farm.
Start-SPTimerJob | Runs a timer job once.
Stop-SPAssignment | Disposes of objects in the provided assignment collection.
Stop-SPServiceInstance | Stops the service instance for a service.
Test-SPContentDatabase | Tests a content database.
Uninstall-SPFeature | Uninstalls an installed feature definition.
Uninstall-SPHelpCollection | Removes Help collection files.
Uninstall-SPSolution | Retracts a deployed SharePoint solution.
Uninstall-SPUserSolution | Deactivates a sandboxed solution in a site collection.
Uninstall-SPWebPartPack | Uninstalls the specified Web Part package.
Uninstall-SPWebTemplate | Uninstalls the given site template.
Unpublish-SPServiceApplication | Stops sharing the specified service application outside the farm.
Update-SPFarmEncryptionKey | Changes the value of the farm encryption key and, using the new key, re-encrypts all the data.
Update-SPInfoPathUrl | Runs a Microsoft InfoPath 2010 .xsn/.udc fix-up on SharePoint Foundation 2010.
Update-SPSolution | Upgrades a deployed SharePoint solution.
Update-SPUserSolution | Upgrades an activated sandboxed solution in a farm.
Upgrade-SPContentDatabase | Upgrades a content database.

SharePoint Foundation 2010 cmdlets in noun order

Cmdlet name | Description
Start-SPAdminJob | Immediately starts any waiting administrative job on the local computer.
Get-SPAlternateURL | Returns all alternate URLs that match a given set of criteria.
New-SPAlternateUrl | Creates a new public or internal URL for the specified Web application zone or resource.
Remove-SPAlternateUrl | Completely deletes the specified alternate URL.
Set-SPAlternateUrl | Configures the specified alternate URL.
Install-SPApplicationContent | Copies shared application data to existing Web application folders.
Start-SPAssignment | Initiates a new assignment store.
Stop-SPAssignment | Disposes of objects in the provided assignment collection.
Get-SPAuthenticationProvider | Returns an authentication provider.
New-SPAuthenticationProvider | Creates a new authentication provider in the farm.
Get-SPBackupHistory | Returns a history of backup and restore operations.
Move-SPBlobStorageLocation | Copies a Windows SharePoint Services 3.0 database by using Remote BLOB Storage (RBS).
Get-SPBrowserCustomerExperienceImprovementProgram | Returns the current opt-in state for the browser Customer Experience Improvement Program.
Set-SPBrowserCustomerExperienceImprovementProgram | Turns on or off the browser Customer Experience Improvement Program.
Copy-SPBusinessDataCatalogAclToChildren | Copies a set of permissions of a Business Data Connectivity Metadata Store metadata object to its child objects.
Import-SPBusinessDataCatalogDotNetAssembly | Imports data that is associated with the Business Data Connectivity Metadata Store for a partition.
Disable-SPBusinessDataCatalogEntity | Deactivates an external content type in the Business Data Connectivity Metadata Store.
Enable-SPBusinessDataCatalogEntity | Activates an external content type in the Business Data Connectivity Metadata Store.
Get-SPBusinessDataCatalogMetadataObject | Returns a Business Data Connectivity Metadata Store metadata object.
Grant-SPBusinessDataCatalogMetadataObject | Grants a right to a principal for the specified Business Data Connectivity Metadata Store metadata object.
Revoke-SPBusinessDataCatalogMetadataObject | Revokes a right to a principal in the specified Business Data Connectivity Metadata Store metadata object.
Set-SPBusinessDataCatalogMetadataObject | Sets the value of a property or attribute of a Business Data Connectivity Metadata Store metadata object.
Export-SPBusinessDataCatalogModel | Exports a Business Data Connectivity Model.
Import-SPBusinessDataCatalogModel | Imports a Business Data Connectivity Model.
Remove-SPBusinessDataCatalogModel | Deletes a Business Data Connectivity Model.
New-SPBusinessDataCatalogServiceApplication | Creates a new Business Data Connectivity service application in the farm.
Set-SPBusinessDataCatalogServiceApplication | Sets global properties for a Business Data Connectivity service application in the farm.
New-SPBusinessDataCatalogServiceApplicationProxy | Creates a new Business Data Connectivity service application proxy in the farm.
Get-SPBusinessDataCatalogThrottleConfig | Returns the throttling configuration for a Business Data Connectivity Service application.
Set-SPBusinessDataCatalogThrottleConfig | Sets the throttling configuration for a Business Data Connectivity Service application.
New-SPCentralAdministration | Creates a new SharePoint Central Administration Web application.
Set-SPCentralAdministration | Sets the port for the SharePoint Central Administration Web site.
Get-SPCertificateAuthority | Returns the SharePoint certificate authority (CA).
Get-SPClaimProvider | Returns a claim provider.
New-SPClaimProvider | Registers a new claim provider in the farm.
Remove-SPClaimProvider | Unregisters a claim provider.
Set-SPClaimProvider | Updates registration of a claims provider.
Get-SPClaimProviderManager | Returns a claim provider manager.
New-SPClaimsPrincipal | Creates a new claims principal.
Add-SPClaimTypeMapping | Adds a claim mapping to a trusted security token service (STS) identity provider.
New-SPClaimTypeMapping | Creates a claim mapping rule for a security token service (STS) identity provider.
Remove-SPClaimTypeMapping | Deletes a claim type mapping rule for a security token service (STS) identity provider.
Backup-SPConfigurationDatabase | Performs a farm-level configuration-only backup.
Connect-SPConfigurationDatabase | Connects the local server computer to a farm.
Disconnect-SPConfigurationDatabase | Disconnects the local server computer from the farm.
New-SPConfigurationDatabase | Creates a new configuration database.
Remove-SPConfigurationDatabase | Permanently removes a configuration database.
Dismount-SPContentDatabase | Detaches a content database from the Web application it is currently associated with.
Get-SPContentDatabase | Returns one or more content databases.
Mount-SPContentDatabase | Attaches an existing content database to the farm.
New-SPContentDatabase | Creates a new content database and attaches it to the specified Web application.
Remove-SPContentDatabase | Deletes a content database.
Set-SPContentDatabase | Sets global properties of a SharePoint content database.
Test-SPContentDatabase | Tests a content database.
Upgrade-SPContentDatabase | Upgrades a content database.
Get-SPCustomLayoutsPage | Returns a mapping to a custom layout page.
Set-SPCustomLayoutsPage | Maps a new path for a custom layout page.
Get-SPDatabase | Retrieves all properties of a database.
Get-SPDesignerSettings | Displays Microsoft SharePoint Designer 2010 features.
Set-SPDesignerSettings | Sets Microsoft SharePoint Designer 2010 features.
Get-SPDiagnosticConfig | Retrieves ULS diagnostic configuration values of the farm.
Set-SPDiagnosticConfig | Sets diagnostic configuration settings on the farm.
Add-SPDiagnosticsPerformanceCounter | Adds an instance of a performance counter.
Get-SPDiagnosticsPerformanceCounter | Returns a collection of performance counters.
Remove-SPDiagnosticsPerformanceCounter | Removes an instance of a performance counter.
Get-SPDiagnosticsProvider | Returns a diagnostics provider.
Set-SPDiagnosticsProvider | Enables a diagnostics provider and updates its retention policy.
Backup-SPFarm | Creates a backup of an individual database, Web application, or the entire farm.
Get-SPFarm | Returns the local SharePoint farm.
Restore-SPFarm | Restores one or more items from a backup.
Get-SPFarmConfig | Returns a global property or a collection of global properties for the local farm.
Set-SPFarmConfig | Sets a global property or a collection of global properties for the local farm.
Update-SPFarmEncryptionKey | Changes the value of the farm encryption key and, using the new key, re-encrypts all the data.
Disable-SPFeature | Disables an installed SharePoint feature at a given scope.
Enable-SPFeature | Enables an installed SharePoint feature at the given scope.
Get-SPFeature | Returns the SharePoint features based on a given scope.
Install-SPFeature | Installs a SharePoint feature by using the Feature.xml file.
Uninstall-SPFeature | Uninstalls an installed feature definition.
Get-SPHelpCollection | Returns Help collection files.
Install-SPHelpCollection | Installs the provided Help site collection files in the current farm.
Uninstall-SPHelpCollection | Removes Help collection files.
Update-SPInfoPathUrl | Runs a Microsoft InfoPath 2010 .xsn/.udc fix-up on SharePoint Foundation 2010.
Get-SPLogEvent | Returns results from a Unified Logging Service (ULS) trace log.
Merge-SPLogFile | Combines trace log entries from all farm computers into a single log file on the local computer.
New-SPLogFile | Creates a new log file.
Clear-SPLogLevel | Resets the Windows trace logging and event logging levels to their default values.
Get-SPLogLevel | Returns a list of objects or diagnostic levels.
Set-SPLogLevel | Sets the trace and event level for a set of categories.
Get-SPManagedAccount | Retrieves accounts registered in the configuration database.
New-SPManagedAccount | Registers a new managed account.
Remove-SPManagedAccount | Removes a managed account registration from the farm.
Set-SPManagedAccount | Configures the managed account.
Repair-SPManagedAccountDeployment | Repairs the local managed account credential deployment.
Get-SPManagedPath | Returns all managed paths that match the given criteria.
New-SPManagedPath | Creates a new managed path for the given Web application for all host header site collections.
Remove-SPManagedPath | Deletes the specified managed path from the specified host header or Web application.
Get-SPMobileMessagingAccount | Retrieves mobile messaging accounts for the specified Web application.
Set-SPMobileMessagingAccount | Configures the specified mobile messaging account.
Grant-SPObjectSecurity | Adds a new security principal to an SPObjectSecurity object.
Revoke-SPObjectSecurity | Removes a security principal from a SPObjectSecurity object.
Set-SPPassPhrase | Sets the passphrase to a new value.
Get-SPProcessAccount | Returns a system account or a managed account.
Get-SPProduct | Returns a list of the SharePoint-related products installed in the farm and the versions of all updates installed for each product.
Initialize-SPResourceSecurity | Enforces resource security on the local server.
Get-SPSearchService | Returns a search service.
Set-SPSearchService | Sets properties of a search service.
Get-SPSearchServiceInstance | Returns an instance of a search service.
Set-SPSearchServiceInstance | Sets properties of a search service instance.
Get-SPSecurityTokenServiceConfig | Returns the security token service (STS) for the farm.
Set-SPSecurityTokenServiceConfig | Updates the settings of the SharePoint security token service (STS) identity provider.
Get-SPServer | Returns the server or servers in the farm that match the given identity.
Rename-SPServer | Renames a server that is currently connected to the farm.
Install-SPService | Installs and provisions services on a farm.
Get-SPServiceApplication | Returns the specified service application.
Grant-SPServiceApplication | Grants a user account access to the service application.
Publish-SPServiceApplication | Shares the specified local service application outside the farm.
Remove-SPServiceApplication | Deletes the specified service application on the local server.
Revoke-SPServiceApplication | Revokes a user's access to a service application.
Set-SPServiceApplication | Sets properties of a service application.
Unpublish-SPServiceApplication | Stops sharing the specified service application outside the farm.
Get-SPServiceApplicationEndpoint | Returns the endpoint of a service application.
Set-SPServiceApplicationEndpoint | Sets the host of an endpoint for a service application.
Get-SPServiceApplicationPool | Returns the specified Internet Information Services (IIS) application pool.
New-SPServiceApplicationPool | Creates a new Web service application pool.
Remove-SPServiceApplicationPool | Completely deletes the specified Web service application pool.
Set-SPServiceApplicationPool | Changes the account used for the Identity of the specified application pool.
Get-SPServiceApplicationProxy | Returns an instance of the specified service application proxy.
Remove-SPServiceApplicationProxy | Deletes the specified service application proxy.
Get-SPServiceApplicationProxyGroup | Returns the proxy group for the specified service application.
New-SPServiceApplicationProxyGroup | Creates a new service application proxy group.
Remove-SPServiceApplicationProxyGroup | Completely deletes the specified service application proxy group.
Add-SPServiceApplicationProxyGroupMember | Adds a member to the service application proxy group.
Remove-SPServiceApplicationProxyGroupMember | Removes one or more proxies from the specified service application proxy group.
Get-SPServiceApplicationSecurity | Returns the SPObjectSecurity object for a service application.
Set-SPServiceApplicationSecurity | Updates the SPObjectSecurity object for a service application.
Get-SPServiceContext | Returns a service context.
Get-SPServiceHostConfig | Returns the common Web service settings.
Set-SPServiceHostConfig | Configures one or more common settings for all Web services.
Get-SPServiceInstance | Returns the services instance for a specific server or the entire farm.
Start-SPServiceInstance | Starts the service instance for a service on a specific server or the farm.
Stop-SPServiceInstance | Stops the service instance for a service.
Receive-SPSharedServiceApplicationInfo | Configures this farm to receive service information from another farm.
Add-SPShellAdmin | Adds a user to the SharePoint_Shell_Access role for the specified database.
Get-SPShellAdmin | Returns the names of all users who have the SharePoint_Shell_Access role.
Remove-SPShellAdmin | Removes a user from the SharePoint_Shell_Access role.
Backup-SPSite | Performs a backup of a site collection.
Get-SPSite | Returns all site collections that match the given criteria.
Move-SPSite | Moves site collections from one content database to another.
New-SPSite | Creates a new site collection at the specified URL.
Remove-SPSite | Completely deletes an existing site collection and all subsites.
Restore-SPSite | Restores a site collection.
Set-SPSite | Configures the specified site collection.
Get-SPSiteAdministration | Returns a site administration object that farm administrators can use to view certain information about site collections to which they might not have access.
Set-SPSiteAdministration | Allows farm administrators to configure any site collection.
Get-SPSiteSubscription | Returns the site subscription for the given URL or all site subscriptions in the local farm.
New-SPSiteSubscription | Creates a new site subscription.
Remove-SPSiteSubscription | Removes data stored in a subscription settings service application for a set of site subscriptions.
Clear-SPSiteSubscriptionBusinessDataCatalogConfig | Deletes all data from the Business Data Connectivity Metadata Store for a specified partition.
Export-SPSiteSubscriptionBusinessDataCatalogConfig | Exports all data from the Business Data Connectivity Metadata Store associated with a partition.
Remove-SPSiteSubscriptionBusinessDataCatalogConfig | Removes the Business Data Connectivity Metadata Store for a partition.
Get-SPSiteSubscriptionConfig | Returns the configuration properties of a site subscription.
Set-SPSiteSubscriptionConfig | Sets the configuration properties of a site subscription.
Get-SPSiteSubscriptionFeaturePack | Retrieves available SharePoint feature sets or the Feature set assigned to a given site subscription.
New-SPSiteSubscriptionFeaturePack | Creates a new SharePoint feature set that can be used to limit the features available to a site subscription.
Remove-SPSiteSubscriptionFeaturePack | Removes a SharePoint feature set from a site subscription.
Add-SPSiteSubscriptionFeaturePackMember | Adds a feature to a SharePoint feature set.
Remove-SPSiteSubscriptionFeaturePackMember | Removes a feature definition from the provided SharePoint feature set.
Export-SPSiteSubscriptionSettings | Creates a backup file of site subscription data.
Import-SPSiteSubscriptionSettings | Restores a backup of subscription site settings to the given subscription identifier.
Remove-SPSiteSubscriptionSettings | Removes the settings service data for a specified site subscription, or finds and removes orphaned data.
Add-SPSolution | Uploads a SharePoint solution package to the farm.
Get-SPSolution | Returns a specified SharePoint solution.
Install-SPSolution | Deploys an installed SharePoint solution in the farm.
Remove-SPSolution | Removes a SharePoint solution from a farm.
Uninstall-SPSolution | Retracts a deployed SharePoint solution.
Update-SPSolution | Upgrades a deployed SharePoint solution.
Remove-SPSolutionDeploymentLock | Removes the solution deployment lock for a server.
New-SPSubscriptionSettingsServiceApplication | Creates a new subscription settings service application.
Set-SPSubscriptionSettingsServiceApplication | Sets properties of a subscription settings service application.
New-SPSubscriptionSettingsServiceApplicationProxy | Creates an application proxy to a subscription settings service application.
Disable-SPTimerJob | Disables a timer job.
Enable-SPTimerJob | Enables a timer job.
Get-SPTimerJob | Returns timer jobs.
Set-SPTimerJob | Sets the schedule for running a timer job.
Start-SPTimerJob | Runs a timer job once.
Get-SPTopologyServiceApplication | Displays properties of the topology service application for the current farm.
Set-SPTopologyServiceApplication | Sets the properties on the topology service application of the local farm.
Get-SPTopologyServiceApplicationProxy | Retrieves the topology service application proxy.
Set-SPTopologyServiceApplicationProxy | Sets the proxy properties of the topology service application.
Get-SPTrustedIdentityTokenIssuer | Returns an identity provider.
New-SPTrustedIdentityTokenIssuer | Creates an identity provider in the farm.
Remove-SPTrustedIdentityTokenIssuer | Deletes a security token service (STS) identity provider from the farm.
Set-SPTrustedIdentityTokenIssuer | Sets the identity providers of a Web application.
Get-SPTrustedRootAuthority | Returns a trusted root authority.
New-SPTrustedRootAuthority | Creates a trusted root authority.
Remove-SPTrustedRootAuthority | Deletes a trusted root authority.
Set-SPTrustedRootAuthority | Creates a new trusted root authority.
Get-SPTrustedServiceTokenIssuer | Returns the object that represents the farm trust.
New-SPTrustedServiceTokenIssuer | Creates a trust with a SharePoint farm.
Remove-SPTrustedServiceTokenIssuer | Deletes the object that represents the farm trust.
Set-SPTrustedServiceTokenIssuer | Updates a trust with the farm.
Get-SPUsageApplication | Returns a specified usage application.
New-SPUsageApplication | Creates a new usage application.
Remove-SPUsageApplication | Removes a usage application from the local farm.
Set-SPUsageApplication | Sets properties of a usage application.
Get-SPUsageDefinition | Returns a usage definition object.
Set-SPUsageDefinition | Sets the retention period for a usage provider.
New-SPUsageLogFile | Starts a new usage log file on the current server computer.
Get-SPUsageService | Returns a usage service.
Set-SPUsageService | Sets the properties of a usage service.
Get-SPUser | Returns the user account or accounts that match a given search criteria.
Move-SPUser | Migrates a user account in SharePoint 2010 Products.
New-SPUser | Adds an existing user to a SharePoint site with the designated permissions.
Remove-SPUser | Removes a user from a Web site.
Set-SPUser | Configures properties on an existing user.
Add-SPUserSolution | Uploads a new sandboxed solution to the solution gallery.
Get-SPUserSolution | Returns a specified sandboxed solution.
Install-SPUserSolution | Activates a sandboxed solution in a site collection.
Remove-SPUserSolution | Removes a sandboxed solution from the solution gallery.
Uninstall-SPUserSolution | Deactivates a sandboxed solution in a site collection.
Update-SPUserSolution | Upgrades an activated sandboxed solution in a farm.
Export-SPWeb | Exports a site collection, Web application, list, or library.
Get-SPWeb | Returns all subsites that match the given criteria.
Import-SPWeb | Imports a site collection, Web application, list, or library.
New-SPWeb | Creates a new site in an existing site collection.
Remove-SPWeb | Completely deletes the specified Web.
Set-SPWeb | Configures the specified subsite.
Get-SPWebApplication | Returns all Web applications that match the given criteria.
New-SPWebApplication | Creates a new Web application within the local farm.
Remove-SPWebApplication | Deletes the specified Web application.
Set-SPWebApplication | Configures the specified Web application.
New-SPWebApplicationExtension | Creates a new zone instance for the Web application.
Disable-SPWebApplicationHttpThrottling | Turns off network throttling for a Web application.
Enable-SPWebApplicationHttpThrottling | Turns on network throttling for a Web application.
Get-SPWebApplicationHttpThrottlingMonitor | Reads all counters for network throttling on a Web application.
Set-SPWebApplicationHttpThrottlingMonitor | Sets the Health Score bucket values for an existing network throttling performance counter for a specified Web application.
Get-SPWebPartPack | Returns the Web Part packages that were installed for the specified scope.
Install-SPWebPartPack | Installs the specified Web Part package to the specified location.
Uninstall-SPWebPartPack | Uninstalls the specified Web Part package.
Get-SPWebTemplate | Displays all globally installed site templates that match the given identity.
Install-SPWebTemplate | Installs the given site template.
Set-SPWebTemplate | Changes the title and description of an installed site template.
Uninstall-SPWebTemplate | Uninstalls the given site template.
Get-SPWorkflowConfig | Returns workflow settings for the specified Web application.
Set-SPWorkflowConfig | Configures the workflow settings for the specified Web application.


Updates to Windows PowerShell cmdlets (SharePoint Foundation 2010)

This article lists the Windows PowerShell cmdlets that have been changed — or are no longer available — since the Beta release of Microsoft SharePoint Foundation 2010.

Beta version | Released version
Get-SPIisWebServiceApplicationPool | Get-SPServiceApplicationPool
New-SPIisWebServiceApplicationPool | New-SPServiceApplicationPool
Remove-SPIisWebServiceApplicationPool | Remove-SPServiceApplicationPool
Set-SPIisWebServiceApplicationPool | Set-SPServiceApplicationPool
Get-SPSecurityTokenServiceManager | Get-SPSecurityTokenServiceConfig
Set-SPSecurityTokenServiceManager | Set-SPSecurityTokenServiceConfig
Get-SPServiceEndpoint | Get-SPServiceApplicationEndpoint
Set-SPServiceEndpoint | Set-SPServiceApplicationEndpoint
Get-SPIisWebServiceSettings | Get-SPServiceHostConfig
Set-SPIisWebServiceSettings | Set-SPServiceHostConfig
Get-SPTopologyWebServiceApplication | Get-SPTopologyServiceApplication
Set-SPTopologyWebServiceApplication | Set-SPTopologyServiceApplication
Get-SPTopologyWebServiceProxy | Get-SPTopologyServiceApplicationProxy
Set-SPTopologyWebServiceProxy | Set-SPTopologyServiceApplicationProxy
Remove-SPBusinessDataCatalogThrottleConfig | This cmdlet is no longer available.
Get-SPSecurityTokenService | Get-SPSecurityTokenServiceConfig
Set-SPSecurityTokenService | Set-SPSecurityTokenServiceConfig
Install-SPWebTemplate | This cmdlet is no longer available.


Stsadm to Windows PowerShell mapping (SharePoint Foundation 2010)
See Also

This article lists Stsadm operations and their equivalent Windows PowerShell cmdlets. Where there is no one-to-one mapping between the operations and cmdlets, the table lists the specific Windows PowerShell parameters you must use to get the same functionality.

Stsadm operation

Windows PowerShell cmdlet

Activatefeature

Enable-SPFeature

Addalternatedomain

New-SPAlternateUrl

Addcontentdb

Mount-SPContentDatabase

New-SPContentDatabase

Addpath

New-SPManagedPath

Addpermissionpolicy

None

Addsolution

Add-SPSolution

Addtemplate

Install-SPWebTemplate

Adduser

New-SPUser

Addwppack

Install-SPWebPartPack

Addzoneurl

New-SPAlternateUrl

Authentication

Set-SPWebApplication

Use the AuthenticationMethod or AuthenticationProvider parameters.

Backup

Backup-SPConfigurationDatabase

Backup-SPFarm

Backup-SPSite

Backuphistory

Get-SPBackupHistory

Binddrservice

None

Blockedfilelist

None

Canceldeployment

None

Changepermissionpolicy

None

Copyappbincontent

None

Createadminvs

New-SPCentralAdministration

Creategroup

None

Createsite

New-SPSite

Createsiteinnewdb

New-SPSite Use the ContentDatabase parameter.

New-SPContentDatabase

Createweb

New-SPWeb

Databaserepair

None

Deactivatefeature

Disable-SPFeature

Deleteadminvs

None

Deletealternatedomain

Remove-SPAlternateUrl

Deleteconfigdb

Remove-SPConfigurationDatabase

Deletecontentdb

Dismount-SPContentDatabase

Deletegroup

None

Deletepath

Remove-SPManagedPath

Deletepermissionpolicy

None

Deletesite

Remove-SPSite

Deletesolution

Remove-SPSolution

Deletetemplate

Uninstall-SPWebTemplate

Deleteuser

Remove-SPUser

Deleteweb

Remove-SPWeb

Deletewppack

Uninstall-SPWebPartPack

Deletezoneurl

Remove-SPAlternateUrl

Deploysolution

Install-SPSolution

Deploywppack

Install-SPWebPartPack

Disablessc

None

Displaysolution

Get-SPSolution

Email

None

Enablessc

None

Enumalternatedomains

Get-SPAlternateURL

Enumcontentdbs

Get-SPContentDatabase

Enumdeployments

None

Enumgroups

None

Enumroles

None

Enumservices

Get-SPServiceInstance

Enumsites

Get-SPSiteAdministration (To run this cmdlet, you must be a member of the Farm Administrators group.)

Get-SPSite (To run this cmdlet, you must be a local administrator on the computer where SharePoint 2010 Products is installed.)

Enumsolutions

Get-SPSolution

Enumsubwebs

Get-SPWeb

Enumtemplates

Get-SPWebTemplate

Enumusers

Get-SPUser

Enumwppacks

Get-SPWebPartPack

Enumzoneurls

Get-SPAlternateURL

Execadmsvcjobs

Start-SPAdminJob

Export

Export-SPWeb

Extendvs

New-SPWebApplication

Extendvsinwebfarm

New-SPWebApplicationExtension

Forcedeletelist

None

Getadminport

Get-SPWebApplication

Use the following syntax:

  • Get-SPWebApplication -IncludeCentralAdministration | ? {$_.IsAdministrationWebApplication -eq $true}

Getproperty

Get-SPFarmConfig

Get-SPTimerJob

Disable-SPTimerJob

Enable-SPTimerJob

Set-SPTimerJob

Start-SPTimerJob

Getsitelock

Get-SPSiteAdministration

Geturlzone

Get-SPAlternateURL

Import

Import-SPWeb

Installfeature

Install-SPFeature

Listlogginglevels

Get-SPLogLevel

Localupgradestatus

None

Managepermissionpolicylevel

None

Mergecontentdbs

Move-SPSite

Migrateuser

Move-SPUser

Provisionservice

Start-SPServiceInstance

Refreshdms

None

Refreshsitedms

None

Registerwsswriter

None

Removedrservice

None

Removesolutiondeploymentlock

None

Renameserver

Rename-SPServer

Renamesite

Set-SPSite

Use the Url parameter.

Renameweb

Set-SPWeb

Use the RelativeUrl parameter.

Restore

Restore-SPFarm

Restore-SPSite

Retractsolution

Uninstall-SPSolution

Retractwppack

None

Scanforfeatures

Install-SPFeature

Use the Scanforfeatures parameter.

Setadminport

Set-SPCentralAdministration

Setapppassword

None

Setconfigdb

Connect-SPConfigurationDatabase

Setlogginglevel

Set-SPLogLevel

Setproperty

Set-SPFarmConfig

Get-SPTimerJob

Disable-SPTimerJob

Enable-SPTimerJob

Set-SPTimerJob

Start-SPTimerJob

Setsitelock

Set-SPSiteAdministration

Use the LockState parameter.

Setworkflowconfig

Set-SPWorkflowConfig

Siteowner

Set-SPSiteAdministration

Spsearch

Get-SPSearchService

Set-SPSearchService

Get-SPSearchServiceInstance

Set-SPSearchServiceInstance

Spsearchdiacriticsensitive

None

Syncsolution

Install-SPSolution

Use the Synchronize parameter.

Unextendvs

Remove-SPWebApplication

Uninstallfeature

Uninstall-SPFeature

Unregisterwsswriter

None

Updateaccountpassword

Set-SPManagedAccount

Updatealerttemplates

None

Updatefarmcredentials

None

Upgrade

None

Upgradesolution

Update-SPSolution

Upgradetargetwebapplication

None

Userrole

Get-SPUser

Move-SPUser

New-SPUser

Remove-SPUser

Set-SPUser

See Also

Other Resources

Resource Center: Windows PowerShell for SharePoint Foundation 2010


Microsoft Press: Using Windows PowerShell to Perform and Automate Farm Administrative Tasks

Published: January 13, 2011

This book excerpt is from Microsoft SharePoint 2010 Administrator's Companion, Microsoft Press, August 2010.

Buy this book

This excerpt from Microsoft SharePoint 2010 Administrator's Companion explores the SharePoint 2010 Management Shell and how to use Windows PowerShell to accomplish some basic administrative tasks.

Authors

Bill English

Bill English, MCTS, MCT, CTT+, GSEC certified, is a Microsoft® MVP for SharePoint® Server. He runs a leading training and consulting company, has written 10+ books, and speaks at the Microsoft® Office SharePoint® Conference, Comdex, and other events.

Brian Alderman

Brian Alderman has his master's in Computer Information Systems and is currently employed by Mindsharp which is located in the Minneapolis-St. Paul area of Minnesota. Since 1995, he has held several Microsoft certifications that currently include; MCT, MCTS for SharePoint, MCITP for SQL Server®, MCSA and MCSE for Windows Server®, and also his PMP certification. As a Senior Technical Instructor and Consultant he has nearly 15 years of experience in networking, SQL Server databases, SharePoint technologies, and project management. Brian's previous publications include Windows 2000 Professional and SQL Server 2000 Administration. He is an active speaker at SharePoint Industry conferences including SharePoint Saturday's and the SharePoint Best Practices Conference.

Mark Ferraz

Mark Ferraz is the President of SolutionsMark (www.solutionsmark.com), a Houston-based consulting firm specializing in the design, development, and implementation of enterprise platforms, solutions, and services based on Microsoft SharePoint Products and Technologies. As a Senior Information Architect, Enterprise Network/Systems Architect, and Developer, Mark has over ten years of experience designing, managing, and implementing complex projects for some of the world's largest companies. In addition to being a contributing author of Microsoft Office SharePoint Server 2007 Best Practices, Mark is an active speaker at industry conferences such as SharePoint Best Practices Conference and SharePoint Technology Conference.

Book Excerpt -- Chapter 5: Using Windows PowerShell to Perform and Automate Farm Administrative Tasks

Over the last couple of years, some SharePoint administrators have recognized the power of Windows PowerShell and have tried to use it, but with no built-in support, most administrators have found it too difficult. Microsoft SharePoint Foundation 2010 and Microsoft SharePoint 2010 now contain native support for Windows PowerShell with the SharePoint 2010 Management Shell. This chapter explores the SharePoint 2010 Management Shell and how to use Windows PowerShell to accomplish some basic administrative tasks. Chapter 12, "Using Windows PowerShell to Manage Search Services and FAST Search," builds on the information in this chapter, using search administrative tasks and scenarios.

There is an enormous amount of information available about Windows PowerShell on the Internet and published in books. The aim of this chapter is not to teach you Windows PowerShell, but to show you how to become familiar with the new Windows PowerShell cmdlets, pronounced command-lets, introduced in SharePoint 2010. However, for those who are relatively new to Windows PowerShell, this chapter begins by reviewing the basics.

In this excerpt

  • Using Windows PowerShell: The Basics

  • Working with the SharePoint 2010 Management Shell

  • Examples of SharePoint Administrative Tasks

Using Windows PowerShell: The Basics

Traditionally, administrating a server on which Microsoft products are installed has involved learning a number of administrator tools, such as graphical interfaces based on the Microsoft Management Console (MMC), known as MMC snap-ins; many command-line utilities; and perhaps a Windows Management Instrumentation (WMI) provider or Component Object Model (COM) objects that administrators can interface with using VBScript. Until the release of SharePoint 2010, SharePoint Products and Technologies were no different than other Microsoft products in the number of available administrator tools. Administrators needed to rely on the Central Administration website, the SharePoint Products Configuration Wizard, and the command-line tools stsadm and psconfig. No one tool could do everything.

Each Microsoft product also had its own community, which created or extended the built-in tools to make an administrator's life easier. The tools an administrator needed were available, but they were scattered among many sources. This is all changing now that every administrative task can potentially be scripted or automated using Windows PowerShell.

The concept for Windows PowerShell is based on a study commissioned by Microsoft in the early 2000s. Originally based on the POSIX shell as specified in IEEE 1003.2 and influenced by Perl and UNIX shell, Windows PowerShell is a command shell and scripting language that is far more powerful than using the Windows command prompt (cmd.exe). Administrators love command-line tools because they can be batched together to automate repetitive tasks or to ensure that a set of tasks are completed again exactly as they were the last time they were executed. Windows PowerShell cmdlets offer administrators these same benefits. You can still use the traditional tools, but Windows PowerShell adds flexibility and breadth that the traditional tools do not provide.

Tip:

Community-led initiatives for previous versions of SharePoint include extensions to stsadm, published at http://stsadm.codeplex.com/; Windows PowerShell scripts for Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007 that can be found at http://sharepointpsscripts.codeplex.com/; and the CodePlex project "PowerShell SharePoint Provider" for Windows SharePoint Services 2.0 and Microsoft SharePoint Portal Server 2003, available at http://www.codeplex.com/PSSharePoint.

This section covers the following Windows PowerShell topics.

  • What's new in the Windows PowerShell 2.0 release

  • Architecture

  • Installing Windows PowerShell

  • Remote management

What's New in Windows PowerShell 2.0

Windows PowerShell 2.0 offers a number of new features and improvements from Windows PowerShell 1.0, including

  • New cmdlets

  • Remote Management and background jobs

  • Windows PowerShell Integrated Scripting Environment (ISE)

  • Windows PowerShell debugger

  • Modules

  • Advanced functions

  • Transactions

  • Steppable pipelines

  • Events

  • Script internationalization

  • Online Help

As an IT professional, many of these new features will interest you. For example, you can remotely manage all the servers in your farm from your desktop, and when you become competent in Windows PowerShell, you will be able to create your own advanced functions using the Windows PowerShell scripting language that you can then use as cmdlets. In Windows PowerShell 1.0, the only way to do this was with a developer, using code and deploying files onto your farm.

Tip:

For more information about what's new in Windows PowerShell 2.0, see What's New in Windows PowerShell and http://en.wikipedia.org/wiki/Windows_PowerShell. Other resources can be found by using your favorite Internet search engine and entering the keywords What's New in Windows PowerShell 2.0 or the feature names listed previously.

Windows PowerShell Architecture

Why is Windows PowerShell so important? Windows PowerShell scripting language is object orientated, built on top of the .NET Framework—.NET Framework 3.5 for Windows PowerShell 2.0—and based on the C# (pronounced C-sharp) programming language. This allows Windows PowerShell to access the underlying object models, to pass objects and their values (properties) from one Windows PowerShell command to another. This means you have almost the power of a developer without having to write, compile, and deploy code. The disadvantage is that it can be all too easy to cause havoc in your installation.

When the Microsoft product teams consider the tools they want to provide to administrators, they build them first on Windows PowerShell. Hence, with the installation of SharePoint 2010, a large number of administrative tasks can be completed natively with Windows PowerShell cmdlets, with no need to install software from community-led initiatives. If any additional cmdlets are required, you can create them using Windows PowerShell scripts and the Advanced Functions feature in Windows PowerShell 2.0, and developers within your organization can create new cmdlets. Using Windows PowerShell to help administer SharePoint is the way of the future, so it's important to start learning to use the built-in cmdlets as soon as possible.

At first, using Windows PowerShell may seem daunting, but if you have used the command prompt (cmd.exe) or have created batch files, you will soon be comfortable with the Windows PowerShell console. In fact, you can even use the Windows PowerShell console instead of the command prompt, because all the commands you currently use, such as dir, cd, and ping, work equally well in the Windows PowerShell console as they do in the command prompt. You may need to enclose command-line parameters in quotation marks to use the commands from within Windows PowerShell, but that is about the only modification you need to make. So there is no need to use two different windows to complete your administrative tasks.

Note:

By default, the command prompt has a black background, but this can be changed. Right-click the title bar and then select Properties. A Properties dialog box appears with four tabs: Options, Font, Layout, and Colors. You can change the font, background color, window size, and more. See the sidebar titled "Command-line Shortcuts" later in this chapter for more information about similarities between the two command-line interfaces.

There are two ways of using Windows PowerShell: either through a command-line interface, known as the Windows PowerShell console (powershell.exe), or through the Windows PowerShell Interactive Scripting Environment (ISE) graphical interface (Powershell_ise.exe). This chapter concentrates on using the Windows PowerShell console.

Tip:

Following are some resources for more information on Windows PowerShell.

  • Windows PowerShell 2.0 Administrator's Pocket Consultant, by William R. Stanek (Microsoft Press, 2009)

  • "Scripting with Windows PowerShell" on the Microsoft TechNet Script Center at http://technet.microsoft.com/en-us/scriptcenter/dd742419.aspx.

  • An aggregation of Windows PowerShell bloggers at http://pipes.yahoo.com/powershell/englishbloggers.

  • A short introduction to Windows PowerShell in a free eBook at http://blogs.msdn.com/mapo/archive/2007/07/17/windows-powershell-free-ebook-at-microsoft.aspx.

  • Mastering PowerShell, by Dr. Tobias Weltner, a free eBook at http://blogs.msdn.com/powershell/archive/2009/07/17/free-powershell-v1-book-from-the-makers-of-powershell-plus.aspx.

Command-line Shortcuts

All the same shortcuts that you use at the command prompt work in the Windows PowerShell console.

  • To pause the display temporarily when a command is writing output, press Ctrl+S, and then press Ctrl+S to resume or press Ctrl+C to terminate execution.

  • By default, up to 50 commands are stored in a buffer. You can move through the buffer by using the up arrow and down arrow keys to scroll through the commands so you can easily execute the next or a previous command.

  • The buffered commands can be displayed from a pop-up window by pressing F7. Select the command you want to execute using the arrow keys, press Enter or F9, type the number of the command you want to execute, and then press Enter.

  • The buffered commands can be displayed from the command line by typing the first few characters of the command you want and then pressing F8. The command-line interface searches though the history buffer for the first command that begins with the characters you typed.

  • Using the auto completion capabilities of the Windows PowerShell command shell, you never need to type the complete name of a command. Type in the first few characters of the command you want and press Tab to cycle through all commands and available file names and folders in alphabetic order, or click Shift+Tab to cycle through the commands in reverse order.

  • To copy and paste text, right-click the command-line interface title, click Mark, highlight the text you want to copy, and then right-click the window title again to copy the selected text automatically into the Clipboard.

  • Commands are case insensitive and can be batched together and placed in a text file. By calling that file in the command-line window, the commands in the file are executed. These text files have an extension of .bat, .cmd, .vbs, or in the case of Windows PowerShell, .ps1. Commands in these files can be executed outside the command window by calling the file from the Run line or by double-clicking the file in Windows Explorer.

  • Arguments can be sent to the command file being called. The arguments passed to your command file are stored in memory and accessed using variables. You can also create variables to store values needed as you complete a task. In Windows PowerShell, you reference variables by preceding the variable name by a dollar sign ($).

  • Output from a command can be directed to a file named to the right of >. This will overwrite the file if it already exists. To redirect the output but append it to the file, use >>. Error messages that result from running a command can be redirected to a file named to the right of 2>, or they can be appended to a file by using 2>> or sent to the same destination as the standard output by using 2>&1.

  • You can execute many commands on the same line. In Windows PowerShell, you separate commands using the semicolon character (;).

  • Redirect the output of one command as input to another command by separating both command with a '|', known as a pipe. For example, dir | sort | more will display a sorted list of files in the current directory one page at a time. The pipe is the symbol located above the backslash on most keyboards.

  • Aliases and shortcuts can be substituted for commonly used commands. For example, the ForEach-Object cmdlet can be replaced with ForEach or even with the percentage character, %. The question mark character, ?, can be used in place of Where or Where-Object. You can also use Get-Alias to return a list of aliases. Note that the use of aliases in scripts can make them difficult to understand.

  • Examples of these shortcuts can be found throughout this book.

Installing Windows PowerShell

Computers running Windows 7 or Windows 2008 R2 or later include Windows PowerShell 2.0 and Windows Remote Management (WinRM) 2.0. If you want to manage computers using earlier operating systems locally or remotely using Windows PowerShell, you will need to install both Windows PowerShell 2.0 and WinRM 2.0.

Installing Windows PowerShell 2.0 and WinRM 2.0

A copy of Windows PowerShell 2.0, together with WinRM 2.0, can be downloaded from http://support.microsoft.com/default.aspx/kb/968929. Ensure that you obtain the correct version; for example, if you install SharePoint on the 64-bit version of Windows Server 2008, you need to download and install the Windows 2008 x64 version of Windows PowerShell 2.0 and WinRM 2.0. After they are installed, you will find the executable for the Windows PowerShell ISE in the folder %SystemRoot%\System32\WindowsPowerShell\v1.0.

Note:

If you going to be a heavy user of ISE, consider placing a shortcut for this program on your taskbar. On the Start menu, right-click Powershell_ise.exe and then select either Pin To Taskbar or Pin To Start Menu.

To use Windows PowerShell ISE on Windows 2008 R2, you need to add the Windows PowerShell ISE feature. This feature can be added using Windows PowerShell commands or the Server Manager. After you have installed SharePoint 2010 or SharePoint Foundation 2010, perform the following steps.

  • Using Windows PowerShell, enter the following commands.

    Import-Module Servermanager; Add-WindowsFeature "PowerShell-ISE"

  • Using Server Manager, complete the following procedure.

    1. Start the Server Manager, click Features, and then select Add Features.

    2. In the middle pane of the Add Features Wizard, select the check box for Windows PowerShell Integrated Scripting Environment (ISE) as shown in Figure 5-1 and then click Next.

Installing Windows PowerShell

Figure 5-1 Install the Windows PowerShell Integrated Scripting Environment (ISE) feature

  1. On the Confirmation Installation Selection screen, click Install.

  2. On the Installation Results screen, click Close.

Working Within Your Execution Policy

Windows PowerShell is a powerful tool, and as with any other scripting language, it is all too easy to borrow someone else's code or download snippets from the Internet. Also, because the code files are just text files, it is easy for anyone to modify them and inject malicious code. Therefore, Windows PowerShell has a built-in security feature called execution policy that you can set on a per-user basis, and these settings are saved in the registry. To view your execution policy, type the following command in the Microsoft SharePoint 2010 Management Shell.

If you are running the Management Shell on a SharePoint server, it is likely that the output from such a command is RemoteSigned, which means that you can run any commands interactively and you can use any scripts that are stored on the computer where you are logged in. However, if you want to run configuration files or scripts from remote sources, they need to be signed. You can change the execution policy if you start the Windows PowerShell console as an administrator and use the Set-ExecutionPolicy cmdlet, or you can change the registry key as follows.

HKLM\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell

Security Note:

The registry key is useful in conjunction with an Active Directory Group Policy. Manual modifications to the registry should be avoided, especially when Microsoft provides a cmdlet to configure Windows PowerShell execution policy.

To sign scripts, use the Set-AuthenticodeSignature cmdlet, which can be used to add an Authenticode signature to a Windows PowerShell script or other file.

In an organization that has multiple environments, such as development, system integration, user acceptance test (UAT), pre-production, and production, consider the need to sign code on your production and UAT farms at minimum. You should also review the execution policy settings for these farms. You can set the execution policy in a Group Policy Object that targets either users or computers so that it cannot be overridden when someone logs on to your SharePoint servers.

Tip:

For more information on Windows PowerShell execution policies and signing scripts, see the TechNet article "Heading Off Malicious Code" at http://technet.microsoft.com/en-us/magazine/2008.01.powershell.aspx, or type Get-Help about_Execution_Policies at a Windows PowerShell command-line interface. There is also a blog post that explains the process in detail. It is "ALLSigned: Signing Your PowerShell Scripts" and can be found at http://sharepoint.microsoft.com/blogs/zach/Lists/Posts/Post.aspx?ID=53.

Note:

If you are using Windows 7 as your desktop and you want to remotely manage Windows Server 2008 R2 for your SharePoint servers, you need the Remote Server Administration Tools (RSAT), which is required for the new Group Policy features and supports Windows PowerShell. RSAT is available from the Microsoft Download Center at http://www.microsoft.com/downloads. For more information, go to http://technet.microsoft.com/en-us/library/dd367853.aspx and http://trycatch.be/blogs/roggenk/archive/2009/06/08/installing-windows-7-rsat-unattended.aspx.

Managing Systems Remotely with WinRM

Windows PowerShell 2.0 introduces a new capability to manage your systems remotely from your desktop by using either WinRM or Internet Information Server (IIS). WinRM is often the mechanism used by administrators and the subject of this section. Remote Management involves not just the ability to run Windows PowerShell locally on your machine using the few commands that allow you to specify a computer name as an optional parameter; it also includes methods known as fan-in and fan-out remoting and background jobs.

  • Fan-in remoting This allows many administrators to connect to an instance of Windows PowerShell running on the same remote servers—this is not supported out of the box in SharePoint 2010.

  • Fan-out remoting This allows you to send a single Windows PowerShell command to run multiple remote instances of Windows PowerShell in parallel, and the results of those commands will be returned to your desktop. You would use this if you need to complete the same task on multiple servers. You no longer need to establish a Remote Desktop connection to each server in turn and then execute the commands locally on that server. You can create a set of Windows PowerShell commands and pass the server names to those commands, which then completes the same commands sequentially for each server whose name you provide.

  • Background jobs Windows PowerShell 2.0 supports both local and remote background jobs. These are commands that execute asynchronously in the background with no interaction. When you execute a command in the background, the command prompt is returned immediately so that you can continue to execute other commands.

Configuring for WinRM

The WinRM Windows service must be started and configured for remoting on both your local computer and the server on which you want to remotely run commands. To find out if your server is running WinRM, type

Get-service winrm

To check if it is running on a remote server, type

Get-service winrm -computername $server_name

On your SharePoint server, this service should be running; however, if your local computer is running Windows 7 (or Windows Vista with Windows PowerShell 2.0 and WinRM 2.0 installed), you may need to start this service and enable remoting. You can do this by typing one command, Enable-PSRemoting, which executes two additional commands, Set-WSManQuickConfig and Start-Service WinRM.

Important:

If one of the network connection types is Public, the Set-WSManQuickConfig command will raise an Invalid Operation Exception. You will need to change the network connections to the network type of either Domain or Private to proceed.

The output to the Enable-PSRemoting command will look similar to the following example.

Copy Code
WinRM Quick Configuration
Running command "Set-WSManQuickConfig" to enable this machine for remote management
through WinRM service.
 This includes:
    1. Starting or restarting (if already started) the WinRM service
    2. Setting the WinRM service type to auto start
    3. Creating a listener to accept requests on any IP address
    4. Enabling firewall exception for WS-Management traffic (for http only).

Do you want to continue?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default
is "Y"): y
WinRM has been updated to receive requests.
WinRM service type changed successfully.
WinRM service started.
Configured LocalAccountTokenFilterPolicy to grant administrative rights remotely to local users.
WinRM has been updated for remote management.
Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine.
WinRM firewall exception enabled.

On a computer running a 64-bit version of Windows, you may see an additional confirmation message.

Copy Code
Are you sure you want to perform this action?
Performing operation "Registering session configuration" on Target "Session
configuration "Microsoft.PowerShell32" is not found. Running command
"Register-PSSessionConfiguration Microsoft.PowerShell32 -processorarchitecture x86
-force" to create "Microsoft.PowerShell32" session configuration. This will restart
WinRM service.".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"):

To determine how WinRM is configured, the authentication method, and the port numbers it will access, use the following command.

winrm get winrm/config/service

This should result in an output similar to the following.

Copy Code
Service
    RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)
    MaxConcurrentOperations = 4294967295
    MaxConcurrentOperationsPerUser = 15
    EnumerationTimeoutms = 60000
    MaxConnections = 25
    MaxPacketRetrievalTimeSeconds = 120
    AllowUnencrypted = false
    Auth
        Basic = false
        Kerberos = true
        Negotiate = true
        Certificate = false
        CredSSP = false
        CbtHardeningLevel = Relaxed
    DefaultPorts
        HTTP = 5985
        HTTPS = 5986
    IPv4Filter = *
    IPv6Filter = *
    EnableCompatibilityHttpListener = false
    EnableCompatibilityHttpsListener = false
    CertificateThumbprint

You can run winrm and winrm-related commands, such as the New-PSSession command, from either the Windows PowerShell console or the SharePoint 2010 Management Shell. However, these must be run as an administrator. To do this, right-click the Windows PowerShell console or the SharePoint 2010 Management Shell and then select Run As Administrator. You must be a member of the Administrators group on the remote machine or be able to provide administrator credentials to do this.

Note:

When your local computer and the remote computer are in different non-trusted domains or in a workgroup, additional steps are required to configure remoting. The workgroup scenario is likely to occur when SharePoint Foundation is installed for external collaboration or in a small business environment rather than in a typical SharePoint Server installation. For information on how to configure remoting between two workgroup machines, see the blog post at http://blogs.msdn.com/wmi/archive/2009/07/24/powershell-remoting-between-two-workgroup-machines.aspx.

Meeting Requirements for SharePoint PowerShell Remoting

To use WinRM to execute SharePoint PowerShell cmdlets on a remote machine, there are a number of additional requirements.

  1. You must have access to a userid with the correct rights to execute those commands. These requirements are applicable whether you are remoting into a server or locally executing SharePoint cmdlets. The userid must meet the following criteria.

    • Must be a member of the WSS_ADM_WGP local security group on the machine executing the commands.

    • Must be a member of the SharePoint_Shell_Access SQL Server role on the configuration database.

    • Must have access to the content database that you want to manipulate.

    You can use the SPShellAdmin cmdlets to help you manage these requirements. When you run the Add-SPShellAdmin cmdlet to add a userid to the SharePoint_Shell_Admin role, you must be mapped to Security_Admin role on the SQL instance and the db_owner role to the relevant databases. You need to run the Add-SPShellAdmin cmdlet for each content database that you want the userid to access.

  2. Designate one server in your farm as the server you will always use for remoting. On that server, increase the WinRM configuration option, MaxMemoryPerShellDB, to a large value, 512 or 1024. This configuration option limits the amount of memory a single remote process can use. Increasing the value will allow long-running commands to run without throwing OutOfMemory Exception errors. The command to display the values of the configuration options and sample output is shown here.

    winrm get winrm/config/winrs

    Copy Code
    Winrs
    AllowRemoteShellAccess = true
    IdleTimeout = 180000
    MaxConcurrentUsers = 5
    MaxShellRunTime = 2147483647
    MaxProcessesPerShell = 15
    MaxMemoryPerShellMB = 150
    MaxShellsPerUser = 5
 Winrs    AllowRemoteShellAccess = true    IdleTimeout = 180000    MaxConcurrentUsers = 5    MaxShellRunTime = 2147483647    MaxProcessesPerShell = 15    MaxMemoryPerShellMB = 150    MaxShellsPerUser = 5

    To modify the MaxMemoryPerShellDB setting, type the following Windows PowerShell command in the SharePoint 2010 Management Shell.

    Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1024

  3. You must use Credential Security Provider (CredSSP) authentication. This authentication mechanism, introduced with Windows Vista, allows an application to delegate the credentials from one machine to another, a process called double hopping. This will enable you to provide the credentials that allow the SharePoint PowerShell cmdlets to talk to the Microsoft SQL Server that is hosting your SharePoint databases. If you do not use CredSSP and you try to remotely execute a SharePoint cmdlet, you are likely to receive a message that indicates the farm is unavailable. In the output from the Winrm get winrm/config/service command shown previously, notice that CredSSP is equal to False. There are several ways you can modify WinRM configuration options, including Group Policy, login scripts, and the command prompt. To enable CredSSP authentication though command-line interfaces, complete the following tasks.

    1. On the computer from which you are remoting, such as your Windows 7 desktop, type the following command, where Web1 is the SharePoint server. Type Y when prompted to confirm that you want to enable CredSSP authentication.

      Enable-WSManCredSSP -role client -DelegateComputer Web1

    2. On the SharePoint server where you are remoting to, type

      Enable-WSManCredSSP -role server

    Tip:

    For more information on multi-hop support in WinRM, see http://msdn.microsoft.com/en-us/library/ee309365(VS.85).aspx.

Using WinRM Remoting

The commands you need to start a remote session to remotely manage a SharePoint farm or one specific SharePoint server are similar to those in the following example.

Copy Code
$cred = Get-Credential contoso\spfarm
$sess = New-PSSession Web1 -Authentication CredSSP -Credential $cred
Invoke-Command -Session $sess -ScriptBlock '
   {ADD-PSSnapin Microsoft.SharePoint.PowerShell;}
Security Note:

You can limit the Windows PowerShell commands that a user can access during a remote session by using the -ConfigurationName parameter with the New-PSSession cmdlet or by using the Proxy cmdlet. For more information, see the blog post "Extending and/or Modifying Command with Proxies" at http://blogs.msdn.com/powershell/archive/2009/01/04/extending-and-or-modifing-commands-with-proxies.aspx.

When you enter the first command, a dialog box appears where you must type the password. This password and the user name are stored in the variable $Cred, which is used in the second command, New-PSSession, which establishes a persistent session with the remote server. Creating a persistent session is not necessary when using Windows PowerShell remoting, but if you do not establish a persistent connection, whenever you invoke a remote command that includes a SharePoint cmdlet, each Invoke-Command will also need to include the PSSnapin cmdlet. The third command, Invoke-Command PSSnapin, allows you to run SharePoint PowerShell cmdlets on the remote server.

Reference to the persistent session is stored in the variable $sess. You can direct any commands you want to that remote server by using this variable. In the following example, the cmdlet Get-SPServiceInstance is typed within the script block—the area between the curly brackets ({ }). The output from the Get-SPServiceInstance cmdlet returns the status of the services within a SharePoint farm.

Invoke-Command -Session $s -ScriptBlock {get-SPServiceInstance}

Copy Code
WARNING: column "PSComputerName" does not fit into the display and was removed.

TypeName                         Status   Id
--------                         ------   --
Business Data Connectivity       Online   3ad4d004-9ae3-4810-94bf-76cc43c9d507
Microsoft SharePoint Foundati... Online   81cc6474-fd6f-42ad-a932-25d67cff8cc1
Microsoft SharePoint Foundati... Disabled cb3b976c-b451-4abe-b808-0c6d191ccd3d
Microsoft SharePoint Foundati... Online   5bac9c93-483a-4901-ae46-f6f7ae0a12a8
Central Administration           Online   0c24457f-b58e-4daa-895e-4acd35ef7543
Microsoft SharePoint Foundati... Online   155570fa-0d4c-495d-9f31-5250e83bdd75
Microsoft SharePoint Foundati... Disabled c25ae170-c07d-48db-97b3-73b0d9b47e94
SharePoint Foundation Help Se... Online   8af8b8b1-92cb-48d2-8864-20a7e191d7c2
Important:

You can type multiple commands in a script block, either on separate lines or on the same line separated by a semicolon (;). If only one command is entered in the script block, the semicolon is optional, but it is good practice to include it. You can also use local variables to generate a remote script block as in the following example.

Copy Code
$url = "http://contoso.com"
$myscript = "get-spsite $url"
$sb = [scriptblock]::Create($myscript)
Invoke-Command $sess -ScriptBlock $sb

You can use the Windows PowerShell Invoke-Command cmdlet to communicate with many sessions, either on the same server or on different servers, from your desktop. This cmdlet enables you to start multiple administrative tasks at the same time that are then run in parallel. However, if these tasks are long running, you will not get control back until the command on the remote machine finishes. This is known as running the command interactively. To run asynchronously as a background job so that the Windows PowerShell prompt returns immediately and you can enter other commands, append the -AsJob parameter to the Invoke-Command, or alternatively, use the Start-Job cmdlet. Using this technique can reduce the amount of time to complete your administrative tasks, compared to running them sequentially. An example of how this can save you a considerable amount of time is during the upgrade process, when each session runs a database-attach-upgrade, and the time taken to complete all database upgrades is limited only by the resources of your SQL Server.

If you have many short-running tasks to complete on a specific server and don't want to keep typing Invoke-Command, use one of the following approaches.

  • You can enter an interactive session with that server by typing Enter-PSSession $sess. The command prompt will change from PS C:\Users\<userid>, where <userid> is the name of the current user, to [<remoteservername>]: PS C:\Users\<remotecredentials>\Documents, where <remotecredentials> is the userid you used for the CredSSP authentication. The command prompt reminds you that you are now submitting commands to the remote server. To return to interactive mode on your local computer, type Exit-PSSession or exit.

  • Use the Import-PSSession remoting cmdlet, also known as implicit remoting, to bring commands from the remote session into the local Windows PowerShell session. An additional advantage of the Import-PSSession approach is that you can interact with your local file system and talk to SharePoint as if you were logged on locally to the SharePoint server. By default, the Import-PSSession cmdlet imports all commands except commands that have the same name as commands in your current session. You can also import a subset of commands and prefix them with a word you specify, so that it is obvious to you which commands are local and which are remote. In the following example, the word Remote is added as a prefix to all SPSite cmdlets.

    Import-PSSession -session $sess -CommandName *-spsite -Prefix Remote

    Copy Code
    M ModuleType Name                      ExportedCommands
---------- ----                      ----------------
Script     tmp_1833f7bc-b269-4229... {Set-SPSite, Backup-SPSite, Get-SPSite,...

    In this example, you can use all SPSite cmdlets as if they were local commands; for example, by typing Get-RemoteSPSite you can return all site collections that match the given criteria. These imported commands are stored in a temporary module that is deleted at the end of the session. To create a persistent module that you can use in future sessions, use the Export-PSSession cmdlet. The imported commands still run in the remote session from which they were imported and therefore may take longer to run than local commands.

When you have completed all of your tasks, you can delete the persistent connection between your local machine and the remote machine by typing Remove-PSSession $sess.

Tip:

For more information about Windows PowerShell remoting, see Chapter 4, "Using Sessions, Jobs, and Remoting" in the Windows PowerShell 2.0, Administrator's Pocket Consultant, by William Stanek (Microsoft Press, 2009), and the TechNet Magazine article "A Sneak Peek at Remote Management in Version 2.0" at http://technet.microsoft.com/en-us/magazine/2008.08.windowspowershell.aspx. Also take a look at the blog post "A Few Good WS-MAN (WinRM) Commands" at http://blogs.technet.com/otto/archive/2007/02/09/sample-vista-ws-man-winrm-commands.aspx.

Working with the SharePoint 2010 Management Shell

To open the SharePoint 2010 Management Shell, click Start, and then select Programs, Microsoft SharePoint 2010 Products, and finally, SharePoint 2010 Management Shell, as shown in Figure 5-2.

Starting Windows PowerShell

Figure 5-2 Accessing the SharePoint 2010 Management Shell

The SharePoint 2010 Management Shell is a custom console; it is not the same console that opens if you open the default Windows PowerShell console, a shortcut to which is usually placed on the taskbar. A review of the properties of the SharePoint 2010 Management Shell shortcut exposes the command that is executed.

Copy Code
C:\Windows\System32\WindowsPowerShell\v1.0\PowerShell.exe  -NoExit  " &
   ' C:\Program Files\Common Files\Microsoft Shared\Web Server
   Extensions\14\CONFIG\POWERSHELL\Registration\\sharepoint.ps1 ' "

The shortcut points to the file Sharepoint.ps1. This is an example of a Windows PowerShell profile, which is identical to any other Windows PowerShell script file and is used to store frequently used elements that need to be automatically loaded at the start of a Windows PowerShell session. Hence, just like normal scripting files, profiles can contain functions, aliases, and variables, and they can load any Windows PowerShell extensions, snap-ins, or modules you might need. A Windows PowerShell snap-in (PSSnapin) is a .NET program that is compiled into DLL files and contains new cmdlets, functions, and/or providers. Windows PowerShell comes with a number of snap-ins, including Microsoft.PowerShell.Core, Microsoft.PowerShell.Host, and Microsoft.PowerShell.WSMan.Management, as well as modules such as ActiveDirectory, FailoverClusters, and WebAdministration. As other products are installed on your computer, additional extensions will become available.

The main aim of the SharePoint profile file is to load the Windows PowerShell for SharePoint snap-in so you can then use the new cmdlets specific to SharePoint. The SharePoint profile file contains the following code, plus a signature.

Copy Code
$ver = $host | select version
if ($ver.Version.Major -gt 1)  {$Host.Runspace.ThreadOptions = "ReuseThread"}
Add-PsSnapin Microsoft.SharePoint.PowerShell
Set-location $home

This code obtains the version of Windows PowerShell, checks that it is greater than 1, and then if that is true, it sets the threading model so that the first thread will be reused, loads the SharePoint PowerShell snap-in, and then changes directory to the home folder, such as C:\users\<userid>, where userid is the person who is currently logged in. For more information on SharePoint, Windows PowerShell, and threading, see the sidebar titled "Memory Considerations When Using Windows PowerShell" later in this chapter.

The SharePoint PowerShell snap-in is not the only snap-in loaded into the SharePoint 2010 Management Shell. Therefore, not only can you use the SharePoint cmdlets, you also can use other cmdlets from the snap-ins that are loaded. To see all the snap-ins and the order in which they were loaded, type Get-PSSnapin. Your output should look similar to the following example.

Copy Code
Name        : Microsoft.PowerShell.Diagnostics
PSVersion   : 2.0
Description : This Windows PowerShell snap-in contains Windows Eventing and
              Performance Counter cmdlets.

Name        : Microsoft.WSMan.Management
PSVersion   : 2.0
Description : This Windows PowerShell snap-in contains cmdlets (such as
              Get-WSManInstance and Set-WSManInstance) that are used by the
              Windows PowerShell host to manage WSMan operations.

Name        : Microsoft.PowerShell.Core
PSVersion   : 2.0
Description : This Windows PowerShell snap-in contains cmdlets used to manage
              components of WindowsPowerShell.

Name        : Microsoft.PowerShell.Utility
PSVersion   : 2.0
Description : This Windows PowerShell snap-in contains utility Cmdlets used to
              manipulate data.

Name        : Microsoft.PowerShell.Host
PSVersion   : 2.0
Description : This Windows PowerShell snap-in contains cmdlets (such as Start-
              Transcript and Stop-Transcript) that are provided for use with the
              Windows PowerShell console host.

Name        : Microsoft.PowerShell.Management
PSVersion   : 2.0
Description : This Windows PowerShell snap-in contains management cmdlets used to
              manage Windows components.

Name        : Microsoft.PowerShell.Security
PSVersion   : 2.0
Description : This Windows PowerShell snap-in contains cmdlets to manage Windows
              PowerShell security.

Name        : Microsoft.SharePoint.PowerShell
PSVersion   : 1.0
Description : Register all administration Cmdlets for Microsoft SharePoint Server.
Note:

If you develop your own scripts that can be called from the command prompt or by double-clicking the file in Windows Explorer, and those scripts contain Windows PowerShell for SharePoint commands, make sure that you include the command to set the threading model and load the Windows PowerShell for SharePoint snap-in in your scripts. When calling a script from within a Windows PowerShell console, you can use the #requires tag at the top of your script.

Real World Customizing Your Console

It is common practice to modify the profile file on the designated administrator machine. The profile could be altered so that it

  • Contains all the snap-ins or modules used by all IT professionals in an organization or department.

  • Tracks all Windows PowerShell commands executed.

  • Changes the prompt to indicate the server name. In an organization with a multitude of servers, it is all too easy to start an administrative task on the wrong server, so anything that can help an administrator identify the server he is working on will be helpful, such as configuring the window title to list the name of the server.

An example of a custom profile could contain the following code.

Copy Code
<# ***********************************************************
 Copyright (c)2010, Contoso, All Rights Reserved
 *************************************************************
Contoso PowerShell Profile - ContosoProfile.ps1
Author: Peter Connelly
Purpose: This profile sets the PowerShell window size, font and title
and loads the SharePoint snap-in
History: Version 1.0 01/02/2010 First version
#>
# Track all Windows PowerShell commands
$profilename = $MyInvocation.MyCommand.Name
$profilepath = $MyInvocation.MyCommand.Path
$transcriptFile = "C:\Contoso\Logs\Powershell_$profilename.log"
Start-Transcript $transcriptFile -append -force
Write-Output "Starting profile: $profilepath"

# Command from SharePoint Server 2010 profile file - SharePoint.ps1
$ver = $host | select version
if ($ver.Version.Major -gt 1)  {$Host.Runspace.ThreadOptions = "ReuseThread"}
Add-PsSnapin Microsoft.SharePoint.PowerShell
Set-location $home

# Check that this is a command-line interface and not the ISE
if ($host.name -eq "ConsoleHost")
{
  $width = 80
  $sizeWindow = new-object System.Management.Automation.Host.Size $width,40
  $sizeBuffer = new-object System.Management.Automation.Host.Size $width,9999
  <# Check to adhere to the following rules:
  The buffer width can't be resized to be narrower than the window's current
  width plus the window's width can't be resized to be wider than the
  buffer's current width. #>
  $S = $Host.UI.RawUI
  if ($s.WindowSize.width -gt $width)
  {
        $s.WindowSize = $sizeWindow
        $s.BufferSize = $sizeBuffer
  } else {
        $s.BufferSize = $sizeBuffer
        $s.WindowSize = $sizeWindow
  }
}
# Set foreground, background color and window title
$s.ForegroundColor = "Yellow";$s.BackgroundColor = "DarkBlue";
$s.WindowTitle = "$env:computername"
# #############################################################
# End of ContosoProfile.ps1
# #############################################################

Because the profile script is automatically executed every time you run the SharePoint 2010 Management Shell, it should be signed. More information about customizing your console can be found at http://technet.microsoft.com/en-us/library/ee156814.aspx.

Understanding cmdlets

Window PowerShell cmdlets are utilities that are built on top of application interfaces, and in the case of SharePoint 2010, the SharePoint Object Module, and SharePoint Web Services, that allow administrators to complete a number of tasks.

In general, cmdlets use a verb-noun pair. The noun specifies the object you want information about or that you want to manipulate, and the verb states what you want to do with that object. The verbs and nouns are always separated by a hyphen with no spaces, and SharePoint cmdlet verbs have a prefix of SP. For example, if you want to get (the verb) information about all the content databases (noun) in your farm, you would use the following SharePoint cmdlet, which would give you the output shown.

PS C:\Users\Peter> Get-SPContentDatabase

Copy Code
Id               : a1d5c96c-a41a-43b3-bc5d-3f8a93b26046
Name             : WSS_Content_a2fde53006e04bf5aae434ffd3c8a19c
WebApplication   : SPWebApplication Name=SharePoint - 80
Server           : SQL
CurrentSiteCount : 1

Id               : 363b11a3-6947-42f6-9df4-665eeff59c83
Name             : SPF_TeamsDB
WebApplication   : SPWebApplication Name=SPF_Teams
Server           : SQL
CurrentSiteCount : 1

Windows PowerShell also provides a few cmdlets that help you to work with the other cmdlets. Two examples of these are Get-Command, which can be shorted to gcm, and Get-Help, which can be shorted to help. (Shortened names of cmdlets are called aliases.) Get-Command allows you to find cmdlets, and then Get-Help can provide you with basic information about a cmdlet after it is retrieved. (You'll see how to use the Get-Help cmdlet in the section titled "Getting Help" later in this chapter.) In the following example, the Get-Command finds all the cmdlets associated with SharePoint.

Copy Code
PS C:\Users\Peter>Get-Command -PSSnapin "Microsoft.SharePoint.PowerShell" |
>>sort noun, verb |Format-Wide -Column 3
>><ENTER>
Note:

When you type a one-line Windows PowerShell script, or you have not provided all the required parameters, Windows PowerShell either prompts you for the parameter or starts a new line with >> so that you can enter more commands. When you have finished typing, press Enter for Windows PowerShell to execute the code. Because of page size restrictions, many of the commands in this chapter are shown on multiple lines when they could be typed on one line, so always remember to press Enter only to execute the scripts.

The set of commands shown previously takes the output from the Get-Command cmdlet and pipes it to the sort cmdlet. The sort cmdlet sorts the data in noun-then-verb order so that all SharePoint cmdlets that manipulate the same object are listed together. The cmdlets that manipulate the same object are then sorted in verb order. To reduce the amount of scrolling necessary in the SharePoint 2010 Management Shell, the sorted data is piped to the format-wide cmdlet. Such a combination of Windows PowerShell cmdlets is quite common. The output from the command set would look similar to the following sample.

Copy Code
Start-SPAdminJob           Get-SPAlternateURL         New-SPAlternateURL
Remove-SPAlternateURL      Set-SPAlternateURL         Install-SPApplicationC...
Start-SPAssignment         Stop-SPAssignment          Get-SPAuthenticationPr...
New-SPAuthenticationPro... Get-SPBackupHistory        Move-SPBlobStorageLoca...
Get-SPBrowserCustomerEx... Set-SPBrowserCustomerEx... Copy-SPBusinessDataCat...
…..(not all output shown)
Set-SPWebApplicationHtt... Get-SPWebPartPack          Install-SPWebPartPack
Uninstall-SPWebPartPack    Get-SPWebTemplate          Install-SPWebTemplate
Set-SPWebTemplate          Uninstall-SPWebTemplate    Get-SPWorkflowConfig
Set-SPWorkflowConfig
Note:

There is another cmdlet similar to the Get-Command that helps you work with cmdlets and that you might find useful—especially if you create your own commands or scripts. It is the Measure-Command cmdlet. This command allows you to measure the time it takes to run cmdlets or scripts. You may also find the Trace-Command cmdlet useful for debugging short script blocks.

Working with Objects

There are a considerable number of objects available in SharePoint, and as you might expect, there are more available in SharePoint Server than in SharePoint Foundation. By reading this book, you might have determined the relationship between these objects. For example, while a SharePoint farm can contain many Web applications, each SharePoint farm has one configuration database. Many of the SharePoint cmdlets use names that you can easily identify to determine which objects they will manipulate. To illustrate, the SPFarm cmdlets allow you to retrieve information about and back up or restore a SharePoint farm. For example, the SPFarmConfig cmdlet lets you retrieve and set properties for the farm.

However, there are a few cmdlet names that could confuse you. For example, the SPSite cmdlet allows you to manipulate site collections, and Chapter 2, "Understanding the Architecture of SharePoint 2010," explains that you can't create a site collection unless you have a Web application, which means using the SPWebApplication object. When a site collection is created, you choose a site template to create a site. In the SharePoint Object Model, this site is known as a web and not a site; hence, the object is named SPWeb. This can be quite confusing because the term "website" is often shortened to "site," and in the SharePoint Object Model, "site collection" is also shortened to "site." Because this terminology has been used through many versions of SharePoint and is used consistently by developers, it is easier for IT professionals to adopt this usage.

  • A web is a website and can be manipulated using the SPWeb object.

  • A site collection contains a collection of webs and can be manipulated using the SPSite object.

Figure 5-3 displays the most common objects and their relationships, but there are others, such as SPSiteCollection, which is a collection of SPSites.

The current selection of built-in cmdlets does not provide full coverage of all SharePoint objects, but you can write new cmdlets to manipulate these objects. To determine the objects associated with the SharePoint PowerShell cmdlets and the number of cmdlets per each object, use the commands in the following example, where a portion of the output is shown.

Copy Code
PS C:\Users\peter> Get-Command -PSSnapin "Microsoft.SharePoint.PowerShell" |
>>sort noun, verb | group-object -property noun
>><ENTER>
Copy Code
Count Name                      Group
----- ----                      -----
    1 SPAdminJob                {Start-SPAdminJob}
    4 SPAlternateURL            {Get-SPAlternateURL, New-SPAlternateURL, Rem...
    1 SPApplicationContent      {Install-SPApplicationContent}
    2 SPAssignment              {Start-SPAssignment, Stop-SPAssignment}
...(not all output shown)
    6 SPWeb                     {Export-SPWeb, Get-SPWeb, Import-SPWeb, New-...
    4 SPWebApplication          {Get-SPWebApplication, New-SPWebApplication,...
    1 SPWebApplicationExtension {New-SPWebApplicationExtension}
    2 SPWebApplicationHttpTh... {Disable-SPWebApplicationHttpThrottling, Ena...
    2 SPWebApplicationHttpTh... {Get-SPWebApplicationHttpThrottlingMonitor, ...
    3 SPWebPartPack             {Get-SPWebPartPack, Install-SPWebPartPack, U...
    4 SPWebTemplate             {Get-SPWebTemplate, Install-SPWebTemplate, S...
    2 SPWorkflowConfig          {Get-SPWorkflowConfig, Set-SPWorkflowConfig}
Common SharePoint objects and their relationships

Fig 5-3 Common SharePoint objects and their relationships

Understanding Properties and Methods

Everything that SharePoint knows about an object is stored in data elements and values known as properties, which also describe the state of that object. For example, the SPContentDatabase object contains all the information about the content databases within the farm.

Objects not only have properties, they also contain actions that determine how they can be manipulated. In object-oriented terminology, these actions, or different ways of acting on an object, are called methods. To determine the properties and methods for the SPSite object, use the cmdlets in the following example, where a portion of the output is shown.

PS C:\Users\peter> Get-SPSite | Get-Member

Copy Code
   TypeName: Microsoft.SharePoint.SPSite

Name                                  MemberType Definition
----                                  ---------- ----------
AddWorkItem                           Method     System.Guid AddWorkItem(Sys...
BypassUseRemoteApis                   Method     System.Void BypassUseRemote...
CheckForPermissions                   Method     System.Void CheckForPermiss...
Close                                 Method     System.Void Close()
ConfirmUsage                          Method     bool ConfirmUsage()
Delete                                Method     System.Void Delete(), Syste...
Dispose                               Method     System.Void Dispose()
…
ToString                              Method     string ToString()
UpdateValidationKey                   Method     System.Void UpdateValidatio...
VisualUpgradeWebs                     Method     System.Void VisualUpgradeWe...
AdministrationSiteType                Property   Microsoft.SharePoint.SPAdmi...
AllowDesigner                         Property   System.Boolean AllowDesigne...
AllowMasterPageEditing                Property   System.Boolean AllowMasterP...
….(not all output shown)
WarningNotificationSent               Property   System.Boolean WarningNotif...
WebApplication                        Property   Microsoft.SharePoint.Admini...
WorkflowManager                       Property   Microsoft.SharePoint.Workfl...
WriteLocked                           Property   System.Boolean WriteLocked ...
Zone                                  Property   Microsoft.SharePoint.Admini...
Important:

Never miss an opportunity to pipe the Get-SP<noun> cmdlet to the Get-Member cmdlet. It is sometimes surprising what information an object is able to retrieve.

Real World: Performance Issues When Running Windows PowerShell Commands

If you want to find all the site collections in the farm, you can type Get-SPSite. However, the only output you will see is the URL of the site collections. For performance reasons, the Url property is the only property displayed by default. This is because site collections have many properties; if you display all of these properties for a large number of site collections, you will consume a large amount of memory, and the command will take a long time to run. Displaying just the Url property is almost instantaneous because it is cached. Therefore, you should refrain from running this command to display more than a few additional properties.

To display more than the default property, you can use the select Windows PowerShell cmdlet with the pipe (|) character. You also can use the wildcard character (*) with the select statement to list all the property values, as shown in the following example.

PS C:\Users\Peter> Get-SPSite "http://teams" | select *

Copy Code
ApplicationRightsMask                 : FullMask
ID                                    : cbf3290e-000e-4768-953c-99a983430283
SystemAccount                         : SHAREPOINT\system
Owner                                 : CONTOSO\spadmin
SecondaryContact                      : CONTOSO\peter
GlobalPermMask                        : FullMask
IISAllowsAnonymous                    : False
Protocol                              : http:
HostHeaderIsSiteName                  : False
HostName                              : teams
Port                                  : 80
...(not all output shown)
AllowDesigner                         : True
AllowRevertFromTemplate               : False
AllowMasterPageEditing                : False
ShowURLStructure                      : False

To get a list of all site collections in your farm, together with the name of the content database where they are stored (output that gives only the URL of the site collection and the content database name), you would use the commands as shown in the following example, which also shows the sample output.

PS C:\Users\peter> Get-SPSite | select url, contentdatabase

Copy Code
Url                                     ContentDatabase
---                                     ---------------
http://MySite                           SPContentDatabase Name=Contoso_MySiteDB
http://MySite/personal/peter            SPContentDatabase Name=Contoso_PersonalDB
http://MySite/personal/erin             SPContentDatabase Name=Contoso_PersonalDB
http://intranet.contoso.msft            SPContentDatabase Name=Contoso_IntranetDB
http://teams                            SPContentDatabase Name=Contoso_TeamsDB
http://teams/sites/Finance              SPContentDatabase Name=Contoso_TeamsDB

Using Verbs

SharePoint uses common verbs that you have seen with other sets of cmdlets; there are also a number of new verbs added in SharePoint that you may not have seen. Again, you can find these by using the Get-Command cmdlet, as shown here.

Copy Code
PS C:\Users\Peter>Get-Command -PSSnapin "Microsoft.SharePoint.PowerShell" |
>>sort verb | group verb | sort count -descending
>><ENTER>
Copy Code
Count Name                      Group
----- ----                      -----
  139 Get                       {Get-PluggableSecurityTrimmer, Get-SPAccessS...
  104 Set                       {Set-SPAccessServiceApplication, Set-SPAlter...
   88 New                       {New-SPAccessServiceApplication, New-SPAlter...
   77 Remove                    {Remove-PluggableSecurityTrimmer, Remove-SPA...
   11 Update                    {Update-SPFarmEncryptionKey, Update-SPInfoPa...
   10 Add                       {Add-PluggableSecurityTrimmer, Add-SPClaimTy...
   10 Install                   {Install-SPApplicationContent, Install-SPDat...
    8 Start                     {Start-SPAdminJob, Start-SPAssignment, Start...
    8 Import                    {Import-SPBusinessDataCatalogModel, Import-S...
    8 Export                    {Export-SPBusinessDataCatalogModel, Export-S...
    8 Uninstall                 {Uninstall-SPDataConnectionFile, Uninstall-S...
    7 Disable                   {Disable-SPBusinessDataCatalogEntity, Disabl...
    6 Enable                    {Enable-SPBusinessDataCatalogEntity, Enable-...
    6 Clear                     {Clear-SPLogLevel, Clear-SPMetadataWebServic...
    5 Stop                      {Stop-SPAssignment, Stop-SPEnterpriseSearchQ...
    4 Move                      {Move-SPBlobStorageLocation, Move-SPProfileM...
    3 Initialize                {Initialize-SPContentDatabase, Initialize-SP...
    3 Upgrade                   {Upgrade-SPContentDatabase, Upgrade-SPEnterp...
    3 Backup                    {Backup-SPConfigurationDatabase, Backup-SPFa...
    3 Restore                   {Restore-SPEnterpriseSearchServiceApplicatio...
    2 Resume                    {Resume-SPEnterpriseSearchServiceApplication...
    2 Test                      {Test-SPContentDatabase, Test-SPInfoPathForm...
    2 Suspend                   {Suspend-SPEnterpriseSearchServiceApplicatio...
    2 Revoke                    {Revoke-SPBusinessDataCatalogMetadataObject,...
    2 Mount                     {Mount-SPContentDatabase, Mount-SPStateServi...
    2 Grant                     {Grant-SPBusinessDataCatalogMetadataObject, ...
    2 Dismount                  {Dismount-SPContentDatabase, Dismount-SPStat...
    1 Merge                     {Merge-SPLogFile}
    1 Receive                   {Receive-SPSharedServiceApplicationInfo}
    1 Disconnect                {Disconnect-SPConfigurationDatabase}
    1 Unpublish                 {Unpublish-SPServiceApplication}
    1 Connect                   {Connect-SPConfigurationDatabase}
    1 Rename                    {Rename-SPServer}
    1 Restart                   {Restart-SPEnterpriseSearchQueryComponent}
    1 Copy                      {Copy-SPBusinessDataCatalogAclToChildren}
    1 Ping                      {Ping-SPEnterpriseSearchContentService}
    1 Publish                   {Publish-SPServiceApplication}

As you can see, the most common SharePoint-related verbs are

  • Get Queries a specific object or a collection of object and retrieves information concerning that object. For example, you could use it to retrieve information on all service applications. Only Get commands return one or more objects; all other commands execute on one object at a time.

    Get-SPServiceApplication

  • Set Modifies specific settings of an object. For example, you could use it to set the site collection owner for a specific site collection.

    Set-SPSite http://teams -OwnerAlias contoso\peter

  • New Creates a new instance of an object, such as creating a new site collection.

    Copy Code
    New-SPSite http://teams/sites/HR -OwnerAlias contoso\peter
-Name "HR Team" -Template STS#0

  • Remove Removes (deletes) an instance of the object, such as a site collection and all its subsites. Because of the dangerous nature of this verb, you usually have to confirm this action by using the -confirm parameter. If this parameter is not present, you will see a message asking you to confirm the action, as shown here.

    Copy Code
    PS C:\Users\Peter> Remove-SPSite http://teams/sites/HR
Confirm
Are you sure you want to perform this action?
Performing operation "Remove-SPSite" on Target "http://teams/sites/Finance".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help
(default is "Y"):y

Parameters are used throughout the examples shown here. These are the words prefixed with a hyphen (-). In the next section, you will look at the Get-Help cmdlet and learn how it can help you find out more about these parameters, including which parameters are available for use with different cmdlets.

Getting Help

Windows PowerShell contains an extensive built-in help system, and you can access it quickly by typing help at the command-line interface. This is an alias for the cmdlet Get-Help. You can even get help about Get-Help by typing Get-Help Get-Help. The output from such a command lists a description of the cmdlet, the syntax used by the cmdlet, parameter descriptions, examples, and other related notes. You also can use the Get-Help cmdlet to get help with the basic Windows PowerShell language. For example, you can use the following commands to get help about specific topics: Get-Help foreach, or Get-Help substring, or Get-Help variables.

Note:

The best way to learn Windows PowerShell is to use its built-in help system. If you or your developers create new Windows PowerShell cmdlets, make sure you create your own help files. In addition to the built-in help, there are many resources on the Internet. For example, you can download a free Windows PowerShell Help 2.0 for either 32-bit or 64-bit from http://www.primaltools.com/downloads/communitytools/.

Help Files

Get-Help finds the information to display by using Extensible Markup Language (XML) files that are installed on the server. When you installed SharePoint, help files were installed along with the Windows PowerShell snap-in. These files can be found in %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\14\CONFIG\PowerShell\Help or %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\14\CONFIG\PowerShell\Help\<locale>, where locale defines the language of the computer, such as en-us. These files use the naming convention <dll filename>-help.xml, such as Microsoft.SharePoint.PowerShell.dll-help.xml, Microsoft.SharePont.Search.dll-help.xml, and Microsoft.Office.Access.Server.dll-help.xml. You can find which cmdlets use which XML help file by typing

Copy Code
PS C:\Users\Peter>Get-Command -PSSnapin "Microsoft.SharePoint.PowerShell" |
>>sort helpfile, name |
>>Format-Wide name -column 2 -groupby helpfile | more
>><ENTER>

Copy Code
   :

Get-SPExcelBlockedFileType        Get-SPExcelDataProvider
Remove-SPExcelDataProvider        Remove-SPExcelUserDefinedFunction
Set-SPExcelFileLocation

   HelpFile: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions
\14\CONFIG\PowerShell\Help\microsoft.office.access.server.dll-help.xml

Get-SPAccessServiceApplication    New-SPAccessServiceApplication
Set-SPAccessServiceApplication

   HelpFile: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions
\14\CONFIG\PowerShell\Help\Microsoft.Office.Excel.Server.MossHost.dll-help.xml

Get-SPExcelDataConnectionLibrary   Get-SPExcelFileLocation
Get-SPExcelServiceApplication      Get-SPExcelUserDefinedFunction
New-SPExcelBlockedFileType         New-SPExcelDataConnectionLibrary
New-SPExcelDataProvider            New-SPExcelFileLocation
New-SPExcelServiceApplication      New-SPExcelUserDefinedFunction
Remove-SPExcelBlockedFileType      Remove-SPExcelDataConnectionL...
Remove-SPExcelFileLocation         Set-SPExcelDataConnectionLibrary
Set-SPExcelDataProvider            Set-SPExcelServiceApplication
-- More -
Tip:

You can find more information about the format of the cmdlet XML help files and how to make your own help files to complement new cmdlets you create at http://blogs.msdn.com/powershell/archive/2006/09/14/Draft-Creating-Cmdlet-Help.aspx and http://blogs.msdn.com/powershell/archive/2008/12/24/powershell-v2-external-maml-help.aspx.

ISE Help

In addition to the command-line help function, there is a graphical help file (WindowsPowerShellHelp.chm) located at %SystemRoot%\Help\mui\<LCID> where LCID is the locale identifier or language of your installation, such as 0409. You can access the graphical help file when using the ISE by selecting the command you want help for and then pressing F1. The chm file opens, and help is displayed for the command, as shown in Figure 5-4.

However, the chm file contains help only for the core Windows PowerShell cmdlets. If you need SharePoint-specific help, you should use the SharePoint 2010 Management Shell and the Get-Help cmdlet.

Tip:

For more information on the Help feature in Windows PowerShell and how you can configure it to show help for aliases or how to disable local help and force ISE to get help directly from TechNet, see http://blogs.microsoft.co.il/blogs/scriptfanatic/archive/2009/01/31/using-help-in-powershell-ise.aspx. Microsoft recommends that you always check the online help to find the latest information and examples. The link to the online version can be found in the Related Links section when you use the Get-Help command.

Windows PowerShell Help

Figure 5-4 Windows PowerShell graphical help

Using Parameters

To find which parameters you can use with a cmdlet, type either Get-Help <cmdlet> or Get-Command <cmdlet> -syntax, where <cmdlet> is the name of the cmdlet you want parameter information about. For example, Get-Help New-SPSite or Get-Command New-SPSite -syntax will provide you with information about the parameters associated with New-SPSite. The Get-Help cmdlet also has several parameters associated with it, and depending on the amount of information you want, you can use them with the Get-Help command. If you know a cmdlet very well and do not want a descriptive explanation of what the cmdlet does, then you may simply want to see some examples of how to use the cmdlet, in which case you would type Get-Help New-SPSite -examples.

To learn about which parameters to use with a cmdlet, review the syntax section of the help results, as shown in the following output. Optional parameters are enclosed within square brackets ([ ]) and the values to be passed to the parameters are enclosed within angled brackets (<>). The following example shows the syntax section of the Get-SPSite cmdlet.

Copy Code
SYNTAX
    Get-SPSite [-AssignmentCollection <SPAssignmentCollection>]
    [-Confirm [<SwitchParameter>]] [-Filter <ScriptBlock>] [-Limit <String>]
    [-WebApplication <SPWebApplicationPipeBind>] [-WhatIf [<SwitchParameter>]]
    [<CommonParameters>]

    Get-SPSite -Identity <SPSitePipeBind> [-AssignmentCollection
    <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Filter <ScriptBlock>]
    [-Limit <String>] [-Regex <SwitchParameter>] [-WhatIf [<SwitchParameter>]]
    [<CommonParameters>]

    Get-SPSite -ContentDatabase <SPContentDatabasePipeBind> [-AssignmentCollection
    <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Filter <ScriptBlock>]
    [-Limit <String>] [-WhatIf [<SwitchParameter>]] [<CommonParameters>]

    Get-SPSite -SiteSubscription <SPSiteSubscriptionPipeBind> [-AssignmentCollection
    <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-Filter <ScriptBlock>]
    [-Limit <String>] [-WhatIf [<SwitchParameter>]] [<CommonParameters>]

Notice that there are four ways to use Get-SPSite, and each syntax has an -AssignmentCollection parameter. The -AssignmentCollection parameter relates to an important aspect of the built-in SharePoint cmdlet, which is examined in more detail in the sidebar titled "Memory Considerations When Using Windows PowerShell," which appears later in this chapter.

The first syntax example shown in the listing above has no mandatory parameter, so the Get-SPSite cmdlet would have a scope of the farm or Web application. The other three syntaxes have a mandatory parameter that defines the scope as site collection, content database, or collection of site collections that subscribe to shared settings, features, and services, as shown in the following code. As is the case with the other SPSite cmdlets, in a large installation, this cmdlet could output a large amount of information, and the queries to many content databases could severely affect the performance of the SharePoint servers. Therefore, by default, the output reports only on the first 20 objects.

You can alter this output limit by using the -limit parameter, as shown in the following example, which outputs all site collections that are stored in the Contoso_TeamsDB content database.

Get-SPSite -ContentDatabase Contoso_TeamsDB -limit all

You can provide the values for these scope parameters, or in the case of the -identity parameter, where the value is a URL, you can use the wildcard character (*). The default help with no parameter provides a limited description of the command.

For more information, use the -detailed or the -full parameter. The -full parameter provides additional information about the parameters. For example, additional information about the -identity parameter is shown on the following page.

Copy Code
PARAMETERS
    -Identity <SPSitePipeBind>
        Specifies the URL or GUID of the site collection to get.

        The type must be a valid URL, in the form http://server_name or http://
        server_name/sites/sitename, or a valid GUID (for example, 12345678-90ab
        -cdef-1234-567890bcdefgh).

        Required?                    true
        Position?                    1
        Default value
        Accept pipeline input?       True
        Accept wildcard characters?  false

If you look at the last five lines of the output, you see that it provides more information on how to use the -identity parameter. For example, the required value is equal to True, which indicates that the -identity parameter is a mandatory parameter for the Get-SPSite cmdlet. However, the position value is equal to 1, which means that if you place a URL of a site collection immediate after the Get-SPSite cmdlet, you do not have to use the -identity parameter because the URL will be read as the identity (URL) of a site collection, where all the property values for site collections that exist under the personal managed path are displayed, as shown in the following example.

Get-SPSite http://MySite/personal/* | Select *

Many of the parameters have a value enclosed in angle brackets, with the suffix PipeBind. This indicates that the parameter can accept an object variable of a specific type. For example, [-ContentDatabase <SPContentDatabasePipeBind>] means that the -ContentDatabase parameter can accept a SharePoint content database object, and this object can be passed to the ContentDatabase object either as a variable, or it can be piped in from the results of another cmdlet. When you pipe an object into a cmdlet, you do not need to type or use a variable. When you pipe an object from one cmdlet into another cmdlet, you do not have to specify the parameter, because Windows PowerShell checks the type of object and will match it to the correct parameter. The following example lists all site collections that are stored in any content databases that have the characters oso anywhere in their names.

Get-SPContentDatabase | where {$_.name -match "oso"} | Get-SPSite -Limit 50

Get-SPContentDatabase returns a collection of content databases, and then you need to check each content database to see if it matches our condition. The Where-object cmdlet, which has the aliases where or ?, acts like a loop, so it will check each content database object returned from the Get-SPContentDatabase cmdlet. The variable $_ represents one content database object, and .name is the content database property that needs to be matched for our query. The operator is -match.

Windows PowerShell has a number of operators, such as -eq (equal to), -ne (not equal to), -lt (less than), -ge (greater than or equal to), -like (matches a wildcard pattern), and -notlike (does not match a wildcard pattern). The -like, -notlike, -match, and -notmatch operators are used for pattern matching. The -match and -notmatch operators use regular expressions to determine whether a value does or does not contain a match for an expression.

Tip:

For more information on Windows PowerShell operators, see the section titled "Working with Expressions and Operators" in Chapter 5, "Navigating Core Windows PowerShell Structures," in Windows PowerShell 2.0, Administrator's Pocket Consultant, by William Stanek (Microsoft Press, 2009).

An alternative method to use instead of a WHERE statement is the -filter parameter, which uses the same syntax as the WHERE statement and can produce the same results. However, the -filter parameter executes on the server. Piping the results of the Get-SPContentDatabase cmdlet to the WHERE statement causes a SQL round trip to wherever the Windows PowerShell client is running. Using the -filter parameter can result in a faster performance, allowing the command to leverage the filtering abilities of SQL instead of attempting a local search. However, when you use the -filter parameter, only the Owner, SecondaryOwner, and LockState properties can be accessed for SPSite cmdlets. A number of cmdlets have other parameters that allow you to filter the resulting output. For example, SPWeb provides parameters to filter output on the template or title of the site (web). Still, in many cases the -filter parameter can save you time—for example, finding all the blog sites in a farm of 4300 webs takes about 1.2 seconds with the -filter parameter, but it takes approximately 15 minutes if you use a WHERE statement. Following are several examples that use the -filter parameter.

  • This example returns all site collections whose primary owner has the username peter.

    Get-SPSite -Filter {$_.Owner -eq "contoso\peter"}

  • This example returns all websites in the http://teams/sites/HR site collection that were created using the Blank Meeting Workspace template.

    Get-SPSite http://teams/sites/HR | Get-SPWeb -Filter {$_.Template -eq "STS#03"}

Note:

When you create a new site collection, if you do not specify a template or the template cannot be found, then you will need to create a website as the root of the site collection. You can do this by using the New-SPWeb command or by selecting the appropriate site template when you display the site collection for the first time in the browser.

To find details of the templates installed, together with the appropriate template ids, use the Get-SPWebTemplate cmdlet. A sample of the output of this command is shown here.

Copy Code
Name                 Title                                    LocaleId   Custom
----                 -----                                    --------   ------
GLOBAL#0             Global template                          1033       False
STS#0                Team Site                                1033       False
STS#1                Blank Site                               1033       False
STS#2                Document Workspace                       1033       False
MPS#0                Basic Meeting Workspace                  1033       False
MPS#1                Blank Meeting Workspace                  1033       False
MPS#2                Decision Meeting Workspace               1033       False
MPS#3                Social Meeting Workspace                 1033       False
MPS#4                Multipage Meeting Workspace              1033       False
CENTRALADMIN#0       Central Admin Site                       1033       False
WIKI#0               Wiki Site                                1033       False
BLOG#0               Blog                                     1033       False
SGS#0                Group Work Site                          1033       False
TENANTADMIN#0        Tenant Admin Site                        1033       False
ACCSRV#0             Access Services Site                     1033       False
ACCSRV#1             Assets Web Database                      1033       False
ACCSRV#3             Charitable Contributions Web Database    1033       False

On the Get-SPSite and Get-SPSiteAdministration, provide two other filters that use the SQL-driven filtering: the "Wildcard URLs" and regular expression (-RegEx) parameter, for example:

  • Get-SPSite http://intranet/sites/*

  • Get-SPSite "http://intranet/(sites|teams)/HR" -RegEx

Memory Considerations When Using Windows PowerShell

The default behavior of Windows PowerShell is that it runs a multithread environment and that each line, function, or script runs in its own thread ($host.Runspace.ThreadOptions == "Default"). This can cause memory leaks, but as you saw in the section titled "Working with the SharePoint 2010 Management Shell" earlier in this chapter, the SharePoint 2010 Management Shell runs each line, function, or script in the first thread ($host.Runspace.ThreadOptions ="ReuseThread"), which mitigates the problem—but memory leaks can still occur. Hence, the two SharePoint cmdlets that you should learn to use are the Start-SPAssignment and the Stop-SPAssignment. These relate to the -SPAssignmentCollection parameter that you may see used with a number of SharePoint cmdlets to return a "disposable object." In developer-speak, these are objects that implement the IDisposable Interface. If these objects are not disposed of correctly, they can cause memory leaks. In particular, this relates to the SPSite, SPWeb, and SPSiteAdministration objects. If you use cmdlets associated with these objects in one pipe and don't use variables to store the objects, the memory used is automatically disposed of at the end of a pipe. If you have a long pipe that obtains many objects, this can cause a shortage of memory on your SharePoint server, which then can have a noticeable effect on requests for pages from that server.

When you store any of the three objects in a variable, you then have to dispose of the memory assigned to that object. The following examples show the main methods of using these objects with variables and how to dispose of the memory.

  • Use the simple method of using the SPAssignment cmdlets, in which all objects are kept in a global memory store that is released when the Stop-SPAssignment cmdlet is called.

    Copy Code
    Start-SPAssignment -Global
$sc = Get-SPSite http://intranet
$sc.Title
Stop-SPAssignment -Global

  • Use the advanced method of using the SPAssignment cmdlet and tell it to track memory assigned to a specific variable. In the following example, the Start-SPAssignment cmdlet creates a named store that is pointed to by $o, and the variable $sc is associated with that named store and populated with information about the Internet site collection object. The Stop-SPAssignment cmdlet then releases the memory associated with the named store.

    Copy Code
    $o = Start-SPAssignment
$sc = $o | Get-SPSite http://intranet
Get-SPSite -Limit all
$sc.Title
$o | Stop-SPAssignment

  • If you are used to developing on the SharePoint platform, then you can use a similar technique to that which you use in your code to overcome this issue. For example, use variables within one Windows PowerShell line and dispose of them at the end of that line.

    Copy Code
    $sc = New-SPSite("http://Intranet"); $sc.Title; $sc.Dispose()

    This stores the site collection object in the variable $sc. The next command then prints out the title of the intranet site collection, and the last command releases the memory that stored the site collection object.

    Note:

    This same command can be run safely using the following syntax.

    New-SPSite(http://intranet) | Select Title

Be aware that the simple method of calling SPAssignment shown here also can cause memory problems. Any object you obtain between the Stop and Stop SPAssignment commands will be retained in the global assignment store and will not be released until the Stop-SPAssignment cmdlet is executed, whereas when you use the advanced method of calling SPAssignment, only the memory associated with variables you ask SPAssignment to track will be retained until the Stop-SPAssignment cmdlet is executed. Therefore, if you need to view large amount of information as you complete a task, and you do not want to starve the SharePoint server of memory, the advanced method of using SPAssigment is preferable. Use Get-Help About_SPAssignment to find more information.

cmdlets for SharePoint Foundation 2010

SharePoint Foundation 2010 contains over 240 SharePoint-related cmdlets. The exact number can be found by typing the following command.

@(Get-Command -PSSnapin "Microsoft.SharePoint.PowerShell").count

The most common objects that these cmdlets manipulate are the SPSite, SPServer, SPWeb, SPBusinessDataCatalogue, and SPConfigurationDatabase objects. Because Windows PowerShell is mainly an administrator's tool, and these are the components an administrator manages, this spread of cmdlet is not unexpected. These cmdlets also can be found in SharePoint 2010, which is built on top of SharePoint Foundation.

Tip:

The document "Microsoft SharePoint Foundation 2010 Cmdlet Reference" is included on this book's companion media. This document contains the output that you would see if you typed the following command in the SharePoint 2010 Management Shell.

Copy Code
PS C:\Users\Peter>Get-Command -PSSnapin Microsoft.SharePoint.PowerShell |
>>Sort Noun, Verb | Get-Help -detailed > CmdletHelp.txt
>><ENTER>

This command generates a list of cmdlet Help topics that is sorted by noun. This list contains the same Help for each cmdlet that you can view in the SharePoint 2010 Management Shell by typing the following command.

Get-Help <Cmdlet-Name> -detailed

The document contains help information that was current at the time that the document was produced. Microsoft recommends that you always check the online help to find the latest information and examples. You can find the link to the online version in the Related Links section when you use the Get-Help command.

cmdlets for SharePoint 2010

If you use the same Windows PowerShell command shown in the previous section to determine the number of cmdlets available in SharePoint 2010, you will find that there are more than 530 SharePoint-related cmdlets associated with SharePoint 2010. Specifically, that is the number of cmdlets associated with a full install of the Enterprise Edition of SharePoint 2010 without FAST Search installed. To identify the additional cmdlets that SharePoint provides, Windows PowerShell can help again. On a computer with both SharePoint Foundation and a version of SharePoint Server installed, type the following command, changing the name of the redirect file name to reflect the SharePoint installation.

Copy Code
PS C:\users\peter>Get-Command -PSSnapin "Microsoft.SharePoint.PowerShell" |
>> Sort noun, verb |group -Property noun -NoElement > cmdlet_sps.txt
>><Enter>

Copy the files to the same server and then type the following command.

Copy Code
PS C:\Users\Peter>Compare-Object -ReferenceObject $(Get-Content .\cmdlet_sps.txt) '
>>-DifferenceObject $(Get-Content .\cmdlet_spf.txt)
>><ENTER>

You will see output similar to the following example.

Copy Code
InputObject                                                 SideIndicator
-----------                                                 -------------
    8 SPContentDatabase                                     =>
    3 PluggableSecurityTrimmer                              <=
    3 SPAccessServiceApplica...                             <=
    9 SPContentDatabase                                     <=
    5 SPContentDeploymentJob                                <=
    4 SPContentDeploymentPath                               <=
    4 SPDataConnectionFile                                  <=
    1 SPDataConnectionFileDe...                             <=
    2 SPEnterpriseSearchAdmi...                             <=
    3 SPEnterpriseSearchLang...                             <=
    4 SPEnterpriseSearchMeta...                             <=
...

Only those objects that do not appear on both installations, and those for which the count of the number of cmdlets per object is different, will appear in this list. The SideIndicator column indicates from which file the object with its cmdlet count came.

In SharePoint 2010, the most common objects that are manipulated by cmdlets are similar to those in SharePoint Foundation. However, the main additional commands available in SharePoint 2010 are the 131 cmdlets that help you manage the search process. (There are only four cmdlets associated with searches for SharePoint Foundation). Type the following command to check this for yourself.

Copy Code
PS C:\Users\Peter>@(gcm -PSSnapin "Microsoft.SharePoint.PowerShell" |
>>where {$_.name -like "*search*"}).count
>><ENTER>

SharePoint 2010 contains more application services than SharePoint Foundation, such as Excel Services, InfoPath Services, Secure Storage, State Service, Microsoft Visio, and PerformancePoint. Therefore, on a SharePoint Server farm, there are more cmdlets that you can use to create, manipulate, and delete application service objects.

Performing Basic Administrative Tasks

There are two types of administrative tasks that are needed in a SharePoint installation: tasks that need to be completed once and from any server, such as creating a new Web application, configuring the primary owner of a site collection, or deleting a specific website; and tasks that need to be completed more than once on a specific server or on more than one server, such as starting a service on a server, adding or removing a server from the farm, or connecting the server to a specific configuration database. The majority of work you will need to complete as a SharePoint administrator is of the first type—it does not matter which server you are logged on to, because you can complete your work from any server.

Windows PowerShell makes it easier to complete both types of administrative tasks. You can loop around a large number of objects and incorporate the scripts into automated tasks so that administrative tasks can be completed in less time. Just because administrative tasks may be easy to complete using Windows PowerShell, however, you should not allow its use to circumvent the controls you may have in place. Some of these farm-wide tasks are very dangerous; they can affect the whole installation. In a production environment, such tasks should be under strict change management.

Important:

Many organizations allow administrative tasks to be completed only by using remote access to the production servers. Computer room access is strictly controlled, so interactive access at the server console is rarely allowed—usually only for hardware-related issues. In such environments, even remote access to the production servers is restricted to a small number of Administrative computers, which administrators have to connect to using a VPN or Remote Desktop. An Administrative computer should be configured to allow only certain users or IP addresses to instigate remote desktop sessions. If this is your scenario, remotely managing your SharePoint Installation using Windows PowerShell should also be restricted to that Administrative computer. Windows PowerShell has a number of built-in capabilities that can help you reduce the risk of tasks that affect the whole of a SharePoint installation; these were referred to in the section titled "Managing Systems Remotely with WinRM" earlier in this chapter.

Windows PowerShell provides a number of "voluntary" capabilities that could be classified as best practices. In the next sections, you will learn more about two of these, the -whatif parameter and transcripts.

Using the -whatif Parameter

Windows PowerShell is a powerful tool, and like any other scripting language, it is all too easy to borrow someone else's code or download snippets from the Internet. You might then execute them without knowing exactly what they do. Using signed scripts and the Windows PowerShell execution policy, as well as restricting who is allowed to load script files onto your SharePoint server, are ways that you can protect your resources.

Windows PowerShell provides a mechanism that allows you to try a command before you execute it—the -whatif parameter. Type the following command.

PS C:\Users\Peter> Get-SPSite http://teams/sites/* | Remove-SPSite -whatif

This command produces the following sample output that lists all site collections and the operation(s) that would be performed on these objects if you executed the command without the -whatif parameter.

Copy Code
What if: Performing operation "Remove-SPSite" on Target "http://teams/sites/Sales".
What if: Performing operation "Remove-SPSite" on Target "http://teams/sites/Blogs".
What if: Performing operation "Remove-SPSite" on Target "http://teams/sites/Finance".
What if: Performing operation "Remove-SPSite" on Target "http://teams/sites/Wikis".
What if: Performing operation "Remove-SPSite" on Target "http://teams/sites/HR".

Nothing has been deleted by trying the command with the -whatif parameter. The parameter tells the Remove-SPSite cmdlet to display the object that would be affected by the command without performing the command. In this example, it displays the objects that would be permanently deleted.

Generating Transcripts

A pair of Windows PowerShell cmdlets, Start-Transcripts and Stop-Transcripts, allows you to record all the commands that you type at the prompt, together with the output. All activity is recorded between the start and stop commands. If you do not type stop, the transcript is terminated when the console session is terminated. This could be very useful in your production environment, where the machine-wide profile contains the Start-Transcript cmdlet to record the Windows PowerShell activities of all users. The recording to the transcript file is complete when they exit the console.

Important:

Don't use a Windows PowerShell cmdlet or script for the first time in a production environment. Also, try to keep it simple—don't use or create aliases if scripts are going to be supported by administrators who are new to Windows PowerShell, and always use Windows PowerShell comments when you create or amend scripts.

Real World: What If You Don't Use the -whatif Parameter?

Sometimes even experienced IT professionals can use the built-in cmdlets incorrectly with serious consequences, especially when cmdlets are used in combination with the pipe character. For example, if you type Get-SPSite | Remove-SPSite, all site collections in your farm will be permanently deleted. Everything—all the data in your lists and libraries, and all the content in your websites—would simply be gone. One likely result of this action is that all your help desk telephone lines would immediately ring. If one of the websites that disappeared was your main e-commerce Internet website, your company could quickly lose a great deal of money, and perhaps more importantly, the company could lose potential customers who might never return. To restore your farm, you would need your latest good backup tapes. The lesson of this example is simple: always use the -whatif parameter first!

Examples of SharePoint Administrative Tasks

Many administrative tasks must be completed on a daily basis, some are needed only occasionally, and then there are those few that are rarely required. Windows PowerShell can help with all of these types of tasks; in fact, you may discover that it is more critical to script a rarely executed task than one you perform every day. This may be because you need to execute that rare task quickly and correctly, because the ramifications of making even a small mistake while completing the task could be catastrophic. Throughout this book, you will see many examples of when and how to use Windows PowerShell. In the following sections, you explore a few examples that you may not have seen elsewhere.

Tip:

There is a section of the Microsoft Script Center, http://gallery.technet.microsoft.com/ScriptCenter/en-us, that contains SharePoint-related scripts.

Deploying SharePoint 2010 with Windows PowerShell Scripts

During the lifetime of your SharePoint installation, there may be many tasks that you must complete (hopefully) only once, such as installing SharePoint and creating your farm. In large organizations with a variety of environments and many developers to support, however, you may find it prudent to develop scripts right from the outset that will build your SharePoint Web front-end (WFE) servers and your SharePoint applications servers, which host your applications services, such as InfoPath Services and search query and indexing services. In previous versions of SharePoint, you could complete such tasks using batch files and the SharePoint command-line tools psconfig and stsadm. You can still use these tools to automate the installation of your SharePoint 2010 and SharePoint Foundation 2010 servers. You will find more information about using these tools in Chapter 4, "Installing SharePoint 2010," so the details aren't repeated here. Microsoft has developed a script that is really the best practice for creating a SharePoint farm from scratch using Windows PowerShell. The order of these commands and parameters can be quite tricky, so Microsoft recommends that you use the Windows PowerShell module, SPModule, documented in the Microsoft's TechNet library article, Install SharePoint Server 2010 by using Windows PowerShell.

Tip:

For information about SharePoint automation and the use of psconfig, stsadm, and Windows PowerShell, see http://stsadm.blogspot.com/.

When you work on a SharePoint installation, you will need to merge the logs. The Windows operating systems provide you with event logs to help you with your administrative tasks, and you can use the Windows PowerShell Get-Eventlog cmdlet to obtain detailed information from those logs. SharePoint also provides the Unified Logging Service (ULS). The ULS contains all application log events, and third-party logging software can be integrated into them as well. SharePoint 2010 includes several Windows PowerShell cmdlets for retrieving information and configuring the ULS. To find how ULS is configured on your farm, type the following command. (The sample output for this command is also shown here.)

Get-SPDiagnosticConfig

Copy Code
AllowLegacyTraceProviders                   : False
CustomerExperienceImprovementProgramEnabled : True
ErrorReportingEnabled                       : True
ErrorReportingAutomaticUploadEnabled        : True
DownloadErrorReportingUpdatesEnabled        : True
DaysToKeepLogs                              : 14
LogMaxDiskSpaceUsageEnabled                 : True
LogDiskSpaceUsageGB                         : 3
LogLocation                                 : %CommonProgramFiles%\Microsoft Sh
                                             ared\Web Server Extensions\14\LOG
                                             S\
LogCutInterval                              : 30
EventLogFloodProtectionEnabled              : True
EventLogFloodProtectionThreshold            : 5
EventLogFloodProtectionTriggerPeriod        : 2
EventLogFloodProtectionQuietPeriod          : 2
EventLogFloodProtectionNotifyInterval       : 5
ScriptErrorReportingEnabled                 : True
ScriptErrorReportingRequireAuth             : True
ScriptErrorReportingDelay                   : 60
 AllowLegacyTraceProviders                   : FalseCustomerExperienceImprovementProgramEnabled : TrueErrorReportingEnabled                       : TrueErrorReportingAutomaticUploadEnabled        : TrueDownloadErrorReportingUpdatesEnabled        : TrueDaysToKeepLogs                              : 14LogMaxDiskSpaceUsageEnabled                 : TrueLogDiskSpaceUsageGB                         : 3LogLocation                                 : %CommonProgramFiles%\Microsoft Sh                                             ared\Web Server Extensions\14\LOG                                             S\LogCutInterval                              : 30EventLogFloodProtectionEnabled              : TrueEventLogFloodProtectionThreshold            : 5EventLogFloodProtectionTriggerPeriod        : 2EventLogFloodProtectionQuietPeriod          : 2EventLogFloodProtectionNotifyInterval       : 5ScriptErrorReportingEnabled                 : TrueScriptErrorReportingRequireAuth             : TrueScriptErrorReportingDelay                   : 60

When diagnosing a problem, you can use cmdlets associated with the SPLogEvent object. You need machine administrator privileges to run these cmdlets, so you may need to start SharePoint 2010 Management Shell using Run As Administrator. Then you would use commands in steps similar to those shown in the following example.

  1. Set up two variables to store the start day and the end date, for example.

    Copy Code
    $SDate = Get-Date -Day 13 -Month 04 -Year 2010
$EDate = Get-Date -Day 14 -Month 04 -Year 2010

    Or the date could be today's date, but the event occurred approximately 15 minutes earlier than the current time. In this case, you set the variable to 20 minutes before the current time and 10 minutes before the current time.

    Copy Code
    $SDate = (Get-Date).AddMinutes(-20)
$EDate = (Get-Date).AddMinutes(-10)

  2. Obtain a list of events between those two dates and times.

    Get-SPLogEvent -StartDate $SDate -EndTime $Edate

    If the -EndTime parameter is not provided, the event logs will be displayed up until the current date and time.

A tracking number, known as the Correlation ID, is associated with each request you make to SharePoint. This number is stored as a value in a property associated with the SPLogEvent object. SQL Profiler traces also show the Correlation IDs. This number is displayed on an Error page, as shown in Figure 5-5.

SharePoint Foundation error message

Figure 5-5 Error page showing the Correlation ID

In a large or heavily used SharePoint installation, many logs may be produced during the period when a problem occurs. You can use the Correlation ID to help troubleshoot errors by reducing the amount of log information that is returned to those entries that are associated with the incident. Again, set the $sdate and the $edate variables to reflect the time around the incident. For an incident that you can't reproduce and one of your users always can reproduce, you might tell the help desk to ask the user to take a screenshot of the error page so you can be sure to obtain the exact Correlation ID number. Then you can pipe the results of the command shown in step 2 to the Where-Object cmdlet, as shown in the following example.

Copy Code
PS C:\Users\Peter>Get-SPLogEvent -StartDate $SDate -EndTime $EDate |
  where {$_.Correlation -eq "68bc5cf4-5a8c-4517-a879-86e35e57c862"}

The output will display only event logs between the two dates that are related to the problem associated with that Correlation ID.

Managing SharePoint Services

After you have run the SharePoint 2010 Products Configuration Wizard to install SharePoint on your servers, you can use the SharePoint 2010 Central Administration website to launch the Farm Configuration Wizard. Although it will get you up and running very quickly, it might not configure your farm as you want; for example, the database names it creates will be in the format name_GUID, where GUID is a randomly generated, globally unique identifier. Also, the farm wizard uses the account entered as the Application Pool Identity for the default content Web application and starts the Web Analytics Service by default—both of which may not be desirable on a production farm.

Using the wizard may be sufficient if you want to create a quick prototype or perhaps if you are using SharePoint in a developer environment. However, if any of those environments are limited in their CPU power or in the amount of memory they have, the farm wizard may not be suitable either. For example, the Web Analytics Service uses a large amount of CPU, so your developers might be interested in stopping that service. There are other services that they might want to start and stop on a regular basis, especially if they are using their computers as their day-to-day desktop connections, where they read e-mails and complete documentations, as well as to run SharePoint for development or prototyping.

You can use tools such as the Central Administration website to manage the configuration; however, you may forget to execute all the tasks necessary to complete a configuration change. Instead, you can use Windows PowerShell scripts, which—after you have tested them to make sure that you have not forgotten any tasks—should make managing configuration changes more reliable and error free. You should store these scripts in a central location after they are developed, to make them convenient for fellow administrators to use and incorporate in their environments. Your developer may also thank you for developing these scripts. Such automated tasks might include the following items.

  • To quickly delete a specific Web application, type

    Get-SPWebApplication http://teams | Remove-SPWebApplication -Confirm

  • To remove the Web application, the IIS website, and all the associated databases, type

    Remove-SPWebApplication http://teams -Confirm -DeleteIISSite ' -RemoveContentDatabases

If you do not run the Farm Configuration Wizard, you might find that you need a service that you originally thought you would not need. For example, if no application services are started, and then you try to use one of the SharePoint 2010 workflows, the Microsoft Visio diagram of the workflow progress will not be displayed. However, to solve this problem, you must do more than just create the Visio Application Service. There are other dependencies involved, one of which is the State Service Application. The state services can only be created in the Central Administration site, by using the farm wizard—something you will want to avoid as an administrator. To create the state service using Windows PowerShell, type the following commands.

Copy Code
PS: C:\Users\Peter>New-SPStateServiceDatabase -Name Contoso_StateService_DB |
>>New-SPStateServiceApplication -Name Contoso_StateService |
>>New-SPStateServiceApplicationProxy -Name Contoso_StateService_Proxy -Default
>><ENTER>
Note:

This command may not work in your environment if the associated service instance is not running. For a more comprehensive script, see "SP+PS 2010: PowerShell to Create a Service Application" at http://sharepoint.microsoft.com/blogs/zach/Lists/Posts/Post.aspx?ID=50.

Each service application is slightly different. For example, not all service applications require a database. Chapter 7 "Scaling Out a SharePoint Farm," contains more information about this. However, each service will require a service application proxy, which connects a Web application to the service application.

Using Windows PowerShell During the Upgrade Process

The following sections provide information about some Windows PowerShell commands you might find useful during an upgrade. The upgrade process is explained in more detail in Chapter 22, "Upgrading to SharePoint 2010."

Preparing for an Upgrade

After installing SharePoint 2010 and before upgrading, you can use the Test-SPContentDatabase cmdlet to check your SharePoint Server 2007 databases for current or potential issues, such as orphan data, missing site definitions, missing features, or missing assemblies. This cmdlet complements the pre-upgrade checker report mentioned in Chapter 22. Checking for these issues does not disrupt your SharePoint installation, and this cmdlet can also test the status of SharePoint 2010 databases, which can assist you in maintaining the continued health of your environment. The following example shows the command and its sample output.

Test-SPContentDatabase -name W_intranet -WebApplication http://www.contoso.msft

Copy Code
Category        : SiteOrphan
Error           : True
UpgradeBlocking : False
Message         : Database [W_intranet] contains a site (Id = [46ad6d70-9a5c-4d
                  e0-8daa-0f73f2466a6a], Url = [/]) whose id is already associa
                  ted with a different database (Id = [6987d2d8-6291-4ead-9eb0-
                  aefe7097a58e], name = [W_Intranet]) in the site map. Consider
                  deleting one of these sites which have conflicting ids.
Remedy          : The orphaned sites could cause upgrade failures. Try detach a
                  nd reattach the database which contains the orphaned sites. R
                  estart upgrade if necessary.

Category        : SiteOrphan
Error           : True
UpgradeBlocking : False
Message         : Database [W_intranet] contains a site (Id = [46ad6d70-9a5c-4d
                  e0-8daa-0f73f2466a6a], Url = [/]) whose url is already used b
                  y a different site, in database (Id = [6063e77c-991f-4c4b-b3a
                  c-68cb62e66502], name = [w_Internet]), in the same web applic
                  ation. Consider deleting one of the sites which have conflict
                  ing urls.
Remedy          : The orphaned sites could cause upgrade failures. Try detach a
                  nd reattach the database which contains the orphaned sites. R
                  estart upgrade if necessary.

Performing Post-Upgrade Tasks

The upgrade process is divided into two components, the content database upgrade and the visual upgrade. By separating these two components, your SharePoint team can decide to upgrade the Microsoft Office SharePoint Server 2007 Web application without users noticing the change, because their sites will maintain the old look and feel. Using the browser, they can preview what their site looks like with the new SharePoint 2010 look and feel and then decide when they permanently want to switch to the visual upgrade. After they make the switch, the browser will not allow them to switch back to the SharePoint Server 2007 look and feel.

The Set-SPWeb cmdlet does not have any parameter to help with this task; you will need to use the properties of the SPWeb object to complete this task. Type the following commands if you want to switch sites back to the old look and feel.

Copy Code
Start-SPAssignment -Global
$web = Get-SPWeb http://teams ;
$web.UIVersion = 3;
$web.UIVersionConfigurationEnabled = $true;
$web.Update();
Stop-SPAssignment
Note:

Previously in this chapter, you created variables to store values and objects. Variable names are prefixed with the dollar sign, $. In the sample code shown here, you will see $true used. This, together with a number of other keywords that look like variables, is an example of a special variable. A special variable should be treated as a reserved word that you cannot use in your scripts to store values or object. The special variable $true represents the value True, $false represents False, $null represents null, and $_ also has been used in this chapter and contains the current pipeline object. It is used in script blocks, filters, and the Where cmdlet.

After you run these commands, the website will revert to the SharePoint Server 2007 look and feel. The Site Actions button will be in the upper-right corner, for example, instead of in the upper-left corner. The Site Actions menu will have the Visual Upgrade option available, although the Visual Upgrade option at the site collection level may not be enabled. To enable the Visual Upgrade option at the site collection level, use the following commands.

Copy Code
$site = Get-SPSite http://teams
$site.UIVersionConfigurationEnabled = $true

When updating the properties of the SPSite object, there is no update method; the changes to the SPSite properties take effect immediately. You could type the following line as an alternative to the previous two lines of commands.

Copy Code
(Get-SPSite http://teams).UIVersionConfigurationEnabled = $false

To reset all "team" websites within a site collection back to the SharePoint Server 2007 look and feel, use the following command.

Copy Code
PS C:\Users\zzspfarm> Get-SPsite http://teams |
>> Get-SPWeb -Filter {$_.Template -eq "STS#0}|
>> ForEach-Object {
>> $_.UIVersion =3;
>> $_.UIVersionConfigurationEnabled = $false;
>> $_.Update();
>> }
>><ENTER>
Note:

These commands also can be run on a site or site collection that has not been upgraded—that is, on a site that was created as a version 4 site, thereby making a SharePoint 2010 site look like a SharePoint 2007 site.

Summary

This chapter explains how you can become familiar with the new Windows PowerShell cmdlets introduced by SharePoint 2010. It explores the SharePoint 2010 Management Shell and how to accomplish some simple but powerful administrative tasks using one-line Windows PowerShell commands.

There are more than 500 SharePoint cmdlets. This chapter could not possibly explain each command; instead, its aim was to provide some general guidelines and good practices for using SharePoint PowerShell in a production environment, such as the configuration and use of remote management, the voluntary use of transcripts, and the use of the -whatif parameter. You should not practice or try out Windows PowerShell commands for the first time on your production environment. Keep your scripts simple, use comments to document your scripts, and don't use or create aliases if the scripts are going to be supported by administrators who are unfamiliar with Windows PowerShell.

The chapter covered two important cmdlets, Start-SPAssignment and Stop-SPAssignment, in some detail. These cmdlets help with cmdlets that return disposable objects, such as SPSite, SPWeb, and SPSiteAdministration. Other SharePoint cmdlets were introduced to expand your knowledge of Windows PowerShell techniques. Chapter 12 builds on this chapter, using search scenarios. The next chapter continues the discussion of SharePoint 2010 farm management and specifically the Central Administration interface.


System Center Operations Manager knowledge articles (SharePoint Foundation 2010)

The articles in this section are knowledge articles for the Microsoft SharePoint Foundation 2010 management pack for Microsoft System Center Operations Manager 2007. Typically, you would see these articles after clicking a link in an alert in the Operations Manager console. You can use these articles to help you troubleshoot and resolve problems in SharePoint Foundation 2010.

In this section:

  • ULS not enough storage for log directory - Event 2150 (SharePoint 2010 Products)

  • Event log flooding - Events 2158 2159 (SharePoint 2010 Products)

  • SQL Server database login failed - Event 3351 (SharePoint 2010 Products)

  • Backup failed due to insufficient permissions - Event 3353 (SharePoint 2010 Products)

  • Cannot connect to SQL Server - Event 3355 (SharePoint 2010 Products)

  • The application pool account cannot add user accounts to Active Directory - Event 3359 (SharePoint 2010 Products)

  • Active Directory organization unit unregistered - Event 3360 (SharePoint 2010 Products)

  • SQL Server database is full - Event 3758 (SharePoint 2010 Products)

  • Database could not be accessed - Event 3760 (SharePoint 2010 Products)

  • Content deployment job failed - Events 4958 5323 5325 5335 (SharePoint 2010 Products)

  • Content database is Read-Only - Event 4971 (SharePoint 2010 Products)

  • Insufficient SQL Server database permissions - Event 5214 (SharePoint 2010 Products)

  • Unable to write to trace log - Event 5401 (SharePoint 2010 Products)

  • Unknown SQL exceptions - Event 5586 (SharePoint 2010 Products)

  • SharePoint Foundation failed to create a site - Event 6141 (SharePoint 2010 Products)

  • Unable to load authentication provider - Event 6143 (SharePoint 2010 Products)

  • Insufficient permissions to write to the configuration data cache - Event 6395 (SharePoint 2010 Products)

  • Alternate access mapping update failed - Event 6397 (SharePoint 2010 Products)

  • Service Instance timer execution failed - Event 6398 (SharePoint 2010 Products)

  • ULS not enough free disk space - Event 6457 (SharePoint 2010 Products)

  • Access denied for writing to registry - Event 6588 (SharePoint 2010 Products)

  • Access denied for writing to disk - Event 6589 (SharePoint 2010 Products)

  • Application pool account must be registered as Kerberos - Event 6590 (SharePoint 2010 Products)

  • SMTP service not running - Event 6599 (SharePoint 2010 Products)

  • Event handler failed to load - Event 6644 (SharePoint 2010 Products)

  • Product Help Library Permission - Event 6769 (SharePoint 2010 Products)

  • Cannot resolve name of the outbound SMTP server - Event 6856 (SharePoint 2010 Products)

  • Cannot connect to SMTP host - Event 6857 (SharePoint 2010 Products)

  • Error occurred while communicating with SMTP server - Event 6858 (SharePoint 2010 Products)

  • SharePoint lists cannot receive e-mail - Event 6872 (SharePoint 2010 Products)

  • E-mail service cannot deliver e-mail - Event 6873 (SharePoint 2010 Products)

  • Event receiver failed - Event 6875 (SharePoint 2010 Products)

  • Backup timer job could not be created - Event 7035 (SharePoint 2010 Products)

  • Central Administration update failed - Event 7037 (SharePoint 2010 Products)

  • Throttling starts alert- Events 8032 8062 (SharePoint 2010 Products)

  • Cannot retrieve end point - Event 8070 (SharePoint 2010 Products)

  • Log folder does not exist - Event 8074 (SharePoint 2010 Products)

  • Usage timer job failed - Event 8075 (SharePoint 2010 Products)

  • Business Data Connectivity Service - BDC database adapter connection exception - Event 8080 (SharePoint 2010 Products)

  • Business Data Connectivity Service - BDC Web service proxy generations exception - Event 8082 (SharePoint 2010 Products)

  • Business Data Connectivity Service - BDC Proxy - unexpected exception - Event 8085 (SharePoint 2010 Products)

  • Business Data Connectivity Service - SQL exception - Event 8086 (SharePoint 2010 Products)

  • ULS trace log reaching maximum size - Event 8094 (SharePoint 2010 Products)

  • ULS usage log reaching maximum size - Event 8095 (SharePoint 2010 Products)

  • STS signing certificate missing - Event 8303 (SharePoint 2010 Products)

  • STS cannot sign credentials - Event 8304 (SharePoint 2010 Products)

  • Claims cannot establish endpoint - Event 8305 (SharePoint 2010 Products)

  • STS claims provider error - Event 8307 (SharePoint 2010 Products)

  • Administration service is not running (SharePoint 2010 Products)

  • Document conversion launcher unavailable (SharePoint 2010 Products)

  • Document conversion load balancer unavailable (SharePoint 2010 Products)

  • Knowledge article is not yet available (SharePoint 2010 Products)

  • Sandboxed code is running (SharePoint 2010 Products)

  • SharePoint Administration service is disabled (SharePoint 2010 Products)

  • SharePoint Foundation 2010 search is not running (SharePoint 2010 Products)

  • SharePoint Health Analyzer has detected an error or warning (SharePoint 2010 Products)

  • SharePoint Timer service could not start (SharePoint 2010 Products)

  • SharePoint Timer service is not running (SharePoint 2010 Products)

  • SQL Server remote access is disabled (SharePoint 2010 Products)

  • Tracing service is not running (SharePoint 2010 Products)

  • Web application taking too long to render a page (SharePoint 2010 Products)

  • Web application unavailable (SharePoint 2010 Products)

  • Web site unavailable (SharePoint 2010 Products)


ULS not enough storage for log directory - Event 2150 (SharePoint 2010 Products)

Alert Name: ULS not enough storage for log directory

Event ID: 2150

Summary: The Microsoft SharePoint Foundation Tracing (SPTracev4) service is used by Microsoft SharePoint Foundation 2010 to manage usage log output. When usage logging is turned on, administrators can specify the path that is used to store the usage logs. This log file is used by many applications that are built on top of SharePoint Foundation 2010. This event occurs when not enough free space is available for logging.

Symptoms: One or more of the following symptoms might appear:

  • The usage log shows no new usage data.

  • This event appears in the event log: Event ID: 2150 Description: Failed to create a usage log file at <Log Location>. There must be at least <# of GBs needed to resume logging> GB of free space if the usage logs are on System Drive.

Cause: The configured log location does not have enough free disk space for logging.

Resolution: Free up disk space or relocate the usage log

  • SharePoint Foundation 2010 could not write to the usage log. This usage log contains information that is helpful for usage tracking and reporting.

    To free up disk space:

    1. Use Disk Cleanup to free up disk space where the usage log files are stored.

    2. Verify whether the trace log has enough disk space to run properly.

    3. If disk space is inadequate, try to clean the Temp folders on the drive.

    4. If this procedure does not solve the problem, you can relocate the usage log file to a partition that has more drive space.

    To relocate the log file:

    1. On the SharePoint Central Administration Web site, on the Quick Launch, click Monitoring and in the Reporting section click Usage Logging.

    2. On the Usage Logging page, in the Logging Settings section, type the new location for the usage log file.

    3. Click OK.

    To check the usage log file:

    1. To verify that Microsoft SharePoint Foundation 2010 can create and write to the usage log file, on the Central Administration page click Monitoring, and in the Reporting section click Usage Logging.

    2. On the Usage Logging page, in the Logging Settings section, copy the path of the usage log file.

    3. In Windows Explorer, navigate to the usage log file by using the copied path. Usage log files are in binary format and the contents cannot be easily viewed and understood. The file size of the usage log increases over time and confirms that usage logging is working.


Event log flooding - Events 2158 2159 (SharePoint 2010 Products)

Alert Name: Event log flooding

Event ID: 2158 or 2159

Summary: Event log flood protection prevents repeated events from being logged to the Windows event log. When an event is logged several times in a short period, flood protection prevents future events of the same type from being logged.

Symptoms: This event appears in the event log: Event ID: 2158 or 2159 Description: Event [Event ID] ([Event Provider Name]) of severity [Event Severity] occurred [Number of occurrences] more time(s) and was suppressed in the event log.

Cause: The same event is being logged repeatedly, triggering event log flood protection. You can identify which event is being logged repeatedly in the Event Description text of Event ID 2158 or 2159.


SQL Server database login failed - Event 3351 (SharePoint 2010 Products)

Alert Name: SQL Server database login failed

Event ID: 3351

Summary: Microsoft SharePoint Foundation uses Microsoft SQL Server 2008 databases to store most of the content for SharePoint Foundation Web sites and configuration settings, and uses a service account to communicate with the database on behalf of a user request. Note that a Web application might be associated with one or many databases. This error — SQL Server database login failed — means that SharePoint Foundation cannot log on to SQL Server 2008 by using the specified service account user name and password.

Symptoms: The following symptom might appear:

  • This event appears in the event log: Event ID: 3351 Description: SQL database login failed. Additional error information from SQL Server is included below.

Cause: The user name or password for the Microsoft SharePoint Foundation service account was invalid before the session or became invalid during the session.

Note:

You must be a member of the Farm Administrators SharePoint group to perform the following procedures.

Resolution: Grant correct permissions to the database access account

  • To resolve this issue, assign the database access account and then verify that the account has correct permission in SQL Server.

    To assign the database access account:

    1. On the Central Administration Web page, on the Quick Launch, click Security, and in the General Security section click Configure service accounts.

    2. In the Credential Management section, in the upper drop-down list click the correct Web application pool for your Web application.

    3. In the Select an account for this component drop-down list, click the domain account with which you want to associate this Web application pool, or click Register new managed account to associate a new domain account with this application pool.

    4. Click OK to save changes.

    To verify that the account has correct permissions in SQL Server:

    1. Connect to the computer that is running SQL Server by using an account with Administrator permissions.

    2. In SQL Server Management Studio, in the Object Explorer navigation pane, expand the Security node, and then click the Logins node. The name of the database access account indicates that it is a SQL login.

    3. If the account exists, in the Object Explorer navigation pane, expand the Databases node, expand the configuration database node (for example, WSS_Config), expand the Security node, and then click Roles.

    4. Expand the Database Roles node, right-click db_owner, and select Properties.

    5. In the Database Roles Properties dialog box, check whether the database access account is in the Members of this role list. If the account is not listed, click Add.

    To verify that any database issues have been resolved:

    1. In the SharePoint Management Shell, run the Windows PowerShell command Get-SPSite | Format-Table -Property ID,WebApplication,ContentDatabase to obtain a list of the sites for each Web application to list all sites in the various databases, and locate one site in each database.

    2. Browse to the site.


Backup failed due to insufficient permissions - Event 3353 (SharePoint 2010 Products)
See Also

Alert Name: Backup failed due to insufficient permissions

Event ID: 3353

Summary: This error occurs when the account that is performing the backup does not have sufficient permissions to write to the backup folder.

When you back up a Web application, you back up the content databases and settings for the Web application, including all sites in the site collections, files in document libraries, files attached to lists, security and permission settings, and feature settings. The backup process creates files that contain all of this data.

Similarly, when you back up a site collection, site, or list, the contents of those structures will be written to files or packages, and the restore or import process will use these files to recover the objects.

Symptoms: This event might appear in the event log: Event ID: 3353 Description: Unable to write to the backup folder.

Cause: One or more of the following might be the cause:

  1. The SQL Server service account does not have Full Control access to the backup folder.

  2. The SharePoint Timer Service account does not have Full Control access to the backup folder.

  3. If the backup or restore was performed by using Windows PowerShell, the user who performed the backup operation did not have Full Control access to the backup folder.

Resolution: Verify permissions

  • Ensure that the following are given the Full Control file share and NTFS permissions for the backup shared folder:

    • The account used by the SQL Server service account.

    • The Windows SharePoint Services Timer V4 (SPTimerV4) account.

    • The logged on account, if you are using Windows PowerShell to perform the backup or restore.

    • If the backup folder is a network share, ensure that all accounts that are listed above have access to both the share and the folder itself.

    • If you are performing a backup or restore operation between two SharePoint farms, services on both farms must have the permissions described above.

  • For more information, see Configuring permissions for backup and recovery (SharePoint Foundation 2010).

See Also

Concepts

View diagnostic logs (SharePoint Foundation 2010)


Cannot connect to SQL Server - Event 3355 (SharePoint 2010 Products)

Alert Name: Cannot connect to SQL Server

Event ID: 3355

Summary: Microsoft SharePoint Foundation 2010 uses Microsoft SQL Server 2008 databases to store configuration settings and most of the content for the Microsoft SharePoint Foundation Web site. For example, all pages in the site, files in document libraries, files attached to lists, and information in lists are stored in the content database, and security and permission settings along with other configuration settings are stored in the configuration database in SQL Server.

SharePoint Foundation 2010 uses a service account to communicate with the database on behalf of a user request. This service account can be either a specific user name or password (domain name and password), or a predefined system account, such as Local System or Network Service. When a SQL Server database is created, a value for the maximum database size is set. Each database has a separate database size setting. Note that a Web application might be associated with one or many databases.

This error indicates that Microsoft SharePoint Foundation could not connect to the SQL Server database.

Symptoms: One or more of the following symptoms might appear:

  • Attempts to communicate with SQL Server fail and no content from databases hosted on the SQL Server can be accessed.

  • This event appears in the event log: Event ID: 3355 Cannot connect to SQL Server. <Server Name> not found. Additional error information from SQL Server is included below.

Cause: One or more of the following might be the cause:

  1. The SQL Server might be offline.

  2. The SharePoint Foundation database access account might not have the necessary permissions to communicate with the SQL Server.

  3. A firewall that runs on either the local server or on SQL Server might be blocking network communications.

Resolution: Grant correct permissions to the database access account

  • You must be a member of the Farm Administrators group to perform this task.

    Assign the database access account:

    1. On the Central Administration home page, click Security and in the General Security section click Configure service accounts.

    2. On the Service Accounts page, in the Credential Management section, in the upper drop-down list click the correct Web application pool for your Web application.

    3. In the Select an account for this component drop-down list, click the domain account that you want to associate with this Web application pool, or click Register new managed account to associate a new domain account with this application pool.

    4. Click OK to save changes.

    Verify that the account has correct permissions in SQL Server:

    1. Connect to the computer that runs SQL Server by using an account that has Administrator permissions.

    2. In SQL Server Management Studio, Object Explorer navigation pane, expand the Security node, and then expand the Logins node. The name of the database access account indicates that it is a SQL login.

    3. If the account exists, in the Object Explorer navigation pane, expand the Databases node, expand the configuration database node, expand the Security, and then click Roles.

    4. Expand the Database Roles node, right-click db_owner role and select Properties.

    5. In the Database Role Properties dialog box, check whether the database access account is in the Members of this role list. If the account is not listed, click Add.

    Verify that any database issues are resolved:

    1. In the SharePoint Management Shell, run the Windows PowerShell command Get-SPSite | Format-Table -Property ID,WebApplication,ContentDatabase to obtain a list of the sites for each Web application to list all sites in the various databases, and locate one site in each database.

    2. Browse to that site, and ensure that the appropriate page rendered. An Access Denied page with an option to request access, or the option to log on as a different user, indicates that the operation completed successfully.

    3. On the Central Administration page, on the Quick Launch, click Application Management and in the Site Collections section click Specify quota templates.

    4. On the Quota Templates page, create a new quota template. The specific settings are not relevant to this verification test. You are creating the template to verify that it can be accessed in step 7.

    5. Click OK to save the quota template.

    6. Refresh the browser window, and then return to the Quota Templates page. If the quota template that you created can be selected, access to the SQL Server 2008 configuration database in Microsoft SharePoint Foundation is restored.

    7. Click Delete to delete the quota template.


The application pool account cannot add user accounts to Active Directory - Event 3359 (SharePoint 2010 Products)

Alert Name: The application pool account cannot add user accounts to Active Directory

Event ID: 3359

Summary: The Internet Information Services (IIS) application pool creates identities based on Active Directory users, and associates these identities by using a set of permissions. This lets users in an Active Directory organizational unit (OU) inherit those permissions.

Symptoms: One or more of the following symptoms might appear:

  • Account creation mode does not work correctly, which prevents user data from being added or read.

  • User accounts are not automatically created in Active Directory.

  • The event appears in the event log: Event ID: 3359 Description: The application pool account has insufficient permissions to add user accounts to Active Directory.

Cause: The account that is used by the application pool does not have the appropriate level of permissions that are required to add new user accounts to Active Directory.

Resolution : Determine the OU in which the application pool account creates new user accounts

  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. At the Windows PowerShell command prompt, type the following:

    Copy Code
    $wa=Get-SPWebApplication
$wa.Parent.CreateActiveDirectoryAccounts
$wa.Parent.ActiveDirectoryDomain
$wa.Parent.ActiveDirectoryOrganizationalUnit
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.

Resolution: Add the correct permissions to the OU

  1. On a server that has the Active Directory tools installed, open the Active Directory Users and Computers snap-in as a user who has sufficient domain permissions, such as domain administrator. To open Active Directory Users and Computers, click Start, click Run, and then type dsa.msc.

  2. In the console tree, right-click the OU for which you want to delegate control.

  3. Click Delegate Control to start the Delegation of Control Wizard, and then follow the instructions in the wizard.

  4. In the Welcome pane, click Next.

  5. In the Users and Groups pane, click Add.

  6. In the Enter the object names to select box, type the user name that you plan to use for the administration application pool identity, and then click OK.

  7. Click Next.

  8. In the Tasks to Delegate pane, select the Create, delete, and manage user accounts and Read all user information check boxes, and then click Next.

  9. Click Finish.


Active Directory organization unit unregistered - Event 3360 (SharePoint 2010 Products)

Alert Name: Active Directory organization unit (OU) unregistered

Event ID: 3360

Summary: This error indicates that the Active Directory organizational unit (OU) that was created for account creation mode does not exist.

Symptoms: One or more of the following symptoms might appear:

  • Account creation mode does not work correctly, which prevents user data from being added or read.

  • This event appears in the event log: Event ID: 3360 Description: The Active Directory organization unit <OU Name> registered in Windows SharePoint Services 4.0 does not exist.

Cause: This can occur due to an error during provisioning or a run-time error that either caused the OU specified during farm configuration to not be created, or caused it to be renamed or deleted. Until this OU is created and registered, you cannot create a new site collection or add additional users.

Resolution: Add the OU to Active Directory

  • You must be logged on as a domain administrator to perform this procedure.

  • Click Start, click Run, and then type dsa.msc.

  • Expand the Domains node.

  • Right-click the domain, click New, and then click Organizational Unit.

  • Type the OU name from event 7037 in the <insert OU here> box.

  • Right-click the OU, and then click Delegate Control.

  • Add the application pool account for the Web application that is being used for account creation.

  • Click Create, delete, and manage accounts.

  • Click Next.

  • Click Finish.


SQL Server database is full - Event 3758 (SharePoint 2010 Products)

Alert Name: SQL Server database is full

Event ID: 3758

Summary: Microsoft SharePoint Foundation uses Microsoft SQL Server 2008 databases to store most of the content for SharePoint Foundation Web site and configuration settings, and uses a service account to communicate with the database on behalf of a user request. When a SQL Server database is created, a value for the maximum database size is set. Each database has a separate database size setting. Note that a Web application might be associated with one or many databases. This error indicates that the database has reached the size of its maximum size setting.

Symptoms: The following symptom might appear:

  • Users cannot add or update any content in SharePoint Foundation.

  • Administrators cannot update any SharePoint Foundation settings.

  • This event appears in the event log: Event ID: 3758 Description: Database full error on SQL Server instance <instance name> in database <database name>. Additional error information from SQL Server is included below. <SQL error message>

Cause: The database has reached its maximum size.

Note:

You must be a member of the Farm Administrators SharePoint group to perform the following tasks.

Resolution: Increase the size of the SQL Server database

  • SharePoint Foundation cannot write to a database that has reached its maximum size. Increase the maximum size setting for the full database that is named in the event message.

    To increase the database size:

    1. In SQL Server Management Studio, in the Object Explorer navigation pane, expand the server node, and then expand the Databases node.

    2. Right-click the database you want, and then click Properties. The database name is provided in the event message.

    3. In the Database Properties dialog box, in the navigation pane, click Files.

    4. In the Database files section, in the Autogrowth column, click the ellipsis for the database file.

    5. In the Change Autogrowth dialog box, in the Maximum File Size section, if the Restricted File Growth option is selected, increase the maximum file size in the box to the right. You can also configure the database to grow without restrictions by selecting the Unrestricted File Growth option.

    6. Click OK to save changes.

    To verify that database issues are resolved:

    1. In the SharePoint Management Shell, run the Windows PowerShell command Get-SPSite | Format-Table -Property ID,WebApplication,ContentDatabase to obtain a list of the sites for each Web application to list all sites in the various databases, and locate one site in each database.

    2. Browse to the site.

    3. Try to add content to the site. For example, add a list item or a document. SharePoint Foundation uses different errors under different editing circumstances, so if adding content to the site fails, check the event log for an error message such as those in the following table.

      Log Name:

      Application

      Source:

      Microsoft-Windows SharePoint-Windows SharePoint Services 4

      Date:

      4/2/2009 6:34:13 AM

      Event ID:

      3758

      Task Category:

      Database

      Level:

      Critical

      Keywords:

      User:

      Domain\Myuser

      Computer:

      MyServer

      Description:

      Database full error on SQL Server instance 'CO137' in database 'wss_2'. Additional error information from SQL Server is included below. Could not allocate space for object 'dbo.AllDocs'.'AllDocs_Url' in database 'wss_2' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.


Database could not be accessed - Event 3760 (SharePoint 2010 Products)

Alert Name: Database could not be accessed

Event ID: 3760

Summary: Microsoft SharePoint Foundation 2010 uses Microsoft SQL Server 2008 databases to store most of the content for the Web site and configuration settings. For example, all pages in the site, files in document libraries, files attached to lists, and information in lists are stored in the content database, and security and permission settings along with other configuration settings are stored in the configuration database in SQL Server.

SharePoint Foundation 2010 uses a service account to communicate with the database on behalf of a user request. This service account can be either a specific domain name/user name and password, or a predefined system account, such as Local System or Network Service. When a SQL Server database is created, a value for the maximum database size is set. Each database has a separate database size setting. Note that a Web application might be associated with one or many databases.

Symptoms: The following symptoms might appear:

  • Content in the database is not available and attempts to access the database generate errors.

  • This event appears in the event log: Event ID: 3760 Description: SQL Database '<database name>' on SQL Server instance '<instance name>' not found. Additional error information from SQL Server is included below. <error information>

Cause: One or more of the following might cause this:.

  • The SQL Server user login failed.

  • The database has been deleted or renamed.

  • The database is currently unavailable because it is in an offline or loading state.

Important:

You must be a member of the local Administrators group to perform this task.

Resolution: Verify that SQL Server is running

  • On the database server, in the Services snap-in, verify that the SQL Server (MSSQLSERVER) service is running.

Resolution: Verify that the user account can connect to SQL Server

  • Log onto Microsoft SQL Server Management Studio as the account provided in the error details and click Connect and then Database Engine.

  • Type the server name provided in the error details and click Connect.

Resolution: Verify that the database exists

  • In Microsoft SQL Server Management Studio, expand the server node.

  • Expand the Databases node.

  • Verify that the database exists.

Note:

You must be a member of the Farm Administrators SharePoint group to perform these tasks.

Resolution: Restore database

  • If the SQL Server database is not present or accessible on the computer that is running SQL Server, restore the database from a backup and reconnect it to SharePoint Foundation 2010.

    To restore the database from a backup:

    1. On the SharePoint Central Administration Web site, click Backup and Restore and in the Farm Backup and Restore section click Restore from a backup.

    2. On the Restore from Backup page, type the backup path in the Backup Directory Location text box, select the backup you want to restore, and then click Next.

    3. Select the database from the list and then click Next.

      Important:

      The backup must include the database and the accompanying Web application.

    4. In the Restore Options section, select the Same configuration option. This action overwrites the existing database.

    5. Click Start Restore.

    To reconnect the database in Central Administration:

    1. On the Central Administration page, click Application Management and in the Databases section click Manage Content databases.

    2. On the Manage Content Databases page, click Add a content database and in the Web Application section select the Web application.

    3. Under Database Name and Authentication, type the name of the server in the Database Server text box and type the database name in the Database Name text box.

    4. Click OK to save the changes.

    To verify that any database issues have been resolved:

    1. In the SharePoint Management Shell, run the Windows PowerShell command Get-SPSite | Format-Table -Property ID,WebApplication,ContentDatabase to obtain a list of the sites for each Web application to list all sites in the various databases, and locate one site in each database.

    2. Browse to that site and make sure that the appropriate page rendered. An Access Denied page with an option to request access, or the option to log on as a different user, indicates that the operation completed successfully.

    3. On the Central Administration page, click Application Management and in the Site Collections section click Specify Quota Templates.

    4. On the Quota Templates page, create a new quota template. The specific settings are not relevant to this verification test. You are creating the template to verify that it can be accessed in step 7.

    5. Click OK to save the quota template.

    6. Refresh the browser window, and then return to the Quota Templates page. If the quota template that you created can be selected, access to the SharePoint Foundation 2010 configuration database has been restored.

    7. Click Delete to delete the quota template.


Content deployment job failed - Events 4958 5323 5325 5335 (SharePoint 2010 Products)

Alert Name: Content deployment job failed

Event ID: 4958 5323 5325 and 5325

Summary: A content deployment job has failed. Content might not have been correctly deployed from the source environment to the target environment.

Symptoms: One or more of the following messages appear in the event log:

  • Event ID: 4958 Description: Publishing: Content deployment job failed. Error: '<error>'.

  • Event ID: 5323 Description: Failed to transfer files to destination server for Content Deployment job '<job name>'. Exception was: '<exception>'.

  • Event ID: 5325 Description: Failed import operation for Content Deployment job '<job name>'. Exception was: '<exception>'.

  • Event ID: 5326 Description: Failed import operation for Content Deployment job '<job name>'. Exception was: '<exception>'.

Cause: Content deployment can fail for various reasons. The specific reasons for this failure are contained in the content deployment report on the Content Deployment Paths and Jobs page in Central Administration.

Resolution: View the content deployment job status

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration Home page, click General Application Settings.

  3. On the General Application Settings page, in the Content Deployment section, click Manage content deployment paths and jobs.

  4. On the Manage Content Deployment Paths and Jobs page, confirm the status of the job. If the job failed, you can view the job details by clicking Failed.

  5. On the Content Deployment Report page, in the Errors and Warnings section, you can view the error details.

    You can also download the error details by clicking Download Report in the Quick Links section of the Content Deployment Report page.

Resolution: Rerun the content deployment job

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration Home page, click General Application Settings.

  3. On the General Application Settings page, in the Content Deployment section, click Manage content deployment paths and jobs.

  4. On the Manage Content Deployment Paths and Jobs page, click the arrow next to the job, and then click Run Now.

  5. You can refresh the page to see the status of the job in progress. If the job failed, you can view the job details by clicking Failed.

  6. On the Content Deployment Report page, in the Errors and Warnings section, you can view the error details.

    You can also download the error details by clicking Download Report in the Quick Links section of the Content Deployment Report page.


Content database is Read-Only - Event 4971 (SharePoint 2010 Products)

Alert Name: Content database is Read-Only

Event ID: 4971

Summary: Microsoft SharePoint Foundation 2010 stores most of the content of the Web application — including site collections, sites, lists, documents, and permissions — in content databases. A single Web application can be associated with one or many content databases.

Symptoms: One or more of the following symptoms might appear:

  • Users cannot add or update content in SharePoint Foundation 2010 sites.

  • The following event appears in the event log: Event ID: 4971 Description: Cannot update database on SQL Server instance '<instance name>'. Database is read/only. Additional error information from SQL Server is included below. <additional information>

Cause: SQL Server provides the option of setting a database to read-only mode, in which data can be read from the database but data cannot be added, changed, or removed. If a content database is in read-only mode, you might observe the symptoms described.

Resolution: Set the database to read/write

  • If you verify that the content database is in read-only mode, set the SQL Server Management Studio database to read/write.

    To verify that the database is read-only:

    1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

    2. On the Central Administration Home page, click Application Management.

    3. On the Application Management page, in the Databases section, click Manage content databases.

    4. On the Manage Content Databases page, select the Web application from the Web Application list.

    5. If Yes appears in the Database Read-Only column for the content database, set the content database to read/write.

    To set the content database to read/write:

    1. Verify that the user account that is performing this procedure is a member of the db_owner fixed database role for the content database.

    2. Open SQL Server Management Studio and connect to the database server.

    3. In Object Explorer, expand Databases.

    4. Right-click the database that you want to set to read/write, and then click Properties.

    5. In the Database Properties dialog box, on the Options properties page, under State, select False from the drop-down list next to Database Read-Only, and then click OK.

    6. Click Yes.


Insufficient SQL Server database permissions - Event 5214 (SharePoint 2010 Products)

Alert Name: Insufficient SQL Server database permissions

Event ID: 5214

Summary: Microsoft SharePoint Foundation uses Microsoft SQL Server 2008 databases to store most of the content for the Web site and configuration settings. For example, all pages in the site, files in document libraries, files attached to lists, and information in lists are stored in the content database, and security and permission settings along with other configuration settings are stored in the configuration database in SQL Server.

SharePoint Foundation uses a service account to communicate with the database on behalf of a user request. This service account can be either a specific user name and password (domain name and password) or a predefined system account, such as Local System or Network Service. This error occurs when the service account specified in SharePoint Foundation has not been granted sufficient permissions in the SQL Server database.

Symptoms: The following symptom might appear:

  • This event appears in the event log: Event ID: 5214 Insufficient SQL database permissions for user '<username>' in database <database name> on SQL Server instance <instance name>. Additional error information from SQL Server is included below.

Cause: One or more of the following might be the cause:

  • The service account to which SharePoint Foundation is set does not have sufficient permissions to the database to which it is trying to connect.

  • The service account is not set up properly in SharePoint Foundation.

Note:

You must be a member of the Farm Administrators SharePoint group to perform the following tasks.

Resolution: Grant correct permissions to the database access account

  • To resolve this issue, assign the database access account and then verify the account has correct permission in SQL Server.

    To assign the database access account:

    1. On the Central Administration Web site, click Security and in the General Security section click Configure Service Accounts.

    2. On the Configure Service Accounts page, in the Credential Management section, select the correct Web application pool for your Web application.

    3. In the Select an account for this component section, select the domain account that you want to associate with this Web application pool, or click Register new managed account to associate a new domain account with this application pool.

      Note:

      You can use a local account for the Web application pool only if SharePoint Foundation and SQL Server are running on the same computer.

    4. Click OK to save changes.

    To verify that account has correct permissions in SQL Server:

    1. Connect to the computer that runs SQL Server by using an account with SQL Server administrator permissions.

    2. In SQL Server Management Studio, in the Object Explorer navigation pane, expand the Security node, and then click the Logins node. The name of the database access account indicates that it is a SQL login.

    3. If the account exists, open the database node, open the Security node, and then click Roles.

    4. Expand the Database Roles node, right-click db_owner, and select Properties.

    5. In the Database Roles Properties dialog box, check whether the database access account is in the Members of this role list. If the account is not listed, click Add.

    To verify that any database issues have been resolved:

    1. In the SharePoint Management Shell, run the Windows PowerShell command Get-SPSite | Format-Table -Property ID,WebApplication,ContentDatabase to obtain a list of the sites for each Web application to list all sites in the various databases, and locate one site in each database.

    2. Browse to the site.


Unable to write to trace log - Event 5401 (SharePoint 2010 Products)

Alert Name: Unable to write to trace log

Event ID: 5401

Summary: Unified Logging Service (ULS) trace logs contain diagnostic information about what is happening on a Microsoft SharePoint Foundation 2010 server. This information can be used to diagnose problems on your server if they occur.

Symptoms: The following symptoms might appear:

  • ULS trace log files are not created.

  • This event appears in the event log: Event ID: 5401 Tracing Service failed to create the trace log file at <Log Location>. Error <Error Number>: <Error Description>.

Cause: This error occurs when the tracing service cannot create a new log file.

Resolution: Check the event log

  • This error can occur for multiple reasons. The error number and error description describe the cause of the error in more detail; use the information in the error description to determine the most appropriate troubleshooting steps.


Unknown SQL exceptions - Event 5586 (SharePoint 2010 Products)

Alert Name: Unknown SQL exceptions

Event ID: 5586

Summary: Microsoft SharePoint Foundation uses Microsoft SQL Server 2008 databases to store configuration settings and most of the content for the Web site. For example, all pages in the site, files in document libraries, files attached to lists, and information in lists are stored in the content database, and security and permission settings along with other configuration settings are stored in the configuration database in SQL Server 2008.

Microsoft SharePoint Foundation uses a service account to communicate with the database on behalf of a user request. This service account can be either a specific user name or password (domain name and password), or a predefined system account, such as Local System or Network Service. When a SQL Server database is created, a value for the maximum database size is set. Each database has a separate database size setting. Note that a Web application might be associated with one or many databases.

Symptoms: The following symptom might appear:

  • This event appears in the event log: Event ID: 5586 Description: Database full error on SQL Server instance <instance name> in database <database name>. Additional error information from SQL Server is included below. <SQL error message>.

    Note:

    The description changes depending on the SQL Error code.

Cause: One or more of the following might be the cause:

  1. Insufficient SQL Server database permissions

  2. SQL Server database is full

  3. Incorrect MDAC version

  4. SQL Server database not found

  5. Incorrect version of SQL Server

  6. SQL Server collation is not supported

  7. Database is read-only

Note:

You must be a member of the Farm Administrators SharePoint group to perform the following tasks.

Resolution: Grant correct permissions to the database access account

  • To resolve this issue, assign the database access account and then verify the account has correct permission in SQL Server.

    To assign the database access account:

    1. On the SharePoint Central Administration Web site, click Security, and in the General Security section click Configure Service Accounts.

    2. On the Configure Service Accounts page, in the Credential Management section, select the correct Web application pool for your Web application.

    3. In the Select an account for this component section, select the domain account that you want to associate with this Web application pool, or click Register new managed account to associate a new domain account with this application pool.

    4. Click OK to save changes.

    To verify that the account has correct permission in SQL Server:

    1. Connect to the computer on which SQL Server runs by using an account with administrator permissions.

    2. In SQL Server Management Studio, in the Object Explorer navigation pane, expand the Security node, and then expand the Logins node. The name of the database access account indications that it is a SQL logon account; for example, ##MS_PolicyTsqlExecutionLogin##.

    3. If the account exists, expand the Databases node, expand the Security node, and then click Roles.

    4. Expand the Database Roles node, right-click db_owner, and select Properties.

    5. In the Database Roles Properties dialog box, check whether the database access account is in the Members of this role list. If the account is not listed, click Add.

Note:

You must be a member of the Farm Administrators SharePoint group to perform the following tasks.

Resolution: Increase the size of the SQL Server database

  • SharePoint Foundation cannot write to a database that has reached its maximum size. One solution is to increase the maximum size setting for the database that is full, which is named in the event message.

    To increase the database size:

    1. In SQL Server Management Studio, in the Object Explorer navigation pane, expand the server node, expand the Databases node, right-click the database you want, and then click Properties. The database name is provided in the event message.

    2. In the Properties dialog box, in the navigation pane, click Files.

    3. In the Database files dialog box, in the Autogrowth column, click the ellipsis for the database file.

    4. In the Change Autogrowth dialog box, under Maximum File Size, if the Restricted File Growth (MB) option is selected, increase the maximum file size in the box to the right. You can also configure the database to grow without restrictions by selecting the Unrestricted File Growth option.

    5. Click OK to save changes.

Note:

You must be a member of the Farm Administrators SharePoint group to perform the following tasks.

Resolution: Restore database

  • If the SQL Server database is not present or accessible on the computer that is running SQL Server, restore the database from a backup and reconnect it to SharePoint Foundation 2010.

    To restore the database from a backup:

    1. Copy the database backup to the SQL Server host.

    2. Restore the database by using the RESTORE SQL Server command. For more information about the RESTORE command, see http://msdn.microsoft.com/en-us/library/ms186858(SQL.90).aspx.

    To reconnect the database in Central Administration:

    1. On the Central Administration page, click Application Management and in the Databases section, click Manage content databases.

    2. On the Manage Content Databases page, click Add a content database and in the Web Application section select the Web application.

    3. In the Database Name and Authentication section, type the name of the server in the Database Server text box and the database name in the Database Name text box.

    4. Click OK to save the changes.

Resolution: Install correct SQL Server version

  • The computer that hosts the database server role must have Microsoft SQL Server 2005 Service Pack 3 Cumulative Update (CU) 3 or SQL Server 2008 Service Pack 1 CU 2 installed. You can either install or upgrade the server to the correct version of SQL Server.

Note:

You must have db_owner permissions to the database to perform the following task.

Resolution: Select the correct SQL Server collation

  1. Connect to the computer on which SQL Server is running by using an account with db_owner permissions to the database.

  2. In SQL Server Management Studio, in the Object Explorer navigation pane, expand the Databases node. Right-click the specific database that was indicated in event 4972, and then click Properties.

  3. On the General tab, the collation is listed in the Maintenance section.

  4. To change the collation, open the Options page.

  5. Select the correct collation from the Collation box.

Resolution: Change database to Read / Write

  • Change the database so that it can be both read from and written to (read/write) by performing the following steps to increase the size of the database.

    Note:

    You must have db_owner access to the database to perform this action.

    To increase the size of the database:

    1. In SQL Server Management Studio, in the Object Explorer navigation pane, expand the server node, and then expand the Databases node.

    2. Right-click the database you want, and then click Properties. The database name is provided in the event message.

    3. In the Database Properties dialog box, in the navigation pane, click Files.

    4. In the Database files section, in the Autogrowth column, click the ellipsis for the database file.

    5. In the Change Autogrowth dialog box, in the Maximum File Size section, if the Restricted File Growth option is selected, increase the maximum file size in the box to the right. You can also configure the database to grow without restrictions by selecting the Unrestricted File Growth option.

    6. Click OK to save changes.

Verify that any database issues have been resolved

  1. In the SharePoint Management Shell, run the Windows PowerShell command Get-SPSite | Format-Table -Property ID,WebApplication,ContentDatabase to obtain a list of the sites for each Web application to list all sites in the various databases, and locate one site in each database.

  2. Browse to the site.


SharePoint Foundation failed to create a site - Event 6141 (SharePoint 2010 Products)

Alert Name: SharePoint Foundation failed to create a site

Event ID: 6141

Summary: In Microsoft SharePoint Foundation 2010, administrators can create new SharePoint sites. Site owners and — depending on the site settings — site visitors can create subsites. This alert indicates that an attempt to create a new SharePoint site has failed.

Symptoms: This event might appear in the event log: Event ID: 6141 Description: The site <Site Name> could not be created. The following exception occurred: <Exception Details>.

Cause: One or more of the following could cause this:.

  • A configuration error.

  • The user does not have sufficient permission to create the site.

  • The user attempted to create a site with a non-valid character in the site name, such as '+'.

To determine the specific error, see the exception text in the event description.

Resolution: User must request access

  • If Event 6141 has the description of: 'The site %SiteURL% could not be created. The following exception occurred: Access denied.' This means the user does not have permission to create a SharePoint site. Users will need to request access to the SharePoint site so that a SharePoint Administrator can update their permissions.

    Instruct the user to follow these steps:

  • On the home page of the site, in the upper right corner of the page, click next to "Welcome, <user name>".

  • Click Request Access.

  • On the Request Access page, type a deception of your request, if needed, and click Send Request.

Resolution: User must use a different URL

  • If Event 6141 has the description of: 'The site %SiteURL% could not be created. The following exception occurred: Invalid character in Web name %SiteName%.' This means the user attempted to create the site using an invalid character. Instruct the user to recreate the site without the special character such as '+' in the site name.


Unable to load authentication provider - Event 6143 (SharePoint 2010 Products)

Alert Name: Unable to load authentication provider

Event ID: 6143

Summary: To authenticate users, Microsoft SharePoint 2010 Products uses the authentication providers that are provided by Windows Server 2008 R2 — such as forms authentication or Web single sign-on (SSO) authentication — by other versions of Windows, and by third-party vendors.

When using Kerberos v5 authentication, the service account used by the Internet Information Services (IIS) application pool for your Web application must be registered in Active Directory as a Service Principal Name (SPN) on the domain on which the front-end Web server is a member.

This error indicates that the role manager or membership provider that is specified for a particular Web application is incorrectly configured.

Symptoms: One or more of the following symptoms might appear:

  • User authentication fails to work correctly, which prevents users from accessing content.

  • User tokens are not updated by using correct role memberships, which prevents users from accessing content that they would expect to have access to, based on their roles.

  • Event 6143 might appear in the event log with one of the following descriptions:

    • Description: Cannot get Membership Provider with name <Membership Provider Name>. The membership provider for this process was not properly configured. You must configure the membership provider in the .config file for every SharePoint process.

    • Description: Cannot get Role Manager with name <Role Manager Name>. The role manager for this process was not properly configured. You must configure the role manager in the .config file for every SharePoint process.

Cause: The role manager or membership provider specified for a particular Web application may be incorrectly configured.

Resolution: Verify the authentication mode

  1. On the Central Administration Home page Quick Launch, click Security.

  2. On the Security page, in the General Security section, click Specify authentication providers.

  3. On the Authentication Providers page, ensure that the correct Web application is selected. If it is not, select the Web application that you want to review.

  4. On the Authentication Providers page, click the zone for which you want to change authentication settings.

  5. On the Edit Authentication page, in the Authentication Type section, review the selected authentication type.

  6. If Windows is selected, review the settings in the IIS Authentication Settings section. If Forms or Web Single Sign-On is selected, review the settings in the Membership Provider Name and Role Manager Name sections.

  7. Click Cancel to close without saving changes.

Resolution: Configure Kerberos v 5 authentication mode

  1. You only need to perform this procedure if you are using Kerberos v 5 authentication.

  2. You must be a member of the SharePoint Administrators group to perform this task.

  3. Contact a domain administrator and ensure that the service account used by the application pool is the registered SPN for all domains listed with the Web application.

    Note:

    If you do not have a specific need for Kerberos v5 authentication, or if you cannot configure the SPN, use NTLM authentication instead. If you use Kerberos v5 authentication and cannot configure the SPN, only server administrators will be able to authenticate to the site. To change the authentication type, see the "Configure NTLM authentication mode" procedure later in this article

    For more information about how to configure SharePoint 2010 Products to use Kerberos v5 authentication, see the Microsoft Knowledge Base article 832769, How to configure a Windows SharePoint Services virtual server to use Kerberos v5 authentication and how to switch from Kerberos v5 authentication back to NTLM authentication.

Resolution: Configure NTLM authentication mode

  1. On the Central Administration Home page Quick Launch, click Security.

  2. On the Security page, in the General Security section, click Specify authentication providers.

  3. On the Authentication Providers page, ensure that the correct Web application is selected. If it is not, select the Web application that you intend to review.

  4. On the Authentication Providers page, click the zone for which you want to change authentication settings.

  5. On the Edit Authentication page, in the Authentication Type section, select Windows authentication.

  6. Under IIS Authentication Settings, ensure that the Integrated Windows authentication check box is selected, and then click NTLM.

  7. Click OK to save changes.

Resolution: Configure Forms or Web Single Sign-On authentication mode

  1. You only need to perform this procedure if you are using Kerberos v 5 authentication.

  2. You must be a member of the SharePoint Administrators group to perform this task.

  3. Review the documentation for the forms or Web SSO provider. Ensure that the correct components for the provider are installed on the server and that the settings for the provider are correctly set up in the Web.config file of the IIS directory for the Web application. Record the membership provider name and role manager from the Web.config file.

  4. On the Central Administration Home page Quick Launch, click Security.

  5. On the Security page, in the General Security section, click Specify authentication providers.

  6. On the Authentication Providers page, click on the correct zone.

  7. On the Edit Authentication page, in the Claims Authentication section, record the ASP.NET Membership provider name. Make sure that this is the same name specified in the Web.config file.

  8. Record the ASP.NET Role manager name. Make sure that this is the same name specified in the Web.config file.


Insufficient permissions to write to the configuration data cache - Event 6395 (SharePoint 2010 Products)

Alert Name: Insufficient permissions to write to the configuration data cache

Event ID: 6395

Summary: Several features of Microsoft SharePoint Foundation 2010 rely on scheduled background processes called timer jobs. Administrators can configure and schedule timer jobs by using SharePoint Central Administration. When you use the Services on Server page of the SharePoint Central Administration Web site to start or stop a service, a timer job performs this action.

To improve the performance of SharePoint Foundation 2010, most of the data in the configuration database in SQL Server 2008 is kept in a local file-system cache, called the configuration data cache. SharePoint Foundation 2010 uses the timer service to keep this cache synchronized with the configuration database.

This error indicates that a permissions issue is preventing specific trusted accounts from writing to the %systemdrive%\Users\AllUsers\Microsoft\SharePoint\Config directory.

Symptoms: The following message might appear in the event log: Event ID: 6395 Insufficient permissions to write to the configuration data cache. More information is included below.

Cause: The configuration cache directory has security settings that prevent write access to its contents. Although configuration objects can be updated farm-wide, the objects are not updated locally.

Resolution: Assign sufficient permissions to the configuration data cache

  • Make sure that the WSS_ADMIN_WPG and WSS_RESTRICTED_WPG local groups have been granted permissions to write to the %systemdrive%\Users\All Users\Microsoft\SharePoint\Config directory. You must have Modify permissions to the directory in order to perform this task.


Alternate access mapping update failed - Event 6397 (SharePoint 2010 Products)

Alert Name: Alternate access mapping update failed

Event ID: 6397

Summary: Several features of Microsoft SharePoint Foundation 2010 rely on scheduled background processes called timer jobs. Administrators can configure and schedule timer jobs by using SharePoint Central Administration. When you use the Services on Server page of the SharePoint Central Administration Web site to start or stop a service, a timer job performs this action.

To improve the performance of SharePoint Foundation 2010, much of the data in the configuration database in SQL Server 2008 is kept in a local file-system cache, called the configuration data cache. SharePoint Foundation 2010 uses the timer service to keep this cache synchronized with the configuration database. Alternate access mapping is a feature of Microsoft SharePoint Foundation 2010 for administrators to configure a load-balanced system by mapping an incoming URL to alternate URLs that are used by SharePoint Foundation.

This error occurs when the timer job that is used to update alternate access mappings failed on the specified server.

Symptoms: One or more of the following symptoms might appear:

  • The alternate access mapping settings for Web applications on the local server might not be current.

  • This event appears in the event log: Event ID: 6397 Alternate Access Mapping failed to be updated. Web Application affected: <Web Application>. Current user: <User Name>. More information is provided below.

Cause: The alternate access mapping specified in the configuration cache was not applied to the IIS settings of the local machine.

Note:

You must be a member of the Farm Administrators SharePoint group on the Central Administration site to perform the following task.

Resolution: Complete the alternate access mapping update

  • The event string for event 6397 provides the alternate access mapping that failed. Try to re-create the mapping by using the Central Administration site.

    To view or change alternate access mapping settings:

    1. On the Central Administration page, click Application Management and in the Web Applications section click Configure alternate access mappings.

    2. To edit the mapping, click the mapping you want to change.

    To verify that the alternate access mapping is correct:

    • If the SharePoint Administration Service was restarted, in the SharePoint Management Shell, run the Windows PowerShell command Start-SPAdminJob to ensure that all tasks required by the administration service were completed.


Service Instance timer execution failed - Event 6398 (SharePoint 2010 Products)

Alert Name: SPServiceInstance timer execution failed

Event ID: 6398

Summary: Several features of Microsoft SharePoint Foundation 2010 rely on scheduled background processes called timer jobs. Administrators can configure, schedule, and view the status of timer jobs by using the SharePoint Central Administration Web site.

Symptoms: The following symptom might appear:

  • This event appears in the event log: Event ID: 6398 The Execute method of job definition <Job Definition Name> (ID Job ID) threw an exception. More information is included below. %n%n <Job Details>

    Most Common Job Definitions:

    • SPPasswordManagementJobDefinition

      Purpose: Sends e-mail and logs events for expiring passwords and password changes. This timer job ensures that managed passwords are changed before they expire.

    • SPGeneratePasswordJobDefinition

      Purpose: Generates new password for an account, updates the account password, and then launches jobs to deploy the new password to everything that uses it.

    • SPAdminAppPoolCredentialDeploymentJobDefinition

      Purpose: Updates the credentials for the administration Internet Information Services (IIS) 7.0 application pool in the farm.

    • SPContentAppPoolCredentialDeploymentJobDefinition

      Purpose: Updates the credentials for a content IIS application pool on all servers in the farm.

    • SPWindowsServiceCredentialDeploymentJobDefinition

      Purpose: Updates the credentials for a Windows service on every computer in the farm where the service is running.

    • SPMasterPassphraseDeploymentJobDefinition

      Purpose: Tells all the front-end Web applications the new passphrase-derived key. This job is run when the administrator decides to change the passphrase of the farm.

Cause: One or more of the following might be the cause:

  • The third-party timer job cannot be found or is corrupt.

  • The Microsoft SharePoint Foundation 2010 timer job cannot be found, or is corrupt.

  • Most Common Job Causes:

    • SPPasswordManagementJobDefinition

      Issue: Password change timer jobs (SPGeneratePasswordJobDefinition) have not been scheduled or updated for farm credentials. Any additions or changes made recently to the password change schedules for any credentials in the farm will not be updated to match the changes until this job completes successfully.

    • SPGeneratePasswordJobDefinition

      Issue: A scheduled timer job to create a new password for a farm credential failed. The current credential value might no longer be valid and has to be updated manually in the Active Directory account. If the credentials for the account are still valid, this timer job should be restarted.

    • SPAdminAppPoolCredentialDeploymentJobDefinition

      Issue: The new credentials for the Central Administration Web application pool have not been updated on the local machine to match the current value that was configured for the farm. This might prevent the Central Administration Web application from starting.

    • SPContentAppPoolCredentialDeploymentJobDefinition

      Issue: The new credentials for the application pool have not been updated on the local machine to match the current value that was configured for the farm. This might prevent the application pool from starting.

    • SPWindowsServiceCredentialDeploymentJobDefinition

      Issue: The new credentials for the service have not been updated on the local machine to match the current value that was configured for the farm. This might prevent the service from starting.

    • SPMasterPassphraseDeploymentJobDefinition

      Issue: The master passphrase for the farm has not been updated on the local machine to match the current value that was configured for the farm. This might prevent decryption or encryption of the farm encryption key until it is updated locally.

Resolution: Determine appropriate resolution

  • Review the job definition name found in the event description to determine the appropriate resolution:

    • SPPasswordManagementJobDefinition

      Resolution: Restart this timer job.

    • SPGeneratePasswordJobDefinition

      Resolution: Restart this timer job to manually force a password reset.

    • SPAdminAppPoolCredentialDeploymentJobDefinition

      Resolution: Restart this timer job to run administrator deployment jobs locally, in order to manually force a password reset.

    • SPContentAppPoolCredentialDeploymentJobDefinition

      Resolution: Restart this timer job to run administrator deployment jobs locally, in order to manually force a password reset.

    • SPWindowsServiceCredentialDeploymentJobDefinition

      Resolution: Restart this timer job to run administrator deployment jobs locally, in order to manually force a password reset.

    • SPMasterPassphraseDeploymentJobDefinition

      Resolution: Restart this timer job to run administrator deployment jobs locally, in order to manually force a password reset.

For all other timer job resolutions, follow the steps in the next section. To resolve this issue, use the resolution that corresponds to the cause you identified in the "Symptoms" section. After performing the resolution steps, see the "Verify" section to confirm that the feature is operating properly.

Note:

You must be a member of the Farm Administrators SharePoint group to perform these tasks.

Resolution: Configure faulty timer job

  • If the faulty assembly cannot be found or is corrupt, and if it is not a SharePoint Foundation 2010 assembly, and if the timer definition is a recurring job, you must disable the faulty timer job.

    To disable the faulty timer job:

    1. On the Central Administration page, click Monitoring and in the Timer Jobs section click Review Job Definitions.

    2. Locate the timer job in the list and click the timer definition name.

    3. On the Edit Timer Job page, click Disable.

      Disabled timer jobs are displayed as Disabled in the Schedule Type column.

    To enable the faulty timer job:

    1. On the Central Administration page, click Monitoring and in the Timer Jobs section click Review Job Definitions.

    2. Locate the timer job in the list and click the timer definition name.

    3. On the Edit Timer Job page, click Enable.

Note:

To perform the following procedure, you must be a member of the Administrators group on the local computer.

Resolution: Repair Windows SharePoint Services installation

  • If the faulty assembly cannot be found or is corrupt, and is a Microsoft SharePoint Foundation assembly, you must repair the SharePoint Foundation installation to restore or repair the assembly.

    Note:

    Repairing the installation requires that you restart the server. Web application modifications and other settings changes will be preserved.

    To repair the SharePoint Foundation installation:

    • Run the Microsoft SharePoint Foundation 2010 setup wizard, select the Repair option, and click Continue.

    To verify that the timer job is working:

    1. If the timer job was a recurring job, go to the Timer Job Definition page, and enable the timer job. The job should run at the next normally scheduled interval.

    2. If the timer job was a one-time-only job, retry the command that triggered the timer job.


ULS not enough free disk space - Event 6457 (SharePoint 2010 Products)

Alert Name: ULS not enough free disk space

Event ID: 6457

Summary: The Microsoft SharePoint Foundation Tracing (SPTracev4) service is used by Microsoft SharePoint Foundation 2010 to manage trace message output. When trace logging is turned on, administrators can specify the path that is to be used to store the trace logs. This log file is used by many applications that are built on top of SharePoint Foundation. The trace log contains information that is useful for diagnosing server problems. SharePoint Foundation 2010 could not write to the trace log. This event occurs when not enough free space is available for logging.

Symptoms: The following symptoms might appear:

  • The trace log shows no new data.

  • This event appears in the event log: Event ID: 6457 Description: Not enough free disk space available. The tracing service has temporarily stopped outputting trace messages to the log file. Tracing will resume when more than <# of MBs needed to resume logging> MB of disk space becomes available.

Cause: The configured log location does not have sufficient free disk space for logging.

Resolution: Free up disk space

  1. Use Disk Cleanup to free up disk space where the trace logs are stored.

  2. Verify that the trace log has enough disk space to run properly.

  3. If the trace log does not have enough disk space, clean up the Temp folders on the drive.

  4. If this procedure does not solve the problem, it is also possible to relocate the trace log file to a partition that has more drive space.

Resolution: Relocate the log file

  1. On the SharePoint Central Administration Web site, click Monitoring and in the Reporting section, click Configure diagnostic logging.

  2. On the Diagnostic Logging page, in the Trace Log section, type the new location for the trace log files in the Path text box.

  3. Click OK.


Access denied for writing to registry - Event 6588 (SharePoint 2010 Products)

Alert Name: Access denied for writing to registry

Event ID: 6588

Summary: This error occurs when an Internet Information Services application pool that is used by Microsoft SharePoint Foundation 2010 attempts to update a registry key and is denied access because the service account that is used by the application pool has inadequate permissions.

Symptoms: The following symptoms might appear:

  • Registry keys might not be updated correctly to reflect configured settings.

  • This event appears in the event log: Event ID: 6588 Description: The application pool account <Account Name> cannot write registry key <Key Name> at <Key Location>. Additional information is below.

Cause: The service account for the IIS application pool that SharePoint Foundation 2010 does not have appropriate access permissions to write to a registry key.

Resolution: Grant correct permissions to the application pool account

  • The Web application pool account does not have sufficient permissions to write to the registry or to a file on disk. First, try to fix SharePoint Foundation 2010 permissions by using the Psconfig command-line tool. If that does not solve the problem, use the following procedures in order. First determine which account is used for the Web application.

    Note:

    You must be a member of the Farm Administrators SharePoint group to perform the following procedures.

    To fix SharePoint Foundation 2010 permissions:

    1. Open a Command Prompt window and at the command prompt, type:

      cd /d %commonprogramfiles%\Microsoft Shared\Web server extensions\14\BIN

    2. Fix the permissions on the server by entering the following command:

      psconfig -cmd secureresources

    3. Restart IIS and make the changes by entering the following command at the command prompt:iisreset /noforce

    To determine the account for the Web application:

    1. In the IIS Manager, in the Connections pane, expand the server node and then click Application Pools.

    2. In the reading pane, in Features View, in the Identity column, note the account for the application pool that you identified.

    To manually set the required group account for the Web application pool account on the computer:

    1. Click Start, click Administrative Tools, and then click Computer Management.

    2. In the tree view, expand Local Users and Groups, and then click the Groups folder.

    3. In the reading pane list, right-click WSS_WPG and click Add to Group.

    4. In the WSS_WPG Properties dialog box, add the Web application pool account by clicking Add.

    To grant required permissions for the Web application pool account to a folder:

    1. On the SharePoint Foundation computer, locate the folder identified in event 6588 or 6589.

    2. Right-click the folder and select Properties.

    3. In the Properties dialog box, on the Security tab, in the Group or user names section, select Everyone, and then click Edit.

      Note:

      Incorrectly editing the registry might severely damage the system. Before making changes to the registry, back up any valued data on the computer.

    4. In the Permissions for <foldername> dialog box, click Add to add the Web application pool account. The account requires Write permission.

    To grant the required permissions for the Web application pool account to a registry key:

    1. Click the Start button, click All Programs, click Accessories, and then click Run.

    2. Type regedit, and then click OK.

    3. In the Registry Editor, in the tree view, locate the registry key that is identified in event 6588 or 6589.

    4. Right-click the registry key and select Permissions.

    5. In the Permissions dialog box, click Add to add the Web application pool account. The account will require Write permission.

    To verify:

    • Retry the operation that previously failed.


Access denied for writing to disk - Event 6589 (SharePoint 2010 Products)

Alert Name: Access denied for writing to disk

Event ID: 6589

Summary: This error occurs when anInternet Information Services (IIS) 7.0 application pool used by Microsoft SharePoint Foundation 2010 attempts to update a file or folder and is denied access because the service account used by the application pool has inadequate permissions.

Symptoms: The following symptoms might appear:

  • Files might not be updated correctly to reflect configured settings.

  • This event appears in the event log: Event ID: 6589 Description: The application pool account <Account Name> has insufficient permissions to write file <File Name> at <File Location>. Additional information is below.

Cause: The service account for the IIS application pool that SharePoint Foundation 2010 uses does not have appropriate permissions to write to a file or folder in the NTFS file system.

Resolution: Grant correct permissions to the application pool account

  • The Web application pool account does not have sufficient permissions to write to the registry or to a file on disk. First, try to fix SharePoint Foundation 2010 permissions by using the Psconfig command-line tool. If that does not solve the problem, use the following procedures in order. First determine which account is used for the Web application.

    Note:

    You must be a member of the Farm Administrators SharePoint group to perform the following procedures.

    To fix SharePoint Foundation 2010 permissions:

    1. Open a Command Prompt window and at the command prompt, type:

      cd /d %commonprogramfiles%\Microsoft Shared\Web server extensions\14\BIN

    2. Fix the permissions on the server by entering the following command:

      psconfig -cmd secureresources

    3. Restart IIS and make the changes by entering the following command at the command prompt: iisreset /noforce

    To determine the account for the Web application:

    1. In the IIS Manager, in the Connections pane, expand the server node and then click Application Pools.

    2. In the reading pane, in Features View, in the Identity column, note the account for the application pool that you identified.

    To manually set the required group account for the Web application pool account on the computer:

    1. Click Start, click Administrative Tools, and then click Computer Management.

    2. In the tree view, expand Local Users and Groups and click Groups.

    3. In the reading pane list, right-click WSS_WPG groups and click Add to Group.

    4. In the WSS_WPG Properties dialog box, add the Web application pool account by clicking Add.

    To grant required permissions for the Web application pool account to a folder:

    1. On the SharePoint Foundation computer, locate the folder identified in event 6588 or 6589.

    2. Right-click the folder and select Properties.

    3. In the Properties dialog box, on the Security tab, in the Group or user names section, select Everyone, and then click Edit.

      Note:

      Incorrectly editing the registry might severely damage the system. Before making changes to the registry, back up any valued data on the computer.

    4. In the Permissions for <foldername> dialog box, click Add to add the Web application pool account. The account requires Write permission.

    To grant the required permissions for the Web application pool account to a registry key:

    1. Click the Start button, click All Programs, click Accessories, and then click Run.

    2. Type regedit, and then click OK.

    3. In the Registry Editor, in the tree view, locate the registry key identified in event 6588 or 6589.

    4. Right-click the registry key and select Permissions.

    5. In the Permission dialog box, click Add to add the Web application pool account. The account will require Write permission.

    To verify:

    • Retry the operation that previously failed.


Application pool account must be registered as Kerberos - Event 6590 (SharePoint 2010 Products)

Alert Name: Application pool account must be registered as Kerberos

Event ID: 6590

Summary: Microsoft SharePoint Foundation 2010 can use the authentication providers that are provided by Windows Server 2008 to authenticate users. For example, Microsoft SharePoint Foundation can use forms-based authentication or Web single sign-on.

When using the Kerberos version 5 authentication protocol, the service account that is used by the Internet Information Services (IIS) application pool for your Web application must be registered in Active Directory Domain Services (AD DS) as an SPN on the domain on which the front end Web server is a member.

Symptoms: This event appears in the event log: Event ID: 6590 Description: The application pool account has insufficient permissions to add user accounts to Active Directory. When using Kerberos authentication, the service account used by the Internet Information Services (IIS) application pool for your Web application must be registered in Active Directory as a Service Principal Name (SPN) on the domain on which the Web front-end is a member.

Cause: One or more of the following might be the cause:

  • If using Kerberos v5 authentication, the Web application pool account is not a registered security provider name.

  • If using either forms-based authentication or Web single sign-on, the authentication provider could not be loaded because no membership provider name was specified.

  • The Web application pool must be restarted for changes to be saved.

Note:

You must be a member of the Farm Administrators SharePoint group to perform the following action.

Resolution: Determine which authentication type the site is using

  1. On the SharePoint Central Administration Web site, on the Quick Launch click Security and in the General Security section click Specify Authentication Providers.

  2. On the Authentication Providers page, select the correct Web application. To select a Web application, click the Web Application drop-down list arrow and click Change Web Application. In the Select Web Application dialog box, click the correct Web application.

  3. On the Authentication Providers page, click the zone for the site from the list.

  4. On the Edit Authentication page, the authentication type is displayed in the IIS Authentication Settings section.

Resolution: Register the application pool account as an SPN

  • The Web application pool account is not a registered security provider name (SPN). Contact a domain administrator and make sure that the service account that is used by the application pool is the registered SPN for all domains listed with the Web application.

Note:

You must be a member of the Farm Administrators SharePoint group to perform the following tasks.

Resolution: Specify membership provider name and a role manager

  1. On the Central Administration page, on the Quick Launch click Security and in the General Security section click Specify authentication providers.

  2. On the Authentication Providers page, select the zone for which you want to change authentication settings.

  3. On the Edit Authentication page, in the Authentication Type section select either the Forms or Web single sign-on authentication option. Windows authentication is selected by default.

  4. Click Save.

  5. In the Membership Provider Name section, type the name in the Membership provider name text box.

  6. In the Role Manager Name section, type the name in the Role manager name text box.

  7. Click Save.

Resolution: Edit authentication settings for a zone

  1. On the Central Administration page, on the Quick Launch click Security, and in the General Security section click Specify authentication providers.

  2. On the Authentication Providers page, select the zone for which you want to change authentication settings.

  3. On the Edit Authentication page, in the Authentication Type section select the authentication option. Windows authentication is selected by default.

  4. In the IIS Authentication Settings section, select the setting. Integrated Windows authentication — NTLM is selected by default. If you select Negotiate (Kerberos) you must perform additional steps to configure authentication.

  5. Click Save.


SMTP service not running - Event 6599 (SharePoint 2010 Products)

Alert Name: SMTP service is not running

Event ID: 6599

Summary: Microsoft SharePoint 2010 Products sends alerts and other SharePoint 2010 Products administration messages by using a Simple Mail Transfer Protocol (SMTP) mail server. When SharePoint 2010 Products is configured to receive incoming e-mail, the SMTP service delivers e-mail messages to a drop folder. A SharePoint timer job scans the drop folder and inserts the messages into SharePoint lists.

Symptoms: One or more of the following symptoms might appear:

  • SharePoint 2010 Products does not receive incoming e-mail.

  • Some front-end Web servers receive incoming e-mail while others do not.

  • This event appears in the event log: Event ID: 6599 Description: there was an error connecting to the Windows SMTP service.

Cause: Automatic configuration for incoming e-mail is enabled and the Windows SMTP service is not installed on one or multiple servers, or the Windows SMTP service is not running on one or multiple servers.

Note:

The SMTP server is not installed by default. SMTP can be added by using the Features Summary area of Server Manager in Windows Server 2008 R2.

Resolution: Configure outgoing e-mail settings in Central Administration

  1. Note:

    SMTP is turned off by default in SharePoint Foundation 2010.

    On the Central Administration Home page, click System Settings, and in the E-Mail and Text Messages (SMS) section, click Configure Outgoing E-Mail Settings.

  2. On the Outgoing E-Mail Settings page, in the Mail Settings section, type the correct SMTP server in the Outbound SMTP server box.

Resolution: Enable and configure the SMTP service

  • Perform the steps in the following article: Configure SMTP E-mail (IIS 7) (http://technet.microsoft.com/en-us/library/cc772058(WS.10).aspx).

Resolution: Start the SMTP service

  1. Note:

    In Internet Information Services (IIS) 6.0 Manager, connect to the SMTP server.

    Expand the server node, and look for the SMTP virtual server used by SharePoint 2010 Products.

  2. Right-click the correct virtual server, and then click Start.


Event handler failed to load - Event 6644 (SharePoint 2010 Products)

Alert Name: Event handler failed to load

Event ID: 6644

Summary: In Microsoft SharePoint Foundation 2010, you can bind an event handler to an event host (such as an entire site, a list, or a document library). By binding an event handler to an event host, you can use document library events to start other processes, such as workflow processes.

Symptoms: This event appears in the event log: Event ID: 6644 Description: Event manager error: <error>.

Cause: One or more of the following might be the cause:

  • The custom event receiver assembly cannot be found, or it is corrupted.

  • The SharePoint Foundation 2010 assembly cannot be found, or it is corrupted.

Resolution: Contact the manufacturer of the faulty custom event receiver

  • If the faulty assembly is corrupted, and it is not a SharePoint Foundation 2010 assembly, contact the manufacturer of the faulty event receiver assembly for more information.

Resolution: Repair your product installation

  1. Repairing the installation will require you to restart the server. Web application modifications and other changes to settings will be preserved.

    Note:

    You must be a member of the Administrators group on the local computer to perform this task.

    To repair the Microsoft SharePoint Foundation 2010 installation:

    1. In Control Panel, open Programs and Features.

    2. Select your installation of SharePoint Foundation 2010 from the list, and then click Change.

    3. In the SharePoint Products Configuration Wizard, select Repair, and then click Continue.

    4. After completing the changes in the SharePoint Products Configuration Wizard, verify that the event handler assembly is either repaired or removed from all farm servers.

    5. Retry the operation that triggered the event handler. These events should not continue to appear in the Windows event log.


Product Help Library Permission - Event 6769 (SharePoint 2010 Products)

Alert Name: Product Help Library Permissions

Event ID: 6769

Summary: Microsoft SharePoint Foundation requires that specific permissions be set on the Product Help Library to correctly display Help to users. For this event ID the SCOM monitor monitors the permission configuration for this library. The Product Help Library is located in the Help Site Collection under the SharePoint Central Administration Web application.

Symptoms: The following symptoms might appear:

  • End users cannot access the product Help.

  • This event appears in the event log: Event ID: 6769 Description: Unable to refresh permissions for Product Help Library Site Collection.

Cause: A problem with refreshing permissions for the Product Help Library Site Collection.

Resolution: Reset Permissions

  • Reset the permission configuration by using a Psconfig job or a Windows PowerShell cmdlet.

    To reset the permission configuration by using a Psconfig job:

    • Open a Command Prompt window and at the command prompt, type psconfig -cmd helpcollections-install.

    To reset the permission configuration by using a Windows PowerShell cmdlet:

    1. Click Start, click All Programs, click Microsoft SharePoint 2010 Products, and then click SharePoint Management Shell. A Command Prompt window opens.

    2. Type the Windows PowerShell command Install-SPHelpCollection -All.


Cannot resolve name of the outbound SMTP server - Event 6856 (SharePoint 2010 Products)

Alert Name: Cannot resolve name of the outbound SMTP server

Event ID: 6856

Summary: Microsoft SharePoint Foundation 2010 sends alerts and other administration messages by using an SMTP mail server. You can specify which SMTP server to use, and you can set the e-mail address to use for sending alerts and receiving replies for all sites, by using the Outgoing E-Mail Settings page of the SharePoint Central Administration Web site.

Symptoms: The following symptoms might appear:

  • Cannot send e-mail by using SPUtility.SendEmail

  • Cannot send e-mail messages, including alert e-mail, confirmation e-mail, invitation e-mail, and e-mail about exceeding quota

  • This event appears in the event log: Event ID: 6856 Description: Cannot resolve name of SMTP host <host id>.

Cause: One or more of the following might be the cause:

  • Microsoft SharePoint Foundation cannot connect to the SMTP host.

  • SharePoint Foundation 2010 cannot resolve the name of the outbound SMTP server.

To resolve this issue, use the resolution that corresponds to the cause that you identify. After performing the resolution, see the "Verify that an e-mail message is sent" section at the end of this article to confirm that the feature is operating properly.

Note:

You must be a member of the Farm Administrators SharePoint group to perform the following actions.

Resolution: Start and configure the SMTP service

  1. Start the Internet Information Services Manager 6.0 Manager and in the tree view expand the name of the server.

  2. Right-click the SMTP virtual server that is used by SharePoint Foundation (for example, Default SMTP Virtual Server), and then click Start.

  3. To configure the virtual server, right-click the virtual server and click Properties.

  4. On the Delivery tab, click Outbound Security.

  5. In the Outbound Security dialog box, either the Anonymous access or Integrated Windows Authentication option is selected. If Integrated Windows authentication is selected, make sure that the SharePoint Foundation Central Administration application pool account has access to the SMTP service. Select the Account and Password check boxes, and type the Windows account name and password that grants you access to the computer to which you connect.

Resolution: Configure outgoing e-mail settings in Central Administration

  1. On the Central Administration page, click System Settings and in the E-Mail section click Configure Outgoing E-Mail Settings.

  2. On the Outgoing E-Mail Settings page, in the Mail Settings section, type the correct SMTP server in the Outbound SMTP server text box.

Verify that an e-mail alert is sent

  1. Navigate to a SharePoint Foundation Web site that has a list of any type.

  2. Click an item in the list.

  3. Click an item in the list and on the ribbon, click Share & Track.

  4. Click Alert Me and from the menu select For this item.

  5. In the New Alert dialog box, in the Send Alerts To section, type the account name in the Users text box.

  6. After verifying other settings, click OK.

    An e-mail message is sent to the e-mail Inbox informing you that you have created a new alert.


Cannot connect to SMTP host - Event 6857 (SharePoint 2010 Products)

Alert Name: Cannot connect to SMTP host

Event ID: 6857

Summary: Microsoft SharePoint Foundation 2010 sends alerts and other administration messages by using an SMTP mail server. You can specify which SMTP server to use to send the alerts, and you can set the e-mail address to use for sending alerts and receiving replies for all sites, by using the Outgoing E-Mail Settings page on the SharePoint Central Administration Web site.

Symptoms: The following symptoms might appear:

  • Cannot send e-mail by using SPUtility.SendEmail

  • Cannot send e-mail messages, including alert e-mail, confirmation e-mail, invitation e-mail, e-mail about exceeding quota

  • This event appears in the event log: Event ID: 6857 Description: Cannot resolve name of SMTP host <host id>.

Cause: One or more of the following might be the cause:

  • Microsoft SharePoint Foundation cannot connect to the SMTP host.

  • SharePoint Foundation cannot resolve name of the outbound SMTP server.

Note:

You must be a member of the Farm Administrators SharePoint group to perform the following actions.

Resolution: Start and configure the SMTP service

  1. In Internet Information Services (IIS) 6.0 Manager, connect to the SMTP server.

  2. Expand the server node and look for the SMTP virtual server that is used by SharePoint Foundation.

  3. Right-click the correct virtual server and click Start.

  4. To configure the virtual server, open the virtual server's properties.

  5. On the Delivery tab, click Outbound Security.

  6. In the Outbound Security dialog box, select either Anonymous access or Integrated Windows Authentication. If you select Integrated Windows authentication, make sure that the SharePoint Foundation Central Administration application pool account is authenticated on the SMTP server by selecting the Account and Password check boxes.

Resolution: Configure outgoing e-mail settings in Central Administration

  1. On the Central Administration page, click System Settings and in the E-Mail section click Configure Outgoing E-Mail Settings.

  2. On the Outgoing E-Mail Settings page, in the Mail Settings section, type the correct SMTP server in the Outbound SMTP server text box.


Error occurred while communicating with SMTP server - Event 6858 (SharePoint 2010 Products)

Alert Name: Error occurred while communicating with SMTP server

Event ID: 6858

Summary: Microsoft SharePoint Foundation 2010 sends alerts and other administration messages by using an SMTP mail server. You can specify which SMTP server to use to send the alerts, and you can set the e-mail address to use for sending alerts and receiving replies for all sites, by using the Outgoing E-Mail Settings page on the SharePoint Central Administration Web site.

Symptoms: The following symptoms might appear:

  • Cannot send e-mail using SPUtility.SendEmail

  • Cannot send e-mail messages, including alert e-mail, confirmation e-mail, invitation e-mail, e-mail about exceeding quota

  • This event appears in the event log: Event ID: 6858 Description: Cannot resolve name of SMTP host <host id>.

Cause: One or more of the following might be the cause:

  • Microsoft SharePoint Foundation cannot connect to the SMTP host.

  • SharePoint Foundation cannot resolve name of the outbound SMTP server.

To resolve this issue, use the resolution that corresponds to the cause that you identify. After performing the resolution, see the "Verify that an e-mail alert is sent" section at the end of this article to confirm that the feature is operating properly.

Note:

You must be a member of the Farm Administrators SharePoint group to perform the following actions.

Resolution: Start and configure the SMTP service

  1. In Internet Information Services (IIS) 6.0 Manager, connect to the SMTP server.

  2. Expand the server node and look for the SMTP virtual server used by SharePoint Foundation.

  3. Right-click the correct virtual server, and then click Start.

  4. To configure the virtual server, open the virtual server's properties.

  5. On the Delivery tab, click Outbound Security.

  6. In the Outbound Security dialog box, select either Anonymous access or Integrated Windows Authentication. If you selected Integrated Windows Authentication, make sure that the Windows SharePoint Services Central Administration application pool account is authenticated on the SMTP server by selecting the Account and Password check boxes.

Resolution: Configure outgoing e-mail settings in Central Administration

  1. On the Central Administration page, click System Settings and in the E-Mail section click Configure Outgoing E-Mail Settings.

  2. On the Outgoing E-Mail Settings page, in the Mail Settings section type the correct SMTP server in the Outbound SMTP server text box.

Verify that an e-mail alert is sent

  1. Navigate to a SharePoint Foundation Web site that has a list of any type.

  2. Click an item in the list.

  3. Click an item in the list and on the ribbon, click Share & Track.

  4. Click Alert Me and from the menu select For this item.

  5. In the New Alert dialog box, in the Send Alerts To section, type the account name in the Users box.

  6. After verifying other settings, click OK.

    An e-mail message is sent to the e-mail Inbox informing you that you have created a new alert.


SharePoint lists cannot receive e-mail - Event 6872 (SharePoint 2010 Products)

Alert Name: SharePoint lists cannot receive e-mail

Event ID: 6872

Summary: The Microsoft SharePoint 2010 Products incoming e-mail service processes e-mail messages to be added to SharePoint lists. The service processes mail that the Windows Simple Mail Transfer Protocol (SMTP) service added to a drop folder.

Symptoms: One or more of the following symptoms might appear:

  • SharePoint lists do not receive incoming e-mail.

  • Duplicate items appear in lists that are receiving incoming e-mail.

  • This event appears in the event log: Event ID: 6872 Description: the incoming email service cannot access the drop directory or doesn't have sufficient permissions.

Cause: One or more of the following might be the cause:

  1. The SharePoint timer service does not have read permissions on the drop folder.

  2. The specified drop folder specified doesn't exist.

  3. The SharePoint timer service does not have write permissions on the drop folder.

Resolution: Configure the drop directory in IIS

  • In the Internet Information Services (IIS) 6.0 Manager snap-in, expand the Server node.

  • In the SMPT Virtual Server node, double-click Domains.

  • Right-click the domain, and then click Properties.

  • Record the location of the drop directory. If no drop directory exists, create one.

  • Grant the SharePoint timer service permissions to the drop directory.

Resolution: Configure the incoming email settings

  • On the Central Administration Home page, click System Settings.

  • On the System Settings page, in the E-Mail and Text Messages (SMS) section, click Configure incoming email settings.

  • On the Configure Incoming E-mail Settings page, if the Advanced option is selected in the Directory Management Service section, type the location of the drop directory from the previous procedure in the E-mail drop folder box, and then click OK.


E-mail service cannot deliver e-mail - Event 6873 (SharePoint 2010 Products)

Alert Name: E-mail service cannot deliver e-mail

Event ID: 6873

Summary: The Microsoft SharePoint 2010 Products e-mail service processes e-mail destined for insertion into SharePoint lists. The service processes mail that the Windows Simple Mail Transfer Protocol (SMTP) service added to a drop folder.

Symptoms: One or more of the following symptoms might appear:

  • SharePoint lists do not receive e-mail.

  • This event appears in the event log: Event ID: 6599 Description: an error occurred while processing incoming email

Cause: One or more of the following might be the cause:

  • There is no corresponding SharePoint list for the recipient of an e-mail.

  • The sender does not have sufficient permissions to add content to the SharePoint list.

Resolution: Verify that the list is configured to receive e-mail

  1. In the list provided in the event details, on the List menu, click List Settings.

  2. On the List Settings page, under Communications, click Incoming e-mail settings.

  3. Verify the following:

    • The correct e-mail address is entered in the E-mail address box.

    • The Yes option is selected under Allow this document library to receive e-mail?

Resolution: Grant the sender the appropriate permissions to the recipient list

  1. In the list provided in the event details, on the List menu, click List Settings.

  2. On the List Settings page, under Permissions and Management, click Permissions for this list.

  3. Verify that the user account provided in the event details has at least Contributor permissions to the list.


Event receiver failed - Event 6875 (SharePoint 2010 Products)

Alert Name: Event receiver failed

Event ID: 6875

Summary: In Microsoft SharePoint Foundation 2010, you can bind an event handler to an event host (such as an entire site, a list, or a document library). By binding an event handler to an event host, you can use document library events to start other processes, such as workflow processes.

Symptoms: This event appears in the event log: Event ID: 6875 Description: Error loading and running event receiver <receiver name> in <receiver location>. Additional information is below. <additional information>.

Cause: One or more of the following might be the cause:

  • The custom event receiver assembly cannot be found, or it is corrupted.

  • The SharePoint Foundation 2010 assembly cannot be found, or it is corrupted.

Resolution: Contact the manufacturer of the faulty event receiver

  1. If the faulty assembly is corrupted, and it is not a SharePoint Foundation 2010 assembly, contact the manufacturer of the faulty event receiver assembly for more information.

Resolution: Repair your product installation

  1. Repairing the installation will require you to restart the server. Web application modifications and other changes to settings will be preserved.

    Note:

    You must be a member of the Administrators group on the local computer to perform this task.

    To repair SharePoint Foundation 2010 installation:

    1. In Control Panel, open Programs and Features.

    2. Select your installation of SharePoint Foundation 2010 from the list, and then click Change.

    3. In the SharePoint Products Configuration Wizard, select Repair, and then click Continue.

    4. After completing the changes in the SharePoint Products Configuration Wizard, verify that the event handler assembly is either repaired or removed from all farm servers.

    5. Retry the operation that triggered the event handler. These events should not continue to appear in the Windows event log.


Backup timer job could not be created - Event 7035 (SharePoint 2010 Products)

Alert Name: Backup timer job could not be created

Event ID: 7035

Summary: When you back up a Web application, you back up the content databases and settings for the Web application, including all sites in the site collections, files in document libraries, files attached to lists, security and permission settings, and feature settings. The backup process creates files that contain all of this data. The restore process uses these files to restore the content databases and settings for the Web application.

Similarly, when you back up a site collection, site, or list, the contents of those structures will be written to files or packages, and the restore or import process will use these files to recover the objects.

Symptoms: One or more of the following symptoms might appear:

  • One or more warning notifications will appear under the Readiness section of the Backup and Restore Job Status or Granular Backup Job Status pages in Central Administration.

  • The following event appears in the event log: Event ID: 7035 Description: The same item is already in the process of being backed up or restored. To check the status of that process, go to the backup/restore job status page in the administration site.

Cause: An existing backup/restore timer job has failed or was not fully completed, and the SharePoint Timer Service or SharePoint Admin Service are not started.

Verify that the Timer and SharePoint Administration services are running

  1. Ensure that the following services are started:

    1. The SharePoint Timer V4 service must be started on all front-end Web servers and application servers in the farm.

    2. The SharePoint Administration V4 service must be started on the server that is running the Central Administration Web site.

Resolution: Verify that the previous backup or restore timer job completed successfully

  • Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.

  • On the Central Administration Home page, click Backup and Restore.

  • On the Backup and Restore page, under Farm Backup and Restore, click Check backup and restore job status.

  • On the Backup and Restore Job Status page, under Readiness, verify that there are no backup or restore jobs in progress, that the Timer service is running, and that the Administration service is running.

  • Click the Back button in the browser.

  • On the Backup and Restore page, under Granular Backup, click Check granular backup job status.

  • On the Granular Backup Job Status page, under Readiness, verify that there are no backup jobs in progress, there are no export jobs in progress, and the Timer service is running.

  • Check the status of any current jobs in the Site Collection Backup and Content Export sections.


Central Administration update failed - Event 7037 (SharePoint 2010 Products)

Alert Name: Central Administration update failed

Event ID: 7037

Summary: This error indicates that the Microsoft SharePoint Foundation 2010 timer job to update Central Administration on a specific URL was not created, or the local registry-based URL for the Central Administration was not updated.

Symptoms: One or more of the following symptoms might appear:

  • Local server URL settings for the Central Administration Web site do not match the configured settings.

  • This event appears in the event log: Event ID: 7037 Description: Error creating timer job to update central administration url location at <URL>.

Cause: One or more of the following might be the cause:

  • The timer job that updates the Central Administration settings failed to be created. This failure may be caused by a communication failure with the configuration database while the configuration object was created.

  • The Central Administration URL registry location on the local server failed to be updated because of registry key permission issues.

Resolution: Grant permissions to the appropriate hive location in registry

  • Make sure that the local administrators and farm administrators groups have full control permissions on the local registry-based URL for the Central Administration.

    Note:

    Incorrectly editing the registry might severely damage the system. Before making changes to the registry, back up any valued data on the computer.

    1. Click Start, click Run, type regedit, and then click OK.

    2. In Registry Editor, in the tree view, locate the following registry key:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0\WSS\CentralAdministrationURL.

    3. Right-click the registry key, and then click Permissions.

    4. Make sure that the Administrators and WSS_ADMIN_WPG local groups have Allow Full Control permissions, and no Deny permissions have been set. Do not remove or change permissions for any other group or user entry for this registry key.

Resolution: Restart the update of the Central Administration Web site port

  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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Set-SPCentralAdministration -Port <Int32>

    Where:

    • <Int32> is the new port number.

For more information, see Set-SPCentralAdministration.

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.


Throttling starts alert- Events 8032 8062 (SharePoint 2010 Products)

Alert Name: SPServer throttling starts

Event ID: 8032 or 8062

Summary: The front-end Web throttling feature is introduced in Microsoft SharePoint Foundation 2010 to keep the server from running out of resources for high-priority server jobs. Throttling monitors performance counters on the server and begins to reject low-priority jobs by returning a 503 error message when the counter values exceed or drop lower than predefined thresholds.

Symptoms: The following symptoms might appear:

  • Users receive a 503 error in the browser: The server is busy now. Try again later.

  • This event appears in the event log: Event ID: 8032 Description: Http throttling starts because a heavy load was detected on <server name> the web app name. The excessive performance counters include: <performance counter name>.

  • This event appears in the event log: Event ID: 8062 Description: Http throttling on <server name> stops because there is no heavy load detected now. <# of requests> requests have been throttled during the throttling period.

Cause: Memory Available and/or ASP.NET\Requests Current have exceeded or dropped lower than the predefined threshold on the front-end Web servers.

Resolution: Change the throttling threshold

  1. Click Start, click All Programs, click Microsoft SharePoint 2010 Products, and then click SharePoint Management Shell. A Command Prompt window opens.

  2. Enter the following command to obtain the current setting of the performance counter thresholds.

    Get-SPWebApplicationHttpThrottlingMonitors URL

  3. Review the thresholds and decide whether you have to change the current values to less-restrictive thresholds. For example, the following Windows PowerShell command can be used to set the CPU percentage threshold to 75 percent.

    Set-SPWebApplicationHttpThrottlingMonitor URL -Category Processor -Counter "% Processor Time" -instance _Total -Max 75

Resolution: Disable the throttling feature

  1. On the SharePoint Central Administration Web site, in the Application Management section click Manage web applications.

  2. On the Web Application tab of the ribbon, click General Settings and select Resource Throttling to turn off HTTP throttling.

    Note:

    Turning off the throttling feature puts the server at risk of running out of resources to serve high-priority jobs in case of high workload. We do not recommend that you ordinarily turn off the throttling feature.

Resolution: Upgrade hardware

  • Review your capacity plan. You can take different actions can be taken as remedies depending on the reason that throttling is triggered:

    1. Add more memory

    2. Upgrade CPU

    3. Upgrade front-end Web servers

    4. Add more front-end Web servers

    5. Upgrade SQL Server host servers


Cannot retrieve end point - Event 8070 (SharePoint 2010 Products)

Alert Name: Cannot retrieve end points

Event ID: 8070

Summary: The Application Discovery and Load Balancer Service Application is unable to retrieve the list of end points for a service application from the remote farm.

Symptoms: This event appears in the event log: Event ID: 8070 Description: An exception occurred when trying to call GetEndPoints: <EndPoint Name>.

Cause: One or more of the following might be the cause:

  • This farm does not have permissions to connect to the remote farm.

  • Network errors or connectivity issues prevent this operation from succeeding.

Note:

You must be a member of the Farm Administrators SharePoint group on the Central Administration site to perform the following task.

Resolution: Ensure that this farm has permissions to connect to the remote farm

  • Contact the administrator of the remote farm to ensure that the following is true:

    • This farm has been added as a trusted farm in the remote farm.

    • This farm's service account has permissions to access the topology service on the remote farm.

  • Ensure that the remote farm has been added as a trusted farm on this farm.

  • To establish the trust between two server farms, each farm must add the other farm's public root certificate to the list of trusted root authorities by using the New-SPTrustedRootAuthorityWindows PowerShell command. For more information, see New-SPTrustedRootAuthority.

Resolution: Ensure that there are no network issues in connecting to the remote farm

  • Ping the servers in the remote farm to ensure that they are available.

  • Contact the remote farm administrator to ensure that there are no connectivity issues on that farm.


Log folder does not exist - Event 8074 (SharePoint 2010 Products)

Alert Name: Log folder does not exist

Event ID: 8074

Summary: The logging folder specified in the error message does not exist or cannot be accessed.

Symptoms: This event appears in the event log: Event ID: 8074 Description: Unable to access directory <directoryname> on server <servername>. Ensure that this directory exists and that the account <domain>\<username> can access it.

Cause: One or more of the following might be the cause:

  • The folder does not exist.

  • The SharePoint 2010 Tracing Service (SPTraceV4) account does not have permissions to read and write to this folder.

Resolution: Verify that usage logging folder exists

  • Log on to the server that is listed in the event.

  • Navigate to the folder that is listed in the event.

  • If the folder does not exist, create the folder.

  • Verify that the SharePoint 2010 Tracing Service (SPTraceV4) account has read, write, and delete permission to the folder.


Usage timer job failed - Event 8075 (SharePoint 2010 Products)

Alert Name: Usage timer job failed

Event ID: 8075

Summary: The Usage Data Processing timer job failed.

Symptoms: This event appears in the event log: Event ID: 8075 Description: The Usage Data Processing timer job failed. You can rerun this job using the Timer Job Status page in the SharePoint Central Administration site.

Cause: One or more of the following might be the cause:

  • Usage logging is not enabled.

  • The farm service account does not have sufficient permissions to the log folder.

  • The disk on which the log folder is located is full.

  • The logging database does not exist or cannot be written to.

  • There were network issues between the farm server and the database server.

Resolution: Verify that usage logging is running on all servers in the farm

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.

  2. On the Central Administration Home page, under System Settings, click Manage servers in this farm.

  3. On the Servers in Farm page, in the Server section, record the names of all the servers in the farm.

  4. For each server in the farm, do the following: In the Services snap-in, verify that the SharePoint 2010 Tracing Service (SPTraceV4) service is enabled and started. If it is not started, start it.

  5. From the Log On tab, record the Run As account for each service.

Resolution: Verify that usage logging folder exists

  1. Log on to the server that is listed in the event.

  2. Navigate to the folder that is listed in the event.

  3. If the folder does not exist, create the folder.

  4. Verify that the SharePoint 2010 Tracing Service (SPTraceV4) Run As account has read, write, and delete permissions to the folder.

Resolution: Verify that the logging database exists

  • Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.

  • On the Central Administration Home page, click Monitoring.

  • On the Monitoring page, in the Reporting section, click Configure usage and health data logging.

  • On the Configure web analytics and health data collection page, in the Usage Data Collection Settings section, record the server and location of the log folder from the Log file location box.

  • In the Logging Database Server section, record the location of the logging database from the Database Server and Database Name boxes.

  • In SQL Server Management Studio, connect to the database server.

  • Expand the Databases node, and verify that the database exists and that it is online.

Resolution: Rerun the timer job

  • Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.

  • On the Central Administration Home page, click Monitoring.

  • On the Monitoring page, in the Reporting section, click Configure usage and health data logging.

  • On the Job Definitions page, click the Microsoft SharePoint Foundation Usage Data Processing timer job.

  • On the Edit Timer Job page, click Run Now.


Business Data Connectivity Service - BDC database adapter connection exception - Event 8080 (SharePoint 2010 Products)
See Also

Alert Name: Business Data Connectivity Service - BDC database adapter connection exception

Event ID: 8080

Summary: The Business Data Connectivity service runtime reads the metadata defined in the service application model, establishes a connection with the external data source, and calls the appropriate methods defined in the application model for any of the operations. This event is logged if this connection cannot be established for a database. None of the operations triggered by client applications will be executed, and the data may be rendered obsolete.

Symptoms: This event appears in the event log: Event ID: 8080 Description: The BDC service application %1 failed to open connection using %2.

Cause: One or the more of the following might be the cause:

  • The Business Data Connectivity service application model does not have the correct connection properties for the external data source.

  • The external data source is currently not functioning and is not responding.

Note:

You must be a member of the Farm Administrators SharePoint group to perform the following procedure.

Resolution: Verify that the external data source connection properties are correct

  1. On the Central Administration Home page, click Application Management.

  2. On the Application Management page, in the Service Applications section, click Manage service applications.

  3. On the Service Applications page, select the BDC Service Application.

  4. On the Edit tab, in the View group, click External systems.

  5. Click the external system to view its instances.

    Tip:

    By default, the only instances of external system types that are configurable are databases and Web services.

  6. Select the external system name.

  7. Edit or view the settings.

For more information about the settings that are available for configuring a database external system, see Configure an instance of an external system. For more information about managing BDC models, see Manage BDC models (SharePoint Foundation 2010).

Resolution: Verify that the network connection to the external data source is working

  • Open a Command Prompt window on the application server and type PING<servername>, where <servername> is the database server that hosts the external data source.

See Also

Other Resources

Resource Center: Operations and Manageability for SharePoint Server 2010
Resource Center: Operations and Manageability for SharePoint Foundation 2010


Business Data Connectivity Service - BDC Web service proxy generations exception - Event 8082 (SharePoint 2010 Products)
See Also

Alert Name: Business Data Connectivity Service - BDC Web service proxy generation exception

Event ID: 8082

Summary: While working with a Web service, the Business Data Connectivity service will first obtain a proxy and then call the appropriate methods based on the metadata defined in the application model. This event is logged when the Business Data Connectivity service fails to obtain a proxy to a Web service. This will affect data synchronization between the client computer and the external data source.

Symptoms: The following event appears in the event log: Event ID: 8082 Description: The Business Data Connectivity Service Could not obtain a proxy to WebService for External Data Source '% ExternalDataSourceName %.

Cause: One or the more of the following might be the cause:

  • The Business Data Connectivity service application model does not have the correct connection properties for the external data source.

  • The external data source is down and is not responding.

Note:

You must be a member of the Farm Administrators SharePoint group to perform the following action.

Resolution: Verify that the external data source connection properties as defined in the application model are correct

  1. On the Central Administration Home page, click Application Management.

  2. On the Application Management page, in the Service Applications section, click Manage service applications.

  3. On the Service Applications page, select the BDC Service Application.

  4. On the Edit tab, in the View group, click External systems.

    Tip:

    By default, the only external system type that is configurable is a Web service. By default, the only instances of external system types that are configurable are databases and Web services.

  5. Point to the external system, click the arrow that appears, and then click Settings.

  6. Edit or view the settings.

For more information about how to configure and manage an external data source, see Configure an instance of an external system in the article "Manage external systems (SharePoint Foundation 2010)." For more information about managing BDC models, see Delete a BDC model.

Resolution: Verify that the external data source is accessible

  • From the application server, ping the database server that hosts the external data source to confirm that the servers can communicate over the network.

See Also

Other Resources

Resource Center: Operations and Manageability for SharePoint Server 2010
Resource Center: Operations and Manageability for SharePoint Foundation 2010


Business Data Connectivity Service - BDC Proxy - unexpected exception - Event 8085 (SharePoint 2010 Products)
See Also

Alert Name: Business Data Connectivity Service - BDC proxy unexpected exception

Event ID: 8085

Summary: When a Web server receives a request from a client computer, it routes the request to an application server through a load balancer. The load balancer maintains a list of available servers for a given service application. If the Business Data Connectivity service application on one or more application servers does not respond, the load balancer drops the application server from the list of available servers and this event is logged.

If the Business Data Connectivity service application is enabled on more than one application server, the client computers may not be affected. If the service application is enabled on only one application server, the client computers that rely on the metadata in the Business Data Connectivity metadata store will fail to read or write data from the external data sources defined in the metadata. The load balancer will ping the service application periodically and will automatically re-enlist it when it responds.

Symptoms: The client computers fail to read or write data from the external data sources.

Cause: One or the more of the following might be the cause:

  • The application server is not accessible or the Business Data Connectivity service application model does not have the correct connection properties for the external data source.

  • The external data source is currently not functioning and is not responding.

Note:

You must be a member of the Farm Administrators SharePoint group to perform the following actions.

Resolution: Verify that the application server is available

  1. On the Central Administration Home page, in the System Settings section, click Manage servers in this farm.

  2. On the Servers in Farm page, verify that the status of the server on which the Business Data Connectivity service runs is No Action Required.

Resolution: Verify that the Business Data Connectivity service application is provisioned correctly

  1. On the Central Administration Home page, click Application Management.

  2. On the Application Management page, in the Service Applications section, click Manage service applications.

  3. On the Service Applications page, find the Business Data Connectivity Service Application, and in the Status column, verify that the service proxy status is Started.

See Also

Other Resources

Resource Center: Operations and Manageability for SharePoint Server 2010
Resource Center: Operations and Manageability for SharePoint Foundation 2010


Business Data Connectivity Service - SQL exception - Event 8086 (SharePoint 2010 Products)
See Also

Alert Name: Business Data Connectivity Service - SQL exception

Event ID: 8086

Summary: The Business Data Connectivity service application connects to the metadata store to allow users to manage the metadata in the metadata store. This event is logged when the service application fails to connect to the database. The Business Data Connectivity metadata in the metadata store will not be accessible. This will impact importing and exporting application models or updating properties for any of the Business Data Connectivity objects by using the Business Data Connectivity Service Application Proxy page in the SharePoint Central Administration Web site.

Symptoms: This event appears in the event log: Event ID: 8086 Description: The BDC service application %name% error occurred because of a database exception.

Cause: One or the more of the following might be the cause:

  • The metadata database server is down or not accessible because of network issues.

  • The connection information for the Business Data Connectivity service application metadata database is incorrect.

  • The Business Data Connectivity service application metadata database was not provisioned correctly.

Resolution: Verify the availability of the metadata database server

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration Home page, click Application Management.

  3. On the Application Management page, in the Service Applications section, click Manage service applications.

  4. On the Service Applications page, select the Business Data Connectivity Service Application, and click Properties on the ribbon.

  5. Verify that the database server listed on the Properties page is available and can be connected to from SharePoint 2010 Products.

See Also

Other Resources

Resource Center: Operations and Manageability for SharePoint Server 2010
Resource Center: Operations and Manageability for SharePoint Foundation 2010


ULS trace log reaching maximum size - Event 8094 (SharePoint 2010 Products)

Alert Name: ULS trace log reaching maximum size

Event ID: 8094

Summary: The SharePoint 2010 Tracing Service (SPTracev4) is used by Microsoft SharePoint Foundation 2010 to manage trace message output. When trace logging is enabled, administrators can specify the path used to store the trace log file. This log file is used by many applications that are built on SharePoint Foundation 2010. This event occurs when the configured log file location is low on space. It serves as a warning that logging may stop soon unless more space is made available or the space allocated to logging is increased.

Symptoms: This event appears in the event log: Event ID: 8094 Description: Trace logs are reaching to the configured storage limit [configured limit]. Please increase the maximum storage settings. Otherwise, older files will be deleted once the limit is reached.

Cause: The configured log file location has insufficient free disk space for logging, or the maximum space allocated for logging is too low.

Resolution: Increase the space limit for log files

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration Home page, click Monitoring.

  3. On the Monitoring page, in the Reporting section, click Configure diagnostic logging.

  4. In the Trace Log section, in the Maximum storage space for Trace Logs (GB) box, type a larger number of gigabytes (GB) you want to allocate to the log files. When log files reach this size on disk, older log files will automatically be deleted

  5. Click OK.

Resolution: Change the location of the log files

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration Home page, click Monitoring.

  3. On the Monitoring page, in the Reporting section, click Configure diagnostic logging.

  4. In the Trace Log section, in the Path box, type the new location for the log file on a drive or partition that has sufficient disk space.

  5. Click OK.

Resolution: Free disk space

  1. Use the Disk Cleanup tool to free disk space where the trace log files are stored.

  2. Verify that the tracing service has sufficient disk space to write the log file.

  3. If the trace logging service has insufficient disk space to write the log files, delete the contents of the Temp folders on the drive.


ULS usage log reaching maximum size - Event 8095 (SharePoint 2010 Products)

Alert Name: ULS usage log reaching maximum size

Event ID: 8095

Summary: The SharePoint 2010 Tracing Service (SPTracev4) is used by Microsoft SharePoint Foundation 2010 to manage usage log output. When usage logging is enabled, administrators can specify the path used to store the usage log file. This log file is used by many applications that are built on SharePoint Foundation 2010. This event occurs when the configured log file location is low on space. It serves as a warning that logging may stop soon unless more space is made available or the space allocated to logging is increased.

Symptoms: This event appears in the event log: Event ID: 8095 Description: Usage logs are reaching to the configured storage limit [configured limit]. Please increase the maximum storage settings. Otherwise, older files will be deleted once the limit is reached.

Cause: The configured log file location has insufficient free disk space for logging, or the maximum space allocated for logging is too low.

Resolution: Increase the space limit for log files

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration Home page, click Monitoring.

  3. In the Reporting section, click Configure usage and health data collection.

  4. On the Configure web analytics and health data collection page, in the Usage Data Collection Settings section, type a larger number of gigabytes (GB) to allocate to the log files. When log files reach this size on the disk, older log files will automatically be deleted.

  5. Click OK.

Resolution: Change the location of the log file

  1. On the Central Administration Home page, click Monitoring.

  2. In the Reporting section, click Configure usage and health data collection.

  3. On the Configure web analytics and health data collection page, in the Usage Data Collection Settings section, type a new location for the log file on a drive or partition that has sufficient disk space.

  4. Click OK.

Resolution: Free disk space

  1. Run the Disk Cleanup tool to free disk space where the usage log files are stored.

  2. Verify that the usage logging service has sufficient disk space to write the log file.

  3. If the usage logging service has insufficient disk space to write the log file, delete the contents of the Temp folders on the drive.

To check the usage log file

  1. On the Central Administration Home page, click Monitoring, and in the Reporting section, click Configure usage and health data collection.

  2. On the Configure web analytics and health data collection page, in the Usage Data Collection Settings section, copy the path of the usage log file.

  3. In Windows Explorer, navigate to the usage log file by using the copied path. Usage log files are in binary format and the contents cannot be easily viewed and understood. The file size of the usage log increases over time and confirms that usage logging is working.


STS signing certificate missing - Event 8303 (SharePoint 2010 Products)

Alert Name: Security Token Service signing certificate missing

Event ID: 8303

Summary: The Security Token service (STS) signing certificate that Microsoft SharePoint 2010 Products uses to authenticate users is missing.

Symptoms: One or more of the following symptoms might appear:

  • Users are unable to log in to SharePoint 2010 Products.

  • This event appears in the event log: Event ID: 8303 Description: The Access Data Services is no longer available. [Session: <session ID> User: <username>].

Cause: One of the following might be the cause:

  • The STS signing certificate that is included with SharePoint 2010 Products is missing.

  • The self-signed STS signing certificate, or the external certificate that you are using, is missing.

Resolution: Import a new STS signing certificate from the SharePoint 2010 Products farm

  1. Retrieve the root certificate of your SharePoint 2010 Products farm.

  2. Export the root certificate.

  3. Use the makecert utility to generate a new STS signing certificate, based on the root certificate.

  4. Import the new certificate into the certificate store for your operating system.

Resolution: Import a new self-signed STS signing certificate or external certificate

  1. Retrieve the root certificate of your SharePoint 2010 Products farm.

  2. Export the root certificate.

  3. Regenerate the certificate.

  4. Import the new certificate into the certificate store for your operating system.


STS cannot sign credentials - Event 8304 (SharePoint 2010 Products)

Alert Name: Security Token Service cannot sign credentials

Event ID: 8304

Summary: The Security Token service (STS) cannot sign user credentials.

Symptoms: One or more of the following symptoms might appear:

  • Users are unable to log on to Microsoft SharePoint Foundation 2010.

  • Logon fails.

  • People Picker fails to search or resolve and return an error message.

  • This event appears in the event log: Event ID: 8307 Description: An exception occurred when trying to create signing credential: <exception>.

Cause: An error occurred with the claims provider that is specified in the exception description.

Resolution: Import a new STS signing certificate from the SharePoint 2010 Products farm

  1. Retrieve the root certificate of your Microsoft SharePoint 2010 Products farm.

  2. Export the root certificate.

  3. Use the makecert utility to generate a new STS signing certificate based on the root certificate.

  4. Import the new certificate into the certificate store for your operating system.

Resolution: Import a new self-signed STS signing certificate or external certificate

  1. Retrieve the root certificate of your SharePoint 2010 Products farm.

  2. Export the root certificate.

  3. Regenerate the certificate.

  4. Import the new certificate into the certificate store for your operating system.


Claims cannot establish endpoint - Event 8305 (SharePoint 2010 Products)

Alert Name: Security Token Service claims cannot establish an endpoint

Event ID: 8305

Summary: The Security Token service (STS) claims authentication cannot establish an endpoint.

Symptoms: One or more of the following symptoms might appear:

  • Users are unable to log on to Microsoft SharePoint Foundation 2010.

  • Logon fails.

  • This event appears in the event log: Event ID: 8305 Description: An exception occurred when trying to establish endpoint for context: <exception>.

Cause: The claims provider is not configured correctly.

To confirm that the STS service is running 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. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Get-SPServiceApplicationPool | Where {$_.DisplayName -eq <DisplayName>}| Format-List

    Where:

    • <DisplayName> is the display name of the STS service application pool. By default, this value is "SecurityTokenServiceApplicationPool".

  6. Verify that the Status of the application pool is Online.

Resolution: Revert changes to the Web.config file

  1. If the Web.config file was modified, try manually reverting to the previous version, or — if you backed up the file — restore the backup.


STS claims provider error - Event 8307 (SharePoint 2010 Products)

Alert Name: Security Token Service claims provider error

Event ID: 8307

Summary: The Security Token service (STS) experienced an error.

Symptoms: One or more of the following symptoms might appear:

  • Users are unable to log on to Microsoft SharePoint Foundation 2010.

  • Logon fails.

  • People Picker fails to search or resolve and return an error message.

  • This event appears in the event log: Event ID: 8307 Description: An exception occurred in <Claim Provider Name> claim provider when calling <Method Name>: <Exception>.

Cause: An error occurred with the claims provider that is specified in the exception description.

Resolution: Disable the claims provider

  1. Disable the claims provider that caused the error and contact the manufacturer of the claims provider for help resolving the error. For more information, see Configure claims authentication (SharePoint Foundation 2010)

    Important:

    Some SharePoint Foundation 2010 components might require the claims provider and might not function correctly if it is disabled. For example, shared service applications might fail during a call because the security modules expect that the system claims were added by this provider.


Administration service is not running (SharePoint 2010 Products)

Alert Name: Administration service is not running

Event ID: No event ID

Summary: The Microsoft SharePoint Foundation Administration service is required to run on all servers in a Microsoft SharePoint Foundation 2010 farm. This service performs multiple operations on the local server computers that require local administrator permissions for operations; for example, creating and deleting Web applications and service applications, and starting and stopping services. If this service is not running on any server in a SharePoint Foundation 2010 farm, administrative operations can fail or partially succeed.

Cause: One or more of the following might be the cause:

  • The SharePoint Foundation Administration service was stopped by an administrator on a particular computer.

  • The user name or password for the account that the SharePoint Foundation Administration service is set to run as is incorrect.

  • An error condition in the SharePoint Foundation Administration service caused the service to terminate.

Resolution: Start the administration service

  • Start the SharePoint Foundation Administration service by using the Services Microsoft Management Console (MMC) snap-in in Windows. Click Start, click Run and type the following:

    services.msc

Resolution: Check the service account

  • If the service fails to start, ensure that the user name and account have membership in the Administrators group on the local computer.

Resolution: Repair the configuration

  • If the service could not be started, try to repair the SharePoint Foundation configuration on that server by running the SharePoint Products and Technologies Configuration Wizard.


Document conversion launcher unavailable (SharePoint 2010 Products)

Alert Name: Document conversion launcher unavailable

Event ID: None

Summary: The Document Conversions Launcher Service starts document conversions on an application server. If the Document Conversions Launcher Service stops, the Document Conversions Load Balancer Service continues and any document conversion will fail. To resume the document conversion process, you must restart the Document Conversions Launcher Service.

Symptoms: One or more of the following symptoms might appear:

  • Documents are not being converted.

  • The Document Conversions Launcher Service is not running.

Cause: The Document Conversions Launcher service is no longer running. This can happen when an administrator unintentionally stops the service or the server runs out of RAM.

Note:

You must be a member of the Farm Administrators SharePoint group to perform the following task.

Resolution: Restart the services

  1. On the SharePoint Central Administration Home page, in the System Settings section, click Manage services on server.

  2. On the Services on Server page, click Document Conversions Launcher Service.

  3. In the Select Server section, verify that the server that you want is selected. If it is not selected, on the Server menu, click Change Server.

  4. On the Select Server page, click the name of the server on which you want to run the Document Conversions Launcher Service.

  5. In the Communication Scheme section, select the scheme that you want the launcher to use for communication. The default is http.

  6. In the Port Number section, type the port number that you want the launcher to use for communication. Choose a port number that is not used by other services on the server, but which is open in the firewall on the server.

  7. Click OK.


Document conversion load balancer unavailable (SharePoint 2010 Products)

Alert Name: Document conversion load balancer unavailable

Event ID: None

Summary: The Document Conversions Load Balancer Service manages the availability of document converters. Stopping the service stops the document conversion process and turns off the Document Conversions Launcher Service. To resume the document conversion process, you must restart the Document Conversions Load Balancer Service, and then start the Document Conversions Launcher Service.

Symptoms: One or more of the following symptoms might appear:

  • Documents are not being converted.

  • Only one server seems to be converting documents.

  • The Document Conversions Load Balancer Service is not running.

Cause: The Document Conversions Load Balancer Service is no longer running. This can occur when an administrator unintentionally stops the service or the server runs out of RAM.

Note:

You must be a member of the Farm Administrators SharePoint group to perform the following task.

Resolution: Restart the Document Conversions Load Balancer Service

  1. On the SharePoint Central Administration Home page, in the System Settings section, click Manage services on server.

  2. On the Services on Server page, click Document Conversions Load Balancer Service.

  3. In the Select Server section, verify that the server that you want is selected. If it is not selected, on the Server menu, click Change Server.

  4. On the Select Server page, click the name of the server on which you want to run the Document Conversions Load Balancer Service.

  5. In the Communication Scheme section, select the scheme that you want the load balancer to use for communication. The default is http.

  6. In the Port Number section, type the port number that you want the load balancer to use for communication. Choose a port number that is not used by other services on the server, but which is open in the firewall on the server.

  7. Click OK.

Resolution: Restart the Document Conversions Launcher Service

  1. On the SharePoint Central Administration Home page, in the System Settings section, click Manage services on server.

  2. On the Services on Server page, click Document Conversions Launcher Service.

  3. In the Select Server section, verify that the server that you want is selected. If it is not selected, on the Server menu, click Change Server.

  4. On the Select Server page, click the name of the server on which you want to run the Document Conversions Launcher Service.

  5. In the Communication Scheme section, select the scheme that you want the launcher to use for communication. The default is http.

  6. In the Port Number section, type the port number that you want the launcher to use for communication. Choose a port number that is not used by other services on the server, but which is open in the firewall on the server.

  7. Click OK.


Knowledge article is not yet available (SharePoint 2010 Products)

Alert Name: Knowledge article is not yet available

Event ID: None

Summary: The Microsoft System Center Operations Manager Management Pack monitors Microsoft SharePoint Foundation 2010. System Center Operations Manager raised an alert because of a problem in SharePoint Foundation 2010.

The link in the alert would go to a knowledge article with more details about how to resolve the problem. However, the knowledge article is not yet available. The article will be made available at a later date. To resolve the problem, try one or more of the following, in the order given (click the link to go to the procedure in this article):

  • View and resolve SharePoint Health Analyzer alerts by using Central Administration

  • Review the Windows Event log.

  • Review the diagnostic log.

  • Review the Management Pack Guide and the product documentation.

  • Restart the affected service.

  • Restart the application pool

  • Restart Internet Information Services.

  • Restart the affected server.

  • Contact Microsoft Support.

View and resolve SharePoint Health Analyzer alerts by using Central Administration

  1. Verify that the user account that is 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 Health Status section, click Review problems and solutions.

  4. On the Review problems and solutions page, click the alert that you want to view and resolve.

  5. To resolve the problem, follow the guidance given in the Remedy section of the Review problems and solutions dialog box. Keep the dialog box open so you can run the rule again to confirm the resolution.

  6. After following the guidance given in the Remedy section, in the Review problems and solutions dialog box for the alert, click Reanalyze Now to confirm the resolution. If the problem is resolved, the alert status changes to 4-Success.

Restart the application pool

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer.

  2. Perform the steps in the following article: Recycle an Application Pool on Demand (http://go.microsoft.com/fwlink/p/?LinkId=168806).


Sandboxed code is running (SharePoint 2010 Products)

Alert Name: SPServiceInstance sandboxed code is running

Event ID: No event ID

Summary: The SharePoint Sandboxed Code Host is a Windows NT service that runs on each Microsoft SharePoint Foundation server.

Symptoms: You are unable to perform requests that require the execution of user code or activation of sandboxed solutions that contain user code. The task that fails depends on the topology and on the server that has the stopped service.

Cause: The SharePoint Sandboxed Code Host service is not running.

Resolution: Start the service on the given server

  • You can restart the SharePoint Sandboxed Code Host on a specific server by using the following command at an elevated command prompt:

    net start spusercodev4


SharePoint Administration service is disabled (SharePoint 2010 Products)

Alert Name: SharePoint Administration service is disabled

Event ID: No event ID

Summary: The SharePoint Administration service V4 (SPAdminV4) is disabled, which prevents local server administration timer jobs from changing local server settings to match farm-wide settings.

Cause: The SharePoint Administration service V4 (SPAdminV4) is disabled and cannot be started.

Resolution: Disable the throttling feature

  • If you want the SharePoint Administration service V4 (SPAdminV4) to run in the environment, set the service to start automatically and then start the service. This can be achieved by using either the Services Microsoft Management Console (MMC) snap-in (services.msc) or, in the Command Prompt window, by using the following two commands in order and executed by a farm administrator who is also a member of the Administrators group on the local computer.

    SC CONFIG SPAdminV4 start= auto

    SC START SPAdminV4

Resolution: Execute administration timer jobs without starting administration service

  • If you do not want the SharePoint Administration service V4 (SPAdminV4) to be set to run in the environment — for example because of least-privilege considerations — the administration timer jobs can be executed directly on the local server without starting the administration service. To execute the timer jobs immediately, in SharePoint Management Shell, run the following Windows PowerShell command:

    Start-SPAdminJob

Note:

The Start-SPAdminJob operation must be run on all computers in the farm where the SharePoint Administration service V4 (SPAdminV4) is not run. Run this command to perform provisioning and other administrative tasks that would typically be performed by using the SharePoint Foundation Timer service (SPTimer_V4).


SharePoint Foundation 2010 search is not running (SharePoint 2010 Products)

Alert Name: SharePoint Foundation search is not running

Event ID: No event ID

Summary: The Microsoft SharePoint Foundation 4 Search service (SPSearch4) is a Windows NT service that runs on each server that hosts a search service application.

Symptoms: One or more of the following symptoms might appear:

  • The Microsoft SharePoint Foundation 4 Search service (SPSearch4) is stopped.

  • You are unable to perform tasks when you attempt to use the crawl, query, or administration search functionality. The task that fails depends on the topology and on which server has the stopped service.

Cause: The Microsoft SharePoint Foundation 4 Search (SPSearch4) service is not running.

Resolution: Start the service on the server

  • You can restart the Microsoft SharePoint Foundation 4 Search (SPSearch4) service on a specific server by typing the following command at an elevated command prompt:

    net start spsearch4


SharePoint Health Analyzer has detected an error or warning (SharePoint 2010 Products)

Alert Name: SharePoint Health Analyzer has detected an error or warning

Event ID: None

Summary: The SharePoint Health Analyzer has detected an error or warning that affects the performance, availability or security of the farm. For instructions for fixing the error or warning condition, review the error message and explanation..

Resolution: View and resolve SharePoint Health Analyzer alerts by using Central Administration

  1. Verify that the user account that is 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 Health Status section, click Review problems and solutions.

  4. On the Review problems and solutions page, click the alert that you want to view and resolve.

  5. To resolve the problem, follow the guidance given in the Remedy section of the Review problems and solutions dialog box. Keep the dialog box open so you can run the rule again to confirm the resolution.

  6. After following the guidance given in the Remedy section, in the Review problems and solutions dialog box for the alert, click Reanalyze Now to confirm the resolution. If the problem is resolved, the alert status changes to 4-Success.


SharePoint Timer service could not start (SharePoint 2010 Products)

Alert Name: SharePoint Services Timer service could not start

Event ID: None

Summary: Microsoft SharePoint Foundation 2010 uses the Windows SharePoint Services Timer V4 (SPTimerV4) service to run most system tasks. The timer service is restarted when the farm service account changes, and it is restarted daily during the timer service recycle job. If SharePoint Foundation 2010 cannot start the timer service, updates to the farm configuration will be not be synchronized to the local server.

Symptoms: Frequently recurring timer jobs, such as Immediate Alerts and Workflow, do not run. Updates to the farm configuration are not synchronized to the local server.

Cause: SharePoint Foundation 2010 cannot start the Windows SharePoint Services Timer V4 (SPTimerV4) service.

Resolution: Start the timer service

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer.

  2. Open a Command Prompt window, type the following command at the command prompt, and then press ENTER:

    net start sptimerv4

  3. If the service does not start, ensure that the service identity account is configured correctly by using the "Verify the service account" procedure later in this article.

Resolution: Verify the service account

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer.

  2. Click Start, click Administrative Tools, and then click Services.

  3. In the Services snap-in, right-click the Windows SharePoint Services Timer V4 service, and then click Properties.

  4. In the Service Properties dialog box, on the Log On tab, type the password for the account, confirm the password, and then click OK.

  5. Right-click the service, and then click Start.


SharePoint Timer service is not running (SharePoint 2010 Products)

Alert Name: Windows SharePoint Services Timer service is not running

Event ID: None

Summary: Microsoft SharePoint Foundation 2010 uses the Windows SharePoint Services Timer V4 (SPTimerV4) service to run most system tasks.

Symptoms: Frequently recurring timer jobs, such as Immediate Alerts and Workflow, do not run. Updates to the farm configuration are not synchronized to the local server.

Cause: The Windows SharePoint Services Timer V4 (SPTimerV4 service is not running.

Resolution: Start the timer service

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer.

  2. Open a Command Prompt window, type the following command at the command prompt, and then press ENTER:

    net start sptimerv4

  3. If the service does not start, ensure that the service identity account is configured correctly by using the "Verify the service account" procedure later in this article.

Resolution: Verify the service account

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer.

  2. Click Start, click Administrative Tools, and then click Services.

  3. Right-click Windows SharePoint Services Timer V4, and then click Properties.

  4. On the Log On tab, confirm that the account being used is a domain user account and is a member of the following:

    • dbcreator fixed SQL Server server role

    • securityadmin fixed SQL Server server role

    • db_owner fixed database role for all databases in the server farm

  5. If the account has sufficient permissions, confirm the password by typing the password for the account, retyping the password in the Confirm password box, and then clicking OK.

  6. Start the service by right-clicking the service name in the Services console, and then clicking Start.


SQL Server remote access is disabled (SharePoint 2010 Products)

Alert Name: SQL Server remote access is disabled

Event ID: None

Summary: Microsoft SharePoint 2010 Products uses Microsoft SQL Server 2008 Express to store data, to which remote access is disabled by default. Depending on your farm setup, there is the possibility that a remote computer will need access to the SQL Server 2008 Express database.

Symptoms: Connecting to SQL Server 2008 Express from a remote server fails.

Cause: Remote access is disabled

Resolution: Enable remote access

  1. Enable remote access. For more information, see How to configure SQL Server 2005 to allow remote connections (http://support.microsoft.com/kb/914277).


Tracing service is not running (SharePoint 2010 Products)

Alert Name: Tracing service is not running

Event ID: No event ID

Summary: The Microsoft SharePoint Foundation Tracing (SPTrace) service is a required service on all Microsoft SharePoint Foundation servers. If this service is stopped, error messages are not logged on the server.

Symptoms: No trace output is being recorded in the trace logs and no errors are being logged to the Windows log.

Cause: One or more of the following might be the cause:

  • An administrator accidentally stopped the SharePoint Foundation Tracing service.

  • An upgrade that was started on this server could not be completed.

Resolution: Start the Trace service

  1. Log on to the SharePoint Foundation server as an administrator.

  2. In a Command Prompt window, type the following at the command prompt:

    net start SPTrace


Web application taking too long to render a page (SharePoint 2010 Products)

Alert Name: Web application taking too long to render a page

Event ID: None

Summary: The Microsoft SharePoint Foundation 2010 Executing Time/Page Request performance counter monitors how long a Web application takes to render a Web page. This performance counter threshold can be exceeded when the network temporarily experiences congestion or a peak in demand from the computer that is running Microsoft SQL Server. If the threshold is exceeded even when the network is not congested, the Web application is consuming too much memory.

Symptoms: One or more of the following symptoms might appear:

  • Pages take too long to render.

  • The Executing Time/Page Request performance counter threshold is frequently exceeded.

Cause: One or more of the following might be the cause:

  • SharePoint Foundation 2010 is configured incorrectly.

  • The server hardware is insufficient to handle user requests.

Resolution: Implement configuration best practices

  • Follow the recommendations for the top configuration best practices in Best practices for operational excellence.

Resolution: Tune Web server performance

  • Follow the recommendations for physical architecture and tuning that can help improve the performance of Web servers in Tune Web server performance (Office SharePoint Server).


Web application unavailable (SharePoint 2010 Products)

Alert Name: Web application unavailable

Event ID: None

Summary: This monitor attempts to access the Web application from the System Center Operations Manager (SCOM) server by using the Run as administrator account. The monitor is changed to an error state when the SCOM server receives a status code greater than 400.

Symptoms: The SCOM server receives a status code greater than 400.

Cause: One or more of the following might be the cause:

  • The Web application is unavailable.

  • The Run as administrator account does not have sufficient permission to access the Web application.

Resolution: Verify that the Web application exists and is running

  1. In the Internet Information Services (IIS) snap-in, expand the server node and the Sites node.

  2. Select the Web site for the Web application and ensure that the site is running. If it is not running, start it. If you cannot start it, go to the next step.

  3. Select the Application Pools node. In the right-pane, ensure that the application pool for the Web application is started. If it is not, start it. If you cannot start it, go to the next step to check the Identity account.

  4. Right-click the application pool, and then click Advanced Settings.

  5. In the Advanced Settings dialog box, in the Process Model section, ensure that the Identity account has sufficient permissions to run the Web application.

  6. You might have to update the password for the Identity account. To do this, click the ellipsis next to the account.

  7. In the Application Pool Identity dialog box, click Set.

  8. In the Set Credentials dialog box, type the account name and password, and then click OK.

  9. In the IIS snap-in, try to start the application pool. If it does not start, the account does not have sufficient permissions. If it does start, then start the Web site.

Resolution: Confirm that the Run as administrator account has sufficient permissions

  1. On the Central Administration Home page, click Security, and in the Users section, click Specify web application user policy.

  2. On the Authentication Providers page, select the correct Web application. To select a Web application, click the arrow next to the Web Application list, and then click Change Web Application. In the Select Web Application dialog box, click the correct Web application.

  3. Click the Run as administrator account. This is the account that is specified as the Identity account in the above resolution. If the account is not listed, go to the next step.

  4. Click Add Users.

  5. On the Edit Users page, in the Permission Policy Levels section, select the Full Control - Has full control check box.

  6. Click Save.


Web site unavailable (SharePoint 2010 Products)

If a Web page is not available, SharePoint 2010 Products cannot render the Web page and users cannot access it.

Alert Name: Web site unavailable

Event ID: None

Summary: If a Web page is not available, SharePoint 2010 Products cannot render the Web page and users cannot access it.

Symptoms: The SharePoint 2010 Products Web site is down, or pages on the Web site do not render.

Cause: One or more of the following might be the cause:

  • The Web site is unavailable.

  • The management pack Run as administrator account does not have permission to access SharePoint 2010 Products Web site.

Resolution: Verify that the Web site appears in the site collection

  1. On the Central Administration Web site, on the Quick Launch, click Application Management.

  2. On the Application Management page, in the Site Collections section, click View all site collections.

  3. If the relative URL of the site collection is invalid, run Management Pack discovery.

  4. If the problem persists after running Management Pack discovery, verify the following:

    • The SharePoint Foundation server that is hosting the Web site is running and can be accessed on the network.

    • Internet Information Services (IIS) is running.

Resolution: Confirm that the Run as administrator account has sufficient permissions

  1. On the Central Administration Home page, click Security and in the Users section, click Specify web application user policy.

  2. On the Authentication Providers page, select the correct Web application. To select a Web application, click the Web Application, and then click Change Web Application. In the Select Web Application dialog box, click the correct Web application.

  3. Click the Run as administrator account. This is the account that is specified as the Identity account in Information Internet Services (IIS) for the Web application that runs the Web site. If the account is not listed, click Add Users.

  4. On the Edit Users page, in the Permission Policy Levels section, select the Full Control - Has full control check box.

  5. Click Save.


SharePoint Health Analyzer rules reference (SharePoint Foundation 2010)

The articles in this section are articles for the SharePoint Health Analyzer. Typically, you would see these articles after you click a link in a message in the SharePoint Health Analyzer in Central Administration. You can use these articles to help you troubleshoot problems in Microsoft SharePoint Foundation 2010.

In this section:

  • Web Applications using Claims authentication require an update (SharePoint Foundation 2010)

    This article describes the SharePoint Health Analyzer rule "Web Applications using Claims authentication require an update", and describes how to update Claims Authentication.

  • Automatic update setting inconsistent across farm servers (SharePoint Foundation 2010)

    This article describes the SharePoint Health Analyzer rule "Automatic update setting inconsistent across farm servers", and describes how to configure automatic update settings to be consistent across the farm.

  • Diagnostic logging is set to verbose (SharePoint Foundation 2010)

    This article describes the SharePoint Health Analyzer rule "Diagnostic logging is set to verbose", and describes how to configure diagnostic logging.

  • The server farm account should not be used for other services (SharePoint Foundation 2010)

    This article describes the SharePoint Health Analyzer rule "The server farm account should not be used for other services", and describes how to change the account that is used for other services.

  • One or more services have started or stopped unexpectedly (SharePoint Foundation 2010)

    This article describes the SharePoint Health Analyzer rule "One or more services have started or stopped unexpectedly", and describes how to start the service that is not running.

  • Databases used by SharePoint have fragmented indices (SharePoint Foundation 2010)

    This article describes the SharePoint Health Analyzer rule "Databases used by SharePoint have fragmented indices", and describes how to reorganize and rebuild indexes.

  • Content databases contain orphaned items (SharePoint Foundation 2010)

    This article describes the SharePoint Health Analyzer rule "Content databases contain orphaned items", and describes how to remove orphan sites from the content.

  • Outbound e-mail has not been configured (SharePoint Foundation 2010)

    This article describes the SharePoint Health Analyzer rule "Outbound e-mail has not been configured", and describes how to configure outgoing e-mail settings in Central Administration.

  • Some health analyzer rules do not have associated timer jobs (SharePoint Foundation 2010)

    This article describes the SharePoint Health Analyzer rule "Some health analyzer rules do not have associated timer jobs", and describes how to create the health data collection timer jobs.

  • Drives are running out of free space (SharePoint Foundation 2010)

    This article describes the SharePoint Health Analyzer rule "Drives are running out of free space", and describes how to free disk space on the server computer.

  • The paging file size should exceed the amount of physical RAM in the system (SharePoint Foundation 2010)

    This article describes the SharePoint Health Analyzer rule "The paging file size should exceed the amount of physical RAM in the system", and describes how to increase the minimum size of the paging file.

  • Built-in accounts are used as application pool or service identities (SharePoint Foundation 2010)

    This article describes the SharePoint Health Analyzer rule "Built-in accounts are used as application pool or service identities", and describes how to change the identity that is used for the service or application pool.

  • Web Analytics: Monitors the health of the Report Consolidator component (SharePoint Foundation 2010)

    This article describes the SharePoint Health Analyzer rule "Web Analytics: Monitors the health of the Report Consolidator component", and describes how to enable data trimming to improve the performance of the Report Consolidator.

  • Web Analytics: Verifies that when the Web Analytics is installed and running, usage logging is enabled in the farm (SharePoint Foundation 2010)

    This article describes the SharePoint Health Analyzer rule " Web Analytics: Verifies that when the Web Analytics is installed and running, usage logging is enabled in the farm", and describes how to enable usage logging.

  • Web Analytics: Verifies that a web application is serviced by at most one Web Analytics service application proxy (SharePoint Foundation 2010)

    This article describes the SharePoint Health Analyzer rule "Web Analytics: Verifies that a web application is serviced by at most one Web Analytics service application proxy", and describes how to disassociate other Web Analytics service application proxies.

  • Web Analytics: Verifies that the SQL Server Service Broker is enabled for the Web Analytics staging databases (SharePoint Foundation 2010)

    This article describes the SharePoint Health Analyzer rule "Web Analytics: Verifies that the SQL Server Service Broker is enabled for the Web Analytics staging databases", and describes how to enable the service broker queue.

  • One or more categories are configured with verbose trace logging setting

    This article provides information about the SharePoint Health Analyzer rule "One or more categories are configured with verbose trace logging", describes the cause and includes a procedure that helps to ensure that diagnostic logging settings are configured correctly.

  • Accounts used by application pools or service identities are in the local machine Administrators group (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by changing the user account to a predefined account or to a domain user account that is not a member of the Administrators group.

  • Application pools recycle when memory limits are exceeded (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by disabling application pool recycling.

  • Alternate access URLs have not been configured (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by changing the default zone URL.

  • Product / patch installation or server upgrade required (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by deploying updates or upgrading.

  • Web.config file has incorrect settings for the requestFiltering element (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by changing the requestFiltering settings in the Web.config file.

  • Web.config files are not identical on all machines in the farm (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by making the Web.config files identical on all front-end Web servers in the farm.

  • The timer service failed to recycle (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by changing the schedule for the Timer Service Recycle job so that it does not conflict with other long-running timer jobs.

  • The Application Discovery and Load Balancer Service is not running in this farm (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by starting the Application Discovery and Load Balancer service on at least one server in the farm.

  • Databases running in compatibility range, upgrade recommended (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by installing software updates.

  • Databases require upgrade or not supported (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by installing software updates.

  • Databases within this farm are set to read only and will fail to upgrade unless it is set to a read-write state (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by setting the databases to read-write.

  • Drives used for SQL databases are running out of free space (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by freeing disk space on the database server computer or decreasing the number of days to store log files.

  • Databases used by SharePoint have outdated index statistics (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by editing the rule definition so that the configuration is automatically repaired.

  • Databases exist on servers running SharePoint Foundation (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by moving the databases to a separate server.

  • Database has large amounts of unused space (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by shrinking the database.

  • One or more servers is not responding (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by connecting the server to the network, restarting the SharePoint 2010 Timer service (SPTimerV4), or removing the server record from the SharePoint topology.

  • The local machine is not joined to a SharePoint server farm (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by creating a new farm or adding this computer to an existing farm.

  • The Security Token Service is not available (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by restarting the Security Token Service application pool.

  • Some content databases are growing too large (SharePoint Foundation 2010)

    This article describes how to resolve the SharePoint Health Analyzer event by editing the rule definition to prevent new sites from being added to the databases, and then moving some site collections to other databases.


Web Applications using Claims authentication require an update (SharePoint Foundation 2010)

Rule Name: Web Applications using Claims authentication require an update

Event ID: None

Summary: Web applications that use claims-based authentication are at risk for a potential security vulnerability that might allow users to elevate privileges. Web servers that host Web applications that use claims-based authentication are potentially vulnerable.

Cause: This can happen when you deploy a Microsoft ASP.NET 2.0-based Web application to a Web site that is hosted on a server running Microsoft SharePoint Foundation 2010 and you have Internet Information Services (IIS) 7.0 or IIS 7.5 running in Integrated mode on the server.

If you deploy partially trusted Web Parts or create external lists on the SharePoint site, these Web Parts or external lists can have more permissions than they should have. This issue might create a security risk on the SharePoint site. For example, these Web Parts or external lists may unexpectedly generate database requests or HTTP requests.

This issue occurs because of a change in the ASP.NET 2.0 authentication component. The change causes the partially trusted Web Parts or external lists to impersonate the application pool account. Therefore, the Web Parts have full permission to access the SharePoint site.

Resolution: Install the update

  • To download the update, go to KB979917 - QFE for SharePoint issues - Perf Counter fix & User Impersonation.

  • For more information about update, see Knowledge Base article 979917.


Automatic update setting inconsistent across farm servers (SharePoint Foundation 2010)

Published: May 29, 2010

Rule Name: Automatic update setting inconsistent across farm servers

Summary: Servers in the SharePoint farm do not have the same Automatic Update settings configured.

Cause: One or more servers in the farm have Automatic Update settings that are different from the other servers in the farm.

Resolution: Ensure all servers in the farm have the same Automatic Update settings

  • Verify that you are a member of the Administrators group on the local computer.

  • Choose an Automatic Update setting that is consistent on each server on the farm. On each server in the farm, open the Automatic Update settings page and ensure the settings are configured according to the planned consistent setting.

    1. Click Start, click All Programs, and then click Windows Update.

    2. On the Windows Update Control Panel page, click Change settings.

    3. On the Choose how Windows can install updates screen, make sure that the update settings are what you want. Change the update settings if necessary.

      Note:

      If you cannot change the update settings, the update settings may be locked because of group policy. If this is the case, ensure that the same group policy is being applied to other servers in the farm.


Diagnostic logging is set to verbose (SharePoint Foundation 2010)

Published: May 29, 2010

Rule Name: Diagnostic logging is set to verbose

Summary: SharePoint Foundation writes diagnostic logging information to record activity on the server. The logs contain information that can help you diagnose server problems. This rule occurs when diagnostic logging is set to verbose. The verbose setting is appropriate when you have to diagnose a server problem, but you should turn off verbose logging during normal operations.

Cause: One or more categories of diagnostic logging are set to verbose.

Resolution: Reset diagnostic logging to the default level

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration Home page, click Monitoring.

  3. On the Monitoring page, in the Reporting section, click Configure diagnostic logging.

  4. In the Event Throttling section, in the Least critical event to report to the event log list and Least critical event to report to the trace log list, select Reset to default.

  5. Click OK.


The server farm account should not be used for other services (SharePoint Foundation 2010)

Published: July 8, 2010

Rule Name: The server farm account should not be used for other services

Summary: The account that is used to run the SharePoint 2010 Timer service and other system services in the SharePoint farm should not be used for other services in the farm.

Cause: The Farm Account, which is used for the SharePoint 2010 Timer service and the Central Administration site, is highly privileged and should not be used for other services on any computers in the server farm. Services in the farm were found to use this account.

Resolution: Change the account that is used for other services

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.

  2. On the Central Administration home page, click Security, and then in the General Security section, click Configure service accounts.

  3. On the Service Accounts page, in the Credential Management section, in the upper drop-down list, click the service for which you want to update credentials.

  4. In the Select an account for this component list, click the domain account that you want to associate with this service.

  5. If you want to register the account that you selected on the SharePoint Foundation 2010 farm, click Register Managed Account.

  6. Click OK.


One or more services have started or stopped unexpectedly (SharePoint Foundation 2010)

Published: July 8, 2010

Rule Name: One or more services have started or stopped unexpectedly

Summary: A critical service required for the SharePoint farm to function is not running.

Cause: One or more critical services are not running on the specified server.

Resolution: Start the service that is not running

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer.

  2. Click Start, click Administrative Tools, and then click Services.

  3. Right-click the service that you want to start, and then click Start.


Databases used by SharePoint have fragmented indices (SharePoint Foundation 2010)
See Also

Published: July 8, 2010

Rule Name: Databases used by SharePoint have fragmented indices

Summary: Microsoft SharePoint Foundation 2010 uses Microsoft SQL Server to store most of the content for the Web site and configuration settings. One or more of the databases used by SharePoint Foundation have fragmented indexes. A fragmented index can cause degradation in performance.

Cause: Database indexes can fragment over time as a result of insert and update operations performed by SharePoint Foundation. We recommend that you periodically delete and rebuild these indexes to improve system performance.

Resolution: Reorganize and rebuild indexes

  1. To correct index fragmentation, you can reorganize an index or rebuild an index. For information, see Reorganizing and Rebuilding Indexes (http://go.microsoft.com/fwlink/p/?LinkID=160083&clcid=0x409).

See Also

Other Resources

Example: Index fragmentation with insert/updates, measuring it and fixing it


Content databases contain orphaned items (SharePoint Foundation 2010)

Published: July 8, 2010

Rule Name: Content databases contain orphaned items

Summary: The SharePoint Health Analyzer has detected some sites in a content database that are not referenced in the configuration database. These sites may not be accessible.

Cause: A restore operation that was not completed can result in sites in a content database that are not referenced in the SharePoint configuration database.

Resolution: Remove orphaned sites from the content databases

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration Home page, click Monitoring.

  3. On the Monitoring page, in the Health Analyzer section, click Review problems and solutions.

  4. On the Review problems and solutions page, click the alert for the failing rule, and then click Fix Now. Keep the dialog box open so you can run the rule again to confirm the resolution.

    Note:

    The Fix Now feature removes all orphans from the content database.

  5. After following the steps in the Remedy section, in the Review problems and solutions dialog box for the alert, click Reanalyze Now to confirm the resolution. If the problem is resolved, the rule is not flagged as a failing rule on the Review problems and solutions page.


Outbound e-mail has not been configured (SharePoint Foundation 2010)

Published: July 8, 2010

Rule Name: Outbound e-mail has not been configured

Summary: An outgoing e-mail server has not been configured on this SharePoint Foundation deployment. With no SMPT server configured for outgoing e-mail, SharePoint Foundation cannot send e-mail messages, including alert e-mail, confirmation e-mail, invitation e-mail, and e-mail about exceeding quotas.

Cause: An SMPT e-mail server has not yet been configured in the farm.

Resolution: Configure outgoing e-mail settings in Central Administration

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration Home page, click System Settings.

  3. On the System Settings page, in the E-Mail and Text Messages (SMS) section, click Configure outgoing e-mail settings.

  4. On the Outgoing E-Mail Settings page, in the Mail Settings section, type the SMTP server information in the Outbound SMTP server box, and then specify the addresses and the character set that you want to use.

  5. Click OK.


Some health analyzer rules do not have associated timer jobs (SharePoint Foundation 2010)

Published: July 8, 2010

Rule Name: Some health analyzer rules do not have associated timer jobs

Summary: The timer jobs that run SharePoint Health Analyzer rules do not exist on this SharePoint Foundation 2010 deployment.

Cause: Some or all of the SharePoint Health Analyzer rules may not run if the health data collection timer jobs are not configured.

Resolution: Create the health data collection timer jobs

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration Home page, click Monitoring.

  3. On the Monitoring page, in the Health Analyzer section, click Review problems and solutions.

  4. On the Review problems and solutions page, click the alert for the failing rule, and then click Fix Now.

  5. After following the guidance given in the Remedy section, in the Review problems and solutions dialog box for the alert, click Reanalyze Now to confirm the resolution. If the problem is resolved, the rule is not flagged as a failing rule on the Review problems and solutions page.


Drives are running out of free space (SharePoint Foundation 2010)

Published: July 8, 2010

Rule Name: Drives are running out of free space

Summary: Disk drives on one or more of the servers in the farm are running out of disk space.

Note:

This rule checks disk space as a proportion of the RAM on the computer. When disk space is less than twice the RAM on the computer, the health rule triggers an error. When disk space is less than five times the RAM on the computer, the health rule triggers a warning. Accordingly, server computers with lots of RAM are more likely to experience a failure of this rule.

Resolution: Free disk space on the server computer

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer.

  2. Run the Disk Cleanup tool to free disk space on the server computer.

Resolution: Decrease the number of days to store log files

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration 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 Trace Log section, in the Number of days to store log files box, type a smaller number.

  5. Click OK.


The paging file size should exceed the amount of physical RAM in the system (SharePoint Foundation 2010)

Published: July 8, 2010

Rule Name: The paging file size should exceed the amount of physical RAM in the system

Summary: The paging file size on some servers in the SharePoint farm is smaller than the total physical memory that is available on the servers.

Cause: A Windows best practice is to set the paging file size to equal to or greater than the total amount of available physical memory. Garbage collection is typically more effective at automatic recovery of heap memory when managed heap size approximates paging file size. When paging file size is smaller than RAM size, new allocations of managed memory are granted, which leads to more garbage collection and higher CPU usage.

Resolution: Increase the minimum size of the paging file

  1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer.

  2. On the Server Manager page, click Change System Properties.

  3. In the System Properties dialog box, on the Advanced tab, in the Performance section, click Settings.

  4. In the Performance Options dialog box, on the Advanced tab, in the Virtual memory section, click Change.

  5. In the Virtual Memory dialog box, select the Automatically manage paging file size for all drives check box, or clear the check box and specify a paging file size that is equal to or greater than the physical memory that is available on the computer. We recommend that you either allow the system to manage the page file size or to set it at 150% of the size of the physical RAM.

  6. When you have made the changes that you want, click OK, and then restart the computer to apply the changes.


Built-in accounts are used as application pool or service identities (SharePoint Foundation 2010)

Published: July 8, 2010

Rule Name: Built-in accounts are used as application pool or service identities

Summary: Built-in or local computer accounts are used as an application pool identity or service identity.

Cause: Using built-in accounts as application pool identities or as service identities is not supported in a farm configuration. Built-in accounts include Network Service, Local Service, and Local System.

Resolution: Change the identity that is used for the service or application pool

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.

  2. On the Central Administration Home page, click Security.

  3. On the Security page, in the General Security section, click Configure service accounts.

  4. On the Service Accounts page, in the Credential Management section, in the upper drop-down list, click the service or application pool for which you want to change the identity.

  5. In the Select an account for this component list, click the domain user account that you want to associate with the service or application pool.

    If you want to register the account that you selected on the SharePoint Foundation 2010 farm, click Register Managed Account.

  6. Click OK.


Web Analytics: Monitors the health of the Report Consolidator component (SharePoint Foundation 2010)

Published: July 8, 2010

Rule Name: Web Analytics: Monitors the health of the Report Consolidator component

Summary: Typically, the Report Consolidator component should not take more than two hours to run. This rule is triggered if it takes longer than five hours.

Cause: The Report Consolidator component takes longer than five hours to run.

Resolution: Enable data trimming by using Windows PowerShell

  1. You can enable data trimming using the Set-WebAnalyticsServiceApplication cmdlet. When data trimming is enabled, the number of rows of data in the tables in the reporting database is trimmed to 20,000 rows per day per component (site, site collection, Web application, etc.). This decreases the time that the Reporting Component takes to run.

  2. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.

  3. On the Start menu, click All Programs.

  4. Click Microsoft SharePoint 2010 Products.

  5. Click SharePoint 2010 Management Shell.

  6. At the Windows PowerShell command prompt, type the following command:

    Copy Code
    Set-SPWebAnalyticsServiceApplication [-Identity <GUID>]-EnableDataTrimming

    Where:

    • <GUID> is GUID identifier of the Web Analytics service application. If you only have one Web Analytics service application, you do not need to specify the GUID.

For more information, see Set-SPWebAnalyticsServiceApplication.

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.


Web Analytics: Verifies that when the Web Analytics is installed and running, usage logging is enabled in the farm (SharePoint Foundation 2010)

Published: July 8, 2010

Rule Name: Web Analytics: Verifies that when the Web Analytics is installed and running, usage logging is enabled in the farm

Summary: The Web Analytics service application collects and reports on usage information such as page views, unique visitors, search queries issued, etc. If you require this service application, you must enable usage logging to ensure that logging of this data occurs.

Cause: Usage logging is not enabled for the Web Analytics service application.

Resolution: Enable usage logging for the Web Analytics service application

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

    Note:

    The usage and health data settings are farm-wide and cannot be set for individual servers in the farm.

  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, select the Enable usage data collection check box.

  5. In the Event Selection section, select the events that you want to log by selecting the check boxes next to the events in the Events to log list. Ensure that at least the following events are selected:

    1. Page Requests

    2. Search Query Usage

    3. Site Inventory Usage

    4. Rating Usage

  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 (from 1 through 20 GB) in the Maximum log file size box.

  8. Click OK to save the settings and enable usage logging.


Web Analytics: Verifies that a web application is serviced by at most one Web Analytics service application proxy (SharePoint Foundation 2010)

Published: July 8, 2010

Rule Name: Web Analytics: Verifies that a Web application is serviced by at most one Web Analytics service application proxy

Summary: When a Web application is associated with a Web Analytics service application, the Web Analytics service application logs and processes the usage data for that Web application. When a Web application is associated with multiple Web Analytics service applications, the Web Analytics service applications log and process the data for the Web application in an unpredictable way. We recommend that you use only one Web Analytics service application to log and process the data for the Web application.

Cause: Multiple Web Analytics service applications were created in the same farm and some Web applications were associated with more than one of those Web Analytics service applications.

Resolution: Disassociate other Web Analytics service applications

  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, under Application Management, click Manage Web applications.

  3. On the Web Applications page, click the Web application that is in the Health Analyzer alert, and then click Service Connections.

  4. In the Configure Service Application Associations dialog box, clear all but one of the Web Analytics service application check boxes.

    Note:

    If the check boxes are not available, do the following:

    1. Record the connections that are listed in the default view.

    2. Select [custom] from the Edit the following group of connections list box.

    3. Clear all but one of the Web Analytics service application check boxes, and ensure that you select all of the other service applications that were in the default view.

  5. Click OK.


Web Analytics: Verifies that the SQL Server Service Broker is enabled for the Web Analytics staging databases (SharePoint Foundation 2010)

Published: July 8, 2010

Rule Name: Web Analytics: Verifies that the SQL Server Service Broker is enabled for the Web Analytics staging databases

Summary: The service broker queue for the Web Analytics databases is not enabled. This causes Web Analytics data to not be processed.

Cause: This could be because of a recent SQL Server databases attach or detach or a backup or restore operation.

Resolution: Enable the service broker queue

  • In Central Administration, on the Review problems and solutions page, click the rule, and then click Repair Automatically.


One or more categories are configured with verbose trace logging setting

Published: May 26, 2011

Rule Name: One or more categories are configured with verbose trace logging

Summary: SharePoint Foundation writes diagnostic logging information to record activity on the server. The logs contain information that can help you diagnose server problems. This rule occurs when diagnostic logging is set to verbose. The verbose setting is appropriate when you have to diagnose a server problem, but you should turn off verbose logging during normal operations.

Cause: One or more categories of diagnostic logging are set to verbose.

Resolution: Reset diagnostic logging to the default level

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration Home page, click Monitoring.

  3. On the Monitoring page, in the Reporting section, click Configure diagnostic logging.

  4. In the Event Throttling section, in the Least critical event to report to the event log list and Least critical event to report to the trace log list, select Reset to default.

  5. Click OK.


Accounts used by application pools or service identities are in the local machine Administrators group (SharePoint Foundation 2010)

Published: August 11, 2011

Rule Name: Accounts used by application pools or service identities are in the local machine Administrators group.

Summary: A user account that is used by application pools or services must have permissions of a domain user account and must not be a member of the Farm Administrators group or a member of the Administrators group on the local computer. Using highly privileged accounts for application pools or services poses a security risk to the farm, and could allow malicious code to execute.

Cause: Accounts that are used by application pools or services are members of the Administrators group on the local computer.

Resolution: Change the user account to a predefined account, or to a domain user account that is not a member of the Administrators group.

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration home page, in the Security section, click Configure service accounts.

  3. On the Service Accounts page, in the Select the component to update list, click the application pool or service that uses the credentials of a member of the Administrators group on the local computer as its security account.

  4. In the Select an account list, click an appropriate account for this component — for example, the predefined account Network Service — or click Register new managed account, and then on the Register Managed Account page, specify the credentials and the password change settings that you want.

  5. Click OK.

For more information, see Initial deployment administrative and service accounts (SharePoint Foundation 2010).


Application pools recycle when memory limits are exceeded (SharePoint Foundation 2010)
See Also

Published: August 23, 2011

Rule Name: Application pools recycle when memory limits are exceeded.

Summary: Application pools recycle because memory limits have been enabled and exceeded. Recycling based on memory limits is not usually necessary in a 64-bit environment, and therefore recycling should not be enabled. Unnecessary recycling can result in dropped requests from the recycled worker process and slow performance for end users who are making requests to the new worker process.

Cause: Application pools are configured to recycle when memory limits are exceeded.

Resolution: Change the application pool recycling settings in Internet Information Services (IIS).

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. Identify the server on which this event occurs. On the Central Administration Web site, in the Monitoring section, click Review problems and solutions, and then find the name of the server in the Failing Servers column. If there are multiple failing servers in a server farm, you must repeat the following steps on each failing server.

  3. Verify that the user account that is performing the following steps is a member of the Administrators group on the local computer that you identified in the previous step.

  4. Log on to the server on which this event occurs.

  5. Click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager.

  6. In the Internet Information Services management console, in the Connections pane, expand the tree view, and then click Application Pools.

  7. In the Application Pools list, right-click the application pool on which you want to disable the memory limits, and then click Recycling.

  8. In the Edit Application Pool Recycling Settings dialog box, in the Memory Based Maximums section, clear the Virtual memory usage (in KB) and Private memory usage (in KB) check boxes, and then click Next.

  9. In the Recycling Events to Log dialog box, click Finish.

See Also

Other Resources

Configuring Recycling Settings for an Application Pool (IIS 7)


Alternate access URLs have not been configured (SharePoint Foundation 2010)

Published: September 7, 2011

Rule Name: Alternate access URLs have not been configured.

Summary: A default zone URL must not point to the computer name of a Web front-end server. Because this installation has more than one Web front-end server, an incorrectly configured default zone URL can result in a variety of errors, including incorrect links and failed operations.

Cause: A default zone URL is pointing to the computer name of a Web front-end server.

Resolution: Change the default zone URL to a URL that differs from the computer name of any Web front-end server.

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration home page, in the System Settings section, click Configure alternate access mappings.

  3. On the Alternate Access Mappings page, on the Alternate Access Mapping Collection menu, click Change Alternate Access Mapping Collection.

  4. In the Select An Alternate Access Mapping Collection dialog box, click the alternate access mapping collection for which you want to change the default zone URL.

  5. On the Alternate Access Mappings page, click Edit Public URLs.

  6. On the Edit Public Zone URLs page, in the Default text box, type a new default zone URL that differs from the computer name of any Web front-end server, and then click Save.


Product / patch installation or server upgrade required (SharePoint Foundation 2010)

Published: September 7, 2011

Rule Name: Product / patch installation or server upgrade required

Summary: You must install all required products on all servers in the farm, and all products should have the same software update and upgrade level across the farm.

Cause: You have not installed required products or updates, or the server needs to be upgraded.

Resolution: Install software updates and security updates or upgrade the server.

  • Check if there are any pending updates and restart all the servers.

    1. Log on to one server.

    2. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer.

    3. On the Start menu, click Control Panel, click System and Security, and then click Windows Update. If there are any pending updates or a restart is required, schedule the updates or restart the computer.

    4. Repeat the previous steps on all servers.

    For more information, see Deploy software updates for SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkID=99199).

  • If a previous upgrade attempt has failed, you must resolve upgrade issues before attempting upgrade again. You can use the Central Administration Web site to find information about current and previous upgrade attempts and determine issues that may be preventing upgrade from succeeding. To do this in Central Administration, in the Upgrade and Migration section, click Check upgrade status. For more information, see Upgrading to SharePoint Foundation 2010 (http://go.microsoft.com/fwlink/p/?LinkId=224172).


Web.config file has incorrect settings for the requestFiltering element (SharePoint Foundation 2010)

Published: September 7, 2011

Rule Name: Web.config file has incorrect settings for the requestFiltering element.

Summary: To support file names that contain the + character, the requestFiltering element in the Web.config file must have the allowDoubleEscaping attribute set to True and it must have a requestLimits element that has a maxAllowedContentLength value set to 2147483647 to avoid interfering with file upload.

Cause: The settings of the requestFiltering element in the Web.config file are incorrect.

Resolution: Change the requestFiltering settings in the Web.config file in Internet Information Services (IIS).

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. Identify the server on which this event occurs. On the Central Administration Web site, in the Monitoring section, click Review problems and solutions, and then find the name of the server in the Failing Servers column. If there are multiple failing servers in a server farm, you must repeat the following steps on each failing server.

  3. Verify that the user account that is performing the following steps is a member of the Administrators group on the local computer that you identified in the previous step.

  4. Log on to the server on which this event occurs.

  5. Click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager.

  6. In the Internet Information Services management console, in the Connections pane, expand the tree view of the server name, expand Sites, and then click the site for which you want to change the requestFiltering settings.

  7. On the site Home page, switch to Features View, and then in the Management section, double-click Configuration Editor.

  8. In the Section list, expand system.webServer, expand security, and then click requestFiltering.

  9. On the Configuration Editor page, ensure the following attributes or elements exist and are configured correctly:

    • The allowDoubleEscaping attribute is set to True.

    • The requestLimits element exists.

    • The requestLimits element has a maxAllowedContentLength attribute and its value is set to 2147483647.

    For more information, see How to: Add and Remove Web.config Settings Programmatically (http://go.microsoft.com/fwlink/p/?LinkId=227014).

  10. After you have made changes to these settings, in the Actions pane, click Apply.


Web.config files are not identical on all machines in the farm (SharePoint Foundation 2010)

Published: November 15, 2011

Rule Name: Web.config files are not identical on all machines in the farm.

Summary: If you have multiple front-end Web servers in the farm and have made manual changes to the Web.config files, you will experience a problem where a front-end Web server cannot read session state that was saved by another server in the farm.

Cause: The Web.config files on the front-end Web servers in the farm are not identical.

Resolution: Ensure that the Web.config files are identical on all front-end Web servers in the farm or ignore this alert if you have intentionally modified the Web.config file on a server.

  • Ignore this alert if you have intentionally modified the Web.config file on a server. Otherwise, perform the following steps:

    1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

    2. Identify the server on which this event occurs. On the Central Administration Web site, in the Monitoring section, click Review problems and solutions, and then find the name of the server in the Failing Servers column. If there are multiple failing servers in a server farm, you must repeat the following steps on each failing server.

    3. Verify that the user account that is performing the following steps is a member of the Administrators group on the local computer that you identified in the previous step.

    4. Log on to the server on which this event occurs.

    5. Typically the Web.config file is stored at C:\inetpub\wwwroot\wss\VirtualDirectories\Port_Number. Note the modified date of the Web.config file.

    6. Repeat the previous steps on other failing servers.

    7. Compare these Web.config files and decide which one is correct. To view the content of the Web.config file, do the following:

      1. Click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager.

      2. In the Internet Information Services management console, in the Connections pane, expand the tree view of the server name, expand Sites, and then click the site for which you want to view the settings of the Web.config file.

      3. On the site Home page, switch to the Features View, and then in the Management section, double-click Configuration Editor.

      4. In the Section list, select a section to view the settings of the Web.config file.

    8. Delete the incorrect Web.config file on each failing server, and then copy and paste the correct Web.config file.

For more information, see Working with Web.config Files (http://go.microsoft.com/fwlink/p/?LinkId=149266).

By default, the Repair Automatically option is enabled for this rule. You can restore the default setting for this rule by doing the following:

  1. On the Central Administration Web site, click Monitoring.

  2. On the Monitoring page, in the Health Analyzer section, click Review rule definitions.

  3. On the Health Analyzer Rule Definitions - All Rules page, in the Category: Configuration section, click the name of the rule.

  4. In the Health Analyzer Rule Definitions dialog box, click Edit Item.

  5. Select the Repair Automatically check box, and then click Save.


The timer service failed to recycle (SharePoint Foundation 2010)

Published: November 15, 2011

Rule Name: The timer service failed to recycle.

Summary: The last attempt to recycle the timer service failed. More than half of the attempts during the past week have also failed.

Cause: The Timer Service Recycle job conflicts with other long-running timer jobs.

Resolution: Change the schedule for the Timer Service Recycle job so that it does not conflict with other long-running timer jobs.

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration Home page, click Monitoring.

  3. On the Monitoring page, in the Timer Jobs section, click Review job definitions.

  4. On the Job Definitions page, click Timer Service Recycle.

  5. On the Edit Timer Job page, change the schedule so that it does not conflict with other long-running timer jobs, and then click OK.

For more information, see Timer job reference (SharePoint Foundation 2010).


The Application Discovery and Load Balancer Service is not running in this farm (SharePoint Foundation 2010)

Published: November 15, 2011

Rule Name: The Application Discovery and Load Balancer Service is not running in this farm.

Summary: The Application Discovery and Load Balancer service provides information about the topology of the farm to users who are using services offered by the farm. Users can use this information to perform load balancing. The Application Discovery and Load Balancer Service should be running on at least one server in the farm.

Cause: The Application Discovery and Load Balancer service is stopped.

Resolution: Start the Application Discovery and Load Balancer service on at least one server in the farm.

  1. Verify that you meet the following minimum requirements: You are a member of the SharePoint_Shell_Access role on the configuration database and a member of the WSS_ADMIN_WPG local group on the computer where SharePoint 2010 Products is installed.

  2. On the Start menu, click All Programs, click Microsoft SharePoint 2010 Products, and then click SharePoint 2010 Management Shell.

  3. At the Windows PowerShell command prompt, type the following command:

    Get-SPServiceInstance -ALL

    For more information, see Get-SPServiceInstance.

  4. Find the GUID of the Application Discovery and Load Balancer service.

  5. Type the following command:

    Start-SPServiceInstance [-Identity]

    Where [-Identity] is the GUID for the Application Discovery and Load Balancer service. For more information, see Start-SPServiceInstance.


Databases running in compatibility range, upgrade recommended (SharePoint Foundation 2010)
See Also

Published: November 15, 2011

Rule Name: Databases running in compatibility range, upgrade recommended.

Summary: The databases have versions that are earlier than the current SharePoint software, but are within the backward-compatible range. To achieve optimal results, upgrade the databases.

Cause: Versions of databases are earlier than the current SharePoint software.

Resolution: Upgrade databases to SQL Server 2008 R2.

  • See the following resource for information about how to upgrade databases: Upgrading to SQL Server 2008 R2.

See Also

Other Resources

Microsoft SQL Server 2008 R2 Enterprise Edition and Microsoft SharePoint Server 2010: Better Together


Databases require upgrade or not supported (SharePoint Foundation 2010)
See Also

Published: November 15, 2011

Rule Name: Databases require upgrade or not supported.

Summary: The databases require upgrade because their versions are earlier than the backward-compatible range, or the databases are not supported because their versions are later than the current version of Microsoft SharePoint Foundation 2010.

Cause: Versions of databases are earlier than the backward-compatible range, or are later than the current version of SharePoint Foundation 2010.

Resolution: Upgrade databases to SQL Server 2008 R2.

  • See the following resource for information about how to upgrade databases: Upgrading to SQL Server 2008 R2.

See Also

Other Resources

Microsoft SQL Server 2008 R2 Enterprise Edition and Microsoft SharePoint Server 2010: Better Together


Databases within this farm are set to read only and will fail to upgrade unless it is set to a read-write state (SharePoint Foundation 2010)

Published: November 15, 2011

Rule Name: Databases within this farm are set to read only and will fail to upgrade unless it is set to a read-write state

Summary: The databases are set to read-only and cannot be upgraded.

Cause: The databases are set to read-only.

Resolution: Set the databases to read-write.

  • See Content database is Read-Only - Event 4971 (SharePoint 2010 Products).


Drives used for SQL databases are running out of free space (SharePoint Foundation 2010)

Published: November 15, 2011

Rule Name: Drives used for SQL databases are running out of free space.

Summary: The databases have one or more files that exceed the available free disk drive space. If this happens, operations will fail. A disk drive should have enough free space to allow the largest database file to automatically grow to twice its size.

Cause: The databases have large files that may exceed the available free space.

Resolution: Free disk space on the database server computer.

  1. Verify that the user account that is performing the following step is a member of the Administrators group on the local database server computer.

  2. Click Start, click All Programs, click Accessories, click System Tools, and then click Disk Defragmenter.

  3. Run the Disk Defragmenter tool to free disk space on the server computer.

  4. If the event persists, move some large files to another disk drive to free up space.

Resolution: Decrease the number of days to store log files.

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration 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 Trace Log section, in the Number of days to store log files box, type a smaller number.

  5. Click OK.


Databases used by SharePoint have outdated index statistics (SharePoint Foundation 2010)
See Also

Published: November 15, 2011

Rule Name: Databases used by SharePoint have outdated index statistics.

Summary: Outdated index statistics can decrease query performance and cause Microsoft SharePoint Foundation 2010 to respond slowly.

Cause: Index statistics in SharePoint Foundation 2010 databases are out of date.

Resolution: Edit the rule definition so that the configuration is automatically repaired.

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration Home page, click Monitoring.

  3. On the Monitoring page, in the Health Analyzer section, click Review rule definitions.

  4. On the Health Analyzer Rule Definitions - All Rules page, in the Category: Configuration section, click the name of the rule.

  5. In the Health Analyzer Rule Definitions dialog box, click Edit Item.

  6. Select the Repair Automatically check box, and then click Save.

See Also

Other Resources

Index Statistics


Databases exist on servers running SharePoint Foundation (SharePoint Foundation 2010)

Published: November 15, 2011

Rule Name: Databases exist on servers running SharePoint Foundation.

Summary: For optimal performance, databases should not share servers with other applications.

Cause: Databases share servers with other applications.

Resolution: Move the databases to a dedicated server or ignore this alert if you are running a stand-alone server.

  • We strongly recommend that you always run the database on a dedicated server that is not running any other farm roles or hosting databases for any other application. The only exception is if you are running SharePoint Foundation 2010 on a stand-alone server.

    • For a stand-alone deployment, ignore this alert.

    • For a multiple sever deployment, move the databases to a dedicated server for optimal performance.

For more information, see Move content databases (SharePoint Foundation 2010) and Move all databases (SharePoint Foundation 2010).


Database has large amounts of unused space (SharePoint Foundation 2010)
See Also

Published: November 15, 2011

Rule Name: Database has large amounts of unused space.

Summary: The database has large amounts of unused space allocated on the disk. This database uses a large amount of space on the file system unless it is shrunk down to a small size. This event occurs if the unused space is more than 20% of the disk space and the unused space is greater than the auto-growth size plus 50 megabytes (MB).

Cause: Many activities can create unused space in the database. These activities include running the Windows PowerShell Move-SPSite command, and deleting documents, document libraries, lists, list items, and sites.

Resolution: Ignore this event, or shrink the database if you have to.

  • Normally you can safely ignore this event. You shrink a database only if it proves absolutely necessary — for example, when you have performed an operation that removes a very large quantity of data from a database, and the free space is not expected to be used again. You can shrink the database by using the DBCC ShrinkDatabase command or SQL Server Management Studio. For more information, see DBCC SHRINKDATABASE (Transact-SQL) (http://go.microsoft.com/fwlink/p/?LinkID=110852) and How to: Shrink a Database (SQL Server Management Studio) (http://go.microsoft.com/fwlink/p/?LinkID=224904).

    The white paper Database Maintenance for Microsoft SharePoint 2010 Products (http://go.microsoft.com/fwlink/p/?LinkID=229104) provides very important guidelines for shrinking a database. We strongly recommend that you read this white paper before you shrink a database.

See Also

Other Resources

Shrinking a Database


One or more servers is not responding (SharePoint Foundation 2010)

Published: November 15, 2011

Rule Name: One or more servers is not responding.

Summary: Microsoft SharePoint Foundation 2010 cannot detect one or more servers in the farm. These servers are managed by the farm, but do not respond.

Cause: The servers are not running, are disconnected from the network, or are physically removed from the farm.

Resolution: Ensure that the servers are running and connected to the network, restart the SharePoint 2010 Timer service (SPTimerV4), or remove the server record from the SharePoint topology.

  • Make sure that the servers are running and connected to the network. If not, start the servers and connect them to the network.

  • If the servers are running and connected to the network, make sure that the SharePoint 2010 Timer service is started on them. If not, start the service by following these steps:

    1. From the Explanation section of the event, identify the failing servers that do not respond.

    2. Log on to each failing server and perform steps 3 - 6 to start the SharePoint 2010 Timer service on the server.

    3. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer.

    4. On the Start menu, click Administrative Tools, and then click Services.

    5. In the Services list, make sure the status of SharePoint 2010 Timer is Started. If not, double-click SharePoint 2010 Timer.

    6. In the SharePoint 2010 Timer Properties (Local Computer) dialog box, click Start.

    Alternatively, you can start the SharePoint 2010 Timer service by doing the following on each server that does not respond:

    1. Verify that the user account that is performing this procedure is a member of the Administrators group on the local computer.

    2. Open the Command Prompt window, type the following command, and then press ENTER:

      net start SPTimerV4

    For more information about starting the SharePoint Timer service, see SharePoint Timer service could not start (SharePoint 2010 Products).

  • If the server was intentionally removed from the farm, follow these steps to remove the record of the server from the SharePoint topology in Central Administration:

    1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

    2. On the Central Administration Web site, in the System Settings section, click Manage servers in this farm.

    3. In the Server list, find the server that you want to remove, and then click Remove Server.

    4. In the warning message dialog box, click OK.


The local machine is not joined to a SharePoint server farm (SharePoint Foundation 2010)

Published: November 15, 2011

Rule Name: The local machine is not joined to a SharePoint server farm.

Summary: Even though the product binaries are installed, the SharePoint installation on this computer will not function until the computer has been added to a SharePoint server farm. This rule only appears on Windows PowerShell.

Cause: This local computer has not been added to a SharePoint server farm yet.

Resolution: Create a new farm or add this computer to an existing farm.

  • Run the Microsoft SharePoint Foundation 2010 Products Configuration Wizard and follow the prompts to create a new farm or to add this computer to an existing farm. For more information, see Add a Web or application server to the farm (SharePoint Foundation 2010) and the "Create and configure the farm" section in Multiple servers for a three-tier farm (SharePoint Foundation 2010).


The Security Token Service is not available (SharePoint Foundation 2010)

Published: November 15, 2011

Rule Name: The Security Token Service is not available.

Summary: The Security Token Service is not issuing tokens.

Cause: The service could be malfunctioning or in a bad state, or some assemblies are missing when you deploy the custom claims provider.

Resolution: Restart the Security Token Service application pool.

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. Identify the server on which this event occurs. On the Central Administration Home site, in the Monitoring section, click Review problems and solutions, and then find the name of the server in the Failing Servers column. If there are multiple failing servers in a server farm, you must repeat the following steps on each failing server.

  3. Verify that the user account that is performing the following steps is a member of the Administrators group on the local computer that you identified in the previous step.

  4. Log on to the server on which this event occurs.

  5. Click Start, click Administrative Tools, and then click Internet Information Services (IIS) Manager.

  6. In the Internet Information Services management console, in the Connections pane, expand the tree view, and then click Application Pools.

  7. In the Application Pools list, right-click SecurityTokenServiceApplicationPool, and then click Start. If the application pool is started already, click Stop and then, in the Action pane, click Start to restart it.

For more information, see Configure the security token service (SharePoint Foundation 2010) and Set-SPSecurityTokenServiceConfig.

Resolution: Install the missing assemblies into the global assembly cache manually.

  1. Check the event logs and ULS logs on all servers to find out which assemblies of the custom claims provider are missing.

  2. Install the missing assemblies into the global assembly cache manually. For more information, see How to: Install an Assembly into the Global Assembly Cache (http://go.microsoft.com/fwlink/p/?LinkId=169102).


Some content databases are growing too large (SharePoint Foundation 2010)

Published: December 6, 2011

Rule Name: Some content databases are growing too large

Summary: The content databases have grown larger than 100 gigabytes (GB). Large content databases can be difficult to back up and restore. They are also more likely to cause the application to stop responding when you perform operations that affect entire databases.

Cause: Content databases exceed 100 GB.

Resolution: Edit the rule definition to prevent new sites from being added to these databases, and then move some site collections to other databases.

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.

  2. On the Central Administration Home page, click Monitoring.

  3. On the Monitoring page, in the Health Analyzer section, click Review rule definitions.

  4. On the Health Analyzer Rule Definitions page, in the Availability category, click the name of the rule.

  5. In the Health Analyzer Rule Definitions dialog box, click Edit Item, and then select the Repair Automatically check box.

  6. Click Save. You can no longer add new sites to databases that exceed 100 GB.

  7. Move some site collections to smaller databases. For more information, see Move site collections between databases (SharePoint Foundation 2010).


Installation reference (SharePoint Foundation 2010)

Published: July 8, 2010

In this section:

  • Setup command-line reference (SharePoint Foundation 2010)

  • Config.xml reference (SharePoint Foundation 2010)

  • Psconfig command-line reference (SharePoint Foundation 2010)

  • Windows PowerShell commands (SharePoint Foundation 2010)

  • Scripted deployment reference (SharePoint Foundation 2010)


Setup command-line reference (SharePoint Foundation 2010)

Published: July 8, 2010

In SharePoint 2010 Products, the Setup command-line tool is used for very few operations, and most of these are for IT administrators only.

In this article:

  • How to use a Setup command-line switch

  • Available switches and parameters

How to use a Setup command-line switch

To run Setup from the command line, type a space after the command, followed by a forward slash (/) and the name of the switch, and sometimes followed by another space and one or more parameters. For example:

Copy Code
setup.exe /<switch> [parameter]

The parameters are specific instructions that give the program more information about how to execute the command. The table in the next section contains several examples of switches.

Available switches and parameters

In SharePoint 2010 Products, Setup recognizes the following command-line options.

Switch or parameter Description
Copy Code
/config [path and file name]

Specifies the configuration file that Setup uses during the installation. By default, the Config.xml file that is stored in the core product folder directs Setup to install that product. You can edit the Config.xml file to make additional customizations to the installation, or you can point to a different configuration file.

The product DVD contains examples of Config.xml files. The example files are stored in the Files folder at the root of the DVD, in folders that correspond to different scenarios. For example, the Files\SetupFarmSilent folder contains a Config.xml file for use in setting up a server farm in silent mode.

Use /config on the Setup command line to point to the location of the default Config.xml file for a particular product or to point to a custom configuration file.

Examples

To point to a customized Config.xml file:

\\<server>\<share>\setup.exe /config \\<server>\<share>\<folder>\config.xml

where <folder> is the folder that contains the Config.xml file.

Or, to point to a different configuration file:

\\<server>\<share>\setup.exe /config \\<server>\<share>\Files\SetupFarmSilent\config.xml

Copy Code
/modify [ProductID]

The /modify switch is used with a modified Config.xml file to run Setup in maintenance mode and make changes to an existing Office installation, such as adding or removing features.

Look up the value of [ProductID] in the Setup.xml file for the product that you want to modify. The Setup.xml file is located in the core product folder at the root of the network installation point or product DVD. For example, the Setup.xml file for SharePoint Foundation 2010 is located in the Wss.en-us folder.

In Setup.xml, [ProductID] is equal to the value of the Id attribute of the Setup element. For example:

- <Setup Id="Wss" Type="Product" ProductCode="{40120000-1110-0000-0000-0000000FF1CE}">

This switch cannot be used to change the configuration of the server (such as from a stand-alone configuration to a server farm configuration). To change the configuration, you must uninstall and reinstall.

Examples

\\<server>\<share>\setup.exe /modify wssmui.en.us /config \\<server>\<share>\<folder>config.xml

In this example, Setup at the root of the DVD is run in maintenance mode to modify SharePoint Foundation, as specified with the wss product ID. If a Config.xml file is not specified, Setup uses the Config.xml in the same folder as the Setup.exe file.

\\<server>\<share>\setup.exe /modify wss

/repair [ProductID]

Runs Setup to repair the files that are needed for the specified product. Running Setup in repair mode only affects the program files and does not repair your server configuration or any sites.

Look up the value of [ProductID] in the Setup.xml file for the product that you want to modify. The Setup.xml file is located in the core product folder at the root of the network installation point or product DVD. For example, the Setup.xml file for SharePoint Foundation 2010 is located in the Global folder at the root of the DVD.

Note:

You should also run the SharePoint Products Configuration Wizard after you run setup.exe /repair to complete the repair of the configuration. If you are using a stand-alone configuration, you can run psconfig.exe -setup from the command line to repair the configuration instead of using the wizard. If you are in a server farm configuration, you should use the full wizard interface. For more information, see the Help for the SharePoint Products Configuration Wizard.

Example

\\<server>\<share>\setup.exe /repair Wss

/uninstall [ProductID]

Removes the specified product from the user's computer. Look up the value of [ProductID] in the Setup.xml file for the product that you want to modify.

Look up the value of [ProductID] in the Setup.xml file for the product that you want to modify. The Setup.xml file is located in the core product folder at the root of the network installation point or product DVD. For example, the Setup.xml file for SharePoint Foundation 2010 is located in the Global folder at the root of the DVD.

Example

\\<server>\<share>\setup.exe /uninstall WSS

Run Setup with a Config.xml file at a command prompt

Running Setup with a configuration file lets you specify configuration choices (such as a data location or server role) during a quiet installation. For example, you can use the Config.xml file to:

  • Perform a silent installation.

  • Install by using a common configuration across multiple servers.

  • Perform an automated or scripted installation.

Use the following procedure to run Setup with a configuration file at a command prompt.

  1. On the drive that contains the product DVD, change to the root directory to locate the Setup.exe file.

  2. Run Setup with the selected Config.xml file.

    setup /config<path and file name>

    Note:

    You can select one of the example files that are included in the Microsoft SharePoint Foundation 2010 product DVD, or customize your own configuration file.

  3. Press ENTER.

For more information, see Install SharePoint Foundation 2010 by using Windows PowerShell.


Psconfig command-line reference (SharePoint Foundation 2010)

Published: July 8, 2010

In SharePoint 2010 Products, you can use the Psconfig command-line tool as an alternative interface to perform several operations that control how SharePoint 2010 Products are configured. You must be a member of the Administrators group on the local computer to perform these operations.

In this article

  • How to use Psconfig commands

  • Available commands and parameters

How to use Psconfig commands

When you run Psconfig at a command prompt, you can specify commands to control how the tool runs. To run Psconfig at a command prompt, navigate to the %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\14\bin folder, and then type the commands by using the following syntax:

Copy Code
psconfig.exe -cmd <command> [optional parameters]

The reference table in the next section contains several examples. Help is also available from the command-line interface. To view Help, at the command prompt, type:

Copy Code
psconfig.exe -?

To view Help about a specific command, type:

Copy Code
psconfig.exe -help <command name>

The commands in Psconfig must be run in a specific order to run successfully. If you use the SharePoint Products Configuration Wizard to configure an installation, it calls the commands (also known as configuration tasks) in the correct order for you. However, if you use the command line to run Psconfig, you must make sure that you are performing the tasks in the correct order. The Psconfig commands must be performed in the following order:

  1. configdb

  2. helpcollections

  3. secureresources

  4. services

  5. installfeatures

  6. adminvs

  7. evalprovision (only for stand-alone installations)

  8. applicationcontent

  9. upgrade

Important:

If Psconfig detects that the server farm has to be upgraded, it will automatically start an upgrade when you run it (even if you did not select the upgrade command).

You can specify all the commands to run in a single command-line string. If you do this, Psconfig runs all the commands in the correct order. For example, at the command prompt, you can run a command similar to the following:

Copy Code
psconfig.exe -cmd configdb <parameters>
-cmd helpcollections <parameters>
-cmd secureresources <parameters>
-cmd services <parameters>
-cmd installfeatures <parameters>
-cmd adminvs <parameters>
-cmd evalprovision <parameters>
-cmd applicationcontent <parameters>

For more information about how to configure a server or server farm from the command line, see the Microsoft SharePoint Foundation 2010 TechCenter.

Available commands and parameters

In the SharePoint Products Configuration Wizard, the following command-line options are recognized.

Command Description, parameters, and examples

?

Displays the commands available for use with Psconfig.

Example

Copy Code
psconfig.exe -?

help <command name>

Displays the commands available for use with Psconfig. If a command name is specified, displays help for that command.

Example

psconfig.exe -help adminvs

adminvs

Manages the SharePoint Central Administration Web application on the local computer. Takes the following optional parameters:

[-provision]

Provisions the SharePoint Central Administration Web application on this server. Provisioning creates a new SharePoint Central Administration Web application and an application pool running under the server farm administrator's account.

[-unprovision]

Unprovisions the SharePoint Central Administration Web application from this server. Unprovisioning removes the SharePoint Central Administration Web application and its application pool.

[-port <port number>]

The SharePoint Central Administration Web application port is a global setting to the server farm. When changing the port, a SharePoint Timer service job is dispatched to synchronize the port for all SharePoint Central Administration Web applications in the server farm. If a port is not specified, the port that is used for existing SharePoint Central Administration Web applications in the server farm is used. If a SharePoint Central Administration web Application has not been provisioned in the server farm, the default port selected will be random if a port is not specified.

[-windowsauthprovider <enablekerberos | onlyusentlm>]

The SharePoint Central Administration Web application authentication provider is a global setting to the server farm. When you change the authentication provider, a SharePoint Timer service job will be dispatched to synchronize the provider on all SharePoint Central Administration Web Applications in the server farm. If onlyusentlm is specified, NTLM will be the exclusive authentication provider for all SharePoint Central Administration Web applications. All other authentication providers are disabled and NTLM will be the only authentication provider allowed. If enablekerberos is specified, Kerberos authentication is enabled for all SharePoint Central Administration Web applications. If an authentication provider is not specified, the provider that is used for existing SharePoint Central Administration Web applications in the server farm will be used. If a SharePoint Central Administration Web application has not been provisioned in the server farm, the Kerberos authentication provider will be enabled if an authentication provider is not specified.

Examples

psconfig.exe -cmd adminvs -provision -port 8080 -windowsauthprovider onlyusentlm

psconfig.exe -cmd adminvs -unprovision

applicationcontent

Manages shared application content. Takes the following required parameter:

-install

Copies shared application data (for example, resource files and Web application binaries) to existing Web application virtual directories.

Example

psconfig.exe -cmd applicationcontent -install

configdb

Creates, connects, or disconnects this server from the server farm. Takes the following optional parameters:

[-create]

Creates a new configuration database and therefore establishes a new server farm. If this server is already connected to a configuration database, the server will be disconnected first, and then the new configuration database will be created.

[-disconnect]

Disconnects this server from the configuration database and therefore disconnects this server from the server farm.

[-connect]

Connects to an existing configuration database and therefore joins this server to an existing server farm. If this server is already connected to a configuration database, the server will be disconnected first, and then connected to the existing configuration database.

[-server <SQLServerName>]

The computer that is running Microsoft SQL Server where the configuration database is located.

[-database <SQLDatabaseName>]

The configuration database name.

[-dbuser <value>]

The user name that is used for SQL authentication.

[-dbpassword <value>]

The password that is used for SQL authentication.

[-user <Domain\User>]

The server farm administrator user account.

[-password <Password>]

The server farm administrator user account password.

[-addomain <value>]

The Active Directory domain name that is used for the server farm.

[-adorgunit <value>]

The Active Directory organization unit name that is used for the server farm.

[-admincontentdatabase <SQLAdminContentDatabaseName>]

The Central Administration Web application content database name.

Examples

psconfig.exe -cmd configdb -create -server <Server_name> -database <Database_name>

-dbuser <DOMAIN\username> -dbpassword <password>

-user <DOMAIN\username> -password <password>

-addomain <domain_name> -adorgunit <org_unit>

-admincontentdatabase <Database_name>

psconfig.exe -cmd configdb -disconnect

psconfig.exe -cmd configdb -connect -server <Server_name> -database <Database_name>

-dbuser <DOMAIN\username> -dbpassword <password>

evalprovision

Provisions this server as a stand-alone (evaluation mode) server. Takes the following required and optional parameters:

-provision

Performs stand-alone mode provisioning on this server.

[-port <port number>]

The port number assigned to the default SharePoint Web application. If not specified, port 80 is used. If a SharePoint Web application already exists and is using the port, the existing site will be overwritten. If an existing site is using the port and is not a SharePoint Web application, the site will be disabled and a new SharePoint Web application will be created that uses the port.

[-overwrite]

Specifies whether to overwrite any existing Microsoft SharePoint Foundation 2010 Web site during installation. If not specified, the site is not deleted.

Example

psconfig.exe -cmd evalprovision -provision -port 1100

helpcollections

Manages help collections. Takes the following required parameter:

-installall

Installs all available help collections.

Example

psconfig.exe -cmd helpcollections -installall

installfeatures

Registers any SharePoint Products and Technologies features located on the file system of this server with the server farm.

Example

psconfig.exe -cmd installfeatures

quiet

Runs the SharePoint Products Configuration Wizard in quiet mode. Output is written to the log file that is named PSCONFIG.EXE_MM_DD_YY_HH_MM_SS_MS.log, where "_MM_DD_YY_HH_MM_SS_MS" is the full date and time that the utility was run. The log file is stored in the %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\14\LOGS directory.

Example

psconfig.exe -cmd quiet

secureresources

Performs SharePoint 2010 Products resource security enforcement on the server. For example, security is enforced on files, folders, and registry keys.

Example

psconfig.exe -cmd secureresources

services

Manages SharePoint 2010 Products services. Takes the following optional parameters:

[-install]

Registers the services in the server farm that are located on this server.

[-provision]

Provisions the services that are located on this server and sets the services as online if SharePoint 2010 Products are installed in stand-alone mode. Provisioning services also ensures that they are registered.

Note:

The [-provision] parameter is supported only for a single server, stand-alone installation. Do not use this parameter for a farm installation.

Example

psconfig.exe -cmd services -install

psconfig.exe -cmd services -provision

setup

Performs configuration for SharePoint 2010 Products based on the installation mode. Also repairs the configuration. If the product is installed in stand-alone mode, stand-alone configuration is complete. If the product is not in stand-alone mode, you must complete the initial configuration by using the SharePoint Products Configuration Wizard instead of the Psconfig command-line tool. To run the wizard, on the Start menu, point to All Programs, point to Administrative Tools, and then click SharePoint Products Configuration Wizard.

If you want to repair a stand-alone installation, first run setup /repair (for more information, see the Setup Help system), and then psconfig.exe -setup. For server farm installations, after you run setup /repair, use the SharePoint Products Configuration Wizard instead of the Psconfig command-line tool.

Takes the following optional parameter:

[-lcid <1033>]

The locale ID (LCID) that specifies the installation language.

Example

psconfig.exe -cmd setup

standaloneconfig

Performs a stand-alone configuration for SharePoint Products and Technologies. Takes the following optional parameters:

[-lcid <1033>]

The locale ID (LCID) that specifies the installation language.

Example

psconfig.exe -cmd standaloneconfig

upgrade

Performs an upgrade of SharePoint 2010 Products. This command is automatically run when you run the SharePoint Products Configuration Wizard if the product has to be upgraded. Takes the following optional parameters:

[-wait]

If specified, the SharePoint Products Configuration Wizard does not return until the upgrade is complete. If not specified, the wizard returns after dispatching a SharePoint Timer Service job to perform the upgrade. To view the upgrade job status, you can access the SharePoint Central Administration Web site by using your Web browser.

[-force]

If specified, the SharePoint Products Configuration Wizard stops any currently running upgrade actions, and then restarts upgrade.

[-reghostonupgrade]

If specified, the SharePoint Products Configuration Wizard will reset all content to the site definition version during the upgrade.

[-inplace <v2v|b2b>]

If specified, the SharePoint Products Configuration Wizard will perform an in-place upgrade. If v2v is specified, an in-place version to version upgrade is performed. If b2b is specified, an in-place build to build upgrade is performed.

[-preserveolduserexperience]

If set to false, the SharePoint Products Configuration Wizard will update sites to use the latest SharePoint user experience. If you do not specify this parameter, the default is true.

[-passphrase]

Passphrase used to join the server farm. The Passphrase value must be the same on all servers in the farm if the farm is to function correctly.

Example

Copy Code
psconfig.exe -cmd upgrade -inplace v2v -wait


Config.xml reference (SharePoint Foundation 2010)

Published: July 8, 2010

When you want to control how Microsoft SharePoint Foundation 2010 is installed, use the Config.xml file and the Setup command-line tool. For example, you can use the Config.xml file to do the following:

  • Perform a silent installation of SharePoint Foundation 2010.

  • Install SharePoint Foundation 2010 by using a common configuration across multiple servers.

  • Perform an automated or scripted installation of SharePoint Foundation 2010.

In this article:

  • Customizing Config.xml

  • Config.xml element quick reference

  • How it works

  • Config.xml file format

  • Config.xml element reference

Customizing Config.xml

To control the installation, first edit the Config.xml file in a text editor to include the elements that you need with the appropriate settings for those elements. Then run setup.exe /config [path and file name] to specify that Setup will run and use the options that you set in the Config.xml file.

Important:

Use a text editor, such as Notepad, to edit Config.xml. Do not use a general-purpose XML editor such as Microsoft Office Word 2007.

The product DVD contains examples of Config.xml files. The example files are stored in the Files folder at the root of the DVD, in folders that correspond to different scenarios. The folders are as follows:

  • Setup Contains a Config.xml file for use in setting up a clean installation. You must run the Psconfig command-line tool after you run Setup to finish configuring the server or server farm.

  • SetupFarmSilent Contains a Config.xml file for use in setting up a server farm in silent mode.

  • SetupSilent Contains a Config.xml file for use in setting up a clean installation for a single server (stand-alone, with Windows Internal Database) in silent mode.

  • SetupUpgradeSilent Contains a Config.xml file for use in upgrading an existing server farm in place.

For more information about the differences among the various upgrade scenarios, see Determine upgrade approach (SharePoint Foundation 2010).

Config.xml element quick reference

The following table contains a list of the elements in Config.xml. These elements can appear in any order, except for Configuration Element, which must be first, and elements such as Command Element, whose order in Config.xml affects how they are processed during installation.

Element | Description
Configuration Element | Top-level element.
ARP Element | Values that control the text and behavior of Add or Remove Programs in Control Panel for the product.
Command Element | Runs a command during installation.
Display Element | The level of UI that Setup displays to the user.
Logging Element | Options for the type of logging that Setup performs.
DATADIR Element | The location to use to store the data files.
Package Element | The package or product to install.
Setting Element | Values for Windows Installer properties.

How it works

Setup looks for a copy of Config.xml in the same folder as Setup.exe. If a copy is not found there, Setup uses the Config.xml file that resides in the core Files folder for the product that you are installing.

You can also use the /config Setup command-line option to specify the location of the Config.xml file. For example:

\\<server>\<share>\setup.exe /config \\<server>\<share>\<folder>\config.xml

Config.xml file format

XML elements in Config.xml begin with an angle bracket (<) and end with a forward slash and an angle bracket (/>).

The basic element format is as follows:

<element_name [attribute_name="value"] [attribute_name="value"] … />

For example:

Copy Code
<Display Level="none" CompletionNotice="no" />

Elements and attributes are case-sensitive. Attribute values must be enclosed in quotation marks (") and are not case-sensitive.

An element definition can span multiple lines. Spaces, carriage returns, line feeds, and tab characters are ignored within an element definition.

For example:

Copy Code
<Display
   Level="none"
   CompletionNotice="no"
/>
Tip:

For long element definitions, put attributes on separate lines and use indentation to make the file easier to read.

The Configuration Element element is a special case and is required. All other elements are contained within the Configuration Element element, and the element is closed with </Configuration>.

The following example shows a configuration file for a clean installation of the Microsoft SharePoint Foundation 2010 package:

<Configuration>

   <Package Id="sts">

      <Setting Id="SETUPTYPE" Value="CLEAN_INSTALL"/>

   </Package>

   <DATADIR Value="%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\14\Data"/>

   <Logging Type="verbose" Path="%temp%" Template="Microsoft SharePoint Foundation 2010 Setup *.log"/>

   <Setting Id="UsingUIInstallMode" Value="1"/>

   <Setting Id="SETUP_REBOOT" Value="Never"/>

</Configuration>

Comments can be added anywhere and are delimited by an angle bracket, exclamation point, and two hyphens (<!--) and two hyphens and an angle bracket (-->).

For example:

<!-- Install Microsoft SharePoint Server for clean install, using UI-->

<Configuration>

   <Package Id="sts">

      <Setting Id="LAUNCHEDFROMSETUPSTS" Value="Yes"/>

   </Package>

   <Package Id="spswfe">

      <Setting Id="SETUPCALLED" Value="1"/>

   </Package>

   <Logging Type="verbose" Path="%temp%" Template="SharePoint Server Setup(*).log"/>

      <!--<PIDKEY Value="Enter Product Key Here" />-->

      <Setting Id="SERVERROLE" Value="SINGLESERVER"/>

      <Setting Id="USINGUIINSTALLMODE" Value="1"/>

      <Setting Id="SETUPTYPE" Value="CLEAN_INSTALL"/>

      <Setting Id="SETUP_REBOOT" Value="Never"/>

   <!-- Tells Setup.exe not to reboot -->

</Configuration>

Config.xml element reference

The following conventions are used in the descriptions in this reference:

bold | Element or attribute name
regular | Text to be entered exactly as shown
italic | Placeholder for a value to be added
x|y | Choose between multiple values
[x] | Optional value

Configuration Element

Top-level element. This element is required, and all other elements must appear within this element.

Syntax

<Configuration>

<Package Id="ID">

...

</Package>

...

</Configuration>

Attributes

Attribute | Value | Description
Package ID | Package ID | The package that is being installed.

Remarks

The Package Id attribute identifies the product and technologies that are affected by this Config.xml file.

Example

The Package ID for SharePoint Foundation 2010 is sts. Use the sts Package ID in Config.xml to specify SharePoint Foundation 2010 by entering the following:

Copy Code
<Configuration>
   <Package Id="sts">
   ...
   </Package>
   ...
</Configuration>

ARP Element

Specifies values that control the text and behavior of Add or Remove Programs in Control Panel for the product.

Syntax

<ARP attribute="value" [attribute="value"] ... />

Attributes

Attribute | Value | Description
ARPCOMMENTS | text | Additional text; can be up to 255 characters, although all characters might not display.
ARPCONTACT | text | List of technical support contacts.
ARPNOMODIFY | Yes | Prevents users from modifying the product installation by making the Change button unavailable.
 | No (default) | Allows users to modify the product installation.
ARPNOREMOVE | Yes | Prevents users from removing the product by making the Remove button unavailable.
 | No (default) | Allows users to remove the product.
ARPURLINFOABOUT | URL | URL for the product's home page.
ARPURLUPDATEINFO | URL | URL for information about product updates.
ARPHELPLINK | URL | URL of a Web site from which users can receive technical support.
ARPHELPTELEPHONE | text | Phone numbers for technical support.

Command Element

Specifies a command line to run. The Command element commands are processed only during initial installations and uninstallations. If Command element commands are used for customizations after the initial installation, they are ignored.

Syntax

<Command

Path="path"

[QuietArg="arguments"]

[Args="args"]

[ChainPosition="Before" | "After"(default)]

[Wait="mseconds"]

[Execute="Install"(default) | "Uninstall"]

[Platform="x86"(default) | "x64"]

/>

Attributes

You can specify double-quotation marks (") in the Path and Args attributes by specifying two double-quotation marks together ("").

Attribute | Value | Description
Path | path | Fully qualified path of the executable Windows Installer package.
QuietArg | string | String of arguments to be appended to the command line when Display Element Level=None.
Args | string | String of arguments to be passed to the executable.
ChainPosition | Before | This command is executed before the primary product installation.
 | After (default) | This command is executed after the primary product installation.
Wait | mseconds | When you install with the Display Element Level attribute set to Full or Basic, this is the number of milliseconds to wait after you run the program before you continue the installation. The default is 0 (zero), which indicates no waiting.
Execute | Install (default) | Setup executes this command when the primary product is installed.
 | Uninstall | Setup executes this command when the primary product is uninstalled.
Platform | x86 (default) | Specifies that this program requires the Intel x86 platform. This command runs only if the computer on which the installation is run matches this platform requirement.
 | x64 | Specifies that this program requires a 64-bit processor that supports the x64 extensions to the x86 architecture. This command runs only if the computer on which the installation is run matches this platform requirement.

Remarks

The Command element in the Config.xml file is intended to be used only for initial product installations and uninstallations. The Command element commands are processed only during initial installations and uninstallations. If Command element commands are used for customizations after the initial installation, they are ignored.

The command line can be specified to run an arbitrary command or to run a lightweight executable that you want to run when this product is installed.

The Command element in Config.xml does not provide the software deployment capabilities that an enterprise software deployment and management tool provides, such as the ability to track deployment progress and troubleshoot problems. Therefore, we recommend that you limit the use of the Command element in Config.xml to run only a lightweight executable program or arbitrary command that will not make changes to the computer or that does not require user input. For example, you can run a utility to copy logs or a command to launch a Welcome page at the end of installation.

The command line can be specified for a chained installation or an executable that runs when this product is installed. If this is specified, you must specify a command line for Setup instead of a single .msi file.

If there are two or more Command elements in the Config.xml file, they will run in the order in which they are specified in Config.xml.

Important:

Chaining is not as reliable as installing each product separately. For example, if you chain two installations together and one of the products fails or encounters an unexpected error, the primary installation and the chained installation might not be completed successfully. Therefore, we do not recommend that you use the chaining approach. The recommended method for installing multiple products together in enterprise environments is to use a deployment management program, such as Microsoft System Center Configuration Manager 2007 or Microsoft Systems Management Server (SMS) 2003, or a third-party tool, instead of chaining.

The use of Args and QuietArg is as follows:

  • The Args attribute is always appended to the command. This can include switches such as /install or Company=MyCorporation.

  • The QuietArg attribute is also appended if Setup is running silently (with Display set as Display="none"). In such cases, you can specify the QuietArg attribute with the "/quiet" switch. For example, you can use: QuietArg="/quiet".

  • If the value of the Args element includes quotation marks, you can enclose the complete value in single (') quotation marks as shown in the following example:Args='"/param value"'

The following statements apply to the Wait attribute:

  • Setting the Wait attribute to 0 milliseconds indicates no waiting after you run the program before you continue the installation. The command will execute and move on immediately.

    Return codes are only respected if the Wait value is nonzero. If you specify 0, Setup will not wait to continue the installation after it runs the specified program. Therefore, there is no return code to report in that case.

  • Setting the Wait attribute to any positive nonzero value will wait exactly the number of milliseconds you specify. If the process ends earlier than the specified time, Setup will continue. If the process has not ended when the specified time is up, Setup will fail.

  • Setting the Wait attribute to -1 indicates to wait indefinitely. This can be problematic because if the command process stops responding (hangs), Setup will stop responding and will wait indefinitely for the command to run.

Example

<Command Path="\\server\share\myscript.exe" Args='/id "123 abc"' QuietArg="/q" Wait="3000">

<Command Path="\\<server>\<share>\setup.exe /config \\<server>\<share>\<folder>\config.xml"

DATADIR Element

The location to use to store the data files, including the search index files.

Syntax

<DATADIR Value="path"/>

Attributes

Attribute | Value | Description
Value | path | Setup stores the data files in the location that is specified.

Remarks

You can use system environment variables in the path. If this element is not specified, the data is stored in the following path:

%ProgramFiles%\Microsoft SQL Server\MSSQL$SHAREPOINT\Data

Example

Copy Code
<DATADIR Value="d:\data"/>

Display Element

The level of UI that Setup displays to the user.

Syntax

<Display

Level="None" | "Basic" | "Full"(default)

CompletionNotice="Yes"(default) | "No"

SuppressModal="Yes" | "No"(default)

NoCancel="Yes" | "No"(default)

AcceptEula="Yes" | "No"(default)

/>

Attributes

Attribute | Value | Description
Level | None | No Setup UI is displayed.
 | Basic | Setup displays the Welcome screen, the Microsoft Software License Terms page (if it is needed), a progress bar, and the completion notice (if it is allowed).
 | Full (default) | Setup displays all UI to the user.
CompletionNotice | Yes | Only applies if Level is set to Basic or None. Setup displays the completion notice.
 | No (default) | Only applies if Level is set to Basic. Setup does not display the completion notice.
SuppressModal | Yes | Only applies if Level is set to Basic. Setup does not display error messages and other dialog boxes that might interrupt the installation.
 | No (default) | Only applies if Level is set to Basic. Setup displays errors and other dialog boxes as needed.
NoCancel | Yes | If Level is set to Full or Basic, disables the cancel button (X in the upper-right corner of the progress dialog box).
 | No (default) | If Level is set to Full or Basic, allows the user to cancel the installation from the progress bar.
AcceptEULA | Yes | The Microsoft Software License Terms are accepted on behalf of the user. Setup does not display the Microsoft Software License Terms page.
 | No (default) | If Level is not set to None, Setup displays the Microsoft Software License Terms page.

Remarks

If this element is not defined, the default settings are used. If an invalid value is specified, Setup ends the installation.

Note:

The Display element is used by Setup only if Setup finds the Config.xml file in the same folder as Setup.exe, or if you specify the Config.xml file by using the Setup /config command-line option.

Example

Copy Code
<Display Level="basic"
   CompletionNotice="yes"
   SupressModal="no"
   AcceptEula="yes"
/>

Logging Element

Specifies the type of logging that Setup performs.

Syntax

<Logging

Type="Off" | "Standard"(default) | "Verbose"

Path="path"

Template="filename.txt"

/>

Attributes

Attribute | Value | Description
Type | Off | Setup does no logging.
 | Standard (default) | Setup writes installation information to the log file.
 | Verbose | Setup writes all installation information to the log file.
Path | Path | The fully qualified path of the folder used for the log file. You can use environment variables. The default is %temp%.
Template | filename.txt | The name of the log file. If you insert the string * anywhere in the file name, a unique log file is created for each installation that is performed by Setup (see the explanation that follows). If * is not included and the file name that is specified already exists, log information is appended to the existing file. The .txt file name extension must be included. The default template is SetupExe(*).log.

Remarks

You can specify a * anywhere in the Template value. Setup inserts a string in that location that has the following format:

YYYYMMDDHHMMSSxxx

where:

  1. YYYY = Year

  2. MM = Month

  3. DD = Day

  4. HH = Hour

  5. MM = Minutes

  6. SS = Seconds

  7. xxx = a unique string generated by Setup

Note:

The Logging element is used by Setup only if you specify the Config.xml file by using the Setup /config command-line option. If you do not specify a Config.xml file to use, then Setup uses the default logging options.

Example

Copy Code
<Logging Type="standard" Path="%temp%"
   Template="MyLog(*).txt"
/>

With this example, Setup creates a log file every time that it installs the product. Setup uses unique file names such as the following:

Copy Code
%temp%\MyLog(20060428110717CFC).txt
%temp%\MyLog(20060429113143C70).txt

Package Element

The package or product to install.

The Package ID for SharePoint Foundation 2010 is sts.

Setting Element

Allows you to specify values for Windows Installer properties.

Syntax

<Setting Id="name" Value="value" />

Attributes

Attribute | Value | Description
Id | name | The name of the Windows Installer property.
Value | value | The value to assign to the property.

Values

The following Setting IDs are used for server installations:

ID | Accepted values | Description
REBOOT | ReallySuppress | Specifies (for Windows Installer) whether to allow a reboot after Setup is completed. Use ReallySuppress to specify no reboot. Must be specified at the global level, not per package.
SETUP_REBOOT | Never, AutoAlways, Always, AutoIfNeeded, IfNeeded | Specifies (for Setup) whether to allow a reboot after Setup is completed. Use Never to specify no reboot. Must be specified at the global level, not per package.
SETUPTYPE | CLEAN_INSTALL, V2V_INPLACE_UPGRADE | Specifies whether to install a new copy of the product or technology (CLEAN_INSTALL), install the new version and upgrade the previous version in place (V2V_INPLACE_UPGRADE). Must be specified at the global level, not per package.
SETUPCALLED | 0 | 1 | Use as part of the Package Id attribute.
SERVERROLE | SINGLESERVER, APPLICATION | Specifies the type of server that you are installing to: stand-alone (SINGLESERVER) or application (APPLICATION).
USINGUIINSTALLMODE | 0 | 1 | Specifies whether you are performing a silent installation (0) or using the user interface for Setup (1).

Remarks

Not all Windows Installer properties can be specified in the Setting element. If a blocked property is specified, Setup ends the installation process. If a supported property is specified, Setup passes the property directly to Windows Installer.

Example

Copy Code
<Setting Id="REBOOT" Value="ReallySuppress" />


Windows PowerShell commands (SharePoint Foundation 2010)
See Also

Published: July 8, 2010

This article discusses the Windows PowerShell cmdlets that are needed to install Microsoft SharePoint Foundation 2010 on a stand-alone server or on a server farm.

In this article:

  • Installing SharePoint Products by using Windows PowerShell

  • Windows PowerShell installation cmdlets

For information about the commands and syntax that are used in scripted deployment of a SharePoint Foundation 2010 farm, see Scripted deployment reference (SharePoint Foundation 2010).

Installing SharePoint Products by using Windows PowerShell

In SharePoint Foundation 2010, you can use Windows PowerShell cmdlets as an alternative interface to perform several operations that control how the SharePoint products are configured. Additionally, you can streamline deployment by using command-line installations in combination with other administrator tools to automate unattended installations.

You can run the Windows PowerShell cmdlets in the SharePoint 2010 Management Shell, or you can add the snap-in that contains the cmdlets. By using a management shell, you can eliminate the step to register the snap-in that contains the cmdlets by using the Add-PSSnapin cmdlet. For more information about how to use Windows PowerShell with Microsoft SharePoint 2010 Products, see SharePoint 2010 Products administration by using Windows PowerShell.

To use the cmdlets, verify that you meet the following minimum requirements: See Add-SPShellAdmin. For information about how to add a user to the SharePoint_Shell_Access role for the specified database, see Add-SPShellAdmin.

Note:

When you create a new farm or join a server to a farm for the first time, ignore the following error message that appears: "The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered."

The cmdlets must be run in a specific order to run successfully. If you use SharePoint Products Configuration Wizard to configure the installation, it calls the commands (also known as configuration tasks) in the correct order for you. However, if you use cmdlets, you must ensure that you are performing the tasks in the correct order. The Windows PowerShell cmdlets must be performed in the following order:

  1. New-SPConfigurationDatabase

  2. Install-SPHelpCollection

  3. Initialize-SPResourceSecurity

  4. Install-SPService

  5. Install-SPFeature

  6. New-SPCentralAdministration

  7. Install-SPApplicationContent

Note:

Use a fresh Windows PowerShell process to perform operations on a new farm. For example, when you add a server to a new farm that was in a different farm, restart the Windows PowerShell process before you add the server to the new farm.

Windows PowerShell installation cmdlets

You can use the following Windows PowerShell cmdlets to install and configure SharePoint Foundation 2010.

Windows PowerShell cmdlet | Description
New-SPConfigurationDatabase | Creates a new configuration database on the specified database server. This is the central database for a new SharePoint farm. This command also creates the administration content database.
Install-SPHelpCollection | Installs the Help site collection files for SharePoint 2010 Products in the current farm. You must specify the All parameter to install all Help Collection CABs under %Program Files%\Common Files\Microsoft Shared\Web Server Extensions\14\HCCab\<LCID> in the Help site collection.
Initialize-SPResourceSecurity | Enforces resource security on the local server. This cmdlet enforces security for all resources, including files, folders, and registry keys.
Install-SPService | Installs and optionally provisions services on a farm. This cmdlet installs all services, service instances, and service proxies that are specified in the registry on the local server computer.
Install-SPFeature | Installs a specific SharePoint feature by using the Feature.xml file. When you create a new farm, you must specify the AllExistingFeatures parameter to install all available features.
New-SPCentralAdministration | Creates a new Central Administration Web application and starts the central administration service on the local computer. Central Administration is available only on computers where this service runs.
Install-SPApplicationContent | Copies shared application data to existing Web application folders.

See Also

Concepts

SharePoint 2010 Products administration by using Windows PowerShell


Installation and other special directories (SharePoint Foundation 2010)

Published: August 5, 2010

In this article:

  • Installation directory files

  • Web Part resource files

  • Web site content files

This article lists the folders and files that are used by Microsoft SharePoint Foundation 2010.

Installation directory files

The following table lists the files and folders that are created in the installation directory (%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14) when you install SharePoint Foundation 2010.

Folder Description Files and purpose

AdmIsapi

The physical directory that hosts the SharePoint Central Administration Web site-specific Web services for the _vti_adm virtual directory within Central Administration.

  • Admin.asmx - Web service for Central Administration-specific Web service methods. Accessed by http://server_name:<admin port>/_vti_adm/admin.asmx.

  • AdminDisco.aspx - Web service discovery file that is used for the admin.asmx Web service. Accessed by http://server_name:<admin port>/_vti_adm/admin.asmx?disco.

  • AdminWsdl.aspx - Web Services Description Language file that is used to specify the methods and parameters that are provided by the Admin.asmx Web service. Accessed by http://server_name:<admin port>/_vti_adm/admin.asmx?wsdl.

  • Web.config - Configuration file for Central Administration

Bin

Contains the core binary files for SharePoint Foundation 2010.

  • *.dll - Core binary files

  • Owstimer.exe - Microsoft SharePoint Timer service

  • Stsadm.exe - SharePoint Foundation command-line administration tool

  • Wssadmin - SharePoint Foundation Administration Service

  • Stscfg.exe - Configuration utility that is used by Setup

  • Mssearch.exe - Search processes

  • Wsstracing.exe - Logs events to the SharePoint diagnostic trace log file

  • Psconfig.exe - SharePoint Products Configuration Wizard

  • Spwriter.exe - SharePoint Foundation VSS Writer

Bin\LCID\

Contains the core binary files that were used by specific languages. LCID is replaced by the locale ID. For example, 3082 is the locale ID for Spanish. Therefore, the path for Spanish language binary files is \Bin\3082.

  • Fpext.msg - Error messages and text strings

  • Microsoft.Sharepoint.Msg.dll - Microsoft SharePoint Foundation Event messages

  • Microsoft.Sharepoint.Perfmonmsg.dll

  • Mssmsg.dll - Microsoft search component

  • WssSmanifest.man

Config

Contains configuration files and default values for the server.

  • *.xml - XML file to map default values

  • AppwpresWeb.config - Configuration file

  • AdminWeb.config - Configuration file for the Central Administration Web site

  • LayoutsWeb.config - Configuration file for the _layouts directory

  • Web.config - Configuration file for Web applications

  • Wss_mediumtrust.config - Configuration file

  • Wss_minimaltrust.config - Configuration file

  • Wss_usercode.config

Config\Adminbin

Contains the core binary files.

*.dll

Config\AdminResources

Contains Central Administration resources.

*.resx

Config\Bin

Contains binary files for the _vti/_bin virtual directory.

Stssoap.dll - Binary file that is used for SOAP code

Microsoft.SharePoint.Applicationpages.dll - Core binary file

Config\Browsers

Contains the configuration file for support of mobile access to list data.

Compat.browser

Config\IdentityModel

Contains configuration files for custom claims.

Webconfig.Identitymodel.Add.xml

Webconfig.Identitymodel.Remove.xml

Config\Powershell\Format

Contains files that define the default display of objects in the Windows PowerShell console.

SharepointPowershell.Format.ps1xml

WssSearchPowershell.Format.ps1xml

Config\Powershell\Help

Information about Windows PowerShell cmdlets for SharePoint 2010 Products.

Microsoft.Sharepoint.Powershell.dll-help.xml

Microsoft.Sharepoint.Search.dll-help.xml

Config\Powershell\Help\UILanguage

The default system language in which to display Help for Windows PowerShell cmdlets.

Microsoft.SharePoint.Powershell.dll-help.xml

Microsoft.SharePoint.Search.dll-help.xml

Microsoft.SharePoint.TopologyService-help.xml

Config\Powershell\Registration

Contains code for the cmdlets and the XML files that register the cmdlets.

Psconsole.psc1

SharePoint.ps1

SPCmdletSchema.xsd

WssCmdlet.xml

WssSearchCmdlets.xml

Config\Powershell\Types

Contains XML-based text files that let you add properties and methods to the objects that are used in Windows PowerShell.

SharepointPowershell.Types.ps1xml

WssSearchPowerShell.Types.ps1xml

Config\Resources

Contains resources for localization.

*.resx

Config\Upgrade

Contains XML files that are used in the upgrade process.

GbwUpgrade.xml

GbwUpgradeB2B.xml

MpsUpgrade.xml

MpsUpgradeB2B.xml

WssUpgrade.xml

WssUpgradeB2B.xml

WssSearchUpgrade.xml

Data

Contains SharePoint Foundation Search index files.

HCCab\LCID

Contains Help files and support files. LCID is replaced by the locale ID. For example, 3082 is the locale ID for Spanish.

*.cab

Help\LCID

Contains the .chm Help file for the SharePoint Products Configuration Wizard. LCID is replaced by the locale ID. For example, 3082 is the locale ID for Spanish.

*.chm

Isapi

The physical directory that is addressed by the _vti/_bin virtual directory.

Contains FrontPage Server Extensions RPC interfaces (Shtml.dll, _vti_aut\Author.dll, _vti_adm\Admin.dll) and Microsoft SharePoint Foundation RPC interfaces (Owssvr.dll).

  • *.asmx - Web services

  • Authentication.asmx - Web service for SharePoint Authentication Web service methods

  • AuthenticationDisco.aspx - Web service discovery file that is used for the Authentication.asmx Web service

  • AuthenticationWsdl.aspx - Web services description language file that is used to specify the methods and parameters that are provided by the Authentication.asmx Web service

  • *.xml - XML file for managed code

  • Web.config - Configuration file

Isapi\_Vti_Adm

Contains FrontPage Server Extensions RPC interfaces.

Admin.dll - RPC interface for remote administration for FrontPage Server Extensions and other Microsoft Office client applications and other client applications that implement this protocol.

Isapi\_Vti_Aut

Contains FrontPage binary files.

Author.dll - RPC interface for remote authoring for FrontPage Server Extensions and other Office client applications and other client applications that implement this protocol.

Isapi\Anonsvc

Contains a configuration file that is used for anonymous authentication.

Web.config

Isapi\Sts

Contains files that are used by SharePoint Server 2010 security token service.

Spsecuritytokenservice.svc

Web.config

Logs

Contains the log files.

Policy

Contains files that are used for information management policy.

*.dll

*.config

Resources

Contains the resource files.

*.resx

Template

Contains templates, features, and core Web site files.

Template\LCIDSts

Contains files that are copied to the root of the Web site upon instantiation with the Team Site template (for example, Default.aspx). LCID is replaced by the locale ID. For example, the path for Spanish is Template\3082\Sts.

This folder contains only the DocTemp folder.

Template\LCID\Sts\Doctemp\Blankpgs

Contains the default document templates.

Bpstd.aspx

_Basicpage.htm

Template\LCID\Sts\Doctemp\Dcl

Contains document templates for the Data Connection Library.

Template.odc

Template\LCID\Sts\Doctemp\Fp

Contains document templates for FrontPage and SharePoint Designer.

Fptmpl.htm - Default document templates for FrontPage and SharePoint Designer documents

Template\LCID\Sts\Doctemp\Onenote

Contains document templates for Microsoft OneNote.

Template.one

Template.onepkg

Template\LCID\Sts\Doctemp\Ppt

Contains document templates for Microsoft PowerPoint.

Filelist.xml

Master03.css

Master03.htm

Master03.xml

Pptmpl.htm

Pptmpl.pot

Pptmpl.pptx

Pres.xml

Pptml.pptx

Preview.wmf

Slide001.htm

Template\LCID\Sts\Doctemp\Smartpgs

Contains document templates for Web Part pages.

*.aspx

_Webpartpage.htm

Template\LCID\Sts\Doctemp\Word

Contains document templates for Microsoft Word.

Wdtmpl.doc

Wdtmpl.htm

Wdtmpl.dotx

Template\LCID\Sts\Doctemp\Xl

Contains document templates for Microsoft Excel.

Filelist.xml

Sheet001.htm

Sheet002.htm

Sheet003.htm

Style.css

Tabstrip.htm

Xltmpl.htm

Xltmpl.xls

Xltmpl.xlsx

Template\LCID\Sts\Doctemp\Xmlforms\Blank

Contains document templates for Microsoft InfoPath.

Template.xml - Default document templates for XML documents

Template\LCID\Workflow

Contains files for workflow activities. LCID is replaced by the locale ID. For example, 3082 is the locale ID for Spanish. Therefore, the path for Spanish is Template\3082\Workflow.

Wss.actions

Moderationworkflow.xml

Template\LCID\Xml

Site template files for the specific language. LCID is replaced by the locale ID. For example, 3082 is the locale ID for Spanish. Therefore, the path for Spanish is Template\3082\Xml.

Deadweb.xml

Rgnlstng.xml

Webtemp.xml

Template\Admin

Contains templates and master pages for Central Administration.

*.aspx

Admin.master

Admin.sitemap

Template\Admin\Bdc

Contains templates and master pages for Microsoft Business Connectivity Services.

*.aspx

Template\ControlTemplates

Contains control templates that determine the layout of list item forms.

*.ascx

Template\DocumentTemplates

Contains the page used for creating document libraries.

Wkpstd.aspx

Template\Features

Contains SharePoint Foundation features.

Template\Features\AdminLinks

Contains Operations and Application Management pages that use the SharePoint Foundation 2010 features infrastructure to provide link extensibility.

Operations.xml

Applications.xml

Feature.xml

Template\Features\AnnouncementsList

Contains files that are used for the Announcements list.

Feature.xml

Template\Features\AnnouncementsList\Announce

Contains a template description file for the Announcements list.

Schema.xml - Schema file

Template\Features\AnnouncementsList\ListTemplates

Contains a template description file for the Announcements list.

Announcements.xml

Template\Features\BasicWebParts

Contains the feature description and Web Part description files for the built-in SharePoint Foundation Web Parts.

Feature.xml - Feature description

Elements.xml - Element manifest

*.dwp - Web Part descriptions

Template\Features\ContactsList

Contains the file that is used for the Contacts list.

Feature.xml

Template\Features\ContactsList\Contacts

Contains the template content file for the Contacts list.

Schema.xml - Schema file

Template\Features\ContactsList\ListTemplates

Contains the template description file for the Contacts list.

Contacts.xml

Template\Features\ContentLightup

Contains files that provide several user interface components and links.

Feature.xml

Template\Features\ContentLightup\Controls

Contains template content files for standard user interface items.

SearchArea.xml

Template\Features\ContentTypeSettings

Contains files that are used for content type settings.

Feature.xml

ContentTypeSettings.xml

Template\Features\ctypes

Contains files that are used for content types.

Ctypeswss.xml

Feature.xml

Template\Features\CustomList

Contains files that are used for Custom lists.

Feature.xml

Template\Features\CustomList\CustList

Contains the template content file for Custom lists.

Schema.xml - Schema file

Template\Features\DataSourceLibrary

Contains files that are used for the Data Source Library.

Feature.xml

Template\Features\DataSourceLibrary\DataSrcs

Contains the template content file for the Data Source Library.

Schema.xml - Schema file

Template\Features\DataSourceLibrary\ListTemplates

Contains the template description file for the Data Source Library.

DataSourceLibrary.xml

Template\Features\DiscussionsList

Contains a file that is used for the Discussion Board list.

Feature.xml

Template\Features\DiscussionsList\Discuss

Contains the template content file for the Discussion Board list.

Schema.xml - Schema file

Template\Features\DiscussionsList\ListTemplates

Contains the template description file for the Discussion Board list.

Discussions.xml

Template\Features\DocumentLibrary

Contains the file that is used for the Document Library list type.

Feature.xml

Template\Features\DocumentLibrary\DOCLib

Contains files that are used for document libraries.

*.aspx - Form pages

*.htm - Dialog boxes

Schema.xml - Schema file

Template\Features\DocumentLibrary\ListTemplates

Contains the template description file for the document libraries.

DocumentLibrary.xml

Template\Features\EventsList

Contains a file that is used for the Events list.

Feature.xml

Template\Features\EventsList\Events

Contains the template content file for the Events list.

Schema.xml - Schema file

Template\Features\EventsList\ListTemplates

Contains the template description file for the Events list.

Events.xml

Template\Features\ExternalList

Contains a file that is used for the External list.

Feature.xml

Template\Features\ExternalList\ExtList

Contains the template content file for the External list.

Schema.xml - Schema file

Template\Features\ExternalList\ListTemplates

Contains the template description file for the External list.

ExternalList.xml

Template\Features\FacilityList

Contains a file that is used for the Facility list.

Feature.xml

Template\Features\FacilityList\Facility

Contains the template content file for the Facility list.

Schema.xml - Schema file

Template\Features\FacilityList\ListTemplates

Contains the template description file for the Facility list.

Facilitylist.xml

Template\Features\FCGroupsList

Contains a file that is used for the FCGroups list.

Feature.xml

Template\Features\FCGroupsList\FCGroups

Contains the template content file for the FCGroups list.

Schema.xml - Schema file

Template\Features\FCGroupsList\ListTemplates

Contains the template description file for the FCGroups list.

Fcgroupslist.xml

Template\Features\Fields

Contains files that are used for the fields in a list.

Feature.xml

Fieldswss.xml

Fieldswss2.xml

Fieldswss3.xml

Template\Features\GanttTasksList

Contains a file that is used for the Project Tasks (Gantt Chart) list.

Feature.xml

Template\Features\GanttTasksList\Gantt

Contains the template content file for the Project Tasks (Gantt Chart) list.

Schema.xml

Template\Features\GanttTasksList\ ListTemplates

Contains the template description file for the Project Tasks (Gantt Chart) list.

GanttTasksList.xml

Template\Features\GBWProvision

Contains files that are used for the Group Board Workshop.

Feature.xml

Listinstance.xml

Template\Features\GBWWebParts

Contains files that are used for Group Board Workshop Web Parts.

Elements.xml

Feature.xml

Timecard.dwp

Whatsnew.dwp

Whereabouts.dwp

Template\Features\GridList

Contains a file that is used for the Custom list in Datasheet view.

Feature.xml

Template\Features\GridList\GridList

Contains a file that is used for the Custom list in Datasheet view list type.

Schema.xml - Schema file

Template\Features\GridList\ ListTemplates

Contains the template description file for the Custom list in Datasheet view.

GridList.xml

Template\Features\GroupWork

Contains files that are used for the Group Board Custom list.

Feature.xml

Listinstance.xml

Template\Features\HelpLibrary

Contains a file that is used for the Help collection.

Feature.xml

Template\Features\HelpLibrary\HelpLibrary

Contains a file that is used for the Help collection.

Schema.xml - Schema file

Template\Features\HelpLibrary\ListTemplates

Contains the template description file for the Help collection.

Helplibrary.xml

Template\Features\HolidaysList

Contains a file that is used for the Holidays List.

Feature.xml

Template\Features\HolidaysList\Holidays

Contains a file that is used for the Holidays List.

Schema.xml - Schema file

Template\Features\HolidaysList\ListTemplates

Contains the template description file for the Holidays List.

Holidayslist.xml

Template\Features\IMEDicList

Contains a file that is used for the Medical Dictionary.

Feature.xml

Template\Features\IMEDicList\IMEDic

Contains a file that is used for the Medical Dictionary.

Schema.xml - Schema file

Template\Features\IMEDicList\ListTemplates

Contains the template description file for the Medical Dictionary.

Imediclist.xml

Template\Features\IssuesList

Contains a file that is used for the Issue Tracking list.

Feature.xml

Template\Features\IssuesList\Issue

Contains the template content file for the Issue Tracking list.

Schema.xml - Schema file

Template\Features\IssuesList\ListTemplates

Contains the template description file for the Issue Tracking list.

Issues.xml

Template\Features\IssueTrackingWorkflow

Contains files that are used for the Issue Tracking Workflow.

IssueTracking.xml

Feature.xml

Template\Features\LinksList

Contains a file that is used for the Links list.

Feature.xml

Template\Features\LinksList\Links

Contains the template content file for the Links list.

Schema.xml - Schema file

Template\Features\LinksList\ListTemplates

Contains the template description file for the Links list.

Links.xml

Template\Features\MobilityRedirect

Contains files that are used for the Mobility Redirection feature for lists.

Feature.xml

Default.aspx

Elements.xml

Template\Features\MpsWebParts

Contains files that are used for the management pack for Microsoft System Center Operations Manager 2007.

Feature.xml

Elements.xml

Template\Features\NoCodeWorkflowLibrary

Contains a file that is used for No-Code Workflows.

Feature.xml

Template\Features\OpenInClient

Contains a file that is used for the OpenInClient feature for opening browser-enabled documents in the Office client applications.

Feature.xml

Template\Features\PictureLibrary

Contains a file that is used for the Picture Library.

Feature.xml

Template\Features\PictureLibrary\PicLib

Contains the template content files that are used for the Picture Library.

*.aspx

Schema.xml

Template\Features\PictureLibrary\ListTemplates

Contains the template description file for the Picture Library.

PictureLibrary.xml

Template\Features\ScheduleList

Contains a file that is used for the Schedule list.

Feature.xml

Template\Features\ScheduleList\Schedule

Contains the template content file that is used for the Schedule list.

Schema.xml

Template\Features\ScheduleList\ListTemplates

Contains the template description file for the Schedule list.

Schedulelist.xml

Template\Features\SiteHelp

Contains a file that is used for the custom site collection Help.

Feature.xml

Template\Features\SiteSettings

Contains files that are used for site settings.

Features.xml

SiteSetting.xml

Template\Features\SPSearchFeature

Contains a file for the SharePoint Foundation Search feature.

Feature.xml

Template\Features\SurveysList

Contains a file for the Survey list.

Feature.xml

Template\Features\SurveysList\Survey

Contains the template content file that is used for the Survey list.

Schema.xml

Template\Features\SurveysList\ListTemplates

Contains the template description file for the Survey list.

Surveys.xml

Template\Features\TasksList

Contains a file for the Tasks list.

Feature.xml

Template\Features\TasksList\ListTemplates

Contains the template description file for the Tasks list.

Tasks.xml

Template\Features\TasksList\Tasks

Contains the template content file that is used for the Tasks list.

Schema.xml - Schema file

Template\Features\TeamCollab

Contains a file that provides team collaboration capabilities by making standard lists — such as document libraries and issues — available.

Feature.xml

Template\Features\TenantAdminBDC

Contains files for Tenant Business Data Connectivity Administration.

Default.aspx

Feature.xml

Template\Features\TenantAdminBDCStapling

Contains files for Tenant Business Data Connectivity Administration Stapling.

Feature.xml

Featurestapling.xml

Template\Features\TenantAdminLinks

Contains files for Tenant Administration Content Deployment Configuration.

Default.aspx

Feature.xml

Template\Features\TimecardList

Contains a file for the Timecard list.

Feature.xml

Template\Features\TimecardList\ListTemplates

Contains the template description file for the Timecard list.

Timecardlist.xml

Template\Features\TimecardList\Tasks

Contains the template content file that is used for the Timecard list.

Schema.xml - Schema file

Template\Features\WebPageLibrary

Contains a file that is used for the Web Page Library.

Feature.xml

Template\Features\WebPageLibrary\ListTemplates

Contains the template description file for the Web Page Library.

WebPageLibrary.xml

Template\Features\WebPageLibrary\WebPageLib

Contains the template content file that is used for the Web Page Library.

Schema.xml - Schema file

Template\Features\WhatsNewList

Contains a file for the What's New list.

Feature.xml

Template\Features\WhatsNewList\ListTemplates

Contains the template description file for the What's New list.

Whatsnewlist.xml

Template\Features\WhatsNewList\Tasks

Contains the template content file that is used for the What's New list.

Schema.xml - Schema file

Template\Features\WhereaboutsList

Contains a file for the Whereabouts list.

Feature.xml

Template\Features\WhereaboutsList\ListTemplates

Contains the template description file for the Whereabouts list.

Whereaboutslist.xml

Template\Features\WhereaboutsList\Whereabouts

Contains the template content file that is used for the Whereabouts list.

Schema.xml - Schema file

Template\Features\WikiPageHomePage

Contains the file that is used for the Wiki home page.

Feature.xml

Template\Features\WikiWelcome

Contains a file that is used for the Wiki site.

Feature.xml

Template\Features\WorkflowHistoryList

Contains a file that provides support for Workflow History lists for a site.

Feature.xml

Template\Features\WorkflowHistoryList\ListTemplates

Contains the template description file for Workflow History lists for a site.

WorkflowHistory.xml

Template\Features\WorkflowHistoryList\Wrkflhis

Contains the template content file that is used for Workflow History lists for a site.

Schema.xml - Schema file

Template\Features\WorkflowProcessList

Provides the ability to support running custom form actions.

Feature.xml

Template\Features\WorkflowProcessList\WorkflowProcess

Contains the template content file that is used for workflow processes.

Schema.xml - Schema file

Template\Features\WorkflowProcessList\ListTemplates

Contains the template description file for workflow processes.

WorkflowProcess.xml

Template\Features\XmlFormLibrary

Contains a file that is used for form libraries.

Feature.xml

Template\Features\XmlFormLibrary\ListTemplates

Contains the template description file for form libraries.

XmlFormLibrary.xml

Template\Features\XmlFormLibrary\XmlForm

Contains the template content file for form libraries.

Schema.xml - Schema file

Template\Global

Contains site definition files that are used for initializing site configurations.

Default.master

Minimal.master

Mwsdefault.master

Mwsdefaultv4.master

V4.master

Template\Identitymodel\Forms

Contains files that are used for a claims forms page.

Default.aspx

Web.config

Template\Identitymodel\Login

Contains files that are used for a claims logon page.

Default.aspx

Web.config

Template\Identitymodel\Trust

Contains files that are used for a trusted provider sign-in page.

Default.aspx

Web.config

Template\Identitymodel\Windows

Contains files that are used for a Windows sign-in page.

Default.aspx

Web.config

Template\Images

Contains images that are shared by all the pages on the server, and that are addressed by the virtual directory _layouts/images.

*.gif, *.jpg, *.png

Template\Layouts

Contains language subdirectories that contain forms such as those for creating lists and site administration pages, and that are addressed by the virtual directory _layouts. All sites share these subdirectories.

*.aspx - Form pages

Web.config - Configuration file

Template\Layouts\LCID

Contains forms for creating lists, site administration pages, and forms for a specific language. LCID is replaced by the locale ID. For example, 3082 is the locale ID for Spanish. Therefore, the path for Spanish is \Template\Layouts\3082.

*.htm - Dialog boxes

*.htc - Menu control

*.js, - JavaScript files

*.xml - XML templates

*.xsd - XML definitions

Template\Layouts\LCID\Images

Contains images that are used in the default site pages for a specific language.

*.gif

Template\Layouts\LCID\Styles

Contains style sheets that are shared by all site templates for a particular language, and that are addressable by the virtual directory _layouts/styles.

*.css - Style sheets

Template\Pages

Contains files that are used for master pages.

Form.aspx

Viewpage.aspx

Webfldr.aspx

Template\Scenarios\AdminConfig

Contains the template description file for a Web site for SharePoint 2010 Products administration and configuration.

Adminconfig.xml

Template\Scenarios\BdcService

Contains the template description file for a Business Data Connectivity administration Web site.

Bdcservice.xml

Template\Scenarios\JoinFarm

Contains the template description file for a Web site where you can join and configure a farm.

Joinfarm.xml

Template\SiteTemplates\Blog

Contains the file that is copied to the root of the Web site upon instantiation of a BLOG by using a BLOG template.

Default.aspx

Template\SiteTemplates\Centraladmin

Contains files that are copied to the root of the Web site upon instantiation of a site by using a CentralAdmin site definition.

*.aspx

Template\SiteTemplates\Centraladmin\Dwp

Contains the file that is used for Central Administration Web Parts.

TopologyView.dwp

Template\SiteTemplates\Centraladmin\Lists\Admintasks

Contains the template content file that is used for the Administrator Tasks list.

Schema.xml

Template\SiteTemplates\Centraladmin\Lists\Distributionlists

Contains the template content files that are used for distribution lists.

*.aspx

Schema.xml

Template\SiteTemplates\Centraladmin\Lists\Healthreports

Contains the template content file that is used for health reports.

Schema.xml

Template\SiteTemplates\Centraladmin\Lists\Healthrules

Contains the template content file that is used for creating health analyzer rules.

Schema.xml

Template\SiteTemplates\Centraladmin\Xml

Contains the site definition file for Central Administration.

Onet.xml

Template\SiteTemplates\Mps

Contains files that are copied to the root of the Web site upon instantiation with a Meeting Workspace template (for example, Default.aspx).

*.aspx - Form pages

Template\SiteTemplates\Mps\Doctemp\Smartpgs

Contains the file that is used for Web Part pages in Meeting Workspaces.

Spstd1.aspx - Form page

Template\SiteTemplates\Mps\Lists

Contains folders for the categories of the lists that are used in the Meeting Workspace templates, and the schema definition and default views.

Template\SiteTemplates\Mps\Lists\Agenda

Contains files that are used for the Agenda list.

*.aspx - Form pages

Schema.xml - Schema file

Template\SiteTemplates\Mps\Lists\Decision

Contains files that are used for the Decisions list.

*.aspx - Form pages

Schema.xml - Schema file

Template\SiteTemplates\Mps\Lists\Meetings

Contains files that are used for the Meeting Workspace templates.

MoveToDt.aspx - Form page

Schema.xml - Schema file

Template\SiteTemplates\Mps\Lists\Objectiv

Contains files that are used for the Objectives list.

*.aspx - Form pages

Schema.xml - Schema file

Template\SiteTemplates\Mps\Lists\People

Contains files that are used for the Attendees list.

*.aspx - Form pages

Schema.xml - Schema file

Template\SiteTemplates\Mps\Lists\Textbox

Contains files that are used for the Text Box list.

*.aspx - Form pages

Schema.xml - Schema file

Template\SiteTemplates\Mps\Lists\Thgbring

Contains files that are used for the Things to Bring list.

*.aspx - Form pages

Schema.xml - Schema file

Template\SiteTemplates\Mps\Lists\Wkspglib

Contains files that are used for lists in the Meeting Workspace templates.

Schema.xml - Schema file

Template\SiteTemplates\Mps\Xml

Contains the available lists in the Meeting Workspace templates, base types for fields (Onet.xml), and the standard view template for new views.

Onet.xml

Template\SiteTemplates\Sgs

Contains files that are copied to the root of the Web site upon instantiation with the Group Work Site template (for example, Default.aspx).

Default.aspx - Default home page for sites that are based on sgs templates

Contains the site definition file.

Onet.xml- Defines navbars, available list types, initial configurations, and modules

Template\SiteTemplates\Sts

Contains files that are copied to the root of the Web site upon instantiation with the Team Site template (for example, Default.aspx).

Default.aspx - Default home page for sites that are based on Team Site templates

Defaultdws.aspx

Template\SiteTemplates\Sts\Xml

Contains the site definition file.

Onet.xml- Defines navbars, available list types, initial configurations, and modules

Template\SiteTemplates\TenantAdmin

Contains files that are copied to the root of the Web site upon instantiation with the Tenant Administration template (for example, Default.aspx).

Default.aspx - Default home page for sites that are based on Tenant Administration templates

Template\SiteTemplates\TenantAdmin\Xml

Contains site definition file.

Onet.xml- Defines navbars, available list types, initial configurations and modules

Template\SiteTemplates\Wiki\Xml

Contains the site definition file.

Onet.xml

Template\Sql

Contains stored procedures for Microsoft SQL Server.

*.sql - Stored procedures for SQL Server

Template\Themes

Contains the list of themes.

Themes.inf - Themes list

Template\Themes\Theme

Contains files that were used by a specific theme.

*.gif ,*.jpg - Images

*.css - Style sheets

*.inf - Theme definition file

Theme.utf8 - Theme file for UTF8 encoding

Template\Xml

Contains XML files that are used by all site templates in all languages.

*.xmo - Templates that are used across all languages and site types

Template\Xml\Help

Contains XML files that are used by the Help system.

Sts.xml - Context-sensitive Help mapping file

UserCode\

Contains files that are used to load and execute sandboxed solutions.

SpucHostService.exe

SpucHostService.exe.config

SpucWorkerProcess.exe

SpucWorkerProcess.exe.config

SpucWorkerProcessProxy.exe

SpucWorkerProcessProxy.exe.config

UserCode\assemblies

Contains core binary files for running sandboxed solutions.

Microsoft.SharePoint.dll

Microsoft.SharePoint.SubsetProxy.dll

Microsoft.SharePoint.UserCode.dll

WebClients\Bdc

Contains a Web client configuration file for a Business Data Connectivity (BDC) Service application.

Client.config

WebClients\SecurityToken

Contains a Web client configuration file for a security token service application.

Client.config

WebClients\SubscriptionSettings

Contains a Web client configuration file for a Subscription Settings Service application.

Client.config

WebClients\Topology

Contains a Web client configuration file for a Topology Web Service application.

Client.config

WebServices\Bdc

Contains files that are used to run a Business Data Connectivity (BDC) Service application.

Bdcservice.svc

Web.config

WebServices\Root

Contains the Web.config file for the Web application root, which stores ASP.NET configuration options.

Web.config

WebServices\SecurityToken

Contains files that are used to run a security token service application.

Securitytoken.svc

Web.config

Windowstokencache.svc

WebServices\SubscriptionSettings

Contains files that are used to run a Subscription Settings Service application.

Subscriptionsettings.svc

Web.config

WebServices\Topology

Contains files that are used to run a Topology Web Service application.

Topology.svc

Web.config

Wpresources

Contains the configuration file for Web Parts.

Web.config

Web Part resource files

In addition to the installation directory, there is a Web Part resources directory that contains the files that are used to support custom Web Parts in SharePoint Foundation 2010. The %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\Wpresources directory contains a Web.config file that is used to help control the security for ASP.NET files that are used in Web Parts. For more information about custom Web Parts, see the Microsoft SharePoint 2010 SDK (http://go.microsoft.com/fwlink/p/?LinkId=198386).

Web site content files

The following table lists the files that are added to each top-level Web site or subsite when a SharePoint site is created.

Folder | Description | Files and purpose
Inetpub\Wwwroot\Wss\VirtualDirectories\porthost header | Contains configuration file. | Web.config
Inetpub\Folder\_vti_pvt | Contains legacy FrontPage Server Extensions files and folders. | Buildversion.cnf Service.cnf Services.cnf
Inetpub\Folder\Wpresources\ | Contains configuration file for Web Parts. | Web.config

All other Web site files are stored in the content and configuration database.


Scripted deployment reference (SharePoint Foundation 2010)

This article describes the commands and syntax that is used in scripted deployment of a Microsoft SharePoint Foundation 2010 farm. It also contains a table of common templates used in Install SharePoint Foundation 2010 by using Windows PowerShell.

Important:

The Install-SharePoint, New-SharePointFarm, and Join-SharePointFarm commands should only be used in the context of the SPModule.zip file.

For information about using these commands to install SharePoint Foundation 2010, see Install SharePoint Foundation 2010 by using Windows PowerShell.

In this article:

  • Install-SharePoint

  • New-SharePointFarm

  • Join-SharePointFarm

  • Common site collection templates

Install-SharePoint

The Install-SharePoint command installs SharePoint Foundation 2010 on all servers.

There are two ways—defined by a parameter set—to run the Install-SharePoint command. In the first case, you specify a path for the install files, and many other values to deviate from the default. The second way is to specify the path for the install files, and then the path to a Config.xml file. During Setup, the PIDKey and other settings are parsed in the config.xml file..

The syntax for the Install-SharePoint command is listed below. Note that the result is determined by which parameter set is specified. For the first parameter set, the SetupExePath is required. All other parameters are optional. If no value is specified for the optional LogPath parameter, the default value is %Temp%.

Note:

In SharePoint Foundation, the PIDKey is not required.

Install-SharePoint -SetupExePath <String> -PIDKey <String> [-LoggingType < Verbose | Off | Standard | Debug>] [-LogPath <String>] [-LogTemplate <String>] [-DisplayLevel <None | Basic | Full>] [-ShowCompletionNotice <SwitchParameter>] [-UseIInstallMode <SwitchParameter>] [-AcceptEula <SwitchParameter>] [-ShowModalDialog <SwitchParameter>] [-AllowCancel <SwitchParameter>] [-ServerRole <APPLICATION | WFE | SINGLESERVER>] [-SetupType <CLEAN_INSTALL | V2V_INPLACE_UPGRADE | B2B_UPGRADE | SKU2SKU_UPGRADE>] [-InstallDirectory <String>] [-DataDirectory <String>] [-RunsWorkaround <SwitchParameter>] [-PhysicalSKU <OfficeServer | SharePoint | SearchServer | SearchServerExpress | WCServer | ProjectServer | SharePointLanguagePack | ServerLanguagePack>]

For the second parameter set, there are two required parameters, SetupExePath and ConfigXMLPath.

Install-SharePoint -SetupExePath <String> -ConfigXMLPath <String> [-PIDKey <String>] [-PhysicalSKU <OfficeServer | SharePoint | SearchServer | SearchServerExpress | WCServer | ProjectServer | SharePointLanguagePack | ServerLanguagePack>]

New-SharePointFarm

The New-SharePointFarm command creates the farm on the server that will be running the Central Administration Web site.

The command performs the following actions:

  1. Creates the configuration database.

  2. Creates the administration content database.

  3. Installs the Help collection.

  4. Creates the Central Administration Web application.

  5. Copies shared application data to existing Web application folders.

The syntax for the New-SharePointFarm command is listed below and there are two required parameters, DatabaseAccessAccount and DatabaseServer. All other parameters are optional.

New-SharePointFarm -DatabaseAccessAccount <PSCredential> -DatabaseServer <String> [-Passphrase <SecureString>] [-Port <Int>] [-AdminAuthMethod <NTLM | Kerberos>] [-FarmName <String>]

Example: New-SharePointFarm -DatabaseAccessAccount (Get-Credential DOMAIN\username) -DatabaseServer "SQL01" -FarmName "TestFarm"

Join-SharePointFarm

You run the Join-SharePointFarm command on servers to connect them to the farm.

The syntax for the Join-SharePointFarm command is listed below and there are two required parameters, DatabaseServer and ConfigurationDatabaseName. All other parameters are optional.

Join-SharePointFarm -DatabaseServer <String> -ConfigurationDatabaseName <String> [-Passphrase <SecureString>]

Note:

To stop the user from being prompted for the password, you can use the Passphrase parameter. The value for the Passphrase parameter is the password of the user.

Common site collection templates

The following table describes common templates used in Install SharePoint Foundation 2010 by using Windows PowerShell.

Parameter value | Description
GLOBAL#0 | Global template
STS#0 | Team Site
STS#1 | Blank Site
STS#2 | Document Workspace
MPS#0 | Basic Meeting Workspace
MPS#1 | Blank Meeting Workspace
MPS#2 | Decision Meeting Workspace
MPS#3 | Social Meeting Workspace
MPS#4 | Multipage Meeting Workspace
CENTRALADMIN#0 | Central Admin Site
WIKI#0 | Wiki Site
BLOG#0 | Blog
SGS#0 | Group Work Site
TENANTADMIN#0 | Tenant Admin Site
ACCSRV#0 | Access Services Site
ACCSRV#1 | Assets Web Database
ACCSRV#3 | Charitable Contributions Web Database
ACCSRV#4 | Contacts Web Database
ACCSRV#6 | Issues Web Database
ACCSRV#5 | Projects Web Database
BDR#0 | Document Center
OFFILE#0 | (obsolete) Records Center
OFFILE#1 | Records Center
OSRV#0 | Shared Services Administration Site
PPSMASite#0 | PerformancePoint
BICenterSite#0 | Business Intelligence Center
PWA#0 | Project Web App Site
PWS#0 | Microsoft Project Site
SPS#0 | SharePoint Portal Server Site
SPSPERS#0 | SharePoint Portal Server Personal Space
SPSMSITE#0 | Personalization Site
SPSTOC#0 | Contents area Template
SPSTOPIC#0 | Topic area template
SPSNEWS#0 | News Site
CMSPUBLISHING#0 | Publishing Site
BLANKINTERNET#0 | Publishing Site
BLANKINTERNET#1 | Press Releases Site
BLANKINTERNET#2 | Publishing Site with Workflow
SPSNHOME#0 | News Site
SPSSITES#0 | Site Directory
SPSCOMMU#0 | Community area template
SPSREPORTCENTER#0 | Report Center
SPSPORTAL#0 | Collaboration Portal
SRCHCEN#0 | Enterprise Search Center
PROFILES#0 | Profiles
BLANKINTERNETCONT | Publishing Portal
SPSMSITEHOST#0 | My Site Host
ENTERWIKI#0 | Enterprise Wiki
SRCHCENTERLITE#0 | Basic Search Center
SRCHCENTERLITE#1 | Basic Search Center
SRCHCENTERFAST#0 | FAST Search Center
visprus#0 | Visio Process Repository


User permissions and permission levels (SharePoint Foundation 2010)
See Also

This article describes the default permission levels as well as the user permissions in Microsoft SharePoint Foundation 2010.

In this article:

  • Default permission levels

  • User permissions

Default permission levels

Permission levels are collections of permissions that allow users to perform a set of related tasks. SharePoint Foundation 2010 includes five permission levels by default. You can customize the permissions available in these permission levels (except for the Limited Access and Full Control permission levels), or you can create customized permission levels that contain only the permissions you need. For more information about how to customize permission levels, see Configure custom permissions (SharePoint Foundation 2010).

Note:

Although you cannot directly edit the Limited Access and Full Control permission levels, you can make individual permissions unavailable for the entire Web application, which removes those permissions from the Limited Access and Full Control permission levels. For more information about how to manage permissions for a Web application, see Manage permissions for a Web application (SharePoint Foundation 2010).

The following table lists the default permission levels for team sites in SharePoint Foundation 2010.

Permission level Description Permissions included by default

Limited Access

Allows access to shared resources in the Web site so that the users can access an item within the site. Designed to be combined with fine-grained permissions to give users access to a specific list, document library, folder, list item, or document, without giving them access to the entire site. Cannot be customized or deleted.

  • View Application Pages

  • Browse User Information

  • Use Remote Interfaces

  • Use Client Integration Features

  • Open

Read

View pages, list items and download documents.

  • Limited Access permissions, plus:

  • View Items

  • Open Items

  • View Versions

  • Create Alerts

  • Use Self-Service Site Creation

  • View Pages

Contribute

View, add, update, and delete items in the existing lists and document libraries.

  • Read permissions, plus:

  • Add Items

  • Edit Items

  • Delete Items

  • Delete Versions

  • Browse Directories

  • Edit Personal User Information

  • Manage Personal Views

  • Add/Remove Personal Web Parts

  • Update Personal Web Parts

Design

View, add, update, delete, approve, and customize items or pages in the Web site.

  • Approve permissions, plus:

  • Manage Lists

  • Add and Customize Pages

  • Apply Themes and Borders

  • Apply Style Sheets

Full Control

Allows full control of the scope.

All permissions

User permissions

SharePoint Foundation 2010 includes 33 permissions, which are used in the five default permission levels. You can change which permissions are included in a particular permission level (except for the Limited Access and Full Control permission levels), or you can create a new permission level to contain specific permissions.

Permissions are categorized as list permissions, site permissions, and personal permissions, depending on the objects to which they can be applied. For example, site permissions apply to a particular site, list permissions apply only to lists and libraries, and personal permissions apply only to things such as personal views, private Web Parts, and more. The following tables describe what each permission is used for, the dependent permissions, and the permission levels in which it is included.

List permissions

Permission | Description | Dependent permissions | Included in these permission levels by default
Manage Lists | Create and delete lists, add or remove columns in a list, and add or remove public views of a list. | View Items, View Pages, Open, Manage Personal Views | Design, Full Control
Override Check Out | Discard or check in a document that is checked out to another user without saving the current changes. | View Items, View Pages, Open | Design, Full Control
Add Items | Add items to lists, and add documents to document libraries. | View Items, View Pages, Open | Contribute, Design, Full Control
Edit Items | Edit items in lists, edit documents in document libraries, and customize Web Part Pages in document libraries. | View Items, View Pages, Open | Contribute, Design, Full Control
Delete Items | Delete items from a list, and documents from a document library. | View Items, View Pages, Open | Contribute, Design, Full Control
View Items | View items in lists, and documents in document libraries. | View Pages, Open | Read, Contribute, Design, Full Control
Approve Items | Approve minor versions of list items or documents. | Edit Items, View Items, View Pages, Open | Design, Full Control
Open Items | View the source of documents with server-side file handlers. | View Items, View Pages, Open | Read, Contribute, Design, Full Control
View Versions | View past versions of list items or documents. | View Items, Open Items, View Pages, Open | Read, Contribute, Design, Full Control
Delete Versions | Delete past versions of list items or documents. | View Items, View Versions, View Pages, Open | Contribute, Design, Full Control
Create Alerts | Create e-mail alerts. | View Items, View Pages, Open | Read, Contribute, Design, Full Control
View Application Pages | View forms, views, and application pages. Enumerate lists. | Open | All

Site permissions

Permission | Description | Dependent permissions | Included in these permission levels by default
Manage Permissions | Create and change permission levels on the Web site and assign permissions to users and groups. | View Items, Open Items, View Versions, Browse Directories, View Pages, Enumerate Permissions, Browse User Information, Open | Full Control
View Usage Data | View reports on Web site usage. | View Pages, Open | Full Control
Create Subsites | Create subsites such as team sites, Meeting Workspace sites, and Document Workspace sites. | View Pages, Browse User Information, Open | Full Control
Manage Web Site | Perform all administration tasks for the Web site, and manage content. | View Items, Add and Customize Pages, Browse Directories, View Pages, Enumerate Permissions, Browse User Information, Open | Full Control
Add and Customize Pages | Add, change, or delete HTML pages or Web Part pages, and edit the Web site by using a Windows SharePoint Services-compatible editor. | View Items, Browse Directories, View Pages, Open | Design, Full Control
Apply Themes and Borders | Apply a theme or borders to the entire Web site. | View Pages, Open | Design, Full Control
Apply Style Sheets | Apply a style sheet (.css file) to the Web site. | View Pages, Open | Design, Full Control
Create Groups | Create a group of users that can be used anywhere within the site collection. | View Pages, Browse User Information, Open | Full Control
Browse Directories | Enumerate files and folders in a Web site by using Microsoft SharePoint Designer 2010 and Web DAV interfaces. | View Pages, Open | Contribute, Design, Full Control
Use Self-Service Site Creation | Create a Web site by using Self-Service Site Creation. | View Pages, Browse User Information, Open | Read, Contribute, Design, Full Control
View Pages | View pages in a Web site. | Open | Read, Contribute, Design, Full Control
Enumerate Permissions | Enumerate permissions on the Web site, list, folder, document, or list item. | Browse Directories, View Pages, Browse User Information, Open | Full Control
Browse User Information | View information about users of the Web site. | Open | All
Manage Alerts | Manage alerts for all users of the Web site. | View Items, View Pages, Open | Full Control
Use Remote Interfaces | Use SOAP, Web DAV, or SharePoint Designer 2010 interfaces to access the Web site. | Open | All
Use Client Integration Features | Use features that start client applications. Without this permission, users must work on documents locally and then upload their changes. | Use Remote Interfaces, Open | All
Open | Open a Web site, list, or folder to access items inside that container. | None | All
Edit Personal User Information | Users can change their own user information, such as adding a picture. | Browse User Information, Open | Contribute, Design, Full Control

Personal permissions

Permission | Description | Dependent permissions | Included in these permission levels by default
Manage Personal Views | Create, change, and delete personal views of lists. | View Items, View Pages, Open | Contribute, Design, Full Control
Add/Remove Personal Web Parts | Add or remove personal Web Parts on a Web Part page. | View Items, View Pages, Open | Contribute, Design, Full Control
Update Personal Web Parts | Update Web Parts to display personalized information. | View Items, View Pages. Open | Contribute, Design, Full Control

See Also

Concepts

Configure custom permissions (SharePoint Foundation 2010)


Database types and descriptions (SharePoint Foundation 2010)

This article describes the databases that are installed for Microsoft SharePoint Foundation 2010. It includes some sizing and placement information.

Databases for SharePoint Foundation 2010 can be hosted in Microsoft SQL Server 2008 R2, SQL Server 2008 with Service Pack 1 (SP1) and Cumulative Update 2, or SQL Server 2005 with SP3 and Cumulative Update 3. Stand-alone installations can also be hosted in the Express Editions of SQL Server 2008 R2 or SQL Server 2008. For more information see Hardware and software requirements (SharePoint Foundation 2010).

Note:

The database names listed in this topic are automatically created when you run the SharePoint Products Configuration Wizard. You do not have to use these naming conventions. You can either specify database names when you create them, or change the database names after they have been created. For more information, see Deploy by using DBA-created databases (SharePoint Foundation 2010).

The database sizes listed in this article are based on the following ranges.

Descriptor | Size range
Small | 1 gigabyte (GB) or less
Medium | Up to 100 GB.
Large | Up to 1 terabyte
Extra-large | 1 terabyte or more

In this article:

  • SharePoint Foundation 2010 databases

  • SQL Server system databases

For a graphical overview of the databases used by SharePoint Foundation 2010, see Database model (http://go.microsoft.com/fwlink/p/?LinkId=187968).

SharePoint Foundation 2010 databases

The following databases are part of a SharePoint Foundation 2010 deployment. These databases are also part of any other SharePoint 2010 Products deployment.

Configuration

The configuration database contains data about SharePoint databases, Internet Information Services (IIS) Web sites, Web applications, trusted solutions, Web Part packages, site templates, and Web application and farm settings specific to SharePoint 2010 Products, such as default quota settings and blocked file types.

Default database name prefix when installed by using the SharePoint Products Configuration Wizard | SharePoint_Config
Location requirements | None
General size information and growth factors | Small. However, transaction log files are likely to become large. For more information, see Additional notes, below.
Read/write characteristics | Read-intensive
Recommended scaling method | Must scale up; that is, the database must grow larger, because only one configuration database is supported per farm. (Significant growth is unlikely.)
Associated health rules | None
Supported backup mechanisms | SharePoint Foundation 2010 backup and recovery, SQL Server, and System Center Data Protection Manager (DPM) 2010. The configuration database is a special case for backup and recovery. For more information, see Additional notes below.
Default recovery model | Full. We recommend that you switch the configuration database to the simple recovery model to restrict growth of the log file.
Supports mirroring within a farm for availability | Yes
Supports asynchronous mirroring or log-shipping to another farm for disaster recovery | No

Additional notes

Transaction log files. We recommend that you back up the transaction log for the configuration database regularly to force truncation, or — if you are not mirroring your system — change the database to run in Simple recovery mode. For more information, see Transaction Log Truncation (http://go.microsoft.com/fwlink/p/?LinkId=186687).

Backup and recovery. The configuration database is backed up when you perform a SharePoint farm configuration and content backup, and some configuration settings from the database are exported and stored as XML files. When a farm is restored, the configuration database is not restored. Instead, the saved configuration settings are imported. The configuration database can be successfully backed up and restored by using SQL Server or other tools if the SharePoint farm is first taken offline.

Note:

Many configuration settings are not saved during a farm configuration-only backup or restore, in particular Web application settings, service application settings, and settings that are specific to the local server. These settings are saved during a farm content and configuration backup, but some of them, such as service application proxy settings, cannot be restored during a farm recovery. For information about what is saved during a configuration backup, see Back up a farm configuration (SharePoint Foundation 2010). For information about how to document and copy configuration settings that are not backed up, see Copy configuration settings from one farm to another (SharePoint Foundation 2010).

Central Administration content

The Central Administration content database is considered to be a configuration database. It stores all site content, including site documents or files in document libraries, list data, and Web Part properties, in addition to user names and rights for the Central Administration site collection.

Default database name prefix when installed by using the SharePoint Products Configuration Wizard | SharePoint_AdminContent
Location requirements | None
General size information, and growth factors | Small.
Read/write characteristics | Varies
Recommended scaling method | Must scale up; that is, the database must grow larger, because only one Central Administration database is supported per farm. (Significant growth is unlikely.)
Associated Health rules | None
Supported backup mechanisms | SharePoint Foundation 2010 backup and recovery, SQL Server, and DPM 2010. The Central Administration content database is a special case for backup and recovery. For more information, see Additional notes below.
Default recovery model | Full
Supports mirroring within a farm for availability | Yes
Supports asynchronous mirroring or log-shipping to another farm for disaster recovery | No

Additional notes

Backup and recovery. The Central Administration content database is backed up when you perform a SharePoint farm configuration and content backup. When a farm is restored, the Central Administration content database is not restored. The Central Administration content database can be successfully backed up and restored by using SQL Server or other tools if the SharePoint farm is first taken offline.

Content databases

Content databases store all content for a site collection, including site documents or files in document libraries, list data, Web Part properties, audit logs, and sandboxed solutions, in addition to user names and rights.

All the data for a specific site collection resides in one content database on only one server. A content database can be associated with more than one site collection.

Content databases also contain the Microsoft Office Web Apps cache, if Office Web Apps have been deployed. Only one cache is created per Web application. If multiple site collections that are stored in different content databases have Office Web Apps activated, they will all use the same cache. You can configure the size of cache, the expiration period, and the location. For more information about the size of the Office Web Apps cache, see Manage the Office Web Apps cache.

Default database name prefix when installed by using the SharePoint Products Configuration Wizard

WSS_Content

Location requirements

None

General size information, and growth factors

We strongly recommended limiting the size of content databases to 200 GB to help ensure system performance. For more information, see Additional notes, below.

Content database size varies significantly by usage. For more information, see Additional notes, below.

Read/write characteristics

Varies by usage. For example, collaboration environments are write-intensive; document management environments are read-intensive.

Recommended scaling method

The content database that supports a site collection must scale up; that is, the database must be able to grow larger as needed. However, you can create additional site collections that are associated with a Web application and associate the new site collection with a different content database. Also, if a content database is associated with multiple site collections, you can move a site collection to another database.

Associated Health rules

None

Supported backup mechanisms

SharePoint Foundation 2010 backup and recovery, SQL Server, and DPM 2010.

Default recovery model

Full

Supports mirroring within a farm for availability

Yes

Supports asynchronous mirroring or log-shipping to another farm for disaster recovery

Yes

Additional notes

Recommended content database size limitations

We strongly recommend that you limit the size of content databases to 200 GB to help ensure system performance.

Important:

Content database sizes up to 1 terabyte are supported only for large, single-site repositories and archives in which data remains reasonably static, such as reference document management systems and Records Center sites. Larger database sizes are supported for these scenarios because their I/O patterns and typical data structure formats have been designed for, and tested at, larger scales. For more information about large-scale document repositories, see "Estimate Performance and Capacity Requirements for Large Scale Document Repositories", available from Performance and capacity test results and recommendations (SharePoint Server 2010).

Content database size estimation

Content database size varies substantially with the usage of the site. Growth factors include the number of documents, number of users, use of versioning, use of Recycle Bins, size of quotas, whether the audit log is configured, and how many items are chosen for auditing.

If Office Web Apps are in use, the Office Web Apps cache can significantly affect the size of a content database. For more information about the size of the Office Web Apps cache, see Manage the Office Web Apps cache.

Usage and Health Data Collection database

The Usage and Health Data Collection service application database stores health monitoring and usage data temporarily, and can be used for reporting and diagnostics. The Usage and Health Data Collection database is the only SharePoint database that supports schema modifications.

Note:

For more information on supported Read operations, see "Read Operations Addendum" in KB 841057: Support for changes to the databases that are used by Office server products and by Windows SharePoint Services.

Default database name prefix when installed by using the SharePoint Products Configuration Wizard | WSS_UsageApplication
Location requirements | The Usage and Health Data Collection database is very active, and should be put on a separate disk or spindle, if possible.
General size information, and growth factors | Extra large. Database size depends on the retention factor, number of items enabled for logging and external monitoring, how many Web applications are running in the environment, how many users are currently working, and which features are enabled.
Read/write characteristics | The Usage and Health Data Collection database is very write-heavy.
Recommended scaling method | Must scale up; that is, the database must grow larger, because only one logging database is supported per farm.
Associated Health rules | None
Supported backup mechanisms | SharePoint Foundation 2010 backup and recovery, SQL Server, and DPM 2010.
Default recovery model | Simple
Supports mirroring within a farm for availability | Yes. However, although you can mirror the Usage and Health Data Collection database, we do not recommend that you do. It is easily re-created in the event of a failure.
Supports asynchronous mirroring or log-shipping to another farm for disaster recovery | Yes. However, although you can asynchronously mirror or log-ship the Usage and Health Data Collection database, we do not recommend that you do. It is easily re-created in the event of a failure.

Business Data Connectivity database

The Business Data Connectivity service application database stores external content types and related objects.

Default database name prefix when installed by using the SharePoint Products Configuration Wizard | Bdc_Service_DB_
Location requirements | None
General size information, and growth factors | Small. Size is determined by the number of connections.
Read/write characteristics | The Business Data Connectivity database is very read-heavy.
Recommended scaling method | Must scale up; that is, the database must grow larger, because only one Business Data Connectivity database is supported per farm. (Significant growth is unlikely.)
Associated Health rules | None
Supported backup mechanisms | SharePoint Foundation 2010 backup and recovery, SQL Server, and DPM 2010.
Default recovery model | Full
Supports mirroring within a farm for availability | Yes
Supports asynchronous mirroring or log-shipping to another farm for disaster recovery | No

Application Registry database

The Application Registry service application database stores backward-compatible information that is used to connect to information that is used by the Microsoft Office SharePoint Server 2007 Business Data Catalog API.

Note:

When you have finished migrating an application from the Office SharePoint Server 2007 Business Data Catalog, the Application Registry service application can be disabled and the database can be deleted.

Default database name prefix when installed by using the SharePoint Products Configuration Wizard | Application_Registry_server_DB_
Location requirements | None
General size information, and growth factors | Small. Size is determined by the number of connections.
Read/write characteristics | Read-heavy.
Recommended scaling method | Must scale up; that is, the database must grow larger, because only one Application Registry service database is supported per farm. (Significant growth is unlikely.)
Associated Health rules | None
Supported backup mechanisms | SharePoint Foundation 2010 backup and recovery, SQL Server, and DPM 2010.
Default recovery model | Full
Supports mirroring within a farm for availability | Yes
Supports asynchronous mirroring or log-shipping to another farm for disaster recovery | No

Subscription Settings database

The Microsoft SharePoint Foundation Subscription Settings service application database stores features and settings for hosted customers. The Subscription Settings service application and database are not created by the SharePoint Products Configuration Wizard — they must be created by using Windows PowerShell cmdlets. For more information, see New-SPSubscriptionSettingsServiceApplication.

Default database name prefix when installed by using the SharePoint Products Configuration Wizard | SubscriptionSettings_
Location requirements | None
General size information, and growth factors | Small. Size is determined by the number of tenants, farms, and features supported.
Read/write characteristics | The subscription database is read-heavy.
Recommended scaling method | Scale up the database that supports the service application instance. You can scale out by creating additional instances of the service application, however, the decision to create a separate service application is likely to be based on business, rather than scale, requirements.
Associated Health rules | None
Supported backup mechanisms | SharePoint Foundation 2010 backup and recovery, SQL Server, and DPM 2010.
Recommended recovery model | Full
Supports mirroring within a farm for availability | Yes
Supports asynchronous mirroring or log-shipping to another farm for disaster recovery | No

SQL Server system databases

SharePoint Foundation 2010 is built on SQL Server, and as a result, makes use of the SQL Server system databases. SQL Server does not support users' directly updating the information in system objects such as system tables, system stored procedures, and catalog views. Instead, SQL Server provides a complete set of administrative tools that let users fully administer their system and manage all users and objects in a database. For more information about the SQL Server system databases, see System Databases (http://go.microsoft.com/fwlink/p/?LinkId=186699).

master

The master database records all the system-level information for an instance of SQL Server.

Default database name | master
Location requirements | None
General size information, and growth factors | Small
Read/write characteristics | Varies
Recommended scaling method | Scale up. (Significant growth is unlikely.)
Associated Health rules | None
Supported backup mechanisms | SQL Server backup and recovery
Default recovery model | Simple
Supports mirroring within a farm for availability | No
Supports asynchronous mirroring or log-shipping to another farm for disaster recovery | No

model

The model database is used as the template for all databases created on the instance of SQL Server. Modifications made to the model database — such as database size, collation, recovery model, and other database options — are applied to any databases created afterward.

Default database name | model
Location requirements | None
General size information, and growth factors | Small
Read/write characteristics | Varies
Recommended scaling method | Scale up. (Significant growth is unlikely.)
Associated Health rules | None
Supported backup mechanisms | SQL Server backup and recovery
Default recovery model | Full
Supports mirroring within a farm for availability | No
Supports asynchronous mirroring or log-shipping to another farm for disaster recovery | No

msdb

The msdb database is used by SQL Server Agent for scheduling alerts and jobs.

Default database name | msdb
Location requirements | None
General size information, and growth factors | Small
Read/write characteristics | Varies
Recommended scaling method | Scale up. (Significant growth is unlikely.)
Associated Health rules | None
Supported backup mechanisms | SQL Server backup and recovery
Default recovery model | Simple
Supports mirroring within a farm for availability | No
Supports asynchronous mirroring or log-shipping to another farm for disaster recovery | No

tempdb

The tempdb database is a workspace for holding temporary objects or intermediate result sets. It also fills any other temporary storage needs. The tempdb database is re-created every time SQL Server is started.

Default database name | tempdb
Location requirements | Locate on a fast disk, on a separate spindle from other databases. Create as many files as needed to maximize disk bandwidth. Using multiple files reduces tempdb storage contention and yields significantly better scalability. However, do not create too many files because this can reduce performance and increase management overhead. As a general guideline, create one data file for each CPU on the server and then adjust the number of files up or down as necessary. Be aware that a dual-core CPU is considered to be two CPUs.
General size information, and growth factors | Small to extra-large. The size of the tempDB database goes both up and down quickly. Size depends on how many users are using the system, in addition to the specific processes that are running; for example, online rebuilds of large indexes, or large sorts cause the database to grow quickly.
Read/write characteristics | Varies
Recommended scaling method | Scale up
Associated Health rules | None
Supported backup mechanisms | SQL Server backup and recovery
Default recovery model | Simple
Supports mirroring within a farm for availability | No
Supports asynchronous mirroring or log-shipping to another farm for disaster recovery | No


User experience on read-only sites (SharePoint Foundation 2010)

This article describes how the user interface is modified on a Microsoft SharePoint Foundation 2010 site for which the related content database is set to be read-only (a read-only site).

The user experience of a read-only site is characterized by the following:

  • Common tasks that do not require writing to the content database are fully available.

  • Most of the common tasks that require writing to the content database are not available, either because they have been disabled in the user interface or because the user is no longer allowed to apply changes.

  • Some common tasks that require writing to the content database appear to be available, but return errors.

This article describes the common tasks that are not available and the common tasks that return errors on a read-only site.

Common tasks that are not available on a read-only site, and do not return errors

The user interface is modified so that common tasks that require writing to the database are not available and appear dimmed. The elements of the user interface that are not available are listed in the following table.

Object | Interface elements disabled on a read-only site
Site Actions menu | Edit page New Page New Document Library New Site More Create Options Edit Site in SharePoint Designer Site Workflows
Library tools tab: Documents | New Document Upload Document New Folder Edit Document Check Out Check In Discard Check Out Edit Properties Version History Delete Document Mobile Link Manage Copies Go To Source Workflows Publish Unpublish Approve/Reject Cancel Approval
Library tools tab: Library | New Row Refresh Data Create View Modify View Create Column Edit Library Form Web Parts Library Settings Workflows
List tools tab: Items | New Item New Folder Edit Item Delete Item Attach File Workflows Approve/Reject
List tools tab: List | New Row Refresh Data Refresh Data Create View Create Column Mobile Link Connect to Outlook Create Visio diagram Open Schedule Edit list Form Web Parts List Settings Customize Form Workflows
Calendar Tools Tab: Events | New Event Edit Event Delete Event Workflows Approve/Reject
Calendar Tools Tab: Calendar | Create View Modify View Alert Me
Site Settings: Users and Permissions People and Groups | New Actions: Remove Users from Group Settings
Site Settings: Users and Permissions: Site Permissions | Grant permissions Create Group User Permissions Remove User Permissions Site Collection Administrators
SiteSettings: Users and Permissions: All People | Actions: Delete Users from Site Settings: List Settings

Some options that are not available on a read-only site appear to be available, but the OK button is disabled on subsequent pages. These pages are listed below.

  • Users and Permissions

    • Site collection administrators

    • Site permissions: Manage access request

  • Look and Feel

    • Title, Description, and Icon

    • Top Link Bar: New Navigation Link

    • Quick Launch

      • New Heading

      • New Navigation Link

    • Tree View

  • Galleries

    • Site columns

    • Site content types

  • Site Administration: Regional settings

  • Site Actions: Reset to site definition

Common tasks that appear to be available in a read-only site, but return errors

Some options that are not available in a read-only database appear to be available in the interface, however users will receive error messages if they attempt to perform these actions. The elements of the user interface that return errors are listed in the following table.

Component or area Type of operation or action Behavior or error message

Site Theme

On the Site Theme page, click Apply.

SharePoint returns the "Error: Access Denied" message.

Site Libraries and Lists

Click Create new content.

SharePoint returns the "An unexpected error has occurred" message.

Sites and workspaces

Click Create.

SharePoint returns the "Error: Access Denied" message.

Customize the Quick Launch

Click Change Order, reset the order of the links on the Reorder Links page, and then click OK.

SharePoint returns the "Error: Access Denied" message.

Site Features

Click Activate or Deactivate.

SharePoint returns the "Error: Access Denied" message.

Delete this site

SharePoint returns the "Error: Access Denied" message.

Recycle Bin

Click any of the following buttons:

  • Restore Selection

  • Delete Selection

  • Empty Recycle Bin

SharePoint returns the "Error: Access Denied" message.

SharePoint Designer Settings

Change any settings, and then click OK.

SharePoint returns the "Error: Access Denied" message.

Help Settings

SharePoint returns the "Error: Access Denied" message.

Custom Commands Ribbon

Click Customize Form.

SharePoint returns the Microsoft InfoPath "Enter your credentials to connect to the following Web service" error.

List Tools Ribbon, List tab

Click Customize Form.

SharePoint returns the error "Microsoft InfoPath 2010 is required to use this feature."


Language packs (SharePoint Foundation 2010)

This article lists the language packs that are available for Microsoft SharePoint Foundation 2010. Language packs enable you to create sites and site collections in multiple languages without requiring separate installations of SharePoint Foundation 2010 in each language. For more information about language packs, see Deploy language packs (SharePoint Foundation 2010). The language packs can be downloaded at Language Packs for SharePoint Foundation 2010.

The following table lists the language packs that are available for SharePoint Foundation 2010:

Language | Language ID
Arabic | 1025
Azeri (Latin) | 1068
Basque | 1069
Bosnian (Latin) | 5146
Bulgarian | 1026
Catalan | 1027
Chinese (Simplified) | 2052
Chinese (Traditional) | 1028
Croatian | 1050
Czech | 1029
Danish | 1030
Dutch | 1043
English | 1033
Estonian | 1061
Finnish | 1035
French | 1036
Galician | 1110
German | 1031
Greek | 1032
Hebrew | 1037
Hindi | 1081
Hungarian | 1038
Indonesian | 1057
Irish - Ireland | 2108
Italian | 1040
Japanese | 1041
Kazakh | 1087
Korean | 1042
Latvian | 1062
Lithuanian | 1063
Macedonian (FYROM) | 1071
Malay (Malaysia) | 1086
Norwegian (Bokmål) | 1044
Polish | 1045
Portuguese (Brazil) | 1046
Portuguese (Portugal) | 2070
Romanian | 1048
Russian | 1049
Serbian (Cyrillic) | 3098
Serbian (Latin) | 2074
Slovak | 1051
Slovenian | 1060
Spanish | 3082
Swedish | 1053
Thai | 1054
Turkish | 1055
Ukrainian | 1058
Vietnamese | 1066
Welsh | 1106


Languages for word breakers and stemmers (SharePoint Foundation 2010)

This article lists the languages for which Microsoft SharePoint Foundation 2010 provides word breakers and stemmers. For information about using word breakers and stemmers with multilingual sites, see Plan for multilingual sites (SharePoint Foundation 2010).

The following table lists the languages for which SharePoint Foundation 2010 provides word breakers and stemmers:

Language | Language | Language
Arabic* | Hindi | Punjabi
Bengali | Hungarian* | Romanian
Bulgarian | Icelandic | Russian
Catalan | Indonesian | Serbian (Cyrillic)
Chinese (Simplified)* | Italian | Serbian (Latin)
Chinese (Traditional)* | Japanese* | Slovak
Croatian | Kannada | Slovenian
Czech | Korean | Spanish (Spain)
Danish | Latvian | Spanish (Mexico)
Dutch | Lithuanian | Swedish
English | Malay | Tamil
Finnish* | Malayalam | Telugu
French | Marathi | Thai*
German | Norwegian | Turkish*
Greek | Polish | Ukrainian
Gujarati | Portuguese (Brazil) | Urdu
Hebrew* | Portuguese (Portugal) | Vietnamese*

*These languages have only word breakers. There are no stemmers available for these languages.


Regional settings (SharePoint Foundation 2010)
See Also

Published: April 28, 2011

This article lists the regional settings for Microsoft SharePoint Foundation 2010.

In this article:

  • Locale

  • Sort order

  • Time zone

  • Calendar

  • Currency

SharePoint Foundation 2010 uses the following types of regional settings: locale, time zone, sort order, calendar, and currency. Although currency is not a regional setting per se, the default value of the currency is determined by the locale you specified in your regional settings. You specify the locale, sort order, time zone, and calendar settings on the Regional Settings page, and you specify the currency settings on the Create Column page when you work with lists.

For more information about how to access and modify regional settings, see Regional Settings Schema (http://go.microsoft.com/fwlink/p/?LinkID=217116).

Locale

The locale setting controls numbering, sorting, calendar, and date and time formatting for the Web site. You can change the locale for a Web site by using the Regional Settings page. You can set the locales for your SharePoint sites to the locales shown in the following table.

ID | Locale | ID | Locale
1078 | Afrikaans | 1089 | Kiswahili
1052 | Albanian | 1111 | Konkani
1156 | Alsatian | 1042 | Korean
1118 | Amharic | 1088 | Kyrgyz
5121 | Arabic (Algeria) | 1108 | Lao
15361 | Arabic (Bahrain) | 1062 | Latvian
3073 | Arabic (Egypt) | 1063 | Lithuanian
2049 | Arabic (Iraq) | 2094 | Lower Sorbian
11265 | Arabic (Jordan) | 4155 | Lule Sami (Norway)
13313 | Arabic (Kuwait) | 5179 | Lule Sami (Sweden)
12289 | Arabic (Lebanon) | 1134 | Luxembourgish
4097 | Arabic (Libya) | 1071 | Macedonian
6145 | Arabic (Morocco) | 1086 | Malay (Malaysia)
8193 | Arabic (Oman) | 2110 | Malay (Brunei Darussalam)
16385 | Arabic (Qatar) | 1100 | Malayalam
1025 | Arabic (Saudi Arabia) | 1082 | Maltese
10241 | Arabic (Syria) | 1153 | Maori
7169 | Arabic (Tunisia) | 1146 | Mapudungun
14337 | Arabic (U.A.E.) | 1102 | Marathi
9217 | Arabic (Yemen) | 1148 | Mohawk
1067 | Armenian | 1104 | Mongolian (Cyrillic)
1101 | Assamese | 2128 | Mongolian (Mongolian)
2092 | Azeri (Cyrillic) | 1121 | Nepali
1068 | Azeri (Latin) | 3131 | Northern Sami (Finland)
1133 | Bashkir | 1083 | Northern Sami (Norway)
1069 | Basque | 2107 | Northern Sami (Sweden)
1059 | Belarusian | 1044 | Norwegian (Bokmal)
1093 | Bengali (India) | 2068 | Norwegian (Nynorsk)
2117 | Bengali (Bangladesh) | 1154 | Occitan
5146 | Bosnian (Latin) | 1096 | Oriya
8218 | Bosnian (Cyrillic) | 1123 | Pashto
1150 | Breton | 1065 | Persian
1026 | Bulgarian | 1045 | Polish
1027 | Catalan | 1046 | Portuguese (Brazil)
3076 | Chinese (Hong Kong S.A.R.) | 2070 | Portuguese (Portugal)
5124 | Chinese (Macau SAR) | 1094 | Punjabi
2052 | Chinese (PRC) | 3179 | Quechua (Peru)
4100 | Chinese (Singapore) | 2155 | Quechua (Ecuador)
1028 | Chinese (Taiwan) | 1131 | Quechua (Bolivia)
1155 | Corsican | 1048 | Romanian
1050 | Croatian (Croatia) | 1047 | Romansh
4122 | Croatian (Bosnia and Herzegovina) | 1049 | Russian
1029 | Czech | 1157 | Sakha
1030 | Danish | 1103 | Sanskrit
1164 | Dari | 2074 | Serbian (Latin)
1125 | Divehi | 3098 | Serbian (Cyrillic)
2067 | Dutch (Belgium) | 6170 | Serbian (Bosnia and Herzegovina)
1043 | Dutch (Netherlands) | 7194 | Serbian (Bosnia and Herzegovina)
3081 | English (Australia) | 1132 | Sesotho sa Leboa
10249 | English (Belize) | 1074 | Setswana
4105 | English (Canada) | 1115 | Sinhala
9225 | English (Caribbean) | 8251 | Skolt Sami
6153 | English (Ireland) | 1051 | Slovak
16393 | English (India) | 1060 | Slovenian
8201 | English (Jamaica) | 6203 | Southern Sami (Norway)
17417 | English (Malaysia) | 7227 | Southern Sami (Sweden)
5129 | English (New Zealand) | 21514 | Spanish (United States)
13321 | English (Philippines) | 2058 | Spanish (Mexico)
18441 | English (Singapore) | 3082 | Spanish (Spain)
7177 | English (South Africa) | 19466 | Spanish (Nicaragua)
11273 | English (Trinidad and Tobago) | 6154 | Spanish (Panama)
2057 | English (United Kingdom) | 15370 | Spanish (Paraguay)
1033 | English (United States) | 10250 | Spanish (Peru)
12297 | English (Zimbabwe) | 20490 | Spanish (Puerto Rico)
1061 | Estonian | 1034 | Spanish (Traditional Sort)
1080 | Faeroese | 4106 | Spanish (Guatemala)
1124 | Filipino | 14346 | Spanish (Uruguay)
1035 | Finnish | 8202 | Spanish (Venezuela)
2060 | French (Belgium) | 5130 | Spanish (Costa Rica)
3084 | French (Canada) | 7178 | Spanish (Dominican Republic)
1036 | French (France) | 9226 | Spanish (Colombia)
5132 | French (Luxembourg) | 11274 | Spanish (Argentina)
6156 | French (Monaco) | 12298 | Spanish (Ecuador)
4108 | French (Switzerland) | 13322 | Spanish (Chile)
1122 | Frisian | 16394 | Spanish (Bolivia)
1110 | Galician | 17418 | Spanish (El Salvador)
1079 | Georgian | 18442 | Spanish (Honduras)
3079 | German (Austria) | 2077 | Swedish (Finland)
1031 | German (Germany) | 1053 | Swedish (Sweden)
5127 | German (Liechtenstein) | 1114 | Syriac
4103 | German (Luxembourg) | 1089 | Swahili
2055 | German (Switzerland) | 1064 | Tajik
1032 | Greek | 2143 | Tamazight
1135 | Greenlandic | 1097 | Tamil
1095 | Gujarati | 1092 | Tatar
1128 | Hausa | 1098 | Telugu
1037 | Hebrew | 1054 | Thai
1081 | Hindi | 1105 | Tibetan
1038 | Hungarian | 1055 | Turkish
1039 | Icelandic | 1090 | Turkmen
1136 | Igbo | 1058 | Ukrainian
9275 | Inari Sami | 1070 | Upper Sorbian
1057 | Indonesian | 1056 | Urdu
1117 | Inuktitut (Syllabics) | 1152 | Uyghur
2141 | Inuktitut (Latin) | 1091 | Uzbek (Latin)
2108 | Irish | 2115 | Uzbek (Cyrillic)
1040 | Italian (Italy) | 1066 | Vietnamese
2064 | Italian (Switzerland) | 1106 | Welsh
1041 | Japanese | 1160 | Wolof
1099 | Kannada | 1076 | Xhosa
1087 | Kazakh | 1144 | Yi
1107 | Khmer | 1130 | Yoruba
1158 | K'iche | 1077 | Zulu
1159 | Kinyarwanda |  |

Sort order

This setting controls the sort order for lists and libraries. You can specify the sort order that you want to use for your SharePoint sites. You can change the sort order for a site by using the Regional Settings page. The following list shows the sort orders available in SharePoint Foundation 2010:

  • General

  • Albanian

  • Arabic

  • Azeri (Cyrillic)

  • Azeri (Latin)

  • Chinese (Traditional) Bopomofo

  • Chinese (Traditional) Stroke Count

  • Chinese Pronunciation

  • Chinese Stroke Count

  • Croatian

  • Cyrillic

  • Czech

  • Danish/Norwegian

  • Divehi

  • Estonian

  • Finnish/Swedish

  • French

  • Georgian Modern

  • German Phone Book

  • Greek

  • Hebrew

  • Hindi

  • Hong Kong Stroke Order

  • Hungarian

  • Hungarian Technical

  • Icelandic

  • Indic (General)

  • Japanese

  • Japanese Unicode

  • Kazakh

  • Korean

  • Korean Unicode

  • Latvian

  • Lithuanian

  • Lithuanian Classic

  • Macedonian (FYROM)

  • Polish

  • Romanian

  • Slovak

  • Slovenian

  • Spanish (Modern Sort)

  • Spanish (Traditional Sort)

  • Syriac

  • Tatar

  • Thai

  • Turkish

  • Ukrainian

  • Uzbek (Latin)

  • Vietnamese

Time zone

You can set the time zone for your SharePoint sites to one of the time zones shown in the following table. You can change the time zone for a Web site by using the Regional Settings page. For more information about how to set time zones, see Configure settings for a Web application (SharePoint Foundation 2010).

Note:

In the following table, time zones are based on their offset from Coordinated Universal Time, or UTC (Greenwich Mean Time).

Code | Time zones
39 | (UTC-12:00) International Date Line West
95 | (UTC-11:00) Coordinated Universal Time-11
16 | (UTC-11:00) Samoa
15 | (UTC-10:00) Hawaii
14 | (UTC-09:00) Alaska
13 | (UTC-08:00) Pacific Time (US and Canada)
78 | (UTC-08:00) Baja California
38 | (UTC-07:00) Arizona
77 | (UTC-07:00) Chihuahua, La Paz, Mazatlan
12 | (UTC-07:00) Mountain Time (US and Canada)
55 | (UTC-06:00) Central America
11 | (UTC-06:00) Central Time (US and Canada)
37 | (UTC-06:00) Guadalajara, Mexico City, Monterrey
36 | (UTC-06:00) Saskatchewan
35 | (UTC-05:00) Bogota, Lima, Quito
10 | (UTC-05:00) Eastern Time (US and Canada)
34 | (UTC-05:00) Indiana (East)
88 | (UTC-04:30) Caracas
91 | (UTC-04:00) Asuncion
9 | (UTC-04:00) Atlantic Time (Canada)
33 | (UTC-04:00) Georgetown, La Paz, Manaus, San Juan
81 | (UTC-04:00) Cuiaba
65 | (UTC-04:00) Santiago
28 | (UTC-03:30) Newfoundland
8 | (UTC-03:00) Brasilia
85 | (UTC-03:00) Buenos Aires
32 | (UTC-03:00) Cayenne, Fortaleza
60 | (UTC-03:00) Greenland
90 | (UTC-03:00) Montevideo
96 | (UTC-02:00) Coordinated Universal Time-02
30 | (UTC-02:00) Mid-Atlantic
29 | (UTC-01:00) Azores
53 | (UTC-01:00) Cape Verde Is.
86 | (UTC) Casablanca
93 | (UTC) Coordinated Universal Time
2 | (UTC) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London
31 | (UTC) Monrovia, Reykjavik
4 | (UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna
6 | (UTC+01:00) Belgrade, Bratislava, Budapest, Ljubljana, Prague
3 | (UTC+01:00) Brussels, Copenhagen, Madrid, Paris
57 | (UTC+01:00) Sarajevo, Skopje, Warsaw, Zagreb
69 | (UTC+01:00) West Central Africa
83 | (UTC+01:00) Windhoek
79 | (UTC+02:00) Amman
5 | (UTC+02:00) Athens, Bucharest, Istanbul
80 | (UTC+02:00) Beirut
49 | (UTC+02:00) Cairo
98 | (UTC+02:00) Damascus
50 | (UTC+02:00) Harare, Pretoria
59 | (UTC+02:00) Helsinki, Kyiv, Riga, Sofia, Tallinn, Vilnius
27 | (UTC+02:00) Jerusalem
7 | (UTC+02:00) Minsk
26 | (UTC+03:00) Baghdad
74 | (UTC+03:00) Kuwait, Riyadh
51 | (UTC+03:00) Moscow, St. Petersburg, Volgograd
56 | (UTC+03:00) Nairobi
25 | (UTC+03:30) Tehran
24 | (UTC+04:00) Abu Dhabi, Muscat
54 | (UTC+04:00) Baku
89 | (UTC+04:00) Port Louis
82 | (UTC+04:00) Tbilisi
84 | (UTC+04:00) Yerevan
48 | (UTC+04:30) Kabul
58 | (UTC+05:00) Ekaterinburg
87 | (UTC+05:00) Islamabad, Karachi
47 | (UTC+05:00) Tashkent
23 | (UTC+05:30) Chennai, Kolkata, Mumbai, New Delhi
66 | (UTC+05:30) Sri Jayawardenepura
62 | (UTC+05:45) Kathmandu
46 | (UTC+06:00) Novosibirsk
71 | (UTC+06:00) Astana, Dhaka
61 | (UTC+06:30) Yangon (Rangoon)
22 | (UTC+07:00) Bangkok, Hanoi, Jakarta
64 | (UTC+07:00) Krasnoyarsk
45 | (UTC+08:00) Beijing, Chongqing, Hong Kong S.A.R., Urumqi
63 | (UTC+08:00) Irkutsk
21 | (UTC+08:00) Kuala Lumpur, Singapore
73 | (UTC+08:00) Perth
75 | (UTC+08:00) Taipei
94 | (UTC+08:00) Ulaanbaatar
20 | (UTC+09:00) Osaka, Sapporo, Tokyo
72 | (UTC+09:00) Seoul
70 | (UTC+09:00) Yakutsk
19 | (UTC+09:30) Adelaide
44 | (UTC+09:30) Darwin
18 | (UTC+10:00) Brisbane
76 | (UTC+10:00) Canberra, Melbourne, Sydney
43 | (UTC+10:00) Guam, Port Moresby
42 | (UTC+10:00) Hobart
68 | (UTC+10:00) Vladivostok
41 | (UTC+11:00) Magadan, Solomon Is., New Caledonia
17 | (UTC+12:00) Auckland, Wellington
97 | (UTC+12:00) Coordinated Universal Time+12
40 | (UTC+12:00) Fiji
92 | (UTC+12:00) Petropavlovsk-Kamchatsky - Old
67 | (UTC+13:00) Nuku'alofa

Calendar

You can specify the type of calendar that you want to use as your primary calendar for your SharePoint sites. You can change the calendar for a Web site by using the Regional Settings page. The following list shows the calendars available in SharePoint Foundation 2010:

  • Gregorian

  • Japanese Emperor Era

  • Korean Tangun Era

  • Hijiri

  • Buddhist

  • Hebrew Jewish

  • Gregorian Middle East French Calendar

  • Gregorian Arabic Calendar

  • Gregorian Transliterated English Calendar

  • Gregorian Transliterated French Calendar

  • Saka Era

If you want to know the date in another calendar type, you can display an additional calendar next to your primary calendar.

Currency

You can set the currency for your SharePoint sites to any one of the currencies shown in the following table. The default value of the currency is determined by the locale that you specified in your regional settings, but users can change the value if they want. The currency is set on the Create Column page when you work with lists.

Note:

The currencies listed below are valid only when they are used with a locale that formats numbers by using a comma for digit grouping and a period as the decimal separator.

ID | Currency
1052 | 123,456.00 Lek (Albania)
5121 | 123,456.00 د.ج.‏ (Algeria)
11274 | $ 123,456.00 (Argentina)
1067 | 123,456.00 դր. (Armenia)
3081 | $123,456.00 (Australia)
3079 | € 123,456.00 (Austria)
1068 | 123,456.00 man. (Azerbaijan)
2092 | 123,456.00 ман. (Azerbaijan)
15361 | 123,456.00 د.ب.‏ (Bahrain)
1059 | 123,456.00 р. (Belarus)
2067 | € 123,456.00 (Belgium)
10249 | BZ$123,456.00 (Belize)
16394 | $b 123,456.00 (Bolivia)
1046 | R$ 123,456.00 (Brazil)
2110 | $123,456.00 (Bruni Darussalam)
1026 | 123,456.00 лв (Bulgaria)
3084 | 123,456.00 $ (Canada)
4105 | $123,456.00 (Canada)
13322 | $ 123,456.00 (Chile)
9226 | $ 123,456.00 (Columbia)
5130 | ₡123,456.00 (Costa Rica)
1050 | 123,456.00 kn (Croatia)
1029 | 123,456.00 Kč (Czech Republic)
1030 | kr 123,456.00 (Denmark)
7178 | RD$123,456.00 (Dominican Republic)
12298 | $ 123,456.00 (Ecuador)
3073 | 123,456.00 ج.م.‏ (Egypt)
17418 | $123,456.00 (El Salvador)
1061 | 123,456.00 kr (Estonia)
1080 | kr 123,456.00 (Faroe Islands)
1035 | 123,456.00 € (Finland)
1036 | 123,456.00 € (France)
1079 | 123,456.00 Lari (Georgia)
1031 | 123,456.00 € (Germany)
1032 | 123,456.00 € (Greece)
4106 | Q123,456.00 (Guatemala)
18442 | L. 123,456.00 (Honduras)
3076 | HK$123,456.00 (Hong Kong S.A.R.)
1038 | 123,456.00 Ft (Hungary)
1039 | 123,456.00 kr. (Iceland)
1081 | 123,456.00 (India)
1094 | 123,456.00 (India)
1095 | 123,456.00 (India)
1097 | 123,456.00 (India)
1098 | 123,456.00 (India)
1099 | 123,456.00 (India)
1057 | Rp123,456.00 (Indonesia)
1065 | 123,456.00 ريال (Iran)
2049 | 123,456.00 د.ع.‏ (Iraq)
6153 | € 123,456.00 (Ireland)
1040 | € 123,456.00 (Italy)
1037 | ₪ 123,456.00 (Israel)
8201 | J$123,456.00 (Jamaica)
1041 | ¥ 165;123,456.00 (Japan)
11265 | 123,456.00 د.ا.‏ (Jordan)
1087 | Т123,456.00 (Kazakhistan)
1089 | S123,456.00 (Kenya)
1042 | ₩123,456.00 (Korea)
13313 | 123,456.00 د.ك.‏ (Kuwait)
1088 | 123,456.00 сом (Kyrgyzstan)
1062 | Ls 123,456.00 (Latvia)
12289 | 123,456.00 ل.ل.‏ (Lebanon)
4097 | 123,456.00 د.ل.‏ (Libya)
5127 | CHF 123,456.00 (Liechtenstein)
1063 | 123,456.00 Lt (Lithuania)
5132 | 123,456.00 € (Luxembourg)
5124 | MOP123,456.00 (Macau S.A.R.)
1071 | 123,456.00 ден. (Macedonia (FYROM))
1086 | R123,456.00 (Malaysia)
1125 | 123,456.00 (Maldives)
2058 | $123,456.00 (Mexico)
6156 | 123,456.00 € (Monaco)
1104 | 123,456.00₮ (Mongolia)
6145 | 123,456.00 د.م.‏ (Morocco)
1043 | € 123,456.00 (Netherlands)
5129 | $123,456.00 (New Zealand)
19466 | C$ 123,456.00 (Nicaragua)
1044 | kr 123,456.00 (Norway)
8193 | 123,456.00 ر.ع.‏ (Oman)
1056 | Rs123,456.00 (Pakistan)
6154 | B/. 123,456.00 (Panama)
15370 | Gs 123,456.00 (Paraguay)
2052 | ￥123,456.00 (People's Republic of China)
10250 | S/. 123,456.00 (Peru)
13321 | Php123,456.00 (Philippines)
1045 | 123,456.00 zł (Poland)
2070 | 123,456.00 € (Portugal)
20490 | $ 123,456.00 (Puerto Rico)
16385 | 123,456.00 ر.ق.‏ (Qatar)
1048 | 123,456.00 lei (Romania)
1049 | 123,456.00р. (Russia)
1025 | 123,456.00 ر.س.‏ (Saudi Arabia)
2074 | 123,456.00 Din. (Serbia)
3098 | 123,456.00 Дин. (Serbia)
4100 | $123,456.00 (Singapore)
1051 | 123,456.00 Sk (Slovakia)
1060 | 123,456.00 SIT (Slovenia)
7177 | R 123,456.00 (South Africa)
3082 | 123,456.00 € (Spain)
1053 | 123,456.00 kr (Sweden)
2055 | SFr. 123,456.00 (Switzerland)
10241 | 123,456.00 ل.س.‏ (Syria)
1028 | NT$123,456.00 (Taiwan)
1054 | ฿123,456.00 (Thailand)
11273 | TT$123,456.00 (Trinidad and Tobago)
7169 | 123,456.00 د.ت.‏ (Tunisia)
1055 | 123,456.00 YTL (Turkey)
1058 | 123,456.00 грн. (Ukraine)
14337 | 123,456.00 د.إ.‏ (United Arab Emirates)
2057 | £163;123,456.00 (United Kingdom)
1033 | $123,456.00 (United States)
14346 | $U 123,456.00 (Uruguay)
1091 | 123,456.00 su'm (Uzbekistan)
2115 | 123,456.00 сўм (Uzbekistan)
8202 | Bs 123,456.00 (Venezuela)
1066 | 123,456.00 ₫ (Vietnam)
9217 | 123,456.00 ر.ي. (Yemen)
12297 | Z$123,456.00 (Zimbabwe)

See Also

Concepts

Language packs (SharePoint Foundation 2010)
Deploy language packs (SharePoint Foundation 2010)


Timer job reference (SharePoint Foundation 2010)

Published: July 8, 2010

This article describes the default timer jobs for SharePoint Foundation 2010. A timer job runs in a specific Windows service for SharePoint Foundation. Timer jobs also perform infrastructure tasks for the Timer service, such as clearing the timer job history and recycling the Timer service; and tasks for Web applications, such as sending e-mail alerts. A timer job contains a definition of the service to run and specifies how frequently the service is started. The SharePoint 2010 Timer service (SPTimerv4) runs timer jobs. Many features in SharePoint Foundation rely on timer jobs to run services according to a schedule.

In this article:

  • Manage timer jobs

  • Default timer jobs

Manage timer jobs

You can check the status of a timer job and edit the timer job definition.

For the general administration of all jobs, the SharePoint Central Administration Web site has a Timer Job Status page and a Job Definitions page. You can find these pages in Central Administration, on the Monitoring page, in the Timer Jobs section.

From the View menu, you can filter the timer jobs at the following levels:

  • All Displays all timer jobs for the farm.

  • Service Displays all the timer jobs for a particular service. If you select this command, use the Service menu to select the service by which you want to filter the listed jobs.

  • Web Application Displays all the timer jobs for a Web application. If you select this option, use the Web Application menu to select the Web application by which you want to filter the listed jobs.

  • Server Displays all the timer jobs for the specified server. If you select this command, use the Server menu to select the server by which you want to filter the listed jobs.

  • Job Definition Displays all the timer jobs for the specified job definition. On the Timer Job Status page, use the Job Definition menu to select the job definition by which you want to filter the listed jobs.

  • Failed Jobs Displays all the timer jobs on the farm that have failed to finish.

The SharePoint 2010 Timer service (SPTimerv4) is based on the Gregorian calendar for scheduling. For every job that you schedule, you specify when the timer job will run, specified in a 24-hour time format. You must specify the time in local time instead of as an offset from Coordinated Universal Time (UTC). The time is stored in that format. Daily, weekly, and monthly schedules also include a window of execution. The timer service will select a random time within this interval to start executing the job on each applicable server. This feature is appropriate for high-load jobs that run on multiple servers on the farm. Running this kind of job on all the servers at the same time might place an unreasonable load on the farm. Timer job schedules can be specified by using Windows PowerShell. For more information, see Timer jobs cmdlets (SharePoint Foundation 2010).

Default timer jobs

The following table lists the default timer jobs for SharePoint Foundation 2010.

Note:

Specific timer jobs and their schedules may differ from the following list depending on installed service pack version and cumulative updates (CUs). Before you install a SharePoint Foundation 2010 service pack or CU, you should make a record of existing timer jobs and schedules and check for differences after updating your farm.

Timer job title Description Schedule type

Application Addresses Refresh Job

Synchronizes connection information for remote service applications.

15 minutes

Audit Log Trimming

Trims audit trail entries from site collections.

Monthly

CEIP Data Collection

Gathers farm data for the Customer Experience Improvement Program.

Daily

Cell Storage Data Cleanup Timer Job

Deletes temporary cell storage data and frees SQL Server disk space.

Weekly

Cell Storage User Data Deletion Job

Deletes user data that is stored as cell storage. This job should only be run only if the SQL Server database server is running out of disk space.

Important:

This job can cause user data loss and does not run automatically by default.

Monthly

Change Log

Removes expired entries from the change log of the Web application.

Daily

Config Refresh

Checks the configuration database for configuration changes.

15 seconds

Content Organizer Processing

Processes documents in the drop-off library that match organizing rules.

Daily

Dead Site Delete

When auto site cleanup is enabled, sites that have not been used in a certain period of time are deleted.

Daily

Delete Job History

Deletes old entries from the timer job history.

Weekly

Diagnostic Data Provider: Event Log

Collects Windows Event Log entries and stores the data in the logging database.

10 minutes

Diagnostic Data Provider: Performance Counters - Database Servers

Collects Performance Monitor Counters data on database servers and stores the data in the logging database.

Important:

The timer service account must have sufficient permission to collect counters on the database server. The account should be a member of the Performance Monitor Users (PMU) group.

5 minutes

Diagnostic Data Provider: Performance Counters - Web Front Ends

Collects Performance Monitor Counters data on front-end Web servers and stores the data in the logging database.

5 minutes

Diagnostic Data Provider: SQL Blocking Queries

Collects data associated with blocked SQL queries and stores the data in the logging database.

15 seconds

Diagnostic Data Provider: SQL DMV

Collects SQL Dynamic Management Views (DMV) data and stores the data in the logging database.

30 minutes

Diagnostic Data Provider: Trace Log

Collects Trace Log entries and stores the usage data in the logging database and stores the data in the logging database.

10 minutes

Disk Quota Warning

Looks for sites that have exceeded the storage quota.

Weekly

Gradual Site Delete

Deletes all the data from the host content database for all deleted site collections.

Daily

Health Analysis Job (Daily, Central Administration, All Servers)

Runs SharePoint Health Analyzer jobs on all servers in the farm that run the Central Administration Web application and the Usage and Health Data Collection Service application.

Daily

Health Analysis Job (Daily, Central Administration, Any Server)

Runs SharePoint Health Analyzer jobs on all servers in the farm that run the Central Administration Web application and the Usage and Health Data Collection Service application.

Daily

Health Analysis Job (Daily, Microsoft SharePoint Foundation Timer, All Servers)

Runs SharePoint Health Analyzer jobs on the first server found in the farm that run the SharePoint Timer Service and the Usage and Health Data Collection Service application.

Daily

Health Analysis Job (Daily, Microsoft SharePoint Foundation Timer, Any Server)

Runs SharePoint Health Analyzer jobs on the first server found in the farm that runs the SharePoint Timer Service and the Usage and Health Data Collection Service application.

Daily

Health Analysis Job (Daily, Microsoft SharePoint Foundation Web Application, All Servers)

Runs SharePoint Health Analyzer jobs on all servers in the farm that run SharePoint Web applications and the Usage and Health Data Collection Service application.

Daily

Health Analysis Job (Daily, Microsoft SharePoint Foundation Web Application, Any Server)

Runs SharePoint Health Analyzer jobs on the first server found in the farm that runs SharePoint Web applications and the Usage and Health Data Collection Service application.

Daily

Health Analysis Job (Hourly, Claims Based Authentication, All Servers)

Runs SharePoint Health Analyzer jobs on all servers in the farm that run the Security Token Service (STS) and the Usage and Health Data Collection Service application.

Hourly

Health Analysis Job (Hourly, Microsoft SharePoint Foundation Timer, All Servers)

Runs SharePoint Health Analyzer jobs on all servers in the farm that run the SharePoint Timer Service and the Usage and Health Data Collection Service application.

Hourly

Health Analysis Job (Hourly, Microsoft SharePoint Foundation Timer, Any Server)

Runs SharePoint Health Analyzer jobs on the first server found in the farm that runs the SharePoint Timer Service and the Usage and Health Data Collection Service application.

Hourly

Health Analysis Job (Hourly, User Profile Service, Any Server)

Runs SharePoint Health Analyzer jobs on the first server found in the farm that runs Profile Services and the Usage and Health Data Collection Service application.

Hourly

Health Analysis Job (Monthly, Microsoft SharePoint Foundation Timer, Any Server)

Runs SharePoint Health Analyzer jobs on the first server found in the farm that runs the SharePoint Timer Service and the Usage and Health Data Collection Service application.

Monthly

Health Analysis Job (Weekly, Central Administration, All Servers)

Runs SharePoint Health Analyzer jobs on all servers in the farm that run the Central Administration Web site and the Usage and Health Data Collection Service application.

Weekly

Health Analysis Job (Weekly, Microsoft SharePoint Foundation Timer, All Servers)

Runs SharePoint Health Analyzer jobs on all servers in the farm that run the SharePoint Timer Service and the Usage and Health Data Collection Service application.

Weekly

Health Analysis Job (Weekly, Microsoft SharePoint Foundation Timer, Any Server)

Runs SharePoint Health Analyzer jobs on the first server found in the farm that runs the SharePoint Timer Service and the Usage and Health Data Collection Service application.

Weekly

Health Analysis Job (Weekly, Microsoft SharePoint Foundation Web Application, All Servers)

Runs SharePoint Health Analyzer jobs on all servers in the farm that run SharePoint Web applications and the Usage and Health Data Collection Service application.

Weekly

Health Analysis Job (Weekly, User Profile Service, Any Server)

Runs SharePoint Health Analyzer jobs on the first server found in the farm that runs Profile Services and the Usage and Health Data Collection Service application.

Weekly

Immediate Alerts

Sends out immediate and scheduled alerts.

5 minutes

Microsoft SharePoint Foundation Site Inventory Usage Collection

Collects site inventory information for each site collection in the farm.

Daily

Microsoft SharePoint Foundation Usage Data Import

Imports usage log files into the logging database.

30 minutes

Microsoft SharePoint Foundation Usage Data Processing

Checks for expired usage data at the farm level and deletes the data. Expired usage data consists of records in the central usage data collection database that are older than 30 days.

If the Web Analytics Service application is also installed, this timer job aggregates and writes the data to a Web Analytics Reporting database. You can run this timer job manually to force a check on expired data, or to force a usage data import to a Web Analytics application database.

Daily

Password Management

Sends e-mail and logs events for expiring passwords and password changes. This timer job helps ensure that managed passwords are changed before they expire.

Daily

Product Version Job

Checks the installation status of the computer and adds that data to the database.

Daily

Recycle Bin

Looks for content in the Recycle Bins and moves it to the next stage or deletes it.

Daily

Solution Daily Resource Usage Update

Marks the daily boundary for sandboxed solution resource quota monitoring.

Daily

Solution Resource Usage Log Processing

Aggregates resource usage data from sandboxed solution execution.

5 minutes

Solution Resource Usage Update

Records resource usage data from sandboxed solution execution, and sends e-mail to owners of site collections that are exceeding their allocated resource quota.

15 minutes

Timer Service Lock Management

Manages the content database locks that are used by the Timer Service to determine which server will run timer jobs for a content database.

1 minute

Timer Service Recycle

Recycles the Timer Service to free resources.

Daily

Upgrade Work Item Job

Processes deferred upgrade work items which were generated during a Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010 upgrade. For example, generating thumbnails for upgraded Image libraries.

Daily

Workflow

Processes workflow events that are in the scheduled items table, such as delays.

5 minutes

Workflow Auto Cleanup

Deletes tasks and instances in the workflow instance table for workflows that have been marked completed more than n days in the past, where n is specified in the workflow association. Crawls through tasks and the workflow instance table.

Daily

Workflow Failover

Processes events for workflows that have failed and are marked to be retried.

15 minutes


SharePoint 2010 Administration Toolkit (SharePoint Foundation 2010)

Published: July 15, 2010

This article provides information for farm administrators about the July 2010 release of the SharePoint Administration Toolkit version 1.0, which includes the following features:

  • The Load Testing Kit, which generates a Visual Studio Team System 2008 (VSTS) load test based on Windows SharePoint Services 3.0 IIS logs. The VSTS load test can be used to generate synthetic load against Microsoft SharePoint Foundation 2010 as part of a capacity planning exercise or a pre-upgrade stress test.

  • The Security Configuration Wizard (SCW) manifest, which add roles for SharePoint 2010 Products to Windows Server 2008 with Service Pack 2 or to Windows Server 2008 R2.

  • The User Profile Replication Engine, which provides a shared services administrator the ability to replicate user profiles and social data between shared services providers (SSP) in Office SharePoint Server 2007 and User Profile service applications in SharePoint Server 2010.

    Note:

    This tool is not supported for SharePoint Foundation 2010.

  • The Content Management Interoperability Services (CMIS) connector for Microsoft SharePoint Server 2010, which enables SharePoint users to interact with content stored in any repository that has implemented the CMIS standard, as well as making SharePoint 2010 content available to any application that has implemented the CMIS standard.

    Note:

    This is not supported for SharePoint Foundation 2010.

When you plan to install the entire toolkit, the SharePoint Administration Toolkit installer supports the use of a quiet installation using the /quiet switch. However, to script partial installations, the following command must be used to extract the Spat.msi from the SharePoint2010AdministrationToolkit.exe file:

SharePoint2010AdministrationToolkit.exe /extract:<path>

where path is the location of where the extracted files will reside.

The installation package is customizable and selectable, meaning that a user can control which tools are installed or uninstalled and can specify a custom installation folder for any tool.

The toolkit can be downloaded from the Microsoft SharePoint 2010 Administration Toolkit page (http://go.microsoft.com/fwlink/p/?LinkId=196866).

In this section:

  • Installing the SharePoint 2010 Administration Toolkit (SharePoint Foundation 2010)

  • Uninstalling the SharePoint 2010 Administration Toolkit (SharePoint Foundation 2010)

  • Load Testing Kit (SharePoint Foundation 2010)

  • Security Configuration Wizard manifest for SharePoint Foundation 2010


Installing the SharePoint 2010 Administration Toolkit (SharePoint Foundation 2010)
See Also

Published: July 15, 2010

This article describes how to install the SharePoint 2010 Administration Toolkit.

The SharePoint Administration Toolkit requires Microsoft SharePoint Foundation 2010 to be installed. Membership in the following groups is required to install each tool:

  • Load Testing Kit, Security Configuration Wizard (SCW) manifest, Content Management Interoperability Services (CMIS) connector: Farm administrator and local administrator

  • User Profile Replication Engine: Local administrator only

    Note:

    The User Profile Replication Engine tool is only available by using Windows PowerShell cmdlets. Verify that you meet the following minimum requirements: See Add-SPShellAdmin. Also, on a Windows Server 2008-based computer, if User Access Control (UAC) is enabled, you must elevate the permission of this tool to Run as Administrator. For additional information about User Access Control, see User Account Control Step-by-Step Guide.

    The User Profile Replication Engine and the Content Management Interoperability Services connector are not supported for Microsoft SharePoint Foundation 2010.

To install the SharePoint 2010 Administration Toolkit

  1. From the Microsoft SharePoint 2010 Administration Toolkit page (http://go.microsoft.com/fwlink/p/?LinkId=196866), download the SharePoint2010AdministrationToolkit.exe file by clicking the Download button, and then save the file to your hard disk.

  2. Double-click the SharePoint2010AdministrationToolkit.exe program file on your hard disk to start the Setup program.

  3. After the License Terms for Microsoft Software is accepted, click Next.

  4. Select which tool or tools are to be installed by choosing the appropriate icon and select the top-level feature ("This feature will be installed on local hard drive").

  5. Click Browse to change the location of this folder. After a location is selected, click OK, and then click Next.

    The default folder location is %ProgramFiles%\Microsoft\SharePoint 2010 Administration Toolkit.

  6. To complete installation, click Finish.

See Also

Concepts

Uninstalling the SharePoint 2010 Administration Toolkit (SharePoint Foundation 2010)


Uninstalling the SharePoint 2010 Administration Toolkit (SharePoint Foundation 2010)

Published: July 15, 2010

This article describes how to uninstall the entire SharePoint 2010 Administration Toolkit or how to uninstall a specific tool.

To uninstall the SharePoint 2010 Administration Toolkit

  1. From Programs and Features, select the Microsoft SharePoint 2010 Administration Toolkit and click Uninstall.

    Note:

    The same dialog box is displayed if you run the SharePoint2010AdministrationToolkit.exe file instead of using Programs and Features.

  2. Click Finish.

To uninstall a specific tool from the SharePoint 2010 Administration Toolkit

  1. From Programs and Features, select the Microsoft SharePoint 2010 Administration Toolkit and click Change.

    Note:

    The same dialog box is displayed if you run the SharePoint2010AdministrationToolkit.exe file instead of using Programs and Features.

  2. Select the tool you want to remove.

  3. Click Next, and then click Finish.


Security Configuration Wizard manifest for SharePoint Foundation 2010
See Also

Published: July 15, 2010

This article provides information about how to register the Security Configuration Wizard (SCW) manifest that is included in the Microsoft SharePoint 2010 Administration Toolkit. The SCW manifest adds roles for Microsoft SharePoint Foundation 2010 to Windows Server 2008 Service Pack 2 or to Windows Server 2008 R2.

Note:

These roles are specific roles that you create in SCW after you have installed the SharePoint Foundation SCW manifest, and not the server roles to configure Windows features in Server Manager.

SCW is an attack surface reduction tool introduced with Windows Server 2003 Service Pack 1. SCW uses a roles-based metaphor to solicit the functionality required for a server and disables the functionality that is not required. By automating this security best practice, SCW helps to create Windows environments that are less susceptible, on the whole, to security vulnerabilities that have been exploited.

For more information about SCW in Windows Server 2008, see Security Configuration Wizard (http://go.microsoft.com/fwlink/p/?LinkId=185511).

The SCW manifest for Microsoft SharePoint Foundation 2010 is included in the SharePoint 2010 Administration Toolkit. Different versions of the manifest are included for Windows Server 2008 Service Pack 2 and Windows Server 2008 R2.

Before you perform these procedures, confirm that:

  • You have installed the SharePoint 2010 Administrator Toolkit.

  • You are running Windows Server 2008 with Service Pack 2 or Windows Server 2008 R2.

  • You have administrator permission for the Command Prompt window.

Register the SCW manifest

Perform the following procedure to register the SCW manifest.

To register the Microsoft SharePoint Foundation 2010 SCW manifest

  1. Open a Command Prompt window.

    Note:

    If you have User Account Control (UAC) turned on in Windows, you might be prompted to run as administrator.

  2. At the command prompt, type cd C:\Program Files\Microsoft\SharePoint 2010 Administration Toolkit\SCWManifests, or type the location where you installed the SharePoint 2010 Administration Toolkit.

  3. Register the Microsoft SharePoint Foundation 2010 SCW manifest:

    • If you are using Windows Server 2008 Service Pack 2, type scwcmd register /kbname:SPF2010 /kbfile:SPF2010W2K8.xml and press ENTER.

    • If you are using Windows Server 2008 R2, type scwcmd register /kbname:SPF2010 /kbfile:SPF2010W2K8R2.xml and press ENTER.

You can now run the SCW to create a security policy that incorporate the roles for SharePoint Foundation 2010.

See Also

Concepts

SharePoint 2010 Administration Toolkit (SharePoint Foundation 2010)

Other Resources

Security Configuration Wizard Documentation


Load Testing Kit (SharePoint Foundation 2010)

Published: July 15, 2010

This article provides a basic overview of and how-to steps for the Load Testing Kit (LTK) of the Microsoft SharePoint 2010 Administration Toolkit.

Overview

The Load Testing Kit (LTK) lets an administrator simulate a synthetic load test against a Microsoft SharePoint Foundation 2010 farm. The goal of the tool is to assist an administrator to certify that an existing Windows SharePoint Services 3.0 topology running on specific hardware can sustain an upgrade to a Microsoft SharePoint Foundation 2010 farm, with the same load.

The Load Testing Kit is a command-line tool that will use information from a Windows SharePoint Services 3.0 production farm as a baseline. There are three steps to perform a load test:

  1. Collect logs.

  2. Prepare data for analysis.

  3. Use the project file to generate a synthetic load.

To install the Load Testing Kit, you must be a local administrator on the any x64-based computer. The files for the Load Testing Kit are installed in the following folder: %ProgramFiles%\Microsoft\SharePoint 2010 Administration Toolkit\Load Testing Kit. The Load Testing Kit includes the following files: Prerequisitecollector.exe, Prerequisitecollector.exe.config, Ltk.exe, and Microsoft.Office.Server.AdministrationToolkit.LoadTestingKitIntl.dll. These files must be copied from the installation folder to any server on the Windows SharePoint Services 3.0 farm.

To use the tool, you need to be a member of the Farm Administrators SharePoint group on both the Windows SharePoint Services 3.0 (original production) and SharePoint Foundation 2010 (upgraded) farms. Also, the LTK.exe file must be run on a computer where SharePoint 2010 Products is installed.

Collect logs

The first step is to gather all the Internet Information Services (IIS) logs on the Windows SharePoint Services 3.0 computer and to determine the Web application-to-ID mapping. This is performed by running the Prerequisitecollector.exe file.

The administrator needs to choose a server in the farm to act as a baseline, and then install the Prerequisitecollector.exe file onto that server.

Note:

The Prerequisitecollector.exe file must be copied to the physical computer in the Windows SharePoint Services 3.0 farm; otherwise, an error message is displayed.

The Prerequisitecollector.exe file contains one parameter, TargetFolder. The TargetFolder parameter specifies the location where the IIS logs of Windows SharePoint Services 3.0 will be stored.

The Prerequisitecollector tool will copy all the IIS logs available in the default source locations. The size of the IIS log files can be very large, so we recommend to check for log file sizes and plan accordingly. If the sizes of the IIS logs are too large, the size can be reduced by using the LogParser.exe or any comparable tool before or after they are being copied.

Typically, the time period needed to collect a complete set of IIS logs is 24 hours.

Prepare data for analysis

Once the IIS log files are captured, use the Load Testing Kit application (Ltk.exe) to prepare the data for analysis.

Note:

The Visual Studio Team System (VSTS) product and Microsoft Visual Studio 2008 Service Pack 1 must be installed before the Ltk.exe is run. Also, some knowledge of how to use VSTS is required. To install the Visual Studio Team System (VSTS), see Visual Studio Team System 2008 Team Suite (http://go.microsoft.com/fwlink/p/?LinkID=101641).

To install Service Pack1, see Microsoft Visual Studio 2008 Service Pack 1 (http://go.microsoft.com/fwlink/p/?LinkID=116488).

The Ltk.exe file generates a VSTS-ready project file, which includes default Web Tests (*.WebTest) and comma-separated value (*.csv) parameter files.

To analyze log files, type the following syntax:

ltk.exe -source LTKSource -output VSSolution -userlist users.csv

Ltk.exe syntax

ltk.exe -source <source directory>

-output <output directory>

-userlist <userlist file>

[-userrolefixup]

[-debugmatchrules <rule1;rule2;rule3>]

Parameters

Parameter name | Value | Required? | Description
source | A valid directory, for example, IISLogs | Yes | Specifies the folder containing the IIS log files that were collected from the Windows SharePoint Services 3.0-based computer using the Prerequisitecollector.exe file.
output | A valid directory, for example, VSSolution | Yes | Specifies the folder for the Load Testing Kit output file, which is a project file that contains all Visual Studio files and .csv files.
userlist | A valid location where the .csv file is stored, for example, C:\users.csv | Yes | Specifies a .csv file that has at least three columns: Username, Password, and Permission. The .csv file contains all the users that you created in the test domain and the permissions that they are supposed to represent. There should be at least one user for each permission. Valid permission values are FullRead and FullControlWithoutAdmin.
userrolefixup | <none> | No | Grants permissions specified in the userlist parameter by adding the users to the target Web application's permission policy.
debugmatchrules | A valid rule that is used for querying log files. | No | Generates a verbose log that maps which IIS logs entries matched each rule. These match rules are contained in the MatchRules section of the WebTestsConfiguration.xml file located in the %ProgramFiles%\Microsoft\SharePoint 2010 Administration Toolkit\Load Testing Kit directory. This parameter is only for advanced debugging purposes.

For example, to use userlist parameter to add a user name "testacct" with the FullControlWithoutAdmin permission, use the following values:

Username | Password | Permission
Domain\testacct | Password | FullControlWithoutAdmin

For example, to use userlist parameter to add a user name "testacct" with the FullRead permission, use the following values:

Username | Password | Permissioin
Domain\testacct | Password | FullRead

Use the project file to generate a synthetic load

Once the project file has been generated, the final step is to use VSTS to open and use the project file. For more information about how to use a VSTS project file, see Getting Started with Load and Web Performance Test Walkthroughs (http://go.microsoft.com/fwlink/p/?LinkId=196791).


Conformance statement A-level (SharePoint Foundation 2010)

Published: July 22, 2010

Conformance statement for Microsoft SharePoint Foundation 2010 in regards to Web Content Accessibility Guidelines 2.0 (http://www.w3.org/TR/WCAG20/).

Conformance statement for configuration and administration experience at A-level

Claim | Details
Date of the claim | May 12th, 2010
Guidelines title, version, and URI | Web Content Accessibility Guidelines 2.0 (http://www.w3.org/TR/2008/REC-WCAG20-20081211/)
Conformance level satisfied: (Level A, AA or AAA) | A
A concise description of the Web pages, such as a list of URIs for which the claim is made, including whether subdomains are included in the claim. | Default content included with SharePoint Foundation 2010 and Administration and Configuration features of SharePoint Foundation 2010. For other product features, see Conformance statement AA-level (SharePoint Foundation 2010).
A list of the Web content technologies relied upon. | HTML JavaScript CSS
Additional Web content technologies used, but not relied upon. | ARIA Silverlight RSS PNG GIF JPEG
A list of success criteria beyond the level of conformance claimed that have been met. This information should be provided in a form that users can use, preferably machine-readable metadata. | Conforms to 1.4.9 Images of Text (No Exception) - AAA. Conforms to 2.1.3 Keyboard (No Exception) - AAA. Conforms to 2.2.3 No Timing (No Exception) - AAA. Conforms to 2.3.2 Three Flashes - AAA. Conforms to 2.4.8 Location - AAA. Conforms to 3.3.6 Error Prevention (All) - AAA.

This conformance statement pertains to SharePoint Foundation 2010.

Customization of the product voids this conformance statement from Microsoft. Customers may make independent conformance statements if they have conducted due diligence to meet all relevant requirements for their customization.

Please consult with Assistive Technology (AT) vendors for compatibility specifications of specific AT products. AT products that are compatible with all the rely-upon-technologies are expected to be functional with the product.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Revised 07/22/2010.

Microsoft regularly updates its websites and provides new information about the accessibility of products as that information becomes available.


Conformance statement AA-level (SharePoint Foundation 2010)

Published: July 22, 2010

Conformance statement for Microsoft SharePoint Foundation 2010 in regards to Web Content Accessibility Guidelines 2.0 (http://www.w3.org/TR/WCAG20/).

Conformance statement for core reader, author, and contributor experience at AA-level

Claim | Details
Date of the claim | May 12th, 2010
Guidelines title, version, and URI | Web Content Accessibility Guidelines 2.0 (http://www.w3.org/TR/2008/REC-WCAG20-20081211/)
Conformance level satisfied: (Level A, AA or AAA) | AA
A concise description of the Web pages, such as a list of URIs for which the claim is made, including whether subdomains are included in the claim. | All default content included with SharePoint Foundation 2010 and Web application features of SharePoint Foundation 2010 except where limited by Conformance statement A-level (SharePoint Foundation 2010).
A list of the Web content technologies relied upon. | HTML JavaScript CSS
Additional Web content technologies used, but not relied upon. | ARIA Silverlight RSS PNG GIF JPEG
A list of success criteria beyond the level of conformance claimed that have been met. This information should be provided in a form that users can use, preferably machine-readable metadata. | Conforms to 1.4.9 Images of Text (No Exception) - AAA. Conforms to 2.1.3 Keyboard (No Exception) - AAA. Conforms to 2.2.3 No Timing (No Exception) - AAA. Conforms to 2.3.2 Three Flashes - AAA. Conforms to 2.4.8 Location - AAA. Conforms to 3.3.6 Error Prevention (All) - AAA.

This conformance statement pertains to SharePoint Foundation 2010.

Customization of the product voids this conformance statement from Microsoft. Customers may make independent conformance statements if they have conducted due diligence to meet all relevant requirements for their customization.

Please consult with Assistive Technology (AT) vendors for compatibility specifications of specific AT products. AT products that are compatible with all the rely-upon-technologies are expected to be functional with the product.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Revised 07/22/2010.

Microsoft regularly updates its websites and provides new information about the accessibility of products as that information becomes available.


Settings and features backed up from a farm configuration (SharePoint Foundation 2010)
See Also

Published: August 12, 2010

This article describes the settings and features that are included in a backup of a server farm configuration. For more information about how to back up a farm configuration, see Back up a farm configuration (SharePoint Foundation 2010).

Settings and features backed up

The following table lists the settings and features that are included in a backup of the configuration of a server farm, and the pages on the SharePoint Central Administration Web site where you can access these settings and features.

Setting or feature Description

Managed account password settings

_Admin/PasswordSettings.aspx

Outgoing e-mail settings

_Admin/globalemailconfig.aspx

Note:

Outgoing e-mail settings are restored only when content and settings are restored to their original locations on the same farm they were backed up from.

  • When you use Central Administration to restore a farm, on the Restore from Backup — Step 2 of 3: Select Restore Options page, in the Restore Options section, select the Type of Restore option, and use the Same configuration setting.

  • When you use the Windows PowerShell Restore-SPFarm cmdlet to restore a farm, use the RestoreMethod parameter to specify overwrite.

Note:

Outgoing e-mail settings are restored only when content and settings are restored to their original server location in the same farm. If you are restoring the configuration and content to a different farm, you are prompted to specify new configuration settings.

Solutions deployed to the farm (trusted solutions)

_Admin/Solutions.aspx

Solutions that are deployed to the farm.

InfoPath Forms Services

_Admin/IpfsConfig.aspx

The list of user agents that are added to a farm.

Web application service

Settings that are shared by all content Web applications.

  • Active Directory Domain Services (AD DS) account creation mode settings

  • Antivirus settings _Admin/AVAdmin.aspx

  • Quota templates _Admin/ManageQuotaTemplate.aspx

  • Information Rights Management (IRM) settings _Admin/IrmAdmin.aspx

  • Managed paths for host-named site collections

Sandboxed solutions service

Solution restrictions and load balancing settings.

Diagnostic logging settings

_Admin/Metrics.aspx

All diagnostic logging settings are backed up except the trace log location.

See Also

Reference

Restore-SPFarm

Concepts

Restore a farm configuration (SharePoint Foundation 2010)
Change passwords used for administration accounts (SharePoint Foundation 2010)
Configure outgoing e-mail (SharePoint Foundation 2010)
Create, edit, and delete quota templates (SharePoint Foundation 2010)
Define managed paths (SharePoint Foundation 2010)
Configure load balancing for sandboxed solutions (SharePoint Foundation 2010)
Block or unblock a sandboxed solution (SharePoint Foundation 2010)
Configure diagnostic logging (SharePoint Foundation 2010)

Other Resources

Get-SPInfoPathUserAgent


Peoplepicker-peopleeditoronlyresolvewithinsitecollection: Stsadm property (SharePoint Foundation 2010)

Published: February 3, 2011

Checks the user against the existing site collection users.

Note:

This operation was added in Microsoft SharePoint Foundation 2010.

Syntax

The syntax for the setproperty operation is:

stsadm -o setproperty

-propertyname peoplepicker-peopleeditoronlyresolvewithinsitecollection

-propertyvalue {Yes | No}

[-url] <URL>

The syntax for the getproperty operation is:

stsadm -o getproperty

propertyname peoplepicker-peopleeditoronlyresolvewithinsitecollection

[-url] <URL>

Note:

You can substitute -pn for -propertyname and -pv for -propertyvalue.

Parameters

Name | Value
propertyname | Gets or sets the name of the property.
propertyvalue | Yes: Resolves only against the existing site collection users. No: Resolves users against the existing site collection users and users from other identity providers, for example, Active Directory Domain Services.
url | Typically a path to the URL of the Web application, in the form http://server_name.

Examples

Display users within a site collection

If you want to display users only from a specific site collection, use the following syntax:

stsadm -o setproperty -url http://<server> -pn peoplepicker- peoplepicker-peopleeditoronlyresolvewithinsitecollection -pv yes

If you want to display any user from an existing site collection, use the following syntax:

stsadm -o setproperty -url http://<server_name> -pn peoplepicker- peopleeditoronlyresolvewithinsitecollection -pv no

To view the current setting for the peopleeditoronlyresolvewithinsitecollection property, use the following syntax:

stsadm -o getproperty -pn peoplepicker- peopleeditoronlyresolvewithinsitecollection


D sf
See Also

7/26/2011

Scope | Token
project | Microsoft SharePoint Foundation 2010
database | Microsoft SharePoint Foundation 2010

See Also

Other Resources

D misc
D ss
D ps
D srch
D or
D gr


Set-SPCustomLayoutsPage
See Also Example
[image]

Published: May 12, 2010

Maps a new path for a custom layout page.

Set-SPCustomLayoutsPage -Identity <None | AccessDenied | Confirmation | Error | Login | RequestAccess | Signout | WebDeleted> -RelativePath <String> -WebApplication <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]
Set-SPCustomLayoutsPage -Identity <None | AccessDenied | Confirmation | Error | Login | RequestAccess | Signout | WebDeleted> -Reset <SwitchParameter> -WebApplication <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-WhatIf [<SwitchParameter>]]

Parameters

1

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.Administration.SPWebApplication+SPCustomPage

Specifies the custom layout page to set.

The type must be one of the following: None, AccessDenied, Confirmation, Error, Login, RequestAccess, Signout, or WebDeleted.

RelativePath

Required

System.String

Specifies the path of the custom layout page.

The type must be a valid path of a layout page, in the form _layouts/custompages/myaccessdenied.aspx.

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the SharePoint Web application that contains the custom layout page.

The type must be a valid URL, in the form http://server_name; a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of SharePoint Web application (for example, MyOfficeApp1); or an instance of a valid SPWebApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

2

Parameter

Required

Type

Description

Identity

Required

Microsoft.SharePoint.Administration.SPWebApplication+SPCustomPage

Specifies the custom layout page to set.

The type must be one of the following: None, AccessDenied, Confirmation, Error, Login, RequestAccess, Signout, or WebDeleted.

Reset

Required

System.Management.Automation.SwitchParameter

Resets the mapping of a custom layouts page.

WebApplication

Required

Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind

Specifies the SharePoint Web application that contains the custom layout page.

The type must be a valid URL, in the form http://server_name; a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh; a valid name of SharePoint Web application (for example, MyOfficeApp1); or an instance of a valid SPWebApplication object.

AssignmentCollection

Optional

Microsoft.SharePoint.PowerShell.SPAssignmentCollection

Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used.

Note:

When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.

Confirm

Optional

System.Management.Automation.SwitchParameter

Prompts you for confirmation before executing the command. For more information, type the following command: get-help about_commonparameters

WhatIf

Optional

System.Management.Automation.SwitchParameter

Displays a message that describes the effect of the command instead of executing the command. For more information, type the following command: get-help about_commonparameters

Detailed Description

This cmdlet contains more than one parameter set. You may only use parameters from one parameter set, and you may not combine parameters from different parameter sets. For more information about how to use parameter sets, see Cmdlet Parameter Sets.

The Set-SPCustomLayoutsPage cmdlet maps a new path for a custom layouts page in a Web application. To remove the mapping for a custom layouts page, use the Reset parameter instead of the RelativePath parameter.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Set-SPCustomLayoutsPage -Identity "_layouts/accessdenied.aspx" -RelativePath "/_layouts/custompages/myaccessdenied.aspx" -WebApplication "http://server_name/mywebapp"

This example maps the specified path for the AccessDenied layout page in the Web application "http://server_name/mywebapp".

See Also

Reference

Get-SPCustomLayoutsPage


Receive-SPServiceApplicationConnectionInfo
Example
[image]

Published: May 12, 2010

Configures this farm to receive service information from another farm.

Receive-SPServiceApplicationConnectionInfo [-FarmUrl] <Uri> [-AssignmentCollection <SPAssignmentCollection>] [-Filter <String>]

Parameters

Parameter | Required | Type | Description
FarmUrl | Required | System.Uri |
AssignmentCollection | Optional | Microsoft.SharePoint.PowerShell.SPAssignmentCollection |
Filter | Optional | System.String |

Detailed Description

The Receive-SPServiceApplicationConnectionInfo cmdlet retrieves the list of service applications published by another farm.

Input Types

Return Types

Example

------------------EXAMPLE-----------------------

Copy Code
Receive-SPServiceApplicationConnectionInfo -FarmUrl http://FarmB/topology/topology.svc

This example retreives a list of service applications published by a given farm.

The FarmURL parameter can be obtained by the Get-SPTopologyServiceApplication cmdlet.


Health monitoring overview (SharePoint Foundation 2010)
See Also

Microsoft SharePoint Foundation 2010 includes an integrated health analysis tool called SharePoint Maintenance Manager that allows SharePoint Foundation to automatically check for potential configuration, performance, and usage problems. As a farm administrator, you can configure specific health reporting jobs to do the following:

  • Run on a predefined schedule

  • Alert you when problems are found

  • Formulate reports that can be used for performance monitoring, capacity planning, and troubleshooting

This article explains the basic structure and functionality of SharePoint Maintenance Manager, and tells you when to use this tool to monitor activity in a SharePoint server farm. For details about configuring and running individual health rules and jobs, see Health Monitoring Technical Reference.

How SharePoint Maintenance Manager works

SharePoint Maintenance Manager runs predefined health rules against servers in the farm. Third-party health rules can be added to the rule set.

A health rule runs a test and returns a status that tells you the outcome of the test. Possible results are listed in the following table.

Test Status Meaning

Success

SharePoint Maintenance Manager ran the test and discovered no issues.

Fixed

SharePoint Maintenance Manager ran the test, discovered an issue, and applied the appropriate software solution to remedy the issue. The issue was successfully resolved.

Failure

SharePoint Maintenance Manager did not run the test, or the test ran successfully but did not resolve a discovered issue.

Issue Detected

The test discovered an issue but did not attempt to fix the issue because of the health rule setting. A severity level is displayed together with a description of the discovered issue. Severity levels are as follows:

  • Critical Error

  • Warning

  • Informative

Important:

Be aware that if a rule is run against multiple servers, a "Success" result is possible only after all servers have reported success.

Using health rule status information

When any rule fails, the status is written to the Maintenance Problems list in SharePoint Server and to the Windows Event log. The Microsoft System Center Operations Manager Management Pack can also detect and display issues discovered by SharePoint Maintenance Manager.

You can also export rule status indicators to an XML file for additional analysis or assistance.

Scheduling health rules

A health rule can be run on a defined schedule, or on an impromptu basis. All health rules are available through the SharePoint Central Administration Web site, on the Monitoring page, for either immediate or scheduled execution.

Health rule categories

Each health rule falls in one of the following categories:

  • Security

  • Performance

  • Configuration

  • Availability

Configuring health rules

Each health rule has configurable parameters, which are described in the following table.

Parameter | Possible Values
Title | The name of the health rule. You can rename a health rule to clarify its functionality.
Scope | You can set a health rule to run against a single server, all servers or any server. If set to any server, the rule will run on the first available server that it encounters.
Schedule | You can schedule a health rule to run Hourly, Daily, Weekly, Monthly, or On Demand Only.
Enabled | You can use this switch to enable or disable a health rule.
Repair Automatically | You can define whether a health rule automatically tries to recover from any error conditions that it finds. If this parameter is set to No and an issue is discovered, the resultant status will be Issue Detected. If this parameter is set to Yes and an issue is discovered, a successful resolution to the issue will result in a status of Fixed; an unresolved issue in this case will result in a status of Failure.
Version | This version history enables you to track the metadata changes performed on each rule. The version number is updated every time the rule is saved.

You can accept each health rule's default settings, or change the rule's behavior by reconfiguring these settings.

Health analysis timer jobs

Scheduled health rules are collected and listed in Central Administration, on the Monitoring page, in the Timer Jobs section. For example, all health rules that are configured to run against all servers on a daily basis are collected into one batch job named Health Analysis Job (Daily, Central Administration, All).

For more information about timer jobs, see Manage SharePoint timer jobs

Health analysis reports

You can generate health analysis reports in Central Administration, on the Monitoring Reports page, and you can generate custom reports by extracting stored usage data or by connecting to the database directly by means of SQL Server Reporting Services.

Using PowerShell commands with SharePoint Maintenance Manager

SharePoint Maintenance Manager accepts PowerShell instructions at the command prompt to do the following:

  • Initiate health analysis timer jobs

  • Extract health monitoring data

  • Run individual health rules

See Also

Other Resources

Resource Center: What's New in SharePoint Foundation 2010


Windows PowerShell for SharePoint 2010 Products and related products

The following sections contain the most current reference content for product-specific Windows PowerShell cmdlets:

  • Windows PowerShell for SharePoint Foundation 2010 reference

  • Windows PowerShell for SharePoint Server 2010 reference

  • Windows PowerShell for Search Server 2010 reference

  • Windows PowerShell for Office Web Apps reference