Share Point

Contents
SharePoint Server
SharePoint Updates
Accessibility guidelines
What's new
SharePoint Server 2019
New and improved features in SharePoint Server 2019
What's deprecated or removed from SharePoint Server 2019
New features in Feature Pack 1
New feature in Feature Pack 2
What's deprecated or removed from SharePoint Server 2016
Getting started
Security for SharePoint Server
Plan for administrative and service accounts
Automatic password change planning
Authentication overview
Plan user authentication
Plan server-to-server authentication
Server-to-server authentication and user profiles
Kerberos authentication planning
Plan for app authentication in SharePoint Server
Create claims-based web applications in SharePoint Server
Create web applications that use classic mode authentication in SharePoint Server
Implement SAML based authentication in SharePoint Server
Migration of Windows claims authentication to SAML based claims authentication
in SharePoint Server
Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocol support in
SharePoint Server
Enable TLS and SSL support in SharePoint 2013
Enable TLS 1.1 and TLS 1.2 support in SharePoint Server 2016
Security hardening
Plan for least-privileged administration
Configure SQL Server security for SharePoint environments
Federal Information Processing Standard security standards
Install
Install for SharePoint Server 2019
System requirements for SharePoint Servers 2016 and 2019
Hardware and software requirements
Browser support planning
Install SharePoint Servers 2016 or 2019 on one server
Install SharePoint Servers 2016 or 2019 across multiple servers
Install or uninstall language packs
Add a server to a SharePoint Server 2016 or SharePoint 2019 farm
Install for SharePoint Server 2016
System requirements for SharePoint Servers 2016 and 2019
Software boundaries and limits
Prerequisites
Initial deployment administrative and service accounts in SharePoint Server
Account permissions and security settings in SharePoint Servers 2016 and 2019
Install prerequisites from network share
Overview of MinRole Server Roles in SharePoint Server
Planning for a MinRole server deployment in SharePoint Server
Install SharePoint Servers 2016 or 2019 across multiple servers
Add a server to a SharePoint Server farm
Install for SharePoint 2013
System requirements for SharePoint 2013
IP support
Software boundaries and limits
Capacity management and sizing overview
Prerequisites
Account permissions and security settings in SharePoint 2013
Installation and configuration overview
Single server with a built-in database
Single server with SQL Server
Multiple servers for a three-tier farm
Add web or application server to the farm
Add a database server to an existing farm
Best Practices for SharePoint Server installation
Deploying on virtual machines
Configure
Configure client certificate authentication
Configure syncing with the new OneDrive sync client
User Profile service overview
Create a User Profile service application
My Sites overview
My Sites planning
Configure My Sites
Upgrade and Update
Upgrade from SharePoint 2013 to SharePoint Server 2019
Upgrade to SharePoint Server 2019
Get started with upgrade
Overview of the upgrade process
Overview of the services upgrade process
Upgrade databases
Create the SharePoint Server 2019 farm for a database attach upgrade
Copy databases to the new farm for upgrade to SharePoint Server 2019
Upgrade service applications to SharePoint Server 2019
Upgrade content databases
Verify upgrade for databases
Upgrade a site collection
Upgrade My Sites
Overview of the upgrade process
Overview of the services upgrade process
Best practices for upgrade
Upgrade databases
Upgrade content databases
Verify upgrade for databases
Upgrade site collections
Upgrade My Sites
Video: Cleanup of databases after upgrade procedure
Deploy updates for SharePoint Server 2016
Software updates overview
Install a software update
Video demo of Zero Downtime Patching in SharePoint Server 2016
SharePoint Server 2016 zero downtime patching steps
Video: How to enable Remote Windows PowerShell to use with SharePoint Server
Upgrade from SharePoint 2010 to SharePoint 2013
What's new in SharePoint 2013 upgrade
Overview of the upgrade process from SharePoint 2010 to SharePoint 2013
Upgrade overview videos for SharePoint 2013
Services upgrade overview from SharePoint 2010 to SharePoint Server 2013
Upgrade farms that share services (parent and child farms) to SharePoint 2013
Best practices for upgrading from SharePoint 2010 to SharePoint 2013
Review supported editions and products for upgrading to SharePoint 2013
Plan for upgrade
Determine strategy for upgrade to SharePoint 2013
Create a plan for current customizations during upgrade to SharePoint 2013
Plan for site collection upgrades in SharePoint 2013
Create a communication plan for the upgrade to SharePoint 2013
Clean up an environment before an upgrade to SharePoint 2013
Test and troubleshoot an upgrade
Use a trial upgrade to SharePoint 2013 to find potential issues
Troubleshoot database upgrade issues in SharePoint 2013
Troubleshoot site collection upgrade issues in SharePoint 2013
Branding issues that may occur when upgrading to SharePoint 2013
Restart a database-attach upgrade or a site collection upgrade to SharePoint
2013
Upgrade databases
Checklist for database-attach upgrade (SharePoint 2013)
Create the SharePoint 2013 farm for a database attach upgrade
Copy databases to the new farm for upgrade to SharePoint 2013
Upgrade service applications to SharePoint 2013
Upgrade content databases from SharePoint 2010 to SharePoint 2013
Verify upgrade
Migrate from classic-mode to claims-based authentication in SharePoint 2013
Upgrade site collections
Run site collection health checks in SharePoint 2013
Upgrade a site collection to SharePoint 2013
Review site collections upgraded to SharePoint 2013
Manage site collection upgrades to SharePoint 2013
Upgrade My Sites to SharePoint Server 2013
Advanced upgrade scenarios
Search-first migration from FAST Search Server for SharePoint 2010 to
How to upgrade an environment that uses content type syndication (SharePoint
Server 2013)
Deploy custom features to upgraded site collections in SharePoint Server 2013
Deploy software updates for SharePoint 2013
Software updates overview
Prepare to deploy software updates
Update Workflow in SharePoint Server 2013
Test and troubleshoot an upgrade
Troubleshoot site collection upgrade issues
Sites
Plan sites and site collections
Sites and site collections overview
Plan self-service site creation
Configure self-service site creation in SharePoint Server 2019
Enable SharePoint home page in SharePoint Server 2019 farms
Site policy overview
Site navigation overview
Plan for multilingual sites
Plan for the multilingual user interface
Themes overview
Plan site maintenance and management
Manage site collections
Create a site collection
Delete and restore site collections
Manage the lock status for site collections
View all site collections
Manage a connection to a document center or a records center
Change site collection administrators
Create, edit, and delete quota templates
Manage unused site collections
Manage web parts
Configure and deploy web parts
Edit existing web parts in SharePoint
Permissions planning for sites and content
User permissions and permission levels
Overview of the Contribute permission level in SharePoint Server
Best practices for using fine-grained permissions in SharePoint Server
Overview of security groups in SharePoint Server
Determine permission levels and groups in SharePoint Server
Choose administrators and owners for the administration hierarchy in SharePoint
Server
Plan site permissions in SharePoint Server
Overview of site permissions in SharePoint Server
Managing digital assets overview
Plan digital asset libraries
OneDrive for Business overview
OneDrive for Business planning
Set up OneDrive for Business
Configure the OneDrive for Business modern user experience
Search
Search planning
Search architecture overview
Plan enterprise search architecture
Scale enterprise search
Redesign topology for more content and users
Redesign for specific performance requirements
Scale search for Internet sites
Best practices for organizing content for search
Plan crawling and federation
Search schema overview
Understanding result sources for search
Plan to transform queries and order results
Best practices of disaster recovery for search
Overview of search result ranking
Overview of analytics processing
Configure search
Create and configure a Search service application
Create a Search Center site
Deploy people search
Search administration
Classic and modern search differences
Manage the Search Center
Configure properties of the Search Box Web Part
Configure properties of the Search Results Web Part
Configure properties of the Refinement Web Part
Configure properties of the Search Navigation Web Part
Manage the index
Manage the search schema
Add or remove a file type from the search index
Delete items from the search index or from search results
Reset the search index
Manage crawling
Add, edit, or delete a content source
Change the default account for crawling
Start, pause, resume, or stop a crawl
Manage continuous crawls
Manage crawl rules
Configure and use the Exchange connector
Configure and use the Documentum connector
Configure and use the Lotus Notes connector
Manage farm-level crawl settings
Configure time-out values for crawler connections
Configure the crawler in case of SSL certificate warnings
Configure proxy server settings for Search
Best practices for crawling
Manage relevance
Manage query spelling correction
Manage query suggestions
Create and deploy a thesaurus
Configure authoritative pages
Manage query rules
Configure result sources for search
Create and deploy custom entity extractors
Manage company name extraction
Customize search result types
Create custom ranking model
Configure trust for search between two SharePoint Server farms
Manage the search topology
Change the default search topology
Manage search components
Manage the index component
Manage a paused Search service application
View search diagnostics
Enable search alerts
Enable query logging
Export and import customized search configuration settings
Search center scenarios
Set up a Search Center
How to create a Search Center Site Collection and enable crawling of your
content
How to configure the Search Results Web Part to use a new result source
Plan to use refiners on a search results page
How to add refiners to your search results page
How to add a custom search vertical to your search results page
How to change the way search results are displayed
Understanding how search results are displayed
Understanding how item display templates and hit highlighting work
How to create a new result type
How to display values from custom managed properties in search results - option
1
How to display values from custom managed properties in search results –
option 2
How to display values from custom managed properties in the hover panel
How to add a custom action to the hover panel
How to change the text that is displayed in the Search Box Web Part
How to change the order in which search results are displayed
Create and import a thesaurus
Create and import query suggestions
Changing the ranking of search results
Hybrid
Explore SharePoint Server hybrid
The building blocks of Office 365 hybrid
Minimum public update levels for SharePoint hybrid features
SharePoint hybrid sites and search
Hybrid search in SharePoint
Learn about cloud hybrid search for SharePoint
Learn about hybrid federated search for SharePoint
Hybrid picker in the SharePoint Online admin center
Plan SharePoint Server hybrid
Plan hybrid SharePoint taxonomy and hybrid content types
Plan hybrid OneDrive for Business
Plan cloud hybrid search for SharePoint
Plan hybrid profiles
The extensible hybrid app launcher
Hybrid site following
Plan hybrid federated search
Plan connectivity from Office 365 to SharePoint Server
Install and configure SharePoint Server hybrid
Hardware and software requirements for SharePoint hybrid
Accounts needed for hybrid configuration and testing
Configuration roadmaps
Configure hybrid OneDrive for Business - roadmap
Configure hybrid sites features - roadmap
Configure cloud hybrid search - roadmap
Cloud hybrid search FAQ
Configure hybrid federated search (SharePoint Server) - roadmap
Configure hybrid federated search (SharePoint Online) - roadmap
Configure hybrid Business Connectivity Services - roadmap
Configure the hybrid infrastructure
Configure Office 365 for SharePoint hybrid
Set up SharePoint services for hybrid environments
Configure server-to-server authentication
Run Hybrid Picker
Configure inbound connectivity
Configure a reverse proxy device for SharePoint Server hybrid
Configure Web Application Proxy for a hybrid environment
Configure Forefront TMG for a hybrid environment
Configure a hybrid solution
Configure hybrid OneDrive for Business
Show results from Office 365 in on-premises SharePoint with cloud hybrid search
Enable previews of on-premises search results in cloud hybrid search
Display hybrid federated search results in SharePoint Server
Display hybrid federated search results in SharePoint Online
Configure hybrid SharePoint taxonomy and hybrid content types
Hybrid self-service site creation
Set up Search of OneDrive for Business in Office 365 from SharePoint Server
Deploy a Business Connectivity Services hybrid solution
Prepare your environment
Validate the hybrid scenario
Governance
What is governance in SharePoint?
IT governance in SharePoint
Application management and governance in SharePoint
Information management and governance in SharePoint
Managed metadata planning
Configure the Managed Metadata service
How to use the Managed Solutions Gallery
Searching and using keywords in the eDiscovery Center
Export content and create reports in the eDiscovery Center
Create and run queries in the eDiscovery Center
Add content to a case and place sources on hold in the eDiscovery Center
eDiscovery and in-place holds in SharePoint Server
Plan for eDiscovery
Configure eDiscovery
Plan and manage cases in the eDiscovery Center
Records management in SharePoint Server
Create a file plan to manage records
Plan how records are collected
Use a records archive or manage records in place
Document management in SharePoint Server
Identify users and analyze document usage
Document library planning
Content type and workflow planning
Document set planning
Information management policy planning
Versioning, content approval, and check-out planning
Co-authoring overview
Configure versioning for co-authoring
Configure the co-authoring versioning period
Configure the maximum number of co-authoring authors
Disable co-authoring
Workflow in SharePoint Server
Getting started with SharePoint Server workflow
Install and configure workflow for SharePoint Server
Install Workflow Manager certificates in SharePoint Server
Video series: Install and configure Workflow in SharePoint Server 2013
Update Workflow in SharePoint Server
Administration
Server Management
Configure Request Manager in SharePoint Server
Global deployment of multiple farms
Global architectures for SharePoint Server
WAN performance and testing
SQL Server and storage
Overview of SQL Server in SharePoint Server 2016 and 2019 environments
Deploy Azure SQL Managed Instance with SharePoint Server 2016 and 2019
Overview of SQL Server in a SharePoint Server 2013 environment
Storage and SQL Server capacity planning and configuration
Database management
Add a content database
Attach or detach content databases
Move site collections between databases
Move content databases
Move all databases
Move or rename service application databases
Run a farm that uses read-only databases
Manage RBS
Best practices for SQL Server in a SharePoint Server farm
Configure log shipping
Backup and recovery overview
Backup and recovery planning
Prepare to back up and restore
Configure permissions for backup and restore
Backup
Back up a farm
Back up a farm configuration
Back up a web application
Back up a service application
Back up a User Profile Service application
Back up a Search service application
Back up the Secure Store Service
Back up a content database
Back up databases to snapshots
Back up customizations
Back up site collections
Back up apps for SharePoint
Export a site, list, or document library
Restore
Restore a farm
Restore a farm configuration
Document farm configuration settings
Copy configuration settings between farms
Restore a web application
Restore a service application
Restore a User Profile Service application
Restore a Search service application
Restore a Secure Store Service application
Restore a content database
Attach and restore a read-only content database
Restore content from an unattached content database
Restore customizations
Restore site collections
Restore apps for SharePoint
Import a list or document library
Best practices for backup and restore
High availability and disaster recovery concepts
Plan for disaster recovery
Plan for SQL Server Always On and Microsoft Azure disaster recovery
Supported high availability and disaster recovery options for SharePoint
databases
Plan for high availability
Disaster Recovery best practices for SharePoint Server and Access Services
Configure an AlwaysOn Availability Group
Performance planning in SharePoint Server 2013
Capacity management and sizing for SharePoint Server 2013
Capacity planning
Performance testing
Monitoring and maintaining
Optimize performance
Performance and capacity test results and recommendations for SharePoint 2013
Enterprise intranet collaboration performance and capacity
Web Content Management capacity and performance
Managed Metadata Service capacity and performance
Video content management capacity and performance
Compliance and eDiscovery capacity and performance
Social performance and capacity
Divisional collaboration performance and capacity
Managing a MinRole Server Farm in SharePoint Server 2016
Role conversion using MinRole in SharePoint Server 2016
Description of MinRole and associated services in SharePoint Server 2016
Remove a server from a farm in SharePoint Servers 2016 or 2019
Remove a server from a farm in SharePoint 2013
Uninstall SharePoint 2013
Uninstall SharePoint Servers 2016 or 2019
Custom Tiles in SharePoint Server 2016
Replace the STS certificate
Turn on automated document translation
Manage the Distributed Cache service
Plan for feeds and the Distributed Cache service
General guidance for hosters in SharePoint Server 2013
Understanding multi-tenancy in SharePoint Server 2013
Plan service deployment in SharePoint Server
SharePoint Server design samples: Corporate portal and extranet sites
Host-named site collection architecture and deployment in SharePoint Server
Update a web application URL and IIS bindings for SharePoint Server
Plan alternate access mappings for SharePoint Server
Configure alternate access mappings for SharePoint Server
Install and manage apps for SharePoint Server
Plan for apps for SharePoint
Configure an environment for apps for SharePoint
Manage the App Catalog
Add apps for SharePoint to a SharePoint site
Remove app for SharePoint instances from a SharePoint site
Monitor apps for SharePoint
Monitor and manage app licenses
Email integration planning
Incoming email planning
Outgoing email planning
Configure Exchange Autodiscover with a My Site Host URL
Configure email integration
Incoming email configuration
Outgoing email configuration
Configure Exchange task synchronization
Configure site mailboxes in SharePoint
Service application management
Start or stop a service
Assign or remove administrators of service applications
Configure automatic password change
Delete a service application
Share service applications across farms
Exchange trust certificates between farms
Publish a service application
Set permission to a published service application
Connect to a service application on a remote farm
Add or remove a service application connection to a Web application
Restrict or enable access to a service application
Monitoring overview
Using Administrative Actions logging in SharePoint Server 2016
Configure SharePoint Hybrid Auditing (Preview)
Configure monitoring
Configure diagnostic logging
Configure SharePoint Health Analyzer timer jobs
Configure usage and health data collection
Configure SharePoint Health Analyzer rules
Overview of scripted monitoring configuration
Profile schema reference
Run scripted monitoring configuration
View reports and logs
View health reports
View diagnostic logs
View timer job status
Monitor cache performance
View data in the logging database
Monitoring planning
Overview of Access Services in SharePoint Server 2013
Set up and configure Access Services for Access apps
Set up and configure Access Services 2010 for web databases in SharePoint 2013
Web applications management
Manage permissions for a web application
Manage permission policies for a web application
Manage anonymous access for a web application
Extend a claims-based web application
Define managed paths
Cache settings operations
Cache settings configuration for a web application
Configure object cache user accounts
Flush the BLOB cache
Web content management
Overview of publishing to Internet, intranet, and extranet sites
Plan for Internet, intranet, and extranet publishing sites
Plan for cross-site publishing
Overview of cross-site publishing
Plan the logical architecture for cross-site publishing
Plan SharePoint authoring sites for cross-site publishing
Plan SharePoint publishing sites for cross-site publishing
Plan search for SharePoint cross-site publishing sites
Plan variations for multilingual cross-site publishing site
Overview of managed navigation
Plan navigation term sets
Variations overview
Plan for variations
Caching and performance planning
View usage reports
How to set up a product-centric website
An introduction to cross-site publishing
Stage 1: Create site collections for cross-site publishing
Stage 2: Import list content into the Product Catalog Site Collection
Stage 3: How to enable a list as a catalog
Stage 4: Set up search and enable the crawling of your catalog content
From site column to managed property - What's up with that?
Stage 5: Connect your publishing site to a catalog
Stage 6: Upload and apply a new master page to a publishing site
Stage 7: Upload page layouts and create new pages in a publishing site
Stage 8: Assign a category page and a catalog item page to a term
Stage 9: Configure the query in a Content Search Web Part on a category page
Stage 10: Configure the query in a Content Search Web Part on a catalog item
page
Stage 11: Upload and apply display templates to the Content Search Web Part
Stage 12: Plan to use refiners for faceted navigation in - Part I
Stage 13: Plan to use refiners for faceted navigation - Part II
Stage 14: Configure refiners for faceted navigation
Stage 15: Add refiners for faceted navigation to a publishing site
Stage 16: Add a Taxonomy Refinement Panel Web Part to a publishing site
How to display recommendations and popular items in SharePoint Server
An introduction to recommendations and popular items
Change the Content Search Web Part display template and use Windows
PowerShell to start Usage analytics
Add and configure the Recommended Items and Popular Items Web Part
Use recommendations and popular items on websites with anonymous users
View and configure usage analytics reports
Search Engine Optimization (SEO)
Integrating social media with public-facing websites
Configure web content management solutions
Configure cross-site publishing
Connect a publishing site to a catalog
Assign a category page and a catalog item page to a term
Configure Search Web Parts
Configure refiners and faceted navigation
Configure result sources for web content management
Create query rules for web content management
Configure recommendations and usage event types
Business intelligence
Software requirements for business intelligence
Excel Services overview
Configure Excel Services
BI capabilities in Excel and Excel Services
Data authentication for Excel Services
Data sources supported in Excel Services (SharePoint Server 2013)
Plan Excel Services Global Settings
Manage Excel Services global settings
Plan Trusted File Locations
Manage Excel Services trusted file locations
Plan Trusted Data Connection Libraries
Manage Excel Services trusted data connection libraries
Plan Excel Services Data Model settings
Manage Excel Services data model settings
Manage Excel Services trusted data providers
Manage Excel Services user defined function assemblies
Share data connections by using Excel and Excel Services (SharePoint Server
2013)
Share a SQL Server Analysis Services data connection using Excel Services
(SharePoint Server 2013)
Share a SQL Server data connection using Excel Services (SharePoint Server
2013)
Share an OLE DB or ODBC connection using Excel Services (SharePoint Server
2013)
Share workbooks by using Excel Services (SharePoint Server 2013)
Create an Excel Services dashboard using an OData data feed
Create an Excel Services dashboard using SQL Server Analysis Services data
Create an Excel Services dashboard using a Data Model (SharePoint Server
2013)
Configure PerformancePoint Services
PerformancePoint Services in SharePoint Server 2016 overview
Enable trusted locations for PerformancePoint Services
PerformancePoint Services application settings
Overview of Visio Services in SharePoint Server
Configure Visio Services
Plan Visio Services security in SharePoint Server
Plan Visio Services deployment in SharePoint Server
Data authentication for Visio Services in SharePoint Server
Use Visio Services with external lists in SharePoint Server
Use Visio Services with SharePoint lists
Configure the Secure Store Service
Plan the Secure Store Service in SharePoint Server
Secure Store for Business Intelligence service applications
Use Excel Services with Secure Store
Use PerformancePoint Services with Secure Store
Use Visio Services with Secure Store
Use Secure Store with SQL Server Authentication
Configure Power Pivot for SharePoint 2013
Data refresh using Secure Store
Data refresh using a specified account
Data refresh using the unattended data refresh account
Use Analysis Services EffectiveUserName in SharePoint Server
Use EffectiveUserName with Excel Services (SharePoint Server 2013)
Use EffectiveUserName in PerformancePoint Services
Configure AdventureWorks
User profiles and identities
Plan user profiles
Overview of profile synchronization in SharePoint Server 2013
Profile synchronization in SharePoint Server 2016
Plan profile synchronization for SharePoint Server 2013
Microsoft Identity Manager in SharePoint Servers 2016 and 2019
Install Microsoft Identity Manager for User Profiles in SharePoint Servers 2016
and 2019
Use a sample MIM solution in SharePoint Servers 2016 and 2019
Overview of Microsoft Identity Manager Synchronization Service in SharePoint
Servers 2016 and 2019
Deployment considerations for implementing Microsoft Identity Manager with
SharePoint Servers 2016 and 2019
People Picker and claims providers overview
Plan for People Picker
Plan for custom claims providers for People Picker
User Profile service administration
Add, edit, or delete custom properties for a user profile
Manage profile synchronization
Configure profile synchronization
Configure profile synchronization by using SharePoint Active Directory Import
Start profile synchronization manually
Schedule profile synchronization
Maintain profile synchronization
Create an audience for SharePoint Server
Create a web application in SharePoint Server
Configure basic authentication for a claims-based web application in SharePoint
Server
Configure digest authentication for a claims-based web application in SharePoint
Server
Edit general settings on a web application in SharePoint Server
Mobile devices overview
Plan for mobile views
Supported mobile device browsers
Mobile security and authentication
Authentication for mobile devices
Supporting the SharePoint mobile apps online and on-premises
Business Connectivity Services overview
Configure a Business Data Connectivity service application
Security tasks overview
Plan a Business Connectivity Services solution
Configure Business Connectivity Services solutions
Deploy an on-premises solution
Create Test and Developer Environments
Test lab guides
Configure SharePoint Server 2013 in a three-tier farm
Configure intranet and team sites
Demonstrate forms-based claims authentication
Demonstrate profile synchronization
Demonstrate SAML-based claims authentication
Demonstrate social features
Configure eDiscovery
Configure a highly available SharePoint Server 2013 Search topology
SharePoint 2013 dev/test environments in Azure
SharePoint Server 2016 in Microsoft Azure
SharePoint Server 2016 dev/test environment in Azure
Intranet SharePoint Server 2016 in Azure dev/test environment
Designing a SharePoint Server 2016 farm in Azure
Deploying SharePoint Server 2016 with SQL Server AlwaysOn Availability
Groups in Azure
SharePoint Intranet Farm in Azure Phase 1: Configure Azure
SharePoint Intranet Farm in Azure Phase 2: Configure domain controllers
SharePoint Intranet Farm in Azure Phase 3: Configure SQL Server
Infrastructure
SharePoint Intranet Farm in Azure Phase 4: Configure SharePoint servers
SharePoint Intranet Farm in Azure Phase 5: Create the availability group and
add the SharePoint databases
Integrate Yammer with on-premises SharePoint Server
Yammer networks, groups, and users overview
Social scenarios with Yammer and SharePoint Server
Integrate a new Yammer network into SharePoint Server
Integrate a single Yammer network into SharePoint Server
Integrate multiple Yammer networks into SharePoint Server
Integrate a Yammer network into SharePoint Server with social features
Integrate a Yammer network into SharePoint Server and Office 365
Add Yammer to the SharePoint Server navigation
Hide SharePoint Server default social features
Add the Yammer Embed widget to a SharePoint page
Troubleshoot
Claims authentication does not validate user
Troubleshoot common fine-grained permissions issues
SharePoint site inaccessible
Upgrade SharePoint 2013 to SharePoint 2016 through Workflow Manager
Upgrade SharePoint 2016 to SharePoint 2019 through Workflow Manager
After installing .NET security patches to address CVE-2018-8421, SharePoint
crawler may fail
Technical reference
System Center Operations Manager knowledge articles
Access Services in SharePoint Server
Machine Translation service in SharePoint Server
Search in SharePoint Server
Visio Services in SharePoint Server
Project Server 2013 knowledge articles
Database types and descriptions
SharePoint Health Analyzer rules reference
A State Service Application has no database defined
Accounts used by application pools or service identities are in the local machine
Administrators group
All State Service databases are paused for a State Service Application
Application pools recycle when memory limits are exceeded
Business Data Connectivity connectors are currently enabled in a partitioned
environment
Cached objects have been evicted
Content databases contain orphaned Apps
Critical state of this rule indicates that the Word Automation Services is not running
when it should be running
Databases exist on servers running SharePoint Foundation
Databases require upgrade or not supported
Databases running in compatibility range, upgrade recommended
Databases within this farm are set to read only and will fail to upgrade unless it is
set to a read-write state
Databases used by SharePoint have outdated index statistics
Dedicated crawl target configuration has one or more invalid servers
Distributed cache service is not configured on server(s)
Distributed cache service is not enabled in this deployment
Distributed cache service is unexpectedly configured on server(s)
Drives used for SQL databases are running out of free space
Expired sessions are not being deleted from the ASP.NET Session State database
Firewall client settings on the cache host are incorrect
Immediate translations for the Machine Translation service are disabled
InfoPath form library forms cannot be filled out in a Web browser
InfoPath Forms Services forms cannot be filled out in a Web browser because no
State Service connection is configured
More cache hosts are running in this deployment than are registered with
SharePoint
One of the cache hosts in the cluster is down
One or more servers is not responding
One or more servers can't retrieve People Picker credentials
One or more servers can't retrieve the outgoing email credentials
One or more web applications are configured to use Windows Classic
authentication
Product / patch installation or server upgrade required
Some content databases are growing too large
The Application Discovery and Load Balancer Service is not running in this farm
The InfoPath Forms Services Maintenance Timer Job not enabled
The Machine Translation Service is not running when it should be running
The number of Distributed Cache hosts in the farm exceeds the recommended
value.
The Security Token Service is not available
The settings for the Machine Translation Service are not within the recommended
limits
The settings for Word Automation Services are not within the recommended limits
The State Service Delete Expired Sessions timer job is not enabled
The timer service failed to recycle
The unattended Service Account Application ID is not specified or has an invalid
value
The Visio Graphics Service has a maximum cache age setting that will adversely
impact performance
The Visio Graphics Service has a maximum cache size setting that may adversely
impact performance
The Visio Graphics Service has a maximum recalc duration setting that will
adversely impact user perceived performance
The Visio Graphics Service has a maximum Web Drawing Size setting that will
adversely impact performance
The Visio Graphics Service has a minimum cache age setting that may cause a
security issue
The Visio Graphics Service has a minimum cache age setting that will adversely
impact performance
This Distributed Cache host may cause cache reliability problems
Verify each User Profile service application has a My Site host configured
Verify each User Profile Service Application has an associated Managed Metadata
Service Connection
Verify each User Profile Service Application has an associated Search Service
Connection
Verify that OAuth is configured correctly for the Machine Translation Service
application
Verify that OAuth is configured correctly for the Machine Translation Service
application proxy
Verify that the Activity Feed Timer Job is enabled
Verify that the critical User Profile Application and User Profile Proxy Application
timer jobs are available and have not been mistakenly deleted
Web Applications using Claims authentication require an update
Web.config file has incorrect settings for the requestFiltering element
Web.config files are not identical on all machines in the farm
XLIFF translations for the Machine Translation Service is disabled
The server farm account should not be used for other services
Databases used by SharePoint have fragmented indices
The paging file size should exceed the amount of physical RAM in the system
Automatic Update setting inconsistent across farm servers
Built-in accounts are used as application pool or service identities
Missing server side dependencies
One or more categories are configured with Verbose trace logging
Outbound e-mail has not been configured
Server role configuration isn't correct
One or more app domains for web applications aren't configured correctly
Drives are running out of free space
Drives are at risk of running out of free space
Content databases contain orphaned items
The Net.Pipe Listener Adapter isn't available
One or more services have started or stopped unexpectedly
The current server is running low on memory
Timer job reference for SharePoint Server
Default timer jobs in SharePoint Server 2019
Default timer jobs in SharePoint Server 2016
Default timer jobs in SharePoint 2013
Search technical reference
Default crawled file name extensions and parsed file types
Default connectors
Linguistic search features
Crawled and managed properties overview
Query variables
Result types and display templates that are used to display search results
Supported and unsupported Documentum object types and properties
Publishing technical reference
Automatically created managed properties in SharePoint
Stsadm to Microsoft PowerShell mapping
Display template reference in SharePoint Server
Technical diagrams
SharePoint PowerShell
Product Servicing Policy
Updated Product Servicing Policy for SharePoint Server 2019
Updated Product Servicing Policy for SharePoint Server 2016
Updated Product Servicing Policy for SharePoint 2013
This guide helps IT Pros plan, deploy, and manage SharePoint Server 2016 and 2013 in their enterprise environments.
Get started
Migration
Hybrid
Community
Product feedback
End user content
Learn about SharePoint

What is SharePoint?
SharePoint Server 2019 overview
SharePoint blog
Before you start

Hybrid
Security
Manage your environment

Sites Administration
Server Management
Backup and recovery
Monitor your environment
Install
SharePoint Server 2016 and 2019
Large scale farms
Small scale farms
Large scale farms
Small scale farms
Upgrade and update

Apply updates to SharePoint Server 2016
Upgrade to SharePoint 2013
Apply updates to SharePoint 2013
Legacy content
SharePoint Server 2007 end of support roadmap
Upgrading from Server 2010 and end of support
Accessibility guidelines in SharePoint Server 2016
6/7/2019 • 2 minutes to read • Edit Online
APPLIES TO: 2013 2016 2019 SharePoint Online

SharePoint Server supports the accessibility features of common browsers that help IT Pros administer
deployments and access sites. For more information about supported features, see Web Content Accessibility
Guidelines 2.0.
Administrators and other users who have administrative responsibilities typically use the SharePoint Central
Administration website and the SharePoint 2016 Management Shell to manage deployments. The mouse and
keyboard are typical devices that administrators use to interact with Central Administration.
Because SharePoint Server runs as web sites in Internet Information Services (IIS ), administrators and users
depend on the accessibility features that browsers provide. SharePoint Server supports the accessibility features of
supported browsers. For more information, see Plan browser support in SharePoint Server 2016.
Users who don't use a mouse can use a keyboard to navigate the user interface and complete actions. The ability to
use the keyboard in this way is a result of support for keyboard interactions that a browser provides. Users who
have devices that support touch can also use gestures to complete operations. For more information, see Touch.
SharePoint Server 2016 conformance statement

The following SharePoint Server 2016 conformance statement, VPAT, and EN 301 549 reports are available at
Microsoft Accessibility Conformance Reports You can download the WCAG Conformance Statement and the
Section 508 VPAT for SharePoint Server 2016, click the provided link and search for SharePoint Server 2016.
Accessibility features in SharePoint Server

Many of the accessibility features in SharePoint Online also apply to SharePoint Server 2016 and SharePoint 2013.
For more information about these accessibility features, see the following topics:
Keyboard shortcuts
Using screen readers
Create accessible sites
Plan browser support in SharePoint Server 2016
See also
Other Resources
Microsoft accessibility
Accessibility features in SharePoint Online
Accessibility support for enterprise
What's new

Articles contain an overview of new and improved product features, updates, deprecated and removed features.
CONTENT DESCRIPTION
New and improved features in SharePoint Server 2019 Learn about the new features and updates to existing features
in SharePoint Server 2019.
What's deprecated or removed from SharePoint Server 2019 Learn about the features and functionality that are deprecated
or removed in SharePoint Server 2019.
New and improved features in SharePoint Server 2016 Learn about the new features and updates to existing features
in SharePoint Server 2016.
New features in November 2016 PU for SharePoint Server Learn about the new features that are included in the
2016 (Feature Pack 1) November 2016 Public Update for SharePoint Server 2016
(Feature Pack 1).
New features in September 2017 PU for SharePoint Server Learn about the new features that are included in the
2016 (Feature Pack 2) September 2017 Public Update for SharePoint Server
2016(Feature Pack 2).
What's deprecated or removed from SharePoint Server 2016 Learn about the features and functionality that are deprecated
or removed in SharePoint Server 2016.
See also
Other Resources
What is SharePoint
About SharePoint

Learn about the new features and updates to existing features in SharePoint Server 2019.
To read more about the updated modern experience in SharePoint Server 2019, see Differences between
SharePoint Server 2016 and 2019.
Detailed description of new features

This section provides detailed descriptions of the new updated features in SharePoint Server 2019.
Access Services 2013 now supports Send Email
The Access Services 2013 service application now supports the SendEmail action for sending email messages from
apps. See Introducing Send Email in Access 2013 web apps for more details.
Additional documentation links for Central Administration site
We've made it easier for farm administrators to reach the latest SharePoint administration documentation and find
the latest Public Updates by adding links in the SharePoint Central Administration homepage.
SharePoint Server Documentation
SharePoint Server Updates
Communication sites
Communication sites are a place to share news, showcase a story, or broadcast a message to other people. The new
Hero web part can display up to five items with compelling images, text, and links to draw attention to your most
important content. Users can easily create communication sites for themselves from SharePoint Home without
needing to contact IT.
Fast site creation
Fast site creation in SharePoint Server 2019 allows users create new sites in a few seconds. Fast site creation is only
supported with the following site templates:
OneDrive personal site [SPSPERS#10]
Team site (modern only) [STS#3]
Communication site [SITEPAGEPUBLISHING#0]
Fast site creation is used when creating sites in the following entry points:
OneDrive personal site auto-provisioning
The Create Site button in SharePoint Home
The New -SPSite PowerShell cmdlet with the -CreateFromSiteMaster switch parameter#
Increased storage file size in SharePoint document libraries
We now support storing files up to 15 GB in SharePoint document libraries. This is up from 10 GB in SharePoint
Server 2016.
Modern lists and libraries
SharePoint Server 2019 contains the modern experiences for lists and libraries in Team sites. This brings the
experience up to date with that found in SharePoint Online.
Modern sharing experiences
SharePoint Server 2019 now supports modern sharing experiences with a simplified sharing UI. You can now
easily share links to content with others in your organization. You can also be warned if you're sharing to a large
group or sharing a large number of items.
Modern Site Pages, modern web parts and authoring
SharePoint Server 2019 users can now add modern site pages and modern web parts on team sites. Do this in the
Add a Page in Site Actions or in the pages library by clicking New > Site Page.
Modern search experience
SharePoint Server 2019 offers a modern search experience in addition to the classic one.
In the modern search experience, the most visible difference for users is that they see results before they start
typing in the search box, and the results update as they type. Learn about the modern search experience.
There are some differences between the search experiences from a search administrator's perspective, learn about
these differences.
Modern Team sites
Modern team sites bring a fresh and responsive user experience to team collaboration. The redesigned homepage
improves the discoverability of the most common collaboration tasks while putting your team’s news front and
center. Users can easily create modern team sites for themselves from SharePoint Home without needing to contact
IT.
SharePoint Server 2019 will continue to support creating classic team sites.
Integration with PowerApps, Power BI and MS Flow
SharePoint Server 2019 brings cloud closer to the Customers and Customers closer to the cloud. The cloud
features PowerApps, Power BI and MS Flow are now available. SharePoint Server 2019 includes process
automation and forms technologies like PowerApps and Flow to connect with your on-premises data. These
features needs to be configured via gateway.
SharePoint using modern Internet Information Services (IIS ) APIs
SharePoint has modernized its integration with IIS by removing all of our dependencies on the legacy IIS6 APIs.
SharePoint now uses the IIS7+ APIs to manage IIS, which are the latest and best supported APIs from the IIS
team. This allows us to more easily adopt new IIS features and stay compatible with future Windows Server
releases.
As a result of this change, the following Windows Server features will no longer be installed by the SharePoint
prerequisite installer:
IIS 6 Management Compatibility (Web-Mgmt-Compat)
IIS 6 Metabase Compatibility (Web-Metabase)
IIS 6 Scripting Tools (Web-Lgcy-Scripting)
SharePoint home page
The SharePoint home page is a modern UI experience that gives users unified access to all of their sites—online
and on-premises. It allows users to navigate seamlessly through their intranet, catch up with activity across their
sites with just a glance, and provides a personalized view of all team news.
The SharePoint home page is also the launching point for users to create new, modern sites on a self-service basis.
You can reach the SharePoint home page by clicking on the "SharePoint" icon in the SharePoint app launcher. The
SharePoint home page replaces the old sites.aspx experience. For more information, see Enable SharePoint home
page in SharePoint Server 2019 farms.
From the SharePoint home page, you can create sites in different web applications
The self-service site creation experience in the SharePoint home page now supports creating new sites in a
different web application, regardless of whether the web application is hosted on the local farm or a remote farm.
This is controlled by the When users select the Create site command, create setting on the Self-service Site
Collection Management page in Central Administration.
To create sites in the same web application, select This web application.
To create sites in a different web application on the local farm, select The following web application and then
select the web application from the drop-down field. Ensure self-service site creation is enabled in the target web
application.
To create sites in a different web application on a remote farm, follow these steps:
1. In the local farm hosting the SharePoint home page, use the Map to External Resource feature in Alternate
Access Mappings (AAM ) to provide the URL of the web application you want to create sites in.
2. In the local farm hosting the SharePoint home page, on the Self-service Site Collection Management page
for the web application hosting the SharePoint home page, select The following web application, and
then select the remote web application from the drop-down field.
3. In the remote farm, use the Map to External Resource feature in Alternate Access Mappings (AAM ) to
provide the URL of the web application hosting the SharePoint home page.
4. In the remote farm, on the Self-service Site Collection Management page for the web application you want
to create the sites in, ensure self-service site creation is enabled.
Self-service site creation on the SharePoint home page now supports AAM zones
The self-service site creation experience on the SharePoint home page now fully supports non-Default Alternate
Access Mapping (AAM ) zones. When creating sites in a different web application on a remote farm, make sure that
an external resource has been created in AAM on both the local farm and the remote farm. This applies to sites
created in the same web application, sites created in a different web application on the local farm, and sites created
in a different web application on a remote farm.
SharePoint will treat the external resource as an external web application. The external resource on the local farm
should be fully populated with the URLs and zones of the web application on the remote farm. And conversely, the
external resource on the remote farm should be fully populated with the URLs and zones of the web application on
the local farm. Be sure that the zones of the local web application and the remote web application are synchronized.
For more information, see Configure self-service site creation in SharePoint Server 2019.
SMTP authentication when sending emails
SharePoint Server 2019 now supports authenticating to SMTP servers when sending email messages.
Authentication can be configured through the Central Administration website and through PowerShell. SharePoint
Server 2019 will still support anonymous connections to SMTP servers that don't require authentication. This
makes it easier for customers to integrate SharePoint into highly secure environments where authentication is
required to send emails. Customers no longer need to configure smart host relays for SharePoint in these
environments. For more information, see Plan outgoing email for a SharePoint Server farm and Configure
outgoing email for a SharePoint Server farm.
Sync files with OneDrive sync client (NGSC )
Users can use the new OneDrive sync client (NGSC – Next Generation Sync Client) instead of Groove.exe to sync
files in your SharePoint Server 2019 team sites and personal sites with your devices. The OneDrive sync client
supports advanced features such as Files On-Demand, push notification, and IRM protection, while still being easy
to use. For more information, see Deploy the new OneDrive sync client for Windows and Deploy and configure the
new OneDrive sync client for Mac.
Use of # and % characters in file and folder names
SharePoint Server 2019 now supports # and % characters in file and folder names, completing our support for all
valid Windows file and folder name characters. This makes it easier to sync to content from personal storage
devices to SharePoint.
Detailed description of new Microsoft PowerShell SharePoint Server

cmdlets
This section lists the new PowerShell cmdlets for SharePoint Server 2019.
New User Profile Synchronization PowerShell cmdlets
The "stsadm.exe -o sync" command has been converted into several PowerShell cmdlets:
Get-SPContentDatabase - You can now use the Get-SPContentDatabase cmdlet with the optional parameter
-DaysSinceLastProfileSync to return content databases that haven't been synchronized with User Profile for
the past n days.
Clear-SPContentDatabaseSyncData - The new Clear-SPContentDatabaseSyncData cmdlet clears User
Profile synchronization information from the content databases in the farm that haven't been synchronized
for the past n days.
Update-SPProfileSync - The new Update-SPProfileSync cmdlet updates the User Profile synchronization
settings to specify the main synchronization schedule, the sweep schedule to identify new users, and which
web applications should be excluded from synchronization.
The "stsadm.exe -o sync" command will still be supported for backward compatibility.
New Get-SPContentDatabaseOrphanedData PowerShell cmdlet
The "stsadm.exe -o enumallwebs" command has been converted into a PowerShell cmdlet. You can now use the
new Get-SPContentDatabaseOrphanedData cmdlet to find orphaned objects within a content database. The
"stsadm.exe -o enumallwebs" command will still be supported for backward compatibility.
New Set-SPApplicationCredentialKey PowerShell cmdlet
The "stsadm.exe -o setapppassword" command has been converted into a PowerShell cmdlet. You can now use the
new Set-SPApplicationCredentialKey cmdlet to set the application credential key on the local server for the
SharePoint People Picker and SMTP authentication. The "stsadm.exe -o setapppassword" command will still be
supported for backward compatibility.
New Remove -SPApplicationCredentialKey PowerShell cmdlet
The new Remove-SPApplicationCredentialKey cmdlet allows you to remove the application credential key from the
local server. The impact level of this cmdlet is set to high, as removing the application credential key from the local
server may degrade or block the functionality of features if they're configured to use the application credential key.
For example, the SharePoint People Picker or SMTP authentication.
Detailed description of new SharePoint Health Analyzer rules

This section lists the new Health Analyzer rules for SharePoint Server 2019.
People Picker health rule
SharePoint has added a new health analyzer rule for the People Picker. This health analyzer rule detects if servers in
the farm are missing the encryption key needed to retrieve People Picker credentials, such as when the People
Picker is configured to search for users in another forest or domain with a one-way trust to the SharePoint farm's
domain. If so, it will notify the SharePoint farm administrator so that they can correct the problem. For more
information, see One or more servers can't retrieve People Picker credentials.
SMTP authentication health rule
SharePoint has added a new health analyzer rule for SMTP authentication. This health analyzer rule detects if
servers in the farm are missing the encryption key needed to retrieve the credentials for authentication. If so, it will
notify the SharePoint farm administrator so that they can correct the problem. For more information, see One or
more servers can't retrieve the outgoing email credentials.
Detailed description of improved features

This section provides detailed descriptions of the updated features in SharePoint Server 2019.
Distributed Cache now uses background garbage collection by default
Distributed Cache will now configure AppFabric Velocity Cache to use background garbage collection. This helps
provide a more reliable experience for features that depend on Distributed Cache.
File path limit of 400 characters
SharePoint Server 2019 has increased the maximum file path length limit from 260 characters to 400 characters.
The file path is everything after the server name and port number in the URL. File path includes the name of the
site and subsites, document library, folders, and the file itself. This file path length limit increase makes it easier to
sync deeply nested content from personal storage devices to SharePoint.
Hybrid experiences improvements
The "OneDrive by Default" experience for SharePoint Server 2013 is now available in SharePoint Server
2019. When enabled, any attempt to browse to the My Site Host welcome page will be redirected to Office
365.
A SharePoint hybrid status bar was added to the top of Central Administration. The hybrid status bar will
appear once the SharePoint Server 2019 farm meets the minimum system requirements needed to enable
hybrid, and will give you direct access to launch the SharePoint Hybrid Configuration Wizard.
We've added and updated hybrid links throughout Central Administration to launch the SharePoint Hybrid
Configuration Wizard. This lets you skip clicking through multiple pages in the SharePoint Online Admin
Center just to get to the SharePoint Hybrid Configuration Wizard.
Recycle Bin restore improvements
SharePoint Server 2019 users can now restore items that they've deleted themselves, and also items that other
users in the site have deleted. Users need edit permission on the deleted items so they're visible in their SharePoint
recycle bin.
Sharing email template
Sharing email notifications have been refreshed to use a modern template design. Customers can set the
SPWebApplication.SharingEmailUseSharePoint2016Templates property to true if they want to continue
using the previous sharing email template.
Suite Navigation and App Launcher improvements
We've refreshed Suite Navigation and App Launcher in SharePoint Server 2019. The user interface now is closely
aligned with what is seen in Office 365 so that SharePoint hybrid customers will have a seamless experience as
they move between SharePoint Server 2019 and SharePoint Online.
Telemetry privacy experience
SharePoint Server 2019 now has an updated telemetry management experience. When you first set up a farm or
browse to the SharePoint privacy settings page in Central Administration, you can now provide an email address
for the telemetry contact of your organization. This is in anticipation of future telemetry reporting capabilities that
will allow customers to associate SharePoint Server and OneDrive Sync Client telemetry with their hybrid tenancy.
The email address provided is not sent outside of the SharePoint farm, not even to Microsoft. It is used in
combination with other farm data to generate a unique hash value to represent your farm when uploading
telemetry data to Microsoft. When customers want to associate telemetry with their hybrid tenancy, this email
address will be part of the process to prove ownership of the telemetry data.
Customers can opt in and opt out of the telemetry experience at any time.
Visio Services accessibility
Visio Services is introducing several accessibility improvements for high contrast displays, keyboard navigation,
and Narrator. Users will be able to access different panes with the following shortcuts:
1. Move focus to Comment pane = Alt + R
2. Move focus to Shape data pane = Alt + S
3. Move focus to Canvas = Alt + C
Related Topics
What is SharePoint?
New development capabilities for SharePoint 2019
What's deprecated or removed from SharePoint
Server 2019

Learn about the features and functionality that are deprecated or removed in SharePoint Server 2019.
Deprecated features are included in SharePoint Server 2019 for compatibility with previous product versions. For
information about new features in SharePoint Server 2019, see New and improved features in SharePoint Server
2019.
Definitions
Different customers may have different interpretations of terms such as “deprecated.” To ensure that customers
fully understand what we mean by the terminology in this document, we’re including this brief definition of each
term.
Deprecated
A deprecated feature is no longer being invested in by Microsoft and we discourage customers from taking a
dependency on it if they haven’t used it before. Deprecated features are still supported by Microsoft in
SharePoint Server 2019 for customers who are already using this feature in previous releases and need the
feature for backward compatibility. Deprecated features may be removed in future major releases of
SharePoint Server with no additional notice. Customers should begin to explore their options for migrating
away from these features.
Removed
A removed feature is no longer supported by Microsoft in SharePoint Server 2019. In many cases the
feature is actually removed from the product, but in some cases it may still be present. A feature labeled as
“removed” is unsupported even if the feature is still present in the product.
Features deprecated in SharePoint Server 2019

The following features and functionality have been deprecated in SharePoint Server 2019.
Access Services 2010
Access Services 2010 will remain supported, but deprecated, for the SharePoint Server 2019 release. Customers
are recommended to explore Microsoft PowerApps and Flows as potential alternatives to Access Services 2010.
Access Services 2013
Access Services 2013 will remain supported, but deprecated, for the SharePoint Server 2019 release. Customers
are recommended to explore Microsoft PowerApps and Flows as potential alternatives to Access Services 2013.
Aggregated Newsfeed
The aggregated newsfeed feature (available at newsfeed.aspx and typically accessed via the Newsfeed tile on the
app launcher), will be set to read-only in SharePoint Server 2019. Both the tile in the app launcher and the option to
implement the newsfeed capability will also be removed from this version forward. For customers who are
currently using the aggregated newsfeed, we recommend considering options such as Team News, Communication
Sites, Yammer and/or Teams. Please note that the Site Feed feature on an individual site is not impacted and will
continue to be supported across all versions of the product.
Custom Help
To ensure that users receive highly relevant help content, Microsoft is moving from away from our legacy on-
premises SharePoint help engine, which is based on help collections being installed in the on-prem farm. The new
SharePoint help system is now rendered in the cloud and will have updated, synchronized content with Office 365.
Custom help based on the legacy SharePoint help engine will remain supported, but deprecated, for the SharePoint
Server 2019 release.
Groove Sync Client
The Groove sync client is our client for syncing documents between your personal devices and SharePoint Server
2010, 2013, and 2016 Team sites. SharePoint Server 2019 introduces support for the new OneDrive Sync Client
(a.k.a. the Next Generation Sync Client), which provides a more reliable and feature-rich syncing experience. If
Groove detects that your existing sync relationships are to a site that has been upgraded to SharePoint Server
2019, it will attempt to migrate those sync relationships to the OneDrive Sync Client. Administrators can control
this migration experience.
The Groove sync client will remain supported, but deprecated, for the SharePoint Server 2019 release.
InfoPath Services
As we announced in the Microsoft 365 blog, InfoPath Services is a deprecated feature and customers are advised to
explore alternatives for this feature. InfoPath Services will remain supported, but deprecated, for the SharePoint
Server 2019 release.
There will not be a new InfoPath client shipped with this release. Microsoft will ensure that the InfoPath 2013 client
will work with SharePoint Server 2019 for the remainder of the client support lifecycle (2026). InfoPath 2013 client
will not be supported beyond that timeframe.
Lists Web Service
The following SOAP endpoints in the Lists web service depend on the Microsoft Sync Framework, which was
necessary to support the Groove sync client. Because the Groove sync client is now a deprecated feature, these
SOAP endpoints are also being deprecated for the SharePoint Server 2019 release.
Lists.GetListItemChangesWithKnowledge
Lists.UpdateListItemsWithKnowledge
Machine Translations
The Machine Translation Service will remain supported but deprecated for the SharePoint Server 2019 release.
Variations
The Variations will remain supported but deprecated for the SharePoint Server 2019 release.
PerformancePoint Services
PerformancePoint Services has a significant dependency on Microsoft Silverlight, which is a technology that will no
longer be supported as of October 12, 2021. PerformancePoint Services will remain supported, but deprecated, for
the SharePoint Server 2019 release. Customers are recommended to explore Microsoft PowerBI as an alternative
to PerformancePoint Services as we are making many new business intelligence investments in PowerBI.
SharePoint Designer
There will not be a new SharePoint Designer client shipped with this release. Microsoft will ensure that SharePoint
Designer 2013 will work with SharePoint Server 2019 for the remainder of the client support lifecycle (2026).
SharePoint Designer 2013 will not be supported beyond that timeframe.
Site Mailbox
As we announced in the SharePoint Community Blog, site mailboxes are being deprecated in SharePoint Online.
Site mailboxes will remain supported, but deprecated, in the SharePoint Server 2019 release. Customers are
recommend to explore shared mailboxes as an alternative to site mailboxes.
Site Manager
The main functionality of Site Manager is now available in modern file move. The Site Manager feature will be
supported, but it is deprecated in SharePoint Server 2019. Only site collection administrators will have permission
to access the Site Manager page and the UI entry points to this page will be removed.
Removed features in SharePoint Server 2019

The following features and functionality have been removed in SharePoint Server 2019.
Code -Based Sandbox Solutions
As announced in the Microsoft Office Dev Center and previous articles, code-based sandbox solutions were
deprecated in SharePoint Server 2013 and have now been removed in SharePoint Online. After careful
consideration, we’ve decided to also remove support for code-based sandbox solutions in SharePoint Server 2019.
Customers are recommended to explore SharePoint add-ins as an alternative, which are fully supported for both
SharePoint on-premises and SharePoint Online.
Digest Authentication
As announced by the Windows Server team, Microsoft is deprecating the Digest authentication feature in Internet
Information Services (IIS ). This authentication mechanism isn’t very popular and there are many alternative
authentication mechanisms available with better interoperability.
To ensure we remain compatible with potential future releases of Windows Server, we are removing support for
Digest authentication in SharePoint Server 2019. The SharePoint prerequisite installer will no longer attempt to
install this Windows feature. Customers using Digest authentication are recommended to explore alternatives such
as Kerberos, NTLM, or SAML.
Incoming email automatic mode
As announced by the Windows Server team, Microsoft is deprecating the IIS 6 Management compatibility features
in Internet Information Services (IIS ). The automatic mode of the SharePoint incoming email feature relies on IIS 6
APIs to manage the IIS SMTP service. Because no alternative APIs exist to manage the IIS SMTP service, we are
removing support for automatic mode in the incoming email feature of SharePoint Server 2019. Customers using
incoming email are recommended to use advanced mode instead, which allows you to manually manage the IIS
SMTP service and drop folder.
Multi-Tenancy
As Microsoft continues to innovate in SharePoint Online, an increasing amount of SharePoint multi-tenancy
capabilities are taking dependencies on cloud technologies that aren’t available in on-premises environments. The
cost and complexity of providing an on-premises alternative has become prohibitive, so we will no longer support
multi-tenancy in the SharePoint Server 2019 release. Existing SharePoint Server customers who depend on multi-
tenancy are recommended to explore migrating to SharePoint Online. Other options include migrating to a non-
multi-tenancy farm configuration or remaining with SharePoint Server 2016.
PDF Viewer (SharePoint Server 2019 Preview)
SharePoint Server 2019 Preview included a built-in PDF viewer which allowed SharePoint to render PDF
documents. This feature was removed from the RTM release of SharePoint Server 2019. Customers can instead
use the native PDF rendering capabilities available in most web browsers and client devices.
PowerPivot Gallery and Refresh
Since the feature was first introduced in SharePoint, Microsoft BI strategy has shifted away from heavy integration
to a standalone BI solution, Power BI, to give customers a flexible, optional integration with SharePoint along with
standalone capabilities. Both PowerBI.com and Power BI Report Server offer the option to host and view Excel
Workbooks with PowerPivot models today and is the preferred method for customers going forward to host and
use their Excel Workbooks with PowerPivot models, or simply to migrate to PBIX files using the migration option in
Power BI Desktop for Excel Workbooks.
SharePoint Workflow Manager (SharePoint Server 2019 Preview)
Microsoft announced that SharePoint Server 2019 Preview would support a new workflow management
application called SharePoint Workflow Manager to run SharePoint Server 2013 workflows. However, the
SharePoint Workflow Manager application was canceled before its final release. The RTM release of SharePoint
Server 2019 supports Service Bus 1.1 and Microsoft Workflow Manager 1.0 CU5 to run SharePoint Server 2013
workflows. For more information, see Install and configure workflow in SharePoint Server.
Visio Services - Silverlight Based Rendering
Visio Services has 2 options for rendering Visio diagrams: Microsoft Silverlight-based and PNG -based. Microsoft
Silverlight is a technology that will no longer be supported as of October 12, 2021. This means that, Silverlight-
based rendering will no longer be supported in SharePoint Server 2019. Visio Services will only render Visio
diagrams using the PNG -based technology.
SharePoint Business Intelligence Scenarios

For more information on SharePoint BI scenarios, review the SQL Server Reporting Services Team blog post,
Simplifying our SharePoint integration story.
New and improved features in SharePoint Server
2016

Learn about the new features and updates to existing features in SharePoint Server 2016.
For a comparison of SharePoint on-premises features between SharePoint 2013 and SharePoint Server 2016
editions, see SharePoint feature availability across on-premises solutions. For new features in SharePoint Server
2016 for end users, see What's new in SharePoint Server 2016.
Summary of features
The following table provides a summary of the new features that you can try out in this SharePoint Server 2016
release.
FEATURE DESCRIPTION MORE INFORMATION
Access Services New Access features are available when For more information, see Access
you deploy Access Services in Services plus Access client and server.
SharePoint Server 2016 .
Compliance features New compliance features for SharePoint For more information, see Compliance
Server 2016 include the document features.
deletion and in-place hold policies.
Customized web parts The compile time for customized XSLT NA

files used for Content Query, Summary
Links, and Table of Contents Web Parts
is improved.
Document Library accessibility SharePoint Server 2016 includes new For more information, see Document
document library accessibility features. Library accessibility.
Durable links Resource-based URLs now retain links NA

when documents are renamed or
moved in SharePoint.
Encrypted Connections SharePoint Server 2016 supports TLS For more information, see Encrypted
1.2 connection encryption by default. connections.
Fast Site Collection Creation The Fast Site Collection Creation feature For more information, see Fast Site
is a rapid method to create site Collection Creation.
collections and sites in SharePoint.
Filenames - expanded support for SharePoint Server 2016 now supports For more information, see File names -
special characters using some special characters in file expanded support for special
names that were blocked in previous characters.
versions.
Hybrid in SharePoint 2016 Hybrid in SharePoint Server 2016 For more information, see Hybrid in
enables you to integrate your on- SharePoint Server 2016.
premises farm with Office 365
productivity experiences, allowing you
to adopt the cloud at your own pace.
Identify and search for sensitive SharePoint Server 2016 now provides For more information, see Identify and
content the same data loss prevention search for sensitive content in both
capabilities as Office 365. SharePoint Server 2016 and OneDrive
documents.
Image and video previews You can now preview images and For more information, see Image and
videos in SharePoint Server 2016 video previews.
document libraries.
Information Rights Management SharePoint Server 2016 provides For more information, see Information
Information Rights Management (IRM) Rights Management.
capabilities to secure information by
encrypting and securing information on
SharePoint libraries with OneDrive for
Business.
Large file support SharePoint Server 2016 now supports For more information, see Large file
uploading and downloading files larger support.
than 2,047 MB.
MinRole MinRole is a new feature in SharePoint For more information, see MinRole farm
Server 2016 that allows a SharePoint topology.
farm administrator to define each
server's role in a farm topology.
Mobile experience SharePoint Server 2016 offers an For more information, see Mobile
improved mobile navigation experience. experience.
New features in November 2016 PU The November 2016 Public Update for For more information, see New features
for SharePoint Server 2016 (Feature SharePoint Server 2016 (Feature Pack in November 2016 PU for SharePoint
Pack 1) 1) offers seven new features for Server 2016 (Feature Pack 1).
SharePoint Server 2016.
New controls for working with SharePoint Server 2016 provides For more information, see New controls
OneDrive for Business controls at the top of your personal for working with OneDrive for Business.
document folders that make common
tasks in OneDrive for Business more
accessible.
New Recycle Bin in OneDrive and SharePoint Server 2016 adds a link for NA
Team sites the Recycle Bin in the left navigation
area of the OneDrive and Team sites.
Open Document Format (ODF) SharePoint Server 2016 adds support For more information, see Open
for Open Document Format (ODF) files Document Format (ODF) available for
to use in document library templates. document libraries.
Project Server New Project Server features are For more information, see Project
available in SharePoint Server 2016. Server 2016 .
ReFS file system support SharePoint Server 2016 now supports For more information about the ReFS
drives that are formatted with the ReFS file system, see Resilient File System
file system. Overview and Resilient file system.
SharePoint business intelligence SharePoint Server 2016 now supports For more information about SharePoint
SQL Server 2016 CTP 3.1 and the business intelligence, see Power Pivot
Power Pivot add-in and Power View. add-in and Power View are now
available to use with SharePoint Server
2016.
SharePoint Search SharePoint Search Server Application For more information, see SharePoint
has significant changes to its Search Service application.
deployment.
Sharing improvements SharePoint Server 2016 has many new For more information, see Sharing.
sharing improvements available.
Site Folders view SharePoint Server 2016 provides a new For more information, see Site folders
Site Folders view that lets you access view.
the document libraries in sites that
you're following.
Sites page pinning This new feature helps you see and For more information, see Sites page
follow sites. pinning.
SMTP Connection Encryption SharePoint Server 2016 supports For more information, see SMTP
sending email to SMTP servers that use connection encryption.
STARTTLS connection encryption.
SMTP ports (non-default) SharePoint Server 2016 adds support For more information, see Use SMTP
for SMTP servers that use TCP ports ports other than the default (25).
other than the default port (25).
Web Application Open Platform You can now rename files, create new NA
Interface Protocol (WOPI) files, and share files from within the
WOPI iframe on the browser page.
Detailed description of features

This section provides detailed descriptions of the new and updated features in SharePoint Server 2016.
Access Services plus Access client and server
The following new Access features are available when you deploy Access Services in SharePoint Server 2016:
Support apps for Office. For more information, see Spice up your Access app with add-ins for Office.
Access App Upgrade. For more information, see Upgrade an Access app.
Download in Excel feature available for users to pivot Access tables. For more information, see Introducing
a new feature in Access 2013 web apps-Download in Excel.
With the improved Related Item Control, you can do the following:
Choose from any existing view for the dialog box on the Related Item Control.
Add a new item on the Related Item Control when the parent record isn't saved.
Turn off the Add link at the bottom of the Related Item Control.
The Cascading Combo box is now available in Access. For more information, see Introducing a new user
experience feature in Access web apps: Cascading Controls.
Central Administration is no longer provisioned on all servers by default
SharePoint Server 2016 Central Administration is now provisioned on the first server in a farm by default when
using the SharePoint Products Configuration Wizard. Central Administration is not provisioned on additional
servers in a farm by default.
You can provision or unprovision Central Administration on individual servers in a farm, no matter what the
server role is by using the following methods:
The Services on Server page on Central Administration > System Settings
Microsoft PowerShell cmdlets:
New -SPCentralAdministration
Remove-SPCentralAdministration
The psconfig.exe -cmd adminvs operation
The SharePoint Products Configuration Wizard
NOTE
The state of Central Administration does not affect whether a server is considered compliant with MinRole. The MinRole
health rule will not attempt to provision or unprovision Central Administration.
Compliance features
The document deletion policy allows you to delete documents in users' OneDrive for Business sites after specific
periods of time. The In-Place Hold policy allows administrators to preserve documents, email, and other files.
For more information, see Overview of document deletion policies.
Document Library accessibility
The following features are now available for working in SharePoint Server 2016 document libraries:
Landmarks to a page make it easier to navigate, and there are alt text improvements for all major
navigation links.
Keyboard shortcuts are provided for the following document tasks:
Alt + N - N ew
Alt + E - E dit
Alt + U - U pload
Alt + M - M anage
Alt + S - S hare
Alt + Y - S y nchronization
Focus improvements, such as keeping focus on prior elements and focus trapping.
Announcements for upload progress.
Announcements for file name and file types when browsing folder and file lists.
Improved callout reading.
Fixed use of color issues for views switcher.
Updates to the Help documentation.
Encrypted connections
When you set up an SSL binding in Internet Information Services (IIS ) Manager to host your web application,
SharePoint uses TLS 1.2 connection encryption if your client application supports it. SharePoint also supports TLS
1.2 connection encryption when connecting to other systems, for example when crawling websites.
NOTE
A security vulnerability was identified in the SSL 3.0 protocol that can allow an attacker to decrypt data. For enhanced
security, some SharePoint features now disable SSL 3.0 connection encryption by default, as well as certain encryption
algorithms (for example RC4) with known weaknesses. SharePoint disables SSL 3.0 connection encryption by default for
some, but not all features. To ensure that SSL 3.0 is disabled for all features, you should disable it in Windows by editing the
Windows Registry. For more information, see the "Disable SSL 3.0 in Windows For Server Software", and "For Client
Software", workarounds in Microsoft Security Advisory 3009008.
Fast Site Collection Creation

This new feature provides templates that work at same level as SQL Server, which reduces the round trips
required between the SharePoint and SQL servers. Use the SPSiteMaster Microsoft PowerShell cmdlets to
create sites and site collections quickly.
File names - expanded support for special characters
SharePoint has historically blocked file names that included the &, ~, {, and } characters, file names that contained
a GUID, file names with leading dots, and file names longer than 128 characters. These restrictions are removed
in SharePoint Server 2016 and are now available to use.
IMPORTANT
Restricted characters such as % and # are still not allowed in file names. Page file names, such as wiki pages, may not contain
the following characters: " # % * : < > ? \ / | nor can they begin with a leading dot (period) character.
Hybrid in SharePoint Server 2016

In SharePoint Server 2016, new hybrid features are available to enable hybrid solutions.
Hybrid sites
Hybrid sites features allows your users to have an integrated experience while using SharePoint Server and
SharePoint Online sites:
Users can follow SharePoint Server and SharePoint Online sites, and see them consolidated in a single list.
Users have a single profile in Office 365, where all of their profile information is stored.
For more information, see SharePoint hybrid sites and search.
Hybrid OneDrive for Business
Hybrid sites features are used in concert with Hybrid OneDrive for Business (introduced in SharePoint Server
2013 with Service Pack 1 (SP1)):
Users can sync files with Office 365 and share them with others.
Users can access their files directly through Office 365 from any device.
Cloud hybrid search
Cloud hybrid search is a new hybrid search solution alternative. With cloud hybrid search:
You index all of your crawled content, including on-premises content, to your search index in Office 365.
You can set up the crawler in SharePoint Server 2016 to crawl the same content sources and use the same
search connectors in Office SharePoint Server 2007, SharePoint Server 2010, and SharePoint Server 2013.
When users query your search index in Office 365, they get unified search results from both on-premises
and Office 365 content.
For more information about cloud hybrid search, see the public Microsoft cloud hybrid search program on
Microsoft Office connection.
For more information, see Plan for hybrid OneDrive for Business.
For more information about the hybrid solutions available today, please visit the SharePoint Hybrid Solutions
Center.
Identify and search for sensitive content in both SharePoint Server 2016 and OneDrive documents
With this new capability, you can:
Search for sensitive content across SharePoint Server 2016, SharePoint Online, and OneDrive for
Business.
Leverage 51 built-in sensitive information types (credit cards, passport numbers, Social Security
numbers, and more).
Use DLP Queries from the eDiscovery site collection to discover sensitive content relating to common
industry regulations from the SharePoint eDiscovery Center, identify offending documents, and export a
report.
Turn on DLP Policies from the Compliance Policy Center site collection to notify end users and
administrators when documents with sensitive information are stored in SharePoint and automatically
protect the documents from improper sharing.
Information on configuring and using this feature is documented in SharePoint Online and Office 365. For more
information, see:
Search for sensitive content in SharePoint and OneDrive documents
Use DLP in SharePoint Online to identify sensitive data stored on sites
Image and video previews
In SharePoint Server 2016 when you post images and videos to a document library, you can see a preview by
hovering the mouse over the image or video, or by clicking on them.
Information Rights Management
For more information, see Secure and sync with Information Rights Management on OneDrive for Business and
Apply Information Rights Management to a list or library.
Large file support
Previous versions of SharePoint did not support uploading or downloading files larger than 2,047 MB. SharePoint
Server 2016 now allows you to upload or download larger files. You can configure the desired maximum file-size
limit on a per-web application basis in your SharePoint farm.
MinRole farm topology
The role of a server is specified when you create a new farm or join a server to an existing farm. SharePoint
automatically configures the services on each server based on the server role, optimizing the performance of the
farm based on that topology. There are eight predefined server roles that are available, as shown in the following
table.
SERVER ROLE DESCRIPTION
Front-end Service applications, services, and components that serve user

requests belong on front-end web servers. These servers are
optimized for low latency.
Application Service applications, services, and components that serve

back-end requests, such as background jobs or search crawl
requests, belong on Application servers. These servers are
optimized for high throughput.
Distributed Cache Service applications, services, and components that are

required for a distributed cache belong on Distributed Cache
servers.
Search Service applications, services, and components that are

required for search belong on Search servers.
Custom Custom service applications, services, and components that

do not integrate with MinRole belong on Custom servers. The
farm administrator has full control over which service
instances can run on servers assigned to the Custom role.
MinRole does not control which service instances are
provisioned on this role.
Single-Server Farm Service applications, services, and components required for a

single-machine farm belong on a Single-Server Farm. A
Single-Server Farm is meant for development, testing, and
very limited production use. A SharePoint farm with the
Single-Server Farm role cannot have more than one
SharePoint server in the farm.
Important:
The Standalone Install mode is no longer available in
SharePoint Server 2016. The Single-Server Farm role replaces
the Standalone Install mode available in previous SharePoint
Server releases. Unlike Standalone Install, the SharePoint
administrator must separately install and prepare Microsoft
SQL Server for SharePoint. The SharePoint administrator must
also configure the SharePoint farm services and web
applications, either manually or by running the Farm
Configuration Wizard.
Front-end with Distributed Cache Shared role that combines the Front-end and Distributed
Cache roles on the same server.
Note:
This shared role was introduced in the November Public
Update for SharePoint Server 2016 (Feature Pack 1).
SERVER ROLE DESCRIPTION
Application with Search Shared role that combines the Application and Search roles on
the same server.
Note:
This shared role was introduced in the November Public
Update for SharePoint Server 2016 (Feature Pack 1).
For more information about the MinRole feature, see Overview of MinRole Server Roles in SharePoint Server
2016 and Planning for a MinRole server deployment in SharePoint Server 2016.
Mobile experience
When you use a mobile device to access the home page for a SharePoint Server 2016 team site, you can tap tiles
or links on the screen to navigate the site. You can also switch from the mobile view to PC view, which displays site
pages as they are seen on a client computer. This view is also touch enabled.
New controls for working with OneDrive for Business
You can click a control to create new Office documents, upload files, synchronize your files for offline use, and
share your files. For more information, see "Simple controls" on The OneDrive Blog.
Open Document Format (ODF ) available for document libraries
The Open Document Format (ODF ) enables you to create new files in a document library and save as ODF files
so that users can edit the new file with a program they choose. For more information, see Set Open Document
Format (ODF ) as the default file template for a library.
Project Server 2016
Project Server 2016 for SharePoint Server 2016 has many new capabilities and features, including:
Resource Engagements: Now project managers can request needed resources from resource managers
to complete their projects. Also, resource managers can use the new heat map functionality to see where
resources are spending their time.
Multiple Timelines: Project and Portfolio managers can now create richer timelines that display multiple
timelines in a single view.
Simpler administration: Project Server now has multi-tenant storage capabilities and has combined data
storage with SharePoint. This greatly reduces IT overhead by eliminating the dedicated Project Server
database and improves backup and restore capabilities.
Cloud grade performance and scale: Many performance and scalability improvements that have been
added to Project Online have also been added to Project Server 2016.
For more information, see What's new for IT pros in Project Server 2016 Preview.
IMPORTANT
Project Server 2016 is installed with SharePoint Server 2016 Enterprise, though is licensed separately. For more information
about Project Server licensing, see Licensing Project.
Power Pivot add-in and Power View are now available to use with SharePoint Server 2016
SQL Server 2016 CTP 3.1 is now available. You can now download SQL Server 2016 CTP 3.1 to use the Power
Pivot for SharePoint add-in. You can also use Power View by installing SQL Server Reporting Services (SSRS ) in
SharePoint-integrated mode and the SSRS front-end add-in from the SQL Server installation media.
Download SQL Server 2016 CTP 3.1 from Microsoft Download Center.
The following SharePoint Server 2016 business intelligence features are available when you upgrade to SQL
Server 2016 CTP 3.1:
Power Pivot Gallery
Scheduled Data Refresh
Workbooks as a Data Source
Power Pivot Management Dashboard
Power View reports
Power View Subscriptions
Report Alerting
For more information, download the new Deploying SQL Server 2016 PowerPivot and Power View in SharePoint
2016 white paper. For details about configuring and deploying business intelligence in a multiple server
SharePoint Server 2016 farm, download Deploying SQL Server 2016 PowerPivot and Power View in a Multi-Tier
SharePoint 2016 Farm.
Request Manager service improvements
SharePoint Request Manager now provisions on the server roles shown in the following list, to support both
throttling and routing scenarios:
Application
Distributed Cache
Front-End
Additionally, the Request Manager service will no longer prevent sites from rendering when the service is enabled
while you have no routing rules defined.
Sharing
The following list shows the sharing improvements that are available for SharePoint Server 2016:
Create and Share folder
Sharing Hint
See who the folder is shared with when viewing a folder
Members can share
Improved invitation mail
One-click email to approve or deny a request for access
Recently Shared Items cache, see Enable the Recently Shared Items (RSI) cache to quickly populate the
Shared with Me view.
SharePoint Search Service application
SharePoint Search supports indexing of up to 500 million items per Search Server application. For more
information, see Overview of search architecture in SharePoint Server. For information about SharePoint cloud
hybrid search, see Learn about cloud hybrid search for SharePoint.
Simplified SSL configuration for Central Administration site
We've simplified the process for configuring Central Administration to use SSL bindings. The following command
parameters are now available to use:
New-SPCentralAdministration -Port <number> -SecureSocketsLayer
Set-SPCentralAdministration -Port <number> -SecureSocketsLayer
Psconfig.exe -cmd adminvs -port <number> -ssl
You must assign a server certificate to the Central Administration IIS web site by using the IIS administration
tools. The Central Administration web application won't be accessible until you do this.
If you specify port 443, it will automatically create an SSL binding instead of an HTTP binding even if you don't
include the SecureSocketsLayer or SSL parameters.
The Central Administration public AAM URL will be automatically updated to use the appropriate protocol
scheme, server name, and port number.
Site collection upgrades
There are three options available for upgrading site collections. For more information, see Upgrade a site
collection to SharePoint Server 2016.
SMTP connection encryption
The following list shows the SharePoint 2016 requirements that are needed to negotiate connection encryption
with an SMTP server:
1. STARTTLS must be enabled on the SMTP server.
2. The SMTP server must support the TLS 1.0, TLS 1.1, or TLS 1.2 protocol.
IMPORTANT
SSL 2.0 and SSL 3.0 protocols are not supported.
3. The SMTP server must have a server certificate installed.

4. The server certificate must be valid. Typically, this means that the name of the server certificate must match
the name of the SMTP server provided to SharePoint. The server certificate must also be issued by a
certificate authority that is trusted by the SharePoint server.
5. SharePoint must be configured to use SMTP connection encryption.
To configure SharePoint to always use SMTP connection encryption, open the SharePoint Central Administration
website and browse to System Settings > Configure outgoing e-mail settings and set the Use TLS
connection encryption drop-down menu to Yes. To configure SharePoint to always use SMTP connection
encryption in Microsoft PowerShell, use the Set-SPWebApplication cmdlet without the DisableSMTPEncryption
parameter. For example:
$WebApp = Get-SPWebApplication -IncludeCentralAdministration | ? { $_.IsAdministrationWebApplication -eq $true

}
Set-SPWebApplication -Identity $WebApp -SMTPServer smtp.internal.contoso.com -OutgoingEmailAddress
sharepoint@contoso.com -ReplyToEmailAddress sharepoint@contoso.com
To configure SharePoint to never use SMTP connection encryption in SharePoint Central Administration, browse
to System Settings > Configure outgoing email settings and set the Use TLS connection encryption drop-
down menu to No. To configure SharePoint to never use SMTP connection encryption in PowerShell, use the
Set-SPWebApplication cmdlet with the DisableSMTPEncryption parameter. For example:
}
Set-SPWebApplication -Identity $WebApp -SMTPServer smtp.internal.contoso.com -DisableSMTPEncryption -
OutgoingEmailAddress sharepoint@contoso.com -ReplyToEmailAddress
sharepoint@contoso.com
NOTE
If SharePoint is configured to use SMTP connection encryption, it will only send email messages if it successfully negotiates
connection encryption with the SMTP server. It will not fall back and send email messages unencrypted if connection
encryption negotiation fails. If SharePoint is not configured to use SMTP connection encryption, it will always send email
messages unencrypted, even if the SMTP server supports connection encryption. > Using SMTP connection encryption
does not enable SMTP authentication. SMTP requests are always sent anonymously.
Site folders view

For more information, see "Site folders" in The OneDrive Blog.
Sites page pinning
You can now pin sites that you see on the sites page. A pinned site shows at the top of the list of sites that you're
following.
Suite Navigation is themable
You can now apply themes to your Suite Navigation.
Use SMTP ports other than the default (25)
To configure SharePoint to use a non-default SMTP port open SharePoint Central Administration, browse to
System Settings > Configure outgoing email settings, and set the SMTP server port to the port number of
your SMTP server. To configure SharePoint to use a non-default SMTP port in PowerShell, use the
Set-SPWebApplication cmdlet with the SMTPServerPort parameter. For example:

}
Set-SPWebApplication -Identity $WebApp -SMTPServer smtp.internal.contoso.com -SMTPServerPort 587 -
OutgoingEmailAddress sharepoint@contoso.com -ReplyToEmailAddress
sh arepoint@contoso.com
Related Topics
What is SharePoint?
New features in November 2016 PU for SharePoint
Server 2016 (Feature Pack 1)

For a list of updates and associated KB articles for SharePoint Server 2016, SharePoint 2013, and SharePoint
2010, see SharePoint Updates.
Summary of features
The following table provides a summary of the new features and enhancements that are included in the
November 2016 Public Update for SharePoint Server 2016 (Feature Pack 1) release.
MinRole enhancements The MinRole feature in SharePoint For more information, see "Minrole
Server 2016 now includes two new enhancements" in Overview of MinRole
server roles and enhanced support for Server Roles in SharePoint Server 2016.
small farms.
SharePoint Custom Tiles SharePoint administrators can now add For more information, see Custom Tiles
SharePoint and Office 365 workloads as in SharePoint Server 2016.
custom tiles in SharePoint app launcher.
Hybrid Taxonomy Hybrid Taxonomy is a new solution that For more information, see SharePoint
you can use to create and maintain a Hybrid Taxonomy.
shared taxonomy between your
SharePoint Server 2016 farm and your
SharePoint Online tenant.
Administrative Actions Logging The Administrative Actions Logging For more information, see Using
feature provides logging around Administrative Actions logging in
common SharePoint administrative SharePoint Server 2016 topic.
actions to aid SharePoint administrators
in troubleshooting changes to their
farm.
OneDrive API for SharePoint on- The OneDrive API provides a support For more information, see OneDrive
premises and Office 365 for access to files located in SharePoint API.
Server 2016 and in Office 365. Use it to
work with data stored in OneDrive and
across SharePoint sites.
SharePoint Hybrid Auditing This new feature for SharePoint Server For more information, see SharePoint
2016 lets administrators view user Hybrid Auditing (Preview).
activity logs in the Microsoft 365 admin
center.
OneDrive for Business modern OneDrive for Business end user For more information, see Configure
experience experience has been updated with new the OneDrive for Business modern user
functionalities from O365. experience.
The OneDrive for Business modern user
experience requires an active Software
Assurance contract at the time it is
enabled.
See also
Concepts
SharePoint Server
Other Resources
What's new in SharePoint Server 2016
New features in September 2017 PU for SharePoint
Server 2016 (Feature Pack 2)

For a list of updates and associated KB articles for SharePoint Server 2016, SharePoint 2013, and SharePoint
2010, see SharePoint Updates.
SharePoint Framework client-side web part support with classic SharePoint pages is included in the September
2017 Public Update for SharePoint Server 2016 (Feature Pack 2).
SharePoint Server 2016 (Feature Pack 2)

SharePoint Server 2016 Feature Pack 2 contains SharePoint Framework client-side web part support with classic
SharePoint pages. SharePoint Server 2016 only supports using one version of the SharePoint Framework because
this version matches the server-side dependencies of the deployed packages. SharePoint Online always uses the
latest version of the SharePoint Framework. The reason for this is because SharePoint Online and SharePoint
Server 2016 don't have the same release cycles for new capabilities so they also need different resources from the
SharePoint Framework. For more information, see SharePoint Framework development with SharePoint 2016
Feature Pack 2 and Overview of the SharePoint Framework.
IMPORTANT
Feature Pack 2 contains all of the new features that shipped with Feature Pack 1. You don't need to separately install Feature
Pack 1 and then install Feature Pack 2. Feature Pack 2 is included in all future Public Updates for SharePoint Server 2016,
beginning with the September 2017 Public Update.
Related Topics
SharePoint Server
New features in November 2016 PU for SharePoint Server 2016 (Feature Pack 1)
What's new in SharePoint Server 2016
See also
Other Resources
Deploy SharePoint Framework web parts to SharePoint Server 2016 with Feature Pack 2
What's deprecated or removed from SharePoint
Server 2016

Learn about the features and functionality that are deprecated or removed in SharePoint Server 2016
Deprecated features are included in SharePoint Server 2016 for compatibility with previous product versions. For
information about new features in SharePoint Server 2016, see New and improved features in SharePoint Server
2016.
Features deprecated in SharePoint Server 2016

The following features and functionality have been deprecated or removed in SharePoint Server.
Duet Enterprise for Microsoft SharePoint
Duet Enterprise for Microsoft SharePoint and SAP cannot be deployed with SharePoint Server 2016. SharePoint
Server 2016 doesn't have any Duet components, so it will not install.
If you want to deploy Duet Enterprise for Microsoft SharePoint you must use SharePoint Server 2013 Enterprise
Edition.
SharePoint Foundation
SharePoint Foundation 2013 remains available for use. For more information, see SharePoint Foundation 2013.
Previous releases of SharePoint Server included SharePoint Foundation, a free edition of SharePoint that included
most of the core functionality and architecture provided by the commercial editions of SharePoint. SharePoint
Foundation is no longer available in the SharePoint Server 2016 release.
Standalone Install mode
SharePoint Server 2016 doesn't support the standalone install option, so it is no longer available in the setup
program. Use the MinRole feature during installation and choose one of the available install options. The Single
Server Farm option where everything is installed on the same computer is supported for dev/test/demo purposes.
When you use this option, you must install SQL Server yourself and then run the SharePoint Server 2016 farm
configuration wizard.. For more information, see "MinRole farm topology" in New and improved features in
ForeFront Identity Manager client (FIM )
Earlier versions of SharePoint used ForeFront Identity Manager client (FIM ) to synchronize between Active
Directory and SharePoint. SharePoint Server 2016 no longer uses FIM as the synchronization client. The default
process is Active Directory Import. You can also use any synchronization tool such as Microsoft Identity Manager
2016, or any third-party tool. We'll soon release tools to help you deploy and configure Microsoft Identity
Manager 2016 to work with SharePoint Server 2016 for identity synchronization.
Excel Services in SharePoint
Excel Services and its associated business intelligence capabilities are no longer hosted on SharePoint Server. Excel
Services functionality is now part of Excel Online in Office Online Server (this is the next version of Office Web
Apps Server), and SharePoint users can use the services from there. For more information, see Office Online
Server now available, Office Online Server, and Configure Excel Online administrative settings.
If you currently use Excel Services in SharePoint 2013 and upgrade to SharePoint Server 2016 you must also
deploy Office Online Server with Excel Online to ensure Excel Services functionality remains available.
The following Excel Services functionality has been deprecated:
Trusted data providers
Trusted file locations
Trusted data connection libraries
Unattended service account
Excel Services PowerShell cmdlets
Opening of Excel workbooks from SharePoint Central Administration site
The following Excel Services functionality requires Excel Online in Office Online Server:
Viewing and editing Excel workbooks in a browser (with or without the Data Model)
Excel Web Access web part for SharePoint
ODC file support (no longer requires Data Connection Libraries)
Programmability features such as JavaScript OM, User Defined Function Assemblies, SOAP and REST
protocol support
SharePoint BI capabilities
If you want to use Microsoft SQL Server Power Pivot for SharePoint or Microsoft Power View for SharePoint for
BI solutions with SharePoint Server 2016 you must install the Power Pivot or Power View add-ins for SQL Server
2016 RTM. The SQL Server 2014 (SP1) Power Pivot for SharePoint and Power View for SharePoint add-ins
cannot be deployed or used with SharePoint Server 2016. To deploy these add-ins you need to upgrade to SQL
Server 2016 RTM. For more information, see New and improved features in SharePoint Server 2016. The
following business intelligence features are available with SharePoint Server 2016 when you download SQL
Server 2016 RTM:
Power Pivot Gallery
Using another workbook's Data Model as a data source
Power View reports (standalone or embedded in Excel workbooks)
Power View Subscriptions and Report Alerting
BISM Link support
Tags and Notes

The Tags and Notes feature is deprecated in SharePoint Server 2016. This means that users can still create new
tags and notes and access any existing ones. However, we don't recommend using this feature because it will be
removed in the next release.
Administrators can archive all existing tags and notes by using the Export-SPTagsAndNotesData cmdlet.
Verify that you meet all of the following minimum requirements.
You must have membership in the securityadmin fixed server role on the SQL Server instance
You must have membership in the db_owner fixed database role on all databases that are to be updated.
You must be a member of the Administrators group on the server on which you are running the Microsoft
PowerShell cmdlet.
Export-SPTagsAndNotesData -Site <http://site.contoso.com> -FilePath <tagsandnotes.zip>
Where :
<http://site.contoso.com> is the URL to an existing SharePoint root site where you want to export the tags
and notes from.
<tagsandnotes.zip> is the name you give to the .zip file that you want to export.
Work Management Service Application

The Work Management Service Application has been removed from SharePoint Server 2016. The My Tasks and
associated Exchange Task Sync features have also been removed from SharePoint Server 2016. Both of these
features required the Work Management Service Application.
Stsadm.exe
We recommend that you use Microsoft PowerShell when you perform command-line administrative tasks. The
Stsadm command-line tool has been deprecated, but it is included to support compatibility with previous product
versions.
Getting started
What is SharePoint?
SharePoint is a powerful collaboration platform that lets you share and manage content, knowledge, and
applications to empower teamwork.
SharePoint Server can be used on-premises or with an Office 365 enterprise subscription to take advantage of all
the latest features. Share common resources and applications on sites. Use search to discover information and
expertise across your organization. And stay in the know with personalized news in SharePoint home and the
SharePoint mobile apps.
To learn more, go to Learn about SharePoint.
Where do I start?
If you are new to SharePoint Server, make a plan as to what you want to do and where you are going. If you have
never deployed SharePoint, consider how large an installation you need. Do you have a large enterprise
environment with hundreds or more licenses? Or do you have smaller deployment in mind? Your hardware
requirements and budget may also be a factor in your deployment.
Depending on your version, system requirements and prerequisites could vary.
ARE YOU DEPLOYING... READ
SharePoint Server 2019 2019 Hardware and software requirements
2019 Prerequisites
2016 Prerequisites
2013 Prerequisites
How large is your company?

ARE YOU... READ
A large enterprise and want to install SharePoint Server 2016? Install SharePoint Server 2016 on the farm servers
A smaller division or smaller company that will deploy a small Install SharePoint Server 2016 on one server
SharePoint 2016 farm?
I have SharePoint Server installed

Do you already have SharePoint Server installed and want to upgrade to a new version? Or apply the new feature
packs or updates?
WHAT DO YOU NEED TO DO? READ
I have SharePoint Server 2013 installed and want to upgrade Upgrade to SharePoint Server 2019
to SharePoint 2019
I have SharePoint Server 2013 installed and want to upgrade Upgrade to SharePoint Server 2016
to SharePoint 2016
I have SharePoint Server 2010 installed and want to upgrade Upgrade from SharePoint 2010 to SharePoint 2013
to SharePoint 2013
How do I apply updates to SharePoint Server 2013? Deploy software updates for SharePoint 2013
How do I apply updates to SharePoint Server 2016? Deploy software updates for SharePoint Server 2016
I have SharePoint Server and want to move to the cloud

Perhaps you already have SharePoint Server and are considering moving to the cloud. Maybe your plans for
migrating to the cloud are only for specific areas, or will be a gradual move. Learn about setting up your hybrid
environment and find out the different ways to migrate your content.
ARE YOU WANTING TO... READ
Decide which hybrid solution you should use for your Explore SharePoint Server hybrid
business?
Find out how you can move your data from on-premises to Migrate to SharePoint Online
SharePoint Online?

The following article provides information about authentication planning in SharePoint Server.
CONTENT DESCRIPTION
Secure Sockets Layer (SSL) and Describes the versions of the Secure
Transport Layer Security (TLS) protocol Sockets Layer (SSL) and Transport Layer
support in SharePoint Server Security (TLS) protocols that SharePoint
Server 2016 supports.
Enable TLS 1.1 and TLS 1.2 support in Describes how to enable Transport
SharePoint Server 2016 Layer Security (TLS) protocol versions
1.1 and 1.2 in a SharePoint Server 2016
environment. SharePoint Server 2016
fully supports TLS 1.1 and TLS 1.2.
Enable TLS and SSL support in Describes how to enable Transport

SharePoint 2013 Layer Security (TLS) protocol versions
1.1 and 1.2 in a SharePoint 2013
environment. SharePoint 2013 fully
supports TLS 1.1 and TLS 1.2.
Plan security hardening for SharePoint Learn about security hardening

Server requirements for SharePoint Server
2013 and SharePoint Server 2016.
Federal Information Processing Learn about SharePoint Server 2016

Standard security standards and and SharePoint Server 2013 support for
SharePoint Server Federal Information Processing
Standard (FIPS).
Plan for administrative and service accounts in
SharePoint Server

To install SharePoint Server, you have to have appropriate administrative and service accounts on servers running
SharePoint Server and SQL Server. After installation, you need to have appropriate administrative and service
accounts to modify and maintain the environment. The accounts that you require to complete these groups of tasks
are not necessarily the same. This article describes the accounts that you require after installation for a single
server environment and a server farm environment.
IMPORTANT
Do not use service account names that contain the symbol $ with the exception of using a Group Managed Service Account
for SQL Server.
Use this article along with Initial deployment administrative and service accounts in SharePoint Server.
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 the account requirements for using Secure Store service in SharePoint Server. For
more information, see Plan the Secure Store Service in SharePoint Server.
About administrative and service accounts

This section lists and describes the accounts that you must plan for to manage servers running SQL Server or
SharePoint Server. 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 SQL Server database software and to install
SharePoint Server.
ACCOUNT PURPOSE REQUIREMENTS

SQL Server service account The SQL Server service account is used Use either a domain user account or
to run SQL Server. It is the service preferably, a Group Managed Service
account for the following SQL Server Account.
services: If you plan to back up to or restore
MSSQLSERVER from an external resource, permissions
SQLSERVERAGENT to the external resource must be
If you do not use the default SQL Server granted to the appropriate account. If
instance, in the Windows Services you use a domain user account or
console, these services will be shown as Group Managed Service Account for the
the following: SQL Server service account, grant
MSSQL<InstanceName> permissions to that domain user
SQLAgent<InstanceName> 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 SQL Server was installed.
Farm administrator user account The farm administrator user account is a Domain user account.
uniquely identifiable account assigned Member of the Administrators group
to a SharePoint administrator. It is used on each SharePoint server in the farm.
to run the following: Member of the following SQL Server
Setup role (optional): sysadmin fixed server
SharePoint Products Configuration role.
Wizard 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 or a
member of the sysadmin fixed server
role on SQL.
Farm service account The farm service account is used to Domain user account.
perform the following tasks: Additional permissions are automatically
Act as the application pool identity for granted for the server farm account on
the SharePoint Central Administration Web servers and application servers
website. that are joined to a server farm.
Run the Microsoft SharePoint The server farm account is automatically
Foundation Workflow Timer Service. 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
This account should not be used
interactively by an administrator.
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 that you plan to implement.
For more information about service application endpoints, see Using Service Endpoints.
NOTE
Excel Services and User Profile Synchronization Service only apply to SharePoint 2013.
ACCOUNT SERVICE PURPOSE REQUIREMENTS
Service Application Endpoint Run SharePoint Services Domain user account

Instances and Windows
Services
SERVICE NAME IN SHAREPOINT SERVER IN SHAREPOINT FOUNDATION
Access Services X
Business Data Connectivity service X X
Secure Store Service X
Usage and Health Data Collection X

Service
User Profile Service X
Visio Graphics Service X
Word Automation services X
Excel Services X
Managed Metadata Service X
PerformancePoint Service X
Search Service X
NOTE
This account is 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. For Excel Services, Managed
Metadata service, PerformancePoint service, and Search service you must be a domain user account. Also Excel Services is
only available in SharePoint Server 2013.
Security Token Service X
Application Discovery and Load X X

Balancer Service
NOTE
This account is used as the identity for the service application endpoint application pool. This account must be the Farm
Service Account and the SharePoint Products Configuration Wizard automatically creates the application pool.
Unattended Service N/A Used to execute functions N/A

on behalf of the user or
service
Excel Services X
PerformancePoint Service X
Visio Graphics Service X
NOTE
Excel Services used with workbooks to refresh data. It is required when workbook connections specify "None" for
authentication, or when any credentials that are notWindows credentials are used to refresh data. PerformancePoint service
is used for authenticating with data sources. Visio service is used with documents to refresh data. It is required when
connecting to data sources that are external to SharePoint Server, such as SQL Server.
Default Content Access Search Crawl content Read access to the content
being crawled
SharePoint Server Search X
NOTE
The default account for crawling content. A Search service application administrator can create crawl rules to specify other
accounts to crawl specific content. 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. Requires Manage auditing and security log right in the Local User Policy on Windows file
servers it is configured to crawl.
Search Service Search Run the Windows Search Be a domain user account
services
SharePoint Server Search X
Farm administrator User Profile Synchronization Runs the Forefront Identity Farm administrator account;
Service Manager services Local administrator where
the User Profile
Synchronization Service is
started
User Profile Synchronization Service X N/A
Synchronization Connection User Profile Service Connect to user identity Replicate directory changes
stores (Active Directory), read
access (other directories)
User Profile Service X N/A
NOTE
Replicating Directory Changes permissions on the configuration partition of the domains being synchronized if the NetBIOS
and fully qualified domain name (FQDN) names do not match.
App Management Service N/A Used to install SharePoint N/A

Add-ins
App management X X
PowerPoint Conversion PowerPoint Conversion Convert PowerPoint files to Farm administrator role
Service Services other file formats (SharePoint Server 2013
only)
PowerPoint conversion service X

Machine Translation service Machine Translation service Perform automated machine N/A
translations
Machine Translation service X
Access Services 2013 Access Services Interact with Access 2013 N/A
databases in a browser
Access Services in SharePoint Server X

2013
Work Management Work Management service Provides task aggregation N/A

across SharePoint, Exchange,
and Project Server.
Work management X
Distributed Cache AppFabric Windows service Runs Distributed Cache N/A

operations
Distributed Cache X X
NOTE
Some of the features that use the Distributed Cache service include:Newsfeeds, Authentication, OneNote client access,
Security Trimming, and improves Page load performance. At least one Distributed Cache server is required in the farm.
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 that you plan to implement.
ACCOUNT PURPOSE
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 that are associated with the
web applications that reside in the application pool.
Single server standard requirements

If you are deploying to a single server, 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
that 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 in SharePoint Server.
Server farm requirements

If you are deploying to more than one server, 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 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 the Configuration
Wizard. 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. The Configuration Wizard
adds this role to the following databases:
SharePoint_Config database (configuration database)
SharePoint_Admin content 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.
Technical reference: Account requirements by scenario

This section lists account requirements by scenario:
Server farm standard requirements
IMPORTANT
We do not recommend this configuration in a production environment.

ACCOUNT REQUIREMENTS
SQL Server service Local System account (default)
Farm administrator user account Member of the Administrators group on the local computer.
Farm service Network Service (default) No manual configuration is

necessary.
Service application accounts
IMPORTANT
Accounts in this table apply only to SharePoint Server.
SharePoint Server Search Service By default, this account runs as the Local System account. If
you want to crawl remote content by changing the default
content access account or by using crawl rules, change this to
a domain user account. If you do not change this account to a
domain user account, you cannot change the default content
access account to a domain user account or add crawl rules to
crawl this content. This restriction is designed to prevent
elevation of privilege for any other process running as the
Local System account.
Default Content Access No manual configuration is necessary if this account is only

crawling local farm content. If you want to crawl remote
content by using crawl rules, change this to a domain user
account, and apply the requirements listed for a server farm.
Content Access Same requirement as the default content access account.
Profile Synchronization account Same requirements as server farm.
Excel Services Unattended Service Must be a domain user account.
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


SQL Server service account The SQL Server service account is used Use either a domain user account or
to run SQL Server. It is the service preferably, a Group Managed Service
account for the following SQL Server Account.
services: If you plan to back up to or restore
MSSQLSERVER from an external resource, permissions
SQLSERVERAGENT to the external resource must be
If you do not use the default SQL Server granted to the appropriate account. If
instance, in the Windows Services you use a domain user account or
console, these services will be shown as Group Managed Service Account for the
the following: SQL Server service account, grant
MSSQL<InstanceName> permissions to that domain user
SQLAgent<InstanceName> 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 SQL Server was installed.
Farm administrator user account The farm administrator user account is a Domain user account.
uniquely identifiable account assigned Member of the Administrators group
to a SharePoint administrator. It is used on each SharePoint server in the farm.
to run the following: Member of the following SQL Server
Setup role (optional): sysadmin fixed server
SharePoint Products Configuration role.
Wizard 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 or a
member of the sysadmin fixed server
role on SQL.
perform the following tasks: Additional permissions are automatically
Act as the application pool identity for granted for the server farm account on
the SharePoint Central Administration Web servers and application servers
website. that are joined to a server farm.
Run the Microsoft SharePoint The server farm account is automatically
Foundation Workflow Timer Service. added as a SQL Server login on the
computer that runs SQL Server. The
account is added to the following SQL
Server security roles:
* db_owner fixed database role for all
SharePoint databases in the server farm
Service application service accounts
IMPORTANT
Profile Synchronization account and Excel Services unattended service account only apply to SharePoint Server.
SharePoint Server 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,
administration content database, the search administration
database, crawl databases. Full Control access to the index
partitions on the query servers.
Default content access account Must be a domain user account. Must not be a member of the
Farm Administrators group. Read access to external or secure
content sources that you want to crawl by using this account.
For sites that are not a part of the server farm, this account
must explicitly be granted Full Read permissions on the web
applications that host the sites. The following are automatically
configured: Full Read permissions are automatically granted to
content databases hosted by the server farm.
Content access account Read access to external or secure content sources that this
account is configured to access. For web sites that are not a
part of the server farm, this account must explicitly be granted
Full Read permissions on the web applications that host the
sites.
Profile Synchronization account Read access to the directory service. The account must have
the Replicate Changes permission in Active Directory. Manage
User Profiles personalization services permission. View
permissions on entities used in Business Data Catalog import
connections.
Excel Services unattended service account Must be a domain user account.
Application pool identity No manual configuration is necessary. The following are

automatically configured: Membership in the
SP_DATA_ACCESS 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 automatic password change in SharePoint Server

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 whether 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.
Configure managed accounts

SharePoint Server supports how to create managed accounts to improve security and guarantee application
isolation. By 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 Server. You can
map managed accounts to various services and web applications in the farm.
Reset 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 that are
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. By using the automatic password change feature, you can now
register managed accounts and enable SharePoint Server to control account passwords. Users have to be notified
about planned password changes and related service interruptions. However, the accounts that are 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.
Detect password expiration

IT departments typically impose a policy requiring that all domain account passwords be reset regularly, for
example, every 60 days. SharePoint Server can be configured to detect imminent password expiration, and send an
e-mail notification to a designated administrator. Even without requiring administrator intervention, SharePoint
Server can be configured to generate and reset passwords automatically. The automatic password reset schedule is
also configurable to guarantee that the impact of possible service interruptions during a password reset will be
minimal.
Reset the account password immediately

You can always override any automatic password reset schedule and force an immediate service account password
reset by using a specific password value. In this scenario, the password for the service account can also be changed
in AD DS by SharePoint Server. The new password is then immediately propagated to other servers in the farm.
Synchronize SharePoint Foundation account passwords with Active

Directory Domain Services
If AD DS and SharePoint Server account passwords are not synchronized, services in the SharePoint farm won't
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.
Reset 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 Microsoft 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 Server 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 they are necessary. If the account password has not yet been
changed, then SharePoint Server 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 Server
will attempt to commit a password change. If it is unable to commit the password change, it will retry by 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.
Service impact when you change passwords

When an administrator performs a password change for the servers in the SharePoint search topology, there is an
implied query downtime when the services are restarted. The query downtime is typically in the range of 3-5
minutes.
See also
Concepts
Configure automatic password change in SharePoint Server
Authentication overview for SharePoint Server

SharePoint Server requires authentication for the following types of interactions:
Users who access on-premises SharePoint resources
Apps that access on-premises SharePoint resources
On-premises servers that access on-premises SharePoint resources, or vice versa
User authentication in SharePoint Server

User authentication is the validation of a user's identity against an authentication provider, which is a directory or
database that contains the user's credentials and can verify that the user submitted them correctly. User
authentication occurs when a user attempts to access a SharePoint resource.
SharePoint Server supports claims-based authentication.
The result of a claims-based authentication is a claims-based security token, which the SharePoint Security Token
Service (STS ) generates.
SharePoint Server supports Windows, forms-based, and Security Assertion Markup Language (SAML )-based
claims authentication. For information about how these three authentication methods work, see the following
videos.
NOTE
The information in the videos applies to SharePoint Server 2013 and SharePoint Server 2016.
Windows claims authentication in SharePoint Server 2013 and 2016 video
Forms-based claims authentication in SharePoint Server 2013 and 2016 video
SAML -based claims authentication in SharePoint Server 2013 and 2016 video
For more information, see Plan for user authentication methods in SharePoint Server.
App authentication in SharePoint Server

App authentication is the validation of a remote SharePoint app's identity and the authorization of the app and an
associated user of a secured SharePoint resource request. App authentication occurs when an external component
of a SharePoint Store app or an App Catalog app, such as a web server that is located on the intranet or the
Internet, attempts to access a secured SharePoint resource.
For example, suppose that a user opens a SharePoint page that contains an IFRAME of a SharePoint app, and that
IFRAME needs an external component, such as a server on the intranet or the Internet, to access a secured
SharePoint resource in order to render the page. The external component of the SharePoint app must be
authenticated and authorized so that SharePoint provides the requested information and the app can render the
page for the user.
Note that if the SharePoint app does not require a SharePoint secured resource to render the page for the user,
app authentication is not needed. For example, a SharePoint app that provides weather forecast information and
only has to access a weather information server on the Internet does not have to use app authentication.
App authentication is a combination of two processes:
Authentication
Verifying that the application has registered correctly with a commonly trusted identity broker
Authorization
Verifying that the application and the associated user for the request has the appropriate permissions to
perform its operation, such as accessing a folder or list or executing a query
To perform app authentication, the application obtains an access token either from the Microsoft Azure Access
Control Service (ACS ) or by self-signing an access token using a certificate that SharePoint Server trusts. The
access token asserts a request for access to a specific SharePoint resource and contains information that identifies
the app and the associated user, instead of the validation of the user's credentials. The access token is not a logon
token.
For SharePoint Store apps, an example of the authentication process is as follows:
1. A user opens a SharePoint web page that contains an IFRAME that has to be rendered by a SharePoint
Store app, which is hosted on the Internet and uses ACS as its trust broker. To render the IFRAME for the
user, the SharePoint Store app must access a SharePoint resource.
2. The SharePoint STS requests and receives a context token from ACS.
3. SharePoint sends the requested web page together with the context token to the user's web browser.
4. The user's web browser sends a request for the IFRAME's content and the context token to the SharePoint
Store app server on the Internet.
5. The SharePoint Store app server requests and receives an access token from ACS.
6. The SharePoint Store app server sends the SharePoint resource request and the access token to the
SharePoint server.
7. The SharePoint server authorizes the access, checking both the app's permissions, which were specified
when the app was installed, and the associated user's permissions.
8. If permitted, SharePoint sends the requested data to the SharePoint Store app server on the Internet.
9. The SharePoint Store app server on the Internet sends the IFRAME results to the web browser, which
renders the IFRAME portion of the page for the user.
Notice how the SharePoint Store app has accessed SharePoint server resources without having to obtain the
user's credentials. The access was authenticated through ACS, which is trusted by the server running SharePoint
Server, and authorized through the set of app and user permissions.
For SharePoint App Catalog apps, an example of the authentication process is as follows:
1. A user opens a SharePoint web page that contains an IFRAME that has to be rendered by an App Catalog
app that is hosted on the intranet and uses a self-signed certificate for its access tokens. To render the
IFRAME for the user, the App Catalog app must access a SharePoint resource.
2. SharePoint sends the requested page along with the IFRAME to the user's web browser.
3. The user's web browser sends a request for the IFRAME's content to the App Catalog app server on the
intranet.
4. The App Catalog app server authenticates the user and generates an access token, signed with its self-
signed certificate.
5. The App Catalog app server sends the SharePoint resource request and the access token to the SharePoint
server.
6. The SharePoint server authorizes the access, checking both the app's permissions, which were specified
when the app was installed, and the associated user's permissions.
7. If permitted, the SharePoint server sends the requested data to the App Catalog app server on the intranet.
8. The App Catalog app server sends the IFRAME results to the web browser, which renders the IFRAME
portion of the page for the user.
NOTE
App Catalog apps can use either ACS or a self-signed certificate for their access tokens.
For more information, see Plan for app authentication in SharePoint 2013 Preview.
Server-to-server authentication in SharePoint Server

Server-to-server authentication is the validation of a server's request for resources that is based on a trust
relationship established between the STS of the server that runs SharePoint Server and the STS of another server
that supports the OAuth server-to-server protocol, such as on-premises running SharePoint Server, Exchange
Server 2016, Skype for Business 2016, or Azure Workflow Service, and SharePoint Server running in Office 365.
Based on this trust relationship, a requesting server can access secured resources on the SharePoint server on
behalf of a specified user account, subject to server and user permissions.
For example, a server running Exchange Server 2016 can request resources of a server running SharePoint Server
for a specific user account. This contrasts with app authentication, in which the app does not have access to user
account credential information. The user can be currently signed in to the server making the resource request or
not, depending on the service and the request.
When a server running SharePoint Server attempts to access a resource on a server or a server attempts to access
a resource on a server running SharePoint Server, the incoming access request must be authenticated so that the
server accepts the incoming access request and subsequent data. Server-to-server authentication verifies that the
server running SharePoint Server and the user whom it is representing are trusted.
The token that is used for a server-to-server authentication is a server-to-server token, not a logon token. The
server-to-server token contains information about the server that requests access and the user account on whose
behalf the server is acting.
For on-premises servers, an example basic process is as follows:
1. A user opens a SharePoint web page that requires information from another server (for example, display
the list of tasks from both SharePoint Server and Exchange Server 2016).
2. SharePoint Server generates a server-to-server token.
3. SharePoint Server sends the server-to-server token to the other server.
4. The other server validates the SharePoint server-to-server token.
5. The other server sends a message to SharePoint Server to indicate that the sent server-to-server token was
valid.
6. The service on the server running SharePoint Server accesses the data on the server.
7. The service on the server running SharePoint Server renders the page for the user.
When both servers are running in Office 365, an example process is as follows:
1. A user opens a SharePoint web page that requires information from another server (for example, display
the list of tasks from both SharePoint Online and Exchange Online).
2. SharePoint Online requests and receives a server-to-server token from ACS.
3. SharePoint Online sends the server-to-server token to the Office 365 server.
4. The Office 365 server verifies the user identity in the server-to-server token with ACS.
5. The Office 365 server sends a message to SharePoint Online to indicate that the sent server-to-server
token was valid.
6. The service on SharePoint Online accesses the data on the Office 365 server.
7. The service on SharePoint Online renders the page for the user.
For more information, see Plan for server-to-server authentication in SharePoint Server.
Plan for user authentication methods in SharePoint
Server

Learn the user authentication types and methods that are supported by SharePoint Server and how to
determine which ones to use for web applications and zones.
Introduction
User authentication is the validation of a user's identity against an authentication provider, which is a directory
or database that contains the user's credentials and can confirm the user submitted them correctly. An example
of an authentication provider is Active Directory Domain Services (AD DS ). Other terms for authentication
provider are user directory and attribute store.
An authentication method is a specific exchange of account credentials and other information that assert a user's
identity. The result of the authentication method is proof, typically in the form of a token that contains claims,
that an authentication provider has authenticated a user.
An authentication type is a specific way of validating credentials against one or more authentication providers,
sometimes using an industry standard protocol. An authentication type can use multiple authentication
methods.
After a user's identity is validated, the authorization process determines which sites, content, and other features
the user can access.
Your planning for user authentication types and methods should determine the following:
The user authentication types and methods for each web application and zone
The authentication infrastructure needed to support the determined authentication types and methods
NOTE
Windows classic mode authentication is no longer supported in SharePoint Server 2016.
Claims-based authentication
User identity in 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 have 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 out to third-party authentication providers
and multi-vendor environments that support Internet, partner, or cloud-based computing models.
With claims-based identities, a user obtains a digitally signed security token from a commonly trusted identity
provider. The token contains a set of claims. Each claim represents a specific item of data about a user such as his
or her name, group memberships, and role on the network. Claims-based authentication is user authentication
that uses claims-based identity technologies and infrastructure. Applications that support claims-based
authentication obtain a security token from a user, rather than credentials, and use the information within the
claims to determine access to resources. No separate query to a directory service such as 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 the Security Assertion Markup Language
(SAML ).
For more information about claims-based authentication, see the following resources:
Claims-based Identity for Windows (white paper)
Windows Identity Foundation home page
Due to the widespread use of claim-based authentication for user authentication, server-to-server
authentication, and app authentication, we recommend claims-based authentication for all web applications and
zones of a SharePoint Server farm. For more information, see Plan for server-to-server authentication in
SharePoint Server. When you use claims-based authentication, all supported authentication methods are
available for your web applications and you can take advantage of new features and scenarios in SharePoint
Server that use server-to-server authentication and app authentication.
For claims-based authentication, SharePoint Server automatically changes all user accounts to claims identities.
This results in a security token (also known as 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. SharePoint Server can use claims that are included in
SAML -based tokens. 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 Server.
You do not have to be a claims architect to use claims-based authentication in SharePoint Server. However,
implementing SAML token-based authentication requires coordination with administrators of your claims-
based environment, as described in Plan for SAML token-based authentication.
Classic mode authentication in SharePoint Server 2013
In SharePoint 2013, when you create a web application in Central Administration, you can only specify
authentication types and methods for claims-based authentication. In previous versions of SharePoint, you could
also configure classic mode authentication for web applications in Central Administration. Classic mode
authentication uses Windows authentication and SharePoint 2013 treats the user accounts as AD DS accounts.
To configure a web application to use classic mode authentication, you must use the New-SPWebApplication
PowerShell cmdlet to create it. SharePoint 2010 Products web applications that are configured for classic mode
authentication retain their authentication settings when you upgrade to SharePoint 2013. However, we
recommend that you migrate your web applications to claims-based authentication before upgrading to
SharePoint 2013.
A SharePoint 2013 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 more information about migrating before upgrading, see Migrate from classic-mode to claims-based
authentication.
For more information about migrating after upgrading, see Migrate from classic-mode to claims-based
authentication in SharePoint Server.
For information about how to create web applications that use classic mode authentication in SharePoint 2013,
see Create web applications that use classic mode authentication in SharePoint Server. Note that you cannot
migrate a web application that uses claims-based authentication to use classic mode authentication.
IMPORTANT
Office Online can be used only by SharePoint 2013 web applications that use claims-based authentication. Office Online
rendering and editing will not work on SharePoint 2013 web applications that use classic mode authentication. If you
migrate SharePoint 2010 web applications that use classic mode authentication to SharePoint 2013, you must migrate
them to claims-based authentication to allow them to work with Office Online.
Supported authentication types and methods

SharePoint Server supports a variety of authentication methods and authentication providers for the following
authentication types:
Windows authentication
Forms-based authentication
SAML token-based authentication
Windows authentication
The Windows authentication type takes advantage of your existing Windows authentication provider (AD DS )
and the authentication protocols that a Windows domain environment uses to validate the credentials of
connecting clients. Windows authentication method, which is used by both claims-based authentication include
the following:
NTLM
Kerberos
Digest
Basic
For more information, see Plan for Windows authentication in this article.
Watch the Windows claims authentication in SharePoint 2013 and SharePoint Server 2016 video
Although not a Windows authentication type, SharePoint Server also supports anonymous authentication.
Users can access SharePoint content without validating their credentials. Anonymous authentication is disabled
by default. You typically use anonymous authentication when you use SharePoint Server to publish content that
does not require security and is available for all users, such as a public Internet website.
Note that in addition to enabling anonymous authentication, you must also configure anonymous access
(permissions) on sites and site resources.
NOTE
Internet Information Services (IIS) websites that are created by SharePoint for serving web applications always have the
Anonymous Authentication and Forms Authentication methods enabled, even when the SharePoint setting for
Anonymous and Forms Authentication are disabled. This is intentional and disabling Anonymous or Forms Authentication
directly in the IIS settings will result in errors in the SharePoint site.
Forms-based authentication is a claims-based identity management system that is based on ASP.NET
membership and role provider authentication. Forms-based authentication can be used against credentials that
are stored in an authentication provider, such as the following:
AD DS
A database such as a SQL Server database
An Lightweight Directory Access Protocol (LDAP ) data store such as Novell eDirectory, Novell Directory
Services (NDS ), or Sun ONE
Forms-based authentication validates users based on credentials that users type in a logon form (typically a web
page). Unauthenticated requests are redirected to a logon page, where a user must provide valid credentials and
submit the form. The system issues a cookie for authenticated requests that contains a key for reestablishing the
identity for subsequent requests.
Watch the forms-based claims authentication in SharePoint 2013 and SharePoint Server 2016 video
NOTE
With forms-based authentication, the user account credentials are sent as plaintext. Therefore, you should not use forms-
based authentication unless you are also using Secure Sockets Layer (SSL) to encrypt the website traffic.
For more information, see Plan for forms-based authentication.

SAML token-based authentication
SAML token-based authentication in SharePoint Server uses the SAML 1.1 protocol and the WS -Federation
Passive Requestor Profile (WS -F PRP ). It requires coordination with administrators of a claims-based
environment, whether it is your own internal environment or a partner environment. If you use Active Directory
Federation Services (AD FS ) 2.0, you have a SAML token-based authentication environment.
A SAML token-based authentication environment includes an identity provider security token service (IP -STS ).
The IP -STS issues SAML tokens on behalf of users whose accounts are included in the associated authentication
provider. Tokens can include any number of claims about a user, such as a user name and the groups to which
the user belongs. An AD FS 2.0 server is an example of an IP -STS.
SharePoint Server takes advantage of claims that are included in tokens that an IP -STS issues to authorized
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 Server, 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 represent
multiple RP -STS entries in the IP -STS.
Watch the SAML -based claims authentication in SharePoint 2013 and SharePoint Server 2016 video
The set of authentication providers for SAML token-based authentication depends on the IP -STS in your claims
environment. If you use AD FS 2.0, authentication providers (known as attribute stores for AD FS 2.0) can
include the following:
Windows Server 2003 Active Directory and AD DS in Windows Server 2008
All editions of SQL Server 2005 and SQL Server 2008
Custom attribute stores
For more information, see Plan for SAML token-based authentication.
Choosing authentication types for LDAP environments
Forms-based authentication or SAML token-based authentication can use LDAP environments. You should use
the authentication type that matches your current LDAP environment. If you do not already have an LDAP
environment, we recommend that you use forms-based authentication because it is less complex. However, if
your authentication environment already supports WS -Federation 1.1 and SAML 1.1, then we recommend
SAML. SharePoint Server has a built-in LDAP provider.
Plan for Windows authentication

The process of planning and implementing Windows authentication methods is similar for claims-based
authentication. Claims-based authentication for a web application does not increase the complexity of
implementing Windows authentication methods. This section summarizes the planning for the Windows
authentication methods.
NTLM and the Kerberos protocol
Both NTLM and the Kerberos protocol are Integrated Windows authentication methods, which let users
seamlessly authenticate without prompts for credentials. For example:
Users who access SharePoint sites from Internet Explorer use the credentials under which the Internet
Explorer process is running to authenticate. By default, these credentials are the credentials that the user
used to log on to the computer.
Services or applications that use Integrated Windows authentication methods to access SharePoint
resources attempt to use the credentials of the running thread, which by default is the identity of the
process, to authenticate.
NTLM is the simplest form of Windows authentication to implement and typically requires no additional
configuration of authentication infrastructure. Simply select this option when you create or configure the web
application.
The Kerberos protocol 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 Server.
The reasons why you should consider Kerberos authentication are as follows:
The Kerberos protocol is the strongest Integrated Windows authentication protocol, and supports
advanced security features including Advanced Encryption Standard (AES ) encryption and mutual
authentication of clients and servers.
The Kerberos protocol allows for delegation of client credentials.
Of the available secure authentication methods, Kerberos requires the least amount of network traffic to
AD DS 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.
The Kerberos protocol is an open protocol that many platforms and vendors support.
The reasons why Kerberos authentication might not be appropriate are as follows:
Kerberos authentication requires more configuration of infrastructure and environment than other
authentication methods to function correctly. In many cases, domain administrator permission is required
to configure the Kerberos protocol. Kerberos authentication can be difficult to set up and manage.
Misconfiguring Kerberos can prevent successful authentication to your sites.
Kerberos authentication requires client computer connectivity to a KDC and to an AD DS domain
controller. In a Windows deployment, the KDC is an AD DS domain controller. While this is a common
network configuration on an organization intranet, Internet-facing deployments are typically not
configured in this manner.
The following steps summarize 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 Server farm.
4. Configure specific services within the farm to use specific accounts.
5. Create the web applications that will use Kerberos authentication.
Digest and Basic
With the Digest authentication method, the user account credentials are sent as an MD5 message digest to the
Internet Information Services (IIS ) service on the web server that hosts the web application or zone. With the
Basic authentication method, the user account credentials are sent as plaintext. Therefore, you should not use the
Basic authentication method unless you are also using SSL to encrypt the website traffic.
You might have to use these older authentication methods if your environment uses web browsers or services
that only support Digest or Basic authentication to websites.
Unlike the NTLM, Kerberos, and Anonymous authentication methods, you configure Digest and Basic
authentication methods from the properties of the web site that corresponds to the web application or zone in
the Internet Information Services (IIS ) snap-in.
If you are using claims-based authentication, see the following:
Configure digest authentication for a claims-based web application in SharePoint Server
Configure basic authentication for a claims-based web application in SharePoint Server
Plan for forms-based authentication

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. SharePoint Server uses the standard ASP.NET role manager interface to collect group
information about the current user. Each ASP.NET role is treated as a domain group by the authorization
process in SharePoint Server. You register role managers in the Web.config file exactly as you register
membership providers for authentication.
If you want to manage membership users or roles from the Central Administration website, you must register
the membership provider and the role manager in the Web.config file for the Central Administration website.
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 in SharePoint Server
Plan for SAML token-based authentication

The architecture for implementing SAML token-based providers includes the following components:
SharePoint Security Token Service This service creates the SAML tokens that the farm uses. 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-based authentication. This
service is also used for authentication methods that are implemented for web applications that use
claims-based authentication. This includes Windows authentication, forms-based authentication, and
SAML token-based authentication.
Token-signing certificate (ImportTrustCertificate) This is the certificate that you export from an IP -
STS and then copy to one server in the farm and add it to the farm's Trusted Root Authority list. Once you
use this certificate to create an SPTrustedIdentityTokenIssuer, you cannot use it to create another one. 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 all 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 mapping of 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 Server 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. You can add more realms after you create the
SPTrustedIdentityTokenIssuer. 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 identifier 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 you add a
realm to the SPTrustedIdentityTokenIssuer, you must also add it to the IP -STS as a relying party. The
SPTrustedIdentityTokenIssuer object is replicated across servers in the SharePoint Server farm.
Relying party security token service (RP -STS ) In SharePoint Server, 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
Server 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 shows the SharePoint Server SAML token claims architecture.
SAML token claims architecture
The SPTrustedIdentityTokenIssuer object is created with several parameters, which include the following:
A single identity claim.
A single SignInURL parameter.
The SignInURL parameter specifies the URL to redirect a user request to in order to authenticate to the
IP -STS.
A single Wreply parameter.
Some IP -STS servers require the Wreply parameter, which is set to either true or false. False is the
default. Use the Wreply parameter only if it is required by the IP -STS.
Multiple realms.
Multiple claims mappings.
To implement SAML token-based authentication with SharePoint Server, use the following steps which require
planning in advance:
1. Export the token-signing certificate from the IP -STS. Copy the certificate to a server in the SharePoint
Server farm.
2. Define the claim that will be used as the unique identifier of the user. This is known as the identity claim.
The user principal name (UPN ) or user e-mail name is frequently used 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. You use Microsoft PowerShell to create claims mappings.
3. Define additional claims mappings. Define the additional claims from the incoming token that the
SharePoint Server farm will use. User roles are an example of a claim that can be used to assign
permissions to resources in the SharePoint Server farm. All claims from an incoming token that do not
have a mapping will be discarded.
4. Use PowerShell to create a new authentication provider 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 you create the SPTrustedIdentityTokenIssuer, 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 you add to the SPTrustedIdentityTokenIssuer, you must create an RP -STS entry
on the IP -STS. You can do this before the SharePoint web application exists. Regardless, you must plan
the URL before you create the web applications.
6. For an existing or new SharePoint web application, configure it to use the newly created authentication
provider. The authentication provider is displayed as a trusted identity provider in Central Administration
when you create a 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 configured providers are displayed as options in Central Administration.
Claims from different trusted STS environments will not conflict.
If you implement SAML token-based authentication with a partner company and your own environment
includes an IP -STS, we recommend that you and the administrator of your internal claims environment establish
a one-way trust relationship from your internal IP -STS to the partner STS. This approach does not require you
to add an authentication provider to your SharePoint Server farm. It also enables your claims administrators to
manage the whole claims environment.
IMPORTANT
You no longer have to set network load balancing to single affinity when you are using claims-based authentication in
SharePoint Server.
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 resolves, regardless of whether it is a valid user, group, or claim. If your SharePoint Server
solution uses SAML token-based authentication, plan to create a custom claims provider that implements custom search
and name resolution.
For detailed steps to configure SAML token-based authentication using AD FS, see Configure SAML -based
claims authentication with AD FS in SharePoint Server.
Planning zones for web applications

Zones represent different logical paths to gain access to the same sites in a web application. Each web
application can include as many as five zones. When you create a web application, Central Administration
creates the zone named default. To create additional zones, extend the web application and select one of the
remaining zone names: intranet, extranet, Internet, or custom.
Your plan for zones will depend on the following:
Claims-based authentication (recommended) — You can implement multiple authentication providers on a
single zone. You can also use multiple zones.
Implementing more than one type of authentication on a single zone
If you use claims-based authentication and implement more than one authentication method, we recommend
that you implement multiple authentication methods on the default zone. The result is the same URL for all
users.
When you implement multiple authentication methods on the same zone, the following restrictions apply:
You can implement only one instance of forms-based authentication on a zone.
Central Administration allows you to use both an Integrated Windows method and Basic at the same
time. Otherwise, you cannot implement more than one type of Windows authentication on a zone.
If multiple SAML token-based authentication providers are configured for a farm, all appear as options when
you create a web application or a new zone. You can configure multiple SAML providers on the same zone.
The following diagram shows multiple types of authentication implemented on the default zone for a partner
collaboration site.
Multiple types of authentication implemented on the default zone
In the diagram, users from different directory stores use the same URL to access the partner web site. The
dashed box that surrounds partner companies shows the relationship between the user directory and the
authentication type that is configured in the default zone.
Planning to crawl content
The crawl component requires NTLM to access content. 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.
Implement 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 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 they
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 shows multiple zones that are implemented to accommodate different authentication
types for a partner collaboration site.
One zone per 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.
Plan for server-to-server authentication in
SharePoint Server

Server-to-server authentication enables servers that are capable of server-to-server authentication to access and
request resources from one another on behalf of users. Servers that are capable of server-to-server
authentication run SharePoint Server, Exchange Server 2016, Skype for Business Server 2015, Azure Workflow
Service, or other software that supports the Microsoft server-to-server protocol. Server-to-server authentication
enables a new set of functionality and scenarios that can be achieved through cross-server resource sharing and
access.
To provide the requested resources from another server that can perform server-to-server authentication, the
server that runs SharePoint Server must do the following:
Verify that the requesting server is trusted. To authenticate the requesting server, you must configure the
server that runs SharePoint Server to trust the server that is sending it requests. This is a one-way trust
relationship.
Verify that the type of access that the server is requesting is authorized. To authorize the access, you must
configure the server that runs SharePoint Server for the appropriate set of permissions for the requested
resources.
Note that the server-to-server authentication protocol in SharePoint Server is separate from user authentication
and is not used as a sign-in authentication protocol by SharePoint users. The server-to-server authentication
protocol, which uses the Open Authorization (OAuth) 2.0 protocol, does not add to the set of user sign-on
protocols, such as WS -Federation. There are no new user authentication protocols in SharePoint Server. The
server-to-server authentication protocol does not appear in the list of identity providers.
For information about how to plan for the User Profile application service for server-to-server authentication, see
Server-to-server authentication and user profiles in SharePoint Server.
Introduction
Planning for server-to-server authentication consists of the following tasks:
Identify the set of trust relationships that you have to configure on a server that runs SharePoint Server.
Address User Profile application service considerations. For more information, see Server-to-server
authentication and user profiles in SharePoint Server.
IMPORTANT
The web applications that include server-to-server authentication endpoints (for incoming server-to-server requests) or
that make outgoing server-to-server requests to other servers must be configured to use Secure Sockets Layer (SSL).
NOTE
You only have to plan for server-to-server authentication on a server that runs SharePoint Server if you are configuring one
or more server-to-server scenarios that require its use.
Identify the set of trust relationships

From the perspective of a server that runs SharePoint Server, a trust relationship with another server that can
perform server-to-server authentication consists of the following:
The server that runs SharePoint Server trusts requests from a server that can perform server-to-server
authentication (incoming to the server that runs SharePoint Server).
This requires configuration on the server that runs SharePoint Server so that it trusts the requesting
server.
The server that can perform server-to-server authentication trusts requests from a server that runs
SharePoint Server (outgoing from the server that runs SharePoint Server).
This requires configuration on the server that can perform server-to-server authentication so that it trusts
the requesting server that runs SharePoint Server.
For each farm that runs SharePoint Server, make a list of servers that are capable server-to-server authentication
and that will be receiving incoming requests based on the server-to-server scenarios that involve the farm. There
are two cases of server-to-server authentication relationships to examine.
Case 1: Farms are on-premises
If the farm that can perform server-to-server authentication is on-premises, you must configure the farm that
runs SharePoint Server. Use the New -SPTrustedSecurityTokenIssuer PowerShell cmdlet to add a JavaScript
Object Notation (JSON ) metadata endpoint of the server that can perform server-to-server authentication to the
server that runs SharePoint Server. If the server that can perform server-to-server authentication is another
server that runs SharePoint Server, the JSON metadata endpoint is in the format:
https:///_layouts/15/metadata/json/1.
Case 2: Farms are part of an Office 365 tenancy
If the farm that runs SharePoint Server and the other server that can perform server-to-server authentication are
both part of an Office 365 tenancy, no additional configuration for server-to-server authentication is needed.
After you determine the set of servers that require server-to-server authentication, see Configure server-to-
server authentication in SharePoint Server to configure the server-to-server trust relationships.
See also
Concepts
Server-to-server authentication and user profiles in SharePoint Server
Server-to-server authentication and user profiles in
SharePoint Server

Server-to-server authentication allows for servers that are capable of server-to-server authentication to access
and request resources from one another on behalf of users. Therefore, the server that runs SharePoint Server and
that services the incoming resource request must be able to complete two tasks:
Resolve the request to a specific SharePoint user
Determine the set of role claims that are associated with the user, a process known as rehydrating the
user's identity
To rehydrate a user's identity, a server that can perform server-to-server authentication requests access to
SharePoint resources. SharePoint Server takes the claims from the incoming security token and resolves it to a
specific SharePoint user. By default, SharePoint Server uses the built-in User Profile service application to resolve
the identity.
The key user attributes for locating the corresponding user profile are as follows:
The Windows Security Identifier (SID )
The Active Directory Domain Services (AD DS ) user principal name (UPN )
The Simple Mail Transfer Protocol (SMTP ) address
The Session Initiation Protocol (SIP ) address
Therefore, at least one of these user attributes must be current in user profiles.
NOTE
For SharePoint Server 2013 only, we recommend a periodic synchronization from identity stores to the User Profile service
application. For more information, see Plan profile synchronization for SharePoint Server 2013.
Furthermore, SharePoint Server expects only one matching entry in the User Profile service application for a
given lookup query that is based on these four attributes. Otherwise, it returns an error condition that multiple
user profiles were found. Therefore, you should delete obsolete user profiles in the User Profile service
application periodically to avoid multiple user profiles that share these four attributes.
If a user profile and the relevant group memberships for the user are not synchronized, SharePoint Server may
incorrectly deny access to a given resource. Therefore, make sure that group memberships are synchronized with
the User Profile service application. For Windows claims, the User Profile service application imports the four key
user attributes previously described and group memberships.
For forms-based and Security Assertion Markup Language (SAML )-based claims authentication, you must do
one of the following:
Create a synchronization connection to a data source that the User Profile service application supports and
associate the connection with a specific forms-based or SAML authentication provider. Additionally, you
have to map attributes from the user store to the four user attributes previously described, or as many of
them as you can obtain from the data source.
Create and deploy a custom component to perform the synchronization manually. This is the most likely
option for users who do not use Windows. Note that the forms-based or SAML authentication provider is
invoked when the user's identity is rehydrated to get their role claims.
User rehydration for requesting servers

If the requesting server is running Exchange Server 2016 or Skype for Business Server 2015, which use standard
Windows authentication methods, the incoming security token sent by the requesting server contains the UPN of
the user and may contain other attributes such as SMTP, SIP, and the SID of the user's identity. SharePoint
Server, the receiving server, uses this information to locate the user profile.
For a requesting server that is running SharePoint Server, the receiving server rehydrates the user through the
following claims-based authentication methods:
For Windows claims authentication, SharePoint Server uses AD DS attributes to find the user profile for
the user (for example, the UPN or SID values) and their role claims (group membership).
For forms-based authentication, SharePoint Server uses the Account attribute to locate the user's profile
and then invokes the role provider and all additional custom claims providers to obtain the corresponding
set of role claims. For example, SharePoint Server uses attributes in AD DS, in a database such as a SQL
Server database, or in an Lightweight Directory Access Protocol (LDAP ) data store to find the user profile
that represents the user (for example, the UPN or SID values). Your component to synchronize your forms-
based provider should at a minimum populate user profiles with the user's account name. You can also
create a custom claim provider to import additional claims as attributes into user profiles.
For SAML -based claims authentication, SharePoint Server uses the AccountName attribute to locate the
user's profile and then invokes the SAML provider and all additional custom claims providers to obtain the
corresponding set of role claims. The user identity claim should be mapped to the Account attribute in user
profiles through the corresponding SAML claims provider, which should be configured to populate your
user profiles. Similarly, a UPN claim should be mapped to the UPN attribute and the SMTP claim should
be mapped to the SMTP attribute. To duplicate the set of claims that the user would usually obtain from
their identity provider, you must add those claims, including the role claims, through claims augmentation.
A custom claim provider must import those claims as attributes into user profiles.
See also
Concepts
Plan for server-to-server authentication in SharePoint Server
Plan for Kerberos authentication in SharePoint Server

The Kerberos protocol supports an authentication method that uses tickets that a trusted source provides. Kerberos
tickets indicate that the network credentials of a user who is associated with a client computer were authenticated.
The Kerberos protocol defines how users interact with a network service to gain access to network resources. The
Kerberos Key Distribution Center (KDC ) issues a ticket-granting-ticket (TGT) to a client computer on behalf of a
user. In Windows, the client computer is a member of an Active Directory Domain Services (AD DS ) domain and
the TGT is proof that the domain controller authenticated the user credentials.
Before establishing a network connection to a network service, the client computer presents its TGT to the KDC
and requests a service ticket. Based on the previously issued TGT, which confirms that the client computer was
authenticated, the KDC issues a service ticket to the client computer. The client computer then submits the service
ticket to the network service. The service ticket must also contain an acceptable Service Principal Name (SPN ) that
identifies the service. 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 AD DS.
Kerberos authentication and SharePoint Server

The reasons why you should consider Kerberos authentication are as follows:
The Kerberos protocol is the strongest Integrated Windows authentication protocol, and supports advanced
security features including Advanced Encryption Standard (AES ) encryption and mutual authentication of
clients and servers.
The Kerberos protocol allows for delegation of client credentials.
Of the available secure authentication methods, Kerberos requires the least amount of network traffic to AD
DS 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.
The Kerberos protocol is an open protocol that is supported by many platforms and vendors.
The reasons why Kerberos authentication might not be appropriate are as follows:
In contrast to other authentication methods, Kerberos authentication requires additional infrastructure and
environment configuration to function correctly. In many cases, domain administrator permission is
required to configure Kerberos authentication which can be difficult to set up and manage. Misconfiguring
Kerberos can prevent successful authentication to your sites.
Kerberos authentication requires client computer connectivity to a KDC and to an AD DS domain controller.
In a Windows and SharePoint deployment, the KDC is an AD DS domain controller. While this is a common
network configuration on an organization intranet, Internet-facing deployments are typically not configured
in this manner.
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
requires the back-end application to be claims-aware.
Used with SharePoint Server, Kerberos delegation enables a front-end service to authenticate a client and then use
the client's identity to authenticate to a back-end system. The back-end 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 back-end system. The Kerberos protocol supports two types
of delegation:
Basic Kerberos delegation (unconstrained)
Kerberos constrained delegation
Basic Kerberos delegation and Kerberos constrained delegation
Basic Kerberos delegation can cross domain boundaries within the same forest but cannot cross a forest boundary.
Kerberos constrained delegation cannot cross domain or forest boundaries, except when you are using domain
controllers that run Windows Server 2012.
Depending on the service applications that are part of a SharePoint Server deployment, implementing Kerberos
authentications with SharePoint Server can require Kerberos constrained delegation.
IMPORTANT
To deploy Kerberos authentication with any of the following service applications, SharePoint Server and all external data
sources must reside in the same Windows domain: > Excel Services > PerformancePoint Services > InfoPath Forms Services >
Visio Services > These service applications are not available in SharePoint Foundation 2013. Excel Services is not available in
To deploy Kerberos authentication with any of the following service applications or products, SharePoint Server
can use either basic Kerberos delegation or Kerberos constrained delegation:
Business Data Connectivity service (this service application is not available in SharePoint Foundation 2013)
Access Services (this service application is not available in SharePoint Foundation 2013)
SQL Server Reporting Services (SSRS ) (a separate product)
Project Server 2016 (a separate product)
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 a back-end service will require basic Kerberos
delegation. This can affect 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 back-end 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 different services if the services meet all of the
following criteria:
There must be a trust relationship between the services.
The services must be claims-aware.
For more information about Kerberos authentication, see the following resources:
Microsoft Kerberos
Kerberos Explained
How the Kerberos Version 5 Authentication Protocol Works
Kerberos Authentication Tools and Settings
Kerberos authentication and claims-based authentication

SharePoint 2013 and SharePoint Server 2016 supports claims-based authentication. Claims-based authentication
is built on the Windows Identity Foundation (WIF ), which is a set of the .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 (white paper)
Windows Identity Foundation home page
When you create a SharePoint Server web application by using Central Administration, you must select one or
more claims-based authentication types. When you create a SharePoint Server web application by using the New-
SPWebApplication Microsoft PowerShell cmdlet, you can specify either claims authentication and claims
authentication types or classic mode authentication. Claims authentication is recommended for all SharePoint
Server web applications. By using claims authentication, all supported authentication types are available for your
web applications and you can take advantage of server-to-server authentication and app authentication. For more
information, see What's new in authentication for SharePoint Server 2013.
IMPORTANT
The following service applications in SharePoint Server 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> > These service applications are not available
in SharePoint Foundation 2013. Excel Services is not available in SharePoint Server 2016.
The service applications that require the C2WTS must use Kerberos constrained delegation because C2WTS
requires protocol transition, which is only supported by Kerberos constrained delegation. For the service
applications in the previous list, the C2WTS translates claims within the farm to Windows credentials for outgoing
authentication. It is important to understand that these service applications can use the C2WTS only if the
incoming authentication method is either Windows claims or Windows classic mode. Service applications that are
accessed through web applications and that use Security Assertion Markup Language (SAML ) claims or forms-
based authentication claims do not use the C2WTS. Therefore, they cannot translate claims to Windows
credentials.
Kerberos authentication and the new SharePoint app model

If you are using Windows claims mode for user authentication and the web application is configured to use only
Kerberos authentication without falling back to NTLM as the authentication protocol, then app authentication does
not work. For more information, see Plan for app authentication in SharePoint Server.
See also
Concepts
Plan for user authentication methods in SharePoint Server
Plan for app authentication in SharePoint Server

App authentication is the validation of an external app for SharePoint's identity and the authorization of both the
app and an associated user when the app requests access to a secured SharePoint resource. App authentication
occurs when an external component of a SharePoint Store app or an App Catalog app, such as a web server that is
located on the intranet or the Internet, attempts to access a secured SharePoint resource. For example, an app for
SharePoint that includes a component that runs in Microsoft Azure is an external app. App authentication enables
a new set of functionality and scenarios that can be achieved by allowing apps to include data from SharePoint
resources in the results that the app processes and displays for users.
To provide the requested resources from an app for SharePoint, the server that runs SharePoint Server must do
the following:
Verify that the requesting app is trusted.
To authenticate the requesting app, you must configure the server that runs SharePoint Server to trust the
app that is sending it requests. This is a one-way trust relationship.
Verify that the type of access that the app is requesting is authorized.
To authorize the access, SharePoint Server relies on the set of app permissions, which was specified in the
app manifest file when it was installed, and the permissions that are associated with the user on whose
behalf the app is acting. SharePoint Server also relies on the permissions that were granted to the
SPAppPrincipal when the trust was established by using the Set-SPAppPrincipalPermission PowerShell
cmdlet.
Note that app authentication in SharePoint Server is separate from user authentication and is not used as a sign-in
authentication protocol by SharePoint users. App authentication uses the Open Authorization (OAuth) 2.0 protocol
and does not add to the set of user authentication or sign-on protocols, such as WS -Federation. There are no new
user authentication protocols in SharePoint Server. App authentication and OAuth do not appear in the list of
identity providers.
Introduction
Planning for app authentication consists of the following tasks:
Identify the set of trust relationships that you have to configure on a farm that runs SharePoint Server that
correspond to the external apps that will be making requests for SharePoint resources.
Provide incoming access from external applications that the Internet hosts.
IMPORTANT
The web applications that include app authentication endpoints (for incoming requests by apps for SharePoint) must be
configured to use Secure Sockets Layer (SSL). You can configure OAuth in SharePoint Server so that it does not require SSL.
However, we recommend this only for evaluation, for ease of configuration or to create an app development environment.
NOTE
You only have to plan for app authentication on a SharePoint farm if you are using one or more external apps for SharePoint
that require its resources.
Identify the set of trust relationships

You must configure the SharePoint farm to trust the access tokens that correspond to resource requests that the
following types of external apps send:
Provider-hosted apps run on their own servers on the Internet or your intranet, are registered with
Microsoft Azure, and use ACS to obtain the access token.
For provider-hosted apps, you must configure the SharePoint farm to trust the ACS instance of the
provider-hosted app.
High-trust apps run on stand-alone servers on your intranet and use a signing certificate to digitally sign
the access tokens that the app generates.
High-trust apps use the server-to-server protocol to request resources on behalf of a user. For high-trust
apps, configure the SharePoint farm with the JavaScript Object Notation (JSON ) metadata endpoint of the
server that hosts the app. Or, you can manually configure the trust. For more information, see Configure
app authentication in SharePoint Server
For more information about high-trust apps, see How to: Create high-trust apps for SharePoint 2013 using
the server-to-server protocol.
Choose user authentication methods for on-premises apps

An on-premises app is either a provider-hosted app that is hosted on an on-premises server or a SharePoint
hosted app. Table 1 lists the different authentication user methods of SharePoint Server and whether that method
can be used for SharePoint Server on-premises apps.
Table 1. User authentication methods and support by on-premises apps
SUPPORTED BY SHAREPOINT HOSTED

AUTHENTICATION METHOD APPS SUPPORTED BY PROVIDER HOSTED APPS
NTLM Yes Yes
Kerberos Yes, but only when it is configured to Yes

use NTLM as a fallback authentication
method. Kerberos-only is not
supported.
Basic Yes Yes
Anonymous Yes Yes
Forms-based authentication using the Yes Yes

default ASP.NET provider
Forms-based authentication using Yes Yes

Lightweight Directory Access Protocol
(LDAP)
SUPPORTED BY SHAREPOINT HOSTED
AUTHENTICATION METHOD APPS SUPPORTED BY PROVIDER HOSTED APPS
Security Assertion Markup Language Yes, if the identity provider supports Yes
(SAML) authentication wildcard return uniform resource
locator (URL) registration and honors
the wreply parameter. .
To configure SharePoint Server to use
the wreply parameter, use the
following commands at a Microsoft
PowerShell command prompt:
$p = Get-
SPTrustedIdentityTokenIssuer$p.UseWReplyParameter
= $true$p.Update()
> [!NOTE]> Active Directory Federation
Services (AD FS) 2.0 version does not
support wildcard for return URL
registration.
For more information about user authentication methods in SharePoint Server, see Plan for user authentication
methods in SharePoint Server.
Provide incoming access from external applications hosted on the

Internet
If external provider-hosted apps are located on the Internet, you have to configure a reverse web proxy to perform
app authentication and request resources from intranet SharePoint farms. A configured reverse web proxy at the
edge of your network has to allow incoming HTTP over SSL (HTTPS ) connections from the apps to your
SharePoint farms. You typically identify the HTTPS -based URLs that the external applications will access and
configure the reverse proxy to publish those URLs and provide the appropriate security.
Address User Profile application service considerations

High-trust apps generate their own access tokens, which include an assertion of the identity of the user on whose
behalf they are acting. The server that runs SharePoint Server and services the incoming resource request must be
able to resolve the request to a specific SharePoint user, a process known as rehydrating the user's identity. Note
that this differs from app authentication for provider-hosted apps, in which the user is identified, but not asserted.
To rehydrate a user's identity, a server that runs SharePoint Server takes the claims from the incoming access
token and resolves it to a specific SharePoint user. By default, SharePoint Server uses the built-in User Profile
service application as the identity resolver.
The key user attributes for user identity rehydration are as follows:
The Windows Security Identifier (SID )
The Active Directory Domain Services (AD DS ) user principal name (UPN )
The Simple Mail Transfer Protocol (SMTP ) address
The Session Initiation Protocol (SIP ) address
Therefore, the app must include at least one of these user attributes and that attribute must be current in user
profiles. We recommend a periodic synchronization from identity stores to the User Profile service application.
Furthermore, SharePoint Server expects only one entry in the User Profile service application for a given lookup
query that is based on one or more of these four attributes. Otherwise, it returns an error condition that multiple
user profiles were found. Therefore, you should delete obsolete user profiles in the User Profile service application
periodically to avoid multiple user profiles.
If a user profile exists for a user and the relevant group memberships are not synchronized, access may be denied
when the user is supposed to be granted access for a given resource. Therefore, make sure that group
memberships are synchronized with the User Profile service application.
See also
Concepts
Create claims-based web applications in SharePoint
Server

Claims-based authentication is a requirement to enable the advanced functionality of SharePoint Server. This
article explains how to use either Central Administration or PowerShell to create a SharePoint Server web
application that uses claims-based authentication. Claims-based authentication is a requirement for web
applications that are deployed in scenarios that support server-to-server authentication and app authentication.
However, this article also provides guidance for using PowerShell to create classic-mode web applications if you
have a specific scenario that cannot support claims-based authentication. Be aware that classic-mode
authentication is deprecated in this release, and it will not be available in the next version. For more information,
see Plan for server-to-server authentication in SharePoint Server
IMPORTANT
Secure Sockets Layer (SSL) is a requirement for web applications that are deployed in scenarios that support server-to-server
authentication and app authentication.
You can create a web application by using the SharePoint Central Administration website or PowerShell. You
typically use PowerShell to create a web application. If you want to automate the task of creating a web application,
which is common in enterprises, use PowerShell. After you complete the procedure, you can create one or several
site collections.
Create a claims-based web application by using Central Administration

Use the procedure described in this section to create a new claims-based SharePoint Server web application using
the Central Administration.
To create a claims-based web application 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.
2. Start SharePoint 2016 Central Administration.
3. On the Central Administration Home page, click Application Management.
4. On the Application Management page, in the Web Applications section, click Manage web
applications.
5. In the Contribute group of the ribbon, click New.
6. On the Create New Web Application page, 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 IIS 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.
In the Port box, type the port number you want to use to access the web application. If you are using an
existing web site, this field contains the current port number.
NOTE
The default port number for HTTP access is 80, and the default port number for HTTPS access is 443.
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
You do not need to populate this field 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.
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 contains a suggested path. If you are using an existing web site, this field contains the
current path of that web site.
7. In the Security Configuration section, choose whether or not to Allow Anonymous access and whether
or not to Use Secure Sockets Layer (SSL ).
IMPORTANT
Secure Sockets Layer (SSL) is a requirement for web applications that are deployed in scenarios that support server-
to-server authentication and app authentication. In general, we strongly recommend using SSL for web applications.
In the Security Configuration section, click Yes or No for the Allow Anonymous options. If you choose
to Yes, visitors can use the computer-specific anonymous access account (that is, IIS_IUSRS ) to access the
web site.
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 Server site level. Later, site
owners can configure anonymous access for their sites. If you do not enable anonymous access at the web
application level, site owners cannot enable anonymous access at the site level.
In the Security Configuration section, click Yes or No for the Use Secure Sockets Layer (SSL ) options.
If you choose Yes, you must request and install an SSL certificate to configure SSL.
8. In the Claims Authentication Types section, select the authentication method that you want to use for the
web application.
To enable Windows authentication, select Enable Windows Authentication and, in the drop-down menu,
select NTLM or Negotiate (Kerberos). We recommend using Negotiate (Kerberos).
If you do not want to use Integrated Windows authentication, clear Integrated Windows authentication.
NOTE
If you do not select Windows Authentication for at least one zone of this web application, crawling for this web
application will be disabled.
If you want users' credentials to be sent over a network in a nonencrypted form, select Basic
authentication (credentials are sent in clear text).
NOTE
You can select basic authentication or integrated Windows authentication, or both. If you select both, SharePoint
Server offers 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, a malicious
user can intercept credentials.
To enable forms-based authentication, select Enable Forms Based Authentication (FBA ), and then enter
the ASP.NET Membership provider name and the ASP.NET Role manager name.
NOTE
If you select this option, ensure that SSL is enabled. Otherwise, a malicious user can intercept credentials.
If you have set up Trusted Identity Provider authentication by using PowerShell, the Trusted Identity
provider check box is selected.
9. In the Sign In Page URL section, choose one of the following options to sign into SharePoint Server:
Select Default Sign In Page URL to redirect users to a default sign-in web site for claims-based
authentication.
Select Custom Sign In page URL and then type the sign-in URL to redirect users to a customized sign-in
web site for claims-based authentication.
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 that are shown on pages within the web
application. The default URL is the current server name and port, and it is automatically updated to reflect
the current SSL, host header, and port number settings on the page. If you deploy SharePoint Server 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. You can change the zone when
you extend a web application.
11. In the Application Pool section, do one of the following:
Click Use existing application pool, and then select the application pool that 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.
Click Predefined to use a predefined security account for this application pool, 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
To create a new account, click the Register new managed account link.
12. 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 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:
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.
To use SQL authentication, click SQL authentication. In the
Account box, type the name of the account that 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 SQL Server in an unencrypted format. We
recommend that you only use SQL authentication if you force
protocol encryption to SQL Server to encrypt your network
traffic by using IPsec.
13. 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
14. 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 service application connections that you want to use for the web application.
15. In the Customer Experience Improvement Program section, click Yes or No.
16. Click OK to create the new web application.
Create a claims-based web application by using PowerShell

Use the procedure in this section to create a new claims-based SharePoint Server web application using
PowerShell.
To create a claims-based web application by using PowerShell
1. Verify that you have the following memberships:
securityadmin fixed server role on the SQL Server instance.
db_owner fixed database role on all databases that are to be updated.
Administrators group on the server on which you are running PowerShell cmdlets.
You must read about_Execution_Policies.
An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 15
Products cmdlets.
NOTE
If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions.
For additional information about PowerShell permissions, see Permissions and Add-SPShellAdmin.
2. To create a claims-based authentication provider, from the PowerShell command prompt, type the following:
$ap = New-SPAuthenticationProvider
3. To create a claims-based web application, from the PowerShell command prompt, type the following:
New-SPWebApplication -Name <Name>

-ApplicationPool <ApplicationPool>
-ApplicationPoolAccount <ApplicationPoolAccount>
-URL <URL> -Port <Port> -AuthenticationProvider $ap
Where:
<Name> is the name of the new web application that uses claims-based 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 this web application.
<Port> is the port on which the web application will be created in IIS.
> [!NOTE]
> For more information, see [New-SPWebApplication](/powershell/module/sharepoint-server/New-SPWebApplication?
view=sharepoint-ps).
The following example creates an https claims-based web application, using the current user credentials and
the current machine name:
$ap = New-SPAuthenticationProvider
New-SPWebApplication -Name "Contoso Internet Site" -URL "https://www.contoso.com" -Port 80
-ApplicationPool "ContosoAppPool"
-ApplicationPoolAccount (Get-SPManagedAccount "DOMAIN\jdoe")
-AuthenticationProvider $ap -SecureSocketsLayer
> [!NOTE]
> After you have created the web site, you must configure SSL in IIS for this newly created web site.
Create a classic-mode web application by using PowerShell

Use the procedure in this section to create a new classic-mode SharePoint Server web application using
PowerShell.
To create a classic-mode web application by using PowerShell
You must read about_Execution_Policies.
2. From the PowerShell command prompt, type the following:
New-SPWebApplication -Name <Name>

-ApplicationPool <ApplicationPool>
-AuthenticationMethod <WindowsAuthType>
-ApplicationPoolAccount <ApplicationPoolAccount>
-Port <Port> -URL <URL>
Where:
<Name> is the name of the new web application that uses classic-mode authentication.
<WindowsAuthType> is either "NTLM" or "Kerberos". Kerberos is recommended.
<URL> is the public URL for the web application.
> [!NOTE]
> For more information, see [New-SPWebApplication](/powershell/module/sharepoint-server/New-SPWebApplication?
> [!NOTE]
> After you successfully create the web application, when you open the Central Administration page, you see a
health rule warning that indicates that one or more web applications is enabled with classic authentication
mode. This is a reflection of our recommendation to use claims-based authentication instead of classic mode
authentication.
See also
Concepts
Create a Web application that uses classic mode authentication in SharePoint 2013
Create web applications that use classic mode
authentication in SharePoint Server

In SharePoint Server, claims-based authentication is the default and preferred method of user authentication and
is required to take advantage of server-to-server authentication and app authentication. In Central Administration,
you can only configure claims-based authentication when you manage web applications. You can also use
Microsoft PowerShell cmdlets. The use of classic mode authentication, also known as Windows classic
authentication, is discouraged in SharePoint Server and you can only create or configure web applications for
classic mode authentication with Microsoft PowerShell cmdlets.
IMPORTANT
Office Online can be used only by SharePoint Server web applications that use claims-based authentication. Office Online
rendering and editing will not work on SharePoint Server web applications that use classic mode authentication. If you
migrate SharePoint 2010 web applications that use classic mode authentication to SharePoint Server 2016, you must migrate
them to claims-based authentication to allow them to work with Office Online. For more information, see Use Office Web
Apps with SharePoint 2013.
To use Windows claims-based authentication instead (recommended), see Create a web application that uses
Windows-claims authentication. To convert a web application that uses classic mode to use claims-based
authentication, see Migrate from classic-mode to claims-based authentication in SharePoint Server.
IMPORTANT
The steps in this article apply to both SharePoint Foundation 2013 and SharePoint Server.
Before you begin

Before you perform this procedure, confirm the following:
You have determined the design of your logical architecture.
For additional information, see Logical architecture components.
You have planned authentication for your web application.
For additional information, see Plan for user authentication methods in SharePoint Server.
If you use Secure Sockets Layer (SSL ), you must associate the SSL certificate with the web application's IIS
website after the IIS website is created. SSL is required by default for web applications that are used in
server-to-server authentication and app authentication scenarios.
You understand host-named site collections.
Create a web application that uses classic mode authentication with

PowerShell
Perform the following procedure to use PowerShell to create a web application that uses classic mode
authentication.
To create a web application that uses classic mode authentication with PowerShell
Administrators group on the server on which you are running the PowerShell cmdlets.
Add memberships that are required beyond the minimums above.
Products cmdlets.
NOTE
For additional information about PowerShell permissions, see Add-SPShellAdmin.
2. Start the SharePoint Management Shell.

3. At the PowerShell command prompt, type the following command:
New-SPWebApplication -Name <Name> -ApplicationPool <ApplicationPool> -AuthenticationMethod <WindowsAuthType> -

ApplicationPoolAccount <ApplicationPoolAccount> -Port <Port> -URL <URL>
Where:
<Name> is the name of the new web application.
< WindowsAuthType > is either "NTLM" or "Kerberos". Kerberos is recommended.
Example
New-SPWebApplication -Name "Contoso Internet Site" -ApplicationPool "ContosoAppPool" -AuthenticationMethod

"Kerberos" -ApplicationPoolAccount (Get-SPManagedAccount "CONTOSO\jdoe") -Port 80 -URL
"https://www.contoso.com"
For more information, see New -SPWebApplication.PShell_stsadm_deprecated

After this procedure is complete, you can create one or more site collections for this web application. For more
information, see Create a site collection in SharePoint Server.
After you successfully create the web application, when you open the Central Administration page, you see a
health rule warning that indicates that one or more web applications is enabled with classic authentication mode.
This is a reflection of our recommendation to use claims-based authentication instead of classic mode
authentication.
See also
Concepts
Create a Web application that uses Windows-claims authentication)
Other Resources
Implement SAML authentication
Overview of SAML authentication

In SAML claims mode, SharePoint Server accepts SAML tokens from a trusted external Security Token Provider
(STS ), often known as a claims provider trust. A user who attempts to log on is directed to an external claims
provider (for example, the Windows Live ID claims provider), which authenticates the user and produces a SAML
token. SharePoint Server accepts and processes this token, augmenting the claim and creating a claims identity
object for the user.
Concepts and terminology

To understand the concepts and terminology that are used in SAML -based authentication, see Authentication
Overview.
SharePoint Server with Active Directory Federation Services 2.0

This section describes how to configure Active Directory Federation Services (AD FS ) to act as an Identity Provider
Security Token Service (IP -STS ) for a SharePoint Server web application. In this configuration, AD FS issues
SAML -based security tokens consisting of claims so that client computers can access web applications that use
claims-based authentication.
Configure a SharePoint web application for SAML authentication

This section discusses how to set up a new or existing Windows authentication web application to support SAML.
Each authentication type has realms associated with it. For example: urn: "customercode":sp "webapptype"
:"authusers"
For example, the value for the Contoso team web application for employee user could be similar to the following:
urn:contoso:spteam:emp.
Configure a new or existing Windows authentication web application to support SAML
There are four steps that are needed to configure a new or existing web application to support SAML claims:
1. Create a realm for employee access.
2. Add trusted certificates.
3. Create the trusted providers.
4. Associate them to a web application.
Create a realm for employee access
The following claim rules for the new realm are created:
Email
UPN
PrimarySID
GroupsSID
If the AD FS STS domain is configured by using additional claims, it will be ignored.
Add trusted certificates by using a Windows PowerShell script
1. Check that you meet the following minimum requirements:
See Add-SPShellAdmin.
Read about_Execution_Policies.
2. Copy the following variable declarations, and paste them into a text editor, like Notepad. Set input values
specific to your organization. You will use these values in Step 3. Save the file, and name it Add-
ADFSCerts.ps1.
Settings you need to change for your organization before the script is run.
ADFS and root certificate names $adfsCertName = "< Input ADFS Cert Name >"
$MACertName = "< Input Machine Authority >"
$MIACertName = "< Input Certificate Authority >"
$RootCertName = "< Input Root name >".
3. Copy the following code, and paste it into Audiences.ps1 underneath the variable declarations from Step 2.
This script configures SharePoint 2013 with ADFS certificates and claim type maps and creates a Trusted Identity
Token Issuer that enables SAML claims support in SharePoint web applications.
The directory that contains this script $ScriptDir = Split-Path -parent $MyInvocation.MyCommand.Path
# ADFS and root certificate names
$adfsCertName = "< Input ADFS Cert Name >"

$MACertName = "< Input Machine Authority >" $MIACertName = "< Input Certificate Authority >" $RootCertName = "
< Input Root name >"
# The local file path, which points to the certificate used to sign token requests (exported from the AD FS
server) $certFilePath = $ScriptDir + "\Certificates\" # Build the certificates. $adfsCertPath = $certFilePath +
$adfsCertName + ".cer" $MACertName = $certFilePath + $MACertName + ".cer" $MIACertPath = $certFilePath +
$MIACertName + ".cer" $RootCertPath = $certFilePath + $BCTRCertName + ".cer"
# Import certificates to the SharePoint Trusted Root Authority. # $adfsCert = $null if($adfsCert -eq $null) {
Write-Host "installing " $adfsCert $adfsCert = New-Object
System.Security.Cryptography.X509Certificates.X509Certificate2($adfsCertPath)
# Install the certificate that was exported from the ADFS server. New-SPTrustedRootAuthority -Name
$adfsCertName -Certificate $adfsCert New-SPTrustedRootAuthority -Name $MACertName -Certificate $MACertName New-
SPTrustedRootAuthority -Name $MIACertName -Certificate $MIACertPath New-SPTrustedRootAuthority -Name
$BCTRCertName -Certificate $RootCertPath }
Note: You can use a different file name, but you must save the file as an ANSI-encoded text file that has the
extension .ps1.
4. On the Start menu, click All Programs > Microsoft SharePoint Products > SharePoint Management
Shell.
5. Change the command prompt to the directory to which you saved the file.
6. At the Windows PowerShell command prompt, type the following command: ./Add-ADFSCerts.ps1.
Create the trusted provider by using a Windows PowerShell script

2. Copy the following variable declarations, and paste them into a text editor, such as Notepad. Set input values
specific to your organization. You will use these values in Step 3. Save the file, and name it
TrustedProviderConfiguration-Regular.ps1.
# ADFS and root certificate names

$adfsCertName = "< Input ADFS Certificate Name >" $MACertName = "< Input Machine Authority >" $MIACertName = "<
Input Certificate Authority >" $RootCertName = "< Input Root name >"
3. Copy the following code, and paste it into Audiences.ps1 underneath the variable declarations from Step 2.
This script configures SharePoint Server with ADFS certificates and claim type maps and creates a Trusted Identity
Token Issuer that enables SAML claims support in SharePoint web applications.
Variables that need to be change before you run script:

The directory that contains this script
$ScriptDir = Split-Path -parent $MyInvocation.MyCommand.Path
ADFS and root certificate names
$adfsCertName = "< Input ADFS Cert Name >"
$RootCertName = "< Input Root name >"
The local file path, which points to the certificate used to sign token requests (exported from the AD FS
server)
$certFilePath = $ScriptDir + "\Certificates" # Build the certificates. $adfsCertPath = $certFilePath +
$adfsCertName + ".cer" $MACertName = $certFilePath + $MACertName + ".cer" $MIACertPath = $certFilePath +
$MIACertName + ".cer" $RootCertPath = $certFilePath + $BCTRCertName + ".cer"
# Import certificates to the SharePoint Trusted Root Authority**
$adfsCert = $null if($adfsCert -eq $null) { Write-Host "installing " $adfsCert $adfsCert = New-Object
# Install the certificate that was exported from the ADFS server.
New-SPTrustedRootAuthority -Name $adfsCertName -Certificate $adfsCert New-SPTrustedRootAuthority -Name

$MACertName -Certificate $MACertName New-SPTrustedRootAuthority -Name $MIACertName -Certificate $MIACertPath
New-SPTrustedRootAuthority -Name $BCTRCertName -Certificate $RootCertPath }
extension .ps1.
Shell.
6. At the Windows PowerShell command prompt, type the following command, .Add-ADFSCerts.ps1.
Create the trusted provider by using a Windows PowerShell script
2. Copy the following variable declarations, and paste them into a text editor, such as Notepad. Set input values
specific to your organization. You will use these values in Step 3. Save the file, and name it
TrustedProviderConfiguration-Regular.ps1.
ADFS and root certificate names
$adfsCertName = "< Input ADFS Certificate Name >"
$RootCertName = "< Input Root name >"
This script configures SharePoint 2013 with ADFS certificates and claim type maps and creates a Trusted Identity
Token Issuer that enables SAML claims support in SharePoint web applications. These providers use the UPN or
EMail claim rule for the identity claim.
**The production ADFS redirect URL**
$signInUrl = https://sts.msft.net/adfs/ls/"
**The URL and realm for the partner web application**
$webAppUri = "https://ppedrtest.mmsxl.com/" $siteRealm = "urn:039d:spdr:emp"
**The directory that contains this script**

$ScriptDir = Split-Path -parent $MyInvocation.MyCommand.Path
**The claim type schema used as the user identity, which uses the email address as the UPN**
$IdClaimType = http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
$adfsCert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($adfsCertPath)
**The ADFS and root certificate names**
$adfsCertName = "<Insert ADFS Certification Name>
**The local file path, which points to the certificate used to sign token requests (exported from the AD FS
server)**
$certFilePath = $ScriptDir + "\Certificates\" # Build the certificates. $adfsCertPath = $certFilePath +

$adfsCertName + ".cer" $adfsCert = New-Object
**Create or rebuild TrustedIdentityTokenIssuer**
$tokenIdentityProviderName = "RegularUsers" $TrustedIdentityTokenIssuerDescription = "SAML Provider for

SharePoint" foreach($issuer in Get-SPTrustedIdentityTokenIssuer) { if($issuer.Name -eq
$tokenIdentityProviderName) {
**Remove TrustedIdentityTokenIssuer (usually, to modify the ADFS property maps) if it already exists?**
Read-Host "Identity Token Issuer already exists. Remove and reinstall it? Press CTRL+C to cancel."
Remove-SPTrustedIdentityTokenIssuer -Identity $tokenIdentityProviderName } }
Read-Host "Create a new SharePoint Trusted Identity Token Issuer?"
**Create the SharePoint Trusted Identity Token Issuer**
Write-Host "Creating SPTrustedIdentityTokenIssuer named " $tokenIdentityProviderName

$ap = New-SPTrustedIdentityTokenIssuer `-Name $tokenIdentityProviderName `-Description
$TrustedIdentityTokenIssuerDescription `-realm $siteRealm `-ImportTrustCertificate $adfsCert `-SignInUrl
$signInUrl ` -UseDefaultConfiguration `-IdentifierClaimIs USER-PRINCIPAL-NAME `-RegisteredIssuerName $siteRealm
**Add the partner site realm to the trusted provider**
$uri = new-object System.Uri($webAppUri)

$ap = Get-SPTrustedIdentityTokenIssuer $tokenIdentityProviderName $ap.ProviderRealms.Add($uri,$siteRealm)
$ap.Update()
extension .ps1.
Shell.
6. At the Windows PowerShell command prompt, type the following command, ./TrustedProviderConfiguration-
Regular.ps1.
Enable tracing for SharePoint Server claims
To enable tracing for SharePoint 2013, you can use the following ways:
Enable tracing in Windows Identity Foundation (WIF ). For information about how to enable tracing, see WIF
Tracing.
Configure diagnostic logging in SharePoint Server.
For information about how to configure diagnostic logging, see Configure diagnostic logging in SharePoint Server.
Trusted identity providers and user profile synchronization

This section describes the steps that let user profile synchronization use claims-based authentication with a trusted
identity provider.
When you configure a directory synchronization connection, you can specify the type of authentication provider
that will be used to access the imported profiles. In the case of a trusted claims provider, you can also select the
specific trusted provider configured in the farm.
To provide the user profile application with sufficient information to map the imported profiles to authenticated
users, you have to set the imported attributed to the corresponding authenticated users identity claim. The claim is
immutable. It cannot be changed after it is configured in the trusted identity provider. To map users correctly, the
user profile system must be informed of which of the attributes it can import to be used as the identity claim. The
key is to identify the identity claim for the user profile system so that there is enough information to match the
identity claim with the corresponding profile entry. The Claim User Identifier property is used to establish the
mapping.
The next profile import will result in users who are associated with the corresponding profile entries. For additional
information about user profile synchronization, see User Profile Synchronization in SharePoint Server 2013 and
User Profile Synchronization in SharePoint Server 2016.
Using audiences with claims-based sites

This section describes how SAML claims work with the audiences feature in SharePoint Server. By default,
synchronization support is available for AD DS and several Lightweight Directory Access Protocol (LDAP ) sources
and from a Lightweight Directory Interchange Format (LDIF ) file. A problem is that the account name for most
SAML claims users is something like i:05:t|AD FS with roles|fred@contoso.com.
To take advantage of audiences, you need to create profiles for users either manually or through custom code.
Create the profiles with their proper claims attributes—for example, i:05:t|AD FS with roles|fred@contoso.com as
the account name—and then populate the other fields with data that you want to use in your audiences.
After the profiles are created, audiences can be created. You can't use a user-based audience, such as membership
in a group, for the audience unless you implement custom code. It might be more efficient to use the property-
based audience.
For more information see, Claims-Based Identity Term Definitions.
Migrate Windows claims to SAML claims

Identifies the steps required to migrate a web application that is going from Windows claims authentication to
SAML -based authentication in SharePoint Server.
Identity migration
To run the identity migration, follow these steps:
NOTE: These steps apply only to existing web applications.
Generate a skip list- A skip list is comma-separated values file (.csv file) that has records to exclude during the
identity migration. For example, it is necessary to exclude certain service applications or certain domain
accounts
Run the migration against the web application that has one or more content databases.
Migration of a web application

To migrate a web application to include all the content databases by using Windows PowerShell.
1. Check that you have the following memberships:
The securityadmin fixed server role on the SQL Server instance.
The db_owner fixed database role on all databases that are to be updated.
The Administrators group on the server on which you are running Windows PowerShell cmdlets.
An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint cmdlets.
NOTE: If you do not have permissions, contact your Setup administrator or SQL Server administrator to request
permissions. For additional information about Windows PowerShell permissions, see Permissions and Add-
SPShellAdmin.
2. To migrate a web application to include all content databases, type the following at the Windows PowerShell
command prompt.
$skipFile = "FileName.csv"
$wa = Get-SPWebApplication -Identity "Name of web application"
$tp = Get-SPTrustedIdentityTokenIssuer "RegularUsers"
Convert-SPWebApplication -Identity $wa -From CLAIMS-WINDOWS -To CLAIMS-TRUSTED-DEFAULT -TrustedProvider $tp -
SourceSkipList $skipFile
To migrate specific web applications and content databases by using Windows PowerShell.
1. Check that you have the following memberships:
The securityadmin fixed server role on the SQL Server instance.
The db_owner fixed database role on all databases that are to be updated.
The Administrators group on the server on which you are running Windows PowerShell cmdlets.
An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint cmdlets.
NOTE: If you do not have permissions, contact your Setup administrator or SQL Server administrator to request
permissions. For additional information about Windows PowerShell permissions, see Permissions and Add-
SPShellAdmin.
2. To migrate specific web applications and content databases, type the following at the Windows PowerShell
command prompt.
$database = Get-SPContentDatabase -Identity "DB_Name"
Convert-SPWebApplication -Identity $wa -Database $database -From CLAIMS-WINDOWS -To CLAIMS-TRUSTED-DEFAULT -
SourceSkipList $skipFile
If you want to reverse the migration process, type the following at the Windows PowerShell command prompt.
Convert-SPWebApplication -Identity $wa -From CLAIMS-TRUSTED-DEFAULT -To CLAIMS-WINDOWS -SourceSkipList
$skipFile -Database $database
NOTE: For more information, see Get-SPContentDatabase, Get-SPWebApplication, and Convert-

SPWebApplication.
Secure Sockets Layer (SSL) and Transport Layer
Security (TLS) protocol support in SharePoint Server

SharePoint Server supports the following versions of the TLS protocol:
TLS 1.0
TLS 1.1
TLS 1.2
SSL 3.0*
*Note that SharePoint Server 2016 does not fully support SSL 3.0. This is because SharePoint Server 2016
disables SSL 3.0 connection encryption by default for some, but not all features.
IMPORTANT
We recommend completely disabling the SSL 3.0 protocol due to its security vulnerability. > For additional information on
how to completely disable SSL 3.0, see the "Disabled SSL 3.0 in Windows For Server Software" and "Disabled SSL 3.0 in
Windows For Client Software" sections in Microsoft Security Advisory 3009008
For information about how to enable TLS support, see:

SSL and TLS Protocols that can be disabled

SharePoint Server supports disabling the following versions of the SSL/TLS protocol:
TLS 1.0
TLS 1.1
TLS 1.2
SSL 3.0
NOTE
At least one of the following TLS protocols must remain enabled: TLS 1.0, TLS 1.1, or TLS 1.2.

TLS protocol version 1.1 and 1.2 support is not enabled by default in SharePoint Server 2013. To enable support,
you'll have to install updates and change configuration settings once in each of the following locations:
1. SharePoint servers in your SharePoint farm
2. Microsoft SQL Servers in your SharePoint farm
3. Client computers used to access your SharePoint sites
IMPORTANT
If you do not update each of these locations, you run the risk of systems failing to connect to each other using TLS 1.1 or
TLS 1.2. The systems will instead fall back to an older security protocol; and if the older security protocols are disabled, the
systems may fail to connect entirely. > Example: SharePoint servers may fail to connect to SQL Server databases, or client
computers may fail to connect to your SharePoint sites.
Summary of the update process

The following image shows the three step process necessary to enable TLS 1.1 and TLS 1.2 support on your
SharePoint servers, SQL Servers, and client computers.
Step 1: Update SharePoint servers in your SharePoint farm

Follow these steps to update your SharePoint server.
STEPS FOR SHAREPOINT

SERVER WINDOWS SERVER 2008 R2 WINDOWS SERVER 2012 WINDOWS SERVER 2012 R2
1.1 - Enable TLS 1.1 and TLS Required N/A N/A

1.2 in Windows Schannel
1.2 - Enable TLS 1.1 and TLS Required Required N/A

1.2 support in WinHTTP
1.3 - Enable TLS 1.1 and TLS Required Required N/A

1.2 support in Internet
Explorer
1.4 - Install SQL Server 2008 Required Required Required

R2 Native Client update for
TLS 1.2 support
STEPS FOR SHAREPOINT
SERVER WINDOWS SERVER 2008 R2 WINDOWS SERVER 2012 WINDOWS SERVER 2012 R2
1.5 - Install .NET Framework Required Required Required

4.6 or higher
1.6 - Enable strong Required Required Required

cryptography in .NET
Framework 4.6 or higher
The following steps are

recommended. Although
not directly required by
SharePoint Server 2013,
they may be necessary for
other software that
integrates with SharePoint
Server 2013.
1.7 - Install .NET Framework Recommended Recommended Recommended

3.5 update for TLS 1.1 and
TLS 1.2 support
1.8 - Enable strong Recommended Recommended Recommended

Framework 3.5
The following step is

optional. You may choose
to run this step based on
your organization's security
and compliance
requirements.
1.9 - Disable earlier versions Optional Optional Optional

of SSL and TLS in Windows
Schannel
1.1 - Enable TLS 1.1 and TLS 1.2 in Windows Schannel

SSL and TLS support are enabled or disabled in Windows Schannel by editing the Windows Registry. Each SSL
and TLS protocol version can be enabled or disabled independently. You don't need to enable or disable one
protocol version to enable or disable another protocol version.
The Enabled registry value defines whether the protocol version can be used. If the value is set to 0, the protocol
version cannot be used, even if it is enabled by default or if the application explicitly requests that protocol version.
If the value is set to 1, the protocol version can be used if enabled by default or if the application explicitly requests
that protocol version. If the value is not defined, it will use a default value determined by the operating system.
The DisabledByDefault registry value defines whether the protocol version is used by default. This setting only
applies when the application doesn't explicitly request the protocol versions to be used. If the value is set to 0, the
protocol version will be used by default. If the value is set to 1, the protocol version will not be used by default. If
the value is not defined, it will use a default value determined by the operating system.
To enable TLS 1.1 support in Windows Schannel
1. From Notepad.exe, create a text file named tls11-enable.reg.
2. Copy, and then paste the following text.
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
3. Save the tls11-enable.reg file.

4. Double-click the tls11-enable.reg file.
5. Click Yes to update your Windows Registry with these changes.
6. Restart your computer for the change to take effect.


1.2 - Enable TLS 1.1 and TLS 1.2 support in WinHTTP

WinHTTP doesn't inherit its SSL and TLS encryption protocol version defaults from the Windows Schannel
DisabledByDefault registry value. WinHTTP uses its own SSL and TLS encryption protocol version defaults,
which vary by operating system. To override the defaults, you must install a KB update and configure Windows
Registry keys.
The WinHTTP ** DefaultSecureProtocols ** registry value is a bit field that accepts multiple values by adding
them together into a single value. You can use the Windows Calculator program (Calc.exe) in Programmer mode
to add the following hexadecimal values as desired.
DEFAULTSECUREPROTOCOLS VALUE DESCRIPTION
0x00000008 Enable SSL 2.0 by default

0x00000080 Enable TLS 1.0 by default
For example, you can enable TLS 1.0, TLS 1.1, and TLS 1.2 by default by adding the values 0x00000080,
0x00000200, and 0x00000800 together to form the value 0x00000A80.
To install the WinHTTP KB update, follow the instructions from the KB article Update to enable TLS 1.1 and TLS
1.2 as a default secure protocols in WinHTTP in Windows
To enable TLS 1.0, TLS 1.1, and TLS 1.2 by default in WinHTTP
1. From Notepad.exe, create a text file named winhttp-tls10-tls12-enable.reg.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000A80
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
3. Save the winhttp-tls10-tls12-enable.reg file.

4. Double-click the winhttp-tls10-tls12-enable.reg file.
1.3 - Enable TLS 1.1 and TLS 1.2 support in Internet Explorer
Internet Explorer versions earlier than Internet Explorer 11 did not enable TLS 1.1 or TLS 1.2 support by default.
Support for TLS 1.1 and TLS 1.2 is enabled by default starting with Internet Explorer 11.
To enable TLS 1.1 and TLS 1.2 support in Internet Explorer
1. From Internet Explorer, click Tools > Internet Options > Advanced or click > Internet Options >
Advanced.
2. In the Security section, verify that the following check boxes are selected, if not click the following check
boxes:
Use TLS 1.1
Use TLS 1.2
3. Optionally, if you want to disable support for earlier security protocol versions, uncheck the following check
boxes:
Use SSL 2.0
Use SSL 3.0
Use TLS 1.0
NOTE
Disabling TLS 1.0 may cause compatibility issues with sites that don't support newer security protocol versions.
Customers should test this change before performing it in production.
4. Click OK.
1.4 - Install SQL Server 2008 R2 Native Client update for TLS 1.2
support
The SQL Server 2008 R2 Native Client doesn't support TLS 1.1 or TLS 1.2 by default. You must install the SQL
Server 2008 R2 Native Client update for TLS 1.2 support.
To install the SQL Server 2008 R2 Native Client update, see SQL 2008 and 2008 R2 TLS 1.2 SQL Native Client
updates not available in Windows Catalog.
1.5 - Install .NET Framework 4.6 or higher

SharePoint 2013 requires .NET Framework 4.6, .NET Framework 4.6.1, or .NET Framework 4.6.2 to support TLS
1.2. Microsoft recommends installing the latest version of .NET Framework for the latest functionality and
reliability improvements.
To install .NET Framework 4.6.2, see the KB article Microsoft .NET Framework 4.6.2 (Web Installer) for Windows
To install .NET Framework 4.6.1, see the KB article The .NET Framework 4.6.1 web installer for Windows
To install .NET Framework 4.6, see the KB article Microsoft .NET Framework 4.6 (Web Installer) for Windows
1.6 - Enable strong cryptography in .NET Framework 4.6 or higher

.NET Framework 4.6 and higher doesn't inherit its SSL and TLS encryption protocol version defaults from the
Windows Schannel DisabledByDefault registry value. Instead, it uses its own SSL and TLS encryption protocol
version defaults. To override the defaults, you must configure Windows Registry keys.
The SchUseStrongCrypto registry value changes the .NET Framework 4.6 and higher encryption protocol
version default from SSL 3.0 or TLS 1.0 to TLS 1.0 or TLS 1.1 or TLS 1.2. In addition, it restricts the use of
encryption algorithms with TLS that are considered weak such as RC4.
Applications compiled for .NET Framework 4.6 or higher will behave as if the SchUseStrongCrypto registry
value is set to 1, even if it isn't. To ensure all .NET Framework applications will use strong cryptography, you must
configure this Windows Registry value.
To enable strong cryptography in .NET Framework 4.6 or higher
1. From Notepad.exe, create a text file named net46-strong-crypto-enable.reg.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
3. Save the net46-strong-crypto-enable.reg file.

4. Double-click the net46-strong-crypto-enable.reg file.
1.7 - Install .NET Framework 3.5 update for TLS 1.1 and TLS 1.2
support
.NET Framework 3.5 doesn't support TLS 1.1 or TLS 1.2 by default. To add support for TLS 1.1 and TLS 1.2, you
must install a KB update, and then manually configure Windows Registry keys.
SharePoint 2013 is built on .NET Framework 4.x and doesn't use .NET Framework 3.5. However, certain
prerequisite components and third party software that integrates with SharePoint 2013 may use .NET Framework
3.5. Microsoft recommends installing and configuring this update to improve compatibility with TLS 1.2.
The SystemDefaultTlsVersions registry value defines which security protocol version defaults will be used by
.NET Framework 3.5. If the value is set to 0, .NET Framework 3.5 will default to SSL 3.0 or TLS 1.0. If the value is
set to 1, .NET Framework 3.5 will inherit its defaults from the Windows Schannel DisabledByDefault registry
values. If the value is undefined, it will behave as if the value is set to 0.
** For Windows Server 2008 R2 **
1. To install the .NET Framework 3.5.1 update for Windows Server 2008 R2, see the KB article Support for
TLS System Default Versions included in the .NET Framework 3.5.1 on Windows 7 SP1 and Server 2008
R2 SP1
2. After the KB update is installed, manually configure the registry keys.
For Windows Server 2012
1. To install the .NET Framework 3.5 update for Windows Server 2012, see the KB article Support for TLS
System Default Versions included in the .NET Framework 3.5 on Windows Server 2012
For Windows Server 2012 R2
1. To install the .NET Framework 3.5 SP1 update for Windows Server 2012 R2, see the KB article Support for
TLS System Default Versions included in the .NET Framework 3.5 on Windows 8.1 and Windows Server
2012 R2
To manually configure the registry keys, do the following:
1. From Notepad.exe, create a text file named net35-tls12-enable.reg.

"SystemDefaultTlsVersions"=dword:00000001
3. Save the net35-tls12-enable.reg file.

4. Double-click the net35-tls12-enable.reg file.
1.8 - Enable strong cryptography in .NET Framework 3.5

The SchUseStrongCrypto registry value restricts the use of encryption algorithms with TLS that are considered
weak such as RC4.
Microsoft has released an optional security update for .NET Framework 3.5 that will automatically configure the
Windows Registry keys for you.
Windows Server 2008 R2
To enable strong cryptography in .NET Framework 3.5.1 on Windows Server 2008 R2, see the KB article
Description of the security update for the .NET Framework 3.5.1 on Windows 7 Service Pack 1 and Windows
Server 2008 R2 Service Pack 1: May 13, 2014
Windows Server 2012
To enable strong cryptography in .NET Framework 3.5 on Windows Server 2012, see the KB article Description of
the security update for the .NET Framework 3.5 on Windows 8 and Windows Server 2012: May 13, 2014
To enable strong cryptography in .NET Framework 3.5 on Windows Server 2012 R2 see the KB article Description
of the security update for the .NET Framework 3.5 on Windows 8.1 and Windows Server 2012 R2: May 13, 2014
1.9 - Disable earlier versions of SSL and TLS in Windows Schannel

IMPORTANT
Microsoft recommends disabling SSL 2.0 and SSL 3.0 due to serious security vulnerabilities in those protocol versions. >
Customers may also choose to disable TLS 1.0 and TLS 1.1 to ensure that only the newest protocol version is used. However,
this may cause compatibility issues with software that doesn't support the newest TLS protocol version. Customers should
test such a change before performing it in production.
To disable SSL 2.0 support in Windows Schannel
1. From Notepad.exe, create a text file named ssl20-disable.reg.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]
3. Save the ssl20-disable.reg file.

4. Double-click the ssl20-disable.reg file.


To disable TLS 1.0 support in Windows Schannel
1. From Notepad.exe, create a text file named tls10-disable.reg.

3. Save the tls10-disable.reg file.

4. Double-click the tls10-disable.reg file.


Step 2: Update your Microsoft SQL Servers in your SharePoint farm

Follow these steps to update your SQL Servers in your SharePoint farm.
STEPS FOR YOUR SQL SERVERS WINDOWS SERVER 2008 R2 WINDOWS SERVER 2012 WINDOWS SERVER 2012 R2

2.2 - Enable TLS 1.1 and TLS Required Required Required

1.2 support in Microsoft
SQL Server

optional. Run this step
depending on your
organization's security and
compliance requirements.

Schannel





2.2 - Enable TLS 1.1 and TLS 1.2 support in Microsoft SQL Server
SQL Server versions earlier than SQL Server 2016 don't support TLS 1.1 or TLS 1.2 by default. To add support for
TLS 1.1 and TLS 1.2, you must install updates for SQL Server.
To enable TLS 1.1 and TLS 1.2 support in SQL Server, follow the instructions from the KB article TLS 1.2 support
for Microsoft SQL Server

IMPORTANT







Step 3: Update your client computers used to access your SharePoint

sites
Follow these steps to update your client computers that access your SharePoint site.
STEPS FOR YOUR CLIENT
COMPUTERS WINDOWS 7 WINDOWS 8.1 WINDOWS 10

3.2 Enable TLS 1.1 and TLS Required N/A N/A


Explorer


TLS 1.2 support

they provide better security
by restricting the use of
weak encryption algorithms.

Framework 3.5

and compliance
requirements.

Schannel





3.2 Enable TLS 1.1 and TLS 1.2 support in WinHTTP

Registry keys.
The WinHTTP ** DefaultSecureProtocols ** registry value is a bit field that accepts multiple values by adding
them together into a single value. You can use the Windows Calculator program (Calc.exe) in Programmer mode
to add the following hexadecimal values as desired.
For 64-bit operating system

**For 32-bit operating system**

Advanced.
2. In the Security section, verify that the following check boxes are selected. If not, click the following check
boxes:
Use TLS 1.1
Use TLS 1.2
boxes:
Use SSL 2.0
Use SSL 3.0
Use TLS 1.0
NOTE
4. Click OK.

.NET Framework 4.5 and higher doesn't inherit its SSL and TLS encryption protocol version defaults from the
Windows Schannel DisabledByDefault registry value. Instead, it uses its own SSL and TLS encryption protocol
The SchUseStrongCrypto registry value changes the .NET Framework 4.5 and higher security protocol version
default from SSL 3.0 or TLS 1.0 to TLS 1.0 or TLS 1.1 or TLS 1.2. In addition, it restricts the use of encryption
algorithms with TLS that are considered weak such as RC4.
Microsoft has released an optional security update for .NET Framework 4.5, 4.5.1, and 4.5.2 that will automatically
configure the Windows Registry keys for you. No updates are available for .NET Framework 4.6 or higher. You
must manually configure the Windows Registry keys on .NET Framework 4.6 or higher.
For Windows 7 and Windows Server 2008 R2
To enable strong cryptography in .NET Framework 4.5 and 4.5.1 on Windows 7 and Windows Server 2008 R2, see
the KB article Description of the security update for the .NET Framework 4.5 and the .NET Framework 4.5.1 on
Windows 7 Service Pack 1 and Windows Server 2008 R2 Service Pack 1: May 13, 2014.
To enable strong cryptography in .NET Framework 4.5.2 on Windows 7 and Windows Server 2008 R2, see the KB
article Description of the security update for the .NET Framework 4.5.2 on Windows 7 Service Pack 1 and
Windows Server 2008 R2 Service Pack 1: May 13, 2014.
To enable strong cryptography in .NET Framework 4.5, 4.5.1, and 4.5.2 on Windows Server 2012, see the KB
article Description of the security update for the .NET Framework 4.5, the .NET Framework 4.5.1, and the .NET
Framework 4.5.2 on Windows 8, Windows RT, and Windows Server 2012: May 13, 2014.
Windows 8.1 and Windows Server 2012 R2
To enable strong cryptography in .NET Framework 4.5.1 and 4.5.2 on Windows 8.1 and Windows Server 2012 R2,
see the KB article Description of the security update for the .NET Framework 4.5.1 and the .NET Framework 4.5.2
on Windows 8.1, Windows RT 8.1, and Windows Server 2012 R2: May 13, 2014.



3.5 - Install .NET Framework 3.5 update for TLS 1.1 and TLS 1.2
support
must install a KB update, and then manually configure Windows Registry keys for each of the operating systems
listed in this section.
To enable .NET Framework 3.5 to inherit its encryption protocol defaults from Windows
Windows 7 and Windows Server 2008 R2
1. To install the .NET Framework 3.5.1 update for Windows 7 and Windows Server 2008 R2, see the KB article
Support for TLS System Default Versions included in the .NET Framework 3.5.1 on Windows 7 SP1 and
Server 2008 R2 SP1 .
1. To install the .NET Framework 3.5 SP1 update for Windows 8.1 and Windows Server 2012 R2, see the KB
article Support for TLS System Default Versions included in the .NET Framework 3.5 on Windows 8.1 and
Windows 10 (Version 1507)
This functionality is not available in Windows 10 Version 1507. You must upgrade to Windows 10 Version
1511, and then install the Cumulative Update for Windows 10 Version 1511 and Windows Server 2016
Technical Preview 4: May 10, 2016, or upgrade to Windows 10 Version 1607 or higher.
Windows 10 (Version 1511)
1. To install the Cumulative Update for Windows 10 Version 1511 and Windows Server 2016 Technical
Preview 4: May 10, 2016, see Cumulative Update for Windows 10 Version 1511 and Windows Server 2016
Technical Preview 4: May 10, 2016.
Windows 10 (Version 1607) and Windows Server 2016
No update needs to be installed. Configure the Windows Registry keys as described below.




weak such as RC4.
Microsoft has released an optional security update for .NET Framework 3.5 on pre-Windows 10 operating
systems that will automatically configure the Windows Registry keys for you. No updates are available for
Windows 10. You must manually configure the Windows Registry keys on Windows 10.
Windows 7 and Windows Server 2008 R2
Windows Server 2008 R2 Service Pack 1: May 13, 2014
To enable strong cryptography in .NET Framework 3.5 on Windows 8.1 and Windows Server 2012 R2 see the KB
article Description of the security update for the .NET Framework 3.5 on Windows 8.1 and Windows Server 2012
R2: May 13, 2014
To enable strong cryptography in .NET Framework 3.5 on Windows 10 and Windows Server 2016




IMPORTANT








Enable TLS 1.1 and TLS 1.2 support in SharePoint
Server 2016

To enable TLS protocol versions 1.1 and 1.2 in your SharePoint 2016 environment, you need to install updates and
change configuration settings in each of the following locations:
IMPORTANT
If you do not update each of these locations, you run the risk of systems failing to connect to each other using TLS 1.1 or
TLS 1.2. The systems will instead fall back to an older security protocol; and if the older security protocols are disabled, the
systems may fail to connect entirely. > Example: SharePoint servers may fail to connect to SQL Server databases, or client
computers may fail to connect to your SharePoint sites.


Follow these steps to update your SharePoint server.
STEPS FOR SHAREPOINT SERVER WINDOWS SERVER 2012 R2 WINDOWS SERVER 2016
1.1 - Install ODBC Driver 11 for SQL Required Required

Server update for TLS 1.2 support
1.2 - Install SQL Server 2012 Native Required Required

Client update for TLS 1.2 support
The following steps are

recommended. Although not directly
required by SharePoint Server 2016,
they may be necessary for other
software that integrates with
STEPS FOR SHAREPOINT SERVER WINDOWS SERVER 2012 R2 WINDOWS SERVER 2016
1.3 - Install .NET Framework 3.5 update Recommended Recommended

for TLS 1.1 and TLS 1.2 support
1.4 - Enable strong cryptography in Recommended Recommended

.NET Framework 3.5
The following step is optional. You may

choose to run this step based on your
organization's security and compliance
requirements.
1.5 - Disable earlier versions of SSL and Optional Optional

TLS in Windows Schannel
1.1 - Install ODBC Driver 11 for SQL Server update for TLS 1.2 support
ODBC Driver 11 for SQL Server doesn't support TLS 1.1 or TLS 1.2 by default. You must install the ODBC Driver
11 for SQL Server update for TLS 1.2 support.
To install ODBC Driver 11 for SQL Server update for TLS 1.2 support, see Microsoft® ODBC Driver 11 for
SQL Server® - Windows.
1.2 - Install SQL Server 2012 Native Client update for TLS 1.2 support
SQL Server 2012 Native Client doesn't support TLS 1.1 or TLS 1.2 by default. You must install the SQL Server
2012 Native Client update for TLS 1.2 support.
To install the SQL Server 2012 Native Client update, see Microsoft® SQL Server® 2012 Native Client - QFE.
1.3 - Install .NET Framework 3.5 update for TLS 1.1 and TLS 1.2 support
.NET Framework 3.5 doesn't support TLS 1.1 or TLS 1.2 by default.
IMPORTANT
To add support for TLS 1.1 and TLS 1.2 in Windows Server 2012 R2, you must install a KB update, and then manually
configure Windows Registry keys. > For Windows Server 2016, you only configure the registry keys.
SharePoint Server 2016 is built on .NET Framework 4.x and doesn't use .NET Framework 3.5. However, certain
prerequisite components and third party software that integrates with SharePoint Server 2016 may use .NET
Framework 3.5. Microsoft recommends installing and configuring this update to improve compatibility with TLS
1.2.
.NET Framework 3.5. If the value is set to 0, .NET Framework 3.5 will default SSL 3.0 or TLS 1.0. If the value is set
to 1, .NET Framework 3.5 will inherit its defaults from the Windows Schannel DisabledByDefault registry
To enable .NET Framework 3.5 to inherit its security protocol defaults from Windows Schannel
For Windows Server 2012 R2
1. To install the .NET Framework 3.5 SP1 update for Windows Server 2012 R2, see the KB article Support for
TLS System Default Versions included in the .NET Framework 3.5 on Windows 8.1 and Windows Server
2012 R2.
For Windows Server 2016, manually configure the registry keys.


weak such as RC4.
Microsoft has released an optional security update for .NET Framework 3.5 on Windows Server 2012 R2 that will
automatically configure the Windows Registry keys for you. No updates are available for Windows Server 2016.
You must manually configure the Windows Registry keys on Windows Server 2016.
To enable strong cryptography in .NET Framework 3.5 for Windows Server 2012 R2, see the KB article
Description of the security update for the .NET Framework 3.5 on Windows 8.1 and Windows Server 2012 R2:
May 13, 2014
Windows Server 2016
To enable strong cryptography in .NET Framework 3.5 for Windows Server 2016, configure the following
Windows registry keys:


IMPORTANT





4. Double-click the tls10-disable.reg.


Follow these steps to update the SQL Servers in your SharePoint farm.
STEPS FOR YOUR SQL SERVERS WINDOWS SERVER 2012 R2 WINDOWS SERVER 2016
2.1 - Enable TLS 1.1 and TLS 1.2 Required Required

support in Microsoft SQL Server

requirements.
2.2 - Disable earlier versions of SSL and Optional Optional

TLS in Windows Schannel
2.1 - Enable TLS 1.1 and TLS 1.2 support in Microsoft SQL Server
SQL Server versions earlier than SQL Server 2016 don't support TLS 1.1 or TLS 1.2 by default. To add support for
TLS 1.1 and TLS 1.2, you must install updates for SQL Server.
To enable TLS 1.1 and TLS 1.2 support in SQL Server, follow the instructions from the KB article TLS 1.2
support for Microsoft SQL Server
IMPORTANT
Customers may also choose to disable TLS 1.0 and 1.1 to ensure that only the newest protocol version is used. However, this
may cause compatibility issues with software that doesn't support the newest TLS protocol version. Customers should test
such a change before performing it in production.








sites




Explorer


TLS 1.2 support


Framework 3.5

and compliance
requirements.

Schannel





Registry keys.
The WinHTTP DefaultSecureProtocols registry value is a bit field that accepts multiple values by adding them
together into a single value. You can use the Windows Calculator program (Calc.exe) in Programmer mode to add
the following hexadecimal values as desired.
For **32-bit operating system**

Advanced.
boxes:
Use TLS 1.1
Use TLS 1.2
boxes:
Use SSL 2.0
Use SSL 3.0
Use TLS 1.0
NOTE
4. Click OK.
.NET Framework 4.5 and higher doesn't inherit its SSL and TLS security protocol version defaults from the
Windows Schannel DisabledByDefault registry value. Instead, it uses its own SSL and TLS security protocol
To enable strong cryptography in .NET Framework 4.5 and 4.5.1 on Windows 7 and Windows Server 2008
R2, see the KB article Description of the security update for the .NET Framework 4.5 and the .NET
Framework 4.5.1 on Windows 7 Service Pack 1 and Windows Server 2008 R2 Service Pack 1: May 13,
2014.
To enable strong cryptography in .NET Framework 4.5.2 on Windows 7 and Windows Server 2008 R2, see
the KB article Description of the security update for the .NET Framework 4.5.2 on Windows 7 Service Pack
1 and Windows Server 2008 R2 Service Pack 1: May 13, 2014.
For Windows 8.1 and Windows Server 2012 R2
To enable strong cryptography in .NET Framework 4.5.1 and 4.5.2 on Windows 8.1 and Windows Server 2012
R2, see the KB article Description of the security update for the .NET Framework 4.5.1 and the .NET
Framework 4.5.2 on Windows 8.1, Windows RT 8.1, and Windows Server 2012 R2: May 13, 2014.


must install a KB update and configure Windows Registry keys for each of the operating systems listed in this
section.
To enable .NET Framework 3.5 to inherit its encryption protocol defaults from Windows Schannel
Server 2008 R2 SP1
For Windows 10 (Version 1507)
Windows 10 (Version 1607) and Windows Server 2016
To manually configure the registry keys, do these steps.


weak such as RC4.
Microsoft has released an optional security update for .NET Framework 3.5 on pre-Windows 10 operating
systems that will automatically configure the Windows Registry keys for you. No updates are available for
Windows 10. You must manually configure the Windows Registry keys on Windows 10.
R2: May 13, 2014
To enable strong cryptography in .NET Framework 3.5 on Windows 10

IMPORTANT







Enable TLS 1.1 and TLS 1.2 support in SharePoint
Server 2019

SharePoint Server 2019 supports TLS protocol versions 1.0, 1.1, and 1.2 by default. However, to enable end-to-end
support for TLS protocol versions 1.1 and 1.2 in your SharePoint 2019 environment, you may need to install
updates or change configuration settings in the following locations:
IMPORTANT
If you do not update each of these locations, you run the risk of systems failing to connect to each other using TLS 1.1 or TLS
1.2. The systems will instead fall back to an older security protocol; and if the older security protocols are disabled, the
systems may fail to connect entirely.
Example: Client computers may fail to connect to your SharePoint sites.


SharePoint Server 2019 supports TLS protocol versions 1.0, 1.1, and 1.2 by default. No changes are necessary on
the SharePoint servers in your farm to enable TLS 1.1 or TLS 1.2 support. Follow this step to update your
SharePoint server if you wish to disable certain TLS protocol versions.
STEPS FOR SHAREPOINT SERVER WINDOWS SERVER 2016 WINDOWS SERVER 2019

requirements.
1.0 - Disable earlier versions of TLS in Optional Optional

Windows Schannel
1.0 - Disable earlier versions of TLS in Windows Schannel
IMPORTANT
SSL 2.0 and SSL 3.0 are disabled by default in Windows Server 2016 and Windows Server 2019 due to serious security
vulnerabilities in those protocol versions.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS
1.0\Client]
1.0\Server]

4. Double-click the tls10-disable.reg.
1.1\Client]
1.1\Server]


SQL Server 2016 and SQL Server 2017 support TLS protocol versions 1.0, 1.1, and 1.2 by default on Windows
Server 2016 and Windows Server 2019. No changes are necessary on the SQL servers in your SharePoint farm to
enable TLS 1.1 or TLS 1.2 support. For more information about TLS support in SQL Server, review the KB article
TLS 1.2 support for Microsoft SQL Server.
Follow this step to update the SQL Servers in your SharePoint farm if you wish to disable certain TLS protocol
versions.
STEPS FOR YOUR SQL SERVERS WINDOWS SERVER 2016 WINDOWS SERVER 2019

requirements.
2.1 - Disable earlier versions of TLS in Optional Optional

Windows Schannel
2.1 - Disable earlier versions of TLS in Windows Schannel

IMPORTANT
SSL 2.0 and SSL 3.0 are disabled by default in Windows Server 2016 and Windows Server 2019 due to serious security
vulnerabilities in those protocol versions.

1.0\Client]
1.0\Server]


1.1\Client]
1.1\Server]


sites



Explorer


TLS 1.2 support


Framework 3.5

and compliance
requirements.

Schannel


1.1\Client]
1.1\Server]


1.2\Client]
1.2\Server]

Registry keys.
The WinHTTP DefaultSecureProtocols registry value is a bit field that accepts multiple values by adding them
together into a single value. You can use the Windows Calculator program (Calc.exe) in Programmer mode to add
the following hexadecimal values as desired.



Advanced.
boxes:
Use TLS 1.1
Use TLS 1.2
boxes:
Use SSL 2.0
Use SSL 3.0
Use TLS 1.0
NOTE
4. Click OK.
.NET Framework 4.5 and higher doesn't inherit its SSL and TLS security protocol version defaults from the
Windows Schannel DisabledByDefault registry value. Instead, it uses its own SSL and TLS security protocol
Applications compiled for .NET Framework 4.6 or higher will behave as if the SchUseStrongCrypto registry value
is set to 1, even if it isn't. To ensure all .NET Framework applications will use strong cryptography, you must
To enable strong cryptography in .NET Framework 4.5 and 4.5.1 on Windows 7 and Windows Server 2008
R2, see the KB article Description of the security update for the .NET Framework 4.5 and the .NET
Framework 4.5.1 on Windows 7 Service Pack 1 and Windows Server 2008 R2 Service Pack 1: May 13, 2014.
To enable strong cryptography in .NET Framework 4.5.2 on Windows 7 and Windows Server 2008 R2, see
the KB article Description of the security update for the .NET Framework 4.5.2 on Windows 7 Service Pack 1
and Windows Server 2008 R2 Service Pack 1: May 13, 2014.
To enable strong cryptography in .NET Framework 4.5.1 and 4.5.2 on Windows 8.1 and Windows Server 2012
R2, see the KB article Description of the security update for the .NET Framework 4.5.1 and the .NET Framework
4.5.2 on Windows 8.1, Windows RT 8.1, and Windows Server 2012 R2: May 13, 2014.



must install a KB update and configure Windows Registry keys for each of the operating systems listed in this
section.
To enable .NET Framework 3.5 to inherit its encryption protocol defaults from Windows Schannel
Server 2008 R2 SP1
Windows 10 (Version 1607) and higher, Windows Server 2016, and Windows Server 2019
To manually configure the registry keys, do these steps.



weak such as RC4.
Microsoft has released an optional security update for .NET Framework 3.5 on pre-Windows 10 operating systems
that will automatically configure the Windows Registry keys for you. No updates are available for Windows 10. You
must manually configure the Windows Registry keys on Windows 10.
R2: May 13, 2014
To enable strong cryptography in .NET Framework 3.5 on Windows 10



IMPORTANT
Microsoft recommends disabling SSL 2.0 and SSL 3.0 due to serious security vulnerabilities in those protocol versions.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL
2.0\Client]
2.0\Server]


3.0\Client]
3.0\Server]


1.0\Client]
1.0\Server]


1.1\Client]
1.1\Server]

Plan security hardening for SharePoint Server
Secure server snapshots

In a server farm environment, individual servers have 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:
SharePoint servers
Database server role
The snapshots are divided into common configuration categories. The characteristics defined for each category
represent the optimal hardened state for SharePoint Server. This article does not include hardening guidance for
other software in the environment.
In addition to hardening servers for specific roles, it is important to protect the SharePoint farm by placing a
firewall between the farm servers and outside requests. The guidance in this article can be used to configure a
firewall.
SharePoint servers
This section identifies hardening characteristics for SharePoint 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:
ASP.NET State service (if you are using InfoPath Forms
Services or Project Server 2016)
View State service (if you are using InfoPath Forms Services)
World Wide Web Publishing Service
Ensure that these services are not disabled:
Claims to Windows Token Service
SharePoint Administration
SharePoint Timer Service
SharePoint Tracing Service
SharePoint VSS Writer
Ensure that these services are not disabled on the servers that
host the corresponding roles:
AppFabric Caching Service
SharePoint User Code Host
SharePoint Search Host Controller
SharePoint Server Search
Ports and protocols
TCP 80, TCP 443 (SSL)

Custom ports for search crawling, if configured (such as for
crawling a file share or a website on a non-default port)
Ports used by the search index component — TCP 16500-
16519 (intra-farm only)
Ports required for the AppFabric Caching Service — TCP
22233-22236
Ports required for Windows Communication Foundation
communication — TCP 808
Ports required for communication between SharePoint servers
and service applications (the default is HTTP):
HTTP binding: TCP 32843
HTTPS binding: TCP 32844
net.tcp binding: TCP 32845 (only if a third party has
implemented this option for a service application)
If your computer network environment uses Windows Server
2012, Windows Server 2008, Windows Server 2008 R2,
Windows 7, or Windows Vista together with versions of
Windows earlier than Windows Server 2012 and Windows
Vista, you must enable connectivity over both the following
port ranges:
High port range 49152 through 65535
Low port range 1025 through 5000
Default ports for SQL Server communication — TCP 1433,
UDP 1434. If these ports are blocked on the SQL Server
computer and databases are installed on a named instance,
configure a SQL Server client alias for connecting to the
named instance.
Microsoft SharePoint Foundation User Code Service (for
sandbox solutions) — TCP 32846. This port must be open for
outbound connections on all Front-end and Front-end with
Distributed Cache servers. This port must be open for
inbound connections on Front-end and Front-end with
Distributed Cache 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.
SMTP for e-mail integration — TCP 25, or a custom TCP port
if you've configured outbound e-mail to use a non-default
port.
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.
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 are 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. Performance can be affected by
uploads that exceed 100 MB.
Database server role
NOTE
With the addition to the MinRole feature in SharePoint Server 2016, the concept of roles has changed. For information about
roles, see Planning for a MinRole server deployment in SharePoint Server 2016.
The primary recommendation for SharePoint Server is to secure inter-farm communication by blocking the
default ports used for 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.
Ports Block UDP 1434.

Consider blocking TCP 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 Server.
In this section:
Blocking the standard SQL Server ports
Service application communication
Connections to external servers
Service requirements for e-mail integration
Service requirements for session state
SharePoint Server 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 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 1433. If this communication is
unsuccessful, the client computers query the SQL Server Resolution Service that is listening on UDP 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.
NOTE
We recommend to use the standard SQL ports, but ensure the firewall is configured to only allow communication with the
servers that need access to the SQL Server. Servers that don't need access to the SQL Server should be blocked from
connecting to the SQL Server over TCP port 1433 and UDP port 1444.
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, 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 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. In this scenario, the
SQL Server client alias specifies the TCP port that the named instance is listening on.
To connect to an instance of SQL Server, 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 Server ports, see Configure SQL Server security for
SharePoint Server.
Service application communication
By default, communication between SharePoint servers and service applications within a farm takes place by using
HTTP with a binding to TCP 32843. When you publish a service application, you can select either HTTP or HTTPS
with the following bindings:
HTTP binding: TCP 32843
HTTPS binding: TCP 32844
Additionally, third parties that develop service applications can implement a third choice:
net.tcp binding: TCP 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.
The HTTP/HTTPS/net.tcp bindings can also be viewed and changed by using the Get-SPServiceHostConfig and
Set-SPServiceHostConfig Microsoft PowerShell cmdlets.
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.
Connections to external servers
Several features of SharePoint Server can be configured to access data that resides on server computers outside of
the server farm. If you configure access to data that is located on external server computers, ensure that you
enable communication between the appropriate computers. In most cases, the ports, protocols, and services that
are used depend on the external resource. For example:
Connections to file shares use the File and Printer Sharing service.
Connections to external SQL Server databases use the default or customized ports for SQL Server
communication.
Connections to Oracle databases typically use OLE DB.
Connections to Web services use both HTTP and HTTPS.
The following table lists features that can be configured to access data that resides on server computers outside
the server farm.
FEATURE DESCRIPTION
Content crawling You can configure crawl rules to crawl data that resides on
external resources, including Web sites, file shares, Exchange
public folders, and business data applications. When crawling
external data sources, the crawl role communicates directly
with these external resources.
For more information, see Manage crawling in SharePoint
Server.
Business Data Connectivity connections Web servers and application servers communicate directly
with computers that are configured for Business Data
Connectivity connections.
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 Server includes 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 Server objects. Only this OU should allow write access to the account that is used by the Microsoft
SharePoint Directory Management Service.
Service requirements for session state
Both Project Server 2016 and InfoPath Forms Services maintain session state. If you are deploying these features
or products within your server farm, do not disable the ASP.NET State service. Additionally, if you are deploying
InfoPath Forms Services, do not disable the View State service.
SharePoint Server Products services
Do not disable services that are installed by SharePoint Server (listed in the snapshot previously).
If your environment disallows services that run as a local system, you can consider disabling the SharePoint
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 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 Microsoft 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 Server 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 Server automatically creates 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
Concepts
Plan for least-privileged administration in SharePoint
Server

The concept of least-privileged administration is to assign 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 account under which a service runs is granted access to
only the resources that are absolutely necessary.
We recommend that you deploy SharePoint Server with least-privileged administration even though 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 made more complex.
Introduction
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. 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.
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 Server. As administrators lock down additional accounts and services,
daily operational costs are likely to increase.
SQL Server roles
In a SharePoint Server environment, several accounts may be granted the following two SQL Server server-level
roles. In a least-privileged SharePoint Server environment, we recommend that you only grant these privileges to
the account under which the Microsoft SharePoint Foundation Workflow Timer Service runs. Typically, the timer
service runs under the server farm account. For day-to-day operations, we recommend that you remove the
following two SQL Server server-level roles from all other accounts that 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 securityadmin to assign most server permissions. You should treat the
securityadmin role as equal to the sysadmin role.
For additional information about SQL Server server-level roles, see Server Level Roles.
If you remove one or more of these SQL Server roles, you might receive "Unexpected" error messages 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, you may be unable to perform any of the following tasks:
Restore a backup of a farm because you can't write to a database
Provision a service instance or web application
Configure managed accounts
Change managed accounts for web applications
Perform any action on any database, managed account, or service that requires the Central Administration
web site
In certain situations, database administrators (DBAs) may want to operate independently from SharePoint Server
administrators and 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
SharePoint Server database requirements to the DBA, who then creates the necessary databases and sets up the
logins that are required for the farm.
By default, the DBA has complete access to the SQL Server instance but requires additional permissions to access
SharePoint Server. DBAs typically use Windows PowerShell 3.0 when they add, create, move, or rename
SharePoint databases, so they must be a member of the following accounts:
Securityadmin fixed server role on the SQL Server instance.
Db_owner fixed database role on all databases in the SharePoint farm.
Administrators group on the computer on which they run the PowerShell cmdlets.
Additionally, the DBA may have to be a member of the SharePoint_Shell_Access role to access the SharePoint
content database. In some conditions, the DBA may want to add the Setup user account to the db_owner role.
SharePoint Server roles and services
In general, you should remove the ability to create new databases from SharePoint Server service accounts. Other
than the account under which the timer service runs (typically the farm account), no SharePoint Server service
account should have the sysadmin role on the SQL Server instance and no SharePoint Server service account
should be a local Administrator on the server that runs SQL Server.
For more information about SharePoint Server accounts, see Account permissions and security settings in
For account information in SharePoint Server 2013, see Account permissions and security settings in SharePoint
2013.
The following list provides information about locking down other SharePoint Server roles and services:
SharePoint_Shell_Access role
When you remove this SQL Server role, you remove the ability to write entries to the configuration and
content database and the ability to perform any tasks by using Microsoft PowerShell. For additional
information about this role, see Add-SPShellAdmin.
SharePoint Timer service (SPTimerV4)
We recommend that you do not limit the default permissions granted to the account under which this
service runs and that you never disable this account. Instead, use a secure user account, for which the
password is not widely known, and leave the service running. By default, this service is installed when you
install SharePoint Server and maintains configuration cache information. If you set the service type to
disabled you may experience the following behavior:
Timer jobs won't run
Health analyzer rules won't 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. We recommend
that you do not limit the default permissions granted to the account under which this service runs and that
you never disable this account. Instead, use a secure user account, for which the password is not widely
known, and leave the service running. If you set the service type to disabled, you may experience the
following behavior:
Administrative timer jobs won't run
Web configuration files won't be updated
Security and local groups won't be updated
Registry values and keys won't 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. If you
are not using sandboxed solutions, you can disable this service.
Claims To Windows Token service (C2WTS )
By default, this service is disabled. The C2WTS service may be required for a deployment with Excel
Services, PerformancePoint Servers, or SharePoint shared services that must translate between SharePoint
security tokens and Windows-based identities. For example, you use this service when you configure
Kerberos-constrained delegation for accessing external data sources. For more information about C2WTS,
see Plan for Kerberos authentication in SharePoint Server.
The following features may experience additional symptoms under certain circumstances:
Backup and restore
The ability to perform a restore from a backup may fail if you have removed database permissions.
Upgrade
The upgrade process starts correctly, but then fails if you do not have suitable permissions to databases. If
your organization is already in a least-privileged environment, the workaround is to 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 things to consider for a least-privileged environment
In addition to the previous considerations, you might have to consider more operations. The following list is
incomplete. Selectively use the items at your own discretion:
Setup user 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 SharePoint Server farm. For additional information about
this account, see Initial deployment administrative and service accounts in SharePoint Server.
Synchronization account - For SharePoint Server Server, this account is used to connect to the directory
service. We recommend that you do not limit the default permissions granted to the account under which
this service runs and that you never disable this account. Instead, use a secure user account, for which the
password is not widely known, and leave the service running. This account also requires Replicate Directory
Changes permission on AD DS which enables the account to read AD DS objects and to discover AD DS
objects that were changed in the domain. The Grant Replicate Directory Changes permission does not
enable an account to create, change or delete AD DS objects.
My Site host application pool account - This is the account under which the My Site application pool
runs. To configure this account, you must be a member of the Farm Administrators group. You can limit
privileges to this account.
Built-in user group - Removing the built-in user security group or changing the permissions may have
unanticipated consequences. We recommend that you do not limit privileges to any built-in accounts or
groups.
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 SharePoint Server to work
correctly. If other services or applications are running on a server, you might consider how they access the
Tasks or Hosts folder locations. For additional information about account settings for SharePoint Server, see
Account permissions and security settings in SharePoint Server 2016.
For account information in SharePoint Server 2013, see Account permissions and security settings in
SharePoint 2013.
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.
See also
Other Resources
Least Privilege Configuration for Workflow Manager with SharePoint 2013
Configure SQL Server security for SharePoint Server

When you install SQL Server, the default settings help to provide a safe database. In addition, you can use SQL
Server tools and Windows Firewall to add additional security to SQL Server for SharePoint Server environments.
IMPORTANT
The security steps in this topic are fully tested by the SharePoint team. There are other ways to help secure SQL Server in a
SharePoint Server farm. For more information, see Securing SQL Server.
Before you begin

Before you begin this operation, review the following tasks about how to secure your server farm:
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 that is running SQL Server.
Configuring a SQL Server instance to listen on a non-default port

SQL Server provides the ability to reassign the ports that are used by the default instance and any named
instances. In SQL Server Service Pack 1 (SP1), you reassign the TCP port by using SQL Server Configuration
Manager. When you change the default ports, you make the environment more secure against hackers who know
default assignments and use them to exploit your SharePoint environment.
To configure a SQL Server instance to listen on a non-default port
1. Verify that the user account that is performing this procedure is a member of either the sysadmin or the
serveradmin fixed server role.
2. On the computer that is running SQL Server, open SQL Server Configuration Manager.
3. In the navigation pane, expand SQL Server Network Configuration.
4. 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.
5. In the main window in the Protocol Name column, right-click TCP/IP, and then click Properties.
6. Click the IP Addresses tab.
For every IP address that is assigned to the computer that is 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.
7. To globally change the port that the default instance is listening on, follow these steps:
For each IP address except IPAll, clear all values for both TCP dynamic ports and TCP Port.
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. To globally change the port that a named instance is listening on, follow these steps:
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.
For each IP address except IPAll, clear all values for TCP Port.
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.
9. Click OK.
A message indicates that the change will not take effect until the SQL Server service is restarted. Click OK.
10. Close SQL Server Configuration Manager.
11. Restart the SQL Server service and confirm that the computer that is running SQL Server is listening on
the port that you selected.
You can confirm this by looking in the Event Viewer log after you restart 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]
12. Verification: Optionally, include steps that users should perform to verify that the operation was
successful.
Blocking default SQL Server listening ports

Windows Firewall with Advanced Security uses Inbound Rules and Outbound Rules to help 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 and Configuring the Windows Firewall to Allow SQL Server Access.
Configuring Windows Firewall to open manually assigned ports
To access a SQL Server instance through a firewall, you must configure the firewall on the computer that is
running SQL Server to allow access. Any ports that you manually assign must be open in Windows Firewall.
To configure Windows Firewall to open manually assigned ports
2. In Control Panel, open System and Security.
3. Click Windows Firewall, and then click Advanced Settings to open the Windows Firewall with
Advanced Security dialog box.
4. In the navigation pane, click Inbound Rules to display the available options in the Actions pane.
5. Click New Rule to open the New Inbound Rule Wizard.
6. Use the wizard to complete the steps that are required to allow access to the port that you defined in
Configuring 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.
Configuring SQL Server client aliases

If you block UDP port 1434 or TCP port 1433 on the computer that is 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.
To configure a SQL Server client alias
2. Run Setup for SQL Server on the target computer, and install the following client components:
Connectivity Components
Management Tools
3. Open SQL Server Configuration Manager.
4. In the navigation pane, click SQL Native Client Configuration.
5. In the main window under Items, right-click Aliases, and select New Alias.
6. In the Alias - New dialog box, in the Alias Name field, enter a name for the alias. For example, enter
SharePoint _alias.
7. In the Port No field, enter the port number for the database instance. For example, enter 40000. Make
sure that the protocol is set to TCP/IP.
8. In the Server field, enter the name of the computer that is running SQL Server.
9. Click Apply, and then click OK.
10. Verification: You can test the SQL Server client alias by using SQL Server Management Studio, which is
available when you install SQL Server client components.
11. Open SQL Server Management Studio.
12. 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 ServerManagement Studio is populated with objects
that correspond to the remote database.
13. To check connectivity to additional database instances from SQL ServerManagement Studio, click
Connect, and then click Database Engine.
See also
Other Resources
SQL Server Security Blog
SQL Vulnerability Assessment
Securing SharePoint: Harden SQL Server in SharePoint Environments
Configure a Windows Firewall for Database Engine Access
Configure a Server to Listen on a Specific TCP Port (SQL Server Configuration Manager)
Federal Information Processing Standard security
standards and SharePoint Server

SharePoint Server 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 Server uses MD5 to create hash values that are used as unique identifiers.
Because SharePoint Server 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
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
FIPS Publications
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 Server.
The FIPS contribution to FISMA certification is the strength of encryption used for security purposes. Security-
related encryption within SharePoint Server is performed by using FIPS -compliant cipher suites.
For additional information about FISMA see,Federal Information Security Management Act (FISMA)
Implementation Project
Install SharePoint Server

The following articles include information about how to prepare for installation, step-by-step installation
instructions, post-installation configuration steps, and upgrade information. Two sections are listed, one for
SharePoint Servers 2016 and 2019 which describes MinRole and its configuration, and the other is SharePoint
Server 2013.
Articles about SharePoint Servers 2016 and 2019 installation and

configuration
CONTENT DESCRIPTION
Install SharePoint Server 2016 Learn how to install SharePoint Server 2016 in various
topologies.
Install SharePoint Server 2019 Learn how to install SharePoint Server 2019 in various
topologies.
Prerequisites for SharePoint Server Learn about permissions, accounts, security settings, and
what you have to do to prepare your environment for
SharePoint Servers 2016 and 2019.
Configure SharePoint Server Learn how to configure settings like services, authentication,
and specific features after you install SharePoint Server.
Install and manage apps for SharePoint Server Learn about apps for SharePoint, the SharePoint Store, and
the App Catalog and how to install, manage, and monitor
apps in your SharePoint Server 2016 environment.
Upgrade to SharePoint Server 2016 Learn how to plan, prepare, and perform an upgrade to
Upgrade to SharePoint Server 2019 Learn how to plan, prepare, and perform an upgrade to
Deploy software updates for SharePoint Server 2016 Learn how to prepare for, download, install, and configure
software updates and patches for SharePoint Server 2016.
Test and troubleshoot an upgrade to SharePoint Server 2016 Learn how to test and troubleshoot an upgrade from
SharePoint Server 2013 with Service Pack 1 (SP1) to
Configure SQL Server security for SharePoint Server Learn how to improve the security of SQL Server for
SharePoint Server 2016 environments.
SharePoint Server 2016 in Microsoft Azure Learn about why Microsoft Azure is the best place to host
your SharePoint Server 2016 farms in the cloud.
CONTENT DESCRIPTION
Microsoft Identity Manager in SharePoint Servers 2016 and Learn about the Microsoft Identity Manager (MIM) in
2019 SharePoint Servers 2016 and 2019 and the features it
provides to you as an external identity manager.
Articles about SharePoint Server 2013 installation and configuration

CONTENT DESCRIPTION
Install for SharePoint 2013 Learn how to install SharePoint Server 2013 in various
topologies.
Prerequisites for SharePoint Server Learn about permissions, accounts, security settings, and
what you have to do to prepare your environment for
Configure SharePoint Server Learn how to configure settings like services, authentication,
and specific features after you install SharePoint Server 2013.
Install and manage apps for SharePoint Server Learn about apps for SharePoint, the SharePoint Store, and
the App Catalog and how to install, manage, and monitor
apps in your SharePoint Server 2013 environment.
Upgrade from SharePoint 2010 to SharePoint 2013 Learn how to plan, prepare, and perform an upgrade to
Upgrade from SharePoint 2013 to SharePoint Server 2019 Learn the high level steps to perform an upgrade to
Deploy software updates for SharePoint 2013 Learn how to prepare for, download, install, and configure
software updates and patches for SharePoint Server 2013.
Test and troubleshoot an upgrade to SharePoint 2013 Learn how to test and troubleshoot an upgrade from
SharePoint Server 2010 to SharePoint Server 2013.
Configure SQL Server security for SharePoint Server Learn how to improve the security of SQL Server for
SharePoint Server 2013 environments.
SharePoint 2013 dev/test environments in Azure Learn about why Microsoft Azure is the best place to host
your SharePoint Server 2013 farms in the cloud.
See also
Other Resources
What is SharePoint
About SharePoint
Install SharePoint Server 2019

Testing and implementing SharePoint Server 2019 solutions at different stages of the deployment life cycle
requires deployments in various topologies.
The following articles provide information about how to deploy SharePoint Server 2019 on one or more servers
to create different topologies that you can use for testing and implementing SharePoint Server 2019 solutions at
different stages of the deployment life cycle.
CONTENT DESCRIPTION
Hardware and software system requirements Describes the system requirements to install SharePoint Server
2019.
Install SharePoint Server on one server Describes how to install SharePoint Server on a single server.
Install SharePoint Server across multiple servers Describes how to install SharePoint Server on multiple servers.
Install or uninstall language packs for SharePoint Server Describes language packs and how to download, install, and
uninstall them.
Add a server to a SharePoint Server farm Explains how to add a server to a farm.
Remove a server from a farm in SharePoint Server Describes how to remove a server from a SharePoint Server
farm.
Uninstall SharePoint Server Describes how to remove SharePoint Server from a computer.
System requirements for SharePoint Servers 2016 and
2019

Before you install SharePoint Server, you must make sure that you have installed all required hardware and
software. To effectively plan your deployment, you must understand the level of support that is 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 Servers 2016 and 2019. You must also understand the URL and path length restrictions in
The following articles help you prepare for the installation of SharePoint Server by providing information about the
prerequisites that you must have in order to run SharePoint Server.
CONTENT DESCRIPTION
Hardware and software requirements Describes the hardware and software

for SharePoint Server 2016 requirements that you must meet to
successfully install SharePoint Server
2016.

2019.
Plan browser support in SharePoint Describes levels of support for web

Servers 2016 and 2019 browsers to use with SharePoint Servers
2016 and 2019.
Hardware and software requirements for SharePoint
Server 2019
IMPORTANT
If you contact Microsoft Customer Support Services 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.
Hardware requirements: Location of physical servers

Some enterprises have datacenters that are in close proximity to one another and connected by high-bandwidth
fiber optic links. In this environment, you can configure the two datacenters as a single farm. This distributed
farm topology is called a stretched farm. Stretched farms for SharePoint Server 2019 are supported.
For a stretched farm architecture to work as a supported high-availability solution, the following prerequisites
must be met:
There is a highly consistent intra-farm latency of <1 ms one way, 99.9% of the time over a period of ten
minutes. (Intra-farm latency is commonly defined as the latency between the front-end web servers and
the database servers.)
The bandwidth speed must be at least 1 gigabit per second.
To provide fault tolerance in a stretched farm, use the standard best practice guidance to configure redundant
service applications and databases.
NOTE
The intra-farm latency of <1 ms one way, 99,9% of the time over a period of ten minutes is also required for SharePoint
environments with servers that are located in the same datacenter. The bandwidth speed should also be in this case at
least 1 gigabit per second.
Hardware requirements: SharePoint Servers and MinRole installations

The values in the following table are minimum values for installations on servers that are running SharePoint
Server 2019 in a multiple server farm installation.
For all installation scenarios, you must have sufficient hard disk space for the base installation and sufficient
space for diagnostics such as logging, debugging, creating memory dumps, and so on. For production use, you
must also have additional free disk space for day-to-day operations. In addition, maintain two times as much free
space as you have RAM for production environments.
For information about hardware and software requirements for Microsoft SQL Server 2016 or higher, see
Hardware and Software Requirements for Installing SQL Server.
INSTALLATION DEPLOYMENT TYPE
SCENARIO AND SCALE RAM PROCESSOR HARD DISK SPACE
Single server role Development or 16 GB 64-bit, 4 cores 80 GB for system

that uses SQL Server evaluation installation drive
of SharePoint Server 100 GB for second
2019 with the drive
minimum
recommended
services for
development
environments. Use
the Single-Server
farm role that will let
you choose which
service applications
to provision. For
additional
information on
Single-Server farm
role, see Overview of
MinRole Server Roles
Single server role Pilot or user 24 GB 64-bit, 4 cores 80 GB for system

that uses SQL Server acceptance test drive
installation of 100 GB for second
SharePoint Server drive and additional
2019 running all drives
available services for
development
environments.
Web server or Development or 12 GB 64-bit, 4 cores 80 GB for system

application server in evaluation installation drive
a three-tier farm of SharePoint Server 80 GB for second
2019 with a drive
minimum number of
services.
Web server or Pilot, user acceptance 16 GB 64-bit, 4 cores 80 GB for system

application server in test, or production drive
a three-tier farm deployment of 80 GB for second
available services.
Deployment requirements: Farm Topology

For information about how to plan for a server deployment, see Planning for a MinRole server deployment in
Software requirements for SharePoint Server 2019

The requirements in the following section apply to the following installations:
Server farm with a single server in the farm
Server farm with multiple servers in the farm
NOTE
SharePoint Server 2019 supports drives that are formatted with the Resilient File System (ReFS). For additional information
about ReFs, see Resilient File System Overview and Resilient File System
IMPORTANT
SharePoint Server 2019 requires a minimum of an Active Directory 2003 native forest and domain functional level.
IMPORTANT
SharePoint Server 2019 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 can assist you in the installation of the software
prerequisites for SharePoint Server 2019. Ensure that you have an Internet connection because some
prerequisites are installed from the Internet.
Minimum software requirements for SharePoint Server 2019
This section provides minimum software requirements for each server in the farm.
Minimum requirements for a database server in a farm
One of the following:
Microsoft SQL Server 2016 RTM Standard or Enterprise Editions
Microsoft SQL Server 2017 RTM Standard or Enterprise Editions for Windows
Microsoft Azure SQL Managed Instance (MI) - For more information, see Deploy Azure SQL Managed
Instance with SharePoint Servers 2016 and 2019.
NOTE
SQL Server products and all future public updates are supported through the SQL Server product lifecycle.
NOTE
SQL Server Express is not supported. Azure SQL Database (the DBaaS service) is also not supported for any SharePoint
databases
One of the following server operating systems:

Windows Server 2016 Standard or Datacenter
Minimum requirements for SharePoint servers in a farm
Windows Server 2016 Standard or Datacenter (Desktop Experience)
Windows Server 2019 Standard or Datacenter (Desktop Experience)
NOTE
We don't support installing or upgrading SharePoint 2019 RTM on a server that previously hosted a prerelease version of
SharePoint. A new server build is required to host SharePoint 2019 RTM.
NOTE
We don't support installing the Office 2019 client and SharePoint Server 2019 on the same computer.
NOTE
The minimum supported version is Office 2010 client.
IMPORTANT
The Microsoft SharePoint Products Preparation Tool might not be able to install Microsoft .NET Framework version 3.5
automatically. In this case you need to manually install the .NET Framework 3.5 Feature Windows Feature as a
prerequisite using the Windows Server install media.
The Microsoft SharePoint Products Preparation Tool installs the following prerequisites on SharePoint servers in
a farm:
Web Server (IIS ) role
Windows Process Activation Service feature
Microsoft .NET Framework version 3.5
Microsoft .NET Framework version 4.7.2
Microsoft SQL Server 2012 Service Pack 4 Native Client
Microsoft WCF Data Services 5.6
Microsoft Identity Extensions
Microsoft Information Protection and Control Client 2.1 (MSIPC )
Microsoft Sync Framework Runtime v1.0 SP1 (x64)
Windows Server AppFabric 1.1
Cumulative Update Package 7 for Microsoft AppFabric 1.1 for Windows Server (KB 3092423)
Visual C++ Redistributable Package for Visual Studio 2012
NOTE
The required software above will be supported when used by SharePoint via the SharePoint Product Lifecycle.
Minimum requirements for client computers

A supported browser. For more information, see Plan browser support in SharePoint Server 2019.
Manually configure Windows Server Roles and Features
To manually configure the required Windows Server Roles and Features, you can use one of two methods: 1.
Server Manager 2. Microsoft PowerShell
To configure by using Server Manager, see Install or Uninstall Roles, Role Services, or Features
To configure by using PowerShell:
From a PowerShell command prompt window, type:
Install-WindowsFeature NET-HTTP-Activation,NET-Non-HTTP-Activ,NET-WCF-Pipe-Activation45,NET-WCF-HTTP-
Activation45,Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-Default-Doc,Web-Dir-
Browsing,Web-Http-Errors,Web-App-Dev,Web-Asp-Net,Web-Asp-Net45,Web-Net-Ext,Web-Net-Ext45,Web-ISAPI-Ext,Web-
ISAPI-Filter,Web-Health,Web-Http-Logging,Web-Log-Libraries,Web-Request-Monitor,Web-Http-Tracing,Web-
Security,Web-Basic-Auth,Web-Windows-Auth,Web-Filtering,Web-Performance,Web-Stat-Compression,Web-Dyn-
Compression,Web-Mgmt-Tools,Web-Mgmt-Console,WAS,WAS-Process-Model,WAS-NET-Environment,WAS-Config-
APIs,Windows-Identity-Foundation,Xps-Viewer -IncludeManagementTools -Verbose
NOTE
Some Windows features being installed are “Features On Demand (FOD)”, which are downloaded from Windows Update. If
the computer doesn’t have access to Windows Update, you can specify local installation files by adding the Source
parameter and pointing to the \sources\sxs folder on the Windows Server installation media.
For example: -Source D:\sources\sxs
Optional software supported in SharePoint Server 2019

The optional software in this section is supported but is not required to install or use SharePoint Server 2019.
This software might be required by capabilities such as business intelligence.
ENVIRONMENT OPTIONAL SOFTWARE
Single server farm, front-end web servers, and application .NET Framework Data Provider for SQL Server (part of
servers in a farm Microsoft .NET Framework)
.NET Framework Data Provider for OLE DB (part of Microsoft
.NET Framework)
SharePoint Workflow Manager
You can install SharePoint Workflow Manager on a dedicated
computer.
Microsoft SQL Server 2008 R2 Reporting Services Add-in for
Microsoft SharePoint Technologies
This add-in is used by Access Services for SharePoint Server
2019.
Microsoft SQL Server 2012 Data-Tier Application (DAC)
Framework 64-bit edition
Microsoft SQL Server 2012 Transact-SQL ScriptDom 64-bit
edition
Microsoft System CLR Types for Microsoft SQL Server 2012
64-bit edition
Microsoft SQL Server 2012 with SP1 LocalDB 64-bit edition
Microsoft Data Services for the .NET Framework 4 and
Silverlight 4 (formerly ADO.NET Data Services)
Exchange Web Services Managed API, version 1.2
Links to applicable software

To install Windows Server 2016 or higher, SQL Server 2016 or higher, or SharePoint Server 2019, you can go to
the websites that are listed in this section. You can install most software prerequisites through the SharePoint
Server 2019 Start page. The software prerequisites are also available from websites that are listed in this section.
You can enable the Web Server (IIS ) role in Server Manager.
In scenarios where installing prerequisites directly from the Internet is not possible, you can download the
prerequisites and then install them from a network share. For more information, see Install prerequisites for
SharePoint Server from a network share.
Language Packs for SharePoint Server 2019
Windows Server 2016
Windows Server 2019
Microsoft SQL Server 2016
Microsoft SQL Server 2017 RTM
Microsoft .NET Framework version 4.7.2
Microsoft Information Protection and Control Client (MSIPC )
Microsoft SQL Server 2012 SP4 Feature Pack - Native Client \x64\sqlncli.msi
Cumulative Update Package 7 for AppFabric 1.1 for Windows Server
Prerequisite installer operations and command-line options

The SharePoint Server 2019 prerequisite installer (prerequisiteinstaller.exe) installs the following software, if it
has not already been installed on the target server, in the following order:
1. Web Server (IIS ) Role
2. Microsoft SQL Server 2012 SP4 Native Client
3. Microsoft Sync Framework Runtime v1.0 SP1 (x64)
4. Windows Server AppFabric 1.1
5. Microsoft Identity Extensions
6. Microsoft Information Protection and Control Client 2.1
7. Microsoft WCF Data Services 5.6
8. Microsoft .NET Framework 4.7.2
9. Cumulative Update Package 7 for Microsoft AppFabric 1.1 for Windows Server (KB 3092423)
10. Visual C++ Redistributable Package for Visual Studio 2012
You can run prerequisiteinstaller.exe at a command prompt with the following options. When you run
prerequisiteinstaller.exe at a command prompt, you might be asked to restart the server one or more times
during the installation process. After restarting, you should continue the prerequisite installation by running
prerequisiteinstaller.exe with the /continue option.
/? This displays command-line options.
/continue This is used to tell the installer that it is continuing from being restarted.
/unattended This indicates no user interaction.
The installer installs from the file that you specify in the command-line options described in the following list. In
this list, < file> signifies the file from which you want to install. If you do not specify the < file> option, the
installer downloads the file from the Internet and installs it. If the option does not apply to the current operating
system, it is ignored.
/SQLNCli:<file> Install Microsoft SQL Server 2012 SP4 Native Client from <file>.
/Sync:<file> Install Microsoft Sync Framework Runtime SP1 v1.0 (x64) from <file>.
/AppFabric:<file> Install Windows Server AppFabric from <file> (AppFabric must be installed with the
options /i CacheClient,CachingService,CacheAdmin /gac).
/IDFX11:<file> Install Microsoft Identity Extensions from <file>.
/MSIPCClient:<file> Install Microsoft Information Protection and Control Client from <file>.
/KB3092423:<file> Install Cumulative Update Package 7 for Microsoft AppFabric 1.1 for Windows
Server (KB3092423) from <file>.
/WCFDataServices56:<file> Install Microsoft WCF Data Services 5.6 from <file>.
/DotNet472:<file> Install Microsoft .NET Framework 4.7.2 from <file>.
/MSVCRT11:<file> Install Visual C++ Redistributable Package for Visual Studio 2012 from <file>.
/MSVCRT141:<file> Install Visual C++ Redistributable Package for Visual Studio 2017 from <file>.
Installation options
Certain prerequisites are installed by the prerequisite installer with specific options. Those prerequisites with
specific installation options are listed below with the options that are used by the prerequisite installer.
Windows AppFabric
/i CacheClient,CachingService,CacheAdmin /gac
Microsoft WCF Data Services
/quiet
The prerequisite installer creates log files at %TEMP%\prerequisiteinstaller.<date>.<time>.log. You can check
these log files for specific details about all changes the installer makes to the target computer.
Plan browser support in SharePoint Servers 2016 and
2019
SharePoint Servers 2016 and 2019 supports several commonly used web browsers, such as Internet Explorer,
Google Chrome, Mozilla Firefox, Apple Safari, and Microsoft Edge. However, certain web browsers can
cause some SharePoint Servers 2016 or 2019 functionality to be downgraded, limited, or available only through
alternative steps.
As you plan your deployment of SharePoint Servers 2016 or 2019, we recommend that you review the browsers
used in your organization to guarantee optimal performance with SharePoint Servers 2016 and 2019.
Key planning phase of browser support

Browser support is an important part of your SharePoint Servers 2016 or 2019 implementation. Before you install
SharePoint Server 2016, make sure that you know the browsers that SharePoint Server 2016 supports. The
information in this article describes browser support in the following sections:
Browser support levels
Browser details
Browser support levels in SharePoint Server 2016
The following table summarizes the support levels of typically used web browsers.
BROWSER SUPPORTED NOT SUPPORTED
Microsoft Edge X
Internet Explorer 11 X
Google Chrome (latest released version) X
Mozilla Firefox (latest released version X

plus immediate previous version)
Apple Safari (latest released version) X

Microsoft Edge X
Google Chrome (latest X

released version)
Mozilla Firefox (latest X

released version plus
immediate previous version)
Apple Safari (latest released X

version)
Browser details
Review the details of the web browser that you have or plan to use in your organization to make sure that the web
browser works with SharePoint Server 2016 and according to your business needs.
Internet Explorer and older functionality
NOTE
Some older SharePoint functionality that relies on NPAPI or ActiveX will not work on browsers other than Internet Explorer.
You can work around each of these issues by using Internet Explorer to perform these tasks.
Using ActiveX controls in SharePoint Server
Some functionality in SharePoint Server requires ActiveX controls. This produces limitations on browsers which do
not support ActiveX. Currently only 32-bit versions of Internet Explorer support this functionality. In SharePoint
Server 2016, all other supported browsers, including Microsoft Edge and the Immersive mode of Internet Explorer
10 have the following limitations.
For SharePoint Server 2016 and 2019, browsers other than Internet Explorer 11 have the following limitations.
Plugin name DLL file name What it does Known limitations

Digital Signature Dsigctrl.dll, dsigres.dll Digital signing takes An inability to verify a
place in both the form produces an
InfoPath client and on error that states that
the InfoPath Forms the form cannot be
Services server. Make signed.
sure that the
following conditions
exist:
Forms that are signed
on the client can be
verified on the server.
on the server can be
verified on the client.
NameCtrl Name.dll Enables a webpage to

display a contact card
and presence status
for people. Integrates
through client-side
APIs with Office client
and Skype for
Business client.
TaskLauncher Nameext.dll Used to export items If software

in a task list to Project requirements are not
Server if Project client met, an error message
is installed on the states that you need
client computer. to install Project client.
SpreadSheetLauncher Owssupp.dll Used to verify If Excel is not installed,

whether Excel is the user may be
installed for Export to prompted to
Excel feature. download the file
"query.iqy" which can
then be opened in
Excel.
StssyncHandler Owssupp.dll Enables

synchronization of
lists of events and lists
of contacts in
SharePoint with a
messaging application
such as Outlook.
Non-IE clients may
have an additional
prompt to open the
calendar in Outlook.
ExportDatabase Owssupp.dll Enables a user to use To export a list, the

an application such as client computer must
Access to create or have a SharePoint
open a database that compatible
contains SharePoint application.
list data.
OpenDocuments Owssupp.dll Starts Office client If a compatible Office
applications so that a application or browser
user can create a or is not installed on a
edit a document. client, an error
Enables users to message states that
create documents the feature requires a
that are based on a SharePoint compatible
specified template, application and web
open documents as browser.
read-only, or open
documents as
read/write.
CopyCtl Stsupld.dll Enables a user to copy In Firefox, Google

a document on a Chrome, and
SharePoint site to one immersive mode of
or more locations on Internet Explorer
a server. version 10, the copy
progress dialog box is
not displayed.
PPActiveX PPSLAX.dll Starts PowerPoint to Does not work on

open presentations Click-to-Run
from a slide library or installations of Office
publish individual and version of Office
slides to a slide library. that run on Windows
for ARM.
BCSLauncher BCSLaunch.dll Starts the Visual

Studio Tools for Office
installer to install a
Visual Studio Tools for
Office package that
has been generated
on the server.
Other functionality, such as Form settings in List settings only function with Internet Explorer.
Mobile browser support

SharePoint Server 2016 supports the following versions:
Internet Explorer and Microsoft Edge on Windows Phone 8.1 or later.
Latest version of Chrome on Android 4.4 or later.
Latest versions of Safari and Chrome on iOS 8 or later.
For SharePoint Server 2019, Chrome or Safari on iOS10 or later

You can install and configure SharePoint Servers 2016 or 2019 on a single server if you are hosting only a few sites
for a limited number of users or if you want to create a trial or development environment. 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
In previous versions of SharePoint, a single server installation automatically installed SQL Server Express. In SharePoint Servers
2016 and 2019, a single server installation contains only SharePoint. SQL Server can be installed on the same server or on a
separate server; both scenarios are supported. For better performance we recommend installing SQL Server on a separate
server.
Overview
After you have completed setup and the SharePoint Products Configuration Wizard, you will have installed
binaries, configured security permissions, configured registry settings, configured the configuration database,
configured 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.
Before you install SharePoint Servers 2016 or 2019 on a single server

Before you begin to install and configure SharePoint Servers 2016 or 2019, do the following:
For SharePoint Server 2016, ensure that you have met all hardware and software requirements. You must
have a 64-bit version of Windows Server 2012 R2. To host SharePoint databases, you must also have a 64-
bit version of SQL Server 2014 SP1. For more information about these requirements, such as specific
updates that you must install, see Hardware and software requirements for SharePoint Server 2016.
have a 64-bit version of Windows Server 2016. To host SharePoint databases, you must also have a 64-bit
version of SQL Server 2016 or 2017. For more information about these requirements, such as specific
Ensure that you perform a clean installation of SharePoint Servers 2016 or 2019.
Ensure that you are prepared to set up the required accounts by using appropriate permissions. For detailed
information, see Initial deployment administrative and service accounts in SharePoint Server.
Ensure the Max degree of parallelism is set to 1. For additional information about max degree of parallelism
see, Configure the max degree of parallelism Server Configuration Option.
Security note: As a security best practice, we recommend that you install SharePoint Servers 2016 or 2019 by
using least-privilege administration.
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.
Install SharePoint Servers 2016 or 2019 on a single server

To install and configure SharePoint Server 2016 or 2019 on a single server, you will follow these steps:
1. Run the Microsoft SharePoint Products and Technologies Preparation Tool, which installs all
prerequisites to use SharePoint Server.
2. Run Setup, which installs binaries, configures security permissions, and edits registry settings for SharePoint
Servers 2016 or 2019.
3. Run SharePoint Products Configuration Wizard, which installs and configures the configuration database,
installs and configures 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, the account that you use must be a member of the Administrators group on the
computer on which you are installing SharePoint Server. For information about user accounts, see Initial deployment
administrative and service accounts in SharePoint Server.
Run the Microsoft SharePoint Products Preparation Tool

Because the prerequisite installer downloads components from the Microsoft Download Center, you must have
Internet access on the computer on which you are running the installer. Use the following procedure to install
software prerequisites for SharePoint Servers 2016 or 2019.
To run the Microsoft SharePoint Products Preparation Tool
1. Verify that the user account that is performing this procedure is the Setup user account. For information
about the Setup user account, see Initial deployment administrative and service accounts in SharePoint
Server.
2. In the SharePoint Server installation disc image software, mount the ISO file, and click the splash.hta file.
The SharePoint Server splash screen is displayed.
3. Click Install software prerequisites.
4. On the Welcome to the SharePoint Products Preparation Tool page, click Next.
5. On the License Terms for software products page, review the terms, select the I accept the terms of the
License Agreement(s) check box, and then click Next.
6. On the Your system needs to restart to continue page, click Finish to restart the computer.
7. Repeat steps 2-4.
8. On the Installation Complete page, click Finish.
Run Setup
The following procedure installs binaries, configures security permissions, and edits registry settings for SharePoint
Server. 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
Server.
2. On the SharePoint Server Start page, click Install SharePoint Server.
3. On the Enter Your Product Key page, enter your product key, and then click Continue.
4. 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.
5. Optional: To install SharePoint Server at a custom location, or to store search index files at a custom location,
click the File Location tab, and then either type the custom location or click Browse to find the custom
location.
NOTE
If you intend to use this computer as a search server, we recommend that you store the search index files on a
separate storage volume or partition. Any other search data that needs to be stored is stored in the same location as
the search index files. You can only set this location at installation time.
6. Click Install Now.

7. 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.
8. Click Close to start the configuration wizard.
NOTE
If Setup fails, check log files in the Temp folder of the user account you used to run Setup. Ensure that you are logged in using
the same user account and then type %temp% in the location bar in Windows Explorer. If the path in Windows Explorer
resolves to a location that ends in a "1" or "2", you have to navigate up one level to view the log files. The log file name is
SharePoint Server Setup (< time stamp>).
Run the SharePoint Products Configuration Wizard

Use the following procedure to install and configure the configuration database and the content database, and to
install the SharePoint Central Administration website.
To run the SharePoint Products Configuration Wizard
Server.
2. If you have closed the SharePoint Products Configuration Wizard, you can access it by clicking Start, point
to All Apps, click Microsoft SharePoint Products, and then click SharePoint Products Configuration
Wizard. If the User Account Control dialog box appears, click Continue.
3. On the Welcome to SharePoint Products page, click Next.
4. In the dialog box that notifies you that some services might have 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:
7. In the Database server box, type the name of the computer that is running SQL Server.
8. In the Database name box, type a name for your configuration database or use the default database name.
The default name is SharePoint_Config.
9. 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.
Security note: The server farm account is used to 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 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 server
farm account has to be a domain user account. However, it does not have to be a member of any specific
security group on your SharePoint 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 SharePoint servers or your database servers.
10. In the Password box, type the user password.
11. Click Next.
12. On the Specify Farm Security Settings page, type a passphrase, and then click Next.
Although a passphrase resembles a password, it is usually longer to improve security. It is used to encrypt
credentials of accounts that are registered in SharePoint Server. For example, the SharePoint Server server
farm account that you provide when you run the SharePoint Products Configuration Wizard. Ensure that
you remember the passphrase, because you must use it every time that you add a server to the farm.
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 !, $, #, %)
9. On the Specify Server Role page, choose the appropriate role, click Next.
NOTE
For a single server farm, we recommend choosing the Single Server Farm role, although you can select a Custom
role if you want to individually manage the services instances that run on the server. You can change the role of a
server later if you change your mind or want to expand your farm by adding additional servers.
10. On the Configure SharePoint Central Administration Web Application page, do the following:
Either select the Specify port number check box and type the port number that 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.
Click either NTLM or Negotiate (Kerberos).
11. Click Next.
12. On the Completing the SharePoint Products Configuration Wizard page, review your configuration
settings to verify that they are correct, and then click Next.
NOTE
The Advanced Settings option is not available in SharePoint Servers 2016 and 2019.
13. On the Configuration Successful page, click Finish. When the wizard closes, setup opens the web browser
and connects to Central Administration.
If the SharePoint Products Configuration Wizard fails, check the PSCDiagnostics log files, which are located
on the drive on which SharePoint Servers 2016 and 2019 are installed, in the
%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\16\LOGS folder.
If you are prompted for your user name and password, you might have 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. If you see a proxy
server error message, you might have to configure proxy server settings so that local addresses bypass the
proxy server. Instructions for configuring proxy server settings are provided in the following section. For
more information about how to configure browser and proxy settings, see Configure browser settings.
Configure browser settings
After you run the SharePoint Products Configuration Wizard, you should confirm that SharePoint Server works
correctly by configuring additional settings in Internet Explorer.
If you are not using Internet Explorer, you might have to configure additional settings for your browser. For
information about supported browsers, see Plan browser support in SharePoint Servers 2016 and 2019.
To confirm that you have configured browser settings correctly, log on to the server by using an account that has
local administrative credentials. Next, connect to the SharePoint Central Administration web site. If you are
prompted for your user name and password when you connect, perform the following procedures:
Add the SharePoint Central Administration website 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
To add the SharePoint Central Administration website to the list of trusted sites
1. Verify that the user account that completes this procedure has the following credentials:
The user account is a member of the Administrators group on the computer on which you are performing the
procedure.
2. In Internet Explorer, on the Tools menu, click Internet Options.
3. On the Security tab, in the Select a zone to view or change security settings area, click Trusted Sites,
and then click Sites.
4. Clear the Require server verification (https:) for all sites in this zone check box.
5. In the Add this web site to the zone box, type the URL to your site, and then click Add.
6. Click Close to close the Trusted Sites dialog box.
7. Click OK to close the Internet Options dialog box.
To disable Internet Explorer Enhanced Security settings
procedure.
2. Click Start, point to All Apps, point to Administrative Tools, and then click Server Manager.
3. In Server Manager, select the root of Server Manager.
4. In the Security Information section, click Configure IE ESC.
The Internet Explorer Enhanced Security Configuration dialog box appears.
5. 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
procedure.
3. On the Connections tab, in the Local Area Network (LAN ) settings area, click LAN Settings.
4. In the Automatic configuration area, clear the Automatically detect settings check box.
5. In the Proxy Server area, click the Use a proxy server for your LAN check box.
6. Type the address of the proxy server in the Address box.
7. Type the port number of the proxy server in the Port box.
8. Select the Bypass proxy server for local addresses check box.
9. Click OK to close the Local Area Network (LAN ) Settings dialog box.
Run the Farm Configuration Wizard
You have now completed setup and the initial configuration of SharePoint Server. You have created the SharePoint
Central Administration web site. You can now configure your farm and sites, and you can select services by using
the Farm Configuration Wizard.
To run the Farm Configuration Wizard
Server.
2. On the SharePoint Central Administration home page, on the Quick Launch, click Configuration Wizards,
and then click Launch the Farm Configuration Wizard.
3. 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.
4. On the Configure your SharePoint farm page, next to Yes, walk me through the configuration of my
farm using this wizard, click Start the Wizard.
5. On the Service Applications and Services page, in the Service Account section, click the service account
option that you want to use to configure your services.
Security 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 of which SharePoint Server 2016 is
aware — make sure that you click that option before you continue.
6. In the Services section, review the services that you want to use in the farm, and then click Next.
7. On the Create Site Collection page, do the following:
8. In the Title and Description section, in the Title box, type the name of your new site.
9. Optional: In the Description box, type a description of what the site contains.
10. In the Web Site Address section, select a URL path for the site.
11. 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.
12. Click OK.

13. 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 Server, 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.
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.
Configure diagnostic logging You can configure diagnostic logging that might be required after initial
installation or upgrade. The default settings are sufficient for most situations. Depending upon the business
needs and life-cycle of the farm, you might want to change these settings.
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 occur, 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 administration.
Configure outgoing email You can configure outgoing email so that your Simple Mail Transfer Protocol
(SMTP ) server sends email alerts to site users and notifications to site administrators. You can configure
both the "From" email address and the "Reply" email address that appear in outgoing alerts.
Configure Search settings You can configure Search settings to crawl the content in SharePoint Server.
Install SharePoint Servers 2016 or 2019 across multiple
servers

The deployment sequence and configurations that are described in this article are based on recommended best
practices. While the farm configuration is not complex, it provides a fundamental infrastructure to implement a
SharePoint Server solution on similar — or more complex farms.
Overview
The basic steps in this deployment are as follows:
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 Server prerequisites on SharePoint servers.
Install SharePoint Server on the SharePoint servers.
Create and configure the SharePoint farm.
Provision services.
Complete post-deployment tasks as required.
Topology overview
SharePoint Servers 2016 and 2019 support a new farm topology design called MinRole. This article will describe a
simple multi-server farm topology with one server assigned to each MinRole server role. However, to take
advantage of zero downtime patching, your farm topology must support high availability (HA) by having multiple
servers assigned to each MinRole server role.
For additional information about MinRole, see Overview of MinRole Server Roles in SharePoint Servers 2016 and
2019.
Before you install SharePoint Server on multiple servers
Ensure that you are familiar with the operating-system guidelines described in Performance Tuning
Guidelines for Windows Server 2012 R2.
Ensure that you have met all hardware and software requirements. For more information about these
requirements, such as specific updates that you must install, see Hardware and software requirements for
SharePoint Server 2016. For SharePoint Server 2019, see Hardware and software requirements for
Ensure that you perform a clean installation of SharePoint Server.
Ensure that you are prepared to set up the required accounts by using appropriate permissions. For detailed
Using the Microsoft SharePoint Products Preparation Tool
The Microsoft SharePoint Products Preparation Tool checks for the presence of prerequisites, and installs and
configures all required programs. The Microsoft SharePoint Products Preparation Tool requires an Internet
connection to download and configure SharePoint Server prerequisites.
Database server
Ensure that SQL Server is updated to the required level and the TCP/IP protocol is enabled for the network
configuration.
Organizations whose database administrators operate independently from SharePoint administrators will have to
make sure 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.
For additional information about DBA databases, see Database types and descriptions in SharePoint Server,
Storage and SQL Server capacity planning and configuration (SharePoint Server).
Ensure the Max degree of parallelism is set to 1. For additional information about max degree of parallelism see,
Configure the max degree of parallelism Server Configuration Option.
Public updates and hotfix packages
Ensure that public updates and the required hotfix packages are installed for the operating system, SQL Server, and
SharePoint Server.
Prepare the farm servers

Before you install SharePoint Server, you must check for and install all the prerequisites on the SharePoint servers
by using the Microsoft SharePoint Products Preparation Tool.
TIP
Use the following procedure to install prerequisites on each server in the farm.
Server.
2. In the SharePoint Server installation disc image, mount the ISO file, and then click the splash.hta file. The
SharePoint Server 2016 splash screen is displayed..
4. On the Welcome to the SharePoint 2016 Products Preparation Tool page, click Next.
NOTE
The preparation tool may have to restart the local server to complete the installation of some prerequisites. The
installer will continue to run after the server is restarted without manual intervention. However, you will have to log
on to the server again.
5. On the License Terms for software products page, review the terms, select the I accept the terms of the
License Agreement(s) check box, and then click Next.
6. If you see the Your system needs to restart to continue page, click Finish to restart the computer, and
then repeat steps 2-4.
Install SharePoint Server 2016 on the farm servers

After the prerequisites are installed, follow these steps to install SharePoint Server 2016 on each farm server.
The following procedure installs binaries, configures security permissions, and edits registry settings for SharePoint
Server 2016. At the end of Setup, you can choose to start the SharePoint Products Configuration Wizard, which is
described later in this article.
To run Setup
Server.
5. Optional: To install SharePoint Server at a custom location, or to store search index files at a custom location,
click the File Location tab, and then either type the custom location or click Browse to find the custom
location.
NOTE
As a best practice, we recommend that you install SharePoint Server on a non-system drive. > If you intend to use
this computer as a search server, we recommend that you store the search index files on a separate storage volume or
partition. Any other search data that needs to be stored, is stored in the same location as the search index files. You
can only set this location at installation time.

7. When the Setup program is finished, 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 you have installed
SharePoint Server 2016 on all SharePoint servers that will participate in the server farm.
8. Click Close to finish Setup.
Create and configure the farm

To configure the farm, you run the SharePoint Products Configuration Wizard. This wizard automates several
configuration tasks, such as creating the configuration database, installing services, and creating the Central
Administration website. We recommend that you run the SharePoint Products Configuration Wizard on the server
that will host the SharePoint Central Administration website before you run the wizard on the other servers in the
farm.
To run the SharePoint Products Configuration Wizard and configure the farm
Server.
2. On the server that will host Central Administration (the application server), click Start, point to All Apps,
and then click Microsoft SharePoint Products, and then click SharePoint Products Configuration
Yes.
8. In the Database name box, type a name for your configuration database, or use the default database name.
The default name is SharePoint_Config.
9. 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 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 SharePoint
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 server farm account has to be a domain user account. However, it does not have to be a
member of any specific security group on your SharePoint 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 SharePoint servers or your database servers.

11. Click Next.
credentials of accounts that are registered in SharePoint Servers 2016 or 2019. For example, the SharePoint
Server server farm account that you provide when you run the SharePoint Products Configuration Wizard.
Ensure that you remember the passphrase, because you must use it every time that you add a server to the
farm.
10. Either select the Specify port number check box and type the port number that you want the SharePoint
11. Click either NTLM or Negotiate (Kerberos).
12. Click Next.
13. On the Completing the SharePoint Products Configuration Wizard page, review configuration
settings, and then click Next.
14. 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 Server 2016
is installed, which are located in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\16\LOGS
folder.
15. The Central Administration website will open in a new browser window.
On the Help Make SharePoint Better page, click one of the following options and then click OK.
16. Yes, I am willing to participate (Recommended).
17. No, I don't wish to participate.
18. On the Initial Farm Configuration Wizard 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.
We recommend waiting until your SharePoint farm has at least one of each type of server role joined to it
before you run the Farm Configuration Wizard.
IMPORTANT
The Farm Configuration Wizard can't be used with DBA-created databases because the Farm Configuration Wizard will
try to create its own databases. If you're using DBA-created databases, you must create each service application and
web application manually so that you can specify the DBA-created database it should connect to.
Add SharePoint servers to the farm

After you create the farm on the first server, you can add servers by following the same process described earlier in
this topic for installing SharePoint Server on the server that hosts Central Administration. The only difference is
that during the SharePoint Products Configuration Wizard, you choose to join an existing farm. Follow the wizard
steps to join the farm.
For your content farm to be MinRole complaint, at a minimum you want to have at least one of each type of server
role in the farm: Application, Front-end, Distributed cache, and Search. The order in which these roles are
created does not matter. You can also combined roles by using shared roles. If you want to take full advantage of
zero down time patching, then you need to make sure high availability is configured.
For additional information about MinRole, see Overview of MinRole Server Roles in SharePoint Servers 2016 and
2019.
NOTE
If this farm is not hosting Search services, then the Search role is not needed.
For additional information about how to add servers to a farm, see Add a server to a SharePoint Server 2016 or
SharePoint Server 2019 farm. This article also provides detailed information for the steps in the following
procedure.
After you install and configure SharePoint Server, your browser window opens to the Central Administration web
needs and life-cycle of the farm, you might want to change these settings.
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
Configure Search settings You can configure Search settings to crawl the content in SharePoint Servers
2016 or 2019.
Install or uninstall language packs for SharePoint

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 Server. You install language packs,
which contain language-specific site templates, on each SharePoint server in your farm. 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 users in different locations, or when sites and web pages must be
duplicated in one or more languages.
Word breakers and stemmers enable you to search efficiently and effectively across content on SharePoint sites
and site collections in multiple languages without requiring separate installations of SharePoint Server. Word
breakers and stemmers are automatically installed on SharePoint servers by Setup.
IMPORTANT
If you are uninstalling SharePoint Server, you must uninstall all language packs before you uninstall SharePoint Server.
About language IDs and language packs

Site owners or site collection administrators who create sites or site collections 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 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 language packs that are installed on the SharePoint servers determine the list of available languages that you
can use to create a site or site collection. By default, sites and site collections are created in the language in which
SharePoint Server was installed. For example, if you install the Spanish version of SharePoint Server, 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 Server language, you must install the language pack for that
language on the SharePoint servers. For example, if you are running the French version of SharePoint Server, and a
site owner wants to create sites in French, English, and Spanish, you must install the English and Spanish language
packs on the SharePoint servers.
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 SharePoint server to
make sure that each SharePoint 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
always displays content in the language of the original site template. For example, SharePoint can render the same site in
multiple languages based on the preferred language of the user’s web browser. But for this to work, the SharePoint language
pack that matches the user’s preferred language must be installed on each server in the SharePoint farm.
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 Server
relies on several supporting technologies — for example, the Microsoft .NET Framework, Microsoft Windows
Workflow Foundation, Microsoft ASP.NET, and SQL Server — 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 are 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.
Each language pack that you install creates a folder at %COMMONPROGRAMFILES%\Microsoft Shared\Web
Server Extensions\16\TEMPLATE\LAYOUTS\Locale_ID that contains language-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 language, this file will be used. You can specify the file
to use by setting the FileNotFoundPage() for each web application.
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

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 Microsoft PowerShell Help files are installed in English (en-us). To view these files in the same language as the
operating system, install the language pack for the same language in which the operating system was installed.
You can download language packs from the Microsoft Download Center for SharePoint Server 2016 and
Installing language packs on the SharePoint servers

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 SharePoint server.
IMPORTANT
The language pack is installed in its native language. The procedure that follows is for the English language pack.
To install a language pack

Verify that the user account that is performing this procedure is the Setup user account. For information about the
Setup user account, see Initial deployment administrative and service accounts in SharePoint Server.
1. In the folder where you downloaded the language pack, run serverlanguagepack.exe.
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.
The SharePoint Products Configuration Wizard runs in the language of the base installation of SharePoint
Server, not in the language of the language pack that you just installed.
To rerun the SharePoint Products Configuration Wizard
1. Click Start, point to Microsoft SharePoint 2019 Products folder, click SharePoint Products
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. After you complete the Completing the SharePoint Products Configuration Wizard, click Next.
8. After you install a new language pack and rerun the SharePoint Products Configuration Wizard, you
must deactivate and then reactivate any language-specific features before you use the new language pack.
When you install language packs, the language-specific site templates are installed in the
%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\16\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\16\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.
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 again.
You cannot remove the language pack for the version of SharePoint Server that you have installed on the server.
For example, if you are running the Japanese version of SharePoint Server, you cannot uninstall the Japanese
language support for SharePoint Server.
List of Languages
Each folder name has a language tag appended to it, in the form ll-cc. That tag identifies the language and culture.
For example, U.S. English language folders are identified by the folder name extension en-us.
Folders for the language-specific components are identified by the language tag that is shown in the table. The
Windows operating system uses locale identifiers (LCIDs) to identify languages in the Windows registry.
SharePoint Servers 2016 and 2019 support the following languages:
LANGUAGE LANGUAGE TAG LCID
Arabic ar-sa 1025
Azerbaijani az-latn-az 1068
Basque eu-es 1069
Bosnian (Latin) bs-latn-ba 5146
Bulgarian bg-bg 1026
Catalan ca-es 1027
Chinese (Simplified) zh-cn 2052
Chinese (Traditional) zh-tw 1028
Croatian hr-hr 1050
Czech cs-cz 1029
Danish da-dk 1026
Dari prs-af 1164
Dutch nl-nl 1043
English en-us 1033
Estonian et-ee 1061
Finnish fi-fi 1035

French fr-fr 1036
Galician gl-es 1110
German de-de 1031
Greek el-el 1032
Hebrew he-il 1037
Hindi hi-in 1081
Hungarian hu-hu 1038
Indonesian id-id 1057
Irish ga-ie 2108
Italian it-it 1040
Japanese ja-jp 1041
Kazakh kk-kz 1087
Korean ko-kr 1042
Latvian lv-lv 1062
Lithuanian lt-lt 1063
Macedonian (FYROM) mk-mk 1071
Malay (Malaysia) ms-my 1086
Norwegian (Bokmål) nb-no 1044
Polish pl-pl 1045
Portuguese (Brazil) pt-br 1046
Portuguese (Portugal) pt-pt 2070
Romanian ro-ro 1048
Russian ru-ru 1049
Serbian (Cyrillic) sr-cyrl-rs 10266
Serbian (Latin) sr-latn-rs 9242

Slovak sk-sk 1051
Slovenian sl-si 1060
Spanish es-es 3082
Swedish sv-se 1053
Thai th-th 1054
Turkish tr-tr 1055
Ukrainian uk-ua 1058
Vietnamese vi-vn 1066
Welsh cy-gb 1106

Add a server to a SharePoint Servers 2016 or 2019
farm
Before you add a server to a SharePoint farm

Determine server role
To add a new server to the farm, you must know its intended role to plan for additional or specialized
configurations and assess the potential effect of adding the server to a production environment.
In SharePoint Server 2016, the concept of server roles has changed from previous versions. Server role types are
now defined by MinRole which allow for better deployment and health of the server in the farm. For additional
information about the MinRole feature and a description for each server role type, see Overview of MinRole Server
Roles in SharePoint Servers 2016 and 2019.
Additional tasks
Before you start to install prerequisite software, you have to complete the following:
Verify that the new server meets the hardware and software requirements described in Hardware and
software requirements for SharePoint Server 2016.
Verify that you have the minimum level of permissions that are required to install and configure SharePoint
Servers 2016 or 2019 on a new server. You must be a member of the Farm Administrators SharePoint group
and the Administrators group on the local server to complete the procedures in this article. For more
Verify that you know the name of the database server on the farm to which you are connecting, and the
name of the configuration database if you are adding the server by using Microsoft PowerShell commands.
If you intend to use PowerShell commands to add the server, verify that you meet the following minimum
memberships is installed.
An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint Server
cmdlets.
NOTE
If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For
additional information about PowerShell permissions, see Add-SPShellAdmin.
Document the location of the SharePoint Server 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.
IMPORTANT
If you change the location of the trace log to a non-system drive, change the location on all the servers in the farm. Existing
or new servers cannot log data if the location does not exist. In addition, you will be unable to add new servers unless the
path that you specify exists on the new server. You cannot use a network share for logging purposes.
Install prerequisite software

Before you can install SharePoint Server and add a server to the farm, you must check for and install all the
prerequisite software on the new server. You do this by using the Microsoft SharePoint Products Preparation Tool,
which requires an Internet connection to download and configure SharePoint Server prerequisites. If you do not
have an Internet connection for the farm servers, you can still use the tool to determine the software that is
required. You will have to obtain installable images for the required software.
For download locations, see Links to applicable software in "Hardware and software requirements (SharePoint
Server 2016)."
Server 2019)."
TIP
After you obtain a copy of the required software, we recommend that you create an installation point that you can use to
store the images. You can use this installation point to install future software updates.
For detailed instructions about how to install the prerequisites, see Prepare the farm servers in the article, Install
SharePoint Servers 2016 or 2019 across multiple servers.
TIP
Install the SharePoint software

After you install the prerequisites, follow these steps to install SharePoint Servers 2016 or 2019 on the new server.
For detailed instructions about how to install SharePoint Server, see Install SharePoint Server on one server.
To install SharePoint Server
Server.
2. From the product media or a file share that contains the SharePoint Server Products installation files, run
Setup.exe.
4. Review and accept the Microsoft License Terms.
5. Accept the default file location where SharePoint Server will be installed or change the installation path in
order to suit your requirements.
TIP
As a best practice, we recommend that you install SharePoint Server on a drive that does not contain the operating system.

7. When Setup finishes, a dialog box prompts you to run the SharePoint Products Configuration Wizard.
You can start the wizard immediately or from the Windows command prompt later.
Add the new SharePoint server to the farm

You add the new server to the farm by using one of the following procedures:
To add a server by using the SharePoint Products Configuration Wizard
To add a new SharePoint Server 2016 or SharePoint Server 2019 server to the farm by using the
PSConfig.exe command-line tool
To add a server by using Microsoft PowerShell
SharePoint Products Configuration Wizard
1. Start the SharePoint Products Configuration Wizard.
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 Specify Server Role page, choose the appropriate role, and then click Next.
NOTE
The concept of server roles has changed staring with SharePoint Server 2016. You can't add a server to a farm if the farm
currently contains a server assigned to the "Single Server Farm" role. > For additional information about MinRole, see
Overview of MinRole Server Roles in SharePoint Servers 2016 and 2019.
9. On the Completing the SharePoint Products Configuration Wizard page, click Next.
10. 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 Server is installed, in the %COMMONPROGRAMFILES%\Microsoft Shared\Web
Server Extensions\16\LOGS folder.
11. 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.
NOTE
This step should only apply if the Custom role is used.
To add a new SharePoint Server server to the farm by using the PSConfig.exe command-line tool
1. To create a farm by using the PSConfig.exe command-line tool, use the following syntax:
psconfig.exe -cmd configdb -connect -server <SqlServerName> -database <ConfigDbName> -user

<DOMAIN\FarmServiceAccount> -password <FarmServiceAccountPassword> -passphrase <FarmPassphrase> -
admincontentdatabase <AdminContentDbName> -localserverrole <ServerRole> -cmd helpcollections -installall -cmd
secureresources -cmd services -install -cmd installfeatures -cmd adminvs -provision -port <PortNumber> -
windowsauthprovider onlyusentlm -cmd applicationcontent -install
Where <ServerRole> can be any of the following values: WebFrontEnd, Application, DistributedCache, Search, or
Custom.
NOTE
The SingleServerFarm cannot be used unless the SharePoint farm has zero servers in it.
NOTE
If SharePoint Server 2016 Feature Pack 2 has been applied, additional <ServerRole> options are available:
ApplicationWithSearch, WebFrontEndWithDistributedCache. These options are also available in SharePoint Server 2019.
NOTE
The PSConfig.exe -cmd Services -Provision syntax is deprecated, but not removed yet. Do not use the Provision
parameter when you create or join a farm. Using this parameter will lead to failures.
To add a new SharePoint Server 2016 or SharePoint Server 2019 server to the farm by using PowerShell
Verify that you have the following memberships:
2016 cmdlets.
NOTE
additional information about PowerShell permissions, see [Add-SPShellAdmin](/powershell/module/sharepoint-server/Add-
SPShellAdmin?view=sharepoint-ps

2. At the PowerShell command prompt, type the following command to connect the server to a configuration
database:
Connect-SPConfigurationDatabase -DatabaseServer <SqlServerName> -DatabaseName <ConfigDbName> -Passphrase

<FarmPassphrase> -LocalServerRole <ServerRole>
Where:
<$DatabaseServer> is the name of the server that hosts the configuration database
<DatabaseName> is the name of the configuration database
<$Passphrase> is the passphrase for the farm
<ServerRole> is the server role type
Where \<ServerRole\> can be any of the following values: WebFrontEnd, Application, DistributedCache, Search, or
Custom.
NOTE
NOTE
The concept of server roles has changed starting with SharePoint Server 2016. You can't add a server to a farm if the farm
3. At the PowerShell command prompt, type the following command to install the Help File Collections:
Install-SPHelpCollection -All
4. At the PowerShell command prompt, type the following command to install the Security Resource for
SharePoint Server:
Initialize-SPResourceSecurity
5. At the PowerShell command prompt, type the following command to install the basic services:
Install-SPService
6. At the PowerShell command prompt, type the following command to install all the features:
Install-SPFeature -AllExistingFeatures
7. At the PowerShell command prompt, type the following command to set the port number of the SharePoint
Central Administration website:
New-SPCentralAdministration -Port <PortNumber> -WindowsAuthProvider NTLM
NOTE
If the SharePoint Central Administration website is already provisioned on an existing server in the farm, you can skip this
step.
8. At the PowerShell command prompt, type the following command to install application content:
Install-SPApplicationContent
9. At the PowerShell command prompt, type the following command to start the Timer service:
Start-Service SPTimerV4
10. At the PowerShell command prompt, type the following command to get a list of servers in the farm.
Get-SPServer
NOTE
located on the drive on which SharePoint Servers 2016 or 2019 is installed, in the %COMMONPROGRAMFILES%\Microsoft
Shared\Web Server Extensions\16\LOGS folder.
Install SharePoint Server 2016

Testing and implementing SharePoint Server 2016 solutions at different stages of the deployment life cycle
requires deployments in various topologies.
The following articles provide information about how to deploy SharePoint Server 2016 on one or more servers
to create different topologies that you can use for testing and implementing SharePoint Server 2016 solutions at
different stages of the deployment life cycle.
CONTENT DESCRIPTION
Install SharePoint Server 2016 on one server Describes how to install SharePoint Server 2016 on a single
server.
Install SharePoint Server 2016 across multiple servers Describes how to install SharePoint Server 2016 on multiple
servers.
Install or uninstall language packs for SharePoint Server 2016 Describes language packs and how to download, install, and
uninstall them.
Add a server to a SharePoint Server 2016 farm Explains how to add a server to a farm.
Remove a server from a farm in SharePoint Server 2016 Describes how to remove a server from a SharePoint Server
2016 farm.
Uninstall SharePoint Server 2016 Describes how to remove SharePoint Server 2016 from a
computer.
System requirements for SharePoint Servers 2016 and
2019

Before you install SharePoint Server, you must make sure that you have installed all required hardware and
in SharePoint Servers 2016 and 2019. You must also understand the URL and path length restrictions in
The following articles help you prepare for the installation of SharePoint Server by providing information about
the prerequisites that you must have in order to run SharePoint Server.
CONTENT DESCRIPTION

2016.

2019.

Servers 2016 and 2019 browsers to use with SharePoint Servers
2016 and 2019.
Hardware and software requirements for
IMPORTANT
hardware specifications described in this document, support will be limited until the system is upgraded to the
minimum requirements.
Hardware requirements: Location of physical servers

Some enterprises have datacenters that are in close proximity to one another and connected by high-
bandwidth fiber optic links. In this environment, you can configure the two datacenters as a single farm. This
distributed farm topology is called a stretched farm. Stretched farms for SharePoint Server 2016 are
supported.
must be met:
There is a highly consistent intra-farm latency of <1 ms one way, 99.9% of the time over a period of ten
minutes. (Intra-farm latency is commonly defined as the latency between the front-end web servers
and the database servers.)
service applications and databases.
Note:
The intra-farm latency of <1 ms one way, 99,9% of the time over a period of ten minutes is also required for
SharePoint environments with servers that are located in the same datacenter. The bandwidth speed should
also be in this case at least 1 gigabit per second.
Hardware requirements: SharePoint server installations

The following table lists minimum hardware requirements for installing and running SharePoint Server 2016
in a multiple server farm installation.
space for diagnostics such as logging, debugging, creating memory dumps, and so on. For production use,
you must also have additional free disk space for day-to-day operations. In addition, maintain two times as
much free space as you have RAM for production environments.
For information about hardware and software requirements for Microsoft SQL Server 2014, see Hardware
and Software Requirements for Installing SQL Server 2014.
Single server role Development or 16 GB 64-bit, 4 cores 80 GB for system

that uses SQL Server evaluation drive
SharePoint Server drive
2016 with the
minimum
recommended
services for
development
environments. Use
the Single-Server
farm role that will let
you choose which
service applications
to provision. For
additional
information on
Single-Server farm
role, see Overview of
MinRole Server Roles
2016
Single server role Pilot or user 24 GB 64-bit, 4 cores 80 GB for system

that uses SQL Server acceptance test drive
available services for
development
environments.
SharePoint server in Development or 12 GB 64-bit, 4 cores 80 GB for system

a multiple server evaluation drive
farm installation of 80 GB for second
SharePoint Server drive
2016 with a
minimum number of
services.
SharePoint server in Pilot, user 16 GB 64-bit, 4 cores 80 GB for system

a multiple server acceptance test, or drive
farm production 80 GB for second
deployment of drive and additional
SharePoint Server drives
2016 running all
available services.
Deployment requirements: Farm Topology

For information about how to plan for a server deployment, see Planning for a MinRole server deployment in
Software requirements for SharePoint Server 2016

NOTE
Before you run the SharePoint prerequisite installer on Windows Server 2012 R2, you need to install Windows RT 8.1,
Windows 8.1, and Windows Server 2012 R2 update: April 2014. The SharePoint prerequisite installer does not install
this update for you.
NOTE
SharePoint Server 2016 supports drives that are formatted with the Resilient File System (ReFS). For additional
information about ReFs, see Resilient File System Overview and Resilient File System
IMPORTANT
SharePoint Server 2016 does not support single label domain names. For more information, see Information about
configuring Windows for domains with single-label DNS names.
prerequisites for SharePoint Server 2016. Ensure that you have an Internet connection because some
prerequisites are installed from the Internet.
Minimum software requirements for SharePoint Server 2016
Minimum requirements for a database server in a farm
The 64-bit edition of Microsoft SQL Server 2014 Service Pack 1 (SP1)
Microsoft SQL Server 2017 RTM for Windows
Microsoft Azure SQL Managed Instance (MI) - For more information, see Deploy Azure SQL Managed
Instance with SharePoint Servers 2016 and 2019.
NOTE
SQL Server products and all future public updates are supported through the SQL Server product lifecycle.
NOTE
To take advantage of any BI scenarios, you must have the latest Powerview and PowerPivot add-ins for Microsoft SQL
Server 2016 RTM. To download the PowerPivot add-ins see, Microsoft® SQL Server® 2016 PowerPivot® for Microsoft
SharePoint® 2016
NOTE
SQL Server Express is not supported. SQL Azure (the SaaS service) is also not supported for any SharePoint databases.
Windows Server 2012 R2 Standard or Datacenter
Minimum requirements for SharePoint servers in a farm
Windows Server 2012 R2 Standard or Datacenter
NOTE
Installing the Office 2016 client and SharePoint Server 2016 on the same computer is not supported.
NOTE
SharePoint Server 2016 only supports the "Server with Desktop Experience" installation option of Windows Server 2016
and Windows Server 2019. For additional information about Windows Server offerings, see Windows Server Semi-
annual Channel Overview
NOTE
SharePoint Server 2016 supports Windows Server 2019 starting with the Security Update for Microsoft SharePoint
Enterprise Server 2016 (KB4011244), also known as the November 2017 Public Update for SharePoint Server 2016. This
update (or a newer Public Update for SharePoint Server 2016) must be installed before you can create a new SharePoint
farm or join a server to an existing SharePoint farm using Windows Server 2019.
The Microsoft SharePoint Products Preparation Tool installs the following prerequisites on SharePoint servers
in a farm:
Application Server role
Microsoft SQL Server 2012 Service Pack 1 Native Client
Microsoft ODBC Driver 11 for SQL Server
NOTE
The required software above will be supported when used by SharePoint via the SharePoint Product Lifecycle.

A supported browser. For more information, see Plan browser support in SharePoint Server 2016.
Optional software supported in SharePoint Server 2016

The optional software in this section is supported but is not required to install or use SharePoint Server 2016.
This software might be required by capabilities such as business intelligence.
Single server farm, front-end web servers, and application .NET Framework Data Provider for SQL Server (part of
servers in a farm Microsoft .NET Framework)
.NET Framework Data Provider for OLE DB (part of
Microsoft .NET Framework)
Workflow Manager
You can install Workflow Manager on a dedicated computer.
Microsoft SQL Server 2008 R2 Reporting Services Add-in
for Microsoft SharePoint Technologies
2016.
edition
64-bit edition
Microsoft SQL Server 2012 with SP1 LocalDB 64-bit edition
Microsoft SQL Server 2008 R2 Remote Blob Store which is
part of the Microsoft SQL Server 2008 R2 Feature Pack
SQL Server 2008 R2 Analysis Services ADOMD.NET

To install Windows Server 2012 R2, SQL Server 2014 Service Pack 1 (SP1) , or SharePoint Server 2016, you
can go to the websites that are listed in this section. You can install most software prerequisites through the
SharePoint Server 2016 Start page. The software prerequisites are also available from websites that are listed
in this section. You can enable the Web Server (IIS ) role and the Application Server role in Server Manager.
In scenarios where installing prerequisites directly from the Internet is not possible, you can download the
Windows Server 2016
Office 365 Enterprise
Microsoft SQL Server 2014 Service Pack 1 (SP1)
Microsoft SQL Server 2012 Service Pack 1 (SP1) Native Client (installs with Microsoft SQL Server
2012 Feature Pack)
Microsoft ODBC Driver 11 for SQL Server
Cumulative Update Package 7 for AppFabric 1.1 for Windows Server
Microsoft Silverlight 3

The SharePoint Server 2016 prerequisite installer (prerequisiteinstaller.exe) installs the following software, if it
has not already been installed on the target server, in the following order:
1. Application Server Role, Web Server (IIS ) Role
2. Microsoft SQL Server 2012 SP1 Native Client
3. Microsoft ODBC Driver 11 for SQL Server
5. Windows Server AppFabric 1.1
6. Microsoft Identity Extensions
7. Microsoft Information Protection and Control Client 2.1
9. Microsoft .NET Framework 4.6
prerequisiteinstaller.exe at a command prompt, you might be asked to restart the server one or more times
during the installation process. After restarting, you should continue the prerequisite installation by running
/? This displays command-line options.
/continue This is used to tell the installer that it is continuing from being restarted.
/unattended This indicates no user interaction.
The installer installs from the file that you specify in the command-line options described in the following list.
In this list, < file> signifies the file from which you want to install. If you do not specify the < file> option, the
installer downloads the file from the Internet and installs it. If the option does not apply to the current
operating system, it is ignored.
/SQLNCli:< file> Install Microsoft SQL Server 2012 SP1 Native Client from < file>.
/IDFX11:< file> Install Microsoft Identity Extensions from < file>.
/Sync:< file> Install Microsoft Sync Framework Runtime SP1 v1.0 (x64) from < file>.
/AppFabric:< file> Install Windows Server AppFabric from < file> (AppFabric must be installed with
the options /i CacheClient,CachingService,CacheAdmin /gac).
/KB3092423:< file> Install Cumulative Update Package 7 for Microsoft AppFabric 1.1 for Windows
Server (KB3092423) from < file>.
/MSIPCClient:< file> Install Microsoft Information Protection and Control Client from < file>.
/WCFDataServices56:< file> Install Microsoft WCF Data Services 5.6 from < file>.
**/ODBC:< file>**Install Microsoft ODBC Driver 11 for SQL Server from < file>.
**/DotNetFx:< file>**Install Microsoft .NET Framework 4.6 from < file>.
/MSVCRT11:< file> Install Visual C++ Redistributable Package for Visual Studio 2012 from < file>.
/MSVCRT14:< file> Install Visual C++ Redistributable Package for Visual Studio 2015 from < file>.
Windows AppFabric
/quiet
Plan browser support in SharePoint Servers 2016
and 2019
SharePoint Servers 2016 and 2019 supports several commonly used web browsers, such as Internet
Explorer, Google Chrome, Mozilla Firefox, Apple Safari, and Microsoft Edge. However, certain web
browsers can cause some SharePoint Servers 2016 or 2019 functionality to be downgraded, limited, or available
only through alternative steps.
As you plan your deployment of SharePoint Servers 2016 or 2019, we recommend that you review the browsers
used in your organization to guarantee optimal performance with SharePoint Servers 2016 and 2019.

Browser support is an important part of your SharePoint Servers 2016 or 2019 implementation. Before you
install SharePoint Server 2016, make sure that you know the browsers that SharePoint Server 2016 supports.
The information in this article describes browser support in the following sections:
Browser support levels
Browser details
Microsoft Edge X
Google Chrome (latest released X

version)
Mozilla Firefox (latest released version X

plus immediate previous version)

Microsoft Edge X
Google Chrome (latest X

released version)
Mozilla Firefox (latest X

released version plus
immediate previous version)
Apple Safari (latest released X

version)
Browser details
Review the details of the web browser that you have or plan to use in your organization to make sure that the
web browser works with SharePoint Server 2016 and according to your business needs.
Internet Explorer and older functionality
NOTE
Some older SharePoint functionality that relies on NPAPI or ActiveX will not work on browsers other than Internet Explorer.
You can work around each of these issues by using Internet Explorer to perform these tasks.
Using ActiveX controls in SharePoint Server
Some functionality in SharePoint Server requires ActiveX controls. This produces limitations on browsers which
do not support ActiveX. Currently only 32-bit versions of Internet Explorer support this functionality. In
SharePoint Server 2016, all other supported browsers, including Microsoft Edge and the Immersive mode of
Internet Explorer 10 have the following limitations.
For SharePoint Server 2016 and 2019, browsers other than Internet Explorer 11 have the following limitations.
Plugin name DLL file name What it does Known limitations
Digital Signature Dsigctrl.dll, dsigres.dll Digital signing takes An inability to verify a

place in both the form produces an
InfoPath client and error that states that
on the InfoPath the form cannot be
Forms Services server. signed.
Make sure that the
exist:
Forms that are
signed on the client
can be verified on the
server.
Forms that are
signed on the server
can be verified on the
client.
NameCtrl Name.dll Enables a webpage to

display a contact card
and presence status
for people. Integrates
through client-side
APIs with Office client
and Skype for
Business client.
TaskLauncher Nameext.dll Used to export items If software

in a task list to requirements are not
Project Server if met, an error
Project client is message states that
installed on the client you need to install
computer. Project client.
SpreadSheetLauncher Owssupp.dll Used to verify If Excel is not

whether Excel is installed, the user
installed for Export to may be prompted to
Excel feature. download the file
"query.iqy" which can
then be opened in
Excel.
StssyncHandler Owssupp.dll Enables

synchronization of
lists of events and
lists of contacts in
SharePoint with a
messaging
application such as
Outlook. Non-IE
clients may have an
additional prompt to
open the calendar in
Outlook.
ExportDatabase Owssupp.dll Enables a user to use To export a list, the
an application such client computer must
as Access to create or have a SharePoint
list data.
OpenDocuments Owssupp.dll Starts Office client If a compatible Office

applications so that a application or
user can create a or browser is not
edit a document. installed on a client,
Enables users to an error message
create documents states that the
that are based on a feature requires a
specified template, SharePoint
open documents as compatible
read-only, or open application and web
documents as browser.
read/write.
CopyCtl Stsupld.dll Enables a user to In Firefox, Google

copy a document on Chrome, and
a SharePoint site to immersive mode of
one or more Internet Explorer
locations on a server. version 10, the copy
not displayed.
PPActiveX PPSLAX.dll Starts PowerPoint to Does not work on

open presentations Click-to-Run
slides to a slide that run on Windows
library. for ARM.
BCSLauncher BCSLaunch.dll Starts the Visual

Studio Tools for
Office installer to
install a Visual Studio
Tools for Office
package that has
been generated on
the server.
Other functionality, such as Form settings in List settings only function with Internet Explorer.

SharePoint Server 2016 supports the following versions:
Internet Explorer and Microsoft Edge on Windows Phone 8.1 or later.
Latest version of Chrome on Android 4.4 or later.
Latest versions of Safari and Chrome on iOS 8 or later.
For SharePoint Server 2019, Chrome or Safari on iOS10 or later
Software boundaries and limits for SharePoint

This article describes software boundaries and limits of SharePoint Servers 2016 and 2019. These include the
following:
Boundaries: Static limits that cannot be exceeded by design
Thresholds: Configurable limits that can be exceeded to accommodate specific requirements
Supported limits: Configurable limits that have been set by default to a tested value
NOTE
The capacity planning information in this document provides guidelines for you to use in your planning. It is based on
testing performed at Microsoft, on live properties. However, your results are likely to vary based on the equipment you use
and the features and functionality that you implement for your sites.
Overview of boundaries and limits

This article contains information to help you understand the tested performance and capacity limits of SharePoint
Server 2016, and offers guidelines for how limits relate to acceptable performance. Use the information in this
article to determine whether your planned deployment falls within acceptable performance and capacity limits,
and to appropriately configure limits in your environment.
The test results and guidelines provided in this article apply to a single SharePoint Server farm. Adding servers to
the installation might not increase the capacity limits of the objects that are listed in the tables in the Limits and
boundaries section later in this topic. On the other hand, adding server computers increases the throughput of a
server farm, which might be necessary to achieve acceptable performance with many objects. In some cases, the
requirements for high numbers of objects in a solution might require more servers in the farm.
Note that there are many factors that can affect performance in a given environment, and each of these factors
can affect performance in different areas. Some of the test results and recommendations in this article might be
related to features or user operations that do not exist in your environment, and therefore do not apply to your
solution. Only thorough testing can give you exact data related to your own environment.
Boundaries, thresholds and supported limits
In SharePoint Server, there are certain limits that are by design and cannot be exceeded, and other limits that are
set to default values that may be changed by the farm administrator. There are also certain limits that are not
represented by a configurable value, such as the number of site collections per web application.
Boundaries are absolute limits that cannot be exceeded by design. It is important to understand these
limits to ensure that you do not make incorrect assumptions when you design your farm.
An example of a boundary is the 10 gigabyte (GB ) document size limit; you cannot configure SharePoint
Server 2016 to store documents that are larger than 10 GB. This is a built-in absolute value, and cannot be
exceeded by design.
Thresholds are those that have a default value that cannot be exceeded unless the value is modified.
Thresholds can, in certain circumstances, be exceeded to accommodate variances in your farm design, but
it is important to understand that doing this may affect the performance of the farm in addition to the
effective value of other limits.
The default value of certain thresholds can only be exceeded up to an absolute maximum value. A good
example is the document size limit. By default, the default document size threshold is set to 250 megabyte
(MB ), but can be changed to support the maximum boundary of 10 GB.
Supported limits define the tested value for a given parameter. The default values for these limits were
defined by testing, and represent the known limitations of the product. Exceeding supported limits may
cause unexpected results, significant decrease in performance, or other harmful effects.
Some supported limits are configurable parameters that are set by default to the recommended value,
while other supported limits relate to parameters that are not represented by a configurable value.
An example of a supported limit is the number of site collections per farm. The supported limit is the largest
number of site collections per web application that met performance benchmarks during testing.
It is important to be aware that many of the limit values that are provided in this document represent a point in a
curve that describes an increasing resource load and concomitant decrease in performance as the value increases.
Therefore, exceeding certain limits, such as the number of site collections per web application, may only result in a
fractional decrease in farm performance. However, in most cases, operating at or near an established limit is not a
best practice, as acceptable performance and reliability targets are best achieved when a farm's design provides
for a reasonable balance of limits values.
Thresholds and supported limits guidelines are determined by performance. In other words, you can exceed the
default values of the limits, but as you increase the limit value, farm performance and the effective value of other
limits may be affected. Many limits in SharePoint Server 2016 can be changed, but it is important to understand
how changing a given limit affects other parts of the farm.
How limits are established
In SharePoint Server, thresholds and supported limits are established through testing and observation of farm
behavior under increasing loads up to the point where farm services and operations reach their effective
operational limits. Some farm services and components can support a higher load than others so that in some
cases you must assign a limit value based on an average of several factors.
For example, observations of farm behavior under load when site collections are added indicate that certain
features exhibit unacceptably high latency while other features are still operating within acceptable parameters.
Therefore, the maximum value assigned to the number of site collections is not absolute, but is calculated based
on an expected set of usage characteristics in which overall farm performance would be acceptable at the given
limit under most circumstances.
Obviously, if some services are operating under parameters that are higher than those used for limits testing, the
maximum effective limits of other services will be reduced. It is therefore important to execute rigorous capacity
management and scale testing exercises for specific deployments in order to establish effective limits for that
environment.
NOTE
We do not describe the hardware that was used to validate the limits in this document, because the limits were collected
from multiple farms and environments.
The Pie Metaphor

In order to understand the relationship between hardware resources, load and performance, it's important to have
a way to visualize the factors involved and how they affect each other.
Consider the capacity of a farm as a pie, the size of which represents the aggregate of factors such as servers,
hardware resources such as CPUs and RAM, storage capacity, disk IOPS, network bandwidth and latency. The
size of the pie is therefore related to the overall resources of the farm; adding resources (such as farm servers)
increases the size of the pie.
This pie is divided into slices that represent load from a variety of sources: user requests, search queries,
operations against installed features, timer jobs and operating system overhead. Each of these sections must
share available farm resources. If the size of one slice increases, the size of others must decrease proportionally.
Since load on a farm is not static (user requests, for example, might only be significant during certain hours of the
day), the relative size of the slices is constantly in flux. However, each slice must maintain a required minimum
size to operate normally, and since the functions represented by each slice are interdependent, increasing the size
of one slice may place more load on other slices in addition to reducing the resources available for them to
consume.
Using this metaphor, the goal of the farm's design is to make the pie large enough to accommodate the required
size of each pie slice under peak load.
Now, consider a scenario where user requests increase by 100% over baseline. Let's say that about half of the
requests are search queries, and the other half editing lists and documents. This increased load squeezes the other
pie slices, but some farm features must also work harder to compensate. The Search service has to process more
queries, most of which are handled by the cache, but some queries are passed on to the database servers,
increasing their load as well. If load on the database servers becomes too great, disk queue lengths will increase,
which in turn increases the latency of all other requests.
Limits and boundaries

This section lists the objects that can be a part of a solution and provides guidelines for acceptable performance
for each kind of object. Acceptable performance means that the system as tested can support that number of
objects, but that the number cannot be exceeded without some decrease in performance or a reduction in the
value of related limits. Objects are listed both by scope and by feature. Limits data is provided, together with notes
that describe the conditions under which the limit is obtained and links to additional information where available.
Use the guidelines in this article to review your overall solution plans. If your solution plans exceed the
recommended guidelines for one or more objects, take one or more of the following actions:
Evaluate the solution to ensure that compensations are made in other areas.
Flag these areas for testing and monitoring as you build your deployment.
Redesign or partition the solution to ensure that you do not exceed capacity guidelines.
Limits by hierarchy
This section provides limits sorted by the logical hierarchy of a SharePoint Server 2016 farm.
Web application limits
The following table lists the recommended guidelines for web applications.
LIMIT MAXIMUM VALUE LIMIT TYPE NOTES

Web application 20 per farm Supported We recommended limiting

the number of web
applications as much as
possible. Create additional
host named site collections
where possible instead of
adding web applications.
Zone 5 per web application Boundary The number of zones

defined for a farm is hard-
coded to 5. Zones include
Default, Intranet, Extranet,
Internet, and custom.
Managed path for host- 20 per farm Supported Managed paths for host-
named site collections named site collections apply
at the farm level. Each
managed path that is
created can be applied in
any Web application.
Managed path for path- 20 per web application Supported Managed paths are cached
based site collections on the web server, and CPU
resources are used to
process incoming requests
against the managed path
list.
Managed paths for path-
based site collections apply
at the Web application level.
You can create a different
set of managed paths for
each Web application.
Exceeding 20 managed
paths per web application
adds more load to the web
server for each request.
If you plan to exceed twenty
managed paths in a given
web application, we
recommend that you test
for acceptable system
performance.
Solution cache size 300 MB per web application Threshold The solution cache allows
the InfoPath Forms service
to hold solutions in cache in
order to speed up retrieval
of the solutions. If the cache
size is exceeded, solutions
are retrieved from disk,
which may slow down
response times. To configure
the size of the solution
cache, see Set-
SPInfoPathFormsService.
SharePoint server limits
The following table lists the recommended guidelines for web servers on the farm.
Application pools 10 per web server Threshold The maximum number is

determined by hardware
capabilities.
This limit is dependent
largely upon:
The amount of memory
allocated to the web servers
The workload that the farm
is serving, that is, the user
base and the usage
characteristics (a single
highly active application
pool can utilize 10 GB or
more)
Content database limits
The following table lists the recommended guidelines for content databases.
Number of content 500 per farm Supported The maximum number of

databases content databases per farm
is 500. With 500 content
databases per web
application, end user
operations such as opening
the site or site collections
are not affected. But
administrative operations
such as creating a new site
collection will experience
decrease in performance. We
recommend that you use
PowerShell to manage the
web application when a
large number of content
databases are present,
because the management
interface might become slow
and difficult to navigate.
With 200GB per content
database, and 500 content
databases per farm,
supports 100TB of data per
farm.
Content database size 200 GB per content Supported We strongly recommended

(general usage scenarios) database limiting the size of content
databases to 200 GB, except
when the circumstances in
the following rows in this
table apply.
If you are using Remote
BLOB Storage (RBS), the
total volume of remote
BLOB storage and metadata
in the content database
must not exceed the 200GB
limit.
Content database size (all 4 TB per content database Supported Content databases of up to
usage scenarios) 4 TB are supported when
the following requirements
are met:
Disk sub-system
performance of 0.25 IOPS
per GB. 2 IOPS per GB is
recommended for optimal
performance.
You must have developed
plans for high availability,
disaster recovery, future
capacity, and performance
testing.
You should also carefully
consider the following
factors:
Requirements for backup
and restore may not be met
by the native SharePoint
Server 2016 backup for
content databases larger
than 200 GB. It is
recommended to evaluate
and test SharePoint Server
2016 backup and alternative
backup solutions to
determine the best solution
for your specific
environment.
It is strongly recommended
to have proactive skilled
administrator management
of the SharePoint Server
2016 and SQL Server
installations.
The complexity of
customizations and
configurations on
SharePoint Server 2016 may
necessitate refactoring (or
splitting) of data into
multiple content databases.
Seek advice from a skilled
professional architect and
perform testing to
determine the optimum
content database size for
your implementation.
Examples of complexity may
include custom code
deployments, use of more
than 20 columns in property
promotion, or features listed
as not to be used in the
over 4 TB section below.
Refactoring of site
collections allows for scale
out of a SharePoint Server
2016 implementation across
This permits SharePoint
Server 2016
implementations to scale
indefinitely. This refactoring
will be easier and faster
when content databases are
less than 200 GB.
It is suggested that for ease
of backup and restore that
individual site collections
within a content database
be limited to 100 GB. For
more information, see Site
collection limits.
> [!IMPORTANT]> We do
not recommend the use of
content databases that
exceed 4 Terabyte (TB),
except in document archive
scenarios (described in the
next row in this table). If, in
the future, you need to
upgrade your SharePoint
Server 2016 installation,
upgrading the site
collections within the
content databases can be
very difficult and time
consuming. > It is strongly
recommended that you
scale out across multiple
content databases, rather
than exceed 4 TB of data in
a single content database.
Content database size No explicit content database Supported Content databases with no
(document archive scenario) limit explicit size limit for use in
document archive scenarios
are supported when the
following requirements are
met:
You must meet all
requirements from the
"Content database size (all
usage scenarios)" limit earlier
in this table, and you should
ensure that you have
carefully considered all the
factors discussed in the
Notes field of that limit.
SharePoint Server 2016 sites
must be based on
Document Center or
Records Center site
templates.
Less than 5% of the content
in the content database is
accessed each month on
average, and less than 1% of
content is modified or
written each month on
average.
Do not use alerts,
workflows, link fix-ups, or
item level security on any
objects in the content
database.
> [!NOTE]> Document
archive content databases
can be configured to accept
documents from Content
Routing workflows.
Content database items 60 million items including Supported The largest number of items
documents and list items per content database that
has been tested on
SharePoint Server 2016 is
60 million items, including
documents and list items. If
you plan to store more than
60 million items in
SharePoint Server 2016, you
must deploy multiple
content databases.
Site collections per content 10,000 maximum (2,500 Supported We strongly recommended
database non-Personal site collections limiting the number of site
and 7,500 Personal Sites, or collections in a content
10,000 Personal Sites alone) database to 5,000. However,
up to 10,000 site collections
in a database are supported.
Note that in a content
database with up to 10,000
total site collections, a
maximum of 2,500 of these
can be non-Personal site
collections. It is possible to
support 10,000 Personal
site collections if they are
the only site collections
within the content database.
These limits relate to speed
of upgrade. The larger the
number of site collections in
a database, the slower the
upgrade with respect to
both database upgrade and
site collection upgrades.
The limit on the number of
site collections in a database
is subordinate to the limit
on the size of a content
database that has more
than one site collection.
Therefore, as the number of
increases, the average size of
the site collections it
contains must decrease.
Exceeding the 5,000 site
collection limit puts you at
risk of longer downtimes
during upgrades. If you plan
to exceed 5,000 site
collections, we recommend
that you have a clear
upgrade strategy to address
outage length and
operations impact, and
obtain additional hardware
to speed up the software
updates and upgrades that
affect databases.
To set the warning and
maximum levels for the
number of sites in a content
database, use the
PowerShell cmdlet Set-
SPContentDatabase with the
WarningSiteCount
parameter. For more
information, see Set-
SPContentDatabase.
Remote BLOB Storage (RBS) Time to first byte of any Boundary When SharePoint Server
storage subsystem on response from the NAS 2016 is configured to use
Network Attached Storage should remain within 40 RBS, and the BLOBs reside
(NAS) milliseconds 95% of the on NAS storage, consider
time. the following supported
limit.
From the time that
requests a BLOB, until it
receives the first byte from
the NAS, 95% of the time no
more than 40 milliseconds
can pass.
Site collection limits
The following table lists the recommended guidelines for site collections.
Site collections per farm 250,000 per site collection / Supported The maximum
500,000 Personal Sites/ recommended number of
250,000 other sites per site collections per farm is
farm. 500,000 Personal Sites plus
250,000 for all other site
templates. The Sites can all
reside on one web
application, or can be
distributed across multiple
web applications.
Note that this limit is
affected by other factors
that might reduce the
effective number of site
collections that can be
supported by a given
content database. Care must
be exercised to avoid
exceeding supported limits
when a container object,
such as a content database,
contains a large number of
other objects. For example, if
a farm contains a smaller
total number of content
databases, each of which
site collections, farm
performance might be
adversely affected long
before the supported limit
for the number of site
collections is reached.
For example, Farm A
contains a web application
that has 200 content
databases, a supported
configuration. If each of
these content databases
contains 1,000 site
collections, the total number
of site collections in the web
LIMIT MAXIMUM VALUE LIMIT TYPE application
NOTES will be 200,000,
which falls within supported
limits. However, if each
content database contains
10,000 site collections, even
though this number is
supported for a content
database, the total number
of site collections in the farm
will be 2,000,000, which
exceeds the limit for the
number of site collections
per web application.
Memory usage on the web
servers should be
monitored, as memory
usage is dependent on
usage patterns and how
many sites are being
accessed in given timeframe.
Similarly, the crawl targets
might also exhibit memory
pressure, and if so the
application pool should be
configured to recycle before
available memory on any
web server drops to less
than 2 GB.
Web site 250,000 per site collection / Supported The maximum

250,000 per farm / 500,000 recommended number of
personal sites per farm. sites and subsites is 250,000
sites.
Performance can degrade as
the number of subsites
surpasses 2,000 at the site
collection level.
> [!IMPORTANT]> Staying
below 2,000 subsites per
site collection is strongly
recommended. You can
create a very large total
number of web sites by
creating multiple site
collections with up to 2000
webs per site collection. For
example, 125 site collections
that contain 2,000 webs
each will equate to 250,000
sites in the farm. However,
this would be considered the
maximum recommended
limit for non-personal sites.
If you have 250,000 site
collections, all containing a
root web site that is not the
Personal Site template,
adding a sub-site to any of
those root sites would
exceed the 250,000 web site
boundary.
If the recommended limit of
2,000 sites per site collection
is exceeded, the following
issues may occur:
Deleting or creating a site or
subsite can significantly
affect a site's availability.
Access to the site and
subsites will be limited while
the site is being deleted.
Attempting to create many
subsites at the same time
may also fail.
When having more than
2,000 subsites, the
performance of actions such
as executing PSConfig when
adding a new server to an
existing farm, or after
installing SharePoint
updates the drastically
decrease.
Executing the stsadm -o
checklocalupgradestatus
operation, or the daily
execution of the Product
Version Job timer job may
take many hours to
complete.
Browsing the Review
database status page
(<your_SharePoint_CentralA
dmin_URL>/_admin/Upgrad
eStatus.aspx) on the Central
Administration web site may
result in a timeout.
Site collection size Maximum size of the Supported A site collection can be as
content database large as the content
database size limit for the
applicable usage scenario.
For more information about
the different content
database size limits for
specific usage scenarios, see
the Content database limits
table in this article.
In general, we strongly
recommend limiting the size
of site collections to 100 GB
for the following reasons:
Certain site collection
actions, such as site
collection backup/restore or
the PowerShell cmdlet
Move-SPSite, cause large
SQL Server operations which
can affect performance or
fail if other site collections
are active in the same
database. For more
information, see Move-
SPSite.
SharePoint site collection
backup and restore is only
supported for a maximum
site collection size of 100
GB. For larger site
collections, the complete
content database must be
backed up. If multiple site
collections larger than 100
GB are contained in a single
content database, backup
and restore operations can
take a long time and are at
risk of failure.
Number of device channels 10 Boundary The maximum allowed

per publishing site collection number of device channels
per publishing site collection
is 10.
List and library limits
The following table lists the recommended guidelines for lists and libraries. For more information, see Designing
large Lists and maximizing list performance (SharePoint Server 2010).

List row size 8,000 bytes per row Boundary Each list or library item can
only occupy 8,000 bytes in
total in the database. 300
bytes are reserved, leaving
7700 bytes for end-user
columns. For details on how
much space each kind of
field consumes, see Column
limits.
File size 10 GB Boundary The default file size is 2

gigabytes (GB) (2,047 MB).
However, a large volume of
very large files can affect
farm performance.
NOTE: In SharePoint Server

2019, the file limit is 15 GB.
Documents 30,000,000 per library Supported You can create very large
document libraries by
nesting folders, or using
standard views and site
hierarchy. This value may
vary depending on how
documents and folders are
organized, and by the type
and size of documents
stored.
Major versions 400,000 Supported If you exceed this limit, basic

file operations—such as file
open or save, delete, and
viewing the version history
— may not succeed.
Minor versions 511 Boundary The maximum number of

minor file versions is 511.
This limit cannot be
exceeded.
Items 30,000,000 per list Supported You can create very large
lists using standard views,
site hierarchies, and
metadata navigation. This
value may vary depending
on the number of columns
in the list and the usage of
the list.
Bulk operations 100 items per bulk Boundary The user interface allows a
operation maximum of 100 items to
be selected for bulk
operations.
List view lookup threshold 12 join operations per query Threshold Specifies the maximum
number of joins allowed per
query, such as those based
on lookup, person/group, or
workflow status columns. If
the query uses more than
eight joins, the operation is
blocked. This does not apply
to single item operations.
When using the maximal
view via the object model
(by not specifying any view
fields), SharePoint will return
up to the first 12 lookups.
List view threshold greater than 5,000 Threshold Specifies the maximum
number of list or library
items that a database
operation, such as a query,
can process at the same
time outside the daily time
window set by the
administrator during which
queries are unrestricted.
When adding or removing a
column index, the threshold
is 20,000 by default.
When deleting a list or
folder, the threshold is
100,000 by default.
When renaming a folder
within the same library, the
threshold is 100,000 by
default.
List view threshold for 20,000 Threshold Specifies the maximum

auditors and administrators number of list or library
time when they are
performed by an auditor or
administrator with
appropriate permissions.
This setting works with
Allow Object Model
Override.
Subsite 2,000 per site view Threshold The interface for

enumerating subsites of a
given web site does not
perform well as the number
of subsites surpasses 2,000.
Similarly, the All Site Content
page and the Tree View
Control performance will
decrease significantly as the
number of subsites grows.
List 2,000 per Web site Threshold Testing indicates a reduction

in list view performance
beyond two thousand
entries.
Coauthoring in Word and 10 concurrent editors per Threshold Recommended maximum

PowerPoint for .docx, .pptx document number of concurrent
and .ppsx files editors is 10. The boundary
is 99.
If there are 99 co-authors
who have a single document
opened for concurrent
editing, each successive user
sees a "File in use" error, and
can only open a read-only
copy.
More than 10 co-editors will
lead to a gradually degraded
user experience with more
conflicts, and users might
have to go through more
iterations to successfully
upload their changes to the
server.
Security scope 50,000 per list Threshold The maximum number of

unique security scopes set
for a list cannot exceed
50,000.
For most farms, we
recommend that you
consider lowering this limit
to 5,000 unique scopes. For
large lists, consider using a
design that uses as few
unique permissions as
possible.
When the number of unique
security scopes for a list
exceeds the value of the list
view threshold (set by
default at 5,000 list items),
additional SQL Server round
trips take place when the list
is viewed, which can
adversely affect list view
performance.
A scope is the security
boundary for a securable
object and any of its children
that do not have a separate
security boundary defined. A
scope contains an Access
Control List (ACL), but unlike
NTFS ACLs, a scope can
include security principals
that are specific to
SharePoint Server 2016. The
members of an ACL for a
scope can include Windows
users, user accounts other
than Windows users (such
as forms-based accounts),
Active Directory groups, or
SharePoint groups.
Security scope (ACL) 500 child objects with Threshold The maximum number of
propagation unique scopes child objects with unique
security scopes that can be
updated during ACL
propagation cannot exceed
500.
Scope updates can be set to
update child objects using
ACL propagation, which will
update uniquely scoped
items and items that inherit
permissions. During a parent
scope update that includes
ACL propagation to children,
if the maximum number of
child objects with unique
scopes is greater than 500,
propagation will fail with
only some of the children
with unique scopes
potentially being updated.
Whenever the maximum
number of child objects with
unique scopes is larger than
500 ACL propagation
should not be used.
Column limits
SharePoint Server 2016 data is stored in SQL Server tables. Each column type has a size value listed in bytes. The
sum of all columns in a SharePoint list cannot exceed 8,000 bytes.
LIMIT MAXIMUM # COLUMNS LIMIT TYPE SIZE PER COLUMN NOTES
Single line of text 255 Threshold 30 bytes
Multiple Lines of Text 350 Threshold 22 bytes
Choice 255 Threshold 30 bytes
Choice (multiple 350 Threshold 22 bytes

selection)
Number 550 Threshold 14 bytes
Currency 550 Threshold 14 bytes
Date and Time 550 Threshold 14 bytes
Lookup 750 Threshold 10 bytes
Yes / No 1000 Threshold 7 bytes
Person or group 750 Threshold 10 bytes

Hyperlink or picture 127 Threshold 60 bytes A Hyperlink or Picture

column is allocated
two columns for
storage: one for the
URL and one for the
Description.
Calculated 255 Threshold 30 bytes SQL Server row

wrapping occurs after
each eight columns in
a SharePoint list. The
default row wrapping
value of six allows for
a maximum of 48
Calculated columns
per SharePoint list (6
* 8 = 48).
GUID 350 Threshold 22 bytes SQL Server row

wrapping occurs after
each column in a
SharePoint list. The
default row wrapping
value of six allows for
a maximum of 6
GUID columns per
SharePoint list (6 * 1
= 6).
Integer 750 Threshold 10 bytes

Managed metadata 190 Threshold 60 bytes for the first, The first Managed
40 bytes for each Metadata field added
subsequent to a list is allocated
four columns:
A lookup field for the
actual tag
A hidden text field for
the string value
catch all
A lookup field for
spillover of the catch
all
Each subsequent
Managed Metadata
field added to a list
adds two more
columns:
actual tag
the string value
The maximum
number of columns of
Managed Metadata is
calculated as (14 +
(16 * (n-1))) where n
is the row mapping
value (default of 6).
Geolocation 2 Threshold 30 bytes
External Data columns have the concept of a primary column and secondary columns. When you add an external
data column, you can select some secondary fields of the external content type that you want to be added to the
list. For example, given an External Content Type "Customer" which has fields like "ID", "Name", "Country", and
"Description", when you add an External Data column of type "Customer" to a list, you can add secondary fields to
show the "ID", "Name" and "Description" of the Customer. Overall these are the columns that get added:
Primary column: A text field.
Hidden Id column: A multi-line text field.
Secondary columns: Each secondary column is a text/number/Boolean/multi-line text that is based on the
data type of the secondary column as defined in the Business Data Catalog model. For example, ID might
be mapped to a Number column; Name might be mapped to a Single line of text column ; Description
might be mapped to a Multiple lines of text column.
Page limits
The following table lists the recommended guidelines for pages.

Web parts 25 per wiki or Web Part Threshold This figure is an estimate
page based on simple Web Parts.
The complexity of the Web
Parts dictates how many
Web Parts can be used on a
page before performance is
affected.
Security limits
Number of SharePoint 5,000 Supported This is not a hard limit but it

groups a user can belong to is consistent with Active
Directory guidelines. There
are several things that affect
this number:
The size of the user token
The groups cache:
SharePoint Server 2016 has
a table that caches the
number of groups a user
belongs to as soon as those
groups are used in access
control lists (ACLs).
The security check time: as
the number of groups that a
user is a member of
increases, the time that is
required for the access check
increases also.
Users in a site collection 2 million per site collection Supported You can add millions of
people to your web site by
using Microsoft Windows
security groups to manage
security instead of using
individual users.
This limit is based on
manageability and ease of
navigation in the user
interface.
When you have many
entries (security groups of
users) in the site collection
(more than one thousand),
you should use PowerShell
to manage users instead of
the UI. This will provide a
better management
experience.
Active Directory 5,000 per SharePoint group Supported SharePoint Server 2016
Principles/Users in a enables you to add users or
SharePoint group Active Directory groups to a
SharePoint group.
Having up to 5,000 users (or
Active Directory groups or
users) in a SharePoint group
provides acceptable
performance.
The activities most affected
by this limit are as follows:
Fetching users to validate
permissions. This operation
takes incrementally longer
with growth in number of
users in a group.
Rendering the membership
of the view. This operation
will always require time.
SharePoint groups 10,000 per site collection Supported Above 10,000 groups, the
time to execute operations is
increased significantly. This is
especially true of adding a
user to an existing group,
creating a new group, and
rendering group views.
Security principal: size of the 5,000 per Access Control Supported The size of the scope affects
Security Scope List (ACL) the data that is used for a
security check calculation.
This calculation occurs every
time that the scope changes.
There is no hard limit, but
the bigger the scope, the
longer the calculation takes.
Limits by feature
This section lists limits sorted by feature.
Search limits
The recommended guidelines for search are organized according to the aspects of search that they impact: the
topology, the size of items, dictionaries, crawling, schema, queries and results, ranking, and the index.
Search: topology limits
The topology limits ensure efficient communication between search components. Exceeding these limits slows
down the communication between search components, which can result in longer query latencies and ultimately
outage of search.
Analytics processing 6 per Search service Supported

components application; 1 per server
Analytics reporting 4 per Search service Threshold You can exceed this limit to
databases application accommodate specific
requirements. When scaling,
add an analytics reporting
database when the size of
any of the deployed
analytics databases reaches
250 GB total size, or 20 M
total rows. This way
repartitioning is as balanced
as possible.
Link databases 4 per Search service Supported The highest tested number
application of items a link database can
contain is 100 million.
Crawl components 16 per Search service Supported

application; 1 per server
Index components 60 per Search service Supported To calculate the number of

application; 4 per server index components you have,
multiply the number of
index partitions with the
number of index replicas.
Index partitions 25 per Search service Supported An index partition holds a

application subset of the Search service
application index. Increasing
the number of index
partitions results in each
partition holding a smaller
subset of the index, reducing
the RAM and disk space that
is needed on the servers
hosting the index
components.
Index replicas 3 per index partition Supported Each index partition can
have a set of replica. If you
increase the number of
index replicas, this has a
positive effect on the query
performance and it provides
better fault tolerance. But, if
you add too many replicas
to your index partition, this
can adversely affect
indexing.
For Internet sites scenarios,
which typically have a high
query rate but low content
volume (less than 4 million
items per partition), the
supported limit is 6 index
replicas per partition.
Content processing 1 per server Supported The search topology

components supports scaling out the
number of content
processing components.
Although a specific physical
host or virtual machine does
support multiple content
processing components, you
achieve better usage of the
CPU capacity by using one
content processing
component. The reason is
that a built-in mechanism
maximizes CPU usage by
adjusting the number of
feeding sessions according
to available CPU cores.
Multiple feeding sessions
allow the content processing
component to process
incoming documents in
parallel. This mechanism
assumes a single content
processing component per
host.
If the number of physical
cores on the host equals N,
then the content processing
component will have NK
feeding sessions. K is a
constant coefficient with the
initial value 3. A 4-core
server will have 12 feeding
sessions, which means that
the content processing
component can process 12
documents in parallel. You
can change the value of K
by setting the
NumberOfCssFeedersPerC
PUForRegularCrawl
property of the Search
Service Application.
limits the value of N
upward to 12, even if a
server has more than 12
physical cores. Therefore a
16-core server will have NK
= 12 * 3 = 36 feeding
sessions.
In the case that there still is
idle CPU time, consider
increasing the K coefficient
instead of adding an
additional content
processing component. If
you increase the K
coefficient, you must make
sure that the host has
sufficient available memory.
Query processing 1 per server Supported SharePoint Server 2016 only

components supports one query
physical machine or virtual
machine.
Search components 64 per Search service Supported This limit does not include
application crawl components. The sum
of all the other search
components must stay
within this limit.
Search service applications 20 per farm Supported Multiple Search service

applications can be deployed
on the same farm, because
you can assign search
components and databases
to separate servers. This
limit is lower than the limit
for the total number of
service applications in a
farm.
Content sources 500 per Search service Boundary There is overhead associated
application with each content source, so
we recommend that you
create the smallest number
of content sources that
satisfy your other
operational requirements,
for example differences in
crawl priority and
scheduling.
Search: item size limits

The item size limits safeguard crawling performance and the size of the index. Here are some examples of how
the limits can affect searching:
If you can't get results when you search for an item, the item could be too large. A warning will show up in
the Crawl Log, stating that the file exceeded the maximum size that the crawler can download.
If you search for text in an item and only get results from the first part of the text, the content processing
component may have truncated the item because it exceeded some of item size limits. When the content
processing component truncates an item, it indicates this by setting the managed property
IsPartiallyProcessed to True. A warning will also show up in the Crawl Log, stating why the item was
truncated.
If you tune item size limits, we recommend that you work with them in the order they appear in this table.

Document size crawl 64 MB (3 MB for Excel Threshold Search downloads meta data
component can download documents) and content from a
document until it reaches
the maximum document
size. The rest of the content
is not downloaded. Search
always downloads a
document's meta data.
You can change the default
limit for the maximum
document size. Do this by
using Microsoft PowerShell
cmdlets to change the
Search service application
property
MaxDownLoadSize or
MaxDownloadSizeExcel.
MaxDownLoadSize doesn't
impact the maximum size for
Excel documents. Enter the
value in megabytes. The
maximum value for the
maximum document size is
1024 MB, also for Excel
documents.
If you increase the limit for
size, search indexes more
content and needs more
disk space.
Parsed content size 2 million characters Boundary Search stops parsing an item
after it has parsed up to 2
million characters of content
from it, including the item's
attachments. The actual
amount of parsed characters
can be lower than this limit
because search uses
maximum 30 seconds on
parsing a single item and its
attachments. When search
stops parsing an item, the
item is marked as partially
processed. Any unparsed
content isn't processed and
therefore isn't indexed.
Characters produced by the 1,000,000 Boundary Search breaks content into

word breaker individual words (tokens).
The word breaker produces
tokens from the first
1,000,000 characters of a
single item, including the
item's attachments.The
actual number of processed
items can be lower than this
limit because search uses
maximum 30 seconds on
word breaking. Any
remaining content isn't
processed and therefore isn't
indexed.
Indexed managed property 512 KB per Threshold This is the default value for
size searchable/queryable the maximum size of a
managed property managed property that is
set to either "searchable" or
"queryable". You can
configure this limit by using
PowerShell cmdlets and the
schema object model to set
the
MP.MaxCharactersInProp
ertyStoreIndex attribute.
Enter the value in bytes. The
maximum value for this
maximum size is 2097152
bytes.
If you increase this limit you
enable indexing of more
data per managed property.
Indexing more data per
managed property uses
more disk space and
increases the overall load on
the search system.
Retrievable managed 16 KB per managed Threshold This is the default value for
property size property the maximum size of a
retrievable managed
property. If you increase this
limit you enable indexing of
more data per managed
property. Increasing this
limit also enables search to
retrieve more data per
managed property for
search results. Indexing and
retrieving more data per
managed property increases
the overall load on the
system and uses more disk
space.
You can configure this limit
per managed property by
using PowerShell cmdlets
and the schema object
model to set the
P.MaxCharactersInPropert
yStoreForRetrievalattribut
e. Enter the value in bytes.
The maximum value for this
maximum size is 2097152
bytes.
Increasing this limit also
enables search to retrieve
property for search results.
Indexing and retrieving
property
Sortable and refinable 16 KB per managed Boundary This is the maximum size of
managed property size property a sortable and refinable
managed property.
Token size Variable Boundary Search can index tokens of

any length. But the word
breaker that search uses to
produce tokens can limit the
token length. Word breakers
are language-aware
components that break
content into single words
(tokens). You can also create
custom word breakers. The
token size limit therefore
depends on the word
breaker.
Here's the limit of the word
breaker for western
languages:
The word breaker only
considers the first 1000
characters of a token for
splitting, it ignores any
remaining characters.
The word breaker splits
tokens that are longer than
300 characters into two or
more tokens where no
token has more than 300
characters. For example, a
612 character token is split
into two 300 character
tokens and one 12 character
token.
Search: dictionary limits

The dictionary limits safeguard memory, content processing efficiency, and query results.
Number of entries in a 1 million Supported The thesaurus contains

thesaurus synonyms for query terms.
Exceeding this tested limit
may result in increased use
of memory and an increased
query response time.
Number of entries in a 1 million Supported Exceeding this tested limit

custom entity extraction may result in increased use
dictionary of memory, slower indexing,
and an increased query
response time.
Number of entries in a 5,000 terms per tenant Boundary This limits the number of
custom search dictionary terms allowed for inclusions
and exclusions dictionaries
for query spelling correction
and company extraction.
You can store more terms
than this limit in the
Termstore, but search only
uses 5000 terms per tenant.
Search: schema limits
The schema limits safeguard memory resources and keep the management operation overhead at an acceptable
level.
Crawled properties 500,000 per Search service Supported The contents and metadata
application of the items that you crawl
are represented as crawled
properties. You can map
these crawled properties to
managed properties. If the
number of crawled
properties exceeds this
supported limit, this reduces
indexing speed.
Managed properties 50,000 per Search service Supported Search uses managed
application propertied in queries.
Crawled properties are
mapped to managed
properties. Exceeding the
supported limit for managed
properties reduces indexing
speed.
Managed property 100 per managed property Supported Crawled properties can be
mappings mapped to managed
properties. Exceeding this
limit might decrease crawl
speed and query
performance.
Values per managed 1,000 Boundary A managed property can

property have multiple values of the
same type. This is the
maximum number of values
per managed multi-valued
managed property per
document. If this number is
exceeded, the remaining
values are discarded.
Metadata properties 100,000 per crawled item Supported This is the maximum
recognized number of metadata
properties that the crawl
component can determine
when crawling an item.
These metadata properties
can be mapped or used for
queries. Approaching this
number of crawled
properties might result in a
low crawl rate.
Search: crawl limits
Start addresses 500 per content source Supported

Length of machine host 15 characters Threshold NetBIOS limits the maximum

name machine host name length
to this value.
Crawl databases 15 per Search service Supported

application
Search: query and result limits

The limits for queries and results safeguard the search engine against executing very large query expressions and
returning very large result sets. Preventing the search engine from executing very large query expressions and
returning very large result sets prevents Denial-of-service (DoS ) attacks and makes sure that results return timely.
If you have to retrieve more results we recommend that you use paging.
Text length for queries using 4 KB (4,096 characters) Supported This is the tested and default
Keyword Query Language value for the maximum text
length for a query built by
using Keyword Query
Language, except for
Discovery queries. For
Discovery queries 16 KB
(16,384 characters) is the
default maximum value.
The default value for the
maximum text length can be
increased up to the
boundary of 20 KB (20,480)
for all query types.
Text length for queries on 16 KB (16,384 characters) Supported This limit applies to
the SharePoint home page SharePoint Server 2019
Public Preview only. This is
the tested and default value
for the maximum text length
for a query used on the
SharePoint home page. The
default value for the
increased up to the
boundary of 20 KB (20,480).
Number of rows in a result 500 rows Supported This is the tested and default
set value for the maximum
number of rows in a result
set, except for a Discovery
query. For Discovery queries
10,000 rows is the default
value. To display the entire
result set, issue more paging
queries.
You can change the value
for the maximum number of
rows in a result set by using
PowerShell cmdlets to
change the Search service
application property
MaxRowLimit.
MaxRowLimit defines the
maximum value of the query
property RowLimit and the
Discovery query property
RowLimit. RowLimit
defines the number of rows
each page contains in a
result set. You can increase
MaxRowLimit up to 10,000
rows, this is the supported
boundary.
Results removal No limit Supported
Search alert quota 100,000 alerts per Search Supported End-users can set search
service application alerts for the result set of a
query. When the results are
changed or updated, search
notifies the end-user. This is
the tested limit for a Search
service application that has
a mix of end-user queries
(75%) and alert queries
(25%). The limit for a Search
only alert queries is 400,000
alerts. These limits are based
on a system with five
queries per second (QPS).
Search: ranking limits

The ranking limits safeguard application server memory, query latency, and the size of the index.
Ranking models 1,000 per tenant Boundary Approaching this limit can
adversely affect the overall
system performance.
Unique contexts used for 15 unique contexts per rank Boundary This is the maximum
ranking model number of unique contexts
per rank model.
Authoritative pages 1 top level and minimal Supported Use as few second- and
second and third level pages third-level pages as possible
per Search service while still achieving the
application desired relevance.
The boundary is 200
authoritative pages per
relevance level per Search
service application. If you
add more pages, you may
not achieve the desired
relevance. Add the key site
to the first relevance level.
Add more key sites at either
second or third relevance
levels, one at a time.
Evaluate relevance after each
addition to make sure that
you have achieved the
desired relevance effect.
Search: index limits

The index limits safeguard the index from growing out of bounds and exceeding the available resources.
Unique terms in the index 2^31 (>2 billion terms) Boundary This is the maximum
number of unique terms
that can exist in the index of
a Search service application.
User defined full text indexes 10 Boundary This is the maximum

number of full text indexes.
Indexed items 20 million per index Supported Each index partition contains
partition a subset of the whole search
index. If the number of
indexed items is high in
relation to how much
memory the server has, this
affects the query response
time negatively.
User Profile Service limits
The following table lists the recommended guidelines for User Profile Service.

User profiles 2,000,000 per service Supported A user profile service

application application can support up
to 2 million user profiles
with full social features
functionality. This number
represents the number of
profiles that can be
imported into the people
profile store from a directory
service, and also the number
of profiles a user profile
service application can
support without leading to
performance decreases in
social features.
Social tags, notes and 500,000,000 per social Supported Up to 500 million total social
ratings database tags, notes and ratings are
supported in a social
database without significant
decreases in performance.
However, database
maintenance operations
such as backup and restore
may show decreased
performance at that point.
Content deployment limits
The following table lists the recommended guidelines for content deployment.
Content deployment jobs 20 Supported For concurrently running

running on different paths jobs on paths that are
connected to site collections
in the same source content
database, there is an
increased risk of deadlocks
on the database. For jobs
that must run concurrently,
move the site collections
into different source content
databases.
> [!NOTE]> Concurrent
running jobs on the same
path are not possible. If you
are using SQL Server
snapshots for content
deployment, each path
creates a snapshot. This
increases the I/O
requirements for the source
database.
For more information, see
About deployment paths
and jobs.
Blog limits
The following table lists the recommended guidelines for blogs.
Blog posts 5,000 per site Supported The maximum number of

blog posts is 5,000 per site.
Comments 1,000 per post Supported The maximum number of

comments is 1,000 per post.
Business Connectivity Services limits
The following table lists the recommended guidelines for Business Connectivity Services.
ECT (in-memory) 5,000 per web server (per Boundary Total number of external
tenant) content type (ECT)
definitions loaded in
memory at a given point in
time on a web server.
External system connections 500 per web server Boundary Number of active/open
external system connections
at a given point in time. The
default maximum value is
200; the boundary is 500.
This limit is enforced at the
web server scope, regardless
of the kind of external
system (for example,
database, .NET assembly,
and so on) The default
maximum is used to restrict
the number of connections.
An application can specify a
larger limit via execution
context; the boundary
enforces the maximum even
for applications that do not
respect the default.
Database items returned per 2,000 per database Threshold Number of items per
request connector request the database
connector can return.
The default maximum of
2,000 is used by the
database connector to
restrict the number of result
that can be returned per
page. The application can
specify a larger limit via
execution context; the
Absolute Max enforces the
maximum even for
applications that do not
respect the default. The
boundary for this limit is
1,000,000.
Response latency 600 seconds Threshold Timeout used by the

external data connector per
request. The default value is
180 seconds, but
applications can be
configured to specify a
larger value up to the
maximum of 600 seconds.
Service response size 150,000,000 bytes Threshold The upper volume of data
per request the external
data connector can return.
The default value is
3,000,000 bytes, but
applications can be
maximum of 150,000,000
bytes.
Filter Descriptor (in-store) 200 per ECT method Boundary The maximum number of
Filter Descriptors per ECT
method is 200.
ECT Identifier (in-store) 20 per ECT Boundary The maximum number of

identifiers per ECT is 20.
Database Item 1,000,000 per request Threshold The default maximum

number of items per request
the database connector can
return is 2,000, and the
absolute maximum is
1,000,000.
The default max is used by
the database connector to
restrict the number of
results that can be returned
per page. The application
can specify a larger limit via
absolute max enforces the
allowed maximum even for
respect the default such as
indexing.
Workflow limits
The following table lists the recommended guidelines for workflow.

Workflow postpone 15 Threshold 15 is the maximum number

threshold of workflows allowed to be
executing against a content
database at the same time,
excluding instances that are
running in the timer service.
When this threshold is
reached, new requests to
activate workflows will be
queued to be run by the
workflow timer service later.
As non-timer execution is
completed, new requests will
count against this threshold.
This is limit can be
configured by using the Set-
SPFarmConfig PowerShell
cmdlet. For more
SPFarmConfig.
Note: This limit does not
refer to the total number of
workflow instances that can
be in progress. Instead, it is
the number of instances
that are being processed.
Increasing this limit
increases the throughput of
starting and completing
workflow tasks but also
increases load against the
content database and
system resources.
Workflow timer batch size 100 Threshold The number of events that
each run of the workflow
timer job will collect and
deliver to workflows. It is
configurable by using
PowerShell. To allow for
additional events, you can
run additional instances of
the SharePoint Foundation
Workflow Timer Service.
Workflow associations 100 per list Supported Exceeding this limit will
degrade browser
performance due to the
large volume of data that is
loaded for more than 100
associations and their status
columns.
List items or documents 5,000 items Supported Testing has verified that all
that can be bulk created or workflow activation events
uploaded to start workflow are processed for an on-
instances item-creation workflow
association when up to
5,000 items are created in a
single bulk upload.
Exceeding this limit could
cause workflow initiation to
time out.
Published workflow 1,000 per web site Supported The maximum supported
definitions per web site number of published
workflow definitions per web
site is 1,000.
Total workflow associations 1,799 per site Boundary The Service Bus supports a
per site maximum of 1,799
subscriptions per scope. This
maximum value includes the
sum of both published and
unpublished associations.
Maximum workflow 5,120 KB Boundary Attempts to publish xaml

definition (xaml) size files that exceed the size
limit will fail.
Maximum depth of a 121 levels Boundary There is a hard limit of 125

workflow sub-step in xaml for node depth in xaml. The
(workflow complexity) maximum value of 121
levels accounts for the
default activities (stage,
sequence, etc.) that
SharePoint Designer inserts
automatically.
Workflow instance 6 per second Threshold Testing has confirmed that a

activations per second per SharePoint web server can
web server activate a maximum of 6
workflow instances per
second. This number is
cumulative, and therefore
scales with the number of
web servers in the farm. For
example, 2 web servers can
activate 12 workflow
instances per second, and 3
web servers can activate 18.
Rest calls from SharePoint 60 per second Supported Testing has confirmed that a
workflow per second per SharePoint web server can
web server effectively process up to 60
rest calls per second from
SharePoint workflow. If this
level of volume will be
exceeded, we recommend
that an additional load-
balanced web server be
added to the SharePoint
farm.In testing, 120 rest calls
per second against a single
web server resulted in
sustained 90-100% CPU
utilization. Adding a second
web server reduced CPU
utilization to 30-40% on
both servers. Adding a third
web server enabled
processing of 180 calls per
second, with 30-40% CPU
utilization on all three
servers, and so on. The
servers used for this test
were Hyper-V virtual
machines with 16 core
processor and 24 GBs RAM
each.
Workflow variable value size 256 KB Boundary The maximum amount of

data that can be stored in a
single workflow variable is
256 KB. Exceeding this limit
will cause the workflow
instance to terminate.
Maximum list size for 5,000 items per list view Threshold This limit is a result of the
workflow lookups to non- maximum view size limit.
indexed fields When this limit is exceeded,
workflow lookups to non-
indexed fields will fail for
non-administrative users. At
this threshold, an index
must be created for the field,
in order for workflows to be
able to successfully perform
lookups against the field.
Maximum list size for auto- 10 million items per list Supported Testing has confirmed that
start workflow associations the performance of auto-
start workflow associations
is not affected when list size
grows to 1 million
items.Because response time
doesn't change as list size
scales, the effective limit is
the same as the maximum
number of items in a non-
workflow list.
Managed Metadata term store (database) limits
The following table lists the recommended guidelines for managed metadata term stores.
Maximum number of levels 7 Supported Terms in a term set can be

of nested terms in a term represented hierarchically. A
store term set can have up to
seven levels of terms (a
parent term, and six levels of
nesting below it.)
Maximum number of term 1,000 Supported You can have up to 1,000

sets in a term store term sets in a term store.
Maximum number of terms 30,000 Supported 30,000 is the maximum

in a term set number of terms in a term
set.
> [!NOTE]> Additional labels
for the same term, such as
synonyms and translations,
do not count as separate
terms.
Total number of items in a 1,000,000 Supported An item is either a term or a

term store term set. The sum of the
number of terms and term
sets cannot exceed
1,000,000. Additional labels
for the same term, such as
synonyms and translations,
do not count as separate
terms.
> [!NOTE]> You cannot
have both the maximum
number of term sets and the
maximum number of terms
simultaneously in a term
store.
Number of Variation Labels 209 per term store Supported The maximum number of
Variation Labels per term
store is 209.
Number of terms in 2,000 Supported The maximum supported

managed navigation term number of terms in a
set managed navigation term
set is 2,000.
Number of direct child- 300 Supported The maximum supported

terms in managed number of direct child-terms
navigation term set in a managed navigation
term set is 300.
Visio Services limits
The following table lists the recommended guidelines for instances of Visio Services in SharePoint Server 2016.
File size of Visio web 50 MB Threshold Visio Services has a

drawings configuration setting that
enables the administrator to
change the maximum size of
web drawings that Visio
processes.
Larger file sizes have the
following side effects:
Increase in the memory
footprint of Visio Services.
Increase in CPU usage.
Reduction in application
server requests per second.
Increase overall latency.
Increase SharePoint farm
network load
Visio web drawing 120 seconds Threshold Visio Services has a

recalculation time-out configuration setting that
change the maximum time
that it can spend
recalculating a drawing after
a data refresh.
A larger recalculation time-
out leads to:
Reduction in CPU and
memory availability.
requests per second.
Increase in average latency
across all documents.
A smaller recalculation time-
out leads to:
Reduction of the complexity
of diagrams that can be
displayed.
Increase in requests per
second.
Decrease in average latency
Visio Services minimum Minimum cache age: 0 to Threshold Minimum cache age applies
cache age (data connected 24hrs to data connected diagrams.
diagrams) It determines the earliest
point at which the current
diagram can be removed
from cache.
Setting Min Cache Age to a
very low value will reduce
throughput and increase
latency, because invalidating
the cache too often forces
Visio to recalculate often
and reduces CPU and
Visio Services maximum Maximum cache age: 0 to Threshold Maximum cache age applies
cache age (non-data 24hrs to non-data connected
connected diagrams) diagrams. This value
determines how long to
keep the current diagram in
memory.
Increasing Max Cache Age
decreases latency for
commonly requested
drawings.
However, setting Max Cache
Age to a very high value
increases latency and slows
throughput for items that
are not cached, because the
items already in cache
consume and reduce
available memory.
PerformancePoint Services limits
The following table lists the recommended guidelines for PerformancePoint Services in SharePoint Server 2016.
Cells 1,000,000 per query on Boundary A PerformancePoint

Excel Services data source scorecard that calls an Excel
Services data source is
subject to a limit of no more
than 1,000,000 cells per
query.
Columns and rows 15 columns by 60,000 rows Threshold The maximum number of
columns and rows when
rendering any
PerformancePoint
dashboard object that uses
a Excel workbook as a data
source. The number of rows
could change based on the
number of columns.
Query on a SharePoint list 15 columns by 5,000 rows Supported The maximum number of
columns and row when
rendering any
PerformancePoint
a SharePoint list as a data
number of columns.
Query on a SQL Server data 15 columns by 20,000 rows Supported The maximum number of
source columns and row when
rendering any
PerformancePoint
a SQL Server table data
number of columns.
Word Automation Services limits
The following table lists the recommended guidelines for Word Automation Services.
Input file Size 512 MB Boundary Maximum file size that can
be processed by Word
Automation Services.
Frequency with which to 1 minute (recommended) Threshold This setting determines how
start conversions (minutes) 15 minutes (default) often the Word Automation
59 minutes (boundary) Services timer job executes.
A lower number leads to the
timer job running faster. Our
testing shows that it is most
useful to run this timer job
once per minute.
Number of conversions to For PDF/XPS output Threshold The number of conversions

start per conversion process formats: 30 x MFor all other to start affects the
output formats: 72 x M throughput of Word
Where M is the value of Automation Services.
Frequency with which to If these values are set higher
start conversions (minutes) than the recommended
levels then some conversion
items may start to fail
intermittently and user
permissions may expire.
User permissions expire 24
hours from the time that a
conversion job is started.
Conversion job size 100,000 conversion items Supported A conversion job includes
one or more conversion
items, each of which
represents a single
conversion to be performed
on a single input file in
SharePoint. When a
conversion job is started
(using the
ConversionJob.Start
method), the conversion job
and all conversion items are
transmitted over to an
application server which
then stores the job in the
Word Automation Services
database. A large number of
conversion items will
increase both the execution
time of the Start method
and the number of bytes
transmitted to the
application server.
Total active conversion N-1, where N is the number Threshold An active conversion process
processes of cores on each application can consume a single
server processing core. Therefore,
customers should not run
more conversion processes
than they have processing
cores in their application
servers. The conversion
timer job and other
SharePoint activities also
require occasional use of a
processing core.
We recommend that you
always leave 1 core free for
use by the conversion timer
job and SharePoint.
Word Automation Services 2 million conversion items Supported Word Automation Services
database size maintains a persistent queue
of conversion items in its
database. Each conversion
request generates one or
more records.
does not delete records
from the database
automatically, so the
database can grow
indefinitely without
maintenance. Administrators
can manually remove
conversion job history by
using the PowerShell cmdlet
Remove-
SPWordConversionServiceJo
bHistory. For more
information, see Remove-
bHistory.
Machine Translation Service limits
The following table lists the recommended guidelines for the Machine Translation Service.
Input file size for binary files 524,288 KB per file Threshold Files larger than the limit
take too long to transfer
and process, decreasing the
throughput of the service.
Input file size for text files 15,360 KB per file Threshold Files larger than the limit
have too much text to
translate, decreasing the
Maximum character count 10,000,000 per document Threshold Documents with more
for Microsoft Word characters than the limit
Documents have too much text to
Total concurrent translation 5 Threshold Using more processes than

processes the limit does not increase
throughput because there is
a limit to how much text can
be translated at a time.
Using more processes
increases the demands on
the server resources.
Delay between translations 59 minutes Threshold Starting translations at a

larger interval than the limit
causes the time taken to
translate documents to
grow too large and can
cause the number of queued
translations to grow too
large.
Number of translations per 1,000 per process Threshold Starting more translations
translation process than the limit causes
translations to fail due to
timing out because they
cannot be processed before
the timeout period.
Maximum concurrent 300 Threshold More than 300 concurrent

translation requests translation requests could
cause translations to time
out because requests are
queued for longer than the
timeout period.
Files per translation job 100,000 files Supported Submitting jobs with a
number of files that exceeds
the limit causes job
submittal time and
processing time to be too
long.
Machine Translation Service 1,000,000 files Supported Operations to maintain the

database size queue of jobs become slow
if the database grows
beyond the maximum
number of files in the
database.
Office Online Service limits
The following table lists the recommended guidelines for Office Online. Office client application limits also apply
when an application is running as a web app.
Cache size 100 GB Threshold Space available to render

documents, created as part
of a content database. By
default, the cache available
to render documents is 100
GB. We do not recommend
that you increase the
available cache.
Renders One per document per Boundary This is the measured

second per CPU core per average number of renders
application server that can be performed of
(maximum eight cores) "typical" documents on the
application server over a
period of time.
OneNote concurrent merge 8 per document Threshold OneNote merges combine

operations changes from multiple users
who are co-authoring a
notebook. If too many
concurrent merges are
already in progress, a
conflict page is generated
instead, which forces the
user to perform the merge
manually.
Project Server limits
The following table lists the recommended guidelines for Project Server. For more information about how to plan
for Project Server, see Planning and architecture for Project Server 2010.
End of project time Date: 12/31/2149 Boundary Project plans cannot extend
past the date 12/31/2149.
Deliverables per project plan 1,500 deliverables Boundary Project plans cannot contain
more than 1,500
deliverables.
Number of fields in a view 256 Boundary A user cannot have more

than 256 fields added to a
view that they have defined
in Project Web App.
Number of clauses in a filter 50 Boundary A user cannot add a filter to

for a view a view that has more than
50 clauses in it.
SharePoint Apps limits
The following table lists the recommended guidelines for apps for SharePoint.
Maximum 100 Mb Boundary 100 MB is the limit for an

Access/SharePoint App app package created in the
Package size Access client.
> [!NOTE]> Access
compresses the database
when it creates the app
package, so the app package
may include more than 100
MB of data.
Maximum Access app 1 Gb Boundary Each Access app created on

database storage size in SQL SharePoint Online creates a
Azure database on SQL Azure. 1
GB is the limit for the
database storage on SQL
Azure. In an on-premise
installation, the
administrator controls the
size of the associated SQL
database.
Apps displayed in Manage 2,000 Boundary Up to 2,000 apps

Licenses page (purchased from the store)
can be displayed on the
Manage Licenses page. You
can still manage the license
of any app by going to the
All Site Contents page of the
site where the app is
installed and clicking on
Licenses, or by searching for
the app using Marketplace
Search.
Number of app licenses per 1,000,000 Supported The maximum supported

tenant number of licenses
(purchase of apps from the
store) for a single SharePoint
deployment, either on-
premises or SharePoint
Online. Exceeding this limit
might cause severe
performance degradation.
Number of apps displayed in 240 Boundary After this limit is reached,

the Add an App page only the first 240 apps are
displayed, and a message
guiding you to search to
find your app is displayed.
Number of managers per 30 Boundary Only 30 people can manage

app license a license. License managers
can add or remove users or
delete a license.
Number of app licenses 2,000 Boundary When more than 2,000

assigned to a user viewable licenses are assigned to a
by that user user, that user will no longer
see any apps in the default
Add an App view. Instead, a
message guiding you to
search the app catalog or
the SharePoint Store will
appear.
Number of apps in the 500 Boundary When more than 500 apps
corporate catalog viewable from the corporate catalog
by a single user are available to a single user,
that user will no longer see
any apps in the default Add
an App view. Instead, a
appear.
Distributed cache service limits
The following table lists the recommended guidelines for the distributed cache service.
Number of followable 400,000 Supported The total number of entities

entities (users, documents, that can be followed by a
sites and hashtags) per single user on a distributed
cache host cache host with 16GB RAM
assigned to the distributed
cache service is 400,000.
Number of cache hosts in a 16 Boundary The total number of cache

cluster hosts a single distributed
cache cluster can support is
16.
Maximum amount of 16GB Boundary The total amount of

memory dedicated to a memory that can be
cache host dedicated to the distributed
cache service on any one
cache host in a cluster is
16GB.
Miscellaneous limits
The following table lists limits and recommended guidelines for services and features not covered in other
sections.
Number of User agent 150 Boundary The maximum number of

substrings per device user agent substrings per
channel mobile device channel is
150.
Number of SharePoint 100 Boundary The maximum number of

sources per EDiscovery case SharePoint sources that can
be added to an EDiscovery
case is 100.
Number of Exchange 1,500 Boundary The maximum number of

sources (mailboxes) per Exchange sources
EDiscovery case (mailboxes) per EDiscovery
case is 1,500.
Maximum size of EDiscovery 16K characters or 500 Boundary The size of an EDiscovery
Query keywords query is limited to 500
keywords or 16,000
characters, whichever is
reached first.
Related Topics
Hardware and software requirements for SharePoint Server 2016
SharePoint Server 2010 capacity management: Software boundaries and limits
Prerequisites for SharePoint Servers 2016 and 2019

The following downloadable resources, articles, video recordings, and related resources provide information
about how to prepare for SharePoint Server installation and initial configuration.
CONTENT DESCRIPTION
Initial deployment administrative and service accounts in Provides information about the administrative and service
SharePoint Server accounts that are required for an initial SharePoint Server
installation.
Account permissions and security settings in SharePoint Describes SharePoint Server administrative and services
Server 2016 account permissions. This article discusses the following areas:
Microsoft SQL Server, the file system, file shares, and registry
entries.
Install prerequisites for SharePoint Server from a network Describes how to install SharePoint Server prerequisites from
share an offline shared network location using the prerequisite
installer (PrerequisiteInstaller.exe) tool.
Initial deployment administrative and service
accounts in SharePoint Server

This article provides information about the administrative and service accounts that you need for an
initial SharePoint Server deployment. Additional accounts and permissions are required to fully
implement all aspects of a production farm.
NOTE
For a complete list of permissions for SharePoint Servers 2016 and 2019, see Account permissions and security
settings in SharePoint Servers 2016 and 2019. > For a complete list of permissions for SharePoint Server 2013,
see Account permissions and security settings in SharePoint 2013.
IMPORTANT
Do not use service account names that contain the symbol $ with the exception of using a Group Managed
Service Account for SQL Server.
Required accounts in SharePoint Server

To deploy SharePoint Server on a server farm, you must provide credentials for several different
accounts.
The following table describes the accounts that you can use to install and configure SharePoint Server.
SQL Server service account The SQL Server service account is Use either a domain user account or
used to run SQL Server. It is the preferably, a Group Managed
service account for the following Service Account.
SQL Server services: If you plan to back up to or restore
MSSQLSERVER from an external resource,
SQLSERVERAGENT permissions to the external resource
If you do not use the default SQL must be granted to the appropriate
Server instance, in the Windows account. If you use a domain user
Services console, these services will account or Group Managed Service
be shown as the following: Account for the SQL Server service
MSSQL<InstanceName> account, grant permissions to that
SQLAgent<InstanceName> 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 SQL Server was
installed.
Farm administrator user account The farm administrator user account Domain user account.
is a uniquely identifiable account Member of the Administrators
assigned to a SharePoint group on each SharePoint server in
administrator. It is used to run the the farm.
following: Member of the following SQL Server
Setup role (optional): sysadmin fixed
SharePoint Products Configuration server role.
Wizard 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 or a member of the
sysadmin fixed server role on SQL.
perform the following tasks: Additional permissions are
Act as the application pool identity automatically granted for the server
for the SharePoint Central farm account on Web servers and
Administration website. application servers that are joined
Run the Microsoft SharePoint to a server farm.
Foundation Workflow Timer Service. 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:
* db_owner fixed database role for
all SharePoint databases in the
server farm
NOTE
We recommend that you install SharePoint Server by using least-privilege administration.
Account permissions and security settings in

This article describes SharePoint administrative and services account permissions for the following areas:
Microsoft SQL Server, the file system, file shares, and registry entries.
IMPORTANT
Do not use service account names that contain the symbol $.
About account permissions and security settings in SharePoint Servers

2016 and 2019
The SharePoint Products Configuration Wizard (Psconfig) and the Farm Configuration Wizard, both of which are
run during a complete installation, configure many of the SharePoint baseline account permissions and security
settings.
Service account recommendations

The following sections describe recommendations on SharePoint Service accounts.
Service account recommendations
Microsoft recommends using a minimal number of Service Application Pool accounts in the farm. This is to
reduce memory usage and increase performance while maintaining the appropriate level of security.
Use an elevated, personally identifiable account for SharePoint installation, maintenance, and upgrades.
This account will hold the roles required as outlined by the SharePoint Farm Administrator account
outlined below. Each SharePoint administrator should use a separate account to clearly identify activity
performed by the administrator on the farm.
If possible use a security group, SharePoint Farm Administrators Groups, to unify all individual
SharePoint Farm Administrator accounts and grant permissions as outlined below. This simplify the
management of the SharePoint Farm Administrator accounts significally.
The SharePoint Farm Service account should only run the SharePoint Timer service, SharePoint
Inights (if applicable), the IIS Application Pools for Central Administration, SharePoint Web Services
System (used for the topology service), and SecurityTokenServiceApplicationPool (used for the Security
Token Service).
A single account should be used for all Service Applications, named Service Application Pool account.
This allows the administrator to use a single IIS Application Pool for all Service Applications. In addition,
this account should run the following Windows Services: SharePoint Search Host Controller, SharePoint
Server Search, and Distributed Cache (AppFabric Caching Service).
A single account should be used for all Web Applications, named Web Application pool account. This
allows the administrator to use a single IIS Application Pool for all Web Applications. The exception is the
Central Administration Web Application, which as noted above, is run by the SharePoint farm service
account.
With the exception of the Claims to Windows Token Service account, no Service Application Pool account
should have Local Administrator access to any SharePoint server, nor any elevated SQL Server role, for
example, the sysadmin fixed role. The SharePoint Farm Administrator account will require the dbcreator
and securityadmin fixed roles unless you pre-provision SharePoint databases and manually assign
permissions to each database.
Service Application Pool accounts, with the exception of the account running the Claims to Windows
Token Service, should have Deny logon locally and Deny logon through Remote Desktop Services in the
Local Security Policy\User Rights Assignment. This is set via secpol.msc.
Use separate accounts for the Content access (Search crawler), Portal Super Reader, Portal Super
User, and User Profile Service Application Synchronization, if applicable.
The Claims to Windows Token Service account is a highly privledged account on the farm. Prior to
deploying this service, verify it is required. If required, use a separate account for this service.
Service accounts recommendations overview
SERVICE ACCOUNT NAME WHAT IS IT USED FOR? HOW MANY SHOULD BE USED?
SharePoint Farm Administrator account Personally identifiable account for a 1-n

SharePoint Administrator
SharePoint Farm Service Account Timer Service, Insights, IIS App for CA, 1
SP Web Services System, Security
Token Service App Pool
Default content access account search crawling internal and external 1-n
sources SP2016
Content access accounts search crawling internal and external 1-n

sources SP2016 and SP2019
Web Application Pool account All Web Applications without Central 1

Administration
SharePoint Service Application Pool All Service Applications 1

account
Portal Super Reader Object caching 1
Portal Super User Object caching 1
User Profile Service Application Used for Active Directory Import 1-n
Synchronization
SharePoint administrative accounts

One of the following SharePoint components automatically configures most of the SharePoint administrative
account permissions during the setup process:
The SharePoint Products Configuration Wizard (Psconfig).
The Farm Configuration Wizard.
The SharePoint Central Administration website.
Microsoft PowerShell.
SharePoint Farm Administrator account
This account is used to set up each server in your farm by running the SharePoint Products Configuration
Wizard, the initial Farm Configuration Wizard, and PowerShell. For the examples in this article, the SharePoint
Farm Administrator account is used for farm administration, and you can use Central Administration to manage
it. Some configuration options, for example, configuration of the SharePoint Server Search query server, require
local administration permissions. The SharePoint Farm Administrator account requires the following
permissions:
It must have domain user account permissions.
It must be a member of the local Administrators group on each server in the SharePoint farm.
This account must have access to the SharePoint databases.
If you use any PowerShell operations that affect a database, the SharePoint Farm Administrator account
must be a member of the db_owner role.
This account must be assigned to the securityadmin and dbcreator SQL Server security roles during setup
and configuration.
NOTE
The securityadmin and dbcreator SQL Server security roles might be required for this account during a complete version-
to-version upgrade because new databases might have to be created and secured for services.
After you run the configuration wizards, machine-level permissions for the SharePoint Farm Administrator
account include:
Membership in the WSS_ADMIN_WPG Windows security group.
After you run the configuration wizards, database permissions include:
db_owner on the SharePoint server farm configuration database.
db_owner on the SharePoint Central Administration content database.
Cau t i on
If the account that you use to run the configuration wizards does not have the appropriate special SQL Server
role membership or access as db_owner on the databases, the configuration wizards will not run correctly.
SharePoint Farm Service account
The SharePoint Farm service account, which is also referred to as the database access account, is used as the
application pool identity for Central Administration and as the process account for the SharePoint Timer Service.
The server farm account requires the following permissions:
It must have domain user account permissions.
Additional permissions are automatically granted to the SharePoint Farm Service account on SharePoint servers
that are joined to a server farm.
After you run Setup, machine-level permissions include:
Membership in the WSS_ADMIN_WPG Windows security group for the SharePoint Timer Service.
Membership in WSS_RESTRICTED_WPG for the Central Administration and Timer service application
pools.
Membership in WSS_WPG for the Central Administration application pool.
After you run the configuration wizards, SQL Server and database permissions include:
Dbcreator fixed server role.
Securityadmin fixed server role.
db_owner for all SharePoint databases.
Membership in the WSS_CONTENT_APPLICATION_POOLS role for the SharePoint server farm
configuration database.
Membership in the WSS_CONTENT_APPLICATION_POOLS role for the SharePoint_Admin content
database.
SharePoint Application Pool accounts

This section describes the SharePoint Application Pool accounts that are set up by default during installation.
Default content access account
IMPORTANT
Information in this section applies to SharePoint Server 2016 only.
The default content access account is used within a specific service application to crawl content, unless a different
authentication method is specified by a crawl rule for a URL or URL pattern. This account requires the following
permission configuration settings:
The default content access account must be a domain user account that has read access to external or
secure content sources that you want to crawl by using this account.
For SharePoint Server sites that are not part of the server farm, you have to explicitly grant this account
full read permissions to the web applications that host the sites.
This account must not be a member of the Farm Administrators group.
Content access accounts
IMPORTANT
Information in this section applies to SharePoint Servers 2016 and 2019 only.
Content access accounts are configured to access content by using the Search administration crawl rules feature.
This type of account is optional, and you can configure it when you create a new crawl rule. For example, external
content (such as a file share) might require this separate content access account. This account requires the
following permission configuration settings:
The content access account must have read access to external or secure content sources that this account
is configured to access.
Web Application Pool account
The Web Application Pool account must be a domain user account. This account must not be a member of the
Farm Administrators group.
This account should b used for all web applications without Central Administration.
The following machine-level permission is configured automatically: This account is a member of WSS_WPG.
The following SQL Server and database permissions are configured automatically:
This account is assigned to the WSS_CONTENT_APPLICATION_POOLS role that is associated with the
farm configuration database.
SharePoint Admin content database.
The application pool accounts for web applications are assigned to the SPDataAccess role for the content
databases
SharePoint Service Application Pool account
The SharePoint Service Application Pool account must be a domain user account. This account must not be a
member of the Administrators group on any computer in the server farm.
The following machine-level permission is configured automatically: This account is a member of WSS_WPG.
This account is assigned to the SPDataAccess role for the content databases.
This account is assigned to the SPDataAccess role for search database that is associated with the web
application.
This account must have read and write access to the associated service application database.
SharePoint_Admin content database.
SharePoint database roles

This section describes the database roles that installation sets up by default or that you can configure optionally.
WSS_CONTENT_APPLICATION_POOLS database role
The WSS_CONTENT_APPLICATION_POOLS database role applies to the application pool account for each web
application that is registered in a SharePoint farm. This enables web applications to query and update the site
map and have read-only access to other items in the configuration database. Setup assigns the
WSS_CONTENT_APPLICATION_POOLS role to the following databases:
The SharePoint Config database (the configuration database)
The SharePoint Admin Content database
Members of the WSS_CONTENT_APPLICATION_POOLS role have the execute permission for a subset of the
stored procedures for the database. In addition, members of this role have 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 these databases is automatically configured. In some cases, limited access to write to
a database is also automatically configured. To provide this access, permissions for stored procedures are
configured.
SharePoint_SHELL_ACCESS database role
The secure SharePoint_SHELL_ACCESS database role on the configuration database replaces the need to add an
administration account as a db_owner on the configuration database. By default, the setup account is assigned
to the SharePoint_SHELL_ACCESS database role. You can use a PowerShell command to grant or remove
memberships to this role. Setup assigns the SharePoint_SHELL_ACCESS role to the following databases:
The SharePoint_Config database (the configuration database).
One or more of the SharePoint Content databases. This is configurable by using the PowerShell command
that manages membership and the object that is assigned to this role.
Members of the SharePoint_SHELL_ACCESS role have the execute permission for all stored procedures for the
database. In addition, members of this role have the read and write permissions on all of the database tables.
SPREADONLY database role
The SPREADONLY role should be used for setting the database to read-only mode instead of using sp_dboption.
This role as its name suggests should be used when only read access is required for data such as usage and
telemetry data.
NOTE
The sp_dboption stored procedure is not available in SQL Server 2012. For more information about sp_dboption, see
sp_dboption (Transact-SQL).
The SPREADONLY SQL role will have the following permissions:

Grant SELECT on all SharePoint stored procedures and functions.
Grant SELECT on all SharePoint tables.
Grant EXECUTE on user-defined type where schema is dbo.
SPDataAccess database role
The SPDataAccess role is the default role for database access and should be used for all object model level access
to databases. Add the application pool account to this role during upgrade or new deployments.
NOTE
The SPDataAccess role replaced the db_owner role in SharePoint Server 2016.
The SPDataAccess role will have the following permissions:

Grant EXECUTE or SELECT on all SharePoint stored procedures and functions.
Grant SELECT on all SharePoint tables.
Grant EXECUTE on User-defined type where schema is dbo.
Grant INSERT on AllUserDataJunctions table.
Grant UPDATE on Sites view.
Grant UPDATE on UserData view.
Grant UPDATE on AllUserData table.
Grant INSERT and DELETE on NameValuePair tables.
Grant create table permission.
Group permissions
This section describes permissions of groups that the SharePoint Servers 2016 and 2019 setup and
configuration tools create.
WSS_ADMIN_WPG
WSS_ADMIN_WPG has read and write access to local resources. The application pool accounts for the Central
Administration and Timer services are in WSS_ADMIN_WPG. The following table shows the
WSS_ADMIN_WPG registry entry permissions.
KEY NAME PERMISSIONS INHERIT DESCRIPTION
HKEY_LOCAL_MACHINE\SY Full control Not applicable Not applicable

STEM\CurrentControlSet\Se
rvices\VSS
HKEY_LOCAL_MACHINE\Sof Read, write Not applicable Not applicable

tware\Microsoft\Office\16.0\
Registration{90150000-
110D-0000-1000-
0000000FF1CE}
HKEY_LOCAL_MACHINE\SO Read No This key is the root of the

FTWARE\Microsoft\Office SharePoint Server registry
Server settings tree. If this key is
altered, SharePoint Server
functionality will fail.
HKEY_LOCAL_MACHINE\SO Full control No This key is the root of the

FTWARE\Microsoft\Office SharePoint Server 2016
Server\16.0 registry settings.
HKEY_LOCAL_MACHINE\Sof Read, write No This key contains settings

tware\Microsoft\Office for the document
Server\16.0\LoadBalancerSe conversion service. Altering
ttings this key will break document
conversion functionality.

Server\16.0\LauncherSetting conversion service. Altering
s this key will break document
HKEY_LOCAL_MACHINE\Sof Full control Not applicable Not applicable

tware\Microsoft\Office
Server\16.0\Search
HKEY_LOCAL_MACHINE\Sof Full control Not applicable Not applicable

tware\Microsoft\Shared
Tools\Web Server
Extensions\16.0\Search
HKEY_LOCAL_MACHINE\Sof Full control No This key contains the

tware\Microsoft\Shared connection string and the
Tools\Web Server ID of the configuration
Extensions\16.0\Secure database to which the
machine is joined. If this key
is altered, the SharePoint
Server installation on the
machine will not function.
HKEY_LOCAL_MACHINE\Sof Full control Yes This key contains settings

tware\Microsoft\Shared used during setup. If this
Tools\Web Server key is altered, diagnostic
Extensions\16.0\WSS logging might fail, and
setup or post-setup
configuration might fail.
The following table shows the WSS_ADMIN_WPG file system permissions.
FILE SYSTEM PATH PERMISSIONS INHERIT DESCRIPTION
%AllUsersProfile%\ Full control No This directory contains the

Microsoft\SharePoint file-system-backed cache of
the farm configuration.
Processes might fail to start,
and the administrative
actions might fail if this
directory is altered or
deleted.
C:\Inetpub\wwwroot\wss Full control No This directory (or the

corresponding directory
under the Inetpub root on
the server) is used as the
default location for IIS Web
sites. SharePoint sites will be
unavailable, and
administrative actions might
fail if this directory is altered
or deleted, unless custom
IIS Web site paths are
provided for all IIS Web sites
extended with SharePoint
Server.
%ProgramFiles%\Microsoft Full control No This directory is the

Office Servers\16.0 installation location for
binaries and data. The
directory can be changed
during installation. All
SharePoint Server
functionality will fail if this
directory is removed,
altered, or removed after
installation. Membership in
the WSS_ADMIN_WPG
Windows security group is
required for some
SharePoint Server services
to be able to store data on
disk.
%ProgramFiles%\Microsoft Read, write No This directory is the root

Office directory where back-end
Servers\16.0\WebServices Web services are hosted, for
example, Excel and Search.
The SharePoint Server
features that depend on
these services will fail if this
directory is removed or
altered.
%ProgramFiles%\Microsoft Full control No This directory is the root

Office Servers\16.0\Data location where local data is
stored, including search
indexes. Search functionality
will fail if this directory is
removed or altered.
WSS_ADMIN_WPG
Windows security group
permissions are required to
enable search to save and
secure data in this folder.
%ProgramFiles%\Microsoft Full control Yes This directory is the location

Office Servers\16.0\Logs where the run-time
diagnostic logging is
generated. Logging
functionality will not
function properly if this
altered.
%ProgramFiles%\Microsoft Full control Yes Same as the parent folder.

Office
Servers\16.0\Data\Office
Server
%windir%\System32\drivers Read, write Not applicable Not applicable

\etc\HOSTS
%windir%\Tasks Full control Not applicable Not applicable

%COMMONPROGRAMFILE Modify Yes This directory is the

S%Microsoft Shared\Web installation directory for
Server Extensions\16 core SharePoint Server files.
If the access control list
(ACL) is modified, feature
activation, solution
deployment, and other
features will not function
correctly.
%COMMONPROGRAMFILE Full control Yes This directory contains the

S%\Microsoft Shared\Web SOAP services for Central
Server Administration. If this
Extensions\16\ADMISAPI directory is altered, remote
site creation and other
methods exposed in the
service will not function
correctly.
%COMMONPROGRAMFILE Full control Yes This directory contains files

S%\Microsoft Shared\Web used to extend IIS Web sites
Server with SharePoint Server. If
Extensions\16\CONFIG this directory or its contents
are altered, web application
provisioning will not
function correctly.
%COMMONPROGRAMFILE Full control No This directory contains

S%\Microsoft Shared\Web setup and runtime tracing
Server Extensions\16\LOGS logs. If the directory is
altered, diagnostic logging
will not function correctly.
%windir%\temp Full control Yes This directory is used by

platform components on
which SharePoint Server
depends. If the access
control list is modified, Web
Part rendering and other
deserialization operations
might fail.
%windir%\System32\logfiles Full control No This directory is used by

\SharePoint SharePoint Server usage
logging. If this directory is
modified, usage logging will
not function correctly.This
registry key applies only to
SharePoint Server.
%systemdrive\program Full control Not applicable This permission is granted

files\Microsoft Office for a %systemdrive\program
Servers\16 folder on Index files\Microsoft Office
servers Servers\16 folder on Index
servers.
WSS_WPG
WSS_WPG has read access to local resources. All application pool and services accounts are in WSS_WPG. The
following table shows WSS_WPG registry entry permissions.

FTWARE\Microsoft\Office SharePoint Server registry
Server\16.0 settings.

tware\Microsoft\Office for the SharePoint Server
Server\16.0\Diagnostics diagnostic logging. Altering
this key will break the
logging functionality.


HKEY_LOCAL_MACHINE\Sof Read No This key contains the

Server 2016 installation on
the machine will not
function.
HKEY_LOCAL_MACHINE\Sof Read Yes This key contains settings

tware\Microsoft\Shared that are used during setup.
Tools\Web Server If this key is altered,
Extensions\16.0\WSS diagnostic logging might fail
and setup or post-setup
configuration mightay fail.
The following table shows the WSS_WPG file system permissions.
%AllUsersProfile%\ Read No This directory contains the

Processes might fail to start
deleted.
C:\Inetpub\wwwroot\wss Read, execute No This directory (or the

unavailable and
Server.
%ProgramFiles%\Microsoft Read, execute No This directory is the

Office Servers\16.0 installation location for the
SharePoint Server binaries
and data. It can be changed
SharePoint Server
altered, or moved after
installation. WSS_WPG read
and execute permissions are
required to enable IIS sites
to load SharePoint Server
binaries.
%ProgramFiles%\Microsoft Read No This directory is the root

The SharePoint Server
altered.
%ProgramFiles%\Microsoft Read, write Yes This directory is the location

Office Servers\16.0\Logs where the runtime
generated. Logging
altered.
%COMMONPROGRAMFILE Read Yes This directory contains the

correctly.
%COMMONPROGRAMFILE Read Yes This directory contains files

Server with SharePoint Server . If
Extensions\16\CONFIG this directory or its contents
are altered, web application
function correctly.
%COMMONPROGRAMFILE Modify No This directory contains

S%\Microsoft Shared\Web setup and runtime tracing
%windir%\temp Read Yes This directory is used by

Part rendering, and other
might fail.
%windir%\System32\logfiles Read No This directory is used by

not function correctly.The
SharePoint Server.
%systemdrive\program Read, execute Not applicable The permission is granted

files\Microsoft Office for %systemdrive\program
Servers\16 files\Microsoft Office
Servers\16 folder on Index
servers.
Local service
The following table shows the local service registry entry permission:
HKEY_LOCAL_MACHINE\Sof Read No This key contains settings

The following table shows the local service file system permission:

%ProgramFiles%\Microsoft Read, execute No This directory is the installed

Office Servers\16.0\Bin location of the SharePoint
Server binaries. All the
SharePoint Server
altered.
Local system
The following table shows the local system registry entry permissions:

conversion functionality.This
SharePoint Server.


tware\Microsoft\Shared encryption key that is used
Tools\Web Server to store secrets in the
Extensions\16.0\Secure\Far configuration database. If
mAdmin this key is altered, service
provisioning and other
features will fail.

The following table shows the local file system permissions:

and administrative actions
might fail if this directory is
altered or deleted.

unavailable and
Server.

correctly.
%COMMONPROGRAMFILE Full control Yes If this directory or its

S%\Microsoft Shared\Web contents are altered, Web
Server Application provisioning will
Extensions\16\CONFIG not function correctly.

S%\Microsoft Shared\Web setup and run-time tracing

might fail.

\SharePoint SharePoint Server for usage
SharePoint Server.
Network service
The following table shows the network service registry entry permission:
HKEY_LOCAL_MACHINE\Sof Read Not applicable Not applicable

Server\16.0\Search\Setup
Administrators
The following table shows the administrators registry entry permissions:


features will fail.

The following table shows the administrators file system permissions:

altered or deleted.
C:\Inetpub\wwwroot\wss Full Control No This directory (or the

unavailable and
IIS web site paths are
provided for all IIS web sites
that are extended with
SharePoint Server .

correctly.

S%\Microsoft Shared\Web contents are altered, web
Server application provisioning will


depends. If the ACL is
modified, Web Part
rendering, and other
might fail.

SharePoint Server.
WSS_RESTRICTED_WPG
WSS_RESTRICTED_WPG can read the encrypted farm administration credential registry entry.
WSS_RESTRICTED_WPG is only used for encryption and decryption of passwords that are stored in the
configuration database. The following table shows the WSS_RESTRICTED_WPG registry entry permission:

features will fail.
Users group
The following table shows the users group file system permissions:

SharePoint Server binaries
SharePoint Server
installation.
%ProgramFiles%\Microsoft Read, execute No This directory is the root

Servers\16.0\WebServices\R root Web services are
oot hosted. The only service
initially installed on this
directory is a search global
administration service.
Some search administration
functionality that uses the
server-specific Central
Administration Settings
page will not work if this
altered.

generated. Logging will not
altered.

Office Servers\16.0\Bin location of SharePoint
Server binaries. All of the
SharePoint Server
altered.
All SharePoint Server service accounts

The following table shows the all SharePoint Server service accounts file system permission:
%COMMONPROGRAMFILE Modify No This directory contains

Server Extensions\16\LOGS logs. If this directory is
All SharePoint Server service
accounts must have write
permission to this directory.
See also
Concepts
Install prerequisites for SharePoint Server from a
network share

Installing prerequisites from an offline location is typically required when the servers on which you want to install
SharePoint Server are isolated from the Internet. Even if this is not the case, by installing prerequisites from a
central, offline location, you can 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.
Installer switches and arguments

By using PrerequisiteInstaller.exe with switches and arguments, you control the versions of the required software
that are installed and the location from which 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, /SQLNCli: is the switch for the Microsoft
SQL Server 2012 SP1 Native Client.
<path> is expressed as the path of a local file or the path of a file share, for example,
"C:\foldername\sqlncli.msi" or "\<servername>\<sharename>\sqlncli.msi".
Each switch and its argument are separated by a colon and a space. The argument is enclosed in quotation marks.
The switch and argument pairs can be passed to PrerequisiteInstaller.exe at the command prompt or read from
an arguments text file.
Download and combine the SharePoint Server prerequisites on a file

share
You can download and combine prerequisites by performing the steps in the following procedures.
To identify prerequisites
1. Refer to the article, Hardware and software requirements for SharePoint Server 2016, which lists all the
required and optional software for SharePoint Server 2016. Additionally, this article provides the
download location for each prerequisite that can be downloaded from the Internet. For hardware and
software requirements for SharePoint Server 2019, see Hardware and software requirements for
For the SharePoint 2013 version, see Hardware and software requirements for SharePoint 2013.
2. From the command prompt, navigate to the root of the SharePoint Server installation media or folder
location.
3. At the command prompt, type the following command, and then press Enter:
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, follow these steps to create a central location that you can use for installing SharePoint Server prerequisites
on all the farm servers.
To combine 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 available network location for the prerequisites, use the procedure in the following
section to install SharePoint Server prerequisites on a server.
Install the SharePoint Server prerequisites at the command prompt

You can install one or more 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 Server source directory.
3. Type the prerequisite program switch and corresponding argument for the program that you want to
install, and then press Enter, for SharePoint Server 2016, type:
PrerequisiteInstaller.exe /SQLNCli:"\o16-sf-admin\SP_prereqs\sqlncli.msi"
NOTE
To install more than one prerequisite, type each switch and argument pair. Be sure to separate each pair by a space,
for example: > PrerequisiteInstaller.exe /IDFX:"\< path>\Windows6.1-KB974405-x64.msu" /sqlncli:"\<
path>\sqlncli.msi" /Sync:"\< path>\Synchronization.msi"
Install the SharePoint Server prerequisites by 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 have 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 processes only the command-
line argument.
2. PrerequisiteInstaller.exe scans the local system to determine whether 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 varies depending on which of the following
conditions are true on the computer:
If the component that requires a restart 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 the component that requires a restart 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 to run again because the startup file that is created
before the restart contains a /continue flag.
Multiple components might require you to restart. So PrerequisiteInstaller.exe might have to be restarted
several times. After you 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 by using the following syntax:
/switch: <path>
Where /switch is a valid switch and <path> is a path of the installation source.
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 at the command prompt to install the prerequisites.
Cau t i on
If you are prompted to click Finish to restart the system, do not do so. Instead, click Cancel. For more
information, see Known issues before you continue with the next step.
2. Manually restart the system.
3. At the command prompt, type the following command, and then press Enter:
PrerequisiteInstaller.exe
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 you restart, PrerequisiteInstaller.exe runs 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 by 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
3. From the Start menu, choose Run, and then type regedit to open the registry.
4. Open the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell
Folders.
5. Check the value for "Common Startup". This shows the directory where the startup tasks are listed.
6. Close the registry editor without making any changes.
7. Navigate to the startup directory, which is usually <systemdir>\ProgramData\Microsoft\Windows\Start
Menu\Programs\Startup.
8. Delete the startup task by deleting "SharePointServerPreparationToolStartup_0FF1CE14-0000-0000-
0000-000000000000.cmd".
Overview of MinRole Server Roles in SharePoint

Learn about the new MinRole farm topology and its benefits in SharePoint Servers 2016 and 2019.
What is MinRole?
MinRole is a new farm topology based on a set of predefined server roles introduced in SharePoint Server
2016. When configuring your SharePoint farm, you now select the role of a server when you create a new farm
or join a server to an existing farm. SharePoint will automatically configure the services on each server based
on the server's role. SharePoint Server 2016 and 2019 has been optimized for the MinRole farm topology.
The following video gives a general overview what MinRole is and can do for your organization.
Benefits of using the MinRole farm topology

Some of the primary benefits to using MinRole are:
Simplified deployment: Now you no longer need to worry about which services should be started on
which servers. By deploying your farm in a recommended MinRole topology, you can focus on what
functionality to enable in your farm and let SharePoint take care of the rest.
Improved performance and reliability: Microsoft has been operating SharePoint Online for years
and has analyzed the performance characteristics of SharePoint under a variety of conditions, including
CPU, memory, disk I/O, and network latency. SharePoint Servers 2016 and 2019 have been optimized
for the MinRole farm topology based on that analysis. By deploying your farm in a recommended
MinRole topology, you'll be able to reduce network latency and increase reliability.
Simplified capacity planning and farm scalability: Microsoft bases capacity planning on the
MinRole topology. By deploying your farm in a recommended MinRole topology, you'll be able to
leverage more predictable and prescriptive capacity-planning guidance. Plus, it's now easier to add
servers into your farm as your needs grow because SharePoint automatically configures the additional
servers for you.
How does MinRole simplify deployment?

MinRole automatically starts and stops service instances on each MinRole-managed server in your farm based
on the server role. When you create a new farm or join a machine to an existing farm, SharePoint starts the
base set of service instances that are required for the server's role. It also detects which additional services
have been enabled in the farm and starts the matching service instances as appropriate for the server's role.
Finally, it detects which service applications have been created in the farm and which services are necessary to
support those service applications. Those service instances will be started as appropriate for the server's role,
as well.
MinRole management of service instances doesn't happen only when you join a server to a farm. As you
enable or disable services in the farm, or as you create and delete service applications in the farm, MinRole
starts and stops service instances on the existing servers in the farm. This ensures that each server in your
SharePoint farm is running exactly the services it needs.
The result is that SharePoint farm administrators can now focus on what services you want to run in your farm
and not worry about where they're running. As long as you've deployed a supported MinRole farm topology,
SharePoint will handle those details.
How does MinRole improve performance and reliability?

SharePoint often needs to communicate with service instances when serving requests. In previous releases,
many service instances were typically hosted on separate servers, requiring cross-server connections from the
front-end servers, which added latency. In addition, if one of the servers hosting those service instances was
unhealthy, it could affect requests from multiple front-end servers, making it difficult to troubleshoot the issue
and limit the impact on the rest of the farm.
MinRole improves this experience by hosting service instances appropriate for each server role on the local
server. For example, service instances that are appropriate for user requests are hosted on the Front-end server
role, while service instances appropriate for background tasks are hosted on the Application server role. When
SharePoint needs to communicate with a service instance to serve a request, it detects if the service instance is
hosted on the local server. If it is, it will always use that local service instance instead of a service instance
hosted on a remote server.
This design reduces latency by keeping traffic on the local server whenever possible. It also improves reliability
by limiting the impact of unhealthy servers on the overall farm. Once an administrator determines that a server
is unhealthy and removes it from the load balancer rotation, the remaining healthy servers can continue to
serve requests and not be affected by the unhealthy server.
MinRole is also self-healing. MinRole scans each server in your farm once a day to confirm that it's running the
service instances that it's supposed to be running. If it detects a server that's not compliant with its server role,
it will automatically start or stop the necessary service instances to return it to compliance. The SharePoint
farm administrator has full control over this health scan and can change how often the scan is performed,
whether MinRole automatically fixes non-compliant servers or simply reports them to the farm administrator,
and can disable the scan entirely.
How does MinRole simplify capacity planning and farm scalability?

Microsoft provides a variety of recommended MinRole farm topologies for our customers, including small,
medium, and large-sized farms. To review the recommended MinRole farm topologies, see Planning for a
MinRole server deployment in SharePoint Servers 2016 and 2019.
MinRole is also adaptable with built-in server role conversion. You can easily convert a server from one server
role to another without having to disconnect a server from a farm and then rejoining it to the farm. Server role
conversion can be performed through the Central Administration web site or Windows PowerShell.
MinRole enhancements
Starting with the November 2016 Public Update for SharePoint Server 2016, Microsoft has introduced the
following enhancements to MinRole:
Better support for small and medium-sized farm topologies via new shared roles. Now you can deploy a
MinRole farm with just 2 servers, or a high availability (HA) MinRole farm with just 4 servers. For more
information about these new roles and recommended MinRole farm topologies, see Planning for a
MinRole server deployment in SharePoint Servers 2016 and 2019.
An improved server role conversion experience via role conversion pre-validation. Now MinRole will
check to ensure your server is ready for role conversion before starting the conversion. If it detects that
the server isn't ready, it will block the conversion and present a message explaining why the role
conversion was blocked, as well as instructions to resolve the issue. For more information about role
conversion pre-validation, see Role conversion using MinRole in SharePoint Servers 2016 and 2019.
Updated service instance assignments for each server role to ensure your farm is operating at optimal
performance. For more information about the new service instance assignments, see Description of
MinRole and associated services in SharePoint Servers 2016 and 2019.
Microsoft recommends installing the November 2016 Public Update (or newer) for SharePoint Server 2016 to
take full advantage of these MinRole enhancements.
See also
Concepts
Technical diagrams for SharePoint Server
Description of MinRole and associated services in SharePoint Servers 2016 and 2019
Other Resources
Planning for a MinRole server deployment in SharePoint Servers 2016 and 2019
Managing a MinRole Server Farm in SharePoint Servers 2016 and 2019
Planning for a MinRole server deployment in
Server roles in SharePoint Servers 2016 and 2019

There are eight pre-defined server roles in 3 categories you can choose from in SharePoint Servers 2016 and
2019. Read more about the roles and their descriptions in the following tables:
Dedicated Roles: Dedicated roles are optimized for performance and scalability and are typically used in large
scale farms. They can also be used in medium scale farms with shared roles.
Server Role Description Notes
Front-end Service applications, services, and The Application server and the Front-
components that serve user requests end server roles host a similar set of
belong on a Front-end server. These services. However, each role serves a
servers are optimized for high different purpose. The Front-end role is
performance. performance-sensitive and optimized
for serving user traffic by running
service instances appropriate for user
requests on the local server. It's normal
for the Front-end server role to run
service instances that would have been
hosted on the Application server role
in previous versions.
Application Service applications, services, and The use of the term "Application
components that serve back-end server" in SharePoint Server 2016 has
requests, such as search crawl a different meaning from the common
requests, belong on an Application use of the term in previous versions. In
server. These servers are optimized for previous versions of SharePoint, the
high throughput. Application server typically hosted
service application endpoints that
Front-end servers would call while
serving user requests. In SharePoint
Servers 2016 and 2019, the
Application server role runs
background tasks such as Timer jobs,
and can be the target for search crawl
requests.
Distributed Cache Service applications, services, and Distributed Cache doesn't support
components that are required for a High Availability the way that other
distributed cache belong on a services do. While you can have
Distributed Cache server. multiple Distributed Cache servers in
your SharePoint farm to help distribute
the load, the data cached on each
Distributed Cache server is not
replicated to the other Distributed
Cache servers. If a Distributed Cache
server unexpectedly goes down, the
data cached in that server will be lost.
Search Service applications, services, and Once a server is assigned to the Search
components that are required for role, it must then be configured in
search belong on a Search server. Search topology management. For
more information about Search
topology, see Manage the search
topology in SharePoint Server .
Shared Roles: Shared roles are optimized for fewer servers in a farm by combining dedicated roles together.
They can also be used in medium scale farms with dedicated roles. Shared roles may require higher available
system resources because they are running more services.
Front-end with Distributed Cache Shared role that combines the Front- This shared role was introduced in the
end and Distributed Cache roles on the November Public Update for
same server. Make sure the server SharePoint Server 2016 (Feature Pack
meets the system requirements for 1).
hosting a shared server role.
Application with Search Shared role that combines the This shared role was introduced in
Application and Search roles on the November Public Update for
same server. Make sure the server SharePoint Server 2016 (Feature Pack
meets the system requirements for 1).
hosting a shared server role.
Special Roles: For special case scenarios, testing, development, and services that are not integrated with
MinRole.

Single-Server Farm Service applications, services, and The Single-Server Farm role replaces
components required for a single- the Standalone Install mode available
server farm belong on a server in previous SharePoint Server releases.
running the Single-Server Farm role. Unlike Standalone Install, the
Use this role for development, testing, SharePoint administrator must
and limited production tasks. separately install and prepare Microsoft
SQL Server. The SharePoint
administrator must also configure the
SharePoint farm services and web
applications, either manually or by
running the Farm Configuration
Wizard. A SharePoint farm with the
Single-Server Farm role cannot have
more than one SharePoint server in
the farm.
Custom Service applications, services, and This server role is typically used to run
components that you want to manage, services that do not integrate with
instead of using MinRole to manage MinRole. The farm administrator has
them, belong on a Custom server. full control over which service instances
can run on servers assigned to the
Custom server role. MinRole will not
attempt to manage servers assigned to
this role.
NOTE
You must have the November Public Update for SharePoint Server 2016 (Feature Pack 1) installed to use shared roles in
your farm topology. >
MinRole Topologies
There are three different types of SharePoint farms:
Content Farms: These farms host sites and service applications, and can optionally consume service
applications from other farms.
Services Farms: These farms host service applications that are consumed by other farms. Example service
applications include: Managed Metadata, Search, and User Profile.
Search Farms: These farms are dedicated to hosting Search service applications that are consumed by
other farms.
Each type of SharePoint farm requires different MinRole server roles to function properly. Refer to the table
below for the list of server roles required for each type of farm.
Server Role Required for Content Required for Services Required for Search
Farm? Farm? Farm?
Front-end Yes No No
Application Yes Yes No
Distributed Cache Yes Yes No

Search Yes, if hosting Search Yes, if hosting Search Yes
NOTE
Shared roles can be substituted for their equivalent dedicated roles to reduce the number of servers in a farm. For
example, the "Front-end with Distributed Cache" role can be used in place of the separate "Front-end" and "Distributed
Cache" roles to meet the requirements of a content farm. > Dedicated roles, shared roles, and the Custom server role can
be used together in the same farm. If you substitute the Custom server role for one or more MinRole-managed server
roles, you must ensure that servers assigned to the Custom role are configured properly with the service instances needed
in that type of farm. > SQL Server can be running on the same server or a different server as SharePoint, but for better
performance we recommend running SQL Server on a separate server.
Refer to the table below for the list of recommended MinRole content farm topologies.
Content Farm Topology Total Servers in Farm Description
Single-Server Farm 1 One server with all roles:

Evaluation, development, testing.
Very light and simple production
workloads.
Small Non-High Availability MinRole 2 Two servers with two shared roles:
farm One Front-end with Distributed Cache
server
One Application with Search server
Small High Availability (HA) MinRole 4 Four servers with two shared roles:
farm Two Front-end with Distributed Cache
servers
Two Application with Search servers
Medium Non-High Availability MinRole 4 Four servers with four dedicated roles:
farm One Front-end server
One Distributed Cache server
One Application server
One Search server
Medium High Availability (HA) MinRole 6 Six servers with both dedicated and
farm (Search optimized) shared roles:
Two Front-end with Distributed Cache
servers
Two Application servers
Two Search servers
Medium High Availability (HA) MinRole 6 Six servers with both dedicated and
farm (user optimized) shared roles:
Two Front-end servers
Two Distributed Cache servers
Two Application with Search servers
Large High Availability (HA) MinRole 8 Eight servers with four dedicated roles:
farm Two Front-end servers
Two Distributed Cache servers
Two Application servers
Two Search servers
MinRole Farm deployment

Deploying servers
Use the following methods to create a new farm or join servers to an existing farm with MinRole:
SharePoint Products Configuration Wizard (PSConfigUI.exe)
PSConfig.exe command line tool
Microsoft PowerShell cmdlets
The MinRole feature introduces two new command-line parameters for PSConfig.exe and PowerShell. The
LocalServerRole parameter specifies the role of the local server when you create a new farm or join a server to
an existing farm. The LocalServerRole parameter accepts the following values:
WebFrontEnd (Front-end server role)
Application (Application server role)
DistributedCache (Distributed Cache server role)
Search (Search server role)
WebFrontEndWithDistributedCache (Front-end with Distributed Cache server role)
ApplicationWithSearch (Application with Search server role)
Custom (Custom server role)
SingleServerFarm (Single-Server Farm server role)
The ServerRoleOptional parameter configures the farm not to require a server role to be specified when
creating a farm or adding a server to a farm. It can be used when you create a new server farm. If no server role
is specified, the server defaults to the Custom role.
You can deploy your servers in a farm in any order you want. Any server role can be the first server in your farm.
When you create a new farm or join a server to an existing farm by using the SharePoint Products Configuration
Wizard, a new form is displayed in the wizard. This form provides a description of each server role, and you can
use it to select the role of this server. The server role radio button will be disabled for roles that are not available
in this farm.
Deploying the SharePoint Central Administration web site
The first server in the farm will host the SharePoint Central Administration web site by default. Additional
servers will not host the Central Administration web site by default. You can start or stop Central Administration
on individual servers in the farm regardless of their server role by using any one of these steps:
From the SharePoint Central Administration web site, go to the Services on Server page.
The New-SPCentralAdministration and Remove-SPCentralAdministration PowerShell cmdlets.
The psconfig.exe -cmd adminvs command.
The SharePoint Products Configuration Wizard user interface.
The state of Central Administration will not affect whether a server is considered compliant with MinRole.
Deploying services
Do not attempt to create service applications in a MinRole farm until it has reached the minimum supported
MinRole farm topology. For example, if you're deploying a content farm using dedicated server roles, then you
shouldn't try to create service applications until at least one of each of the following server roles have been
deployed:
Front-end
Application
Distributed Cache
Search (if hosting a Search service application)
Note: This guidance does not apply to farms that use the Custom server role.
Manually configuring Search to crawl
The farm administrator should configure Search to crawl web applications using the Application server role or
the Application with Search server role instead of the Front-end server role for optimal performance. This can be
done by configuring your load balancer to forward Search crawler requests to the Application or Application
with Search servers, or by configuring the SharePoint Request Manager to forward Search crawler requests to
the Application or Application with Search servers.
Converting Single -Server Farm into a multiple server farm
You can convert a single-server farm into a multiple-server farm. To do this, use the role conversion feature. For
additional information about how to change a server role, see Role conversion using MinRole in SharePoint
Servers 2016 and 2019.
Opting out of MinRole

SharePoint Servers 2016 and 2019 supports the backward compatible behavior of previous SharePoint releases
with the Custom server role. SharePoint farm administrators can directly manage service instances on individual
servers assigned to the Custom role. MinRole won't attempt to manage servers assigned to the Custom role.
You can assign zero, some, or all servers in a farm to the Custom role.
If you have existing deployment scripts that you do not want to modify to support MinRole, you can specify the
ServerRoleOptional parameter when you create a new SharePoint farm by using the PSConfig.exe command-
line tool or PowerShell. This parameter configures the farm to not require a server role to be specified. If no
server role is specified, the server defaults to the Custom role.
See also
Concepts
Overview of MinRole Server Roles in SharePoint Servers 2016 and 2019
Description of MinRole and associated services in SharePoint Servers 2016 and 2019
Other Resources
Managing a MinRole Server Farm in SharePoint Servers 2016 and 2019

You can install and configure SharePoint Servers 2016 or 2019 on a single server if you are hosting only a few
sites for a limited number of users or if you want to create a trial or development environment. 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
In previous versions of SharePoint, a single server installation automatically installed SQL Server Express. In SharePoint
Servers 2016 and 2019, a single server installation contains only SharePoint. SQL Server can be installed on the same
server or on a separate server; both scenarios are supported. For better performance we recommend installing SQL Server
on a separate server.
Overview
After you have completed setup and the SharePoint Products Configuration Wizard, you will have installed
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.
Before you install SharePoint Servers 2016 or 2019 on a single server

have a 64-bit version of Windows Server 2012 R2. To host SharePoint databases, you must also have a
64-bit version of SQL Server 2014 SP1. For more information about these requirements, such as specific
have a 64-bit version of Windows Server 2016. To host SharePoint databases, you must also have a 64-bit
version of SQL Server 2016 or 2017. For more information about these requirements, such as specific
Ensure that you perform a clean installation of SharePoint Servers 2016 or 2019.
Ensure that you are prepared to set up the required accounts by using appropriate permissions. For
detailed information, see Initial deployment administrative and service accounts in SharePoint Server.
Ensure the Max degree of parallelism is set to 1. For additional information about max degree of
parallelism see, Configure the max degree of parallelism Server Configuration Option.
Security note: As a security best practice, we recommend that you install SharePoint Servers 2016 or 2019 by
using least-privilege administration.
TIP
Install SharePoint Servers 2016 or 2019 on a single server

To install and configure SharePoint Server 2016 or 2019 on a single server, you will follow these steps:
1. Run the Microsoft SharePoint Products and Technologies Preparation Tool, which installs all
prerequisites to use SharePoint Server.
2. Run Setup, which installs binaries, configures security permissions, and edits registry settings for
SharePoint Servers 2016 or 2019.
IMPORTANT
computer on which you are installing SharePoint Server. For information about user accounts, see Initial deployment

software prerequisites for SharePoint Servers 2016 or 2019.
Server.
2. In the SharePoint Server installation disc image software, mount the ISO file, and click the splash.hta file.
The SharePoint Server splash screen is displayed.
4. On the Welcome to the SharePoint Products Preparation Tool page, click Next.
5. On the License Terms for software products page, review the terms, select the I accept the terms of
the License Agreement(s) check box, and then click Next.
6. On the Your system needs to restart to continue page, click Finish to restart the computer.
7. Repeat steps 2-4.
Run Setup
The following procedure installs binaries, configures security permissions, and edits registry settings for
SharePoint Server. 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
Server.
5. Optional: To install SharePoint Server at a custom location, or to store search index files at a custom
location, click the File Location tab, and then either type the custom location or click Browse to find the
custom location.
NOTE
separate storage volume or partition. Any other search data that needs to be stored is stored in the same location
as the search index files. You can only set this location at installation time.

7. 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.
NOTE
If Setup fails, check log files in the Temp folder of the user account you used to run Setup. Ensure that you are logged in
using the same user account and then type %temp% in the location bar in Windows Explorer. If the path in Windows
Explorer resolves to a location that ends in a "1" or "2", you have to navigate up one level to view the log files. The log file
name is SharePoint Server Setup (< time stamp>).

Server.
to All Apps, click Microsoft SharePoint Products, and then click SharePoint Products Configuration
Yes.
8. In the Database name box, type a name for your configuration database or use the default database
name. The default name is SharePoint_Config.
9. 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.
Security note: The server farm account is used to 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 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
server farm account has to be a domain user account. However, it does not have to be a member of any
specific security group on your SharePoint 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 SharePoint servers or your database servers.
11. Click Next.
credentials of accounts that are registered in SharePoint Server. For example, the SharePoint Server server
farm account that you provide when you run the SharePoint Products Configuration Wizard. Ensure that
you remember the passphrase, because you must use it every time that you add a server to the farm.
9. On the Specify Server Role page, choose the appropriate role, click Next.
NOTE
For a single server farm, we recommend choosing the Single Server Farm role, although you can select a Custom
role if you want to individually manage the services instances that run on the server. You can change the role of a
server later if you change your mind or want to expand your farm by adding additional servers.
Either select the Specify port number check box and type the port number that you want the SharePoint
Click either NTLM or Negotiate (Kerberos).
11. Click Next.
12. On the Completing the SharePoint Products Configuration Wizard page, review your configuration
NOTE
The Advanced Settings option is not available in SharePoint Servers 2016 and 2019.
13. On the Configuration Successful page, click Finish. When the wizard closes, setup opens the web
browser and connects to Central Administration.
If the SharePoint Products Configuration Wizard fails, check the PSCDiagnostics log files, which are
located on the drive on which SharePoint Servers 2016 and 2019 are installed, in the
Explorer. You might also want to disable the Internet Explorer Enhanced Security settings. If you see a
proxy server error message, you might have to configure proxy server settings so that local addresses
bypass the proxy server. Instructions for configuring proxy server settings are provided in the following
section. For more information about how to configure browser and proxy settings, see Configure browser
settings.
After you run the SharePoint Products Configuration Wizard, you should confirm that SharePoint Server works
information about supported browsers, see Plan browser support in SharePoint Servers 2016 and 2019.
procedure.
procedure.
2. Click Start, point to All Apps, point to Administrative Tools, and then click Server Manager.
then click OK.
procedure.
5. In the Proxy Server area, click the Use a proxy server for your LAN check box.
You have now completed setup and the initial configuration of SharePoint Server. You have created the
SharePoint Central Administration web site. You can now configure your farm and sites, and you can select
services by using the Farm Configuration Wizard.
Server.
2. On the SharePoint Central Administration home page, on the Quick Launch, click Configuration
Wizards, and then click Launch the Farm Configuration Wizard.
4. On the Configure your SharePoint farm page, next to Yes, walk me through the configuration of
my farm using this wizard, click Start the Wizard.
5. On the Service Applications and Services page, in the Service Account section, click the service
account option that you want to use to configure your services.
Security 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 of which SharePoint Server 2016 is
aware — make sure that you click that option before you continue.
NOTE
12. Click OK.

click Finish.
After you install and configure SharePoint Server, 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.
installation or upgrade. The default settings are sufficient for most situations. Depending upon the
business needs and life-cycle of the farm, you might want to change these settings.
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 occur, save e-mailed documents, and show e-mailed meetings on site calendars. In
Configure Search settings You can configure Search settings to crawl the content in SharePoint Server.
Install SharePoint Servers 2016 or 2019 across
multiple servers

The deployment sequence and configurations that are described in this article are based on recommended best
practices. While the farm configuration is not complex, it provides a fundamental infrastructure to implement a
SharePoint Server solution on similar — or more complex farms.
Overview
Ensure that you have done all the planning and preparatory work, such as verifying hardware and
software requirements.
Install the SharePoint Server prerequisites on SharePoint servers.
Install SharePoint Server on the SharePoint servers.
Provision services.
Topology overview
SharePoint Servers 2016 and 2019 support a new farm topology design called MinRole. This article will describe
a simple multi-server farm topology with one server assigned to each MinRole server role. However, to take
advantage of zero downtime patching, your farm topology must support high availability (HA) by having multiple
servers assigned to each MinRole server role.
For additional information about MinRole, see Overview of MinRole Server Roles in SharePoint Servers 2016
and 2019.
Before you install SharePoint Server on multiple servers
Guidelines for Windows Server 2012 R2.
Ensure that you have met all hardware and software requirements. For more information about these
requirements, such as specific updates that you must install, see Hardware and software requirements for
SharePoint Server 2016. For SharePoint Server 2019, see Hardware and software requirements for
Ensure that you perform a clean installation of SharePoint Server.
connection to download and configure SharePoint Server prerequisites.
Database server
configuration.
make sure 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.
Storage and SQL Server capacity planning and configuration (SharePoint Server).
Configure the max degree of parallelism Server Configuration Option.
Ensure that public updates and the required hotfix packages are installed for the operating system, SQL Server,
and SharePoint Server.

Before you install SharePoint Server, you must check for and install all the prerequisites on the SharePoint
servers by using the Microsoft SharePoint Products Preparation Tool.
TIP
Server.
2. In the SharePoint Server installation disc image, mount the ISO file, and then click the splash.hta file. The
SharePoint Server 2016 splash screen is displayed..
4. On the Welcome to the SharePoint 2016 Products Preparation Tool page, click Next.
NOTE
6. If you see the Your system needs to restart to continue page, click Finish to restart the computer, and
then repeat steps 2-4.
Install SharePoint Server 2016 on the farm servers

After the prerequisites are installed, follow these steps to install SharePoint Server 2016 on each farm server.
SharePoint Server 2016. At the end of Setup, you can choose to start the SharePoint Products Configuration
Wizard, which is described later in this article.
To run Setup
Server.
5. Optional: To install SharePoint Server at a custom location, or to store search index files at a custom
custom location.
NOTE
As a best practice, we recommend that you install SharePoint Server on a non-system drive. > If you intend to use
this computer as a search server, we recommend that you store the search index files on a separate storage volume
or partition. Any other search data that needs to be stored, is stored in the same location as the search index files.
You can only set this location at installation time.

7. When the Setup program is finished, 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
SharePoint Server 2016 on all SharePoint servers that will participate in the server farm.

To configure the farm, you run the SharePoint Products Configuration Wizard. This wizard automates several
configuration tasks, such as creating the configuration database, installing services, and creating the Central
Administration website. We recommend that you run the SharePoint Products Configuration Wizard on the
server that will host the SharePoint Central Administration website before you run the wizard on the other
servers in the farm.
Server.
2. On the server that will host Central Administration (the application server), click Start, point to All Apps,
and then click Microsoft SharePoint Products, and then click SharePoint Products Configuration
Yes.
8. In the Database name box, type a name for your configuration database, or use the default database
IMPORTANT
The server farm account is used to 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
SharePoint 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 server farm account has to be a domain user account. However, it does not have to
be a member of any specific security group on your SharePoint 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 SharePoint servers or your database servers.

11. Click Next.
credentials of accounts that are registered in SharePoint Servers 2016 or 2019. For example, the
SharePoint Server server farm account that you provide when you run the SharePoint Products
Configuration Wizard. Ensure that you remember the passphrase, because you must use it every time that
you add a server to the farm.
12. Click Next.
13. On the Completing the SharePoint Products Configuration Wizard page, review configuration
settings, and then click Next.
NOTE
If the SharePoint Products Configuration Wizard fails, check the log files on the drive on which SharePoint Server
2016 is installed, which are located in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server
Extensions\16\LOGS folder.
18. On the Initial Farm Configuration Wizard 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.
We recommend waiting until your SharePoint farm has at least one of each type of server role joined to it
before you run the Farm Configuration Wizard.
IMPORTANT
The Farm Configuration Wizard can't be used with DBA-created databases because the Farm Configuration Wizard
will try to create its own databases. If you're using DBA-created databases, you must create each service application
and web application manually so that you can specify the DBA-created database it should connect to.
Add SharePoint servers to the farm

After you create the farm on the first server, you can add servers by following the same process described earlier
in this topic for installing SharePoint Server on the server that hosts Central Administration. The only difference
is that during the SharePoint Products Configuration Wizard, you choose to join an existing farm. Follow the
wizard steps to join the farm.
For your content farm to be MinRole complaint, at a minimum you want to have at least one of each type of
server role in the farm: Application, Front-end, Distributed cache, and Search. The order in which these roles
are created does not matter. You can also combined roles by using shared roles. If you want to take full advantage
of zero down time patching, then you need to make sure high availability is configured.
For additional information about MinRole, see Overview of MinRole Server Roles in SharePoint Servers 2016
and 2019.
NOTE
If this farm is not hosting Search services, then the Search role is not needed.
For additional information about how to add servers to a farm, see Add a server to a SharePoint Server 2016 or
SharePoint Server 2019 farm. This article also provides detailed information for the steps in the following
procedure.
After you install and configure SharePoint Server, 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.
business needs and life-cycle of the farm, you might want to change these settings.
Configure Search settings You can configure Search settings to crawl the content in SharePoint Servers
2016 or 2019.

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 Server. You install
language packs, which contain language-specific site templates, on each SharePoint server in your farm. 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 users in different locations, or when
sites and web pages must be duplicated in one or more languages.
and site collections in multiple languages without requiring separate installations of SharePoint Server. Word
breakers and stemmers are automatically installed on SharePoint servers by Setup.
IMPORTANT
If you are uninstalling SharePoint Server, you must uninstall all language packs before you uninstall SharePoint Server.

Site owners or site collection administrators who create sites or site collections 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 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 language packs that are installed on the SharePoint servers determine the list of available languages that
you can use to create a site or site collection. By default, sites and site collections are created in the language in
which SharePoint Server was installed. For example, if you install the Spanish version of SharePoint Server, 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 Server language, you must install the
language pack for that language on the SharePoint servers. For example, if you are running the French version
of SharePoint Server, and a site owner wants to create sites in French, English, and Spanish, you must install the
English and Spanish language packs on the SharePoint servers.
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 SharePoint
server to make sure that each SharePoint 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 always displays content in the language of the original site template. For example, SharePoint can render the
same site in multiple languages based on the preferred language of the user’s web browser. But for this to work, the
SharePoint language pack that matches the user’s preferred language must be installed on each server in the SharePoint
farm.
notifications, and dialog boxes do not display in the language that was specified. This is because SharePoint
Server relies on several supporting technologies — for example, the Microsoft .NET Framework, Microsoft
Windows Workflow Foundation, Microsoft ASP.NET, and SQL Server — 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
are 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.
Server Extensions\16\TEMPLATE\LAYOUTS\Locale_ID that contains language-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 language, this file will be used. You can
specify the file to use by setting the FileNotFoundPage() for each web application.

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 Microsoft PowerShell Help files are installed in English (en-us). To view these files in the same language as
the operating system, install the language pack for the same language in which the operating system was installed.
You can download language packs from the Microsoft Download Center for SharePoint Server 2016 and
Installing language packs on the SharePoint servers

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 SharePoint server.
IMPORTANT

Verify that the user account that is performing this procedure is the Setup user account. For information about
the Setup user account, see Initial deployment administrative and service accounts in SharePoint Server.
1. In the folder where you downloaded the language pack, run serverlanguagepack.exe.
SharePoint Products Configuration Wizard after you install a language pack, the language pack will not
be installed correctly.
The SharePoint Products Configuration Wizard runs in the language of the base installation of
SharePoint Server, not in the language of the language pack that you just installed.
To rerun the SharePoint Products Configuration Wizard
1. Click Start, point to Microsoft SharePoint 2019 Products folder, click SharePoint Products
configuration.
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. After you complete the Completing the SharePoint Products Configuration Wizard, click Next.
8. After you install a new language pack and rerun the SharePoint Products Configuration Wizard, you
must deactivate and then reactivate any language-specific features before you use the new language
pack.
%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\16\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\16\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.
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 again.
You cannot remove the language pack for the version of SharePoint Server that you have installed on the server.
For example, if you are running the Japanese version of SharePoint Server, you cannot uninstall the Japanese
language support for SharePoint Server.
List of Languages
Each folder name has a language tag appended to it, in the form ll-cc. That tag identifies the language and
culture. For example, U.S. English language folders are identified by the folder name extension en-us.
Folders for the language-specific components are identified by the language tag that is shown in the table. The
Windows operating system uses locale identifiers (LCIDs) to identify languages in the Windows registry.
SharePoint Servers 2016 and 2019 support the following languages:
Arabic ar-sa 1025
Azerbaijani az-latn-az 1068
Basque eu-es 1069
Bosnian (Latin) bs-latn-ba 5146
Bulgarian bg-bg 1026
Catalan ca-es 1027
Chinese (Simplified) zh-cn 2052
Chinese (Traditional) zh-tw 1028
Croatian hr-hr 1050
Czech cs-cz 1029
Danish da-dk 1026
Dari prs-af 1164
Dutch nl-nl 1043
English en-us 1033
Estonian et-ee 1061

Finnish fi-fi 1035
French fr-fr 1036
Galician gl-es 1110
German de-de 1031
Greek el-el 1032
Hebrew he-il 1037
Hindi hi-in 1081
Hungarian hu-hu 1038
Indonesian id-id 1057
Irish ga-ie 2108
Italian it-it 1040
Japanese ja-jp 1041
Kazakh kk-kz 1087
Korean ko-kr 1042
Latvian lv-lv 1062
Lithuanian lt-lt 1063
Macedonian (FYROM) mk-mk 1071
Malay (Malaysia) ms-my 1086
Norwegian (Bokmål) nb-no 1044
Polish pl-pl 1045
Portuguese (Brazil) pt-br 1046
Portuguese (Portugal) pt-pt 2070
Romanian ro-ro 1048
Russian ru-ru 1049
Serbian (Cyrillic) sr-cyrl-rs 10266

Serbian (Latin) sr-latn-rs 9242
Slovak sk-sk 1051
Slovenian sl-si 1060
Spanish es-es 3082
Swedish sv-se 1053
Thai th-th 1054
Turkish tr-tr 1055
Ukrainian uk-ua 1058
Vietnamese vi-vn 1066
Welsh cy-gb 1106

Add a server to a SharePoint Servers 2016 or 2019
farm
Before you add a server to a SharePoint farm

In SharePoint Server 2016, the concept of server roles has changed from previous versions. Server role types
are now defined by MinRole which allow for better deployment and health of the server in the farm. For
additional information about the MinRole feature and a description for each server role type, see Overview of
MinRole Server Roles in SharePoint Servers 2016 and 2019.
Additional tasks
Verify that you have the minimum level of permissions that are required to install and configure
SharePoint Servers 2016 or 2019 on a new server. You must be a member of the Farm Administrators
SharePoint group and the Administrators group on the local server to complete the procedures in this
article. For more information, see Initial deployment administrative and service accounts in SharePoint
Server.
name of the configuration database if you are adding the server by using Microsoft PowerShell
commands.
memberships is installed.
cmdlets.
NOTE
additional information about PowerShell permissions, see Add-SPShellAdmin.
Document the location of the SharePoint Server 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.
IMPORTANT
If you change the location of the trace log to a non-system drive, change the location on all the servers in the farm.
Existing or new servers cannot log data if the location does not exist. In addition, you will be unable to add new servers
unless the path that you specify exists on the new server. You cannot use a network share for logging purposes.

Before you can install SharePoint Server and add a server to the farm, you must check for and install all the
prerequisite software on the new server. You do this by using the Microsoft SharePoint Products Preparation
Tool, which requires an Internet connection to download and configure SharePoint Server prerequisites. If you
do not have an Internet connection for the farm servers, you can still use the tool to determine the software that
is required. You will have to obtain installable images for the required software.
Server 2016)."
Server 2019)."
TIP
SharePoint Servers 2016 or 2019 across multiple servers.
TIP

After you install the prerequisites, follow these steps to install SharePoint Servers 2016 or 2019 on the new
server. For detailed instructions about how to install SharePoint Server, see Install SharePoint Server on one
server.
To install SharePoint Server
Server.
2. From the product media or a file share that contains the SharePoint Server Products installation files, run
Setup.exe.
5. Accept the default file location where SharePoint Server will be installed or change the installation path in
TIP
As a best practice, we recommend that you install SharePoint Server on a drive that does not contain the operating
system.

7. When Setup finishes, a dialog box prompts you to run the SharePoint Products Configuration
Wizard. You can start the wizard immediately or from the Windows command prompt later.

To add a server by using the SharePoint Products Configuration Wizard
PSConfig.exe command-line tool
To add a server by using Microsoft PowerShell
1. Start the SharePoint Products Configuration Wizard.
4. Click Next.
8. On the Specify Server Role page, choose the appropriate role, and then click Next.
NOTE
The concept of server roles has changed staring with SharePoint Server 2016. You can't add a server to a farm if the farm
10. 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
located on the drive on which SharePoint Server is installed, in the %COMMONPROGRAMFILES%\Microsoft Shared\Web
Server Extensions\16\LOGS folder.
NOTE
This step should only apply if the Custom role is used.
To add a new SharePoint Server server to the farm by using the PSConfig.exe command-line tool
1. To create a farm by using the PSConfig.exe command-line tool, use the following syntax:
psconfig.exe -cmd configdb -connect -server <SqlServerName> -database <ConfigDbName> -user

<DOMAIN\FarmServiceAccount> -password <FarmServiceAccountPassword> -passphrase <FarmPassphrase> -
admincontentdatabase <AdminContentDbName> -localserverrole <ServerRole> -cmd helpcollections -installall -
cmd secureresources -cmd services -install -cmd installfeatures -cmd adminvs -provision -port <PortNumber> -
windowsauthprovider onlyusentlm -cmd applicationcontent -install
Where <ServerRole> can be any of the following values: WebFrontEnd, Application, DistributedCache, Search,
or Custom.
NOTE
The SingleServerFarm cannot be used unless the SharePoint farm has zero servers in it.
NOTE
NOTE
The PSConfig.exe -cmd Services -Provision syntax is deprecated, but not removed yet. Do not use the Provision
parameter when you create or join a farm. Using this parameter will lead to failures.
To add a new SharePoint Server 2016 or SharePoint Server 2019 server to the farm by using
PowerShell
2016 cmdlets.
NOTE
additional information about PowerShell permissions, see [Add-SPShellAdmin](/powershell/module/sharepoint-server/Add-
SPShellAdmin?view=sharepoint-ps

2. At the PowerShell command prompt, type the following command to connect the server to a
configuration database:
Connect-SPConfigurationDatabase -DatabaseServer <SqlServerName> -DatabaseName <ConfigDbName> -Passphrase

<FarmPassphrase> -LocalServerRole <ServerRole>
Where:
<DatabaseName> is the name of the configuration database
<ServerRole> is the server role type
Where \<ServerRole\> can be any of the following values: WebFrontEnd, Application, DistributedCache, Search,
or Custom.
NOTE
NOTE
The concept of server roles has changed starting with SharePoint Server 2016. You can't add a server to a farm if the farm
SharePoint Server:
Install-SPService
7. At the PowerShell command prompt, type the following command to set the port number of the SharePoint
Central Administration website:
New-SPCentralAdministration -Port <PortNumber> -WindowsAuthProvider NTLM
NOTE
If the SharePoint Central Administration website is already provisioned on an existing server in the farm, you can skip this
step.
9. At the PowerShell command prompt, type the following command to start the Timer service:
Start-Service SPTimerV4
Get-SPServer
NOTE
located on the drive on which SharePoint Servers 2016 or 2019 is installed, in the

Testing and implementing SharePoint 2013 solutions at different stages of the deployment life cycle requires
deployments in various topologies.
The following articles provide information about how to deploy SharePoint 2013 on one or more servers to create
different topologies that you can use for testing and implementing SharePoint 2013 solutions at different stages
of the deployment life cycle.
CONTENT DESCRIPTION
Install SharePoint 2013 on a single server with a built-in Explains how to install SharePoint 2013 on a single server.
database This deployment uses SQL Server Express and is typically used
for evaluating SharePoint 2013.
Install SharePoint 2013 on a single server with SQL Server Describes how to install SharePoint 2013 on a single server.
This deployment uses SQL Server and can easily be scaled out
to create two- and three-tier farm topologies.
Install SharePoint 2013 across multiple servers for a three-tier Describes how to install SharePoint 2013 on multiple servers.
farm This deployment uses SQL Server and the resulting three-tier
topology provides the foundation for implementing any
solution.
Install and configure a virtual environment for SharePoint This article describes how to use PowerShell to install
2013 SharePoint 2013 in a Hyper-V environment.
Install or uninstall language packs for SharePoint 2013 Describes language packs and how to download, install, and
uninstall them.
Add web or application servers to farms in SharePoint 2013 Explains how to add a web or application server to a farm. The
procedures in this article apply to a SharePoint 2013 farm
that consists of at least two tiers. They should not be used for
converting a single server deployment to a multiple server
farm.
Add a database server to an existing farm in SharePoint 2013 Provides information about how to add a new database
server to an existing SharePoint 2013 farm.
Remove a server from a farm in SharePoint 2013 Describes how to remove a web server, application server, or
a database server from a SharePoint 2013 farm.
Uninstall SharePoint 2013 Describes how to remove SharePoint 2013 from a computer.
SharePoint 2013 dev/test environments in Azure Learn how to use Azure Resource Manager (ARM) templates
to create a basic or high-availability SharePoint 2013 dev/test
farm in Microsoft Azure infrastructure services.
APPLIES TO: 2013 2016 2019 SharePoint Online .

Before you install SharePoint 2013, you must make sure that you have installed all required hardware and
in SharePoint 2013. You must also understand the URL and path length restrictions in SharePoint 2013.
The following articles help you prepare for the installation of SharePoint 2013 by providing information about the
prerequisites that you must have in order to run SharePoint 2013.
CONTENT DESCRIPTION

for SharePoint 2013 requirements that you must meet to
successfully install SharePoint 2013.

2013 browsers to use with SharePoint 2013.
IP support in SharePoint 2013 Describes SharePoint 2013 support for

IP version 4 (IPv4) and IP version 6
(IPv6).
Software boundaries and limits for This article provides a starting point for
SharePoint 2013 planning the performance and capacity
of your SharePoint 2013 farm, and
includes performance and capacity
testing results and guidelines for
acceptable performance.
Capacity management and sizing This article walks you through the
overview for SharePoint Server 2013 concepts involved in capacity
management and sizing SharePoint
2013 farms, and provides an overview
of the planning process.
2013
IMPORTANT
hardware specifications described in this document, support will be limited until the system is upgraded to the minimum
requirements.
IMPORTANT
Some of the hardware requirement values in this article are based on test results from SharePoint 2010 Products and still
apply to SharePoint 2013. This article will be updated with appropriate values and republished when new data becomes
available. Hardware requirement values obtained from SharePoint 2010 Products that are listed in this article do not
apply to search in SharePoint 2013. > This article links to SharePoint 2010 Products guidance where that guidance is still
valid. The SharePoint 2010 Products guidance is not applicable for search in SharePoint 2013 because the search
architecture has changed significantly. > The hardware and software requirements in this article refer to physical and
virtual servers in a SharePoint farm.
Overview
SharePoint 2013 provides for several installation scenarios. Currently, these installations include single server
with built-in database installations, single-server farm installations, and multiple-server farm installations. This
article describes the hardware and software requirements for SharePoint 2013 in each of these scenarios.
Hardware and software requirements for other SharePoint 2013

capabilities
If you plan to use capabilities that are offered through SharePoint 2013 or through other integration channels,
such as SQL Server or Exchange Server, you also need to meet the hardware and software requirements that
are specific to that capability. The following list provides links to hardware and software requirements for some
SharePoint 2013 capabilities:
Hardware and software requirements (Project Server 2013)
For eDiscovery, each front-end web server must have the Exchange Web Services Managed API, version
1.2 installed. For more information, see the following articles:
Configure eDiscovery in SharePoint Server
Configure Exchange for SharePoint eDiscovery Center
Hardware requirements for search in SharePoint Server 2013:
Step 3: Which hardware requirements should I be aware of?
Hardware requirements for search topologies for Internet sites
Mobile device browsers supported in SharePoint 2013
Hardware requirements—location of physical servers

Some enterprises have data centers that are located in close proximity to one another and are connected by
high-bandwidth fiber optic links. In this environment it is possible to configure the two data centers as a single
farm. This distributed farm topology is called a stretched farm. Stretched farms for SharePoint 2013 are
supported as of April 2013.
must be met:
There is a highly consistent intra-farm latency of <1ms one way, 99.9% of the time over a period of ten
minutes. (Intra-farm latency is commonly defined as the latency between the front-end web servers and
the database servers.)
service applications and databases. For more information, see Create a high availability architecture and
strategy for SharePoint Server.
Hardware requirements—web servers, application servers, and single

server installations
The values in the following table are minimum values for installations on a single server with a built-in
database and for web and application servers that are running SharePoint 2013 in a multiple server farm
installation.
space for diagnostics such as logging, debugging, creating memory dumps, and so on. For production use, you
must also have additional free disk space for day-to-day operations. In addition, maintain two times as much
free space as you have RAM for production environments. For more information, see Capacity management
and sizing for SharePoint Server 2013.

Single server with a Development or 8 GB 64-bit, 4 cores 80 GB for system

built-in database or evaluation drive
single server that installation of
uses SQL Server SharePoint Server
2013 or SharePoint
Foundation 2013
with the minimum
recommended
services for
development
environments. For
information, see
Minimum
recommended
services for
development
environments.

2013 or SharePoint
Foundation 2013
running Visual Studio
2012 and the
minimum
recommended
services for
development
environments. For
information, see
Minimum
recommended
services for
development
environments.

2013 running all
available services.
Web server or Pilot, user acceptance 12 GB 64-bit, 4 cores 80 GB for system

application server in test, or production drive
a three-tier farm deployment of
SharePoint Server
2013 or SharePoint
Foundation 2013.
Hardware requirements—database servers

The requirements in the following table apply to database servers in environments that have multiple servers in
the farm.
NOTE
The requirements listed in this section also apply to SQL Server 2014.
COMPONENT MINIMUM REQUIREMENT
Processor 64-bit, 4 cores for small deployments (fewer than 1,000

users)
64-bit, 8 cores for medium deployments (between 1,000 to
10,000 users)
COMPONENT MINIMUM REQUIREMENT
RAM 8 GB for small deployments (fewer than 1,000 users)

16 GB for medium deployments (between 1,000 to 10,000
users)
For large deployments over 10,000 users, see the "Estimate
memory requirements" section in Storage and SQL Server
capacity planning and configuration (SharePoint Server
2010). This document does not apply to search in
SharePoint 2013.
These values are larger than those recommended as the
minimum values for SQL Server because of the distribution
of data that is required for a SharePoint 2013 environment.
For more information about SQL Server system
requirements, see Hardware and Software Requirements for
Installing SQL Server 2008 R2.
Hard disk 80 GB for system drive

Hard disk space depends on how much content that you
have in your deployment. For information about how to
estimate the amount of content and other databases for
your deployment, see Storage and SQL Server capacity
planning and configuration (SharePoint Server 2010).
Software requirements
Single server with built-in database
IMPORTANT
SharePoint 2013 does not support single label domain names. For more information, see Information about configuring
Windows for domains with single-label DNS names.
prerequisites for SharePoint 2013. Ensure that you have an Internet connection, because some prerequisites are
installed from the Internet. For more information about how to use the Microsoft SharePoint Products
Preparation Tool, see Install SharePoint 2013 across multiple servers for a three-tier farm and Install
SharePoint 2013 across multiple servers for a three-tier farm.
NOTE
SQL Server 2014 requires the May 2014 Cumulative Update to be installed. To install the May 2014 Cumulative Update
see Updates to SharePoint 2013.
NOTE
At this time, SQL Server 2016 RTM is not supported.
Minimum software requirements

Minimum requirements for a database server in a farm:
NOTE
SQL Server products and all future public updates and service packs are supported through the SQL Server product
lifecycle.

The 64-bit edition of Microsoft SQL Server 2012.
The 64-bit edition of SQL Server 2008 R2 Service Pack 1
The 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard, Enterprise, or Datacenter
or the 64-bit edition of Windows Server 2012 Standard or Datacenter
The SharePoint parsing process crashes in Windows Server 2008 R2 (KB 2554876)
FIX: IIS 7.5 configurations are not updated when you use the ServerManager class to commit
configuration changes (KB 2708075)
Hotfix: ASP.NET (SharePoint) race condition in .NET 4.5 RTM:
Windows Server 2008 R2 SP1 (KB 2759112)
Windows Server 2012 (KB 2765317)
Minimum requirements for a single server with built-in database:
NOTE
At this time, Windows Server 2016 RTM is not supported.
or the 64-bit edition of Windows Server 2012 R2 Standard or Datacenter
NOTE
Windows Server 2012 R2 is only supported on a SharePoint Server 2013 Service Pack 1 environment. For
additional information about Windows Server 2012 R2 support, see SharePoint 2013 SP1 support in Windows
Server 2012 R2.
The Setup program installs the following prerequisite for a single server with built-in database:
Microsoft SQL Server 2008 R2 SP1 - Express Edition
The Microsoft SharePoint Products Preparation Tool installs the following prerequisites for a single
server with built-in database:
SQL Server 2008 R2 SP1 Native Client
Windows Management Framework 3.0 which includes Microsoft PowerShell 3.0
Windows Identity Foundation (WIF ) 1.0 and Microsoft Identity Extensions (previously named WIF
1.1)
Windows Server AppFabric
NOTE
The required software above will be supported when used by SharePoint via the SharePoint Product
Lifecycle.
Minimum requirements for front-end web servers and application servers in a farm:
NOTE
At this time, Windows Server 2016 RTM is not supported.
or the 64-bit edition of Windows Server 2012 R2 Standard or Datacenter.
NOTE
Windows Server 2012 R2 is only supported on a SharePoint Server 2013 Service Pack 1 environment. For
additional information about Windows Server 2012 R2 support, see SharePoint 2013 SP1 support in Windows
Server 2012 R2.
The Microsoft SharePoint Products Preparation Tool installs the following prerequisites for front-end
web servers and application servers in a farm:
SQL Server 2008 R2 SP1 Native Client
Windows Identity Foundation (WIF ) 1.0 and Microsoft Identity Extensions (previously named WIF
1.1)
Windows Server AppFabric
A supported browser. For more information, see Plan browser support in SharePoint 2013. For information
on browsers supported on mobile devices, see Mobile device browsers supported in SharePoint 2013.
Minimum recommended services for development environments
The following are the minimum SharePoint 2013 services and service applications that are recommended for
development environments:
App Management service application
Central Administration web site
Claims to Windows Token service (C2WTS )
Distributed cache service
Microsoft SharePoint Foundation 2013 Site and Subscription Settings service
Secure Store Service
User Profile service application (SharePoint Server 2013 only)
Optional software
The optional software in this section is supported but is not required to install or use SharePoint 2013. This
software might be required by capabilities such as business intelligence. For more information about system
requirements for other capabilities, see Hardware and software requirements for other SharePoint 2013
capabilities.

Single server with built-in database, front-end web servers, .NET Framework Data Provider for SQL Server (part of
and application servers in a farm Microsoft .NET Framework)
.NET Framework Data Provider for OLE DB (part of Microsoft
.NET Framework)
Workflow Manager
You can install Workflow Manager on a dedicated computer.
Microsoft SQL Server 2008 R2 Reporting Services Add-in for
Microsoft SharePoint Technologies
2016.
edition
64-bit edition
Microsoft SQL Server 2012 with Service Pack 1 (SP1)
LocalDB 64-bit edition
Microsoft SQL Server 2008 R2 Remote Blob Store which is
part of the Microsoft SQL Server 2008 R2 Feature Pack
SQL Server 2008 R2 Analysis Services ADOMD.NET
KB 2472264
If you are running a geo-distributed deployment and your
servers are running Windows Server 2008 R2, then installing
KB 2472264 can optimize network latency in a dedicated
datacenter network. For more information, and to download
the software, see You cannot customize some TCP
configurations by using the netsh command in Windows
Server 2008 R2.
Client computer Windows 7

For information about how to use Windows 7 with
SharePoint 2013 in a development environment, see Start:
Set up the development environment for SharePoint 2013.
Silverlight 3
Office 2016
Microsoft Office 2010 with Service Pack 2
With KB 2553248
Microsoft Office 2007 with Service Pack 2
With KB 2583910
Microsoft Office for Mac 2011 with Service Pack 1
Microsoft Office 2008 for Mac version 12.2.9
Support ends April 9, 2013.

To install Windows Server 2008 R2 SP1, Windows Server 2012, SQL Server, or SharePoint 2013, you can go
to the web sites that are listed in this section. You can install most software prerequisites through the
SharePoint 2013 Start page. The software prerequisites are also available from web sites that are listed in this
section. You can enable the Web Server (IIS ) role and the Application Server role in Server Manager.
In scenarios where installing prerequisites directly from the Internet is not possible you can download the
Windows 7 and Windows Server 2008 R2 Service Pack 1 (SP1) (KB 976932)
Microsoft SharePoint Server 2013
Microsoft SharePoint Foundation 2013
Office 365 Enterprise
Windows Server 2012 and Windows 8 (KB 2765317)
Windows Server 2012, Datacenter Edition or Standard Edition
Microsoft SQL Server 2008 R2 Service Pack 1
Microsoft SQL Server 2008 R2 SP1 - Express Edition
Workflow Manager
WCF Data Services 5.0 for OData
Windows Identity Foundation 1.0 for Windows Server 2008 R2
Windows Identity Extensions for Windows Server 2008 R2
Microsoft SQL Server 2008 R2 Feature Pack which includes the Microsoft SQL Server 2008 R2 SP1
Native Client and the SQL Server Remote BLOB Store
Microsoft SQL Server 2008 R2 SP1 Feature pack which includes Microsoft SQL Server 2008 R2
ADOMD.NET
Microsoft Silverlight 3
Microsoft SQL Server 2012 Native Client 64-bit edition - ENU\x64\sqlncli.MSI
Microsoft SQL Server 2012 Data-Tier Application (DAC ) Framework 64-bit edition -
ENU\x64\dacframework.msi
Microsoft SQL Server 2012 Transact-SQL ScriptDom 64-bit edition - SQLDOM.msi
Microsoft System CLR Types for Microsoft SQL Server 2012 64-bit edition - SQLSysClrTypes.msi
Microsoft SQL Server 2012 with Service Pack 1 (SP1) LocalDB 64-bit edition, which is also a component
of SQL Server 2012 with Service Pack 1 (SP1) Express - ENU\x64\SqlLocalDB.msi

The SharePoint 2013 prerequisite installer (prerequisiteinstaller.exe) installs the following software, if it has not
already been installed on the target server, in this order:
1. Microsoft .NET Framework version 4.5
2. Windows Management Framework 3.0
3. Application Server Role, Web Server (IIS ) Role
4. Microsoft SQL Server 2008 R2 SP1 Native Client
5. Windows Identity Foundation (KB974405)
7. Windows Identity Extensions
8. Microsoft Information Protection and Control Client
10. Windows Server AppFabric
prerequisiteinstaller.exe at a command prompt, you may be asked to restart the server one or more times
during the installation process. After rebooting, you should continue the prerequisite installation by running
/? Display command-line options
/continue This is used to tell the installer that it is continuing from a restart
/unattended No user interaction
The installer installs from the file that you specify in the command-line options described in the following list. In
this list, < file> signifies the file from which you want to install. If you do not specify the < file> option, the
installer downloads the file from the Internet and installs it. If the option does not apply to the current operating
system, it is ignored.
/SQLNCli:< file> Install Microsoft SQL Server 2008 SP1 Native Client from < file>
/PowerShell:< file> Install Windows Management Framework 3.0 from < file>
/NETFX:< file> Install Microsoft .NET Framework version 4.5 from < file>
/IDFX:< file> Install Windows Identity Foundation (KB974405) from < file>
/IDFX11:< file> Install Windows Identity Foundation v1.1 from < file>
/Sync:< file> Install Microsoft Sync Framework Runtime SP1 v1.0 (x64) from < file>
/AppFabric:< file> Install Windows Server AppFabric from < file> (AppFabric must be installed with
the options /i CacheClient,CachingService,CacheAdmin /gac)
/KB2671763:< file> Install Microsoft AppFabric 1.1 for Windows Server (AppFabric 1.1) from < file>
/MSIPCClient:< file> Install Microsoft Information Protection and Control Client from < file>
/WCFDataServices:< file> Install Microsoft WCF Data Services from < file>
Windows AppFabric
/quiet
Plan browser support in SharePoint 2013
SharePoint 2013 supports several commonly used web browsers, such as Internet Explorer, Google
Chrome, Mozilla Firefox, and Apple Safari. However, certain web browsers could cause some SharePoint
2013 functionality to be downgraded, limited, or available only through alternative steps.
As you plan your deployment of SharePoint 2013, we recommend that you review the browsers used in your
organization to guarantee optimal performance with SharePoint 2013.

Browser support is an important part of your SharePoint 2013 implementation. Before you install SharePoint
2013, make sure that you know the browsers that SharePoint 2013 supports. The information in this article
describes browser support in the following sections:
Browser support matrix
Browser details
Browser support matrix
Microsoft Edge X
Google Chrome (latest released version) X
Mozilla Firefox (latest released version) X
Browser details
Review the details of the web browser that you have or plan to use in your organization to make sure that the web
browser works with SharePoint 2013 and according to your business needs.
Supported 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.
Microsoft Edge, Internet Explorer 11, Internet Explorer 10, Internet Explorer 9, Internet Explorer 8
NOTE
Internet Explorer 11 edge mode is not supported. Add sites to the Compatibility View list to make some features work.
NOTE
Microsoft Edge is supported with the SharePoint Server 2013 December 2015 CU. For additional information about the
December 2015 CU, see December 8, 2015, update for SharePoint Foundation 2013 (KB3114352)
Other supported browsers

Google Chrome (latest released version)
Mozilla Firefox (latest released version plus immediate previous version)
For example, if the latest released version is 10, then version 9 would be supported.
Apple Safari (latest released version)
ActiveX controls
Some functionality in SharePoint 2013 requires 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.
NOTE
Internet Explorer 10 does not support Active X controls when in immersive mode. The functionality for the controls listed
below should only be expected to work in desktop mode.
Plugin name DLL Filename What it does Supported browser Known limitations
version
Digital Signature Dsigctrl.dll, dsigres.dll Digital signing takes Internet Explorer An inability to verify a
place in both the versions 8, 9 and 10 form produces an
InfoPath client and on error that states that
the InfoPath Forms the form cannot be
Services server. Make signed.
sure that the
exist:
on the client can be
verified on the server.
on the server can be
verified on the client.
NameCtrl Name.dll Enables a web page Supported in Internet
to display a contact Explorer versions 8, 9,
card and presence and 10.
status for people. Firefox, Google
Integrates through Chrome are also
client-side APIs with supported by using a
Office 2016. plug-in.
Internet Explorer
version 10 immersive
mode is not
supported.
TaskLauncher Nameext.dll Used to export items All browsers If software

in a task list to Project requirements are not
Server if Project 2010 met, an error
is installed on the message states that
client computer. you need to install
Project Server.
SpreadSheetLauncher Owssupp.dll Used to verify Internet Explorer If Excel is not installed,

whether Excel is versions 8, 9, and 10 an error message
installed for Export to states that a list
Excel feature. cannot be imported
because a compatible
spreadsheet
application is not
installed or is not
compatible with the
browser.
StssyncHandler Owssupp.dll Enables Internet Explorer

synchronization of versions 8, 9, and 10
lists of events and
lists of contacts in
SharePoint with a
messaging application
such as Outlook
2016.
ExportDatabase Owssupp.dll Enables a user to use Internet Explorer To export a list, the
an application such as versions 8, 9, and 10 client computer must
Access to create or have a SharePoint
list data.
OpenDocuments Owssupp.dll Starts Office client All except Internet If a compatible Office
applications so that a Explorer version 10 in application or browser
user can create a immersive mode. is not installed on a
document or edit a client, an error
document. Enables message states that
users to create the feature requires a
documents that are SharePoint
based on a specified compatible
template, open application and web
documents as read- browser.
only, or open
documents as
read/write.
UploadCtl Stsupld.dll Enables drag-and- Internet Explorer
drop in SharePoint versions 8 and 9.
2013 visual mode
"upload multiple files"
dialog box.
CopyCtl Stsupld.dll Enables a user to Internet Explorer In Firefox, Google

copy a document on versions 8, 9, and 10 Chrome, and
a SharePoint site to immersive mode of
one or more locations Internet Explorer
on a server. version 10, the copy
not displayed.
PPActiveX PPSLAX.dll Starts PowerPoint to Internet Explorer Does not work on

open presentations versions 8, 9, and 10 Click-to-Run
slides to a slide that run on Windows
library. for ARM.
BCSLauncher BCSLaunch.dll Starts the Visual Internet Explorer

Studio Tools for Office versions 8, 9, and 10
installer to install a
Visual Studio Tools for
Office package that
has been generated
on the server.

To learn about the different mobile device browsers supported, see Mobile device browsers supported in
SharePoint 2013
See also
Other Resources
Plan for SharePoint Server
IP support in SharePoint 2013

SharePoint Server 2013 supports the following environments:
IPv4-only
In an IPv4-only environment, the network infrastructure supports address assignment, name registration
and resolution, and routing for only IPv4-based network traffic. Note that even in an IPv4-only
environment, the recommendation is that you leave IPv6 enabled on your Windows-based computers. If the
network infrastructure does not support IPv6 traffic, SharePoint will use IPv4 traffic.
Mixed IPv4 and IPv6
In a mixed IPv4 and IPv6 environment, the network infrastructure supports address assignment, name
registration and resolution, and routing for both IPv4 and IPv6-based network traffic.
IPv6-only
In an IPv6-only environment, the network infrastructure supports address assignment, name registration
and resolution, and routing for only IPv6-based network traffic.
In a SharePoint environment, "mixed" can be defined as one of the following likely scenarios:
Both IPv4 and IPv6 protocols are running on hosts. This is also known as a dual-stack environment, in
which both the IPv4 and IPv6 protocol stacks are enabled and being used.
Some of your client computers are using only IPv4, some of them are using only IPv6, and some of them
are using both IPv4 and IPv6.
Your client computers are using only IPv4, but the server computers are using both IPv4 and IPv6.
By default, the IPv6 protocol and the IPv4 protocol are both installed and enabled in Windows 8, Windows Server
2012, Windows 7, Windows Server 2008 R2, Windows Vista, and Windows Server 2008. When both IPv4 and
IPv6 are enabled, IPv6 is preferred over IPv4 when you are using names and Domain Name System (DNS ) name
query responses contain both types of addresses. Additionally, you can remove the IPv4 protocol so that the
computer runs only IPv6.
To determine what versions are being used on your network, you can use the IPConfig.exe tool. If the display of the
IPConfig command at a Command Prompt contains rows named "IPv6 Address" or "Temporary IPv6 Address,"
you have IPv6 in your environment. If all of the IPv6 addresses begin with "fe80" and correspond to rows named
"Link-Local IPv6 Address," you do not have IPv6 in your environment. For additional information, see IPConfig.
The following list shows other important considerations about IPv6:
For any computer that is authenticated by using a domain controller and is only running IPv6 in a
SharePoint Server 2013 environment, the domain controller must be running Windows Server 2012,
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 for
All versions of SQL Server supported for SharePoint Server 2013 also support IPv6. For more information
about IPv6 support for SQL Server 2008, see Connecting Using IPv6 (https://go.microsoft.com/fwlink/p/?
LinkId=183115).
When SharePoint Server 2013 uses the IPv6 protocol, all end-user URLs must be based on DNS names
with AAAA records. For more information about AAAA records, see Adding a Resource Record to a
Forward Lookup Zone.
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, you can enter IPv6 literal
addresses for certain farm administration tasks, such as entering the server name when you create or attach
databases. For server names that use a literal address format, you must enclose the literal address within
square brackets.
When specifying an outbound Simple Mail Transfer Protocol (SMTP ) server, SharePoint does not support
the configuration of IPv6 literal addresses. The recommendation is to specify a DNS name for the SMTP
server, which can resolve to an IPv4 address, an IPv6 address, or both. If you do not have a DNS name for
the SMTP server and must supply an IPv6 address, you can configure the corresponding ipv6-literal.net
name for the address.
To create an ipv6-literal.net name for an IPv6 address, convert the colons (:) in the address to dashes (-),
then add the result to "ipv6-literal.net". For example, for the IPv6 address
2001:db8:28:3:f98a:5b31:67b7:67ef, the corresponding ipv6-literal.net name is 2001-db8-28-3-f98a-5b31-
67b7-67ef.ipv6-literal.net.
Some SharePoint features or components integrate with cloud services - such as SharePoint Help,
SharePoint Translation Service, and SharePoint apps that use the Azure Access Control Service (ACS ) -
which might not yet be IPv6-capable. Therefore, make sure that your SharePoint servers are IPv4-capable,
which includes both IPv4-only and mixed IPv4 and IPv6 environments, until all of the SharePoint-
dependent cloud services become IPv6-capable. For more information, see [IPv6 Support in Office 365
Services] (https://docs.microsoft.com/en-us/office365/enterprise/ipv6-support ) and Internet Protocol
Version 6 (IPv6) Overview.
For additional information about IPv6 in Microsoft products, see the IPv6 TechCenter.
See also
Other Resources
IPv6 Survival Guide in the TechNet Wiki
Software boundaries and limits for SharePoint 2013

This article describes software boundaries and limits of SharePoint Server 2013. These include the following:
Boundaries: Static limits that cannot be exceeded by design
Thresholds: Configurable limits that can be exceeded to accommodate specific requirements
Supported limits: Configurable limits that have been set by default to a tested value
IMPORTANT
Some values in this article are based on test results from SharePoint 2010 Products and may not represent the final values
for SharePoint Server 2013. This article will be updated with appropriate values as SharePoint Server 2013 test data
becomes available. > For information about current hardware and software requirements, see Hardware and software
requirements for SharePoint 2013.
NOTE
The capacity planning information in this document provides guidelines for you to use in your planning. It is based on
testing performed at Microsoft, on live properties. However, your results are likely to vary based on the equipment you use
and the features and functionality that you implement for your sites.
Overview of boundaries and limits

This article contains information to help you understand the tested performance and capacity limits of SharePoint
Server 2013, and offers guidelines for how limits relate to acceptable performance. Use the information in this
article to determine whether your planned deployment falls within acceptable performance and capacity limits,
and to appropriately configure limits in your environment.
The test results and guidelines provided in this article apply to a single SharePoint Server 2013 farm. Adding
servers to the installation might not increase the capacity limits of the objects that are listed in the tables in the
Limits and boundaries section later in this topic. On the other hand, adding server computers increases the
throughput of a server farm, which might be necessary to achieve acceptable performance with many objects. In
some cases, the requirements for high numbers of objects in a solution might require more servers in the farm.
Note that there are many factors that can affect performance in a given environment, and each of these factors
can affect performance in different areas. Some of the test results and recommendations in this article might be
related to features or user operations that do not exist in your environment, and therefore do not apply to your
solution. Only thorough testing can give you exact data related to your own environment.
Boundaries, thresholds and supported limits
In SharePoint Server 2013, there are certain limits that are by design and cannot be exceeded, and other limits
that are set to default values that may be changed by the farm administrator. There are also certain limits that are
not represented by a configurable value, such as the number of site collections per web application.
Boundaries are absolute limits that cannot be exceeded by design. It is important to understand these
limits to ensure that you do not make incorrect assumptions when you design your farm.
An example of a boundary is the 2 GB document size limit; you cannot configure SharePoint Server 2013
to store documents that are larger than 2 GB. This is a built-in absolute value, and cannot be exceeded by
design.
Thresholds are those that have a default value that cannot be exceeded unless the value is modified.
Thresholds can, in certain circumstances, be exceeded to accommodate variances in your farm design, but
it is important to understand that doing this may affect the performance of the farm in addition to the
effective value of other limits.
The default value of certain thresholds can only be exceeded up to an absolute maximum value. A good
example is the document size limit. By default, the default document size threshold is set to 250MB, but
can be changed to support the maximum boundary of 2GB.
Supported limits define the tested value for a given parameter. The default values for these limits were
defined by testing, and represent the known limitations of the product. Exceeding supported limits may
cause unexpected results, significant decrease in performance, or other harmful effects.
Some supported limits are configurable parameters that are set by default to the recommended value,
while other supported limits relate to parameters that are not represented by a configurable value.
An example of a supported limit is the number of site collections per farm. The supported limit is the largest
number of site collections per web application that met performance benchmarks during testing.
curve that describes an increasing resource load and concomitant decrease in performance as the value increases.
Therefore, exceeding certain limits, such as the number of site collections per web application, may only result in
a fractional decrease in farm performance. However, in most cases, operating at or near an established limit is not
a best practice, as acceptable performance and reliability targets are best achieved when a farm's design provides
for a reasonable balance of limits values.
limits may be affected. Many limits in SharePoint Server 2013 can be changed, but it is important to understand
In SharePoint Server 2013, thresholds and supported limits are established through testing and observation of
farm behavior under increasing loads up to the point where farm services and operations reach their effective
operational limits. Some farm services and components can support a higher load than others so that in some
cases you must assign a limit value based on an average of several factors.
Therefore, the maximum value assigned to the number of site collections is not absolute, but is calculated based
on an expected set of usage characteristics in which overall farm performance would be acceptable at the given
limit under most circumstances.
Obviously, if some services are operating under parameters that are higher than those used for limits testing, the
maximum effective limits of other services will be reduced. It is therefore important to execute rigorous capacity
management and scale testing exercises for specific deployments in order to establish effective limits for that
environment.
Note: We do not describe the hardware that was used to validate the limits in this document, because the limits
were collected from multiple farms and environments.
The Pie Metaphor
In order to understand the relationship between hardware resources, load and performance, it's important to
have a way to visualize the factors involved and how they affect each other.
Consider the capacity of a farm as a pie, the size of which represents the aggregate of factors such as servers,
hardware resources such as CPUs and RAM, storage capacity, disk IOPS, network bandwidth and latency. The
size of the pie is therefore related to the overall resources of the farm; adding resources (such as farm servers)
increases the size of the pie.
This pie is divided into slices that represent load from a variety of sources: user requests, search queries,
operations against installed features, timer jobs and operating system overhead. Each of these sections must
share available farm resources. If the size of one slice increases, the size of others must decrease proportionally.
Since load on a farm is not static (user requests, for example, might only be significant during certain hours of the
day), the relative size of the slices is constantly in flux. However, each slice must maintain a required minimum
size to operate normally, and since the functions represented by each slice are interdependent, increasing the size
of one slice may place more load on other slices in addition to reducing the resources available for them to
consume.
Using this metaphor, the goal of the farm's design is to make the pie large enough to accommodate the required
size of each pie slice under peak load.
Now, consider a scenario where user requests increase by 100% over baseline. Let's say that about half of the
requests are search queries, and the other half editing lists and documents. This increased load squeezes the
other pie slices, but some farm features must also work harder to compensate. The Search service has to process
more queries, most of which are handled by the cache, but some queries are passed on to the database servers,
increasing their load as well. If load on the database servers becomes too great, disk queue lengths will increase,
which in turn increases the latency of all other requests.
Limits and boundaries

This section lists the objects that can be a part of a solution and provides guidelines for acceptable performance
for each kind of object. Acceptable performance means that the system as tested can support that number of
objects, but that the number cannot be exceeded without some decrease in performance or a reduction in the
value of related limits. Objects are listed both by scope and by feature. Limits data is provided, together with
notes that describe the conditions under which the limit is obtained and links to additional information where
available.
Use the guidelines in this article to review your overall solution plans. If your solution plans exceed the
recommended guidelines for one or more objects, take one or more of the following actions:
Evaluate the solution to ensure that compensations are made in other areas.
Flag these areas for testing and monitoring as you build your deployment.
Redesign or partition the solution to ensure that you do not exceed capacity guidelines.
Limits by hierarchy
This section provides limits sorted by the logical hierarchy of a SharePoint Server 2013 farm.
Web application limits
The following table lists the recommended guidelines for web applications.

Web application 20 per farm Supported We recommended limiting

the number of web
applications as much as
possible. Create additional
host named site collections
where possible instead of
adding web applications.
Zone 5 per web application Boundary The number of zones

defined for a farm is hard-
coded to 5. Zones include
Default, Intranet, Extranet,
Internet, and custom.
Managed path for host- 20 per farm Supported Managed paths for host-
named site collections named site collections apply
at the farm level. Each
managed path that is
created can be applied in
any Web application.
Managed path for path- 20 per web application Supported Managed paths are cached
based site collections on the web server, and CPU
resources are used to
process incoming requests
against the managed path
list.
Managed paths for path-
based site collections apply
at the Web application level.
You can create a different
set of managed paths for
each Web application.
Exceeding 20 managed
paths per web application
adds more load to the web
server for each request.
If you plan to exceed twenty
managed paths in a given
web application, we
recommend that you test
for acceptable system
performance.
Solution cache size 300 MB per web application Threshold The solution cache allows
the InfoPath Forms service
to hold solutions in cache in
order to speed up retrieval
of the solutions. If the cache
size is exceeded, solutions
are retrieved from disk,
which may slow down
response times. You can
configure the size of the
solution cache by using the
SPInfoPathFormsService. For
more information, see Set-
SPInfoPathFormsService.
Web server and application server limits
The following table lists the recommended guidelines for web servers on the farm.
Application pools 10 per web server Threshold The maximum number is

determined by hardware
capabilities.
This limit is dependent
largely upon:
The amount of memory
allocated to the web servers
The workload that the farm
is serving, that is, the user
base and the usage
characteristics (a single
highly active application
pool can utilize 10 GB or
more)
Content database limits
The following table lists the recommended guidelines for content databases.
Number of content 500 per farm Supported The maximum number of

databases content databases per farm
is 500. With 500 content
databases per web
application, end user
operations such as opening
the site or site collections
are not affected. But
administrative operations
such as creating a new site
collection will experience
decrease in performance.
use PowerShell to manage
the web application when a
large number of content
databases are present,
because the management
interface might become slow
and difficult to navigate.
With 200GB per content
database, and 500 content
databases per farm,
supports 100TB of data per
farm.
Content database size 200 GB per content Supported We strongly recommended

(general usage scenarios) database limiting the size of content
databases to 200 GB, except
when the circumstances in
the following rows in this
table apply.
If you are using Remote
BLOB Storage (RBS), the
total volume of remote
BLOB storage and metadata
in the content database
must not exceed the 200GB
limit.
Content database size (all 4 TB per content database Supported Content databases of up to
usage scenarios) 4 TB are supported when
the following requirements
are met:
Disk sub-system
performance of 0.25 IOPS
per GB, 2 IOPS per GB is
recommended for optimal
performance.
You must have developed
plans for high availability,
disaster recovery, future
capacity, and performance
testing.
You should also carefully
consider the following
factors:
Requirements for backup
and restore may not be met
by the native SharePoint
Server 2013 backup for
content databases larger
than 200 GB. It is
recommended to evaluate
and test SharePoint Server
2013 backup and alternative
backup solutions to
determine the best solution
for your specific
environment.
It is strongly recommended
to have proactive skilled
administrator management
of the SharePoint Server
2013 and SQL Server
installations.
The complexity of
customizations and
configurations on
SharePoint Server 2013 may
necessitate refactoring (or
splitting) of data into
Seek advice from a skilled
professional architect and
perform testing to
determine the optimum
content database size for
your implementation.
Examples of complexity may
include custom code
deployments, use of more
than 20 columns in
property promotion, or
features listed as not to be
used in the over 4 TB
section below.
Refactoring of site
collections allows for scale
out of a SharePoint Server
2013 implementation across
This permits SharePoint
Server 2013
implementations to scale
indefinitely. This refactoring
will be easier and faster
when content databases are
less than 200 GB.
It is suggested that for ease
of backup and restore that
individual site collections
within a content database
be limited to 100 GB. For
more information, see Site
collection limits.
IMPORTANT: We do not
recommend the use of
content databases that
exceed 4 TB, except in
(described in the next row in
this table). If, in the future,
you need to upgrade your
installation, upgrading the
site collections within the
very difficult and time
consuming. > It is strongly
recommended that you
scale out across multiple
content databases, rather
than exceed 4 TB of data in
a single content database.
Content database size No explicit content database Supported Content databases with no
(document archive scenario) limit explicit size limit for use in
are supported when the
following requirements are
met:
You must meet all
requirements from the
"Content database size (all
usage scenarios)" limit
earlier in this table, and you
should ensure that you have
carefully considered all the
factors discussed in the
Notes field of that limit.
SharePoint Server 2013 sites
must be based on
Document Center or
Records Center site
templates.
Less than 5% of the content
in the content database is
accessed each month on
average, and less than 1% of
content is modified or
written each month on
average.
Do not use alerts,
workflows, link fix-ups, or
item level security on any
objects in the content
database.
Note: Document archive
configured to accept
documents from Content
Routing workflows.
large-scale document
repositories, see Estimate
performance and capacity
requirements for large scale
document repositories in
SharePoint Server 2010, and
the Typical large-scale
content management
scenarios section of the
article Enterprise content
storage planning
(SharePoint Server 2010).
Content database items 60 million items including Supported The largest number of items
documents and list items per content database that
has been tested on
SharePoint Server 2013 is
60 million items, including
documents and list items. If
you plan to store more than
60 million items in
SharePoint Server 2013, you
must deploy multiple
content databases.
Site collections per content 10,000 maximum (2,500 Supported We strongly recommended
database non-Personal site collections limiting the number of site
and 7,500 Personal Sites, or collections in a content
10,000 Personal Sites alone) database to 5,000. However,
up to 10,000 site collections
in a database are supported.
Note that in a content
database with up to 10,000
total site collections, a
maximum of 2,500 of these
can be non-Personal site
collections. It is possible to
support 10,000 Personal
site collections if they are
the only site collections
within the content database.
These limits relate to speed
of upgrade. The larger the
number of site collections in
a database, the slower the
upgrade with respect to
both database upgrade and
site collection upgrades.
The limit on the number of
is subordinate to the limit
on the size of a content
database that has more
than one site collection.
Therefore, as the number of
increases, the average size
of the site collections it
contains must decrease.
Exceeding the 5,000 site
collection limit puts you at
risk of longer downtimes
during upgrades. If you plan
to exceed 5,000 site
collections, we recommend
that you have a clear
upgrade strategy to address
outage length and
operations impact, and
obtain additional hardware
to speed up the software
updates and upgrades that
affect databases.
To set the warning and
maximum levels for the
number of sites in a content
database, use the
SPContentDatabase with
the -WarningSiteCount
parameter. For more
information, see [Set-
SPContentDatabase]/powers
hell/module/sharepoint-
server/Set-
SPContentDatabase?
Remote BLOB Storage (RBS) Time to first byte of any Boundary When SharePoint Server
storage subsystem on response from the NAS 2013 is configured to use
Network Attached Storage should remain within 40 RBS, and the BLOBs reside
(NAS) milliseconds 95% of the on NAS storage, consider
time. the following supported
limit.
From the time that
requests a BLOB, until it
receives the first byte from
the NAS, 95% of the time no
more than 40 milliseconds
can pass.
Site collection limits
The following table lists the recommended guidelines for site collections.
Site collections per farm 750,000 per farm (500,000 Supported The maximum
rooted with the Personal recommended number of
Sites template and 250,000 site per farm is 500,000 site
rooted with other sites collections containing only
types) one Personal Sites plus
250,000 site collections
containing any other for all
other site templates. The
Sites can all reside on one
web application, or can be
distributed across multiple
web applications.
Note that this limit is
affected by other factors
that might reduce the
effective number of site
collections that can be
supported by a given
content database. Care
must be exercised to avoid
exceeding supported limits
when a container object,
such as a content database,
other objects. For example, if
a farm contains a smaller
total number of content
databases, each of which
site collections, farm
performance might be
adversely affected long
before the supported limit
for the number of site
collections is reached.
For example, Farm A
contains a web application
that has 200 content
databases, a supported
configuration. If each of
these content databases
contains 1,000 site
collections, the total number
LIMIT MAXIMUM VALUE LIMIT TYPE application
NOTES will be 200,000,
which falls within supported
limits. However, if each
content database contains
10,000 site collections, even
though this number is
supported for a content
database, the total number
of site collections in the farm
will be 2,000,000, which
exceeds the limit for the
number of site collections
per web application and per
farm.
Memory usage on the web
servers should be
monitored, as memory
usage is dependent on
usage patterns and how
many sites are being
accessed in given timeframe.
Similarly, the crawl targets
might also exhibit memory
pressure, and if so the
application pool should be
configured to recycle before
available memory on any
web server drops to less
than 2 GB.
Web site 250,000 per site collection / Supported The maximum

250,000 per farm / 500,000 recommended number of
personal sites per farm. web sites is 500,000 sites
based on the Personal Site
template, and 250,000 sites
based on all other
templates. This limit applies
per site collection as well as
per farm.
Performance can degrade as
surpasses 2,000 at the site
collection level.
IMPORTANT: Staying below
2,000 subsites per site
collection is strongly
recommended. You can
create a very large total
number of web sites by
creating multiple site
collections with up to 2,000
webs per site collection. For
example, 125 site collections
that contain 2,000 webs
each will equate to 250,000
sites in the farm. However,
this would be considered
the maximum
recommended limit for non-
personal sites.
If you have 250,000 site
collections, all containing a
root web site that is not the
Personal Site template,
adding a sub-site to any of
those root sites would
exceed the 250,000 web site
boundary.
If the recommended limit of
2,000 sites per site
collection is exceeded, the
following issues may occur:
Deleting or creating a site or
subsite can significantly
affect a site's availability.
Access to the site and
subsites will be limited while
the site is being deleted.
Attempting to create many
subsites at the same time
may also fail.
When having more than
2,000 subsites, the
performance of actions such
as executing PSConfig when
adding a new server to an
existing farm, or after
installing SharePoint
updates the drastically
decrease.
Executing the stsadm -o
checklocalupgradestatus
operation, or the daily
execution of the Product
Version Job timer job may
take many hours to
complete.
Browsing the Review
database status page
(<your_SharePoint_CentralA
dmin_URL>/_admin/Upgrad
eStatus.aspx) on the Central
Administration web site may
result in a timeout.
Site collection size Maximum size of the Supported A site collection can be as
content database large as the content
database size limit for the
applicable usage scenario.
the different content
database size limits for
specific usage scenarios, see
the Content database limits
table in this article.
In general, we strongly
recommend limiting the size
of site collections to 100 GB
for the following reasons:
Certain site collection
actions, such as site
collection backup/restore or
the PowerShell cmdlet
Move-SPSite, cause large
SQL Server operations which
can affect performance or
fail if other site collections
are active in the same
database. For more
information, see Move-
SPSite.
SharePoint site collection
backup and restore is only
supported for a maximum
site collection size of 100
GB. For larger site
collections, the complete
content database must be
backed up. If multiple site
collections larger than 100
GB are contained in a single
content database, backup
and restore operations can
take a long time and are at
risk of failure.
Number of device channels 10 Boundary The maximum allowed

per publishing site collection number of device channels
per publishing site collection
is 10.
List and library limits
The following table lists the recommended guidelines for lists and libraries. For more information, see Designing
large Lists and maximizing list performance (SharePoint Server 2010).

List row size 8,000 bytes per row Boundary Each list or library item can
only occupy 8,000 bytes in
total in the database. 300
bytes are reserved, leaving
7700 bytes for end-user
columns. For details on how
much space each kind of
field consumes, see Column
limits.
File size 2 GB Boundary The default maximum file

size is 250 MB. This is a
configurable limit that can
be increased up to 2 GB
(2,047 MB). However, a
large volume of very large
files can affect farm
performance.
Documents 30,000,000 per library Supported You can create very large
document libraries by
nesting folders, or using
standard views and site
hierarchy. This value may
vary depending on how
documents and folders are
organized, and by the type
and size of documents
stored.
Major versions 400,000 Supported If you exceed this limit, basic

file operations—such as file
open or save, delete, and
viewing the version history
— may not succeed.
This value is set on the
library level for files.
Minor versions 511 Boundary The maximum number of

minor file versions is 511.
This limit cannot be
exceeded.
This value is set on the
library level for files.
Items 30,000,000 per list Supported You can create very large
lists using standard views,
site hierarchies, and
metadata navigation. This
value may vary depending
on the number of columns
in the list and the usage of
the list.
Bulk operations 100 items per bulk Boundary The user interface allows a
operation maximum of 100 items to
be selected for bulk
operations.
List view lookup threshold 12 join operations per query Threshold Specifies the maximum
number of joins allowed per
query, such as those based
on lookup, person/group, or
workflow status columns. If
the query uses more than
eight joins, the operation is
blocked. This does not apply
to single item operations.
When using the maximal
view via the object model
(by not specifying any view
fields), SharePoint will return
up to the first 12 lookups.
Note: After applying the
cumulative update package
released on August 13,
2013
(https://support.microsoft.co
m/en-us/kb/2817616), the
default value is increased
from 8 to 12.
List view threshold 5,000 Threshold Specifies the maximum

number of list or library
time outside the daily time
window set by the
administrator during which
queries are unrestricted.
List view threshold for 20,000 Threshold Specifies the maximum

auditors and administrators number of list or library
time when they are
performed by an auditor or
administrator with
appropriate permissions.
This setting works with
Allow Object Model
Override.
Note: This threshold needs
to be enabled by using
custom code to set the
SPQueryThrottleOption.
Subsite 2,000 per site view Threshold The interface for

enumerating subsites of a
given web site does not
perform well as the number
of subsites surpasses 2,000.
Similarly, the All Site
Content page and the Tree
View Control performance
will decrease significantly as
grows.
Coauthoring in Word, 10 concurrent editors per Threshold Recommended maximum

PowerPoint and Excel for document number of concurrent
.docx, .pptx, .ppsx and .xlsx editors is 10. The boundary
files is 99.
If there are 99 co-authors
who have a single document
opened for concurrent
editing, each successive user
sees a "File in use" error, and
can only open a read-only
copy.
More than 10 co-editors will
lead to a gradually degraded
user experience with more
conflicts, and users might
have to go through more
iterations to successfully
upload their changes to the
server.
Security scope 50,000 per list Threshold The maximum number of

unique security scopes set
for a list cannot exceed
50,000.
For most farms, we
recommend that you
consider lowering this limit
to 5,000 unique scopes. For
large lists, consider using a
design that uses as few
unique permissions as
possible.
When the number of unique
security scopes for a list
exceeds the value of the list
view threshold (set by
default at 5,000 list items),
additional SQL Server round
trips take place when the list
is viewed, which can
adversely affect list view
performance.
A scope is the security
boundary for a securable
object and any of its
children that do not have a
separate security boundary
defined. A scope contains an
Access Control List (ACL),
but unlike NTFS ACLs, a
scope can include security
principals that are specific to
SharePoint Server 2013. The
members of an ACL for a
scope can include Windows
users, user accounts other
than Windows users (such
as forms-based accounts),
Active Directory groups, or
SharePoint groups.
Column limits
SharePoint Server 2013 data is stored in SQL Server tables. Each column type has a size value listed in bytes. The
sum of all columns in a SharePoint list cannot exceed 8,000 bytes.
Single line of text 255 Threshold 30 bytes
Multiple Lines of Text 350 Threshold 22 bytes
Choice 255 Threshold 30 bytes
Choice (multiple 350 Threshold 22 bytes

selection)
Number 550 Threshold 14 bytes

Currency 550 Threshold 14 bytes
Date and Time 550 Threshold 14 bytes
Lookup 750 Threshold 10 bytes
Yes / No 1000 Threshold 7 bytes
Person or group 750 Threshold 10 bytes
Hyperlink or picture 127 Threshold 60 bytes
Calculated 255 Threshold 30 bytes
GUID 350 Threshold 22 bytes
Int 750 Threshold 10 bytes
Managed metadata 190 Threshold 60 bytes for the first, The first Managed
40 bytes for each Metadata field added
subsequent to a list is allocated
four columns:
actual tag
the string value
catch all
A lookup field for
spillover of the catch
all
Each subsequent
Managed Metadata
field added to a list
adds two more
columns:
actual tag
the string value
Geolocation 2 Threshold 30 bytes
External Data columns have the concept of a primary column and secondary columns. When you add an external
data column, you can select some secondary fields of the external content type that you want to be added to the
list. For example, given an External Content Type "Customer" which has fields like "ID", "Name", "Country", and
"Description", when you add an External Data column of type "Customer" to a list, you can add secondary fields
to show the "ID", "Name" and "Description" of the Customer. Overall these are the columns that get added:
Primary column: A text field.
Hidden Id column: A multi-line text field.
Secondary columns: Each secondary column is a text/number/Boolean/multi-line text that is based on the
data type of the secondary column as defined in the Business Data Catalog model. For example, ID might
be mapped to a Number column; Name might be mapped to a Single line of text column ; Description
might be mapped to a Multiple lines of text column.
Page limits
The following table lists the recommended guidelines for pages.
Web parts 25 per wiki or Web Part Threshold This figure is an estimate
page based on simple Web Parts.
The complexity of the Web
Parts dictates how many
Web Parts can be used on a
page before performance is
affected.
Security limits
Number of SharePoint 5,000 Supported This is not a hard limit but it

groups a user can belong to is consistent with Active
Directory guidelines. There
are several things that affect
this number:
The size of the user token
The groups cache:
SharePoint Server 2013 has
a table that caches the
number of groups a user
belongs to as soon as those
groups are used in access
control lists (ACLs).
The security check time: as
the number of groups that a
user is a member of
increases, the time that is
required for the access
check increases also.
Users in a site collection 2 million per site collection Supported You can add millions of
people to your web site by
using Microsoft Windows
security groups to manage
security instead of using
individual users.
This limit is based on
manageability and ease of
navigation in the user
interface.
When you have many
entries (security groups of
users) in the site collection
(more than one thousand),
you should use PowerShell
to manage users instead of
the UI. This will provide a
better management
experience.
Active Directory 5,000 per SharePoint group Supported SharePoint Server 2013
Principles/Users in a enables you to add users or
SharePoint group Active Directory groups to a
SharePoint group.
Having up to 5,000 users
(or Active Directory groups
or users) in a SharePoint
group provides acceptable
performance.
The activities most affected
by this limit are as follows:
Fetching users to validate
permissions. This operation
takes incrementally longer
with growth in number of
users in a group.
Rendering the membership
of the view. This operation
will always require time.
SharePoint groups 10,000 per site collection Supported Above 10,000 groups, the
time to execute operations
is increased significantly. This
is especially true of adding a
user to an existing group,
creating a new group, and
rendering group views.
Security principal: size of the 5,000 per Access Control Supported The size of the scope affects
Security Scope List (ACL) the data that is used for a
security check calculation.
This calculation occurs every
time that the scope
changes. There is no hard
limit, but the bigger the
scope, the longer the
calculation takes.
Limits by feature
This section lists limits sorted by feature.
Search limits
The recommended guidelines for search are organized according to the aspects of search that they impact: the
topology, the size of items, dictionaries, crawling, schema, queries and results, ranking, and the index.
NOTE
Limits for Search have changed significantly as the feature has been updated. For more information, see Plan search in
SharePoint Server.
Search: topology limits

The topology limits ensure efficient communication between search components. Exceeding these limits slows
down the communication between search components, which can result in longer query latencies and ultimately
outage of search.
Analytics processing 6 per Search service Supported

components application; 1 per server
Analytics reporting 4 per Search service Threshold You can exceed this limit to
databases application accommodate specific
requirements. When scaling,
add an analytics reporting
database when the size of
any of the deployed
analytics databases reaches
250 GB total size, or 20 M
total rows. This way
repartitioning is as balanced
as possible.
Link databases 4 per Search service Supported The highest tested number
application of items a link database can
contain is 100 million.
Crawl components 16 per Search service Supported

application; 1 per server
Index components 60 per Search service Supported To calculate the number of

application; 4 per server index components you have,
multiply the number of
index partitions with the
number of index replicas.
For SharePoint Foundation
2013 , this limit is one index
component per Search
service application and
cannot be exceeded.
Index partitions 25 per Search service Supported An index partition holds a

application subset of the Search service
application index. Increasing
the number of index
partitions results in each
partition holding a smaller
subset of the index,
reducing the RAM and disk
space that is needed on the
servers hosting the index
components.
2013, the maximum number
of index components per
Search service application is
one, so the maximum
number of index partitions
per Search service
application is limited to one.
Index replicas 3 per index partition Supported Each index partition can
have a set of replica. If you
increase the number of
index replicas, this has a
positive effect on the query
performance and it provides
better fault tolerance. But, if
you add too many replicas
to your index partition, this
can adversely affect
indexing.
For Internet sites scenarios,
which typically have a high
query rate but low content
volume (less than 4 million
items per partition), the
supported limit is 6 index
replicas per partition.
of index components per
Search service application is
one, so the maximum
number of index partitions
per Search service
application is limited to one.
Content processing 1 per server Supported The search topology

components supports scaling out the
number of content
processing components.
Although a specific physical
host or virtual machine does
support multiple content
processing components, you
achieve better usage of the
CPU capacity by using one
content processing
component. The reason is
that a built-in mechanism
maximizes CPU usage by
adjusting the number of
feeding sessions according
to available CPU cores.
Multiple feeding sessions
allow the content processing
component to process
incoming documents in
parallel. This mechanism
assumes a single content
host.
If the number of physical
cores on the host equals N,
then the content processing
component will have NK
feeding sessions. K is a
constant coefficient with
the initial value 3. A 4-core
server will have 12 feeding
sessions, which means that
the content processing
component can process 12
documents in parallel. You
can change the value of K
by setting the
NumberOfCssFeedersPerC
PUForRegularCrawl
property of the Search
Service Application.
limits the value of N
upward to 12, even if a
server has more than 12
physical cores. Therefore a
16-core server will have NK
= 12 * 3 = 36 feeding
sessions.
In the case that there still is
idle CPU time, consider
increasing the K coefficient
instead of adding an
additional content
processing component. If
you increase the K
coefficient, you must make
sure that the host has
sufficient available memory.
Query processing 1 per server Supported SharePoint Server 2013 only

components supports one query
physical machine or virtual
machine.
Search components 64 per Search service Supported This limit does not include
application crawl components. The sum
of all the other search
components must stay
within this limit.
Search service applications 20 per farm Supported Multiple Search service

applications can be
deployed on the same farm,
because you can assign
search components and
databases to separate
servers. This limit is lower
than the limit for the total
number of service
applications in a farm.
Content sources 500 per Search service Boundary There is overhead associated
application with each content source, so
create the smallest number
of content sources that
satisfy your other
operational requirements,
for example differences in
crawl priority and
scheduling.
Search: item size limits

The item size limits safeguard crawling performance and the size of the index. Here are some examples of how
the limits can affect searching:
If you can't get results when you search for an item, the item could be too large. A warning will show up in
the Crawl Log, stating that the file exceeded the maximum size that the crawler can download.
If you search for text in an item and only get results from the first part of the text, the content processing
component may have truncated the item because it exceeded some of item size limits. When the content
processing component truncates an item, it indicates this by setting the managed property
IsPartiallyProcessed to True. A warning will also show up in the Crawl Log, stating why the item was
truncated.
If you tune item size limits, we recommend that you work with them in the order they appear in this table.

Document size crawl 64 MB (3 MB for Excel Threshold Search downloads meta

component can download documents) data and content from a
document until it reaches
size. The rest of the content
is not downloaded. Search
always downloads a
document's meta data.
You can change the default
limit for the maximum
document size. Do this by
using Microsoft PowerShell
cmdlets to change the
property
MaxDownLoadSize or
MaxDownloadSizeExcel.
MaxDownLoadSize doesn't
impact the maximum size
for Excel documents. Enter
the value in megabytes. The
maximum value for the
maximum document size is
1024 MB, also for Excel
documents.
If you increase the limit for
size, search indexes more
content and needs more
disk space.
Parsed content size 2 million characters Boundary Search stops parsing an

item after it has parsed up
to 2 million characters of
content from it, including
the item's attachments. The
actual amount of parsed
characters can be lower than
this limit because search
uses maximum 30 seconds
on parsing a single item and
its attachments. When
search stops parsing an
item, the item is marked as
partially processed. Any
unparsed content isn't
processed and therefore
isn't indexed.
Characters processed by the 1,000,000 Boundary Search breaks content into

word breaker individual words (tokens).
The word breaker produces
tokens from the first
1,000,000 characters of a
single item, including the
item's attachments. The
actual number of processed
characters can be lower than
this limit because search
uses maximum 30 seconds
on word breaking. Any
remaining content isn't
processed and therefore
isn't indexed.
Indexed managed property 512 KB per Threshold This is the default value for
size searchable/queryable the maximum size of a
managed property managed property that is
set to either "searchable" or
"queryable". You can
configure this limit by using
the
MP.MaxCharactersInProp
ertyStoreIndex attribute.
Enter the value in bytes. The
maximum value for this
maximum size is 2,097,152
bytes.
Indexing more data per
managed property uses
more disk space and
increases the overall load on
the search system.
Retrievable managed 16 KB per managed Threshold This is the default value for
property size property the maximum size of a
retrievable managed
property. You can configure
this limit per managed
property by using
the
P.MaxCharactersInPropert
yStoreForRetrievalattribut
e. Enter the value in bytes.
The maximum value for this
maximum size is 2,097,152
bytes.
Indexing and retrieving
property increases the
overall load on the system
and uses more disk space.
Sortable and refinable 16 KB per managed Boundary This is the maximum size of
managed property size property a sortable and refinable
managed property.
Token size Variable Boundary Search can index tokens of

any length. But the word
breaker that search uses to
produce tokens can limit the
token length. Word breakers
are language-aware
components that break
content into single words
(tokens). You can also create
custom word breakers. The
token size limit therefore
depends on the word
breaker.
Here's the limit of the word
breaker for western
languages:
The word breaker only
considers the first 1000
characters of a token for
splitting, it ignores any
remaining characters.
The word breaker splits
tokens that are longer than
300 characters into two or
more tokens where no
token has more than 300
characters. For example, a
612 character token is split
into two 300 character
tokens and one 12 character
token.
Search: dictionary limits

The dictionary limits safeguard memory, content processing efficiency, and query results.
Number of entries in a 1 million Supported The thesaurus contains

thesaurus synonyms for query terms.
Exceeding this tested limit
may result in increased use
of memory and an increased
query response time.
Number of entries in a 1 million Supported Exceeding this tested limit

custom entity extraction may result in increased use
dictionary of memory, slower indexing,
and an increased query
response time.
Number of entries in a 5,000 terms per tenant Boundary This limits the number of
custom search dictionary terms allowed for inclusions
and exclusions dictionaries
for query spelling correction
and company extraction.
You can store more terms
than this limit in the
Termstore, but search only
uses 5000 terms per tenant.
Search: schema limits

The schema limits safeguard memory resources and keep the management operation overhead at an acceptable
level.
Crawled properties 500,000 per Search service Supported The contents and metadata
application of the items that you crawl
are represented as crawled
properties. You can map
these crawled properties to
managed properties. If the
number of crawled
properties exceeds this
supported limit, this reduces
indexing speed.
Managed properties 50,000 per Search service Supported Search uses managed
application propertied in queries.
Crawled properties are
mapped to managed
properties. Exceeding the
supported limit for
managed properties reduces
indexing speed.
Managed property 100 per managed property Supported Crawled properties can be
mappings mapped to managed
properties. Exceeding this
limit might decrease crawl
speed and query
performance.
Values per managed 1000 Boundary A managed property can

property have multiple values of the
same type. This is the
maximum number of values
per managed multi-valued
managed property per
document. If this number is
exceeded, the remaining
values are discarded.
Metadata properties 100,000 per crawled item Supported This is the maximum
recognized number of metadata
properties that the crawl
component can determine
when crawling an item.
These metadata properties
can be mapped or used for
queries. Approaching this
number of crawled
properties might result in a
low crawl rate.
Search: crawl limits
Start addresses 500 per content source Supported
Length of machine host 15 characters Threshold NetBIOS limits the

name maximum machine host
name length to this value.
Crawl databases 15 per Search service Supported

application
Search: query and result limits

The limits for queries and results safeguard the search engine against executing very large query expressions and
returning very large result sets. Preventing the search engine from executing very large query expressions and
returning very large result sets prevents Denial-of-service (DoS ) attacks and makes sure that results return
timely. If you have to retrieve more results we recommend that you use paging.
Text length for queries using 4 KB (4,096 characters) Supported This is the tested and
Keyword Query Language default value for the
maximum text length for a
query built by using
Keyword Query Language,
except for Discovery queries.
For Discovery queries 16 KB
(16,384 characters) is the
default maximum value.
The default value for the
increased up to the
boundary of 20 KB (20,480)
for all query types.
Number of rows in a result 500 rows Supported This is the tested and
set default value for the
maximum number of rows
in a result set, except for a
Discovery query. For
Discovery queries 10,000
rows is the default value. To
display the entire result set,
issue more paging queries.
You can change the value
for the maximum number of
rows in a result set by using
PowerShell cmdlets to
change the Search service
application property
MaxRowLimit.
MaxRowLimit defines the
maximum value of the
query property RowLimit
and the Discovery query
property RowLimit.
RowLimit defines the
number of rows each page
contains in a result set. You
can increase MaxRowLimit
up to 10,000 rows, this is
the supported boundary.
Results removal No limit Supported
Search alert quota 100,000 alerts per Search Supported End-users can set search
service application alerts for the result set of a
query. When the results are
changed or updated, search
notifies the end-user. This is
the tested limit for a Search
a mix of end-user queries
(75%) and alert queries
(25%). The limit for a Search
only alert queries is 400,000
alerts. These limits are based
on a system with five
queries per second (QPS).
Search: ranking limits

The ranking limits safeguard application server memory, query latency, and the size of the index.
Ranking models 1,000 per tenant Boundary Approaching this limit can
adversely affect the overall
system performance.
Unique contexts used for 15 unique contexts per rank Boundary This is the maximum
ranking model number of unique contexts
per rank model.
Authoritative pages 1 top level and minimal Supported Use as few second- and
second and third level pages third-level pages as possible
per Search service while still achieving the
application desired relevance.
The boundary is 200
authoritative pages per
relevance level per Search
service application. If you
add more pages, you may
not achieve the desired
relevance. Add the key site
to the first relevance level.
Add more key sites at either
second or third relevance
levels, one at a time.
Evaluate relevance after
each addition to make sure
that that you have achieved
the desired relevance effect.
Search: index limits

The index limits safeguard the index from growing out of bounds and exceeding the available resources.
Unique terms in the index 2^31 (>2 billion terms) Boundary This is the maximum
number of unique terms
that can exist in the index of
a Search service application.
User defined full text 10 Boundary This is the maximum

indexes number of full text indexes.
Indexed items 10 million per index Supported Each index partition

partition contains a subset of the
whole search index. If the
number of indexed items is
high in relation to how
much memory the server
has, affects the query
response time negatively.
of indexed items is 2 million
items per index partition.
of indexed items is 2 million
items per index partition,
before applying the June
2016 Public Update. The
June 2016 Public Update,
increases this limit to 10
million items per index
partition.
User Profile Service limits
The following table lists the recommended guidelines for User Profile Service.
User profiles 2,000,000 per service Supported A user profile service

application application can support up
to 2 million user profiles
with full social features
functionality. This number
represents the number of
profiles that can be
imported into the people
profile store from a
directory service, and also
the number of profiles a
user profile service
application can support
without leading to
performance decreases in
social features.
Social tags, notes and 500,000,000 per social Supported Up to 500 million total
ratings database social tags, notes and
ratings are supported in a
social database without
significant decreases in
performance. However,
database maintenance
operations such as backup
and restore may show
decreased performance at
that point.
Content deployment limits
The following table lists the recommended guidelines for content deployment.
Content deployment jobs 20 Supported For concurrently running

running on different paths jobs on paths that are
connected to site collections
in the same source content
database, there is an
increased risk of deadlocks
on the database. For jobs
that must run concurrently,
move the site collections
into different source content
databases.
Note: Concurrent running
jobs on the same path are
not possible. If you are
using SQL Server snapshots
for content deployment,
each path creates a
snapshot. This increases the
I/O requirements for the
source database.
For more information, see
About deployment paths
and jobs.
Blog limits
The following table lists the recommended guidelines for blogs.
Blog posts 5,000 per site Supported The maximum number of

blog posts is 5,000 per site.
Comments 1,000 per post Supported The maximum number of

comments is 1,000 per post.
Business Connectivity Services limits
The following table lists the recommended guidelines for Business Connectivity Services.
ECT (in-memory) 5,000 per web server (per Boundary Total number of external
tenant) content type (ECT)
definitions loaded in
memory at a given point in
time on a web server.
External system connections 500 per web server Boundary Number of active/open
external system connections
at a given point in time. The
default maximum value is
200; the boundary is 500.
This limit is enforced at the
web server scope, regardless
of the kind of external
system (for example,
database, .NET assembly,
and so on) The default
maximum is used to restrict
the number of connections.
An application can specify a
larger limit via execution
context; the boundary
enforces the maximum even
for applications that do not
respect the default.
Database items returned 2,000 per database Threshold Number of items per
per request connector request the database
connector can return.
The default maximum of
2,000 is used by the
database connector to
restrict the number of result
that can be returned per
page. The application can
specify a larger limit via
Absolute Max enforces the
maximum even for
respect the default. The
boundary for this limit is
1,000,000.
Response latency 600 seconds Threshold Timeout used by the

external data connector per
request. The default value is
180 seconds, but
applications can be
maximum of 600 seconds.
Service response size 150,000,000 bytes Threshold The upper volume of data
per request the external
data connector can return.
The default value is
3,000,000 bytes, but
applications can be
maximum of 150,000,000
bytes.
Filter Descriptor (in-store) 200 per ECT method Boundary The maximum number of
Filter Descriptors per ECT
method is 200.
ECT Identifier (in-store) 20 per ECT Boundary The maximum number of

identifiers per ECT is 20.
Database Item 1,000,000 per request Threshold The default maximum

number of items per request
the database connector can
return is 2,000, and the
absolute maximum is
1,000,000.
The default max is used by
the database connector to
restrict the number of
results that can be returned
per page. The application
can specify a larger limit via
absolute max enforces the
allowed maximum even for
respect the default such as
indexing.
Workflow limits
The following table lists the recommended guidelines for workflow.

Workflow postpone 15 Threshold 15 is the maximum number

threshold of workflows allowed to be
executing against a content
database at the same time,
excluding instances that are
running in the timer service.
When this threshold is
reached, new requests to
activate workflows will be
queued to be run by the
workflow timer service later.
As non-timer execution is
completed, new requests will
count against this threshold.
This is limit can be
configured by using the Set-
SPFarmConfig PowerShell
cmdlet. For more
SPFarmConfig.
Note: This limit does not
refer to the total number of
workflow instances that can
be in progress. Instead, it is
the number of instances
that are being processed.
Increasing this limit
increases the throughput of
starting and completing
workflow tasks but also
increases load against the
content database and
system resources.
Workflow timer batch size 100 Threshold The number of events that
each run of the workflow
timer job will collect and
deliver to workflows. It is
configurable by using
PowerShell. To allow for
additional events, you can
run additional instances of
the SharePoint Foundation
Workflow Timer Service.
Workflow associations 100 per list Supported Exceeding this limit will
degrade browser
performance due to the
large volume of data that is
loaded for more than 100
associations and their status
columns.
List items or documents 5,000 items Supported Testing has verified that all
that can be bulk created or workflow activation events
uploaded to start workflow are processed for an on-
instances item-creation workflow
association when up to
5,000 items are created in a
single bulk upload.
Exceeding this limit could
cause workflow initiation to
time out.
Published workflow 1,000 per web site Supported The maximum supported
definitions per web site number of published
workflow definitions per web
site is 1,000.
Total workflow associations 1,799 per site Boundary The Service Bus supports a
per site maximum of 1,799
subscriptions per scope. This
maximum value includes the
sum of both published and
unpublished associations.
Maximum workflow 5,120 KB Boundary Attempts to publish xaml

definition (xaml) size files that exceed the size
limit will fail.
Maximum depth of a 121 levels Boundary There is a hard limit of 125

workflow sub-step in xaml for node depth in xaml. The
(workflow complexity) maximum value of 121
levels accounts for the
default activities (stage,
sequence, etc.) that
SharePoint Designer inserts
automatically.
Workflow instance 6 per second Threshold Testing has confirmed that a

activations per second per SharePoint web server can
web server activate a maximum of 6
workflow instances per
second. This number is
cumulative, and therefore
scales with the number of
web servers in the farm. For
example, 2 web servers can
activate 12 workflow
instances per second, and 3
web servers can activate 18.
Rest calls from SharePoint 60 per second Supported Testing has confirmed that a
workflow per second per SharePoint web server can
web server effectively process up to 60
rest calls per second from
SharePoint workflow. If this
level of volume will be
exceeded, we recommend
that an additional load-
balanced web server be
added to the SharePoint
farm. In testing, 120 rest
calls per second against a
single web server resulted in
sustained 90-100% CPU
utilization. Adding a second
web server reduced CPU
utilization to 30-40% on
both servers. Adding a third
web server enabled
processing of 180 calls per
second, with 30-40% CPU
utilization on all three
servers, and so on. The
servers used for this test
were Hyper-V virtual
machines with 16 core
processor and 24 GBs RAM
each.
Workflow variable value size 256 KB Boundary The maximum amount of

data that can be stored in a
single workflow variable is
256 KB. Exceeding this limit
will cause the workflow
instance to terminate.
Maximum list size for 5,000 items per list view Threshold This limit is a result of the
workflow lookups to non- maximum view size limit.
indexed fields When this limit is exceeded,
workflow lookups to non-
indexed fields will fail for
non-administrative users. At
this threshold, an index
must be created for the
field, in order for workflows
to be able to successfully
perform lookups against the
field.
Maximum list size for auto- 10 million items per list Supported Testing has confirmed that
start workflow associations the performance of auto-
start workflow associations
is not affected when list size
grows to 1 million items.
Because response time
doesn't change as list size
scales, the effective limit is
the same as the maximum
number of items in a non-
workflow list.
Managed Metadata limits
The following table lists the recommended guidelines for managed metadata configuration.
Number of folders with 1,000 folders per site, or Boundary Location-based default
location-based defaults data file size of 256 Mb metadata allows you to set
default values for list
columns per folder. You can
only apply location-based
default values on up to
1,000 folders per site, or up
to the point at which the
data file in which location-
based default metadata is
stored for the site
(client_LocationBasedDefault
s.html) reaches 265 Mb.
When the number of folders
in the data file exceeds
1,000, or the data file size
exceeds 256 Mb, default
values added for additional
folders will be ignored.
Number of links in or file 1,000 links or file size of 256 Boundary When a document
size of a document that are Mb per document containing links is added to
updated when the target a folder, SharePoint
location changes Foundation 2013 will
update links automatically
when the link target is
moved to a new location. In
a document with more than
1,000 links, or a document
with a file size that exceeds
256 Mb, the document is
treated as though it
contains no links, and
updates to link targets are
ignored for the entire
document.
Managed Metadata term store (database) limits
The following table lists the recommended guidelines for managed metadata term stores.
Maximum number of 7 Supported Terms in a term set

levels of nested terms can be represented
in a term store hierarchically. A term
set can have up to
seven levels of terms
(a parent term, and
six levels of nesting
below it.)
Maximum number of 1,000 Supported You can have up to

term sets in a term 1,000 term sets in a
store term store.
Note: Both local term
set and global term
set follow the limit of
30,000 terms per
term site. Use global
term sets to store the
reusable data for all
site collections,
instead of using a
large amount of site
collection term sets
or creating a new
Managed Metadata
service. A web
application can have
connections to
multiple services.
Maximum number of 30,000 Supported 30,000 is the

terms in a term set maximum number of
terms in a term set.
Note: Additional
labels for the same
term, such as
synonyms and
translations, do not
count as separate
terms.
Total number of items 1,000,000 Supported An item is either a

in a term store term or a term set.
The sum of the
number of terms and
term sets cannot
exceed 1,000,000.
Additional labels for
the same term, such
as synonyms and
translations, do not
count as separate
terms.
Note: You cannot
have both the
maximum number of
term sets and the
maximum number of
terms simultaneously
in a term store.
Number of Variation 209 per term store Supported The maximum

Labels number of Variation
Labels per term store
is 209.
Number of terms in 2,000 Supported The maximum

managed navigation supported number of
term set terms in a managed
navigation term set is
2,000.
See also Overview of Managed Metadata service in SharePoint 2013 and The impact of having multiple
Managed Metadata services per farm
Visio Services limits
The following table lists the recommended guidelines for instances of Visio Services in SharePoint.
File size of Visio web 50 MB Threshold Visio Services has a

drawings configuration setting that
change the maximum size of
web drawings that Visio
processes.
Larger file sizes have the
following side effects:
Increase in the memory
footprint of Visio Services.
Increase in CPU usage.
server requests per second.
Increase overall latency.
Increase SharePoint farm
network load
Visio web drawing 120 seconds Threshold Visio Services has a

recalculation time-out configuration setting that
change the maximum time
that it can spend
recalculating a drawing after
a data refresh.
A larger recalculation time-
out leads to:
Reduction in CPU and
Increase in average latency
A smaller recalculation time-
out leads to:
Reduction of the complexity
of diagrams that can be
displayed.
Increase in requests per
second.
Decrease in average latency
Visio Services minimum Minimum cache age: 0 to Threshold Minimum cache age applies
cache age (data connected 24hrs to data connected diagrams.
diagrams) It determines the earliest
point at which the current
diagram can be removed
from cache.
Setting Min Cache Age to a
very low value will reduce
throughput and increase
latency, because invalidating
the cache too often forces
Visio to recalculate often
and reduces CPU and
Visio Services maximum Maximum cache age: 0 to Threshold Maximum cache age applies
cache age (non-data 24hrs to non-data connected
connected diagrams) diagrams. This value
determines how long to
keep the current diagram in
memory.
Increasing Max Cache Age
decreases latency for
commonly requested
drawings.
However, setting Max Cache
Age to a very high value
increases latency and slows
throughput for items that
are not cached, because the
items already in cache
consume and reduce
available memory.
SharePoint Web Analytics service limits
The SharePoint Web Analytics service has been deprecated in SharePoint Server 2013.
PerformancePoint Services limits
The following table lists the recommended guidelines for PerformancePoint Services in SharePoint.
Cells 1,000,000 per query on Boundary A PerformancePoint

Excel Services data source scorecard that calls an Excel
Services data source is
subject to a limit of no more
than 1,000,000 cells per
query.
Columns and rows 15 columns by 60,000 rows Threshold The maximum number of
columns and rows when
rendering any
PerformancePoint
a Excel workbook as a data
number of columns.
Query on a SharePoint list 15 columns by 5,000 rows Supported The maximum number of
columns and row when
rendering any
PerformancePoint
a SharePoint list as a data
number of columns.
Query on a SQL Server data 15 columns by 20,000 rows Supported The maximum number of
source columns and row when
rendering any
PerformancePoint
a SQL Server table data
number of columns.
Word Automation Services limits
The following table lists the recommended guidelines for Word Automation Services.
Input file Size 512 MB Boundary Maximum file size that can
be processed by Word
Automation Services.
Frequency with which to 1 minute (recommended) Threshold This setting determines how
start conversions (minutes) 15 minutes (default) often the Word Automation
59 minutes (boundary) Services timer job executes.
A lower number leads to the
timer job running faster. Our
testing shows that it is most
useful to run this timer job
once per minute.
Number of conversions to For PDF/XPS output Threshold The number of conversions

start per conversion process formats: 30 x MFor all other to start affects the
output formats: 72 x M throughput of Word
Where M is the value of Automation Services.
Frequency with which to If these values are set higher
start conversions (minutes) than the recommended
levels then some conversion
items may start to fail
intermittently and user
permissions may expire.
User permissions expire 24
hours from the time that a
conversion job is started.
Conversion job size 100,000 conversion items Supported A conversion job includes
one or more conversion
items, each of which
represents a single
conversion to be performed
on a single input file in
SharePoint. When a
conversion job is started
(using the
ConversionJob.Start
method), the conversion job
and all conversion items are
transmitted over to an
application server which
then stores the job in the
database. A large number of
conversion items will
increase both the execution
time of the Start method
and the number of bytes
transmitted to the
application server.
Total active conversion N-1, where N is the number Threshold An active conversion
processes of cores on each application process can consume a
server single processing core.
Therefore, customers should
not run more conversion
processes than they have
processing cores in their
application servers. The
conversion timer job and
other SharePoint activities
also require occasional use
of a processing core.
always leave 1 core free for
use by the conversion timer
job and SharePoint.
Word Automation Services 2 million conversion items Supported Word Automation Services
database size maintains a persistent
queue of conversion items
in its database. Each
conversion request
generates one or more
records.
does not delete records
from the database
automatically, so the
database can grow
indefinitely without
maintenance. Administrators
can manually remove
conversion job history by
using the PowerShell cmdlet
Remove-
bHistory. For more
information, see Remove-
bHistory.
Excel Services limits
The following table lists the recommended guidelines for Excel Services in SharePoint.
Maximum workbook size 10 MB Supported The maximum size of a

workbook that can be
opened in Excel Services is
10 megabytes.
Machine Translation Service limits
The following table lists the recommended guidelines for the Machine Translation Service.
Input file size for binary files 524,288 KB per file Threshold Files larger than the limit
take too long to transfer
and process, decreasing the
Input file size for text files 15,360 KB per file Threshold Files larger than the limit
have too much text to
Maximum character count 10,000,000 per document Threshold Documents with more
for Microsoft Word characters than the limit
Documents have too much text to
Total concurrent translation 5 Threshold Using more processes than

processes the limit does not increase
throughput because there is
a limit to how much text can
be translated at a time.
Using more processes
increases the demands on
the server resources.
Delay between translations 59 minutes Threshold Starting translations at a

larger interval than the limit
causes the time taken to
translate documents to
grow too large and can
cause the number of
queued translations to grow
too large.
Number of translations per 1,000 per process Threshold Starting more translations
translation process than the limit causes
translations to fail due to
timing out because they
cannot be processed before
the timeout period.
Maximum concurrent 300 Threshold More than 300 concurrent

translation requests translation requests could
cause translations to time
out because requests are
queued for longer than the
timeout period.
Files per translation job 100,000 files Supported Submitting jobs with a
number of files that exceeds
the limit causes job
submittal time and
processing time to be too
long.
Machine Translation Service 1,000,000 files Supported Operations to maintain the

database size queue of jobs become slow
if the database grows
beyond the maximum
number of files in the
database.
Office Web Application Service limits
The following table lists the recommended guidelines for Office Online. Office client application limits also apply
when an application is running as a web app.

Cache size 100 GB Threshold Space available to render

documents, created as part
of a content database. By
default, the cache available
to render documents is 100
GB. We do not recommend
that you increase the
available cache.
Renders One per document per Boundary This is the measured

second per CPU core per average number of renders
application server that can be performed of
(maximum eight cores) "typical" documents on the
application server over a
period of time.
OneNote concurrent merge 8 per document Threshold OneNote merges combine

operations changes from multiple users
who are co-authoring a
notebook. If too many
concurrent merges are
already in progress, a
conflict page is generated
instead, which forces the
user to perform the merge
manually.
Project Server limits
The following table lists the recommended guidelines for Project Server. For more information about how to plan
for Project Server, see Planning and architecture for Project Server 2010.
End of project time Date: 12/31/2149 Boundary Project plans cannot extend
past the date 12/31/2149.
Deliverables per project plan 1,500 deliverables Boundary Project plans cannot contain
more than 1,500
deliverables.
Number of fields in a view 256 Boundary A user cannot have more

than 256 fields added to a
view that they have defined
in Project Web App.
Number of clauses in a filter 50 Boundary A user cannot add a filter to

for a view a view that has more than
50 clauses in it.
SharePoint Apps limits
The following table lists the recommended guidelines for apps for SharePoint.
Maximum 100 Mb Boundary 100 MB is the limit for an

Access/SharePoint App app package created in the
Package size Access client.
Note: Access compresses
the database when it creates
the app package, so the app
package may include more
than 100 MB of data.
Maximum Access app 1 Gb Boundary Each Access app created on

database storage size in SharePoint Online creates a
SQL Azure database on SQL Azure. 1
GB is the limit for the
database storage on SQL
Azure. In an on-premise
installation, the
administrator controls the
size of the associated SQL
database.
Apps displayed in Manage 2,000 Boundary Up to 2,000 apps

Licenses page (purchased from the store)
can be displayed on the
Manage Licenses page. You
can still manage the license
of any app by going to the
All Site Contents page of the
site where the app is
installed and clicking on
Licenses, or by searching for
the app using Marketplace
Search.
Number of app licenses per 1,000,000 Supported The maximum supported

tenant number of licenses
(purchase of apps from the
store) for a single
SharePoint deployment,
either on-premises or
SharePoint Online.
Exceeding this limit might
cause severe performance
degradation.
Number of apps displayed 240 Boundary After this limit is reached,

in the Add an App page only the first 240 apps are
displayed, and a message
guiding you to search to
find your app is displayed.
Number of managers per 30 Boundary Only 30 people can manage

app license a license. License managers
can add or remove users or
delete a license.
Number of app licenses 2,000 Boundary When more than 2,000

assigned to a user viewable licenses are assigned to a
by that user user, that user will no longer
see any apps in the default
Add an App view. Instead, a
appear.
Number of apps in the 500 Boundary When more than 500 apps
corporate catalog viewable from the corporate catalog
by a single user are available to a single user,
that user will no longer see
any apps in the default Add
an App view. Instead, a
appear.
Distributed cache service limits
The following table lists the recommended guidelines for the distributed cache service.
Number of followable 400,000 Supported The total number of entities

entities (users, documents, that can be followed by a
sites and hashtags) per single user on a distributed
cache host cache host with 16GB RAM
assigned to the distributed
cache service is 400,000.
Number of cache hosts in a 16 Boundary The total number of cache

cluster hosts a single distributed
cache cluster can support is
16.
Maximum amount of 16GB Boundary The total amount of

memory dedicated to a memory that can be
cache host dedicated to the distributed
cache service on any one
cache host in a cluster is
16GB.
Miscellaneous limits
The following table lists limits and recommended guidelines for services and features not covered in other
sections.
Number of User agent 150 Boundary The maximum number of

substrings per device user agent substrings per
channel mobile device channel is
150.
Number of SharePoint 100 Boundary The maximum number of

sources per EDiscovery case SharePoint sources that can
be added to an EDiscovery
case is 100.
Number of Exchange 1,500 Boundary The maximum number of

sources (mailboxes) per Exchange sources
EDiscovery case (mailboxes) per EDiscovery
case is 1,500.
Maximum size of EDiscovery 16K characters or 500 Boundary The size of an EDiscovery
Query keywords query is limited to 500
keywords or 16,000
characters, whichever is
reached first.
Related topics
Hardware and software requirements for SharePoint 2013
Capacity management and sizing overview for

This article provides an overview of how to effectively plan and manage the capacity of SharePoint Server 2013
environments. This article also describes how to maintain a good understanding of the capacity needs and
capabilities of your deployment, by analysis of performance and volume data. It also reviews the major application
impacts that affect capacity, including content characteristics and usage.
IMPORTANT
Some values in this article are based on test results and other information related to SharePoint 2010 Products and may not
represent the final values for SharePoint Server 2013. This article will be updated with appropriate values, links to related
content and other information and republished when data related to SharePoint Server 2013 becomes available.
Capacity management is an ongoing process, because no implementation remains static with regard to content
and usage. You need to plan for growth and change, so that your SharePoint Server 2013-based environment can
continue to deliver an effective business solution.
Capacity Planning is only one part of the capacity management cycle. It is the initial set of activities that brings the
design architect to the point where there is an initial architecture that the architect believes will best serve the
SharePoint Server 2013 deployment. The capacity management model includes additional steps to help you
validate and tune the initial architecture, and provides a feedback loop for re-planning and optimizing the
production environment until it can support design goals with optimal choices of hardware, topology, and
configuration.
Glossary
The following specialized terms are used in SharePoint Server 2013 capacity management documentation.
RPS Requests per second. The number of requests received by a farm or server in one second. This is a
common measurement of server and farm load. The number of requests processed by a farm is greater than
the number of page loads and end-user interactions. This is because each page contains several
components, each of which creates one or more requests when the page is loaded. Some requests are
lighter than other requests with regard to transaction costs. In our lab tests and case study documents, we
remove 401 requests and responses (authentication handshakes) from the requests that were used to
calculate RPS because they have insignificant impact on farm resources.
Peak hours The time or times during the day when load on the farm is at its maximum.
Peak load The average maximum daily load on the farm, measured in RPS.
Load spike Transient load peaks that fall outside usual peak hours. These can be caused by unplanned
increases in user traffic, decreased farm throughput because of administrative operations, or combinations
of such factors.
Scale up To scale up means to add resources such as processors or memory to a server.
Scale out To scale out means to add more servers to a farm.
Who should read capacity management articles?
Consider the following questions to determine whether you should read this content.
Evaluating SharePoint Server 2013
IMPORTANT
Some links in this section might refer to SharePoint Server 2010 and other previous product versions, and will be updated
when SharePoint Server 2013 versions of this content become available.
I am an IT pro or business decision maker, and I am looking for a solution to specific business problems. SharePoint
Server 2013 is an option for my deployment. Can it provide features and scalability that meet my specific
requirements?
For information about how SharePoint Server 2013 scales to meet the demands of specific solutions and how to
determine the hardware that will be required to support your requirements, see the following sections later in this
article:
For information about how to evaluate SharePoint Server 2013 for your specific business requirements, see the
following articles:
What's new
Upgrading from Office SharePoint Server 2010
I am currently using SharePoint Server 2010. What has changed in SharePoint Server 2013, and what do I have to
consider if I upgrade? What effect will the upgrade have on my topology's performance and scale?
For information about more general upgrade considerations and guidance on how to plan and execute an upgrade
from Office SharePoint Server 2007, see the following article:
Tuning and optimizing a live SharePoint-based environment
I have deployed SharePoint Server 2013, and I want to make sure I have the appropriate hardware and topology
in place. How do I validate my architecture and maintain it correctly?
For information about monitoring and performance counters for SharePoint Server 2013 farms, see the following
article:
Monitoring and maintaining SharePoint Server 2013
For information about how to use the health monitoring tools built into the Central Administration interface, see
the following article:
Monitoring and Reporting in SharePoint Server
I have deployed SharePoint Server 2013, and I am experiencing performance issues. How do I troubleshoot and
optimize my environment?
For information about monitoring and performance counters for SharePoint Server 2013 farms, see the following
articles:
Plan for monitoring in SharePoint Server
For information about tools and techniques for optimizing SharePoint Server 2013 farms, see the following article:
Optimize performance for SharePoint Server 2013
For information about troubleshooting by using the health monitoring tools built into the Central Administration
interface, see the following article:
Solving problems and troubleshooting in SharePoint Server
For a list of capacity management articles that are available for specific SharePoint Server 2010 services and
features (more articles will be added as they become available), see the following article:
Performance and capacity test results and recommendations (SharePoint Server 2013)
For information about database sizing and performance, see the following article:
Storage and SQL Server capacity planning and configuration (SharePoint Server)
For information about Remote BLOB Storage (RBS ), see the following article:
Deciding to use RBS in SharePoint Server
Beginning to end
I want to know everything about SharePoint Server 2013 capacity management. Where do I start?
For information about the general concepts behind capacity management and links to additional documentation
and resources, see the following article:
For additional information about capacity management, see the following companion articles to this overview
article:
Capacity planning for SharePoint Server 2013
Performance testing for SharePoint Server 2013
You should now have a good understanding of the concepts. For information the limits and boundaries of
SharePoint Server 2013, see the following article:
When you are ready to identify a starting point topology for your SharePoint Server 2013-based environment, you
can look through the library of available technical case studies to find the one that most closely matches your
requirements. For a list of SharePoint Server 2010 case studies (SharePoint Server 2013 case studies will be
published as they become available), see the following article:
Performance and capacity technical case studies (SharePoint Server 2010)
For information about health monitoring and troubleshooting by using the health monitoring tools built into the
Central Administration interface, see the following articles:
Solving problems and troubleshooting in SharePoint Server
For more information about how to virtualize SharePoint Server 2013-based servers, see the following article:
Plan for on-premises or hosted virtualization in SharePoint 2013
For more information about high availability and disaster recovery, see the following article:
Plan for high availability and disaster recovery for SharePoint Server
Four fundamentals of performance

Capacity management focuses on the following four major aspects of sizing your solution:
Latency For the purposes of capacity management, latency is defined as the duration between the time that
a user initiates an action, such as clicking a hyperlink, and the time until the last byte is transmitted to the
client application or web browser.
Throughput Throughput is defined as the number of concurrent requests that a server or server farm can
process.
Data scale Data scale is defined as the content size and data corpus that the system can host. The structure
and distribution of the content databases has a significant effect on the time that is required for the system
to process requests (latency) and the number of concurrent requests it can serve (throughput).
Reliability Reliability is a measurement of the ability of the system to meet the targets set for the latency
and throughput over time.
The main goal of managing your environment's capacity is to establish and maintain a system that meets your
organization's latency, throughput, data scale, and reliability targets.
Latency
Latency, also known as end-user perceived latency, is composed of three major components:
The time it takes the server to receive and process the request.
The time it takes the request and the server response to transfer over the network.
The time it takes the response to render on the client application.
Different organizations define different latency goals based on business requirements and user expectations. Some
organizations can afford latency of several seconds, whereas other organizations require very fast transactions.
Optimizing for very fast transactions is usually costlier, and usually requires more powerful clients and servers,
more recent browser and client application versions, high-bandwidth network solutions, and possibly development
investments and page tuning.
Some major factors that contribute to longer end-user perceived latencies, and examples of some common
problems, are described in the following list. These factors are especially relevant in scenarios where the clients are
geographically distant from the server farm, or are accessing the farm across a low -bandwidth network connection.
Features, services, or configuration parameters that are not optimized might delay the processing of
requests and impact latency for both remote and local clients. For more information, see Capacity
management and sizing overview for SharePoint Server 2013 and Capacity management and sizing
overview for SharePoint Server 2013 later in this article.
Web pages that generate unnecessary requests to the server to download required data and resources.
Optimization would include downloading the minimum number of resources to draw the page, reducing the
sizes of images, storing the static resources in folders that enable anonymous access, clustering requests and
enabling page interactivity while resources are downloaded asynchronously from the server. These
optimizations are important for achieving an acceptable first time visit browse experience.
Excessive volume of data being transmitted over the network contributes to latency and throughput
degradation. For example, images and other binary objects on a page should use a compressed format such
as .png or .jpg instead of bitmaps when it is possible.
Web pages that are not optimized for second-access page loads. Page Load Time (PLT) improves for
second-access page loads because some page resources are cached on the client, and the browser must only
download dynamic non-cached content. Unacceptable second-access page load latencies are often caused
by incorrect Binary Large Object (BLOB ) cache configuration or local browser caching being disabled on
client computers. Optimizations would include correct caching of resources on the client.
Web pages that have non-optimized custom JavaScript code. This might slow rendering of the page on the
client. Optimization would delay JavaScript from being processed on the client until the rest of the page has
loaded, and preferably calling scripts instead of adding JavaScript inline.
Throughput
Throughput is described by the number of requests that a server farm can process in a unit of time, and is also
often used to measure the scale of operations that the system is expected to sustain based on the size of the
organization and its usage characteristics. Every operation has a specific cost in server farm resources.
Understanding the demand and deploying a farm architecture that can consistently satisfy demand requires
estimating the expected load, and testing the architecture under load to validate that latency does not fall below
target when concurrency is high and the system is under stress.
Some common examples of low throughput conditions include the following:
Inadequate hardware resources When the farm receives more requests than it can process concurrently,
some requests are queued, which cumulatively delays the processing of each subsequent request until
demand is reduced enough for the queue to be cleared. Some examples of optimizing a farm to sustain
greater throughput include the following:
Ensure that the processors on farm servers are not over-utilized. For example, if CPU usage during
peak hours or load spikes consistently exceeds 80 percent, add more servers or redistribute services
to other farm servers.
Ensure that there is sufficient memory on application servers and web servers to contain the
complete cache. This will help avoid calls to the database to serve requests for uncached content.
Ensure that database servers are free of bottlenecks. If total available disk IOPS are insufficient to
support peak demand, add more disks or redistribute databases to underutilized disks. See the
Removing Bottlenecks section of Monitoring and maintaining SharePoint Server 2013 for more
information.
If adding resources to existing computers is insufficient to resolve throughput issues, add servers and
redistribute affected features and services to the new servers.
Non-optimized custom web pages Adding custom code to frequently used pages in a production
environment is a common cause of throughput issues. Adding custom code might generate additional
round trips to the database servers or Web services to service data requests. Customization of infrequently
used pages might not significantly impact throughput, but even well-optimized code can decrease farm
throughput if it is requested thousands of times a day. SharePoint Server 2013 administrators can enable
the Developer Dashboard to identify custom code that requires optimization. Some examples of optimizing
custom code include the following:
Minimize the number of web service requests and SQL queries.
Fetch the minimum required data in each trip to the database server while limiting the number of
necessary round trips.
Avoid adding custom code to frequently used pages.
Use indexes when you are retrieving a filtered amount of data.
Untrusted solutions Deploying custom code in bin folders can cause slow server performance. Every time
that a page that contains untrusted code is requested, SharePoint Server 2013 must perform security checks
before the page can be loaded. Unless there is a specific reason to deploy untrusted code, you should install
custom assemblies in the GAC to avoid unnecessary security checking.
Data scale
Data scale is the volume of data the server or server farm can store while meeting latency and throughput targets.
Generally, the greater the data volume on the farm, the greater the impact on overall throughput and user
experience. The method that is used to distribute data across disks and database servers can also affect farm
latency and throughput.
Database sizing, data architecture, and sufficient database server hardware are all very important to an optimal
database solution. In an ideal deployment, content databases are sized according to limits guidance and are
distributed across physical disks so that requests are not queued because of disk overutilization, and database
servers can support peak loads and unexpected spikes without exceeding resource utilization thresholds.
Also, certain operations can lock certain tables during the operation. An example of this is large site deletion, which
can cause the related tables in the content database where the site resides to be locked until the delete operation is
complete.
Some examples of optimizing a farm for data and storage performance include the following:
Ensure that databases are properly distributed across the database servers, and that database server
resources are sufficient to support the volume and distribution of data.
Separate database volumes into unique Logical Units (LUNs), consisting of unique physical disk spindles.
Use multiple disks that have low seek time and appropriate RAID configurations to satisfy database server
storage demands.
You can use Remote BLOB Storage (RBS ) if your corpus contains many Binary Large Objects (BLOBs). RBS
can provide the following benefits:
BLOB data can be stored on less expensive storage devices that are configured to handle simple
storage.
The administration of the BLOB storage is controlled by a system that is designed specifically to work
with BLOB data.
Database server resources are freed for database operations.
These benefits are not free. Before you implement RBS with SharePoint Server 2013, you should
evaluate whether these potential benefits override the costs and limitations of implementing and
maintaining RBS.
For more information about how to plan data scale, see Storage and SQL Server capacity planning and
configuration (SharePoint Server).
Reliability
Reliability is the aggregate measurement of the server farm's capacity to meet established latency, throughput, and
data capacity targets over time. A reliable farm is one for which uptime, responsiveness, failure rate, and frequency
and amplitude of latency spikes are within established targets and operational requirements. A reliable farm can
also consistently sustain latency and throughput targets during peak load and peak hours, or when system
operations such as crawling or daily backups occur.
A major factor in sustaining reliability is the effect of common administrative operations on performance targets.
During certain operations, such as rebuilding the database indexes, maintenance timer jobs, or deleting multiple
sites that have large volume of content, the system might be unable to process user requests as quickly. In this case,
both latency and throughput of end-user requests can be affected. The impact on the farm depends on the
frequency and transaction cost of such less common operations, and whether they are run during normal operating
hours.
Some examples of how to sustain a more reliable system include the following:
Schedule resource-intensive timer jobs and administrative tasks during off-peak hours.
Scale up hardware on existing farm servers, or scale out by adding web servers, application servers or
additional database servers.
Distribute resource-intensive services and features to dedicated servers. You can also use a hardware load
balancer to direct feature-specific traffic to a web server dedicated to specific features or services.
Capacity management versus capacity planning

Capacity management extends the concept of capacity planning to express a cyclical approach in which the capacity
of a SharePoint Server 2013 deployment is continually monitored and optimized to accommodate changing
conditions and requirements.
SharePoint Server 2013 offers increased flexibility and can be configured to sustain usage scenarios in a wide
variety of different scale points. There is no single deployment architecture. Therefore, system designers and
administrators must understand the requirements for their specific environments.
SharePoint Server 2013 capacity management model
Step 1: Model Modeling is the process by which you decide the key solutions that you want your
environment to support, and establish all important metrics and parameters. The output of the modeling
exercise should be a list of all the key data that you must have to design your environment.
Understand your expected workload and dataset.
Set farm performance and reliability targets.
Analyze the SharePoint Server 2013 IIS logs.
Step 2: Design Once you have collected the data from Step 1, you can design your farm. Outputs are
detailed data architecture and physical and logical topologies.
Determine your starting point architecture.
Select your hardware.
Step 3: Pilot, Test, and Optimize If you have designed a new deployment, you must deploy a pilot
environment for testing against your workload and expected usage characteristics. For an existing farm,
testing is advised when major changes are being made to the infrastructure, but regular optimization based
on monitoring results might be necessary to maintain performance targets. The output from this phase is
analysis of test results against targets, and an optimized architecture able to sustain established performance
and capacity targets.
Pilot Deploy a pilot environment.
Test Test against latency and throughput targets.
Optimize Gather test results and make any required changes to the farm resources and topology.
Step 4: Deploy This step describes implementing the farm, or deploying changes to an existing farm.
Output for a new design is a completed deployment to live production, including all content and user
migrations. Output for an existing farm is revised farm maps and updates to maintenance plans.
Step 5: Monitor and maintain This step describes how to set up monitoring, and how to predict and
identify bottlenecks and perform regular maintenance and bottleneck mitigation activities.
Oversizing versus undersizing

Oversizing describes an approach to farm design in which targets are achieved without full utilization of hardware,
and the resources in the SharePoint Server 2013 farm are significantly and consistently underutilized. In an
oversized deployment, memory, CPU, and other indicators on the farm's resources show that it can well serve the
demand with fewer resources. The downside of oversizing is increased hardware and maintenance expenditures
and can impose greater power and space demands.
Undersizing describes an approach to farm design in which performance and capacity targets are not achievable
because hardware resources in the SharePoint Server 2013 farm are over-utilized. Undersizing a farm is
sometimes done to reduce hardware costs, but generally results in high latency leading to a poor user experience,
low satisfaction, frequent escalations, high support costs, and unnecessary spending for troubleshooting and
tuning the environment.
When you design your farm, make sure that your farm can meet established performance and capacity targets,
both under regular peak load and unexpected spikes. Design, testing, and optimization will help you to make sure
that that your farm has the correct hardware.
To maintain performance targets and accommodate growth, it is always more desirable to have more resources
than you must have to meet your targets. The cost of overinvestment in hardware is usually far less than the
cumulative expenses related to troubleshooting problems cause by undersizing.
You should always size a system to respond adequately during peak demand, which might be different for specific
services at different times. To effectively estimate capacity requirements, you must identify the worst case demand
period for all resources. There might be increased load on various features and services at certain times of the day,
such as first thing in the morning or after lunch.
The farm must also be able to support unplanned peaks, such as when organization-wide announcements are
made and an unusually high number of users access a site at the same time. During such periods of high demand,
users will experience high latency or not get a response from the farm at all unless sufficient farm resources are
available to satisfy the increased load on the farm.
Farm capacity should also be revisited when additional users will be provisioned in the enterprise. Situations such
as a merger or acquisition characterized by new employees or members accessing the farm can have adverse
effects on performance if not planned and estimated in advance.
Operational states: Green Zone and Red Zone
When we describe the load of a production system, we refer to two major operational states: the "Green Zone"
state in which the system is operating under the normal, expected load range, and the "Red Zone" state, which is a
state in which the farm experiences very high transient resource demand that can only be sustained for limited
periods until failures and other performance and reliability issues occur.
Green Zone This is the state at which the server or farm is operating under normal load conditions, up to expected
daily peak loads. A farm operating in this range should be able to sustain response times and latency within
acceptable parameters.
Red Zone The operating range in which load is greater than normal peak load, but can still service requests for a
limited period. This state is characterized by greater than normal latency and possible failures caused by saturation
of system bottlenecks.
The ultimate goal of farm design is to deploy an environment that can consistently support Red Zone load without
service failure and within acceptable latency and throughput targets.
Software limits and boundaries

In SharePoint Server 2013, there are certain limits that are by design and cannot be exceeded, and other limits that
are set to default values that can be changed by the farm administrator. There are also certain limits that are not
represented by a configurable value, such as the number of site collections per web application.
Boundaries are absolute limits that cannot be exceeded by design. It is important to understand these limits to
ensure that you do not make incorrect assumptions when you design your farm.
An example of a boundary is the 2 GB document size limit. You cannot configure SharePoint Server 2013 to store
documents that are larger than 2 GB. This is a built-in absolute value, and cannot be exceeded by design.
Thresholds are those that have a default value that cannot be exceeded unless the value is changed. Thresholds can,
in certain circumstances, be exceeded to accommodate variances in your farm design. However, you must
understand that doing this might affect the performance of the farm and the effective value of other limits.
The default value of certain thresholds can only be exceeded up to an absolute maximum value. A good example is
the document size limit again. By default, the document size limit is set to 50 MB, but can be changed to a
maximum value of 2 GB.
Supported limits define the tested value for a given parameter. The default values for these limits were defined by
testing, and represent the known limitations of the product. Exceeding supported limits could cause unexpected
results, significant performance degradation, or other detrimental effects.
Some supported limits are configurable parameters that are set by default to the recommended value, whereas
other limits relate to parameters that are not represented by a configurable value.
An example of a supported limit is the number of site collections per web application. The supported limit is the
largest number of site collections per web application that met performance benchmarks during testing.
curve that describes an increasing resource load and concomitant performance degradation as the value increases.
Therefore, exceeding certain limits, such as the number of site collections per web application, might only result in
a fractional decrease in farm performance. However, in most cases, operating at or near an established limit is not a
best practice, as acceptable performance and reliability targets are best achieved when a farm's design provides for
a reasonable balance of limits values.
limits might be affected. Many limits in SharePoint Server 2013 can be changed. However, you should understand
If you contact Microsoft Customer Support Services about a production system that does not meet the published
minimum hardware specifications as described in Hardware and software requirements for SharePoint 2013,
support will be limited until the system is upgraded to the minimum requirements.
In SharePoint Server 2013, thresholds and supported limits are established through testing and observation of
farm behavior under increasing loads up to the point where farm services and operations reach their effective
operational limits. Some farm services and components can support a greater load than others. Therefore, in some
cases, you must assign a limit value that is based on an average of several factors.
Therefore, the maximum value assigned to the number of site collections is not absolute, but is calculated based on
an expected set of usage characteristics in which overall farm performance would be acceptable at the given limit
under most circumstances.
If other services are operating under parameters that are greater than those used for limits testing, the maximum
effective limits of other services will be reduced. Therefore, it is important to execute rigorous capacity
management and scale testing exercises for specific deployments to establish effective limits for that environment.
For more information about boundaries and limits and how they affect the capacity management process, see
Software boundaries and limits for SharePoint 2013.
SharePoint Server 2013 deployment key differentiators

Each SharePoint Server 2013 deployment has a key set of characteristics that will make it unique and different
from other farms. These key differentiators can be described by these four major categories:
Specification Describes the farm's hardware, and the farm topology and configuration.
Workload Describes the demand on the farm, including the number of users and the usage characteristics.
Dataset Describes content sizes and distribution.
Health and performance Describes the farm's performance against latency and throughput targets.
Specifications
Hardware
Hardware is the computer's physical resources such as processors, memory, and hard disks. Hardware also
includes physical network components such as NICs (Network Interface Cards), cables, switches, routers and
hardware load balancers. Many performance and capacity issues can be resolved by making sure that the correct
hardware is being used. Conversely, a single misapplication of a hardware resource, such as insufficient memory
on a server, can affect performance across the entire farm.
Topology
Topology is the distribution and interrelationships of farm hardware and components. There are two kinds of
topology:
Logical topology The map of software components such as services and features in a farm.
Physical topology The map of servers and physical resources.
Typically, the number of users and usage characteristics determine the physical topology of a farm, and business
requirements such as the need to support specific features for expected load drives the logical topology.
Configuration
We use the term configuration to describe software settings and how parameters are set. Also, configuration refers
to caching, RBS, how configurable limits are set, and any part of the software environment that can be set or
modified to meet specific requirements.
Workload
Workload defines the key operational characteristics of the farm, including the user base, concurrency, features that
are being used, and the user agents or client applications that are used to connect with the farm.
Different SharePoint Server 2013 features have different associated costs on the farm's resources. Popularity of
more costly features can potentially significantly impact the performance and the health of the system.
Understanding your expected demand and usage characteristics will enable you to correctly size your
implementation, and reduce the risk of constantly running the system in an unhealthy condition.
User Base
The user base of a SharePoint Server 2013-based application is a combination of the total number of users and
how they are geographically distributed. Also, within the total user base, there are subgroups of users who might
use given features or services more heavily than other groups. Concurrency of users is defined as the total
percentage of users actively using the system at a given time. Indicators that define the user base include the
number of total unique users and number of concurrent users.
Usage Characteristics
A farm's performance can be affected not only by the number of users interacting with the system, but also by their
usage characteristics. Two organizations that have the same number of users might have significantly different
requirements based on how often users access farm resources, and whether resource-intensive features and
services are enabled on the farm. Indicators that describe the usage characteristics include the frequency of unique
operations, the overall operational mix (the ratio of read and write operations and administrative operations), and
the usage patterns and load against new features that are enabled on the farm (such as My Sites, Search,
Workflows, and Office Online Server).
Dataset
The volume of content that is stored in the system and the characteristics of the architecture in which it is stored
can have a significant effect on the overall health and performance of the system. Understanding the size, access
frequency, and distribution of data will enable you to correctly size the storage in the system and prevent it from
becoming the bottleneck that slows down user interactions with farm services and affects the end-user experience.
To correctly estimate and design the storage architecture of a SharePoint Server 2013-based solution, you need to
know the volume of data that you will store on the system, and how many users are requesting data from different
data sources. The volume of the content is an important element of sizing disk capacity, because it can influence the
performance of other features, and can also potentially affect network latency and available bandwidth. Indicators
that define the dataset include total size of content, total number of documents, total number of site collections, and
average and maximum sizes of site collection.
Health and performance
SharePoint Server 2013 farm health is basically a simplified measurement or score that reflects the reliability,
stability, and performance of the system. How well the farm performs against targets is basically dependent on the
first three differentiators. The health and performance score can be tracked and described by a distillation of a set
of indicators. For more information, see Monitoring and maintaining SharePoint Server 2013 and Plan for
monitoring in SharePoint Server. These indicators include the system's uptime, end-user perceived latency, page
failure rates, and resource utilization indicators (CPU, RAM ).
Any significant change in hardware, topology, configuration, workload, or dataset can significantly vary the
reliability and responsiveness of the system. The health score can be used to track performance over time and to
assess how changing operating conditions or system modifications affect farm reliability.
Reference architectures
SharePoint Server 2013 is a complex and powerful product, and there is no one-size-fits-all architecture solution.
Each SharePoint Server 2013 deployment is unique, and is defined by its usage and data characteristics. Every
organization needs to perform a thorough capacity management process and effectively take advantage of the
flexibility that the SharePoint Server 2013 system offers to customize a correctly sized solution that best satisfies
the organizational needs.
The concept of reference architectures is meant to describe and illustrate the different major categories of
SharePoint Server 2013 deployments, and not to provide a recipe for architects to use to design their solutions.
This section focuses on describing the vectors on which SharePoint Server 2013 deployments usually scale.
The architectures listed here are provided as a useful way to understand the general differentiators between these
generic categories, and to distinguish them by general cost factors and scale of effort.
Single server deployment
The single server deployment architecture consists of one server that is running SharePoint Server 2013 and a
supported version of SQL Server. This architecture might be appropriate for evaluation purposes, developers or
for an isolated non-mission-critical departmental implementation with only a few users. However, we do not
recommend its use for a production environment.
Small farm deployment

A small farm deployment consists of a single database server or cluster and one or two SharePoint Server 2013-
based computers. The major architecture characteristics include limited redundancy and failover, and a minimal set
of SharePoint Server 2013 capabilities enabled.
A small farm is useful to serve only limited deployments, with a minimal set of service applications enabled, a
relatively small user base, a relatively low usage load (a few requests per minute up to very few requests per
second), and a relatively small volume of data (10 or more gigabytes).
Medium farm deployment

This architecture introduces the breakdown of the topology into three tiers: dedicated Web servers, dedicated
application servers, and one or more database servers or clusters. Separating the front end server tier from the
application server tier allows greater flexibility in service isolation and helps balancing the load across the system.
This is the most common architecture, and includes a wide spectrum of service topologies and farm sizes. A
medium farm deployment is useful to serve environments that have the following:
Several service applications distributed across multiple servers. A typical set of features might include the
Office Online Service, User Profile Service, Managed Metadata Service, and Excel Calculation Service.
A user base of tens of thousands of users and a load of 10 to 50 requests per second.
A data store of one or two terabytes.
Large farm deployment

Large farm deployments introduce the breakdown of services and solutions across multiple farms, and additional
scaling out the tiers on a single farm. Several SharePoint Server 2013 services can be deployed on a dedicated
services farm that serves requests from multiple consuming farms. In these large architectures, there are typically
Web servers, multiple application servers, depending on the usage characteristic of each of the local (non-shared)
services, and multiple SQL Server-based servers or SQL Server clusters, depending on the content size and the
application services databases that are enabled on the farm. Large farm architectures are expected to serve
deployments that have the following:
Several service applications federated and consumed from dedicated services farm, typically the User
Profile Service, Search, Managed Metadata service, and Web Analytics.
Most other service applications are enabled locally.
A user base in the range of hundreds of thousands of users.
A usage load in the range of hundreds of requests per second.
A dataset in the range of ten or more terabytes.
See also
Concepts
Performance testing for SharePoint Server 2013
Performance and capacity test results and recommendations (SharePoint Server 2013)
Other Resources
Performance and capacity technical case studies (SharePoint Server 2010)
Prequisites for SharePoint Server 2013

The following downloadable resources, articles, video recordings, and related resources provide information about
how to prepare for SharePoint Server installation and initial configuration.
CONTENT DESCRIPTION
Initial deployment administrative and service accounts in Provides information about the administrative and service
SharePoint Server accounts that are required for an initial SharePoint Server
installation.
Account permissions and security settings in SharePoint 2013 Describes SharePoint Server 2013 administrative and services
account permissions. This article discusses the following areas:
Microsoft SQL Server, the file system, file shares, and registry
entries.
Install prerequisites for SharePoint Server from a network Describes how to install SharePoint Server prerequisites from
share an offline shared network location using the prerequisite
installer (PrerequisiteInstaller.exe) tool.
Account permissions and security settings in
SharePoint 2013

This article describes SharePoint administrative and services account permissions for the following areas:
Microsoft SQL Server, the file system, file shares, and registry entries.
IMPORTANT
Do not use service account names that contain the symbol $ with the exception of using a Group Managed Service Account
for SQL Server.
About account permissions and security settings

The SharePoint Configuration Wizard (psconfig) and the Farm Creation Wizard, both of which are run during a
Complete installation, configure many of the SharePoint baseline account permissions and security settings.
SharePoint administrative accounts

One of the following SharePoint components automatically configures most of the SharePoint administrative
account permissions during the setup process:
The SharePoint Configuration Wizard (Psconfig).
The Farm Creation Wizard.
The SharePoint Central Administration web site.
PowerShell.
Farm administrator user account
This account is a uniquely identifiable account assigned to the SharePoint administrator and is used to set up each
server in your farm by running the SharePoint Configuration Wizard, the initial Farm Creation Wizard, and
PowerShell. The account must be a domain user. For the examples in this article, the farm administrator account is
used for farm administration, and you can use Central Administration to manage it. Some configuration options
such as configuration of the SharePoint 2013 Search query server require local administration permissions. The
farm administrator user account requires the following permissions:
It must be a member of the Local Administrators group on each server in the SharePoint farm.
This account must have access to the SharePoint databases.
If you use any PowerShell operations that affect a database, the setup user administrator account must be
a member of the db_owner role or sysadmin fixed server role.
This account must be assigned to the securityadmin and dbcreator fixed server roles during setup and
configuration or the sysadmin fixed server role in SQL Server.
NOTE
The securityadmin and dbcreator SQL Server security roles might be required for this account during a complete version-
to-version upgrade because new databases might have to be created and secured for services.
After you run the configuration wizards, machine-level permissions for the setup user administrator account
include:
Membership in the WSS_ADMIN_WPG Windows security group.
Membership in the IIS_WPG role.
After you run the configuration wizards, database permissions include:
db_owner on the SharePoint server farm configuration database.
db_owner on the SharePoint Central Administration content database.
Cau t i on
If the account that you use to run the configuration wizards does not have the appropriate special SQL Server
role membership or access as db_owner on the databases, the configuration wizards will not run correctly.
SharePoint farm service account
The server farm account, which is also referred to as the database access account, is used as the application pool
identity for Central Administration and as the process account for the SharePoint Foundation 2013 Timer service.
The server farm account must be a domain user account.
Permissions are automatically granted to the server farm account on web servers and application servers that are
joined to a server farm.
After you run the configuration wizards, SQL Server and database permissions include:
Membership in the WSS_ADMIN_WPG Windows security group for the SharePoint Foundation 2013
Timer service.
Membership in WSS_RESTRICTED_WPG for the Central Administration and Timer service application
pools.
Membership in WSS_WPG for the Central Administration application pool.
Dbcreator fixed server role.
Securityadmin fixed server role.
db_owner for all SharePoint databases.
Membership in the WSS_CONTENT_APPLICATION_POOLS role for the SharePoint server farm
Membership in the WSS_CONTENT_APPLICATION_POOLS role for the SharePoint_Admin content
database.
SharePoint service application accounts

This section describes the service application accounts that are set up by default during installation.
Application pool account
The application pool account is used for application pool identity. The application pool account must be a domain
user account.
The following machine-level permission is configured automatically:
The application pool account is a member of WSS_WPG.
The following SQL Server and database permissions for this account are configured automatically:
The application pool accounts for Web applications are assigned to the SP_DATA_ACCESS role for the
content databases.
This account is assigned to the WSS_CONTENT_APPLICATION_POOLS role associated with the farm
This account is assigned to the WSS_CONTENT_APPLICATION_POOLS role associated with the
Default content access account
IMPORTANT
The default content access account is used within a specific service application to crawl content, unless a different
authentication method is specified by a crawl rule for a URL or URL pattern. This account requires the following
permission configuration settings:
The default content access account must be a domain user account that has read access to external or
secure content sources that you want to crawl by using this account.
This account must not be a member of the Farm Administrators group.
Content access accounts
IMPORTANT
Content access accounts are configured to access content by using the Search administration crawl rules feature.
This type of account is optional and you can configure it when you create a new crawl rule. For example, external
content (such as a file share) might require this separate content access account. This account requires the
following permission configuration settings:
The content access account must have read access to external or secure content sources that this account is
configured to access.
The content access account must hold the Manage auditing and security log right in the Local User
Policy on Windows file servers it is configured to crawl.
Excel Services unattended service account
IMPORTANT
Excel Services uses the Excel Services unattended service account to connect to external data sources that require
a user name and password that are based on operating systems other than Windows for authentication. If this
account is not configured, Excel Services will not attempt to connect to these types of data sources. Although
account credentials are used to connect to data sources of operating systems other than Windows, if the account
is not a member of the domain, Excel Services cannot access them. This account must be a domain user account.
My Sites application pool account
IMPORTANT
The My Sites application pool account must be a domain user account. This account must not be a member of the
Farm Administrators group.
This account is a member of WSS_WPG.
The application pool accounts for web applications are assigned to the SP_DATA_ACCESS role for the
content databases
Other application pool accounts
The other application pool account must be a domain user account. This account must not be a member of the
Administrators group on any computer in the server farm.
This account is a member of WSS_WPG.
This account is assigned to the SP_DATA_ACCESS role for the content databases.
This account is assigned to the SP_DATA_ACCESS role for search database that is associated with the web
application.
This account must have read and write access to the associated service application database.
NOTE
We strongly recommend you use a single Web Application Pool account for all Web Applications in the farm, including the
My Sites Web Application. The exception is the Central Administration Web Application which uses the Farm service
account.
SharePoint database roles
This section describes the database roles that installation sets up by default or that you can configure optionally.
WSS_CONTENT_APPLICATION_POOLS database role
The WSS_CONTENT_APPLICATION_POOLS database role applies to the application pool account for each web
application that is registered in a SharePoint farm. This enables web applications to query and update the site
map and have read-only access to other items in the configuration database. Setup assigns the
WSS_CONTENT_APPLICATION_POOLS role to the following databases:
The SharePoint_Admin content database.
Members of the WSS_CONTENT_APPLICATION_POOLS role have the execute permission for a subset of the
stored procedures for the database. In addition, members of this role have the select permission to the Versions
table (dbo.Versions) in the SharePoint_Admin content database. For other databases, the accounts planning tool
indicates that access to read these databases is automatically configured. In some cases, limited access to write to
a database is also automatically configured. To provide this access, permissions for stored procedures are
configured.
WSS_SHELL_ACCESS database role
The secure WSS_SHELL_ACCESS database role on the configuration database replaces the need to add an
administration account as a db_owner on the configuration database. By default, the farm administrator account
which initially ran the Configuration Wizard is assigned to the WSS_SHELL_ACCESS database role. You can use a
PowerShell command to grant or remove memberships to this role. Setup assigns the WSS_SHELL_ACCESS role
to the following databases:
One or more of the SharePoint Content databases. This is configurable by using the PowerShell command
that manages membership and the object that is assigned to this role.
Members of the WSS_SHELL_ACCESS role have the execute permission for all stored procedures for the
database. In addition, members of this role have the read and write permissions on all of the database tables.
SP_READ_ONLY database role
The SP_READ_ONLY role should be used for setting the database to read only mode instead of using
sp_dboption. This role as its name suggests should be used when only read access is required for data such as
usage and telemetry data.
NOTE
The sp_dboption stored procedure is not available in SQL Server 2012. For more information about sp_dboption see
sp_dboption (Transact-SQL).
The SP_READ_ONLY SQL role will have the following permissions:

Grant SELECT on all SharePoint stored procedures and functions
Grant SELECT on all SharePoint tables
Grant EXECUTE on user-defined type where schema is dbo
SP_DATA_ACCESS database role
The SP_DATA_ACCESS role is the default role for database access and should be used for all object model level
access to databases. Add the application pool account to this role during upgrade or new deployments.
NOTE
The SP_DATA_ACCESS role replaces the db_owner role in SharePoint 2013.
The SP_DATA_ACCESS role will have the following permissions:

Grant EXECUTE or SELECT on all SharePoint stored procedures and functions
Grant SELECT on all SharePoint tables
Grant EXECUTE on User-defined type where schema is dbo
Grant INSERT on AllUserDataJunctions table
Grant UPDATE on Sites view
Grant UPDATE on UserData view
Grant UPDATE on AllUserData table
Grant INSERT and DELETE on NameValuePair tables
Grant create table permission
Group permissions
This section describes permissions of groups that the SharePoint 2013 setup and configuration tools create.
WSS_ADMIN_WPG
WSS_ADMIN_WPG has read and write access to local resources. The application pool accounts for the Central
Administration and Timer services are in WSS_ADMIN_WPG. The following table shows the
WSS_ADMIN_WPG registry entry permissions.
HKEY_LOCAL_MACHINE\SY Full control Not Applicable Not Applicable

STEM\CurrentControlSet\Ser
vices\VSS
HKEY_LOCAL_MACHINE\Sof Read, write Not Applicable Not Applicable

tware\Microsoft\Office\15.0\
Registration{90150000-
110D-0000-1000-
0000000FF1CE}

FTWARE\Microsoft\Office SharePoint 2013 registry
Server settings tree. If this key is
altered, SharePoint 2013
functionality will fail.
HKEY_LOCAL_MACHINE\SO Full control No This key is the root of the


Server\15.0\LoadBalancerSet conversion service. Altering
tings this key will break document

HKEY_LOCAL_MACHINE\Sof Full control Not Applicable Not Applicable

Server\15.0\Search
HKEY_LOCAL_MACHINE\Sof Full control Not Applicable Not Applicable

tware\Microsoft\Shared
Tools\Web Server
Extensions\15.0\Search

tware\Microsoft\Shared connection string and the ID
Tools\Web Server of the configuration
2013 installation on the

tware\Microsoft\Shared used during setup. If this
Tools\Web Server key is altered, diagnostic
Extensions\15.0\WSS logging may fail and setup
or post-setup configuration
may fail.
The following table shows the WSS_ADMIN_WPG file system permissions.

deleted.

unavailable and
or deleted, unless custom IIS
Web site paths are provided
for all IIS Web sites extended
with SharePoint 2013.
%ProgramFiles%\Microsoft Full control No This directory is the

SharePoint 2013 binaries
and data. The directory can
be changed during
installation. All SharePoint
2013 functionality will fail if
this directory is removed,
altered, or removed after
installation. Membership in
the WSS_ADMIN_WPG
Windows security group is
required for some
SharePoint 2013 services to
be able to store data on
disk.
%ProgramFiles%\Microsoft Read, write No This directory is the root

The SharePoint 2013
altered.
%ProgramFiles%\Microsoft Full control No This directory is the root

Office Servers\15.0\Data location where local data is
stored, including search
indexes. Search functionality
will fail if this directory is
removed or altered.
WSS_ADMIN_WPG Windows
security group permissions
are required to enable
search to save and secure
data in this folder.
%ProgramFiles%\Microsoft Full control Yes This directory is the location

generated. Logging
altered.
%ProgramFiles%\Microsoft Full control Yes Same as the parent folder.

Office
Servers\15.0\Data\Office
Server
%windir%\System32\drivers\ Read, write Not Applicable Not Applicable

etc\HOSTS
%windir%\Tasks Full control Not Applicable Not Applicable
%COMMONPROGRAMFILE Modify Yes This directory is the

S%Microsoft Shared\Web installation directory for core
Server Extensions\15 SharePoint 2013 files. If the
access control list (ACL) is
modified, feature activation,
solution deployment, and
other features will not
function correctly.

correctly.
%COMMONPROGRAMFILE Full control Yes This directory contains files

Server with SharePoint 2013. If this
Extensions\15\CONFIG directory or its contents are
altered, web application
function correctly.
%COMMONPROGRAMFILE Full control No This directory contains setup

S%\Microsoft Shared\Web and runtime tracing logs. If
Server Extensions\15\LOGS the directory is altered,
diagnostic logging will not
function correctly.

which SharePoint 2013
Part rendering and other
might fail.

not function correctly.
This registry key applies only
to SharePoint Server.
%systemdrive\program Full control Not Applicable This permission is granted

files\Microsoft Office for a %systemdrive\program
Servers\15 folder on Index files\Microsoft Office
servers Servers\15 folder on Index
servers.
WSS_WPG
WSS_WPG has read access to local resources. All application pool and services accounts are in WSS_WPG. The
following table shows WSS_WPG registry entry permissions.


tware\Microsoft\Office for the SharePoint 2013
Server\15.0\Diagnostics diagnostic logging. Altering
this key will break the
logging functionality.


HKEY_LOCAL_MACHINE\Sof Read No This key contains the

HKEY_LOCAL_MACHINE\Sof Read Yes This key contains settings

Extensions\15.0\WSS diagnostic logging may fail
configuration may fail.
The following table shows the WSS_WPG file system permissions.
%AllUsersProfile%\ Read No This directory contains the

deleted.
C:\Inetpub\wwwroot\wss Read, execute No This directory (or the

unavailable and

Office Servers\15.0 installation location for the
SharePoint 2013
installation. WSS_WPG read
and execute permissions are
required to enable IIS sites
to load SharePoint 2013
binaries.
%ProgramFiles%\Microsoft Read No This directory is the root

The SharePoint 2013
altered.

Office Servers\15.0\Logs where the runtime
generated. Logging
altered.
%COMMONPROGRAMFILE Read Yes This directory contains the

correctly.
%COMMONPROGRAMFILE Read Yes This directory contains files

Server with SharePoint 2013. If this
Extensions\15\CONFIG directory or its contents are
altered, web application
function correctly.
%COMMONPROGRAMFILE Modify No This directory contains setup

function correctly.
%windir%\temp Read Yes This directory is used by

may fail.
%windir%\System32\logfiles Read No This directory is used by

The registry key applies only
%systemdrive\program Read, execute Not Applicable The permission is granted

files\Microsoft Office for %systemdrive\program
Servers\15 files\Microsoft Office
Servers\15 folder on Index
servers.
Local service
The following table shows the local service registry entry permission:

The following table shows the local service file system permission:

Office Servers\15.0\Bin location of the SharePoint
2013 binaries. All the
SharePoint 2013
altered.
Local system
The following table shows the local system registry entry permissions:



features will fail.

The following table shows the local file system permissions:

altered or deleted.

unavailable and

correctly.

S%\Microsoft Shared\Web contents are altered, Web
Server Application provisioning will

S%\Microsoft Shared\Web and run-time tracing logs. If
function correctly.

might fail.

Network service
The following table shows the network service registry entry permission:
HKEY_LOCAL_MACHINE\Sof Read Not Applicable Not Applicable

Server\15.0\Search\Setup
Administrators
The following table shows the administrators registry entry permissions:


features will fail.

The following table shows the administrators file system permissions:

altered or deleted.
C:\Inetpub\wwwroot\wss Full Control No This directory (or the

unavailable and
web site paths are provided
for all IIS web sites that are
2013.

correctly.

S%\Microsoft Shared\Web contents are altered, web
Server application provisioning will

function correctly.

depends. If the ACL is
modified, Web Part
rendering, and other
might fail.

WSS_RESTRICTED_WPG
WSS_RESTRICTED_WPG can read the encrypted farm administration credential registry entry.
WSS_RESTRICTED_WPG is only used for encryption and decryption of passwords that are stored in the
configuration database. The following table shows the WSS_RESTRICTED_WPG registry entry permission:

features will fail.
Users group
The following table shows the users group file system permissions:

SharePoint 2013
installation.
%ProgramFiles%\Microsoft Read, execute No This directory is the root

Servers\15.0\WebServices\R root Web services are
oot hosted. The only service
initially installed on this
directory is a search global
administration service. Some
search administration
functionality that uses the
server-specific Central
Administration Settings
page will not work if this
altered.

generated. Logging will not
altered.

Office Servers\15.0\Bin location of SharePoint 2013
binaries. All of the
SharePoint 2013
altered.
All SharePoint 2013 service accounts

The following table shows the all SharePoint 2013 service accounts file system permission:
%COMMONPROGRAMFILE Modify No This directory contains setup

Server Extensions\15\LOGS this directory is altered,
function correctly. All
SharePoint 2013 service
accounts must have write
permission to this directory.
See also
Concepts
Overview of SharePoint 2013 installation and
configuration

Although SharePoint products 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.
This article provides an overview for all types of SharePoint Server 2013 farm deployment.
For a visual representation of the information in this article, see the SharePoint 2013 Products Deployment model
in the Technical diagrams for SharePoint Server topic. Related technical diagrams include " Topologies for
SharePoint 2013 and Services in SharePoint Server 2013".
Concepts
The logical result of SharePoint Server 2013's flexibility and richness can be a high degree of complexity around
installing and configuring SharePoint Server 2013 correctly. A fundamental understanding of the following key
structural elements in a SharePoint Server 2013 environment is required in order to correctly deploy and support
SharePoint Server 2013:
Server farm: The top-level element of a logical architecture design for SharePoint Server 2013.
Web application: An IIS Web site that is created and used by SharePoint Server 2013.
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 Server 2013 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 Server 2013 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 Server 2013 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 planning in SharePoint Server
2013.
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 Server 2013 farm is deployed on one, two, or three tiers, as follows:
In a single-tier deployment, SharePoint Server 2013 and the database server are installed on one computer.
In a two-tier deployment, SharePoint Server 2013 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 solution you can create a SharePoint Server 2013 farm to host the solution. The first
step is to install SharePoint Server 2013 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 Server 2013 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 Server 2013 installed. The following servers must be configured to support and host a
farm:
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 Server 2013 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:
Application servers and front-end Web servers: The farm servers that will have SharePoint Server 2013
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
Server 2013 software prerequisites installed and hardened, and have the required authentication
configured. For more information, see:
"Installing software prerequisites" in Hardware and software requirements for SharePoint 2013
Plan security hardening for SharePoint Server
Domain controller: The required farm accounts have to be configured for the domain and directory
synchronization must be configured.
IMPORTANT
SharePoint Server 2013 does not support installation on to a domain controller in a production environment.
Additionally, SharePoint Server 2013 does not support installation on to a domain controller when using the sandbox
service in developer, test, or demo environments. > A single label domain (SLD) names or single label forests is also
not supported. Because the use of SLD names is not a recommended practice, SharePoint Server 2013 is not tested
in this scenario. Therefore, there may be incompatibility issues when SharePoint Server 2013 are implemented in a
single label domain environment. For more information, see Information about configuring Windows for domains
with single-label DNS names and the DNS Namespace Planning Solution Center.
For information about required accounts, see:

Initial deployment administrative and service accounts in SharePoint Server
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 Server 2013 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 Server 2013 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 Server 2013 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.
Configure settings, services, solutions, and sites

In this phase, you prepare the farm to host your site content by completing the following tasks:
Configure services.
Configure global settings. For more information, see Configure SharePoint Server
Create and populate the sites. For more information, see Create a web application in SharePoint Server
NOTE
Farm configuration steps are not isolated to a specific tier in the server infrastructure.
Deployment stages
By deploying a SharePoint Server 2013 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
Pilot
User acceptance test
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 Plan for SharePoint Server.
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 Server 2013.
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 Server 2013 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
During the proof of concept stage, the objective is two-fold: to understand SharePoint Server 2013 and to evaluate
SharePoint Server 2013 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 Server 2013 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 Server 2013
into production.
TIP
Virtualization provides a good platform for evaluating SharePoint Server 2013 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 Server 2013 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.
Install SharePoint 2013 on a single server with a built-
in database

You can quickly publish a SharePoint site by deploying SharePoint 2013 on a single server that has a built-in
database. This configuration is useful if you want to evaluate SharePoint 2013 features and capabilities, such as
collaboration, document management, and search. This configuration is also useful if you are deploying only a few
websites and you want to minimize administrative overhead.
This article contains required information and procedures to install and configure SharePoint 2013 with a built-in
database on a single server.
IMPORTANT
The steps in this article apply to SharePoint Foundation 2013 and SharePoint Server 2013. The procedures in this topic
install Microsoft SQL Server 2008 R2 SP1 Express Edition. However, User Profile synchronization does not work with the
Express Edition. If you intend to use User Profile synchronization withSharePoint Server 2013, you must choose a different
installation scenario.
Overview
When you deploy SharePoint 2013 on a single server that has a built-in database by using the default settings,
Setup installs Microsoft SQL Server 2008 R2 SP1 Express Edition and the SharePoint product. The SharePoint
Products Configuration Wizard creates the configuration database and content database for the SharePoint sites.
Additionally, the SharePoint Products Configuration Wizard installs the SharePoint Central Administration
website and creates your first SharePoint site collection.
NOTE
This article does not describe how to install SharePoint 2013 in a farm environment, or how to upgrade from previous
releases of SharePoint 2013. For more information about how to install SharePoint 2013 on a single-server farm, see Install
SharePoint 2013 on a single server with SQL Server. For more information about how to install SharePoint 2013 on a
multiple server farm, see Install SharePoint 2013 across multiple servers for a three-tier farm. For more information about
upgrade, see Upgrade from SharePoint 2010 to SharePoint 2013.
NOTE
The Distributed Cache service gives you a complete social computing experience. For more information about the Distributed
Cache service, see Overview of microblog features, feeds, and the Distributed Cache service in SharePoint Server, Manage
the Distributed Cache service in SharePoint Server, Plan for feeds and the Distributed Cache service in SharePoint Server, and
What's new in authentication for SharePoint Server 2013
Consider the following restrictions of this method of installation:

You cannot use this method on a domain controller or in a workgroup environment.
This method is not supported for production on a domain controller.
If your computer is in a workgroup, you cannot install AppFabric for Windows Server.
A Microsoft SQL Server 2008 R2 SP1 Express Edition database cannot be larger than 10 GB.
You cannot use user profile synchronization in this type of installation. If you want to use user profile
synchronization, you must use a server farm installation of SharePoint 2013. For more information, see
Install SharePoint 2013 on a single server with SQL Server or Install SharePoint 2013 across multiple
servers for a three-tier farm, and Synchronize user and group profiles in SharePoint Server 2013.
Before you begin

Before you begin installation, make sure that you have met all hardware and software requirements. For more
information, see Hardware and software requirements for SharePoint 2013. To make sure that you perform a
clean installation of SharePoint 2013, you must first remove any earlier version of SharePoint 2013 and any pre-
release prerequisites if installed.
Install SharePoint 2013

To install and configure SharePoint 2013, follow these steps:
1. Run the Microsoft SharePoint Products Preparation Tool.
2. Run Setup, which installs Microsoft SQL Server 2008 R2 SP1 Express Edition and the SharePoint product.
3. Run the SharePoint Products Configuration Wizard, which installs and configures the configuration
database, the content database, and installs the SharePoint Central Administration website. This wizard also
creates your first SharePoint site collection.
IMPORTANT
To complete the following procedures, you must be a member of the Administrators group on the computer on which you
are installing SharePoint 2013.

software prerequisites for SharePoint 2013.
Server.
2. In the folder where you downloaded the SharePoint 2013 software, locate and then run
prerequisiteinstaller.exe.
3. On the Welcome to the Microsoft SharePoint Products Preparation Tool page, click Next.
6. After you complete the Microsoft SharePoint Products Preparation Tool, you must also install the following:
KB 2554876
KB 2708075
KB 2759112
KB 2765317
Run Setup
The following procedure installs Microsoft SQL Server 2008 R2 SP1 Express Edition 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
Server.
2. On the SharePoint Server 2013 or SharePoint Foundation 2013 Start page, click Install SharePoint
Server or Install SharePoint Foundation.
5. On the Server Type tab, click Standalone.
the Run the SharePoint Products Configuration Wizard now check box is selected.
NOTE
If Setup fails, check log files in the Temp folder of the user account that you used to run Setup. Ensure that you are
logged in using the same user account, and then type %temp% in the location bar in Windows Explorer. If the path in
Windows Explorer resolves to a location that ends in a "1" or "2", you will have to navigate up one level to view the
log files. The log file name is SharePoint Server Setup (< time stamp>).

Use the following procedure to install and configure the configuration database and the content database, and
Server.
to All Programs, click SharePoint 2013 Products, and then click SharePoint 2013 Products
Configuration Wizard. If the User Account Control dialog box appears, click Continue.
Yes.
NOTE
If the SharePoint Products Configuration Wizard fails, check the PSCDiagnostics log files, which are located on the
drive on which SharePoint 2013 is installed, in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server
Extensions\15\LOGS folder.
6. On the Template Selection page, select 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 customize your own site template.
7. 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 be part of this group.
To use an existing group, click Use an existing group, and then select the user group in the Item list.
8. Click OK.
NOTE
If you are prompted for your user name and password, you might have to add the SharePoint Central Administration
website 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. If you see a proxy server error message, you might have to
configure proxy server settings so that local addresses bypass the proxy server. For more information about how to
configure browser and proxy settings, see Install SharePoint 2013 on a single server with a built-in database.

After you run the SharePoint Products Configuration Wizard, you should confirm that SharePoint 2013 works
information about supported browsers, see Plan browser support in SharePoint 2013.
local administrative credentials. Next, connect to the SharePoint Central Administration website. If you are
procedure.
procedure.
2. Click Start, point to All Programs, point to Administrative Tools, and then click Server Manager.
then click OK.
procedure.
5. In the Proxy Server area, select the Use a proxy server for your LAN check box.
After you install SharePoint 2013, your browser window opens to the SharePoint Central Administration website
of your new SharePoint site. Although you can start to add content to the site or customize the site, we
recommend that you first perform the following administrative tasks:
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 in SharePoint Server.
deployment or upgrade. The default settings are sufficient for most situations, but depending on the
business needs and life cycle of the farm, you might want to change these settings. For more information,
see Configure diagnostic logging in SharePoint Server.
archive incoming e-mail. You can also configure incoming e-mail so that SharePoint sites can archive e-mail
distribution list creation and administration. For more information, see Configure incoming email for a
SharePoint Server farm.
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 email for a SharePoint Server farm.
Configure search settings You can configure search settings to crawl the content in SharePoint 2013.
Install SharePoint 2013 on a single server with SQL
Server

A single server installation consists of one server that runs both SQL Server and SharePoint 2013. You can install
and configure SharePoint 2013 on a single server if you are hosting only a few sites for a limited number of users
or if you want to create a trial or development environment. 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.
IMPORTANT
The steps in this article apply to SharePoint Foundation 2013 and SharePoint Server 2013.
Overview
When you install SharePoint 2013 on a single server, you can configure SharePoint 2013 to meet your specific
needs. After you have completed setup and the SharePoint Products Configuration Wizard, you will have installed
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.
Before you install SharePoint 2013 on a single server

Before you begin to install and configure SharePoint 2013, do the following:
Guidelines for Windows Server 2008 and Performance Tuning Guidelines for Windows Server 2008 R2.
Ensure that you have met all hardware and software requirements. You must have a 64-bit version of
Windows Server 2008 R2 SP1. For server farms, you must also have a 64-bit version of SQL Server 2008
R2 SP1. For more information about these requirements, such as specific updates that you must install, see
Hardware and software requirements for SharePoint 2013.
Ensure that you perform a clean installation of SharePoint 2013.
parallelism see, Configure the max degree of parallelism Server Configuration Optionand Degree of
Parallelism.
NOTE
The Distributed Cache service gives you a complete social computing experience. For more information about the
Distributed Cache service, see Overview of microblog features, feeds, and the Distributed Cache service in SharePoint Server,
Manage the Distributed Cache service in SharePoint Server, Plan for feeds and the Distributed Cache service in SharePoint
Server, and What's new in authentication for SharePoint Server 2013
NOTE
As a security best practice, we recommend that you install SharePoint 2013 by using least-privilege administration.
Install SharePoint 2013 on a single server

To install and configure SharePoint 2013 on a single server, you will follow these steps:
1. Run the Microsoft SharePoint Products Preparation Tool, which installs all prerequisites to use SharePoint
2013.
2. Run Setup, which installs binaries, configures security permissions, and edits registry settings for
SharePoint 2013.
IMPORTANT
computer on which you are installing SharePoint 2013. For information about user accounts, see Initial deployment

software prerequisites for SharePoint 2013.
Server.
6. After you complete the Microsoft SharePoint Products Preparation Tool, you must also install the following:
KB 2554876
KB 2708075
KB 2759112
KB 2765317
Run Setup
SharePoint 2013. 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
Server.
2. On the SharePoint Server 2013 Start page, click Install SharePoint Server.
5. On the Server Type tab, click Complete.
The stand-alone option is used to install a single server that has a built-in database.
6. Optional: To install SharePoint 2013 at a custom location, or to store search index files at a custom
custom location.
NOTE
separate storage volume or partition. Any other search data that needs to be stored, is stored in the same location
as the search index files. You can only set this location at installation time.

the Run the SharePoint Products and Technologies Configuration Wizard now check box is selected.
NOTE
If Setup fails, check log files in the Temp folder of the user account you used to run Setup. Ensure that you are logged in
using the same user account and then type %temp% in the location bar in Windows Explorer. If the path in Windows
Explorer resolves to a location that ends in a "1" or "2", you have to navigate up one level to view the log files. The log file
name is SharePoint Server Setup (< time stamp>).

Server.
to All Programs, click SharePoint 2013 Products, and then click SharePoint 2013 Products
Yes.
8. In the Database name box, type a name for your configuration database or use the default database
9. 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.
[!SECURITY NOTE ] 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 has to be a domain user account.
However, it does not have 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.

11. Click Next.
credentials of accounts that are registered in SharePoint 2013. For example, the SharePoint 2013 system
account that you provide when you run the SharePoint Products Configuration Wizard. Ensure that you
remember the passphrase, because you must use it every time that you add a server to the farm.
12. Click Next.
13. After you complete the SharePoint Products Configuration Wizard page, review your configuration
NOTE
The Advanced Settings option is not available in SharePoint Foundation 2013.
14. On the Configuration Successful page, click Finish. When the wizard closes, setup opens the web
browser and connects to Central Administration.
If the SharePoint Products Configuration Wizard fails, check the PSCDiagnostics log files, which are
located on the drive on which SharePoint 2013 is installed, in the
Explorer. You might also want to disable the Internet Explorer Enhanced Security settings. If you see a
proxy server error message, you might have to configure proxy server settings so that local addresses
bypass the proxy server. Instructions for configuring proxy server settings are provided in the following
section. For more information about how to configure browser and proxy settings, see Configure browser
settings.
After you run the SharePoint Products Configuration Wizard, you should confirm that SharePoint 2013 works
information about supported browsers, see Plan browser support in SharePoint 2013.
procedure.
procedure.
2. Click Start, point to All Programs, point to Administrative Tools, and then click Server Manager.
then click OK.
procedure.
5. In the Proxy Server area, select the Use a proxy server for your LAN check box.
You have now completed setup and the initial configuration of SharePoint 2013. 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.
Server.
2. On the SharePoint Central Administration home page, on the Quick Launch, click Configuration
Wizards, and then click Launch the Farm Configuration Wizard.
4. On the Configure your SharePoint farm page, next to Yes, walk me through the configuration of my
farm using this wizard, click Start the Wizard.
5. On the Configure your SharePoint farm page, in the Service Account section, click the service account
option that you want to use to configure your services.
[!SECURITY 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 of which SharePoint 2013 is aware — make sure that you click
that option before you continue.
NOTE
If you are using Office Online, see Office Web Apps (SharePoint 2013).

NOTE
12. Click OK.

click Finish.
After you install and configure SharePoint 2013, your browser window opens to the Central Administration web
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 in SharePoint Server.
needs and life-cycle of the farm, you might want to change these settings. For more information, see
Configure diagnostic logging in SharePoint Server.
both the "From" email address and the "Reply" email address that appear in outgoing alerts. For more
Configure Search settings You can configure Search settings to crawl the content in SharePoint 2013.
Install SharePoint 2013 across multiple servers for a
three-tier farm

A three-tier farm configuration 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. While the farm configuration is not complex, it provides a fundamental infrastructure to implement
a SharePoint 2013 solution on similar — or more complex farms.
Overview
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 SharePoint 2013 prerequisites on servers in the application and web tiers.
Install SharePoint 2013 on the application server and the web servers.
Provision services.
Topology overview
This topology is typically used for the medium and large farms described in Overview of SharePoint 2013
installation and configuration. 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 it 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.
Three-tier farm configuration
In the previous illustration, note the following:
You can add web servers to the web tier. These servers can be configured as conventional web servers to
handle user requests, or they can be configured to host dedicated query components or other service
components.
You can add farm servers to the application tier and configure them as dedicated servers that will host the
SharePoint Central Administration website or other services on the farm that require dedicated resources
or isolation from the web tier — for example, crawl components, query components, and profile pages.
You can add database servers to the database tier to implement a stand-alone instance, database
mirroring, or a failover cluster. To configure the farm for high availability, database mirroring or a failover
cluster is required on the database tier.
Before you install SharePoint 2013 on multiple servers for a three -tier farm
Before you begin to install and configure SharePoint 2013, do the following:
Guidelines for Windows Server 2008 and Performance Tuning Guidelines for Windows Server 2008 R2.
Ensure that you have met all hardware and software requirements. You must have a 64-bit version of
Windows Server 2008 R2 SP1. For server farms, you must also have a 64-bit version of SQL Server 2008
R2 SP1. For more information about these requirements, such as specific updates that you must install,
see Hardware and software requirements for SharePoint 2013.
Ensure that you perform a clean installation of SharePoint 2013.
parallelism see, Configure the max degree of parallelism Server Configuration Optionand Degree of
Parallelism.
NOTE
If your computer is in a Workgroup, you cannot install AppFabric for Windows Server.
NOTE
The Distributed Cache service gives you a complete social computing experience. For more information about the
Distributed Cache service, see Overview of microblog features, feeds, and the Distributed Cache service in SharePoint
Server, Manage the Distributed Cache service in SharePoint Server, Plan for feeds and the Distributed Cache service in
SharePoint Server, and What's new in authentication for SharePoint Server 2013

connection to download and configure SharePoint 2013 prerequisites. The Microsoft SharePoint Products
Preparation Tool runs when you start to install SharePoint 2013.
Database server
configuration.
make sure 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 .
Storage and SQL Server capacity planning and configuration (SharePoint Server), and Databases that support
SharePoint 2013.
Configure the max degree of parallism Server Configuration option and Degree of Parallelism.
Ensure that public updates and the required hotfix packages are installed for the operating system, SQL Server,
and SharePoint 2013. We recommend that all servers be updated to the same software version before you apply
the public updates.

Before you install SharePoint 2013 , 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
Server.
NOTE
6. After you complete the Microsoft SharePoint Products Preparation Tool, you must also install the
following:
KB 2554876
KB 2708075
KB 2759112
KB 2765317
Install SharePoint 2013 on the farm servers

After the prerequisites are installed, follow these steps to install SharePoint 2013 on each farm server.
SharePoint 2013. At the end of Setup, you can choose to start the SharePoint Products Configuration Wizard,
which is described later in this article.
To run Setup
Server.
2. On the SharePoint 2013 Start page, click Install SharePoint Server.
5. On the Choose the installation you want page, click Server Farm.
6. On the Server Type tab, click Complete.
7. Optional: To install SharePoint 2013 at a custom location, or to store search index files at a custom
custom location.
NOTE
As a best practice, we recommend that you install SharePoint 2013 on a non-system drive. > If you intend to use
this computer as a search server, we recommend that you store the search index files on a separate storage volume
or partition. Any other search data that needs to be stored, is stored in the same location as the search index files.
You can only set this location at installation time.

9. When the Setup program is finished, 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
SharePoint 2013 all application and front-end web servers that will participate in the server farm.

To create and configure the farm, you run the SharePoint Products Configuration Wizard. This wizard automates
several configuration tasks, such as creating the configuration database, installing services, and creating the
Central Administration website. We recommend that you run the SharePoint Products Configuration Wizard on
the server that will host the SharePoint Central Administration website before you run the wizard on the other
servers in the farm.
Server.
2. On the server that will host Central Administration (the application server), click Start, point to All
Programs, and then click SharePoint 2013 Products, and then click SharePoint 2013 Products
Yes.
8. In the Database name box, type a name for your configuration database, or use the default database
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 SharePoint 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 has to 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 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.

11. Click Next.
credentials of accounts that are registered in SharePoint 2013. For example, the SharePoint 2013 system
account that you provide when you run the SharePoint Products Configuration Wizard. Ensure that you
remember the passphrase, because you must use it every time that you add a server to the farm.
NOTE
If you want to access the SharePoint Central Administration website from a remote computer, make sure 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.

12. Click Next.
NOTE
If the SharePoint Products Configuration Wizard fails, check the log files on the drive on which SharePoint 2013 is
installed, which are located in the %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\15\LOGS
folder.
18. On the Initial Farm Configuration Wizard 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 that you make here is a matter of personal preference. The Farm Configuration Wizard will
configure some services automatically when you run it. However, if you configure services manually, you
have greater flexibility in designing your logical architecture.
If you are using Office Web Apps Server, see Office Web Apps overview (Installed on SharePoint 2013) .
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 2013 on the server that hosts Central
Administration. The only difference is that during setup, you are prompted to join an existing farm. Follow the
wizard steps to join the farm.
For additional information about how to add servers to a farm, see Add web or application servers to farms in
SharePoint 2013. This article also provides detailed information for the steps in the following procedure.
After you install and configure SharePoint 2013, your browser window opens to the Central Administration web
For more information, see Configure usage and health data collection in SharePoint Server.
business needs and life-cycle of the farm, you might want to change these settings. For more information,
see Configure diagnostic logging in SharePoint Server.
both the "From" email address and the "Reply" email address that appear in outgoing alerts. For more
Configure Search settings You can configure Search settings to crawl the content in SharePoint 2013.
2013

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 2013. 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 users in different locations, or when sites and
web pages must be duplicated in one or more languages.
If users are accessing Project Server 2016 in the SharePoint farm and have to view their project data in another
language, they will also have to install a corresponding Project Server 2016 language pack. For more information
about Project Server 2016 language packs, see Deploy language packs in Project Server 2013
and site collections in multiple languages without requiring separate installations of SharePoint 2013. Word
breakers and stemmers are automatically installed on web and application servers by Setup.
IMPORTANT
If you are uninstalling SharePoint 2013, you must uninstall all language packs before you uninstall SharePoint 2013.

Site owners or site collection administrators who create sites or site collections 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 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 language packs that are installed on the web and application servers determine the list of available languages
that you can use to create a site or site collection. By default, sites and site collections are created in the language
in which SharePoint 2013 was installed. For example, if you install the Spanish version of SharePoint 2013, 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 2013 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 2013, 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.
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 make sure 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 always displays content in the language of the original site template.
Only a limited set of language packs are available for SharePoint 2013.
notifications, and dialog boxes do not display in the language that was specified. This is because SharePoint 2013
relies on several supporting technologies — for example, the Microsoft .NET Framework, Microsoft Windows
Workflow Foundation, Microsoft ASP.NET, and SQL Server — 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 are 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.
server extensions\15\LAYOUTS\Locale_ID that contains language-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 language, this file will be used. You can specify the file to use by
setting the FileNotFoundPage() for each web application.

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 Microsoft PowerShell Help files are installed in English (en-us). To view these files in the same language as the
operating system, install the language pack for the same language in which the operating system was installed.
You can download language packs from the same location where you downloaded SharePoint 2013.
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 web and application server.
IMPORTANT

Server.
2. In the folder where you downloaded the language pack, run setup.exe.
3. 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.
SharePoint Products Configuration Wizard after you install a language pack, the language pack will not be
installed correctly.
The SharePoint Products Configuration Wizard runs in the language of the base installation of SharePoint
2013, not in the language of the language pack that you just installed.
To rerun the SharePoint 2013 Configuration Wizard
Server.
2. Click Start, point to All Programs, click SharePoint 2013, and then click SharePoint 2013 Products
configuration.
click Next.
6. If the Modify SharePoint Central Administration Web Administration Settings page appears, do not
change any of the default settings, and then click Next.
7. After you complete the Completing the SharePoint Products and Technologies Configuration Wizard, click
Next.
9. After you install a new language pack and rerun the Rerun the SharePoint 2013 Configuration Wizard, you
must deactivate and then reactivate any language-specific features before you use the new language pack.
%COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\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\15\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.
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 (It could cause many issues that is, the URL will produce a HTTP 500 - Internal server error page,
broken layout, mixture of default, and uninstalled language.). Reinstalling the language pack will make the site
functional again.
You cannot remove the language pack for the version of SharePoint 2013 that you have installed on the server.
For example, if you are running the Japanese version of SharePoint 2013, you cannot uninstall the Japanese
language support for SharePoint 2013.
Add web or application servers to farms in
SharePoint 2013

The procedures in this article apply to a SharePoint 2013 farm that consists of at least two tiers. This article does
not describe how to convert a single-server deployment to a multiple-server farm.
Before you add a web or application server to a SharePoint farm

NOTE
A typical three-tier farm includes 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 of the server in your farm topology, you must identify the services and features that
must be configured for the server to meet this role. This information will determine how SharePoint 2013 is
configured to provision the server for its role in either the web tier or the application tier. For more information,
see Manage service applications in SharePoint Server.
The following illustration shows a SharePoint 2013 farm with two front-end web servers (Web-1 and Web-2) that
serve content. The only application server (App-1) hosts Central Administration and the search components for
the farm.
Options for adding a server to a farm
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 to host web pages, web services, and the Web Parts that are
required to process requests from users. The web server directs these requests to the application server, which
returns the results to the front-end web server.
Application server role
By default, the server that hosts Central Administration in a three-tier farm is 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.
Services with similar usage and performance characteristics can be logically grouped on a server, and if it is
necessary, hosted on multiple servers if a scale out is required to respond to performance or capacity
requirements. For example, client-related farm services such as Word Services and Word Viewer can be combined
into a service group and hosted on a dedicated server. In addition, some services, such as the Managed Metadata
service, can be configured as service application that can be used by other farms.
In the farm illustration, there are two options to add an application server.
In option A an additional server is configured to host an additional instance of all search components. This
will provide fault-tolerance for the search service.
In option B an additional server is configured to host a second index partition. This will enable indexing of
more than 10 million documents.
In a three-tier farm that is running enterprise search, dedicated application servers are typically configured to host
individual search components. For more information, see Manage the search topology in SharePoint Server.
NOTE
Distributing search is not an option for SharePoint 2013, where only a single search instance is permitted for each content
database.
Additional tasks
software requirements for SharePoint 2013.
Verify that you have the minimum level of permissions that are required to install and configure SharePoint
2013 on a new server. You must be a member of the Farm Administrators SharePoint group and the
Administrators group on the local server to complete the procedures in this article. For more information,
see Initial deployment administrative and service accounts in SharePoint Server.
name of the configuration database if you are adding the server by using Microsoft PowerShell commands.
memberships: SharePoint 2013 is installed.
cmdlets.
NOTE
If you do not have permissions, contact your Setup administrator or SQL Server administrator to request
permissions. For additional information about PowerShell permissions, see Add-SPShellAdmin.
Document the location of the SharePoint 2013 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 in SharePoint Server.
IMPORTANT
If you change the location of the trace log to a non-system drive, change the location on all the servers in the farm.
Existing or new servers cannot log data if the location does not exist. In addition, you will be unable to add new
servers unless the path that you specify exists on the new server. You cannot use a network share for logging
purposes.

Before you can install SharePoint 2013 and add a server to the farm, you must check for and install all the
prerequisite software on the new server. You do this by using the Microsoft SharePoint Products Preparation Tool,
which requires an Internet connection to download and configure SharePoint 2013 prerequisites. If you do not
have an Internet connection for the farm servers, you can still use the tool to determine the software that is
required. You will have to obtain installable images for the required software. For download locations, see Links to
applicable software in "Hardware and software requirements (SharePoint 2013)."
TIP

After you install the prerequisites, follow these steps to install SharePoint 2013 on the new server. For detailed
instructions about how to install SharePoint 2013, see Install SharePoint 2013 on a single server with SQL Server.
To install SharePoint 2013
Server.
2. From the product media or a file share that contains the SharePoint 2013 Products installation files, run
Setup.exe.
3. On the Start page, click the link to install SharePoint 2013.
5. On the Server Type tab, select Complete.
NOTE
You can choose to install only the components that are required for a front-end web server. However, if you perform
a complete installation, you have more flexibility to re-purpose the server role in the farm in the future.
6. Accept the default file location where SharePoint 2013 will be installed or change the installation path in
TIP
As a best practice, we recommend that you install SharePoint 2013 on a drive that does not contain the operating
system.
7. When Setup finishes, a dialog box prompts you to run the SharePoint Products Configuration Wizard. You
can start the wizard immediately or from the Windows command prompt later.

To add a new SharePoint 2013 server to the farm by using the SharePoint Products Configuration
Wizard
Server.
2. Start the SharePoint 2013 Products Configuration Wizard.
5. Click Next.
10. 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 2013 is installed, in the %COMMONPROGRAMFILES%\Microsoft
Shared\Web Server Extensions\15\LOGS folder. For more information, see Monitoring and Reporting in SharePoint
Server.
12. Configure SharePoint 2013 so that the new server can accommodate the role for which it was intended. For
more information, see Add a server to a SharePoint Server 2016 farm.
To add a new SharePoint 2013 server to the farm by using PowerShell
cmdlets.
NOTE

3. At the PowerShell command prompt, type the following command to connect the server to a configuration
database:
Connect-SPConfigurationDatabase -DatabaseServer "<$DatabaseServer>" -DatabaseName "
<$RunSettings.ConfigurationDatabaseName>" -Passphrase "<$Passphrase>"
Where:
<$RunSettings.ConfigurationDatabaseName> is the name of the configuration database
SharePoint 2013:
Install-SPService
Get-SPFarm | select Servers
NOTE
located on the drive on which SharePoint 2013 is installed, in the %COMMONPROGRAMFILES%\Microsoft Shared\Web
Server Extensions\15\LOGS folder. For more information, see Monitoring and Reporting in SharePoint Server.
10. Configure SharePoint 2013 so that the new server can accommodate the role for which it was intended. 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.
Add a database server to an existing farm in
SharePoint 2013

You can add more database servers at any time to respond to business or operations requirements. Because a
database server contains the farm content, which can consist of diverse types of data and can have a fast growing
document collection, the size of the farm databases can grow quickly. Storage capacity is often the key reason to
add more database servers. Other reasons can include adding new features, improving performance and high
availability.
Before you begin

Normally, all that is required to add a database server to an existing SharePoint 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 to the new server. SharePoint 2013 automatically allocates and assigns new database resources
as necessary when they are required.
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 for SQL Server 2008 R2 and SQL Server 2012, see
High Availability Solution Overview and High Availability Solutions (SQL Server).
The procedures in this article are intended to show how to configure a new database server for a specific task in
SharePoint 2013.
Prepare the new database server

Before you can use the new database server, you must prepare it so that it can be used in a SharePoint 2013 farm.
Use the following steps as guidance to provision the new server.
IMPORTANT
IT policy may require a database administrator (DBA) to complete some or all steps in these procedures.
To provision the database server

1. Verify that the user account that is performing this procedure is a member of the SQL Server database
dbcreator fixed server role, the Farm Administrators SharePoint group, and Administrators group on the
server.
2. Review Hardware and software requirements for SharePoint 2013
3. Install the operating system, and make sure that the following conditions are satisfied:
The disk 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.
4. Install the same version of SQL Server that is installed on the existing farm database server.
For information about how to install and configure SQL Server 2008 R2 with Service Pack 1 (SP1) or SQL
Server 2012 before you add them to an existing server farm, see SQL Server Installation (SQL Server 2008
R2)orQuick-Start Installation of SQL Server 2012.
5. Configure SQL Server, and confirm the following:
The database collation is LATIN1_General_CI_AS_KS_WS.
A logon account is created for the SharePoint 2013 Setup user account. This account will be the database
owner for the new database.
6. 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 to configure a new database server to host specific SharePoint databases.
This includes the following:
Create a new web application.
Move a site collection to the new server.
You can use either the SharePoint Central Administration website or Microsoft PowerShell to create a new web
application. You must use PowerShell to move a site collection.
To create a new web application
1. Verify that the user account that is performing this procedure is a member of the SQL Server database
dbcreator fixed server role and the Farm Administrators SharePoint group.
2. Use the Application Management page in the SharePoint Central Administration website 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 that 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 of the site directory on the server where the web site is hosted.
5. Configure authentication and encryption for your web by 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 (predefined or configurable).
9. Identify the database server, database name, and authentication method for your new web application.
For detailed instruction, see Create a web application (SharePoint 2013).
To move a site collection by using PowerShell
1. The SharePoint 2013 content database stores all site content for a farm, this includes the site collection.
Content databases can store more than one site collection. Whether you move a site collection between
database servers or between databases the procedure is the same. If the site collection grows too large then
it can be moved to a new content database using the same procedure.
cmdlets. For additional information about PowerShell permissions, see Add-SPShellAdmin.
3. 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.
4. Determine the size of the source site collection and verify that the destination hard disk has at least three
times more free space than 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
5. Use the Move-SPSite cmdlet 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 in SharePoint Server.
See also
Other Resources
Deploy Windows Server 2008 R2
Install and Deploy Windows Server 2012
SQL Server Installation (SQL Server 2008 R2)
Install SQL Server 2012
Best practices for installation for SharePoint Servers
2016 and 2019
Introduction
Installing a new version gives the opportunity to review what you have done in the past, currently and envision
your goals going forward.
As you prepare for your installation, consider the following:
• Are you staying on Server (on-premises) for the foreseeable future?
• Do you currently have existing pieces of your system in the cloud?
• What customizations or features do you no longer use?
• Are you ready for a modern approach?
• What is working well now, and what isn’t?
Evaluating what features or services are no longer supported

As you install a new version of SharePoint Server, take time to evaluate any service applications or features that
you currently rely on that are no longer supported or listed as “deprecated”.
If you have a reliance on any of the following, plan what you intend to replace that functionality with or if it is no
longer being used actively by your company and it is time to phase it out.
Use supported service applications and consider phasing out the use of these deprecated service applications. For
any of the SharePoint BI tools, you can use PowerBI as a replacement:
DEPRECATED FEATURE OR SERVICE
Access Services and Access Services 2010
Document Conversions services
Lotus Notes Connector
Machine Translation Services
PerformancePoint Service
PowerPoint Conversion Service
Visio Graphics Service

DEPRECATED FEATURE OR SERVICE
InfoPath
Workflow Manager
Customizations
If you currently have SharePoint Server installed, chances are you have made some customizations to suit your
business needs.
If you already have a portion of your company in the cloud or plan to do so in the future, know that certain
customizations will not transfer to SharePoint Online. Here is a list of few of those:
• Workflows, User Alerts, and custom master pages will not transfer to SharePoint Online. We recommend you use
Microsoft Flow for workflows, reconfigure alerts once migrated, and use the out of the box customization for site
look and feel changes.
• Custom Search schema will not transfer to SharePoint Online. When content is migrated to SharePoint Online,
you may want to re-implement any custom Search schema configuration necessary.
• Use SharePoint Add-ins with the Low Trust model. To learn more, see Creating SharePoint add in that use low
trust authorization.
• Use SharePoint Framework solutions for custom business solutions. To get started, see SharePoint Framework
Overview.
Connect your data the modern way

Do you use Business Data Connectivity Services (BCS ) for any of your data connections? Are your data sources
available by using a web service? verify all data sources are available via other means, such as a web service.
• Where is your data? Where will it reside?
Instead of using BCS to display your data, you could use PowerBI and a Data Management Gateway.
Adopt the modern features

If a portion of your sites are already in the cloud, or if you intend on moving online in the future, adopting the
modern features now will help “futureproof” your installation.
• Use Office 365 Groups and Microsoft Flow. Retire the use of email, Site mailboxes, or Mobile Accounts
(SMS/Text Messaging)
• Solutions that intercept and/or modify the HTTP pipeline you could use Azure Conditional Access Policies by
fronting the farm by using the Azure AD App Proxy. For more information on how to use AD FS, see Access
Control Policies in Windows Server 2016 AD FS.
• Implement only the necessary Web Application Policies, such as self-service site creation, Object Cache, and
Search Crawler accounts, but try to avoid further usage of Web Application Policies as they are not available in
SharePoint Online.
• For security purposes, phase out the use of anonymous SharePoint Server sites. Also note that anonymous site
access is not available in SharePoint Online.
Plan for virtualization of SharePoint Server

SharePoint Server may be deployed as a virtual server on Hyper-V or other platforms supported as part of the
Server Virtualization Validation Program. Virtual machines provide increased flexibility for IT administrators.
Limitations
SharePoint Server imposes certain restrictions when operating as a virtual machine. These restrictions stem from
the use of the local configuration cache and search index when used in a SharePoint Server farm deployment. As
certain hypervisor operations cannot synchronize actions, the configuration cache and/or search index may
become out of sync with either other SharePoint Servers in the farm or SharePoint databases residing on the SQL
Server.
SharePoint Server does not support the following type of operations while SharePoint Server is online.
Virtual machine online backups - If full virtual machine backups are required, shut down the SharePoint and
SQL Servers in the farm prior to taking virtual machine backups. If a restore is required, restore all servers in
the farm.
Virtual machine snapshots - If a snapshot of SharePoint is required, shut down all SharePoint Servers and SQL
Servers in the farm prior to taking a virtual machine snapshot. If a restore is required, restore all servers in the
farm. Delete the snapshot as soon as possible as it may incur a performance penalty.
Virtual machine replication - Note an exception to this is Azure Site Recovery.
SAN (Storage Area Network) replication of SharePoint Server virtual disks
SharePoint Server also does not support dynamic/ballooning memory and we recommend against using
differencing disks for long periods of time.
Virtual Machine Templates

SharePoint Server supports virtual machine templates. Templates can be created by installing SharePoint Server
prerequisites, SharePoint Server, and any applicable public updates. As long as the Configuration Wizard has not
been run, the virtual machine can be saved as a template following your virtualization software guidance.
Do not create a template from a virtual machine running SharePoint Server that is already joined to a farm.
See also
Configure SharePoint Server

After you install SharePoint Server, you must configure several additional settings to enable key features in your
farm. The articles in this section provide steps for configuring these settings.
CONTENT DESCRIPTION
Configure client certificate authentication for SharePoint Learn how to configure SharePoint Server to support user
Server authentication using a client certificate.
Configure eDiscovery in SharePoint Server Learn the steps to set up and configure eDiscovery in
SharePoint Server, Exchange Server 2016, and Exchange
Server 2013.
Configure enterprise search in SharePoint Server 2016 Learn how to configure the Search service application and set
up a Search Center in SharePoint Server.
Manage the Distributed Cache service in SharePoint Server Learn how to configure and manage the Distributed Cache
service in SharePoint Server.
Configure site mailboxes in SharePoint Server Learn how to configure the Site Mailboxes feature in
SharePoint Server.
Configure Exchange task synchronization in SharePoint Server Learn how to configur Exchange task synchronization in
2013 SharePoint Server 2013.
Custom Tiles in SharePoint Server 2016 Describes Custom Tiles, one of the new features in the
November 2016 Public Update for SharePoint Server 2016
(Feature Pack 1).
Configure email integration for a SharePoint Server farm Learn how to set up incoming and outgoing email in
SharePoint Server.
Turn on automated document translation in SharePoint Learn how to create and configure Machine Translation
Server Service for SharePoint Server.
Configure Business Connectivity Services solutions for Learn how to install and configure SharePoint Server Business
SharePoint Server Connectivity Services (BCS).
Configure User Profile service applications in SharePoint Learn how to create and configure a User Profile service
Server application in SharePoint Server.
Configure My Sites in SharePoint Server Learn how to set up My Sites in SharePoint Server.
Configure client certificate authentication for
SharePoint Server

Client certificate authentication enables web-based clients to establish their identity to a server by using a digital
certificate, which provides additional security for user authentication. SharePoint Server does not provide built-in
support for client certificate authentication, but client certificate authentication is available through Security
Assertion Markup Language (SAML )-based claims authentication. You can use Active Directory Federation
Services (AD FS ) 2.0 as your security token service (STS ) for SAML claims or any third-party identity management
system that supports standard security protocols such as WS -Trust, WS -Federation, SAML 1.1, and SAML 2.0.
NOTE
For more information about SharePoint Server protocol requirements, see SharePoint Front-End Protocols.
Claims-based authentication in SharePoint Server allows you to use different STSs. If you configure AD FS as your
STS, SharePoint Server can support any identity provider or authentication method that AD FS supports, which
includes client certificate authentication.
NOTE
For more information about AD FS, see Active Directory Federation Services Overview and AD FS 2016.
For additional information on an overview of authentication in SharePoint, please see Plan for user authentication
methods in SharePoint Server.
The following figure applies to SharePoint Server 2013 and SharePoint Server 2016, SharePoint Server is
configured as a relying partner for an AD FS -based STS.
AD FS can authenticate user accounts for several different types of authentication methods, such as forms-based
authentication, Active Directory Domain Services (AD DS ), client certificates, and smart cards. When you configure
SharePoint Server as a relying partner of AD FS, SharePoint Server trusts the accounts that AD FS validates and
the authentication methods that AD FS uses to validate those accounts. This is how SharePoint Server supports
client certificate authentication.
Configure client certificate authentication

The following topics explain how to configure SharePoint Server with client certificate authentication or smart card
authentication when you use AD FS as your STS:
1. Configure AD FS to support claims-based authentication.
For more information, see AD FS 2.0 - How to change the local authentication type.
2. Configure SharePoint Server to support SAML -based claims authentication using AD FS.
For more information, see Configure SAML -based claims authentication with AD FS in SharePoint Server
and Improved interoperability with SAML 2.0.
3. Create a web application that uses SAML -based claims authentication.
For more information, see Create claims-based web applications in SharePoint Server.
NOTE
These steps will be similar for a third-party STS.
See also
Other Resources
Configure SAML -based claims authentication with AD FS in SharePoint Server
Planning and Architecture: AD FS 2.0
AD FS 2.0 Deployment Guide
Using Active Directory Federation Services 2.0 in Identity Solutions
Configure syncing with the new OneDrive sync client

When you deploy SharePoint Server 2019 in your organization, your users can sync their OneDrive for Business
files as well as SharePoint team site files by using the new OneDrive sync client (OneDrive.exe) for Windows.
Compared with the previous OneDrive for Business sync client (Groove.exe), the new sync client provides:
Improved performance and reliability
Files On-Demand
Support for larger files
Higher sync limits
The ability to silently deploy If your users are already syncing document libraries with the previous OneDrive
for Business sync client, they will transition to the new OneDrive sync client automatically.
Requirements
1. Install SharePoint Server 2019
2. Install the OneDrive sync client version 18.131.0701.0004 or higher (download)
Configure OneDrive for SharePoint Server 2019

To set up OneDrive with SharePoint Server 2019, you can either use Group Policy or set the registry keys directly.
NOTE
For settings that require a tenant ID, you can use OP1 if you sync a single domain. Do not use this if you sync multiple
domains.
The Known Folder Move settings don't work for SharePoint Server.
Using Group Policy

Configure the following two Group Policy objects to configure OneDrive to be used with SharePoint 2019:
Specify SharePoint Server URL and organization name
The URL will help the sync client locate the SharePoint Server and allows the sync client to authenticate and set up
sync. The organization name lets you specify the name of the root folder that will be created in File Explorer. If you
don’t supply an organization name, the sync client will use the first segment of the URL as the name. For example,
office.sharepoint.com would become “office”.
Specify the OneDrive location in a hybrid environment
This setting lets you specify if the sync client should authenticate against SharePoint Online or the SharePoint on-
premises server if the identity exists in both identity providers.
You should be able to find these Group Policy objects using the Group Policy Editor (gpedit.msc) when navigating
to Computer Configuration\Administrative Templates\OneDrive. If the OneDrive folder is not present, you can add
the OneDrive Group Policy template by coping the following two files from the OneDrive installation folder after
you have installed the latest OneDrive sync client on that computer:
C:\Users\username\AppData\Local\Microsoft\OneDrive\onedrivesyncclientversion\adm\OneDrive.admx to
C:\Windows\PolicyDefinitions\OneDrive.admx
C:\Users\username\AppData\Local\Microsoft\OneDrive\onedrivesyncclientversion\adm\OneDrive.adml to
C:\Windows\PolicyDefinitions\en-US\OneDrive.adml
To automate this copying using PowerShell, you could use:
Get-ChildItem -Recurse -Path "$env:LOCALAPPDATA\Microsoft\OneDrive" -Filter "OneDrive.admx" | ? FullName -like

"*\adm\OneDrive.admx" | Copy-Item -Destination "$env:WINDIR\PolicyDefinitions" -Force
Get-ChildItem -Recurse -Path "$env:LOCALAPPDATA\Microsoft\OneDrive" -Filter "OneDrive.adml" | ? FullName -like
"*\adm\OneDrive.adml" | Copy-Item -Destination "$env:WINDIR\PolicyDefinitions\en-US" -Force
More information: Learn how to manage OneDrive using Group Policy

By setting the registry keys
Alternatively, you can also directly configure the following underlying registry keys:
KEY TYPE VALUE
HKLM:\Software\Policies\Microsoft\One DWORD (32-bit) 1

Drive\SharePointOnPremPrioritization
HKLM:\Software\Policies\Microsoft\One String https://sharepoint.contoso.local

Drive\SharePointOnPremFrontDoorUrl
HKLM:\Software\Policies\Microsoft\One String Contoso

Drive\SharePointOnPremTenantName
Differences between syncing files in SharePoint Server and SharePoint

Online
If your organization also uses the OneDrive sync client to sync files in Office 365, here’s what will be different for
users who sync on-premises files.
Folder names
The OneDrive sync client creates the following folders on users’ computers: OneDrive – Contoso (for syncing
personal My Site files) Contoso (for syncing SharePoint team site files)
In SharePoint Online, “Contoso” is the tenant name that has been set for the SharePoint Online instance. In
SharePoint on-premises, there is no tenant name associated to the instance of SharePoint. You can set the this with
the “Specify SharePoint Server URL and organization name” group policy, or the sync client will use the first
segment of your SharePoint URL.
File thumbnails and previews
Thumbnails don’t appear in File Explorer for files synced from SharePoint on-premises. If you enable Files On-
Demand, and a file is online-only, a file preview won’t be available. Image files and Office files will not have a
thumbnail in File Explorer until the file is downloaded.
Sharing from File Explorer
When users share files and folders from File Explorer, the sharing option will open the browser instead of the
Share dialog box.
Privacy settings
When setting up SharePoint Server, you’ll be prompted to select if clients should send error reports and usage
statistics back to Microsoft. If you enable the setting, individual users can opt out by following these steps:
1. Right-click the OneDrive cloud icon in the notification area, at the far right of the taskbar.
2. Click Settings.
3. Click the Settings tab, and then clear the option under Privacy.

The User Profile service stores information about users in a central location. It enables My Sites, social computing
features such as social tagging and newsfeeds, and creating and distributing profiles across multiple sites and
farms. It is also required by most SharePoint hybrid scenarios.
The User Profile service application

The User Profile service application in SharePoint Server provides a central location where service administrators
configure and administer the following features:
User profiles - contain detailed information about people in an organization. A user profile organizes and
displays all of the properties related to each user, together with social tags, documents, and other items
related to that user.
Profile synchronization - provides a reliable way to synchronize groups and user profile information that
is stored in the SharePoint Server profile database together with information that is stored in Active
Directory Directory Services.
In SharePoint Server 2013, you can synchronize directly with other directories across the enterprise.
In SharePoint Server 2016, you can synchronize with other directories by using an external identity
manager such as Microsoft Identity Manager 2016.
Audiences - enables organizations to target content to users based on their job or task, as defined by their
membership in a SharePoint Server group or distribution list, by the organizational reporting structure, or
by the public properties in their user profiles.
My Site Host - a dedicated site for hosting My Sites. A My Site Host is needed in order to deploy the social
features of SharePoint Server.
My Site - a personal site that gives users in your organization a central location to manage and store
documents, links, and information about colleagues.
Social tags and notes - enables users to add social tags to documents, to other SharePoint Server items,
and to other items, such as external web pages and blog posts. Users can also leave notes on profile pages
of a My Site or any SharePoint Server page. Administrators can delete all tags for employees when they
leave the company or remove a tag they do not want.
These features make it possible for users in an organization to share information and to stay informed about what
happens within the organization. Social tags, for example, enable users to tag and track the information in which
they are most interested. Users can be alerted when people with which they work author new blog posts or when
there is a change in organizational metadata.
Like other service applications in SharePoint Server, farm administrators can delegate the administration of all or
part of the User Profile service application to one or more service application administrators. This enables the
User Profile service application to be managed by the appropriate business group. One administrator can manage
all areas of the User Profile service application or areas can be isolated and managed by different administrators.
For example, one administrator can manage My Sites while a different administrator manages social tags and
notes. The User Profile service application can be restricted and made available only to certain departments or
sets of sites based on business need, security restrictions, and budgets.
User profile databases

When you create a User Profile service application, SharePoint Server creates three databases for storing user
profile information and associated data:
Profile database - used to store user profile information.
Synchronization database - used to store configuration and staging information for synchronizing profile
data from external sources such as the Active Directory Domain Services (AD DS ).
Social tagging database - used to store social tags and notes created by users. Each social tag and note is
associated with a profile ID.
Related service applications

The User Profile service application relies on other service applications to implement the full range of social
computing features in SharePoint Server. These related service applications include the following:
Managed metadata service - makes it possible to use managed metadata and share content types across
site collections and web applications. Configure the managed metadata service before you configure the
User Profiles service application.
Search Service application - needed to enable the People Search feature.
See also
Concepts
Administer the User Profile service in SharePoint Server
Create a User Profile service applications in
SharePoint Server

The User Profile service is a shared service in SharePoint Server that provides a central location for configuring
and managing user profiles.
This article contains required information and procedures for configuring a User Profile service application.
Before you begin

Before you begin this operation, review the following information about prerequisites:
You have configure the managed metadata service.
A managed path exists.
An application pool for My Sites exists.
A site collection that uses the My Site Host template exists.
Create a User Profile service application

You can create a User Profile service application by using either the SharePoint Central Administration website or
Microsoft PowerShell. Be sure you're a member of the Farm Administrators group when you perform these
procedures.
To create a User Profile Service application by using Central Administration
1. In Central Administration, in the Application Management section, click Manage service applications.
2. In the Create group of the ribbon, click New, and then click User Profile Service Application in the list
of service applications to create.
3. In the Create New User Profile Service Application dialog box, in the Name section, type a unique
name for the User Profile service application.
4. In the Application Pool section, select Use existing application pool to choose an existing application
pool from the list or select Create a new application pool to create a new application pool.
5. In the Application Pool section, for the Select a security account for this application pool option,
select Predefined to choose an existing predefined security account from the list or select Configurable to
choose an existing managed account.
6. In the Profile Database section, in the Database Server box, type the name of the database server where
you want to create the profile database. In the Database Name box, type the name that you want to use
for the profile database.
7. In the Profile Database section, for the Database authentication option, select Windows
Authentication (recommended) to use Integrated Windows authentication to connect to the profile
database or select SQL authentication to enter the credentials that will be used to connect to the profile
database.
8. In the Failover Server section, in the Failover Database Server box, type the name of the database
server to be used together with SQL Server database mirroring.
9. In the Synchronization Database section, in the Database Server box, type the name of the database
server where you want to create the synchronization database. In the Database Name box, type the name
of the synchronization database.
NOTE
Only ASCII characters are allowed for the synchronization database name.
10. In the Failover Server section under Synchronization Database, in the Failover Database Server box,
type the name of the database server to be used together with SQL Server database mirroring.
11. In the Social Tagging Database section, in the Database Server box, type the name of the database
server where the social tagging database will be located. In the Database Name box, type the name of the
database where social tags will be stored.
12. In the Social Tagging Database section, for the Database authentication option, select Windows
Authentication (recommended) to use Integrated Windows authentication to connect to the social
tagging database or select SQL authentication to type the credentials that will be used to connect to the
social tagging database.
13. In the Failover Server section, in the Failover Database Server box, type the name of the database
server that you want to use with SQL Server database mirroring.
14. In the My Site Host URL section, type the URL of the site collection where the My Site Host is
provisioned.
15. In the My Site Managed Path section, type the managed path where you want to create individual My
Sites.
NOTE
Self-service site creation can be enabled for the web application that hosts My Sites. Users must have Create
Personal Site permissions to create their own My Site. By default, this permission is enabled in SharePoint Server for
all authenticated users. Ensure that you want the default setting to apply to the organization. Or, you can use one or
more security groups to grant the Create Personal Site permission to a subset of users in an organization.
16. In the Site Naming Formatsection, select one of the following formats for naming new personal sites:
User name (do not resolve conflicts)
User name (resolve conflicts by using domain_user name)
Domain and user name (will not have conflicts)
17. In the Default Proxy Group section, select whether you want the proxy of this User Profile service
application to be a part of the default proxy group on this farm.
18. In the Yammer Integration section, select whether you want to use Yammer for social collaboration.
19. Click Create.
See also
Concepts
Overview of My Sites in SharePoint Server

This article provides an overview of My Sites end-user functionality and benefits for consideration by enterprise
business decision makers or SharePoint administrators. It does not discuss the architecture of My Sites or
information about planning and configuring My Sites.
If you are a SharePoint administrator who is responsible for configuring My Sites in your organization, use this
article together with Plan for My Sites in SharePoint Server to understand and plan for My Sites. You can then use
Configure My Sites in SharePoint Server to configure My Sites and Plan user profiles in SharePoint Server to see
how user profile setup can influence the information that is displayed in My Sites.
Uses and benefits of My Sites

In SharePoint Server, a My Site is a personal site for individual users in an organization. Although an organization
can customize My Sites, by default users will be able to click on the app launcher at the top of every page to display
tiles for:
Newsfeed
OneDrive
Sites
The default links on the left navigation bar that are visible to the owner of the My Site are as follows:
Newsfeed
About me
Blog
Apps
When a user views another user's profile, the links on the left navigation bar are similar, but also include a link to
Documents and People. The Documents link lets other users view the My Site owner's public documents stored
on the owner's OneDrive for Business, and the People link displays the people whom the My Site owner is
following.
My Sites give users rich social networking and collaboration features, which enable users to explore and share
interests, projects, business relationships, content, and other data with people in the organization.
Because My Sites enable users to easily share information about themselves and their work, this sharing of
information encourages collaboration, builds and promotes information about expertise, and targets relevant
content to the people who want to see it. Once My Sites are deployed, a user can access his or her My Site by
clicking his or her user name in the top-right corner of a SharePoint Server page and then clicking About me. A
user can also click any photo or a name in a newsfeed to be directed to that user's My Site profile.
Newsfeed
Newsfeed is the user's social hub where he or she can see updates from the people, documents, sites, and tags
that the user is following. Newsfeed is the default page that displays when a user accesses his or her My Site. This
page displays the feed of recent activities related to a user's specified colleagues and interests. Users can customize
their newsfeeds by adding or removing colleagues they are interested in, specifying interests, and configuring the
kind of activities they want to follow, such as when a colleague tags a shared interest.
When the system generates an activity related to a user's action, such as when the user follows a site or changes a
document, the activity includes the URL of the related item and an activity is created with a link to the affected
content. These activities are security trimmed , which means that users can only see activities with links to which
they have permission. This differs from user-generated posts with URLs to site or content, which are not security
trimmed.
The Newsfeed page contains the information shown in the following table.
HEADING DESCRIPTION
Start a conversation A text box in which the user can post to the newsfeed. The
user can either choose to share with everyone, or with the
members of a team site of which he or she is a member.
Following Lists all the conversations, tags, groups, and documents that
the user is following.
Everyone Displays the recent conversations from everyone in the

organization.
Mentions Displays all the mentions other users have made of the user,
tasks assigned to the user, and so on.
Activities Displays all the activities by the user.
Likes Displays all the items that the user has liked.
I'm following Displays a number that indicates how many people,

documents, sites, and tags the user is following. The user can
click the numbers to get more details about any items that
she or she is following.
Trending #tags Lists the top five tags.
OneDrive
The OneDrive tab or tile links to the user's OneDrive for Business. OneDrive for Business is the user's personal
file storage and synchronization service for business use.
The user's OneDrive for Business usually includes a private folder and a folder that is shared with everyone, or
with specific people. For more information, see Overview of OneDrive for Business in SharePoint Server.
Sites
The Sites tab lists the sites that the user is following and suggested sites that the user might find interesting. The
user can use this to easily keep track of the sites he or she is most interested in.
About me
The About me is the default page that displays when a user accesses another user's My Site. This page displays
the user's profile page to other people in the organization. The About me is also the default page that displays
when a user accesses another user's My Site by clicking the user's name or profile picture.
SharePoint Server provides user profile policies that specify how profile information is displayed and how it can be
used. Although there are recommended default policies for features and properties exposed in user profiles and
personal sites, you can configure custom policies to meet specific needs of the organization. For example, you can
configure a property to be more or less visible by default, and allow a user to override default settings for
properties that you want to give them control over. You configure these policies for the User Profile service in the
SharePoint Central Administration website. For more information, see Plan user profiles in SharePoint Server.
The About me page includes a title that is typically "About < user's name>" and it displays the user's profile data,
such as the user's picture, title, group and telephone number.
The About me page contains the information shown in the following table.
HEADING DESCRIPTION
Activities Displays the user's recent activities on newsfeeds, who the

user is following, colleagues the user has added, and so on.
edit your profile By clicking edit your profile link, a user can change or
update their display photo and information, and privacy
settings for their individual profile properties that you allow
them to override in the profile policy. The privacy settings are
assigned to one of the following two privacy groups: Only Me
or Everyone. For example, a user might decide to display
more information, such as a personal phone number.
In Common When a user views another user's profile, he or she can see the
lowest level manager that they share.
Org Chart Displays an organization chart. The chart shows the user's
position in the organization among management, peers, and
direct reports. You can select other people from the chart to
view their profiles.
Blog
Blog is a Web Part page that the My Site owner can use to publish a blog. By default, the Blog page displays a left
navigation pane with links to the user's blog categories and archives that can be edited.
The user can also customize the Blog page by editing the page, by adding apps to the page, or by changing the
look of the page.
Apps
Displays the lists, libraries, and other apps for the user.
Tasks
Displays tasks assigned to the user. This is only visible to the owner of the My Site page.
The tasks can be viewed based on importance, status (active), whether they are completed, recently added, or
personal.
See also
Concepts
Configure My Sites in SharePoint Server
Plan for My Sites in SharePoint Server
Plan user profiles in SharePoint Server
Overview of OneDrive for Business in SharePoint Server

In SharePoint Server, a My Site is a personal site for a user in an organization. Although a My Site appears as a
single site to a user, the My Sites architecture in SharePoint Server consists of a web application, a My Site host
site collection, an individual site collection, and several SharePoint service applications and features. Except for
the individual site collection, all other parts of this infrastructure are configured once and shared among all the
users who are part of the My Sites deployment.
This article contains information about My Sites architecture, related services, and other considerations when
planning to deploy My Sites.
My Sites architecture
The My Sites architecture consists of a web application that hosts My Sites, a My Site host site collection, and
individual site collections for users.
Each user's My Site uses two site collections: the farm's My Site host site collection and the user's individual site
collection. Although you can use an existing web application to host these site collections, we recommend that
you use a dedicated web application to improve performance and manageability.
When you create the My Site host site collection and users create their individual site collections, the data is
maintained in one or more content databases that are associated with the web application that hosts My Sites.
Like other web applications in SharePoint Server, you can add content databases to this web application if you
must have multiple databases for storage. For more information, see Planning for storage requirements later in
this article.
The My Site host site collection and the configuration that enables individual My Sites site collections to be
created are required before users can create My Sites. For more information, see Configure My Sites in
SharePoint Server.
The My Site host site collection and individual site collections are described more fully in the following sections.
My Site host site collection
The My Site host site collection is a special site collection that displays the newsfeed and profile pages of all
users' My Sites. The site collection's site template must be the My Site host site template, available from the
Enterprise tab of the Create Site Collection page. The My Site host site template can be used only once per
User Profile service application, which is discussed later in this article.
My Sites require that a site collection exist at the web application root (which is displayed as / in the user
interface). Without this, you will receive a message that states that there is no site collection at the root when you
try to enable self-service site creation for the web application. Because we recommend that you use a dedicated
web application to host My Sites, you should use the root path for the My Site host collection unless you have a
specific requirement to create the site collection deeper in the uniform resource locator (URL ) path.
Although not recommended, if you create the My Site host deeper in the path, it must be under an explicit
inclusion managed path. Additionally, you must create a separate site collection at the web application root,
although this site collection can be empty and created without a template.
The URL for a My Site host site collection is shared by all users of the same User Profile service application. The
URL for Newsfeed is http:// hostname/default.aspx, and the URL for About Me is http://
hostname/person.aspx, where hostname is the address of the site collection. For example, if you configure your
My Site host site collection at http://contoso.com/my, users access their newsfeeds and profiles at
http://contoso.com/my/default.aspx and http://contoso.com/my/person.aspx, respectively.
Although these URLs are the same for all users of a User Profile service application, the information displayed
for each user is different. SharePoint Server determines the information to display based on the user's logon
account. The information is targeted to that specific user and is provided by the SharePoint service applications
referred to in this article.
When a visitor views another user's My Site, the visitor can see only the user's profile page. This URL is http://
hostname/person.aspx?accountname= account, where hostname is the address of the site collection and
account is the user name (and, if it is configured, the user's domain name). For example,
http://contoso.com/my/person.aspx?accountname=sidney.
Individual site collections
A user's individual site collection hosts the document library of the user's individual My Site. An individual site
collection is created the first time that a user accesses the My Site. This ability to create an individual site
collection requires the following configuration in SharePoint Server:
The web application that hosts My Sites has a wildcard inclusion managed path, such as sites or personal.
This is the path under which the individual site collections will be created when users access their My
Sites for the first time.
The Setup My Sites settings for the User Profile service application are configured to use the URL of the
My Site host site collection and the wildcard inclusion managed path for individual site collections.
The web application is enabled for self-service site creation. This functionality enables the individual site
collections to be created under the specified wildcard inclusion managed path. The self-service site
creation feature has special security considerations for cross-site scripting. This strengthens the
recommendation to host My Sites in a dedicated web application to isolate any scripts running in a My
Site from affecting other sites in your environment.
Users must have Create Personal Site permissions to create a My Site. By default, this permission is
enabled for all authenticated users. For more information, see Plan users and user permissions later in
this article.
The URL to a user's document library section of a My Site is in the format of http:// hostname/ managed_path/
account/documents, where hostname is the address of the My Site host site collection, managed_path is the
managed path for the My Site host, and account is the account of the user logged on. For example, if you
configure your My Site host site collection and managed path at http://contoso.com/my, users access their
documents at http://contoso.com/my/ account/documents.
With the account part of the URL, when you set up My Sites, you have three options to specify how to name an
individual user's site collection, as shown in the following table.
Table: Naming options for an individual user's site collection
OPTION DESCRIPTION
OPTION DESCRIPTION
User name (do not resolve conflicts) By using this option, the My Site name is the user name of
the account. This is not a user's display name. For example, if
a user's friendly name is Sidney Higa and the user's account
is sidney, the site collection is named sidney. Only choose the
first option if you are sure that all user names in your
organization are unique. Otherwise users will encounter
conflicts when they provision their My Sites. If a conflict
occurs, the first user who creates a My Site with a user name
is successful. However, the next user who tries to use the
same user name cannot create a My Site.
User name (resolve conflicts by using By using this option, the first user who has a duplicate user
domain_username) name will have a My Site created by using the user name
only, and a second user who has that same user name will
have a My Site created by using both the domain name and
user name. For example, the first user will have a My Site
created under http://contoso.com/my/sidney/default.aspx
while the second user will have a My Site created under
http://contoso.com/my/CONTOSO_sidney/default.aspx.
Choose this option when it is possible for a user name to
exist multiple times in an organization, such as when you
have multiple domains. Because a user name is guaranteed
to be unique only within its own directory source, this option
prevents two users who have the same user name but
different domains from encountering issues when they create
their My Sites.
Domain and user name (will not have conflicts) By using this option, all My Site names are created by using
both the domain name and user name. For example,
http://contoso.com/my/CONTOSO_sidney/default.aspx.
Choose this option when you want My Sites to be
consistently named with the domain name and user name,
regardless of whether conflicts with user names exist or not.
Related service applications

My Sites rely on several SharePoint service applications and their related databases. These related service
applications are discussed in this section, although you should also refer to the linked articles to fully plan and
implement them to support My Sites in your enterprise.
User Profile service application
The User Profile service application has three databases: profile database, a social database, and a
synchronization database. The profile database stores information about users, such as a profile picture, the
organization the users belong to, and so on. The social database stores pointers to social tags and notes created
by the users when they use the Notes and Tags feature. The synchronization database stores connection
information for profile import. SharePoint Server uses the information in the profile database to personalize the
data displayed on the About Me page of a user's My Site. Additionally, the User Profile service application
enables social computing features, such as tagging, mentions, and newsfeeds for My Sites, which affect the
About Me and Newsfeed sections of a user's My Site.
The User Profile service application is required for My Sites.
Plan for profile synchronization
Although configuring the User Profile service application is required for My Sites, synchronizing profiles
between SharePoint Server and directory services or business applications is optional but highly recommended.
Profile synchronization provides rich functionality for My Sites by enabling the User Profile service application
to collect information about users in an organization from directory services and business applications. As a
result, consistent and timely information is always available on a user's My Site. Information about users can
also be synchronized across the deployment among all site collections that use the same User Profile service
application. User information can also be used by personalization features to increase the value of collaboration
and relationships in an organization.
Plan policies and privacy
SharePoint Server provides a default set of policies that you can configure to make the appropriate information
available to meet the needs of an organization. You can also create and deploy custom policy features to meet
specific needs. When planning for My Sites, you should define which information is needed for key business
processes in an organization and which information might be unsuitable for sharing across an organization.
Between these extremes is the information that should be shared only among some users. In the case of
information that might be unsuitable for sharing across an organization, you must create policies to address
these specific situations.
Additionally, My Site features might store or use personally identifiable information. When planning to deploy
My Sites, make sure that you carefully plan how to control the behavior of these features — or turn off the
features — to help protect the privacy of this information. These decisions are affected by several factors, such as
corporate privacy practices, and regional or national/regional privacy laws.
Plan users and user permissions
For users to create My Sites, maintain their profiles, follow people and content, and use tags and notes, there are
user permissions to configure in the User Profile service application. Determine which of the following
permissions to grant to users or groups of users:
1. Create Personal Site This permission enables users to create a personal site to store their documents,
newsfeed, and followed content.
2. Follow People and Edit Profile This permission enables users to follow people from their My Site and
to edit their personal profile.
3. Use Tags and Notes This permission enables users to use the Tags and Notes feature.
By default, all authenticated users are granted all these permissions, but you can configure specific permissions
depending on your needs. For example, you could allow only full-time employees to create My Sites, instead of
all workers in your organization. There are seven different combinations of user permissions available to grant
to users. However, not all of these permission combinations provide the expected results. As a best practice,
simplify administration by granting permissions to security groups instead of specific users.
NOTE
Changing user permissions in the User Profile service application is not recommended. Any changes that you make will
not impact the user experience in a meaningful way. For example, if you remove the Follow People and Edit Profile
permission the user will still be able to edit profiles and other users will still be able to follow people they choose.
Additionally, if you remove the Follow People and Edit Profile permission for a My Site user the Tags and Notes feature
is disabled. We do not recommend removing any social features.
Managed metadata service application

The managed metadata service application enables web applications to store and access keywords from a
managed metadata term database. For My Sites, this functionality is required for users to specify keywords as
their areas of expertise in the Ask Me About section, to use hash tags in posts in newsfeeds, and for social
tagging by using the Tags and Notes feature of a My Site.
A managed metadata service application is highly recommended for My Sites. It must be configured as the
default keyword term store for the web application.
Although not required for My Sites, the SharePoint Server Search service application is highly recommended to
enable users to search from their My Sites for people in the organization based on names or areas of expertise.
Additionally, when you add a hash tag to microblog posts, users are directed to search results for that tag when
they click it. This search functionality is part of enterprise search planning and configuration.
People search
When a user searches for people, results contain links to the public profiles of users and links to contact them by
email or messaging programs. When planning for My Sites, you might want to consider supplementing the
default people search scope, and supplementing the Search Center tab with customized search scopes and tabs
for more specific groups of users.
If the administrator of the User Profile service application differs from the administrator of the Search service
application, the User Profile service application administrator should review the information architecture and
site hierarchy to determine the key business concepts that might relate to specific groups of users for whom
other users might search across sites. Then the User Profile service application administrator can work with the
Search service application administrator to develop search scopes and people search tabs for those specific
groups. User Profile service application administrators can also use their knowledge of the user profiles they
manage to determine other useful groups of users, and to create additional specific search scopes and search
tabs for those groups.
Site collection administrators can also create site-level search scopes for users who are members of their site
collections.
People search planning also feeds back into user profile planning. Initial planning might reveal people or groups
of users whom you want to make it easier to find. However, additional user profile properties might have to be
created to allow for those users to be found easily.
Expertise search
When planning My Sites, you should determine whether you want to enable users to locate colleagues within
the organization based on the colleagues' expertise. People search and expertise tagging help users locate
people inside an organization who have identified themselves as having significant experience with a particular
subject. Users in your organization can add terms to their profile that describe areas in which they have
experience. These terms are used by people search when a user searches for someone in the organization who
has experience in a particular area.
If email analysis is enabled, users can also find people by using email analysis in Outlook. Colleague suggestions
are imported from Outlook if you are using Outlook email. If you are using Outlook, SharePoint Server analyzes
sent email messages and then makes colleague and keyword suggestions based on this analysis. Users can then
see these suggestions when they edit their profiles.
Although you can enable email analysis for all users in Outlook or only for specific groups by using Group
Policy, users can opt out of this feature. If email analysis is disabled for all users, individual users can still opt in.
Planning for jobs and schedules

The timer jobs in the following table are related to My Sites functionality.
Table: Timer jobs related to My Sites
SERVICES JOBS
Microsoft SharePoint Foundation Web Application My Site Cleanup Job

SERVICES JOBS
Microsoft SharePoint Foundation Timer User Profile service application name - User Profile to
SharePoint Full Synchronization
User Profile service application name - User Profile to
SharePoint Quick Synchronization
User Profile Service User Profile service application name - Feed Cache
Repopulation
User Profile service application name - Activity Feed Job
User Profile service application name - Activity Feed
Cleanup Job
User Profile service application name - My Site
Suggestions Email Job
You can enable or disable these jobs, and configure their schedules to meet the needs of your organization.
These jobs are located in the SharePoint Central Administration website, under Monitoring, in the Review job
definitions section. In the View list, select Service and then, from the Service menu, select Change Service
to select different services and view the related timer jobs.
Planning for geographically distributed deployments

When planning for My Sites, you must consider the location of the users in the organization and the number of
farms or User Profile service applications that will host My Sites. If you have more than one farm or User Profile
service application, you will likely have to configure trusted My Site host locations.
User Profile service deployment considerations for My Sites
My Sites depend on the User Profile service application. In SharePoint Server, My Sites should be configured by
using one User Profile service application. Server farm architectures using a single User Profile service
application include the following:
A single server farm with a single User Profile service application.
An enterprise services farm sharing a single User Profile service application together with one or more
consuming farms. The My Sites Host is located on one of the consuming farms. In SharePoint Server, the
consuming farm must be physically located in the same datacenter as the enterprise services farm when
you share the User Profile service application. Consuming the User Profile service application from
another farm over a WAN connection is not supported. This means that both the User Profile service
application and the My Site Host must be located in the same datacenter.
Trusted My Site host locations
The Trusted My Site Host Locations feature prevents a user from creating more than one My Site in an
organization with multiple User Profile service applications.
For example, in a server farm deployment that spans geographic regions, you might have separate User Profile
service applications for each region or regional server farms in the environment. By default, a user can create a
different My Site in each User Profile service application or server farm, which could cause unwanted results
from both an administration perspective and a user perspective. When you have multiple My Sites for an
individual user in an organization, server resource needs increase. Additionally, users might not understand or
want multiple My Sites.
To prevent individual users from creating multiple My Sites, configure trusted My Site host locations. When
specified, users are redirected to the single My Site host location that is intended for their accounts regardless of
where they are browsing when they attempt to create or access their My Sites. This feature ensures that each
user can create only one My Site in an organization.
Configuring trusted My Site host locations is optional.
Planning for the multilingual user interface

When enabled, users can use the multilingual user interface feature for their My Sites. This feature is used to
display the site's user interface in a secondary language that the user prefers instead of the default, primary
language that was selected when the site was created. By default, when a new site is created, it is created in the
default, primary language of the SharePoint Server 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 My Sites, the multilingual user interface feature is controlled by the Language Options setting when you
configure My Site settings. The languages that are available to users correspond to the language packs installed
in the server farm. For more information about language packs, see Install or uninstall language packs for
Planning for storage requirements

Because My Site users can edit their profiles, generate newsfeed activities, upload and download documents,
and so on, plan carefully for the storage and capacity needs of your environment. Take into consideration the
content databases for My Sites and the databases for the related services of My Sites.
Additionally, SharePoint Server includes a default Personal Site quota template, which has a storage limit of 100
MB and no user limit. This quota template is used for each user's individual site collection in the user's My Site.
Because feed activity is now stored in lists in the user's My Site, and those lists are not archived, storage needs
will continue to grow. Therefore, consider increasing the personal site quota to 500 MB or more depending on
the activity that you expect in the feeds.
Configuring quota templates is optional, but recommended.
Planning for file types

Like other web applications in SharePoint Server, you can configure the file types that users can upload to or
download from the web application that hosts My Sites. This is useful if you want to prevent users from
uploading or downloading file types that can be large, such as media file types, or file types that can be run on
the client computer, such as executable files.
By default, SharePoint Server blocks certain file types. However, you can configure My Sites to allow these file
types, or add other file types to block depending on the needs in your organization.
Configure My Sites in SharePoint Server

This article describes how to set up My Sites in SharePoint Server. Like other tasks in SharePoint Server, there
are multiple ways to complete a task. This article provides ordered tasks with prerequisites and procedures to
help you set up My Sites in your enterprise.
Before you set up My Sites, ensure that you understand the concepts and terminology in Overview of My Sites in
SharePoint Server and Plan for My Sites in SharePoint Server.
We recommend that you perform all of the procedures in the order listed for best results, although not all of
them are required.
Prerequisites
Because My Sites have dependencies on other service applications and features in SharePoint Server, ensure that
you meet the prerequisites in this section before you perform the procedures in this task.
NOTE
My Sites are hosted by a web application and rely on a User Profile service application. Both are described in this section.
My Sites also requires a managed metadata service application. We recommend that you also have a Search service
application to use with My Sites, but this is not required. Without the Search service application, some My Sites
functionality is affected. For more information, see Plan for My Sites in SharePoint Server.
Web application
Although you can use an existing web application, for optimal performance and security, we recommend that you
create the My Site host site collection in a dedicated web application. For more information, see Create a web
application in SharePoint Server.
IMPORTANT
If a My Site host site collection was created during initial deployment and configuration, we recommend that you do not
use it because it was created in the default web application. Delete this site collection, and create a new web application
that is dedicated to hosting My Sites. Then create a new My Site host site collection in the dedicated web application.
User Profile service application and profile synchronization

Ensure you have a User Profile service application that you want to use for My Sites.
IMPORTANT
Although the Create New User Profile service application dialog box requests information in the My Site Host URL
and Personal Site Location sections, for this task, remove any default values and leave those fields blank when you create
the User Profile service application. Additionally, you can select any of the options in Site Naming Format. These settings
will be configured separately later in this task.
NOTE
This section only applies to SharePoint Server 2013. > Optionally, configure profile synchronization if you want to
synchronize user and group profile information that is stored in the SharePoint Server 2013 profile database with profile
information that is stored in a directory service or business system.
Create a My Site host site collection

The My Site host site collection is a site collection that uses the Enterprise site template named My Site Host.
This site collection must be created in the web application that you want to host My Sites. Generally, this site
collection can be created at the root path of the web application, although it can be created as an explicit inclusion
managed path deeper in the URL as long as there is a site collection created at the web application root. For
more information about how to select the path for the My Site host collection, see Plan for My Sites in
SharePoint Server.
To create a My Site host site collection
To create a My Site host site collection, you must be a member of the Farm Administrators group on the
computer running the SharePoint Central Administration website or a service application administrator for
the services related to My Sites. If you are a service application administrator, you must also have permission
to create site collections in the web application that you dedicate to host My Sites.
2. In Central Administration, click Application Management, and then click Create site collections.
3. On the Create Site Collection page, in the Web Application section, ensure that the selected web
application is the web application that you want to host My Sites. If it is not, expand the list, and then click
Change Web Application. In the Select Web Application dialog box, select a different web application.
4. In the Title and Description section, type a title and description for the site collection.
5. In the Web Site Address section, select the URL where you want this site collection created. Generally,
you should use the default path (which is displayed as / in the user interface), which is the root of the web
application. For more information about this path, see My Sites architecture in Plan for My Sites in
SharePoint Server.
6. In the Template Selection section, on the Enterprise tab, click My Site Host.
7. In the Primary Site Collection Administrator section, and optionally in the Secondary Site
Collection Administrator section, type an account in the format domain\username to specify an
administrator for the site collection.
8. Optionally, in the Quota Template section, select a quota template for the My Site host site collection.
This quota template does not affect the individual site collections that users create for their My Sites. For
more information, see Planning for storage requirements in Plan for My Sites in SharePoint Server.
9. Click OK. Copy this site collection URL for later reference.
Add a wildcard inclusion managed path to the web application

The wildcard inclusion managed path is the path under which separate site collections are created for a user's My
Site. Creation of the site collection occurs the first time that a user views the user's My Site. This functionality is
available only when self-service site creation is also enabled. Enabling self-service site creation is discussed later
in this article.
To add a wildcard inclusion managed path to the web application
To add managed paths, you must be a member of the Farm Administrators group on the computer running
the SharePoint Central Administration website.
2. In Central Administration, click Application Management, and then click Manage Web applications.
3. On the Web Applications Management page, select the web application that you created to host My
Sites.
4. On the Web Applications tab, in the Manage group, click Managed Paths.
5. In the Define Managed Paths dialog box, in the Add a New Path section, in the Path box, type the path
that you want to append to the URL namespace, and then select Wildcard inclusion. For example, if your
web application URL is http://mysites.contoso.com/ and you want users' individual site collections created
under a path named "personal", type personal in the Path box. Separate My Sites site collections will be
created for each user under http://mysites.contoso.com/personal/.
6. Click Add Path, and then click OK.
7. Copy this managed path for later reference.
Connect the web application to service applications

The web application that hosts My Sites must be connected to service applications in SharePoint Server. The
User Profile service application is required for My Sites. The managed metadata service application and Search
service application are highly recommended. For more information, see My Sites architecture in Plan for My
Sites in SharePoint Server.
Additionally, if you have other SharePoint sites from which you want users to be able to access their My Site and
About Me links from the upper-right corner menu, connect the web applications of those sites to the User
Profile service application.
To connect the web application to service applications
To connect a web application to a service application, you must be a member of the Farm Administrators
group on the computer running the SharePoint Central Administration website.
2. In Central Administration, in the Application Management section, click Manage Web applications.
3. On the Web Applications Management page, select the web application that you created to host My
Sites.
4. On the Web Applications tab, in the Manage group, click Service Connections.
5. In the Configure Service Application Associations dialog box, in the Edit the following group of
connections list, select default if the default group contains the service applications that you want to
connect to the web application.
If you choose [Custom ], select any service applications to which you want to connect the web application,
including the User Profile service application, the managed metadata service application, and the Search
service application.
6. Click OK.
Enable self-service site creation for the web application

Self-service site creation enables the automatic creation of a separate site collection for users when they first
view their My Site.
To enable self-service site creation for the web application
To enable self-service site creation, you must be a member of the Farm Administrators group on the computer
running the SharePoint Central Administration website.
2. In Central Administration, in the Application Management section, click Manage Web applications.
3. On the Web Applications page, select the web application that you created to host My Sites.
4. On the Web Applications tab, in the Security group, click Self-Service Site Creation.
5. In the Self-Service Site Creation Management dialog box, in Site Collections, select On. Optionally,
in Quota template to apply, select a quota template.
6. In Start a Site for SharePoint Server 2013 and 2016 or Site Creation in SharePoint Server 2019, any
option may be selected, including hiding the Self-Service Site Creation process from the user.
7. Click OK to finish.
Perform these additional steps to configure permissions for users to create team sites from their My Sites to use
site feeds.
1. In the Policy group, click Permission Policy.
2. On Manage Permission Policy Levels dialog box, click Add Permission Policy Level.
3. Type a name for the permission policy.
4. Under Permissions, in Site Permissions, select the Grant option for Create Subsites - Create subsites
such as team sites, Meeting Workspace sites, and Document Workspace sites.
5. Click Save.
6. In the Policy group, click User Policy.
7. On Policy for Web Application dialog box, click Add Users.
8. On Add Users, in Zones select (All Zones), then click Next.
9. In Choose Users, enter the user names of the users that you want to create team sites from their My Site
to use site feeds. If all users can create team sites from their My Site to use site feeds, click the Browse
icon. In Select People and Groups, click All Users, then click Everyone. Click Add, and then click OK.
10. In the Choose Permissions section, select the name of the Permission Policy created previously.
11. Click Finish, and then click OK.
Configure My Site settings for the User Profile service application

After you have a My Site host site collection and wildcard inclusion managed path configured for My Sites, you
can update the My Sites settings in the User Profile service application. Most of these settings are configured
during initial deployment and only change infrequently during maintenance operations afterward.
To configure My Site settings for the User Profile service application
To configure My Site settings for the User Profile service application, you must be a member of the Farm
Administrators group on the computer running the SharePoint Central Administration website or a service
application administrator for the User Profile service application.
2. In Central Administration, in the Application Management section, click Manage service
applications.
3. Click the User Profile service application that you connected to the web application hosting My Sites
earlier in this task.
4. On the Manage Profile Service page, in the My Site Settings section, click Setup My Sites.
5. On the My Sites Settings page, in the Preferred Search Center section, specify settings for the search
center to direct users to when they search for people or documents from their About Me profile page. If
you do not have a search center set up yet, you can skip this step and complete it later. For more
information, see Search service application in Plan for My Sites in SharePoint Server.
6. In the My Site Host section, type the URL of the My Site host site collection that you created earlier in
this task.
7. The My Site Host URL in Active Directory section uses Exchange Autodiscover to allow client and
mobile phone applications to find a user's SharePoint Server 2016 My Site.
8. In the Personal Site Location section, type the wildcard inclusion managed path you configured earlier
in this task. By default, personal is prepopulated in the box. However, if you chose a different path for
your wildcard inclusion managed path, replace personal with your path.
9. In the Site Naming Format section, select a naming format for the My Sites site collections that will be
created when users view their My Sites for the first time. For more information about these formats, see
My Sites architecture in Plan for My Sites in SharePoint Server.
10. In the Language Options section, there is an option to specify whether users can select a preferred
language for their My Site. However, the current behavior is to default to the installation language for
SharePoint. My Sites architecture in Plan for My Sites in SharePoint Server
NOTE
This section is not present in SharePoint Server 2019.
11. In the Read Permission Level section, specify the users or groups that can view other users' My Sites
when they are created. By default, this includes all authenticated users. However, you can select a more
specific group or users depending on the needs of your deployment.
12. In the Security Trimming Options section, specify how system generated posts are checked for
permissions before they are displayed in feeds and on the Tags and Notes page.
13. In the Newsfeed section, enable system generated posts to the feed on My Sites by selecting Enable
activities in My Site newsfeeds. This option is selected by default. This is important in hosted
environments where tenants can share the same User Profile service but have different requirements on
whether they can enable newsfeeds for their users.
14. In the E -mail Notifications section, specify an email address to use as the sender email address for My
Site email notifications. This account does not have to be a real monitored email address. If you want to
receive notifications for newsfeed activities, such as replies to your posts or when someone follows you,
select Enable newsfeed email notifications.
IMPORTANT
You must add the IP address of the farm's outbound SMTP server to the safe list in Exchange Server 2013 to
prevent My Site email notifications from being sent to the Junk folder.
15. In the My Site Cleanup section, specify a new owner of a My Site if the existing My Site user is removed
from the profile database. For example, if a user leaves the company and is no longer in the profile
database, the user's My Site will be deleted together with any content. However, before it is deleted, a new
owner can recover any important content. Select Enable access delegation for the My Site cleanup job
to first attempt to assign ownership of the My Site to the user's manager. If no manager is found, the My
Site is assigned to the user specified in Secondary Owner. The new owner has two weeks to retrieve
content from the My Site before it is deleted.
16. In the Privacy Settings section, select Make My Sites Public to make all users' My Sites public. This
option is not selected by default.
NOTE
When a user's My Site is public, the user's list of followers, the user's list of people they are following, and all
activities (including new follow notifications, social tagging and rating of content, birthdays, job title changes,
workplace anniversary, updating Ask Me About, posting on a note board, and new blog posts) will be public. Any
policies set within People and Privacy on the Manage Policies page is overridden.
17. Click OK.

For more information about additional timer jobs for My Sites, see Planning for jobs and schedules in Plan for
My Sites in SharePoint Server.
Enable the User Profile Service Application - Activity Feed Job

The User Profile Service Application - Activity Feed Job creates system generated posts in the feeds for the
following events:
Following a tag
Tagging an item
Birthday celebration
Job title change
Workplace anniversary
Updates to Ask Me About
Posting on a note board
After you configure My Sites, enable the User Profile Service Application - Activity Feed Job so that users
receive system generated posts in the Newsfeed on their My Sites.
There are other timer jobs related to My Sites that you might want to review and change default settings for. For
more information about jobs related to My Sites functionality, see Planning for jobs and schedules in Plan for My
Sites in SharePoint Server.
To enable the User Profile Service Application - Activity Feed Job
To configure timer jobs, you must be a member of the Farm Administrators group on the computer running
the SharePoint Central Administration website.
2. In Central Administration, click Monitoring, and then click Review job definitions.
3. On the Job Definitions page, in the View list, select Service. The Service list appears.
If the Service list does not display User Profile Service, in Service, click No selection, then click Change
Service. On the Select Service page, use the arrows in the upper-right corner to locate User Profile
Service, and then click it. The Job Definitions page updates with the User Profile service jobs.
4. Click the activity feed job for the User Profile service application that you created in Prerequisites earlier in
this article. The job name is in the format User_Profile_service_name - Activity Feed Job, where
User_Profile_service_name is the name that you specified for your User Profile service application.
5. On the Edit Timer Job page, in the Recurring Schedule section, select the interval that you want the job
to run. Available intervals are Minutes, Hourly, Daily, Weekly, and Monthly. Selecting a shorter
interval, such as Minutes or Hourly, ensures that activities appear on users' My Site newsfeeds more
frequently. However, it increases load on the system depending on how many activities are available.
Selecting a longer interval, such as Daily, Weekly, or Monthly, reduces the number of times the job runs
and processes feeds. However, it also means that users receive less frequent updates to activities in their
newsfeeds.
6. Click Enable.
7. Optionally, click Run Now to run the job immediately without waiting for the next scheduled interval.
Next steps
After you configure My Sites by using the procedures in this article, consider whether you require the following
optional procedures:
Configure trusted My Site host locations
Configure links to Office client applications
Promote site links on My Sites
Start related services
Configure trusted My Site host locations
Trusted My Site Host Locations is an optional feature that prevents a user from creating more than one My
Site in an organization with multiple User Profile service applications.
User Profile service application administrators can add links to trusted My Site host locations when they want to
give users access to My Sites on multiple User Profile service applications. In most cases, links to trusted My Site
host locations will be targeted to individual users or groups of users based on an identified business need. The
links can be maintained and changed over time as business and user needs change. User Profile service
application administrators can delete a link to a trusted My Site host locations when the users targeted by the link
no longer require access to My Sites in multiple locations.
To add a trusted My Site host location by using Central Administration
To use Central Administration to add a trusted My Site host location, you must be a member of the Farm
Administrators group or a Service Application Administrator for the User Profile service application.
2. On the Central Administration Web site, under Application Management, click Manage service
applications.
3. On the Manage Service Applications page, select the User Profile service application from the list of
service applications.
4. On the ribbon, click Manage.
5. On the Manage Profile Service page, under My Site Settings, click Configure Trusted Host Locations.
6. On the Trusted My Site Host Locations page, click New Link to add a trusted My Site host location.
7. On the Add Trusted Host Location page, enter the URL of the trusted personal site location in the URL
box.
8. In the Description box, enter a description for the trusted personal site location.
9. Optionally, in the Target Audiences box, either type the user names or group names in the
corresponding box or click Browse to select audiences by browsing, and then click OK.
Configure links to Office client applications
Users' My Sites are convenient locations for users to save files that they work on in Office client applications,
such as Word, Excel, and PowerPoint. After you configure an environment for My Sites, you can add a link to the
Favorite Links section that users see when they save documents in the Save As dialog box in Office client
applications. Users can then select their My Site and save files to the Documents library available on their My
Site.
To add a link to Office client applications
To add a link to Office client applications, you must be a member of the Administrators group on the
computer that is running the SharePoint Central Administration Web site.
applications.
5. On the Manage Profile Service page, under My Site Settings, click Publish Links to Office Client
Applications.
6. On the Published links to Office client applications page, click New Link.
7. On the Add Published Link page, in the URL box, type the URL of the location where users will be able to
publish links.
8. In the Description box, type a brief name for this location.
This is the name that will appear in the Favorite Links section of the Save As dialog box.
9. Select the type of the location that this link represents. For example, if the target location is a SharePoint
document library, select Document Library.
10. In the Target Audiences box, either type the name of the user or group to add or using the address book
to find a user or group to add. Separate multiple user names or group names with a semicolon (;). You
may also type All site users to select all users.
NOTE
To use the address book, click the book icon. In the dialog box that appears, type all or part of a user's name, and
then press ENTER. Scroll through the search results, and double-click the name of the user or users whom you want
to add. Then click OK.
11. Click OK.

The new link is displayed in the list of links on the Published links to Office client applications page.
Promote site links on My Sites
If your organization wants to provide important information to users, it can do so by promoting a site link to a
user's My Site. When you promote a site link, it appears on all the My Sites in the site collection. They can be
used to display important company information. For instance, your organization might want to give users quick
access to a timesheet. The destination of the link can be a site within the company intranet or an external site on
the Internet.
Add promote a site link to My Sites
To use Central Administration to add a trusted My Site host location, you must be a member of the Farm
Administrators group or a Service Application Administrator for the User Profile service application.
applications.
5. On the Manage Profile Service page, under My Site Settings, click Manage promoted sites.
6. On the Promoted Sites page, click New Link.
7. On the Promoted a Site page, in the Properties section, do the following:
8. In the URL box, type the URL of the site to which you want to link.
9. In the Description box, type a description of the site.
10. In the Owner box, type the name of an owner for this link, or click Browse to select an owner from the
People Picker.
11. Leave Target Audiences blank.
When you leave this box blank, the link that you specified in the URL box appears on the My Sites top link
bar for all users.
NOTE
If you want to specify target audiences for the site, either type the audience names in the Target Audiences box or
click Browse to use the Select Audiences page. This option requires that you define an audience, set up rules for
this audience, and compile the audience.
12. Click OK.

Start related services
If the related services for My Sites have not been started yet, start them so that My Sites functionality is available
in your environment. For more information, see Start or stop a service in SharePoint Server.
Upgrade and Update

Upgrading to a new version of SharePoint? The first step in any upgrade process is to learn about the process itself
so that you can plan and prepare appropriately. These articles help you understand how the SharePoint upgrade
process works. These articles also include overviews of how to upgrade service applications.
Applying updates to a current version? Microsoft periodically releases software updates for SharePoint. These
articles and related resources provide information about the software update process for SharePoint Server 2013,
SharePoint Server 2016, and SharePoint Server 2019.
High level overview to upgrade from SharePoint 2013
to SharePoint Server 2019
Overview
The upgrade scenario has not changed in SharePoint Server 2019. There is no direct upgrade path from 2013 to
2019. To upgrade to SharePoint Server 2019, you must upgrade SharePoint 2013 to SharePoint Server 2016, and
then upgrade to SharePoint Server 2019. Your databases must be at a SharePoint Server 2016 RTM version or
higher when you upgrade to SharePoint Server 2019. Any database with a lower version will be locked and
upgrade will not start.
For a visual look of the high-level steps, see
FILE TYPE DOWNLOAD LOCATION
Visio Upgrade from SharePoint 2013 to SharePoint Server 2019
PDF Upgrade from SharePoint 2013 to SharePoint Server 2019
NOTE
The steps for creating and restoring service applications only applies to these six:
• Secure Store service application

• Business Data Connectivity service application
• Managed Metadata service application
• PerformancePoint Services service application
• User Profile service application
• Search service application
For the specific, end to end steps to upgrade SharePoint 2013 to SharePoint Server 2016, see Upgrade to
Steps to Upgrade
2013
In SharePoint 2013, if you have any web applications that are in windows authentication mode, you should convert
them to claims authentication. Claims authentication is the default mode in SharePoint Server 2016 and SharePoint
Server 2019.
Next, upgrade all the site collections from 14 mode to 15 mode by using the Upgrade-SPSite cmdlet. Any database
with a 14 version will be locked and prevented from upgrading to SharePoint Server 2016. After the site collections
have been upgraded, create a backup of all content and service application databases from your old farm (for
example, SQL2013). Restore these databases to a new farm’s SQL Server in SharePoint Server 2016 (for example,
SQL2016).
2016
In SharePoint Server 2016, build a new temporary farm that includes service applications. When the service
applications are created use the existing database names that reside on SQL2016. After the new farm is created,
create a new web application with a temporary database. Install any full trust solutions, administrator approved
InfoPath forms, etc. Dismount the temporary content database from the web application.
NOTE
You may need to delete the temporary content database from the SQL Server.
Start the upgrade process to SharePoint Server 2016 by running the Mount-SPContentDatabase cmdlet on the
restored content databases from SQL2016. After the upgrade process is complete, perform any individual
configuration changes that are not part of the service application and content databases, such as
incoming/outgoing email settings, etc.
2019
The steps to upgrade from SharePoint Server 2016 to SharePoint Server 2019 are the same as going from
SharePoint 2013 to SharePoint Server 2016 except for converting web applications to claims authentication and
upgrading database modes to level 15. These are not required.
Create a backup of all content and service application databases from your temporary farm (for example,
SQL2016). Restore these databases to a new farm’s SQL Server in SharePoint Server 2019 (for example,
SQL2019).
In SharePoint Server 2019, build a new farm that includes service applications. When the service applications are
created use the existing database names that reside on SQL2019. After the new farm is created, create a new web
application with a temporary database. Install any full trust solutions, administrator approved InfoPath forms, etc.
Dismount the temporary content database from the web application.
NOTE
You may need to delete the temporary content database from the SQL Server.
Start the upgrade process to SharePoint Server 2019 by running the Mount-SPContentDatabase cmdlet on the
restored content databases from SQL2019. After the upgrade process is complete, perform any individual
configuration changes that are not part of the service application and content databases, such as
incoming/outgoing email settings, etc.
See Also
Overview of the upgrade process to SharePoint Server 2019

The following articles provide information about performing an upgrade to SharePoint Server 2019.
CONTENT DESCRIPTION
Get started with upgrades to Find resources about how to start the
SharePoint Server 2019 upgrade process from SharePoint
Server 2016 to SharePoint Server 2019.
Upgrade databases from SharePoint Find resources to help you perform the
2016 to SharePoint Server 2019 steps to upgrade databases from
SharePoint Server 2016 to SharePoint
Server 2019.
Upgrade site collections to SharePoint Find out how to upgrade a site

Server 2019 collection to SharePoint Server 2019.
Video: Cleanup of databases after Learn how to use Windows Powershell

upgrade procedure scripts to assist in cleaning up
databases after a successful upgrade
procedure.
Get started with upgrades to SharePoint Server 2019

The first step in any upgrade process is to learn about the process itself so that you can plan and prepare
appropriately. These articles help you understand how the SharePoint upgrade process works. These articles also
include overviews of how to upgrade service applications.
The following downloadable resources, articles, and related resources provide information about understanding
the upgrade for SharePoint Server 2019.
CONTENT DESCRIPTION
Overview of the upgrade process to Get a visual overview of the steps

SharePoint Server 2019 involved in performing an upgrade.
Services upgrade overview for SharePoint Server 2016 included several

SharePoint Server 2019 service applications, some of which
have databases that can be upgraded
when you upgrade to SharePoint Server
2019. Find out which service application
databases can be upgraded and what
steps you must take before, during, and
after the upgrade for your service
applications.
Overview of the upgrade process to SharePoint
Server 2019

To upgrade from Microsoft SharePoint Server 2016 to SharePoint Server 2019, you use the database-attach
method. In the database-attach method, you first create and configure a SharePoint Server 2019 farm. Then you
copy the content and service application databases from the SharePoint Server 2016, and then attach and
upgrade the databases. This upgrades the data to the new version. Site owners can then upgrade individual site
collections.
SharePoint Server 2019 supports an upgrade from a RTM version of SharePoint Server 2016.
NOTE
All databases must be upgraded to version 16.0.4351.1000 or higher, otherwise upgrade to SharePoint Server 2019 will be
blocked.
After you've configured a new SharePoint Server 2019 environment, you can copy the content and service
application databases from the SharePoint Server 2016 to the SharePoint Server 2019 environment. You use a
backup and restore process to copy the database. You can also choose to set the databases to read-only in the
SharePoint Server 2016 environment so that users can continue to access their information, but not change it.
Before you attach and upgrade the content databases, review the following information and take any
recommended actions.
Make sure 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.
Make sure that the account that you use to create web applications is a member of the Farm
administrators group in the SharePoint Central Administration website.
Figure: The sequence of upgrade stages
This article helps you to understand the upgrade sequence so that you can plan an upgrade project. To get
detailed steps for an upgrade, see Overview of the upgrade process to SharePoint Server 2019 and Upgrade site
collections to SharePoint Server 2019.
Create the SharePoint Server 2019 farm
The first stage in the upgrade process creates the new SharePoint Server 2019 farm:
1. A server farm administrator installs SharePoint Server 2019 to a new farm. The administrator configures
farm settings and tests the environment.
2. A server farm administrator sets the SharePoint Server 2016 farm to read-only so that users can continue
to access the old farm while upgrade is in progress on the new farm.
Figure: Create new farm, set old farm to read-only
Copy the SharePoint Server 2016 databases

The second stage in the upgrade process copies the databases to the new environment. You use SQL Server
Management Studio for these tasks.
1. With the farm and databases in read-only mode, a server farm administrator backs up the content and
service application databases from the SQL Server instance on the SharePoint Server 2016 farm.
2. The server farm administrator restores a copy of the databases to the SQL Server instance on the
SharePoint Server 2019 farm and sets the databases to read-write on the new farm.
Figure: Use SQL Server tools to copy databases
Upgrade SharePoint Server 2016 databases and service applications
The third stage in the upgrade process upgrades the databases and service applications.
1. A server farm administrator configures the service applications for the new farm. The following service
applications have databases that you can upgrade during this process:
Business Data Connectivity service application
Managed Metadata service application
PerformancePoint Services service application
Secure Store Service application
2. A server farm administrator creates a web application on the SharePoint Server 2019 farm for each web
application on the SharePoint Server 2016 farm.
Figure: Create web applications for upgrade
3. A server farm administrator installs all server-side customizations.
Figure: Copy customizations to the new farm
4. A server farm administrator then attaches the content databases to the new farm and upgrades the
content databases for those web applications.
Figure: Upgrade the databases by using Microsoft PowerShell
5. A server farm administrator confirms that the upgrade is successful.
Upgrade SharePoint Server 2016 site collections

The final stage in the upgrade process is to upgrade the site collections. The upgrade process for My Sites is
slightly different from for other types of site collections.
Upgrade My Sites
IMPORTANT
This section applies to SharePoint Server 2019 only.
A server farm administrator upgrades the My Site host and then individual users can upgrade their My Sites or
the farm administrator can upgrade them by using PowerShell. The following illustration shows four stages for
the My Site host and My Sites during the upgrade process.
Figure: Stages in upgrading My Sites
1. The My Site host has not been upgraded. My Sites cannot be upgraded yet.
2. A server farm administrator has upgraded the My Site host. No My Sites have been upgraded.
3. Some users have upgraded their My Sites.
4. All My Sites have been upgraded.
NOTE
A server farm administrator can choose to force an upgrade of My Sites without waiting for users to upgrade them. For
details and steps, read Upgrade site collections to SharePoint Server 2019.
Upgrade other SharePoint Server 2016 site collections

For information about how to upgrade a site collection, see Upgrade site collections to SharePoint Server 2019.
NOTE
A server farm administrator can also force specific site collections to be upgraded without waiting for the site owners to
upgrade them. For details and steps, read Upgrade site collections to SharePoint Server 2019.
Services upgrade overview for SharePoint Server
2019

The upgrade process for SharePoint Server 2019 uses the database attach upgrade method. When you move your
databases to a new farm and upgrade the content, you must create your services infrastructure in the new farm,
and configure the services appropriately for your new farm and new version. The following service applications
have databases that can be upgraded when you upgrade from SharePoint Server 2016 to SharePoint Server 2019:
NOTE
Word Automation Services and Machine Translation Services can't be upgraded. A new service instance needs to be created.
Attaching and upgrading these databases configures these service applications. Settings for other services will
have to be reconfigured when you upgrade.
Database attach upgrade with services

You must create the service applications on your new farm before you upgrade your content databases. The steps
included in the installation guide above describe how to use the Farm Configuration Wizard to enable all service
applications. Some service applications can be upgraded by using a service application database upgrade. If you
want to upgrade these service applications by upgrading the service application databases, you should not use the
Farm Configuration Wizard to configure these service applications when you set up your new farm.
The following service applications can be upgraded by performing a services database upgrade:
Business Data Connectivity service
The Business Data Connectivity service uses a database to store information about external data. This
database must be upgraded as part of a services database attach upgrade. This service application is also
available in SharePoint Foundation 2013.
Managed Metadata service
The Managed Metadata service uses a database to store metadata information. This database must be
upgraded as part of a services database attach upgrade. You must attach and upgrade the database for this
service and for the User Profile service before you can upgrade any My Sites.
PerformancePoint services
PerformancePoint Services use a database to store information. This database must be upgraded as part of
a services database attach upgrade.
Secure Store service
The Secure Store Service uses a database to store information. This database must be upgraded as part of a
services database attach upgrade. You have to upgrade the data for this service application so that any
connections from Excel Services Application and Business Connectivity Services can work with existing
passwords.
User Profile service
The User Profile service uses databases to store profile, social, and sync information. These databases must
be upgraded as part of a services database attach upgrade. You have to attach and upgrade the databases
for this service and for the Managed Metadata service before you can upgrade any My Sites.
Search
The Search service uses several databases. The search administration database stores search configuration
data, such as the topology, crawl rules, query rules, and the mappings between crawled and managed
properties. The analytics reporting database stores the results of usage analytics and statistics information
from the analyses.
The search administration database must be upgraded as part of a services database attach upgrade, and you can
optionally upgrade the analytics database as part of the services database attach upgrade. You have to attach and
upgrade the database for the User Profile service and Managed Metadata service before you upgrade the search
databases. You cannot use the database attach approach for the rest of the search databases, these databases are
re-created when you upgrade the Search service application.
Specifically, the following service application databases can be upgraded:
SERVICE APPLICATION DEFAULT DATABASE NAME
Business Data Connectivity BDC_Service_DB_<GUID>
Managed Metadata Managed Metadata Service_<GUID>
PerformancePoint PerformancePoint Service Application_<GUID>
Search Search_Service_Application_DB_<GUID>
Search_Service_Application_AnalyticsReportingStoreDB_<GUI
D>
Secure Store Secure_Store_Service_DB_<GUID>
User Profile: Profile and Social databases User Profile Service Application_ProfileDB_<GUID>
User Profile Service Application_SocialDB_<GUID>
User Profile Service Application_SyncDB_<GUID>
The steps to upgrade these service application databases are included in Upgrade service applications to
Considerations for specific services

The following services in SharePoint Server 2016 also require additional steps to enable and configure when you
upgrade:
InfoPath Forms Service
This service is not part of the Farm Configuration Wizard. If you want to use this service, you can use the
Configure InfoPath Forms Services link on the General Application Settings page in SharePoint
Central Administration to configure it. If you want to continue using form templates from your previous
environment, you can export any administrator-deployed form templates (.xsn files) and data connection
files (.udcx files) from your SharePoint Server 2016 environment, and then import them to your new
SharePoint Server 2019 environment by using the Export-SPInfoPathAdministrationFiles PowerShell
cmdlet. If the URL of the new server differs from the URL of the previous server, you can run the Update-
SPInfoPathAdminFileUrl PowerShell cmdlet to update links that are used in the upgraded form
templates.
See also
Concepts
Upgrade content databases to SharePoint Server 2019
Upgrade databases from SharePoint 2016 to

The following articles provide information about upgrading databases to SharePoint Server 2019.
CONTENT DESCRIPTION
Create the SharePoint Server 2019 farm for a database attach Create and configure a SharePoint Server 2019 farm so that
upgrade you can upgrade databases from SharePoint Server 2016.
Copy databases to the new farm for upgrade to SharePoint Copy SharePoint Server 2016 content and service databases
Server 2019 to a SharePoint Server 2016 farm so that you can upgrade
the data to SharePoint Server 2019.
Upgrade service applications to SharePoint Server 2019 Upgrade service applications (Business Connectivity Services,
Managed Metadata, Secure Store, User Profiles, Search) to
Upgrade content databases to SharePoint Server 2019 Learn how to upgrade content databases from SharePoint
Server 2016 to SharePoint Server 2019.
Verify database upgrades in SharePoint Server 2019 Verify that the upgrade for your databases has succeeded and
that you are ready to begin to upgrade sites.
Create the SharePoint Server 2019 farm for a
database attach upgrade

When you upgrade from SharePoint Server 2016 to SharePoint Server 2019, you must use a database attach
upgrade, which means that you upgrade only the content for your environment and not the configuration settings.
Before you can upgrade the content, you must configure a new server or server farm by using SharePoint Server
2019. This article lists the items that you have to configure when you create that new environment.
Phase 1 of the upgrade process: Create SharePoint Server 2019 farm
This is the first phase in the process to upgrade SharePoint

Server 2016 data and sites to SharePoint Server 2019. The
process includes the following phases that must be completed
in order:
Create the SharePoint Server 2019 farm for a database attach

upgrade (this phase).
Copy databases to the new farm for upgrade to SharePoint

Server 2019.
Upgrade service applications to SharePoint Server 2019.
Upgrade content databases to SharePoint Server 2019.
For an overview of the whole process, see Overview of the

upgrade process to SharePoint Server 2019.
Before you begin

Before you create the SharePoint Server 2019 farm, review the following information and take any recommended
actions.
Make sure that the hardware and software that you are using meets the requirements in Hardware and
Make sure that you have appropriately planned your logical and physical architecture to support the
features and functionality that you want in the SharePoint Server 2016 farm.
Make sure that you have planned for sufficient performance and capacity for the SharePoint Server 2016
farm.
Collect information and settings

IMPORTANT
The section explains how to configure service applications, except for the Business Data Connectivity service application
which applies to SharePoint Server 2019.
Before you start to upgrade, you must collect information and settings about your existing environment. You have
to know what is in your SharePoint Server 2016 environment before you can start to build your SharePoint
Server 2019 environment. Gather information such as the following:
Alternate access mappings
Authentication providers and authentication modes that are being used
Quota templates
Managed paths
Self-service site management settings
Incoming and outgoing e-mail settings
Customizations
You also have to turn off or remove services or components in the SharePoint Server 2016 environment that
could cause errors in the upgrade process. The following services or components should be removed or stopped
before you back up your databases:
PowerPoint Broadcast Sites Office Online Server has changed into a separate server product which can
serve multiple SharePoint farms for viewing and editing documents. Because of this change, PowerPoint
Broadcast sites cannot be upgraded to SharePoint Server 2019.
Record the passphrase for the Secure Store service application

The Secure Store service application uses a passphrase to encrypt information. You have to know what this
passphrase is so that you can use it in the new environment. Otherwise, you will not have access to the
information in the Secure Store. If you do not know the passphrase, you can refresh the key, and then back up the
Secure Store database. For more information, see Work with encryption keys in Configure the Secure Store
Service in SharePoint Server .
Install SharePoint Server 2019 in a new environment

Before you can upgrade your databases, you must use SharePoint Server 2019 to configure a new server or
server farm. The first step in creating your new environment is to install SharePoint Server 2019 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 all language packs that you want in your environment.
NOTE
For more information about how to install available language packs, see Install or uninstall language packs for
4. Run the SharePoint Products Configuration Wizard to configure your server or servers.
IMPORTANT
Some service applications can be upgraded by using a service application database upgrade. If you want to upgrade
these service applications by upgrading the service application databases, do not use the Farm Configuration Wizard
to configure these service applications when you set up your new farm.
For step-by-step instructions for these tasks, see Install SharePoint Server 2019.
Configure service applications

You must create the service applications on your new farm before you upgrade your content databases. There are
some service applications that can be upgraded from SharePoint Server 2016 to SharePoint Server 2019. The
steps in Install SharePoint Server 2019 describe how to use the Farm Configuration Wizard to enable all service
applications. However, you should not use the Farm Configuration Wizard to enable the service applications that
you want to upgrade.
Search
For an overview of how to upgrade these service applications, see Services upgrade overview for SharePoint
Server. For the specific steps to upgrade these service application databases see Upgrade service applications to
SharePoint Server.
Configure farm settings

The next step in creating the new environment is to apply general farm settings. You must manually reapply
configuration settings from your SharePoint Server 2016 farm, such as the following:
All farm-level security and permission settings, such as adding user or group accounts to the Farm
Blocked file types
And you must configure all new farm-level settings that you want to use, such as the following:
Usage and health data collection
Diagnostic logging
Settings and schedules for timer jobs
IMPORTANT
If you had disabled the Workflow Auto Cleanup timer job in your SharePoint Server 2016 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
SharePoint Server 2016 environment, you might lose workflow associations when you upgrade. .
In a standard installation, the next step would be to create web applications. However, for upgrade, you create web
applications later in the process, after you upgrade the service application databases. For more information, see
Create web applications.

Server 2016 data and sites to SharePoint Server 2019.
Next phase: Copy databases to the new farm for upgrade to
Copy databases to the new farm for upgrade to

upgrade, which means that you upgrade only the content for your environment and not the configuration settings.
After you have configured a new SharePoint Server 2019 environment, you can copy the content and service
application databases from the SharePoint Server 2016 environment to the SharePoint Server 2019 environment.
You use a backup and restore process to copy the database, and you can also choose to set the databases to read-
only in the SharePoint Server 2016 environment so that users can continue to access their information, but not
change it. This article contains the steps that you take to copy the databases.
Phase 2 of the upgrade process: Copy databases to the new farm
This is the second phase in the process to upgrade SharePoint

in order:

upgrade
Server 2019 (this phase)
Upgrade content databases to SharePoint Server 2019.

Before you begin

Before you copy the databases, review the following information and take any recommended actions.
Make sure that the account that you use to copy the databases has access to SQL Server Management
Studio on both the SharePoint Server 2016 and SharePoint Server 2019 environments and has access to a
network location that can be accessed from both environments to store the copies of the databases.
Make sure that the account that you use to set the databases to read-only and read-write is a member of
the db_owner fixed database role for the content databases that you want to upgrade.
Before you back up the databases, check for and repair all database consistency errors.
Set the earlier version databases to be read-only

To maintain user access to your original environment, set the SharePoint Server 2016 databases to read-only
before you back up the databases. Even if you don't want to maintain access over the long term, set the databases
to read-only to make sure that you capture all the data in the backup so that you restore and upgrade the current
state of the environment without allowing additional changes to be made. If the databases are set to read-only,
users can continue to view content. However, they will be unable to add or change content.
NOTE
Don't set search databases to read-only at this point. It's best not to interrupt the search experience until you're ready to
upgrade the Search service applications. You will handle these databases when you upgrade service applications (the fourth
phase in the process to upgrade SharePoint Server 2016 data and sites to SharePoint Server 2019).
IMPORTANT
Perform this step in the SharePoint Server 2016 environment.
To set a database to read-only by using SQL Server tools

1. Verify that the user account that is performing this procedure is a member of the db_owner fixed database
role for the databases.
2. In SQL Server Management Studio, in Object Explorer, connect to an instance of the Database Engine,
expand the server, and then expand Databases.
3. Find the database that you want to configure to be read-only, right-click the database, and then click
Properties.
4. In the Database Properties dialog box, in the Select a page section, click Options.
5. In the details pane, under Other options, in the State section, next to Database Read-Only, click the
arrow, and then select True.
You can use Transact-SQL to configure the READ_ONLY database availability option. For more information
about how to use the SET clause of the ALTER DATABASE statement, see Setting Database Options.
Back up the SharePoint Server 2016 databases by using SQL Server

tools
You back up the databases in SQL Server Management Studio. A backup copy of the database guarantees that
you have the data in a safe state if you must enable the original farm again and is required for a database-attach
upgrade. Repeat the procedure for the following databases in the SharePoint Server 2016 server farm:
All content databases (default database name: WSS_Content_ ID
The following service application databases:
Business Data Connectivity BDC_Service_DB_ ID
Managed Metadata Managed Metadata Service_ ID
PerformancePoint PerformancePoint Service Application_ ID
Secure Store Secure_Store_Service_DB_ ID
You do not have to back up the configuration or admin content databases, because you recreated these databases
when you set up the SharePoint Server 2019 server farm. Upgrading the configuration or admin content
databases and the Central Administration site collection is not supported.
After you complete this procedure, you will have created backups of the read-only content databases.
IMPORTANT
To back up a database by using SQL Server tools

2. In Management Studio, in Object Explorer, connect to an instance of the Database Engine, expand the
server, and then expand Databases.
3. 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.
4. In the Source area, in the Database box, verify the database name.
5. In the Backup type box, select Full.
6. Under Backup component, select Database.
7. In the Backup set area, in the Name box, either accept the backup set name that is suggested or type a
different name for the backup set.
8. 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.
9. Click OK to start the backup process.
Repeat the previous procedure to back up all the content and appropriate service application databases that
SharePoint Server 2019 uses in your environment.
Copy the backup files to the SharePoint Server 2019 environment

Copy the backup files that you created in the previous procedure from the SharePoint Server 2016 environment
to the SharePoint Server 2019 environment.
Restore a backup copy of the database

After you configure the new SharePoint Server 2019 server farm, you can restore the backup copies of the
databases to SQL Server. Start with one database, and then verify that the restoration has worked before you
restore the other databases.
IMPORTANT
Be sure to keep a copy of your original backups in reserve, just in case upgrade fails and you have to troubleshoot and try
again. > Perform this step in the SharePoint Server 2016 environment.
To restore a backup copy of a database by using SQL Server tools

2. After you connect to the appropriate instance of the SQL Server 2014 Database Engine, in Object Explorer,
expand the server name.
3. Right-click Databases, and then click Restore Database.
The Restore Database dialog box appears.
4. In the Restore Database dialog box, on the General page, type the name of the database to be restored in
the To database list.
TIP
When you type the name for the restored database, you do not have to use the original name. If you want to
change the database name from a name with a long GUID to a shorter, friendlier name, this is an opportunity to
make that change. Be sure to also change the database and log file names in the file system (the MDF and LDF files)
so that they match.
5. In the To a point in time text box, keep the default (Most recent possible).
6. To specify the source and location of the backup sets to restore, click From device, and then use the ellipsis
( ...) to select the backup file.
7. In the Specify Backup dialog box, in the Backup media box, be sure that File is selected.
8. In the Backup location area, click Add.
9. 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.
10. 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.
11. In the Restore Database dialog box, on the Options page, under Restore options, select the Overwrite
the existing database check box.
12. Click OK to start the restore process.
Set the databases to read-write

You cannot upgrade a database that is set to read-only. You must set the databases back to read-write on your
SharePoint Server 2019 farm before you attach and upgrade them.
IMPORTANT
To set a database to read-write by using SQL Server tools

2. Select the database that you want to configure to be read-write, right-click the database, and then click
Properties.
arrow, and then select False.
This is the second phase in the process to upgrade SharePoint

Next phase: Upgrade service applications to SharePoint Server
2016
See also
Concepts
Upgrade service applications to SharePoint Server
2019

upgrade, which means that you upgrade only the content for your environment and not the configuration
settings. After you have configured the SharePoint Server 2019 environment, and copied the content and service
application databases, you can upgrade the service applications to SharePoint Server 2019. This article contains
the steps that you take to upgrade the service applications.
Phase 3 of the upgrade process: Upgrade service applications
This is the third phase in the process to upgrade SharePoint

process includes the following phases that must be
completed in order:
upgrade
Server 2019
Upgrade service applications to SharePoint Server 2019 (this
phase)

Before you begin

Before you upgrade the service applications, review the following information and take any recommended
actions.
Make sure that the account that you use to perform the steps in this article is a member of the Farm
administrators group in the Central Administration web site.
Decide which service application pool to use for the upgraded service applications. The procedures below
use the default application pool for service applications which is "SharePoint Web Services Default". You
can view a list of available service application pools by using the Get-SPServiceApplicationPool cmdlet
in PowerShell. Or you can create a service application pool by using the New-
SPServiceApplicationPool cmdlet. For more information, see Get-SPServiceApplicationPool and New -
SPServiceApplicationPool.
TIP
Throughout this article, variables (such as $applicationPool, $sss, $upa, and so on) are used in the PowerShell cmdlets to
save time and effort. You do not have to use these variables if you would prefer not to. However, if you do not use these
variables, you must use IDs for the service applications and service application proxies when you specify the Identity
parameters. Each procedure has information about the variables used, or the alternate cmdlets to use to look up any IDs
that are required. > Also, many procedures in this article include a step to set the $applicationPool variable. If you are
performing all of these procedures in the same session of PowerShell, and you want to use the same application pool for all
service applications, you do not have to repeat this step in each procedure. Instead, you can set this variable once at the
beginning and use it throughout the procedures in this article.
About upgrading the service application databases

To upgrade a service application database, you create a new service application and provide the name of the
existing database to use for the new service application. As the service application is created, the database is
upgraded. This process has several steps.
NOTE
Word Automation Services and Machine Translation Services can't be upgraded. A new service instance will need to be
created.
IMPORTANT
The following steps only apply to the Custom server role type. For more information on server role types, see Planning for
a MinRole server deployment in SharePoint Server 2016 and SharePoint Server 2019
1. Start the service instances

The first step is to start service instances for the five service applications that you can upgrade: the
Business Data Connectivity service, Managed Metadata Web Service, PerformancePoint Services service,
Secure Store service, and Search service. Most of these service instances can be started from Central
Administration. However the SharePoint Server Search service instance must be started by using
PowerShell.
2. Create the service applications and upgrade the databases
After you have started the service instances, the next step is to create the service applications and upgrade
the databases. You must use PowerShell to restore the service application databases.
3. Create proxies for the service applications
After you have upgraded the service application databases, you create the proxies for the service
applications and add them to the default proxy group. You must create proxies for the following service
applications:
Secure Store service application
The Business Data Connectivity service application automatically creates a proxy and assigns it to the
default proxy group when you create the service application.
4. Verify that the proxies are in the default group
The following sections provide procedures to complete these steps.
Start the service instances

The following procedures start the service instances.
To start service application instances from Central Administration
2. In SharePoint 2019 Central Administration, on the Application Management page, in the Service
Applications section, click Manage Services on Server.
3. Next to the Business Data Connectivity service, click Start.
4. Next to the Managed Metadata Web Service, click Start.
5. Next to the PerformancePoint Services service, click Start.
6. Next to the Secure Store Service, click Start.
The Search service instance must be started by using PowerShell because you cannot start it from Central
Administration unless a Search Service application already exists.
TIP
When using MinRoles, Start may not be available as it is managed by the farm. When the associated Service Application
has been created, it automatically starts the Service Instance.
To start the Search service instance by using PowerShell

2019 cmdlets.
NOTE
2. Start the SharePoint 2019 Management Shell.

3. To start the Search service instance, at the Microsoft PowerShell command prompt, type the following
commands and press ENTER after each one:
$SearchInst = Get-SPEnterpriseSearchServiceInstance
# Stores the identity for the Search service instance on this server as a variable
Start-SPServiceInstance $SearchInst
# Starts the service instance
For more information, see Get-SPEnterpriseSearchServiceInstance and Start-SPServiceInstance.
Upgrade the Secure Store service application

To upgrade the Secure Store service application, you create the new service application and upgrade the
database, create a proxy and add it to the default proxy group, and then restore the passphrase from the previous
environment.
To upgrade the Secure Store service application by using PowerShell
cmdlets.
NOTE

3. To store the application pool that you want to use as a variable for this service application, at the Microsoft
PowerShell command prompt, type the following command:
$applicationPool = Get-SPServiceApplicationPool -Identity 'SharePoint Web Services default'
Where:
SharePoint Web Services default is the name of the service application pool that will contain the new service
applications. This is the default service application pool. You can specify a different service application pool.
This cmdlet sets the service application pool as a variable that you can use again in the cmdlets that follow. If you
have multiple application pools and have to use a different application pool for a particular service application,
repeat this step in the procedure to create each service application to use the appropriate application pool.
4. To upgrade the Secure Store service application, at the PowerShell command prompt, type the following
command:
$sss = New-SPSecureStoreServiceApplication -Name 'Secure Store' -ApplicationPool $applicationPool -
DatabaseName 'SecureStore_Upgrade_DB' -AuditingEnabled
Where:
SecureStore is the name that you want to give the new Secure Store service application.
$applicationpool is the variable that you set earlier to identify the service application pool to use.
TIP
If you do not use the variable $applicationPool, then you must specify the name of an existing service application
pool in the format ' Application Pool Name'. To view a list of service application pools, you can run the Get-
SPServiceApplicationPool cmdlet.
SecureStore_Upgrade_DB is the name of the service application database that you want to upgrade.
This command sets a variable, $sss, that you use when you create the proxy later.
For more information, see New -SPSecureStoreApplication.
5. Type the following command to create a proxy for the Secure Store service application:
$sssp = New-SPSecureStoreServiceApplicationProxy -Name ProxyName -ServiceApplication $sss -DefaultProxyGroup
Where:
ProxyName is the proxy name that you want to use.
$sss is the variable that you set earlier to identify the new Secure Store service application.
TIP
If you do not use the variable $sss, then you must use an ID to identify the Secure Store service application instead
of a name. To find the ID, you can run the Get-SPServiceApplication cmdlet to return a list of all service
application IDs.
DefaultProxyGroup adds the Secure Store service application proxy to the default proxy group for the
local farm.
This command sets a variable, $sssp, for the service application proxy that you use when you restore the
passphrase.
For more information, see New -SPSecureStoreServiceApplicationProxy.
After you create the Secure Store service application and the proxy, you have to refresh the encryption key. For
information about how to refresh the encryption key, see Refresh the Secure Store encryption key.
6. Type the following command to restore the passphrase for the Secure Store service application:
Update-SPSecureStoreApplicationServerKey -Passphrase <Passphrase> -ServiceApplicationProxy $sssp
Where:
<Passphrase> is the Passphrase for the Secure Store service application from your previous environment.
$sssp is a variable that you set earlier to identify the new Secure Store service application proxy.
TIP
If you do not use the variable $sssp, then you must use an ID to identify the Secure Store service application proxy
instead of a name. To find the ID, you can run the Get-SPServiceApplicationProxy cmdlet to return a list of all
service application proxy IDs.
For more information, see Update-SPSecureStoreApplicationServerKey.
Upgrade the Business Data Connectivity service application

To upgrade the Business Data Connectivity service application, you create the new service application and
upgrade the database. You do not have to create a proxy for the Business Data Connectivity service application.
The Business Data Connectivity service application automatically creates a proxy and assigns it to the default
proxy group when you create the service application.
To upgrade the Business Data Connectivity service application by using PowerShell
2016 cmdlets.
NOTE

Where:
applications.
4. To upgrade the Business Data Connectivity service application, at the Microsoft PowerShell command prompt,
type the following command:
New-SPBusinessDataCatalogServiceApplication -Name 'BDC Service' -ApplicationPool $applicationPool -
DatabaseName 'BDC_Service_DB'
Where:
BDC Service is the name that you want to give the new Business Data Connectivity service application.
TIP
BDC_Service_DB is name of the service application database that you want to upgrade.
For more information, see New -SPBusinessDataCatalogServiceApplication.
Upgrade the Managed Metadata service application

To upgrade the Managed Metadata service application, you create the new service application and upgrade the
database, and then create a proxy and add it to the default proxy group.
To upgrade the Managed Metadata service application by using PowerShell
2016 cmdlets.
NOTE

3. To store the application pool that you want to use as a variable for this service application, at the
Where:
applications.
4. To upgrade the Managed Metadata service application, at the PowerShell command prompt, type the
following command:
$mms = New-SPMetadataServiceApplication -Name 'Managed Metadata Service Application' -ApplicationPool

$applicationPool -DatabaseName 'Managed Metadata Service_DB'
Where:
Managed Metadata Service Application is the name that you want to give the new Managed Metadata
TIP
Managed Metadata Service_DB is name of the service application database that you want to upgrade.
This command sets a variable, $mms, that you use when you create the proxy later.
For more information, see New -SPMetadataServiceApplication.
5. At the PowerShell command prompt, type the following command to create a proxy for the Managed
Metadata service application:
New-SPMetadataServiceApplicationProxy -Name ProxyName -ServiceApplication $mms -DefaultProxyGroup
Where:
$mms is the variable that you set earlier to identify the new Managed Metadata service application.
TIP
If you do not use the variable $mms, then you must use an ID to identify the Managed Metadata service
application proxy instead of a name. To find the ID, you can run the Get-SPServiceApplication cmdlet to return a
list of all service application IDs.
DefaultProxyGroup adds the Managed Metadata service application proxy to the default proxy group for
the local farm.
For more information, see New -SPMetadataServiceApplicationProxy.
Upgrade the PerformancePoint Services service application

To upgrade the PerformancePoint Services service application, you create the new service application and
upgrade the database, and then create a proxy and add it to the default proxy group.
To upgrade the PerformancePoint Services service application by using PowerShell
2016 cmdlets.
NOTE

Where:
applications.
4. To upgrade the PerformancePoint Services service application, at the PowerShell command prompt, type the
following command:
$pps = New-SPPerformancePointServiceApplication -Name 'PerformancePoint Service' -ApplicationPool

$applicationPool -DatabaseName 'PerformancePoint Service Application_DB'
Where:
PerformancePoint Service is the name that you want to give the new PerformancePoint Services service
application.
TIP
PerformancePoint Service Application_DB is name of the PerformancePoint Services service application

database that you want to upgrade.
This command sets a variable, $pps, that you use when you create the proxy later.
For more information, see New -SPProfileServiceApplication.
5. Type the following command to create a proxy for the PerformancePoint Services service application:
New-SPPerformancePointServiceApplicationProxy -Name ProxyName -ServiceApplication $pps -Default
Where:
$pps is the variable that you set earlier to identify the new PerformancePoint Services service application.
TIP
If you do not use the variable $pps, then you must use an ID to identify the PerformancePoint Services service
application instead of a name. To find the ID, you can run the Get-SPServiceApplication cmdlet to return a list of
all service application IDs.
Default adds the PerformancePoint Services service application proxy to the default proxy group for the
local farm.
For more information, see New -SPPerformancePointServiceApplicationProxy.
Upgrade the User Profile service application

Upgrade the Managed Metadata service application before you upgrade the User Profile service application.
To upgrade the User Profile service application, you copy the Profile and Social databases in your SharePoint
Server 2016 farm to your SharePoint Server 2019 farm and create a new User Profile service application from
your SharePoint Server 2016 farm in your SharePoint Server 2019 farm. The restore triggers SharePoint Server
2019 to create a new User Profile service application in the SharePoint Server 2019 farm and point it to the
copied User Profile databases. To complete the upgrade of the User Profile service application, you create a proxy
and add it to the default proxy group.
To upgrade the User Profile service application by using PowerShell
1. Copy the Profile and Social databases in the SharePoint Server 2016 farm to the SharePoint Server 2019
farm by following these steps:
IMPORTANT
Perform these steps in the SharePoint Server 2016 environment.

An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint
Server 2016 cmdlets.
NOTE
Start the SharePoint Management Shell.

Set the User Profile databases to read-only. In the second phase of the process to upgrade
SharePoint Server 2016 data and sites to SharePoint Server 2019, you set all the other databases to
read-only.
Copy the Profile and Social databases in the SharePoint Server 2016 farm to the SharePoint Server
2019 farm, follow the procedures in Copy databases to the new farm for upgrade to SharePoint
Server 2019.
IMPORTANT
Perform the next steps in the SharePoint Server 2019 environment.

2016 cmdlets.
NOTE

Where:
SharePoint Web Services default is the name of the service application pool that will contain the new
This cmdlet sets the service application pool as a variable that you can use again in the cmdlets that follow.
If you have multiple application pools and have to use a different application pool for a particular service
application, repeat this step in the procedure to create each service application to use the appropriate
application pool.
5. To restore the User Profile service application and upgrade the Profile and Social databases, at the
Microsoft PowerShell command prompt, type the following command:
New-SPProfileServiceApplication -Name '<UserProfileApplicationName>' -ApplicationPool $applicationPool
-ProfileDBName '<ProfileDBName>' -SocialDBName '<SocialDBName>' -ProfileSyncDBName '<SyncDBName>'
Where:
UserProfileApplicationName is the name of the User Profile service application.
$applicationpool is the variable that you set to identify the service application pool to use.
Note: If you do not use the variable $applicationPool, then you must specify the name of an
existing service application pool in the format 'Application Pool Name'. To view a list of service
application pools, you can run the Get-SPServiceApplicationPool cmdlet.
ProfileDBName is the name of the Profile database that you want to upgrade.
SocialDBName is the name of the Social database that you want to upgrade.
SyncDBName is the name of the new Synchronization database.
6. Create the User Profile service application proxy and add it to the default proxy group by completing these
actions:
Type the following command to get the ID for the Search service application and store it as a
variable:
$sa = Get-SPServiceApplication | ?{$_.TypeName -eq 'User Profile Service Application'}
For more information, see Get-SPServiceApplication.

Type the following command to create a proxy for the Search service application:
New-SPProfileServiceApplicationProxy -Name ProxyName -ServiceApplication $sa
Where:
$sa is the variable that you set earlier to identify the new User Profile service application.
Tip: If you do not use the variable $sa, then you must use an ID to identify the User Profile
service application instead of a name. To find the ID, you can run the Get-
SPServiceApplication cmdlet to return a list of all service application IDs.
For more information, see New -SPProfileServiceApplicationProxy.
Type the following command to get the Search service application proxy ID for the proxy you just
created and set it as the variable $ssap:
$proxy = Get-SPServiceApplicationProxy | ?{$_.TypeName -eq 'User Profile Service Application

Proxy'}
For more information, see Get-SPServiceApplicationProxy.

Type the following command to add the User Profile service application proxy to the default proxy
group:
Add-SPServiceApplicationProxyGroupMember -member $proxy -identity ""
Where:
$proxy is the variable that you set earlier to identify the ID for the proxy you just created for
the User Profile service application.
Tip: If you do not use the variable $proxy, then you must use an ID to identify the User
Profile service application proxy instead of a name. To find the ID, you can run the Get-
SPServiceApplicationProxy cmdlet to return a list of all service application proxy IDs.
You use an empty Identity parameter ("") to add it to the default group.
For more information, see Add-SPServiceApplicationProxyGroupMember.
Upgrade the Search service application

Upgrade the User Profile service application and the Managed Metadata service application before you upgrade
the Search service application.
To upgrade the Search service application, you copy the search administration database in your SharePoint
Server 2016 farm to your SharePoint Server 2019 farm and restore the Search service application from your
SharePoint Server 2016 farm in your SharePoint Server 2019 farm. The restore triggers SharePoint Server 2019
to create a new Search service application in the SharePoint Server 2019 farm and point it to the copied search
administration database. To complete the upgrade of the Search service application you create a proxy and add it
to the default proxy group and you ensure that the new Links Database and the new search topology is
configured the same way as in the SharePoint Server 2016 farm.
SharePoint Server 2019 normally creates a new search topology with all the search components and databases
when it creates a new Search service application. During a restore of a Search service application, SharePoint
Server 2019 creates a new search topology, but upgrades the restored Search Administration database instead of
creating a new Search Administration database. The upgraded Search Administration database retains any
additions or modifications made to the search schema, result sources and query rules from the SharePoint Server
2016 farm.
NOTE
During this upgrade, search doesn't crawl content in your SharePoint Server 2016. If freshness of search results is
important, save time by familiarizing yourself with these steps before starting the upgrade.
IMPORTANT
Because the search topology in the SharePoint Server 2019 farm is new, the index is empty. You have to perform a full crawl
of the entire indexed corpus after you have upgraded all content sources (the fourth phase in the process to upgrade
SharePoint Server 2016 data and sites to SharePoint Server 2019).
To upgrade the Search service application by using PowerShell

1. Copy the search administration database in the SharePoint Server 2016 farm to the SharePoint Server
2019 farm, follow these steps:
NOTE
You copied all other content and service databases in your SharePoint Server 2016 environment in an earlier step of
the process for upgrading to SharePoint Server 2019. We recommend copying the Search Administration database
at this later stage because you have to pause the Search service application in your SharePoint Server 2016
environment while copying the Search Administration database.
IMPORTANT
Perform these steps in the SharePoint Server 2016 environment.

An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use
SharePoint Server 2019 cmdlets.
NOTE
If you do not have permissions, contact your Setup administrator or SQL Server administrator to
request permissions. For additional information about PowerShell permissions, see Add-
SPShellAdmin.
Start the SharePoint 2016 Management Shell.

Pause the Search service application. At the PowerShell command prompt, type the following
command:
$ssa = Get-SPEnterpriseSearchServiceApplication <SearchServiceApplicationName>

Suspend-SPEnterpriseSearchServiceApplication -Identity $ssa
Where:
SearchServiceApplicationName is the name of the Search service application you want to pause.
NOTE
While the Search service application is paused, the index in the SharePoint Server 2016 environment isn't
updated. This means that during the upgrade to SharePoint Server 2019, search results might be less fresh.
Set the Search Administration database to read-only. In the second phase of the process to upgrade
SharePoint Server 2016 data and sites to SharePoint Server 2019, you set all the other databases to
read-only. Follow the same instructions now for the Search Administration database.
Copy the search administration database in the SharePoint Server 2016 farm to the SharePoint
Server 2019 farm, follow the procedures in Copy databases to the new farm for upgrade to
SharePoint Server 2019 for the search administration database only.
IMPORTANT

2019 cmdlets.
NOTE

4. To store the application pool that you want to use as a variable for this service application, at the
Where:
application pool.
5. To restore the Search service application and upgrade the Search Administration database, at the
$searchInst = Get-SPEnterpriseSearchServiceInstance -local

# Gets the Search service instance and sets a variable to use in the next command
Restore-SPEnterpriseSearchServiceApplication -Name '<SearchServiceApplicationName>' -applicationpool
$applicationPool -databasename '<SearchServiceApplicationDBName>' -databaseserver <ServerName> -
AdminSearchServiceInstance $searchInst
Where:
SearchServiceApplicationName is the name of the Search service application.
Note: If you do not use the variable $applicationPool, then you must specify the name of an
existing service application pool in the format ' Application Pool Name'. To view a list of service
application pools, you can run the Get-SPServiceApplicationPool cmdlet.
SearchServiceApplicationDBName is the name of the search administration database that you want
to upgrade, and that this Search service application shall use.
$searchInst is the variable that you set to identify the new Search Service application instance.
Note: A Search service application upgrade might fail, for example due to network or SQL Server latency.
If an error message appears during the upgrade, do the following:
Delete the Search Administration database that you were trying to upgrade.
Using the backup copy that you made of the Search Administration database, repeat the following
procedures in this article for the Search service application only:
Type the command to upgrade the Search service application again at the PowerShell command
prompt.
For more information, see Restore-SPEnterpriseSearchServiceApplication.
6. Create the Search service application proxy and add it to the default proxy group by completing these
actions:
variable:
$ssa = Get-SPEnterpriseSearchServiceApplication
For more information, see Get-SPEnterpriseSearchServiceApplication.

New-SPEnterpriseSearchServiceApplicationProxy -Name ProxyName -SearchApplication $ssa
Where:
$ssa is the variable that you set earlier to identify the new Search service application.
Tip: If you do not use the variable $ssa, then you must use an ID to identify the Search
For more information, see New -SPEnterpriseSearchServiceApplicationProxy.
$ssap = Get-SPEnterpriseSearchServiceApplicationProxy
For more information, see Get-SPEnterpriseSearchServiceApplicationProxy.

Type the following command to add the Search service application proxy to the default proxy
group:
Add-SPServiceApplicationProxyGroupMember -member $ssap -identity ""

Where:
$ssap is the variable that you set earlier to identify the ID for the proxy you just created for
Tip: If you do not use the variable $ssap, then you must use an ID to identify the Search
service application proxy instead of a name. To find the ID, you can run the Get-
7. If the SharePoint Server 2016 farm uses a Links Database that is partitioned, partition the Links Database
in the SharePoint Server 2019 farm the same way. Learn how in Move-
SPEnterpriseSearchLinksDatabases.
8. (Optional) Preserve search relevance settings from the SharePoint Server 2016 farm. Because the
upgraded Search service application has a new, empty index, search analytics data from the SharePoint
Server 2016 farm cannot be fully retained. Copy the Analytics Reporting database from the SharePoint
Server 2016 farm and attach it to the new Search service application in the SharePoint Server 2019 farm:
In the SharePoint Server 2016 farm, backup the Analytics Reporting database.
In the SharePoint Server 2019 farm, restore the backed up database to the new database server.
In the SharePoint Server 2019 farm, attach the restored database to the new Search service
application.
9. Verify that the search topology on the new SharePoint Server 2019 farm is alike that of the SharePoint
Server 2016 farm. If your requirements for search have changed, now is a good time to scale out the
search topology of the new SharePoint Server 2019 farm.
10. Resume the Search service application in the SharePoint Server environment.
At the PowerShell command prompt, type the following command:

$ssa.ForceResume(0x02)
Where:
SearchServiceApplicationName is the name of the Search service application you want to resume.
Verify that all of the new proxies are in the default proxy group
Use the following procedure to verify that the steps to create the proxies and add them to the default proxy group
worked.
To verify that all of the new proxies are in the default proxy group by using PowerShell
2016 cmdlets.
Note: If you do not have permissions, contact your Setup administrator or SQL Server administrator to
request permissions. For additional information about PowerShell permissions, see Add-SPShellAdmin.
3. At the PowerShell command prompt, type the following commands:
$pg = Get-SPServiceApplicationProxyGroup -Identity ""

$pg.Proxies
Where:
$pg is a variable you set to represent the default proxy group.
You use an empty Identity parameter ("") to specify the default proxy group.
This returns a list of all proxies in the default proxy group, their display names, type names, and IDs.
For more information, see Get-SPServiceApplicationProxyGroup.
Now that the service applications are upgraded, you can start the process to upgrade the content databases. The
first step in that process is to create the web applications that are needed for each content database.

Next phase: Upgrade content databases to SharePoint Server 2019
See also
Concepts
Services upgrade overview for SharePoint Server 2019
Upgrade content databases to SharePoint Server
2019

settings. After you have configured the SharePoint Server 2016 environment, copied the content and service
application databases, and upgraded the service applications, you can attach and upgrade the content databases
to SharePoint Server 2019. This article explains the steps you take to attach and upgrade the content databases
to SharePoint Server 2019.
Phase 4 of the upgrade process: Upgrade content databases
This is the fourth phase in the process to upgrade SharePoint

completed in order:
Create the SharePoint Server 2019 farm for a database
attach upgrade
Server 2019
Upgrade content databases to SharePoint Server 2019 (this
phase)

Before you begin

administrators group in Central Administration.
Create web applications

Create a web application for each web application that existed in the SharePoint Server 2016 environment. For
each web application, do the following:
Use the same URL (including name, port, and host header) and configure alternate-access mapping
settings.
If you use a different URL, Office applications might not be redirected correctly to the new URLs and all
bookmarks to the old URLs will not work.
Use the same authentication method.
Because claims-based authentication is now the default option for SharePoint Server 2019, you must use
Microsoft PowerShell to create a web application that uses Windows Classic authentication. .
Recreate managed paths.
Recreate quota templates.
Configure email settings for the web application.
Enable self-service site creation for any web application that used it in the previous environment. Recreate
any self-service site creation settings.
Create the managed path for the My Sites (/personal) on the web application that hosts My Sites. My
Sites are available in SharePoint Server only.
Recreate any web application policies or other web application settings that you had configured in the
previous environment.
Reapply customizations
One frequent cause of failures during upgrade is that the new environment does not have customized features,
solutions, or other elements. Make sure that all custom elements from the SharePoint Server 2016 environment
are installed on your front-end web servers before you upgrade any content databases.
In this step, you manually transfer all customizations to your new farm. Make sure to install any components that
your sites depend on to work correctly, such as the following:
Custom site definitions
Custom style sheets, such as 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 all unique settings from the Web.config files for each web application to the new
servers.
Administrator-approved form templates (.xsn files) and data connection files (.udcx files) for InfoPath.
Any other components or files on which your sites depend.
The installation for SharePoint Server 2019 continues to use 16 as its major version number including in the file
system paths.
Verify custom components

To make sure that you have identified all custom components for your environment, use the Stsadm -o
enumallwebs operation in the SharePoint Server 2016 environment and use the includefeatures and
includewebparts parameters. This operation can report the templates, features, Web Parts, and other custom
elements that are used for each site. For more information about how to use the enumallwebs operation, see
Enumallwebs: Stsadm operation (Office SharePoint Server).
You can also use the Get-SPWeb cmdlet in your SharePoint Server 2016 environment to see template that are
associated with each site and then verify that the template is installed in your SharePoint Server 2019
environment. For more information about this operation, see Get-SPWeb.
Before you attach the content databases to the web applications, use the Test-SPContentDatabase cmdlet to
verify that you have all the custom components that you must have for that database.
To verify custom components are available by using PowerShell
2016 cmdlets.
NOTE

Test-SPContentDatabase -Name DatabaseName -WebApplication URL
Where:
DatabaseName is the name of the database that 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 and upgrade the

database
When you attach a content database, you upgrade the database and add the site collections in that database to
the web application that you specify. After the databases are upgraded, the site collection upgrade process is
automatically started by default.
When you attach a content database, for a web application that spans multiple content databases, make sure that
you attach the content database that contains the root site collection first. In other words, before you continue,
examine the root of the web application in the SharePoint Server 2016 server farm to determine the first site
collection. After you attach the database that contains the root site, 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 attaches the content databases and the site collections inside that database. Make sure
that you do not add new site collections until you have restored all the content databases.
TIP
Each site collection in a content database has a GUID that is registered in the configuration database and associated with
the site collection. Therefore, you cannot add the same site collection two times to the farm, even in separate web
applications. Although you can successfully attach the database in this situation, you will be unable to browse to the site
collection. > If you must have a 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 Backup-SPSite and Restore-SPSite PowerShell cmdlets to copy the site
collection to the other farm. The backup and restore process creates a new GUID for the site collection. For more
information about these cmdlets, see Backup-SPSite and Restore-SPSite.
For My Sites, attach the content database that contains the My Site host before attaching databases that contain
the My Sites.
By default, when you created the web applications in the new SharePoint Server 2019 environment, a content
database was created for each web application. You can ignore these default databases until after you have
attached your SharePoint Server 2016 databases, and then you can delete the default databases.
IMPORTANT
If you are moving the content databases across domains or forests or to another environment that has different service
accounts, make sure that the permissions for the service accounts are still correct before you attach the databases.
NOTE
One frequent cause of failures during upgrade is that the environment is missing customized features, solutions, or other
elements. Be sure that all custom elements from the SharePoint Server 2016 environment are installed on your servers in
the SharePoint Server 2019 environment before you start the upgrade process. Use the Test-SPContentDatabase cmdlet
to identify custom elements that your sites might be missing.
To attach a content database to a web application by using PowerShell

1. You must use the Mount-SPContentDatabase cmdlet 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.
If you want to delay the sites upgrade, you can use the SkipSiteUpgrade parameter of the Mount-
SPContentDatabase cmdlet.
NOTE
Using the Mount-SPContentDatabase cmdlet to attach a content database is the recommended behavior and
option for upgrading databases and site collections in SharePoint Server 2016.
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.
2019 cmdlets.
NOTE

3. At the PowerShell command prompt, type the following command and then press ENTER:
Mount-SPContentDatabase -Name DatabaseName -DatabaseServer ServerName -WebApplication URL
Where:
DatabaseName is the name of the database that you want to upgrade.

ServerName is server on which the database is stored.
For more information, see Mount-SPContentDatabase. After the databases are upgraded, the site collections are
automatically upgraded. For additional information on how to upgrade a site collection, see Upgrade a site
collection to SharePoint Server 2019.
Verify upgrade for the first database

After you attach a database, you can use the Upgrade Status page in Central Administration to check the status
of upgrade on your databases. After the upgrade process is complete, you can review the upgrade log file to see
whether upgrade produced issues. You can use a PowerShell cmdlet to check the upgrade status for all the
content databases. For more information about verifying and troubleshooting upgrade, see Verify database
upgrades in SharePoint Server 2019.
To view the Upgrade Status page
Verify that the user account that is performing this procedure is a member of the db_owner fixed
database role for the databases.
In Central Administration, click Upgrade and Migration, and then click Check upgrade status.
To view the upgrade log file
The upgrade error log file and the upgrade log file are located at
%COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\16\LOGS. The upgrade log file
contains more detailed information than the upgrade error log. Be sure to check the summary at the
bottom of the log files for information about the overall status and a count of the warnings and errors in
the file.
The logs are text files named in the following format:
Upgrade-YYYYMMDD -HHMMSS -SSS -error.log
Upgrade-YYYYMMDD -HHMMSS -SSS.log
Where
YYYYMMDD is the date
HHMMSS -SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds)
An example for an upgrade error log is Upgrade-20120105-132126-374-error.log, and an example for an
upgrade log is Upgrade-20120105-132126-374.log.
NOTE
The format of the upgrade log for SharePoint Server 2016 is based on the same structure as ULS. > The upgrade
log file includes the name of the content database being upgraded.
To view upgrade status for all databases by using PowerShell

2019 cmdlets.
NOTE

Get-SPContentDatabase | ft Name, NeedsUpgradeIncludeChildren
This cmdlet returns a table-style list of databases in your farm and indicates whether the database needs an
upgrade to SharePoint Server 2019.
Attach the remaining databases
After you restore the first content database and verify success, you can continue to restore and upgrade other
databases. You can perform parallel database attach upgrades to upgrade more than one database at a time. Use
separate Microsoft PowerShell command prompt to run multiple upgrades. It is recommended that you separate
the start time for each new database upgrade session by several minutes to prevent issues with temporary locks
set for the web application during attachment. Otherwise you might receive an error on the upgrade session. The
wait time to clear temporary locks varies depending on the number of site collections, or the speed of the
database server hardware.
Verify upgrade for additional databases

After you upgrade all 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.
Next steps
After you upgrade the databases, you might want to perform additional steps to make sure that your farm is
ready for use. For example:
Migrate user accounts to claims authentication, if it is necessary.
By default, new web applications in SharePoint Server 2019 use claims authentication. If you were using
classic authentication in the previous environment, you must migrate the users to claims authentication.
Update links that are used in any upgraded InfoPath form templates.
For a database-attach upgrade, you exported and imported all InfoPath form templates in your
environment when you created the new environment. After upgrade, you can now update the links that
are used in those upgraded form templates to point to the correct URLs by using a Microsoft PowerShell
cmdlet.
InfoPath is available in SharePoint Server only.
Perform a full crawl
For more information, see Start, pause, resume, or stop a crawl in SharePoint Server.
Back up your farm
For more information, see Back up farms in SharePoint Server.

Verify database upgrades in SharePoint Server 2019

After you upgrade databases to SharePoint Server 2019, you must verify that the content was successfully
upgraded to the new version. You can verify the status of the database-attach upgrade (is it still in progress, or has
it been completed successfully or with errors or failures?) to see whether 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 important that you know whether the upgrade has completed and what issues
remain to be addressed.
Verify upgrade status for databases

You can use the following methods to verify upgrade:
Use the Upgrade Status page in Central Administration
This page lists all farm, service, or content database upgrades and their statuses. This includes a count of
errors or warnings.
Review the log files to look for errors or warnings
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 for database attach upgrade
To verify that upgrade has succeeded, you can review the following log and error files:
The upgrade log file and the upgrade error log file.
Review the upgrade log file and the upgrade error log file (generated when you run the upgrade). The
upgrade log file and the upgrade error log file are located at %COMMONPROGRAMFILES%\Microsoft
Shared\Web server extensions\16\LOGS. The logs are named in the following format: Upgrade-
YYYYMMDD -HHMMSS -SSS -<GUID>.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 in a shorter file and is named Upgrade- YYYYMMDD -HHMMSS -SSS -<GUID>-
error.log.
The format of the log files complies with the Unified Logging System (ULS ) conventions. 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 tries will be listed in the log file.
If you find blocking issues in the log file, you can resolve the issues and then restart upgrade to continue with the
process.
Check the upgrade status for databases
The Upgrade Status page lists the upgrade sessions and gives details about the status 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 view upgrade status in SharePoint Central Administration
To use SharePoint Central Administration, you must be a member of the Farm Administrators group.
2. On the Central Administration home page, in the Upgrade and Migration section, click Check upgrade
status.
Validate the upgraded environment

After you determine whether upgrade was completed successfully, validate your environment. Review the
following items:
Service applications
Are they configured correctly?
Are the service application proxies configured the way that you want?
Do you have to create new connections between farms?
Site collections
Are all features associated with the sites working?
Search
Check that the search configuration settings are alike those in the SharePoint Server 2019 farm.
Run search queries, and verify that the queries work as expected and provide appropriate results.
Twenty-four hours later, view the query reports and look for issues.
Search for people and profiles.
Check any Search customizations to make sure that they work as expected.
Upgrade a site collection to SharePoint Server 2019

In SharePoint Server 2019 the way site collection upgrades are performed has changed. After a server farm
administrator has upgraded the databases, site collections are automatically upgraded.
NOTE
There is no concept of "site collection compatibility modes" in SharePoint Server 2019. You must be running the latest
version at all times.

There are three ways to upgrade a site collection:
In conjunction with content databases upgrade
On-browse upgrade
Manually triggered by using PowerShell.
Content databases upgrade- To upgrade the databases run the Mount-SPContentDatabase cmdlet. After the
databases have been upgraded the site collections are automatically upgraded during database upgrade process
by default.
NOTE
This is the default behavior and recommended method to upgrade databases.
IMPORTANT
If you want to delay the sites upgrade, use the SkipSiteUpgrade parameter of the Mount-SPContentDatabase cmdlet. >
When the parameter is provided, the site collection is upgraded when first browsed.
On-browse upgrade - You do not need to know whether the site collection has pending upgrade, SharePoint
decides it for you during the upgrade process. Once the site is browsed, SharePoint checks if the site needs to be
upgraded, if so, the site will be put in a queue and a timer job will pick it up for upgrade.
Farm administrators can use PowerShell to upgrade a site collection.
Manually trigger site upgrade - You can use the Upgrade-SPSite cmdlet to manually upgrade the site
collections.
NOTE
This is a legacy option to upgrade a site collection.
This option is ideal for databases with large number of sites and for customers who use only a subset of all their
sites.
Verify that site collection upgrade has succeeded

Site collection administrators can view the Upgrade Status page in Site Settings to verify that upgrade has
succeeded for a site collection.
To view upgrade status in Site Settings
1. Verify that the user account that performs this procedure is a site collection administrator.
2. On the Site Settings page for the site collection, in the Site Collection Administration section, click
Site collection upgrade.
3. On the Site Collection Upgrade page, click Review Site Collection Upgrade Status.
The Upgrade Status page for the site collection is displayed.
Farm administrators can use PowerShell to view site collection upgrade status.
Review site collections upgraded to SharePoint Server 2019

After the site collections have been upgraded to SharePoint Server 2019, review your upgraded sites to fix any
issues after you have upgraded a site collection. Use the steps in this section to identify any issues before you
upgrade your production environment.
When you perform tests before upgrading your environment:
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.
To verify basic functionality, 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 do not render, 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
site collection upgrade log file to see whether you can get more information about the problem.
You can review the site collection upgrade logs from the following locations:
For site collection administrators: If site collections are upgraded by using the Mount-
SPContentDatabase cmdlet, there are no separate SiteUpgrade*.log files. The SiteUpgrade logs are inside
Upgrade*.log files.
NOTE
You can retrieve the log files by using PowerShell . > From a PowerShell command prompt type the following
syntax: Get-SPSiteUpgradeSessionInfo -Site <siteUrl> OR $site.UpgradeInfo
For farm administrators: The site collection upgrade log file and the upgrade error log file are located at
%COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\16\LOGS. The logs are named
in the following format: SiteUpgrade- 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). These
file system logs have more information if you want details about issues.
For additional information on how to troubleshoot error messages, see Troubleshoot site collection
upgrade issues in SharePoint Server 2019.
Use the following checklists to review your upgraded sites and look for issues for either trial upgrades or
upgrades in a production environment.
Checklists for reviewing upgraded sites

Large lists
By default, large list query throttling is turned on in SharePoint Server 2019. 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 administrator 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. For more information about large list throttling and how to address
issues with large lists, see Manage lists and libraries with many items.
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 resolved 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 Verify or fix the links to the cascading style sheet file. Verify
used in the appropriate locations? the link on the master page.
Theme choices are different in SharePoint 2019 - which Your site's home page, or other pages on your site, may look
theme do you want to use? different after the site is upgraded. You may have to re-create
or revise a theme and reapply it.
Do you have any JavaScript controls that are not working? Verify or fix the links to the controls.
Are your pages displayed correctly in the browser? 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.
See also
Concepts
My Sites are personal site collections that end users can use to store their documents, connect with other users,
and follow and discover content. Upgrading My Sites differs from upgrading other site collections because My
Sites consist of both the shared My Site Host site collection (also known as the My Site Host) and the My Site
personal site collection (also known as the personal site collection).
My Site Host. The My Site Host is a special site collection shared among all My Site users. The My Site
Host is used to show the profile (person.aspx) and newsfeed pages (default.aspx) on the My Site. The My
Site Host is also used for storing the user profile photos.
Personal site collection. In SharePoint Server 2019, the personal site collection is used to store a user's
documents. In SharePoint Server 2019, the personal site collection contains OneDrive for Business, followed
content, and so on.
Plan to upgrade My Sites

Before you start to upgrade from SharePoint Server 2016 to SharePoint Server 2019, you should carefully plan
your upgrade process. The following list discusses some considerations when planning a My Site upgrade.
Before upgrading the My Site Host and the personal site collections, you must upgrade the Managed
Metadata service application, and then the User Profile Service application. For more information, see
Some enterprises have multiple farms, that may include a services farm. In these environments, typically,
one server farm, known as the enterprise services farm, publishes cross-farm shared services, and the other
farms consume those shared services. In some cases, the User Profile Service application will be shared
from the services farm, while a separate farm that consumes the shared User Profile Service application
contains the My Sites. When you upgrade this type of configuration, you must upgrade the User Profile
Service application on the services farm first, before you upgrade the My Sites farm.
IMPORTANT
This list highlights some important things to consider when you perform an upgrade of My Sites. For a detailed discussion on
upgrades, see Get started with upgrades to SharePoint Server 2019
Upgrade My Sites
The following list summarizes some of the upgrade activities for a My Site upgrade only. For more information
about upgrades, see Upgrade to SharePoint Server 2019
IMPORTANT
Once you upgrade your My Site Host and personal site collections, you cannot undo the upgrade. > Some of the items in the
following list require additional steps to be performed. These additional steps are discussed in the sections that follow this
procedure. It is recommended when upgrading the entire server farm, that you also upgrade My Sites.
1. Install and configure a new SharePoint Server 2019 farm. For more information, see Create the SharePoint
Server 2016 farm for a database attach upgrade.
2. Copy the SharePoint Server 2016 My Site content database, Social database, Sync database (optional),
Profile database, and Managed Metadata service database to the SQL Server that supports your SharePoint
Server 2019 farm. You will need db_owner permissions to perform this step. For more information, see
Copy databases to the new farm for upgrade to SharePoint Server 2016 and Create the SharePoint Server
2016 farm for a database attach upgrade.
3. Create the new service applications that you need for the SharePoint Server 2019 farm. Do not create the
User Profile Service application and the Managed Metadata service application. You must upgrade
these service applications, which is described in the next step. You must however start the User Profile
Service and Managed Metadata service from Manage Services on Server.
4. Upgrade the Managed Metadata service and User Profile service applications using the database
attach method. For more information, see Upgrade service applications to SharePoint Server 2019. Ensure
the My Site Host URL field on the User Profile Service application is left blank because this field will be
updated during the upgrade process. For more information, see Configure My Site settings for the User
Profile service application
5. Create the web application for the My Sites using the default content database. To ensure the storage
requirements of your users are met, you should review the site quota on the My Sites web application.
6. Install customizations.
7. Run the Test-SPContentDatabase cmdlet to make sure that all customizations and language packs are
installed on the server before upgrading the My Site content databases. This cmdlet must be run against all
My Sites content databases. After running this cmdlet, you'll get a report on your environment. Ensure you
review all items in this report as some reported items may prevent you from moving onto the next step.
8. Run the Mount-SPContentDatabase cmdlet. Note: this does not upgrade any of the personal site
collections at this point. After this step is complete, the My Sites will still be displayed as SharePoint Server
2013 My Sites.
9. Check the configuration of the self-service site creation and managed paths settings on the My Sites web
application to ensure the correct configuration settings are applied to the web application.
10. Verify that the My Site Host URL field on the User Profile Service application has the correct URL users
should use to access the My Sites web application. For more information, see Configure My Site settings for
11. Upgrade the My Site Host from a SharePoint Server 2016 My Site host to a SharePoint Server 2019 My
Site Host (discussed in the section titled Upgrade the My Site Host site collection).
12. Upgrade the personal site collections (discussed in the section titled Upgrade the personal site collection).
Cau t i on
During the upgrade process, users will see some visual changes occurring on their My Sites until the upgrade
process is complete. You should inform your users and helpdesk administrators that this experience is expected.
Upgrade the My Site Host site collection

To upgrade a SharePoint Server 2016 My Site host to a SharePoint Server 2019 My Site host, run the following
command at the SharePoint 2019 Management Shell command prompt:
Upgrade-SPSite http://MySiteHostURL -versionupgrade

Where:
http://MySiteHostURL is the URL of the My Site Host.
Upgrade the personal site collection

The personal site collections are upgraded automatically when a user visits their My Site. The SharePoint Server
2019 My Site Host has a hidden, automatic upgrade web part on it. This upgrade process is performed per user
and may take some time to finish.
IMPORTANT
Once you upgrade your My Sites to SharePoint Server 2019 My Sites, you cannot revert to SharePoint Server 2016 My Sites.
NOTE
The upgrade of the personal site collection is not an instant process. The My Site is added to an upgrade queue. When the
upgrade starts, the My Site remains available to use during the upgrade process. Users can work on their documents
throughout the upgrade process. The My Site Host and personal site collection will display mixed user interface modes until
the upgrade is complete.
Other Resources
Update-SPProfilePhotoStore
The following articles provide information about performing an upgrade to SharePoint Server 2016.
CONTENT DESCRIPTION
Get started with upgrades to Find resources about how to start the
SharePoint Server 2016 upgrade process from SharePoint
Server 2013 with Service Pack 1 (SP1)
to SharePoint Server 2016.
Upgrade databases from SharePoint Find resources to help you perform the
2013 to SharePoint Server 2016 steps to upgrade databases from
SharePoint Server 2013 with Service
Pack 1 (SP1) to SharePoint Server 2016.
Upgrade site collections to SharePoint Find out how to upgrade a site

Server 2016 collection to SharePoint Server 2016.
Video: Cleanup of databases after Learn how to use Windows Powershell

upgrade procedure scripts to assist in cleaning up
SharePoint Server 2016 databases after
a successful upgrade procedure.
Get started with upgrades to SharePoint Server 2016
appropriately. These articles help you understand how the SharePoint upgrade process works. These articles also
include overviews of how to upgrade service applications.
understanding the upgrade for SharePoint Server 2016.
CONTENT DESCRIPTION
Overview of the upgrade process to Get a visual overview of the steps

SharePoint Server 2016 involved in performing an upgrade.
Services upgrade overview for SharePoint Server 2013 with the March
SharePoint Server 2016 2013 Cumulative Update included
several service applications, some of
which have databases that can be
upgraded when you upgrade to
SharePoint Server 2016. Find out which
service application databases can be
upgraded and what steps you must
take before, during, and after the
upgrade for your service applications.
Best practices for upgrading to Get off to the right start - review these
SharePoint Server 2016 best practices for testing and
performing an upgrade to SharePoint
Server 2016.
Overview of the upgrade process to SharePoint
Server 2016
To upgrade from Microsoft SharePoint Server 2013 with the March 2013 Cumulative Update to SharePoint
Server 2016, you use the database-attach method. In the database-attach method, you first create and configure
a SharePoint Server 2016 farm. Then you copy the content and service application databases from the
SharePoint Server 2013 with the March 2013 Cumulative Update farm, and then attach and upgrade the
databases. This upgrades the data to the new version. Site owners can then upgrade individual site collections.
SharePoint Server 2016 supports an upgrade from SharePoint Server 2013 with the March 2013 Cumulative
Update (CU ), version 15.0.4481.1005 or higher.
NOTE
All database must be upgraded to version 15.0.4481.1005 or higher, otherwise upgrade to SharePoint Server 2016 will be
blocked.
[TIP ] As a best practice, we recommend that you apply the latest Cumulative Update to SharePoint 2013
prior to upgrading to SharePoint 2016.
After you've configured a new SharePoint Server 2016 environment, you can copy the content and service
application databases from the SharePoint Server 2013 with the March 2013 Cumulative Update environment to
the SharePoint Server 2016 environment. You use a backup and restore process to copy the database. You can
also choose to set the databases to read-only in the SharePoint Server 2013 with the March 2013 Cumulative
Update environment so that users can continue to access their information, but not change it.
NOTE
SharePoint Server 2016 does not support SharePoint 2010 mode (that is, compatibility level 14) site collections. Any site
collection that is in this mode will block the attachment of that content database to the SharePoint Server 2016 farm. You
must upgrade all SharePoint 2010 mode sites to 2013 mode (that is, compatibility level 15) on the existing 2013 farm
before you mount the database on the new SharePoint 2016 farm. For additional information about site creation modes,
see the Control the compatibility range for site creation modes of Manage site collection upgrades to SharePoint
Server 2016.
You can run the Microsoft PowerShell Test-SPContentDatabase cmdlet on a SharePoint Server 2013 with the
March 2013 Cumulative Update content database that isn't attached to the SharePoint Server 2016 farm to
determine what site collections are running in SharePoint 2010 mode. The following Microsoft PowerShell
command sample returns the list of all site collections that are in SharePoint 2010 mode. You would run this
command on the SharePoint Server 2013 with the March 2013 Cumulative Update farm so that you could
upgrade those site collections into 2013 mode before attaching the content databases to a 2016 farm.
Get-SPSite -Limit All | ? { $_.CompatibilityLevel -eq 14 }
If you want to find sites in the SharePoint Server 2013 with the March 2013 Cumulative Update farm that are in
SharePoint 2010 mode but on a per-content database basis, run the following Microsoft PowerShell syntax on
the SharePoint Server 2013 with the March 2013 Cumulative Update farm:
Get-SPSite -ContentDatabase <database name> -Limit All | ? { $_.CompatibilityLevel -eq 14 }
administrators group in the SharePoint Central Administration website.
This article helps you understand the upgrade sequence so that you can plan an upgrade project. To get detailed
steps for an upgrade, see Upgrade databases from SharePoint 2013 to SharePoint Server 2016 and Upgrade site
Create the SharePoint Server 2016 farm

The first stage in the upgrade process creates the new SharePoint Server 2016 farm:
1. A server farm administrator installs SharePoint Server 2016 to a new farm. The administrator configures
farm settings and tests the environment.
2. A server farm administrator sets the SharePoint Server 2013 with the March 2013 Cumulative Update
farm to read-only so that users can continue to access the old farm while upgrade is in progress on the
new farm.
Copy the SharePoint Server 2013 with the March 2013 Cumulative
Update databases
service application databases from the SQL Server instance on the SharePoint Server 2013 with the
March 2013 Cumulative Update farm.
SharePoint Server 2016 farm and sets the databases to read-write on the new farm.
Upgrade SharePoint Server 2013 with the March 2013 Cumulative
Update databases and service applications
SharePoint Server 2013 with the March 2013 Cumulative Update only
2. A server farm administrator creates a web application on the SharePoint Server 2016 farm for each web
application on the SharePoint Server 2013 with the March 2013 Cumulative Update farm.
Figure: Upgrade the databases by using Windows PowerShell
Upgrade SharePoint Server 2013 with the March 2013 Cumulative

Update site collections
The final stage in the upgrade process is to upgrade the site collections. The upgrade process for My Sites is
slightly different from for other types of site collections.
Upgrade My Sites
IMPORTANT
A server farm administrator upgrades the My Site host and then individual users can upgrade their My Sites or
the farm administrator can upgrade them by using PowerShell. The following illustration shows four stages for
the My Site host and My Sites during the upgrade process.
NOTE
details and steps, read Upgrade site collections to SharePoint Server 2016.
Upgrade other SharePoint Server 2013 with the March 2013 Cumulative Update site collections
For information about how to upgrade a site collection, see Upgrade site collections to SharePoint Server 2016.
NOTE
upgrade them. For details and steps, read Upgrade site collections to SharePoint Server 2016.
Services upgrade overview for SharePoint Server
2016
have databases that can be upgraded when you upgrade from SharePoint Server 2013 to SharePoint Server
2016:
NOTE
Word Automation Services and Machine Translation Services can't be upgraded. A new service instance needs to be created.

The Secure Store Service uses a database to store information. This database must be upgraded as part of
a services database attach upgrade. You have to upgrade the data for this service application so that any
passwords.
Search
The Search service uses several databases. The search administration database stores search configuration
data, such as the topology, crawl rules, query rules, and the mappings between crawled and managed
properties. The analytics reporting database stores the results of usage analytics and statistics information
from the analyses.
The search administration database must be upgraded as part of a services database attach upgrade, and you can
optionally upgrade the analytics database as part of the services database attach upgrade. You have to attach and
upgrade the database for the User Profile service and Managed Metadata service before you upgrade the search
databases. You cannot use the database attach approach for the rest of the search databases, these databases are
re-created when you upgrade the Search service application.
Business Data Connectivity BDC_Service_DB_<GUID>
Managed Metadata Managed Metadata Service_<GUID>
PerformancePoint PerformancePoint Service Application_<GUID>
Search Search_Service_Application_DB_<GUID>
Search_Service_Application_AnalyticsReportingStoreDB_<GUI
D>
Secure Store Secure_Store_Service_DB_<GUID>
User Profile: Profile and Social databases User Profile Service Application_ProfileDB_<GUID>
User Profile Service Application_SocialDB_<GUID>
User Profile Service Application_SyncDB_<GUID>
The steps to upgrade these service application databases are included in Upgrade service applications to

upgrade:
templates.
Office Online Server
You must deploy Office Online Server and then connect SharePoint Server 2016 it to after the content
databases are upgraded. You do not have to wait until the site collections are upgraded because Office
Online Server supports both the 2013 and 2016 site collection modes in SharePoint Server 2016. For more
information, see Office Web Apps.
See also
Concepts
Best practices for upgrading to SharePoint Server
2016

To increase your chances of a successful and faster upgrade to SharePoint Server 2016, follow these best practices
to test and complete an upgrade.
Best practices for testing upgrade

To understand your environment before you upgrade it, and to plan for the time that an upgrade will require, you
should try one or more trial upgrades. The goal of testing upgrade is to find and fix issues and develop confidence
in the outcome before the real upgrade. To develop an accurate trial of the upgrade process from SharePoint
Server 2013 with Service Pack 1 (SP1) to SharePoint Server 2016, follow these best practices:
1. Know what is in your environment. Do a full survey first.
Document the hardware and software in your environment, where server-side customizations are installed
and used, and the settings that you need. This helps you plan the trial environment and also helps you
recover if upgrade fails.
2. Make your test environment as similar as possible to your real environment.
If possible, use the same kind of hardware and use the same settings, the same URLs, and so on to
configure it. Minimize the differences between your test environment and your real environment. As you
introduce more differences, you are likely to spend time resolving unrelated issues to make sure that they
will not occur during the actual upgrade.
3. Use real data.
Use copies of your actual databases to run the tests. When you use real data, you can identify trouble areas
and also determine upgrade performance. You can also 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.
Make sure that you find issues with the different kinds and sizes of sites, lists, libraries, and customizations
that are present in your environment. If you cannot test all data because of storage concerns, try going over
the data in several passes, removing the old trial copies before going on to the next batch.
4. Run multiple tests.
A single test can tell you whether you will encounter big problems. Multiple tests will help you find all the
issues that you might face and help you estimate a more accurate timeline for the process. By running
multiple tests, you can determine the following:
The upgrade approaches that will work best for your environment
The downtime mitigation techniques that you should plan to use
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 the errors and are ready to upgrade
your production environment.
5. Do not ignore errors or warnings.
Even though a warning is not an error, a warning could lead to problems in the upgrade process. Resolve
errors, but also investigate warnings to make sure that you know the results that a warning might produce.
6. Test the upgraded environment, not just the upgrade process.
Check your service applications and run a search crawl and review the log files.
Best practices for upgrading to SharePoint Server 2016

To guarantee a smooth upgrade from SharePoint Server 2013 to SharePoint Server 2016, follow these best
practices:
1. Install the latest Cumulative Update for SharePoint Server 2013 and latest Public Update for SharePoint
Server 2016 (but at a minimum, SharePoint Server 2013 must be running the March 2013 PU
(15.0.4481.1005)).
2. Ensure that the environment is fully functioning before you begin to upgrade.
An upgrade does not solve problems that already exist in your environment. Therefore, make sure that the
environment is fully functioning before you start to upgrade. For example, if you are not using web
applications, 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 Server
2016 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 estimated upgrade schedule.
3. Perform a trial upgrade on a test farm first.
Copy your databases to a test environment and perform a trial upgrade. Examine the results to determine
the following:
Whether the service application data was upgraded as expected
The appearance of upgraded sites
The time to allow for post-upgrade troubleshooting
The time to allow for the upgrade process
Try a full search indexing crawl.
4. Plan for capacity.
Ensure that you have enough disk, processor, and memory capacity to handle upgrade requirements. For
more information about system requirements, see System requirements for SharePoint Server 2016.
5. Clean up before you upgrade
Issues in your environment can affect the success of upgrade, and unnecessary or very large amounts of
data can affect upgrade performance for both databases and site collections. If you don't need something in
your environment, consider removing it before upgrade. If there are issues detected, try to resolve them
before you start to upgrade. .
6. Back up your databases.
Perform a full backup of your databases before you upgrade. That way, you can try upgrade again if it fails.
7. Optimize your environment before upgrade.
Be sure to optimize your SharePoint Server 2013 with Service Pack 1 (SP1) environment to meet any limits
or restrictions, either from your business or governance needs or from the SharePoint Server 2016
boundaries and limits before upgrade. This will help reduce errors during the upgrade process and prevent
broken lists or sites after upgrade.
8. (Optional) Set the original databases to read-only if you want to keep your original environment available
while you upgrade.
If you expect a long outage period while you upgrade, you can set the databases in the original environment
to read-only. Users can continue to access the data but cannot change it. For more information, see Upgrade
content databases to SharePoint Server 2016.
9. After upgrade, review the Upgrade Status page and upgrade logs to determine whether you must address
issues. 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. Verify all the sites and test them before you consider the upgrade
finished. For more information, see Verify database upgrades in SharePoint Server 2016 and the Review
site collections upgraded section in Upgrade site collections to SharePoint Server 2016.
10. Make sure that the appropriate service pack or update is applied to your 2013 environment. If you are using
remote blob storage (RBS ) in your environment, you must be running SharePoint Server 2013 with Service
Pack 1 (SP1) in your environment before you start the upgrade process.
The following articles provide information about upgrading databases to SharePoint Server 2016.
CONTENT DESCRIPTION
Create the SharePoint Server 2016 farm for a database attach Create and configure a SharePoint Server 2016 farm so that
upgrade you can upgrade databases from SharePoint Server 2013 with
Service Pack 1 (SP1).
Copy databases to the new farm for upgrade to SharePoint Copy SharePoint Server 2013 with Service Pack 1 (SP1)
Server 2016 content and service databases to a SharePoint Server 2016
farm so that you can upgrade the data to SharePoint Server
2016.
Upgrade service applications to SharePoint Server 2016 Upgrade service applications (Business Connectivity Services,
Upgrade content databases to SharePoint Server 2016 Learn how to upgrade content databases from SharePoint
Server 2013 with Service Pack 1 (SP1) to SharePoint Server
2016.
Verify database upgrades in SharePoint Server 2016 Verify that the upgrade for your databases has succeeded and
that you are ready to begin to upgrade sites.
Create the SharePoint Server 2016 farm for a
database attach upgrade
settings. Before you can upgrade the content, you must configure a new server or server farm by using
SharePoint Server 2016. This article lists the items that you have to configure when you create that new
environment.
Phase 1 of the upgrade process: Create SharePoint Server 2016 farm

in order:
upgrade (this phase)
Server 2016
2016Upgrade content databases to SharePoint Server 2016
For an overview of the whole process, see Overview of the upgrade process to SharePoint Server 2016.
Before you begin

Before you create the SharePoint Server 2016 farm, review the following information and take any recommended
actions.
features and functionality that you want in the SharePoint Server 2016 farm.
Make sure that you have planned for sufficient performance and capacity for the SharePoint Server 2016
farm.

IMPORTANT
The section explains how to configure service applications, except for the Business Data Connectivity service application
which applies to SharePoint Server 2016.
to know what is in your SharePoint Server 2013 environment before you can start to build your SharePoint
Server 2016 environment. Gather information such as the following:
Quota templates
Managed paths
Customizations
You also have to turn off or remove services or components in the SharePoint Server 2013 with Service Pack 1
(SP1) environment that could cause errors in the upgrade process. The following services or components should
be removed or stopped before you back up your databases:
PowerPoint Broadcast Sites Office Online Server has changed into a separate server product which can
serve multiple SharePoint farms for viewing and editing documents. Because of this change, PowerPoint
Broadcast sites cannot be upgraded to SharePoint Server 2016.

Secure Store database. For more information, see Work with encryption keys in Configure the Secure Store
Service in SharePoint 2013 .
Install SharePoint Server 2016 in a new environment

Before you can upgrade your databases, you must use SharePoint Server 2016 to configure a new server or
server farm. The first step in creating your new environment is to install SharePoint Server 2016 and configure
your new server or server farm. You must do the following:
NOTE
IMPORTANT
these service applications by upgrading the service application databases, do not use the Farm Configuration
Wizard to configure these service applications when you set up your new farm.
For step-by-step instructions for these tasks, see Install SharePoint Server 2016.

some service applications that can be upgraded from SharePoint Server 2013 to SharePoint Server 2016. The
steps in Install SharePoint Server 2016 describe how to use the Farm Configuration Wizard to enable all service
applications. However, you should not use the Farm Configuration Wizard to enable the service applications that
you want to upgrade.
Search
For an overview of how to upgrade these service applications, see Services upgrade overview for SharePoint
Server 2016. For the specific steps to upgrade these service application databases see Upgrade service
applications to SharePoint Server 2016.

configuration settings from your SharePoint Server 2013 farm, such as the following:
Blocked file types
Diagnostic logging
IMPORTANT
If you had disabled the Workflow Auto Cleanup timer job in your SharePoint Server 2013 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
SharePoint Server 2013 environment, you might lose workflow associations when you upgrade. .
In a standard installation, the next step would be to create web applications. However, for upgrade, you create
web applications later in the process, after you upgrade the service application databases. For more information,
see Create web applications.

settings. After you have configured a new SharePoint Server 2016 environment, you can copy the content and
service application databases from the SharePoint Server 2013 environment to the SharePoint Server 2016
environment. You use a backup and restore process to copy the database, and you can also choose to set the
databases to read-only in the SharePoint Server 2013 environment so that users can continue to access their
information, but not change it. This article contains the steps that you take to copy the databases.
This is the second phase in the process to upgrade

SharePoint Server 2013 data and sites to SharePoint Server
2016. The process includes the following phases that must be
completed in order:
attach upgrade. Copy databases to the new farm for upgrade
to SharePoint Server 2016 (this phase) Upgrade service
applications to SharePoint Server 2016. Upgrade content
databases to SharePoint Server 2016. For an overview of the
whole process, see Overview of the upgrade process to
Before you begin

Studio on both the SharePoint Server 2013 and SharePoint Server 2016 environments and has access to
a network location that can be accessed from both environments to store the copies of the databases.
Make sure that the appropriate service pack or update is applied to your 2013 environment. If you are
using remote blog storage (RBS ) in your environment, you must be running SharePoint Server 2013 in
your environment before you start the upgrade process.

To maintain user access to your original environment, set the SharePoint Server 2013 databases to read-only
before you back up the databases. Even if you don't want to maintain access over the long term, set the
databases to read-only to make sure that you capture all the data in the backup so that you restore and upgrade
the current state of the environment without allowing additional changes to be made. If the databases are set to
read-only, users can continue to view content. However, they will be unable to add or change content.
NOTE
Don't set search databases to read-only at this point. It's best not to interrupt the search experience until you're ready to
upgrade the Search service applications. You will handle these databases when you upgrade service applications (the
fourth phase in the process to upgrade SharePoint Server 2013 data and sites to SharePoint Server 2016).
IMPORTANT

1. Verify that the user account that is performing this procedure is a member of the db_owner fixed
Properties.
Back up the SharePoint Server 2013 databases by using SQL Server

tools
upgrade. Repeat the procedure for the following databases in the SharePoint Server 2013 server farm:
You do not have to back up the configuration or admin content databases, because you recreated these
databases when you set up the SharePoint Server 2016 server farm. Upgrading the configuration or admin
content databases and the Central Administration site collection is not supported.
IMPORTANT

8. 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.
SharePoint Server 2013 uses in your environment.
Copy the backup files to the SharePoint Server 2016 environment

Copy the backup files that you created in the previous procedure from the SharePoint Server 2013 environment
to the SharePoint Server 2016 environment.

After you configure the new SharePoint Server 2016 server farm, you can restore the backup copies of the
databases to SQL Server. Start with one database, and then verify that the restoration has worked before you
restore the other databases.
IMPORTANT
again. > Perform this step in the SharePoint Server 2016 environment.

2. After you connect to the appropriate instance of the SQL Server 2014 Database Engine, in Object
Explorer, expand the server name.
4. In the Restore Database dialog box, on the General page, type the name of the database to be restored
in the To database list.
TIP
make that change. Be sure to also change the database and log file names in the file system (the MDF and LDF
files) so that they match.
6. To specify the source and location of the backup sets to restore, click From device, and then use the
ellipsis ( ...) to select the backup file.

SharePoint Server 2016 farm before you attach and upgrade them.
IMPORTANT

Properties.

SharePoint Server 2013 data and sites to SharePoint Server
2016.
Next phase: Upgrade service applications to SharePoint
Server 2016
See also
Concepts
2016
When you upgrade from SharePoint Server 2013 with Service Pack 1 (SP1) to SharePoint Server 2016, you must
use a database attach upgrade, which means that you upgrade only the content for your environment and not the
configuration settings. After you have configured the SharePoint Server 2016 environment, and copied the
content and service application databases, you can upgrade the service applications to SharePoint Server 2016.
This article contains the steps that you take to upgrade the service applications.

Server 2013 with Service Pack 1 (SP1) data and sites to
SharePoint Server 2016. The process includes the following
phases that must be completed in order:
upgrade
Server 2016
Upgrade service applications to SharePoint Server 2016 (this
phase)
Before you begin

Before you upgrade the service applications, review the following information and take any recommended
actions.
TIP
variables, you must use IDs for the service applications and service application proxies when you specify the identity
NOTE
For any SPWebURL Managed Property in their SharePoint 2013 Schema they should rename it before they start the
procedure (that is, SPWebURL to SPWebURL1). After you upgrade to SharePoint Server 2016, they SPWebURL1 managed
property name can changed back to the original name (that is, SPWebURL).

NOTE
Word Automation Services and Machine Translation Services can't be upgraded. A new service instance will need to be
created.
IMPORTANT
The following steps outlining starting service instances only apply to the Custom server role type. For more information on
server role types, see Planning for a MinRole server deployment in SharePoint Server 2016.

Secure Store service, and Search service. Most of these service instances can be started from Central
Administration. However the SharePoint Server Search service instance must be started by using
PowerShell.
applications:

For Windows Server 2012 R2:
On the Start screen, click SharePoint 2016 Central Administration.
If SharePoint 2016 Central Administration is not on the Start screen:
Right-click Computer, click All apps, and then click SharePoint 2016 Central Administration.
For more information about how to interact with Windows Server 2012 R2, see Common Management
Tasks and Navigation in Windows Server 2012.
2. In SharePoint 2016 Central Administration, on the Application Management page, in the Service
Applications section, click Manage Services on Server.
2016 cmdlets.
NOTE

On the Start screen, click SharePoint 2016 Management Shell.
If SharePoint 2016 Management Shell is not on the Start screen:
Right-click Computer, click All apps, and then click SharePoint 2016 Management Shell.

environment.
2016 cmdlets.
NOTE

For more information about how to interact with Windows Server 2012 R2Windows Server 2012, see
Common Management Tasks and Navigation in Windows Server 2012.
Where:
4. To upgrade the Secure Store service application, at the Microsoft PowerShell command prompt, type the
following command:

Where:
TIP
Where:
TIP
application IDs.
local farm.
passphrase.
Where:
TIP

2016 cmdlets.
NOTE

Where:
applications.
4. To upgrade the Business Data Connectivity service application, at the Microsoft PowerShell command prompt,

Where:
TIP
database, and then create a proxy and add it to the default proxy group.
2016 cmdlets.
NOTE

Where:
applications.
This cmdlet sets the service application pool as a variable that you can use again in the cmdlets that
follow. If you have multiple application pools and have to use a different application pool for a particular
service application, repeat this step in the procedure to create each service application to use the
appropriate application pool.
4. To upgrade the Managed Metadata service application, at the Microsoft PowerShell command prompt, type
the following command:

Where:
TIP
5. At the Microsoft PowerShell command prompt, type the following command to create a proxy for the
Managed Metadata service application:
Where:
TIP
the local farm.

2016 cmdlets.
NOTE

Where:
applications.
4. To upgrade the PerformancePoint Services service application, at the Microsoft PowerShell command prompt,

Where:
application.
TIP

For more information, see New -SPPerformancePointServiceApplication.
Where:
TIP
local farm.

Upgrade the Managed Metadata service application before you upgrade the User Profile service application.
To upgrade the User Profile service application, you copy the Profile and Social databases in your SharePoint
Server 2013 with Service Pack 1 (SP1) farm to your SharePoint Server 2016 farm and create a new User Profile
service application from your SharePoint Server 2013 with Service Pack 1 (SP1) farm in your SharePoint Server
2016 farm. The restore triggers SharePoint Server 2016 to create a new User Profile service application in the
SharePoint Server 2016 farm and point it to the copied User Profile databases. To complete the upgrade of the
User Profile service application, you create a proxy and add it to the default proxy group.
NOTE
As SharePoint Server 2016 does not have the User Profile Synchronization Service, you do not copy the Synchronization
database. Instead, a new database will be created with an empty schema.

1. Copy the Profile and Social databases in the SharePoint Server 2013 with Service Pack 1 (SP1) farm to the
SharePoint Server 2016 farm by following these steps:
IMPORTANT
Perform these steps in the SharePoint Server 2013 with Service Pack 1 (SP1) environment.

NOTE
SPShellAdmin.

For Windows Server 2012 R2: On the Start screen, click SharePoint Management Shell.
If SharePoint Management Shell is not on the Start screen, right-click Computer, click All apps,
and then click SharePoint Management Shell.
For more information about how to interact with Windows Server 2012 R2, see Common
Management Tasks and Navigation in Windows Server 2012.
Set the User Profile databases to read-only. In the second phase of the process to upgrade
SharePoint Server 2013 with Service Pack 1 (SP1) data and sites to SharePoint Server 2016, you
set all the other databases to read-only.
Copy the Profile and Social databases in the SharePoint Server 2013 with Service Pack 1 (SP1)
farm to the SharePoint Server 2016 farm, follow the procedures in Copy databases to the new farm
for upgrade to SharePoint Server 2016 for the search administration database only.
IMPORTANT

2016 cmdlets.
NOTE

If SharePoint Management Shell is not on the Start screen, right-click Computer, click All apps, and
then click SharePoint Management Shell.
Where:
5. To restore the User Profile service application and upgrade the Profile and Social databases, at the
New-SPProfileServiceApplication -Name '<UserProfileApplicationName>' -ApplicationPool $applicationPool

-ProfileDBName '<ProfileDBName>' -SocialDBName '<SocialDBName>' -ProfileSyncDBName '<SyncDBName>'
Where:
UserProfileApplicationName is the name of the User Profile service application.
TIP
ProfileDBName is the name of the Profile database that you want to upgrade.
SocialDBName is the name of the Social database that you want to upgrade.
SyncDBName is the name of the new Synchronization database that you want to upgrade.
6. Create the User Profile service application proxy and add it to the default proxy group by completing these
actions:
Type the following command to get the ID for the User Profile service application and store it as a
variable:
$sa = Get-SPServiceApplication | ?{$_.TypeName -eq 'User Profile Service Application'}
For more information, see Get-SPServiceApplication.

Type the following command to create a proxy for the User Profile service application:
New-SPProfileServiceApplicationProxy -Name ProxyName -ServiceApplication $sa

Where:
$sa is the variable that you set earlier to identify the new User Profile service application.
Tip: If you do not use the variable $sa, then you must use an ID to identify the User Profile
$proxy = Get-SPServiceApplicationProxy | ?{$_.TypeName -eq 'User Profile Service Application

Proxy'}
For more information, see Get-SPServiceApplicationProxy.

Type the following command to add the User Profile service application proxy to the default proxy
group:
Add-SPServiceApplicationProxyGroupMember -member $proxy -identity ""
Where:
$proxy is the variable that you set earlier to identify the ID for the proxy you just created for
Tip: If you do not use the variable $proxy, then you must use an ID to identify the User
Profile service application proxy instead of a name. To find the ID, you can run the Get-

Upgrade the User Profile service application and the Managed Metadata service application before you upgrade
To upgrade the Search service application, you copy the search administration database in your SharePoint
Server 2013 with Service Pack 1 (SP1) farm to your SharePoint Server 2016 farm and restore the Search service
application from your SharePoint Server 2013 with Service Pack 1 (SP1) farm in your SharePoint Server 2016
farm. The restore triggers SharePoint Server 2016 to create a new Search service application in the SharePoint
Server 2016 farm and point it to the copied search administration database. To complete the upgrade of the
Search service application you create a proxy and add it to the default proxy group and you ensure that the new
Links Database and the new search topology is configured the same way as in the SharePoint Server 2013 with
Service Pack 1 (SP1) farm.
SharePoint Server 2016 normally creates a new search topology with all the search components and databases
when it creates a the new Search service application. During a restore of a Search service application, SharePoint
Server 2016 creates a new search topology, but upgrades the restored Search Administration database instead of
creating a new Search Administration database. The upgraded Search Administration database retains any
additions or modifications made to the search schema, result sources and query rules from the SharePoint Server
2013 with Service Pack 1 (SP1) farm.
NOTE
During this upgrade, search doesn't crawl content in your SharePoint Server 2013 with Service Pack 1 (SP1). If freshness of
search results is important, save time by familiarizing yourself with these steps before starting the upgrade.
IMPORTANT
Because the search topology in the SharePoint Server 2016 farm is new, the index is empty. You have to perform a full crawl
of the entire indexed corpus after you have upgraded all content sources (the fourth phase in the process to upgrade
SharePoint Server 2013 with Service Pack 1 (SP1) data and sites to SharePoint Server 2016).

1. Copy the search administration database in the SharePoint Server 2013 with Service Pack 1 (SP1) farm to
the SharePoint Server 2016 farm by following these steps:
NOTE
You copied all other content and service databases in your SharePoint Server 2013 with Service Pack 1 (SP1)
environment in an earlier step of the process for upgrading to SharePoint Server 2016. We recommend copying the
Search Administration database at this later stage because you have to pause the Search service application in your
SharePoint Server 2013 with Service Pack 1 (SP1) environment while copying the Search Administration database.
IMPORTANT
Perform these steps in the SharePoint Server 2013 with Service Pack 1 (SP1) environment.

NOTE
SPShellAdmin.

If SharePoint Management Shell is not on the Start screen, right-click Computer, click All apps,
For more information about how to interact with Windows Server 2012 R2, see Common
Management Tasks and Navigation in Windows Server 2012.
Set the Search Administration database to read-only. In the second phase of the process to upgrade
SharePoint Server 2013 with Service Pack 1 (SP1) data and sites to SharePoint Server 2016, you
set all the other databases to read-only. Follow the same instructions now for the Search
Administration database.
Pause the Search service application. At the Windows PowerShell command prompt, type the
following command:

Where:
SearchServiceApplicationName is the name of the Search service application you want to pause.
NOTE
While the Search service application is paused, the index in the SharePoint Server 2013 with Service Pack 1
(SP1) environment isn't updated. This means that during the upgrade to SharePoint Server 2016, search
results might be less fresh.
Copy the search administration database in the SharePoint Server 2013 with Service Pack 1 (SP1)
farm to the SharePoint Server 2016 farm, follow the procedures in Copy databases to the new farm
for upgrade to SharePoint Server 2016 for the search administration database only.
IMPORTANT

2016 cmdlets.
NOTE

If SharePoint Management Shell is not on the Start screen, right-click Computer, click All apps, and
Where:
application pool.
5. To restore the Search service application and upgrade the Search Administration database, at the

Where:
TIP
SearchServiceApplicationDBName is the name of the search administration database that you want
to upgrade, and that this Search service application shall use.
Note: A Search service application upgrade might fail, for example due to network or SQL Server latency.
If an error message appears during the upgrade, do the following:
Delete the Search Administration database that you were trying to upgrade.
Using the backup copy that you made of the Search Administration database, repeat the following
procedures in this article for the Search service application only:
Type the command to upgrade the Search service application again at the Microsoft PowerShell
command prompt.
6. Create the Search service application proxy and add it to the default proxy group by completing these
actions:
variable:

Where:
Tip: If you do not use the variable $ssa, then you must use an ID to identify the Search

Type the following command to add the Search service application proxy to the default proxy
group:
Add-SPServiceApplicationProxyGroupMember -member $ssap -identity ""
Where:
$ssap is the variable that you set earlier to identify the ID for the proxy you just created for
Tip: If you do not use the variable $ssap, then you must use an ID to identify the Search
service application proxy instead of a name. To find the ID, you can run the Get-
7. If the SharePoint Server 2013 with Service Pack 1 (SP1) farm uses a Links Database that is partitioned,
partition the Links Database in the SharePoint Server 2016 farm the same way. Learn how in Move-
SPEnterpriseSearchLinksDatabases.
8. (Optional) Preserve search relevance settings from the SharePoint Server 2013 with Service Pack 1 (SP1)
farm. Because the upgraded Search service application has a new, empty index, search analytics data from
the SharePoint Server 2013 with Service Pack 1 (SP1) farm cannot be fully retained. Copy the Analytics
Reporting database from the SharePoint Server 2013 with Service Pack 1 (SP1) farm and attach it to the
new Search service application in the SharePoint Server 2016 farm:
In the SharePoint Server 2013 with Service Pack 1 (SP1) farm, backup the Analytics Reporting
database.
In the SharePoint Server 2016 farm, restore the backed up database to the new database server.
In the SharePoint Server 2016 farm, attach the restored database to the new Search service
application.
9. Verify that the search topology on the new SharePoint Server 2016 farm is alike that of the SharePoint
Server 2013 with Service Pack 1 (SP1) farm. If your requirements for search have changed, now is a good
time to scale out the search topology of the new SharePoint Server 2016 farm.
10. Resume the Search service application in the SharePoint Server 2013 with Service Pack 1 (SP1)
environment.
At the PowerShell command prompt, type the following command:

$ssa.Resume()
Where:
SearchServiceApplicationName is the name of the Search service application you want to resume.
Use the following procedure to verify that the steps to create the proxies and add them to the default proxy group
worked.
Server 2016 cmdlets.
Note: If you do not have permissions, contact your Setup administrator or SQL Server administrator to
request permissions. For additional information about PowerShell permissions, see Add-SPShellAdmin.
If SharePoint 2016 Management Shell is not on the Start screen, right-click Computer, click All apps,
and then click SharePoint 2016 Management Shell.
$pg = Get-SPServiceApplicationProxyGroup -Identity ""
$pg.Proxies
Where:
You use an empty Identity parameter ("") to specify the default proxy group.

Next phase: Upgrade content databases to SharePoint Server 2016
See also
Concepts
Other Resources
Upgrade content databases to SharePoint Server
2016
When you upgrade from SharePoint Server 2013 with Service Pack 1 (SP1) to SharePoint Server 2016, you
must use a database attach upgrade, which means that you upgrade only the content for your environment and
not the configuration settings. After you have configured the SharePoint Server 2016 environment, copied the
content and service application databases, and upgraded the service applications, you can attach and upgrade
the content databases to SharePoint Server 2016. This article explains the steps you take to attach and upgrade
the content databases to SharePoint Server 2016.

SharePoint Server 2016. The process includes the following
phases that must be completed in order:
attach upgrade
Server 2016
Upgrade content databases to SharePoint Server 2016 (this
phase)
Before you begin

Create a web application for each web application that existed in the SharePoint Server 2013 with Service Pack 1
(SP1) environment. For each web application, do the following:
settings.
For example, if you use Windows Classic authentication in your old environment, and you want to
continue to use it, then you must create a web application that uses Windows Classic authentication.
Because claims-based authentication is now the default option for SharePoint Server 2016, you must use
PowerShell to create a web application that uses Windows Classic authentication. .
Recreate managed paths.
Enable self-service site creation for any web application that used it in the previous environment. Recreate
any self-service site creation settings.
solutions, or other elements. Make sure that all custom elements from the SharePoint Server 2013 with Service
Pack 1 (SP1) environment are installed on your front-end web servers before you upgrade any content
databases.
In this step, you manually transfer all customizations to your new farm. Make sure to install any components that
your sites depend on to work correctly, such as the following:
Custom Web Parts
Custom Web services
Custom assemblies
Ensure that you transfer all unique settings from the Web.config files for each web application to the new
servers.
InfoPath is available in SharePoint Server 2010 only.
The installation for SharePoint Server 2016 contains both SharePoint Server 2013 with Service Pack 1 (SP1) and
SharePoint Server 2016 versions of many elements. The directories on the file system are duplicated in both the
15 and 16 paths, for example:
Web Server Extensions/15/TEMPLATE/Features
There are also two versions of the IIS support directories: _Layouts, _Layouts/16 and _ControlTemplates,
_ControlTemplates/16.
Be sure to install customizations to the correct location in your new farm. For example, additional style sheets for
SharePoint Server 2013 with Service Pack 1 (SP1) should be installed in the /15 path, not the new /16 path so
that site collections that you haven't upgraded can use them. If you want a solution to be available to both paths,
install it two times, and the second time use the CompatibilityLevel parameter when you install it, and it will be
installed to the /16 path. For more information, see Install-SPSolution.

enumallwebs operation in the SharePoint Server 2013 with Service Pack 1 (SP1) environment and use the
includefeatures and includewebparts parameters. This operation can report the templates, features, Web
Parts, and other custom elements that are used for each site. For more information about how to use the
enumallwebs operation, see Enumallwebs: Stsadm operation (Office SharePoint Server) and Clean up an
environment before an upgrade to SharePoint 2013.
You can also use the Get-SPWeb cmdlet in your SharePoint Server 2013 with Service Pack 1 (SP1) environment
to see template that are associated with each site and then verify that the template is installed in your SharePoint
Server 2016 environment. For more information about this operation, see Get-SPWeb.
Before you attach the content databases to the web applications, use the Test-SPContentDatabase cmdlet to
verify that you have all the custom components that you must have for that database.
2016 cmdlets.
NOTE

Where:


database
the web application that you specify. After the databases are upgraded, the site collection upgrade process is
automatically started by default.
When you attach a content database, for a web application that spans multiple content databases, make sure that
you attach the content database that contains the root site collection first. In other words, before you continue,
examine the root of the web application in the SharePoint Server 2013 with Service Pack 1 (SP1) server farm to
determine the first site collection. After you attach the database that contains the root site, 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 attaches the content databases and the site collections
inside that database. Make sure that you do not add new site collections until you have restored all the content
databases.
TIP
For My Sites, attach the content database that contains the My Site host before attaching databases that contain
the My Sites.
By default, when you created the web applications in the new SharePoint Server 2016 environment, a content
attached your SharePoint Server 2013 with Service Pack 1 (SP1) databases, and then you can delete the default
databases.
IMPORTANT
NOTE
elements. Be sure that all custom elements from the SharePoint Server 2013 with Service Pack 1 (SP1) environment are
installed on your front-end web servers in the SharePoint Server 2016 environment before you start the upgrade process.
Use the Test-SPContentDatabase cmdlet to identify custom elements that your sites might be missing.

1. You must use the Mount-SPContentDatabase cmdlet to attach a content database to a web application.
upgrading.
If you want to delay the sites upgrade, you can use the SkipSiteUpgrade parameter of the Mount-
SPContentDatabase cmdlet.
NOTE
Using the Mount-SPContentDatabase cmdlet to attach a content database is the recommended behavior and
option for upgrading databases and site collections in SharePoint Server 2016.
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.
2016 cmdlets.
NOTE

Where:

For more information, see Mount-SPContentDatabase.After the databases are upgraded, the site collections are
automatically upgraded. For additional information on how to upgrade a site collection, see Upgrade site
Verify upgrade for the first database

After you attach a database, you can use the Upgrade Status page in Central Administration to check the status
of upgrade on your databases. After the upgrade process is complete, you can review the upgrade log file to see
whether upgrade produced issues. You can use a PowerShell cmdlet to check the upgrade status for all the
content databases. For more information about verifying and troubleshooting upgrade, see Verify database
upgrades in SharePoint Server 2016.
%COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\16\LOGS. The upgrade log
file contains more detailed information than the upgrade error log. Be sure to check the summary at the
the file.
Where
An example for an upgrade error log is Upgrade-20120105-132126-374-error.log, and an example for an
upgrade log is Upgrade-20120105-132126-374.log.
NOTE
The format of the upgrade log for SharePoint Server 2016 is based on the same structure as ULS. > The upgrade
log file includes the name of the content database being upgraded.

2016 cmdlets.
NOTE

upgrade to SharePointAll_2nd_CurrentVer.

databases. You can perform parallel database attach upgrades to upgrade more than one database at a time. Use
separate Microsoft PowerShell command prompt to run multiple upgrades. It is recommended that you separate
the start time for each new database upgrade session by several minutes to prevent issues with temporary locks
set for the web application during attachment. Otherwise you might receive an error on the upgrade session. The
wait time to clear temporary locks varies depending on the number of site collections, or the speed of the
Verify upgrade for additional databases

After you upgrade all 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.
Next steps
By default, new web applications in SharePoint Server 2016 use claims authentication. If you were using
classic authentication in the previous environment, you must migrate the users to claims authentication.
are used in those upgraded form templates to point to the correct URLs by using a Microsoft PowerShell
cmdlet.
Back up your farm

2010 Products data and sites to SharePoint Server 2016.
Verify database upgrades in SharePoint Server 2016

After you upgrade databases to SharePoint Server 2016, you must verify that the content was successfully
upgraded to the new version. You can verify the status of the database-attach upgrade (is it still in progress, or has
it been completed successfully or with errors or failures?) to see whether 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

errors or warnings.
YYYYMMDD -HHMMSS -SSS -<GUID>.log, where YYYYMMDD is the date and HHMMSS -SSS is the time
errors and warnings in a shorter file and is named Upgrade- YYYYMMDD -HHMMSS -SSS -<GUID>-
error.log.
The format of the log files complies with the Unified Logging System (ULS ) conventions. 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 tries will be listed in the log file.
If you find blocking issues in the log file, you can resolve the issues and then restart upgrade to continue with the
process.
Check the upgrade status for databases
The Upgrade Status page lists the upgrade sessions and gives details about the status 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.
status.

following items:
Site collections
Search
Check that the search configuration settings are alike those in the SharePoint Server 2013 farm.
Upgrade site collections to SharePoint Server 2016
Articles about how to upgrade site collections
DESCRIPTION
Upgrade a site collection to SharePoint Server 2016 Site collection administrators can preview a copy of their sites
in SharePoint Server 2016 mode, upgrade their site
collections, and then review them for issues.
Upgrade My Sites to SharePoint Server 2016 Learn how to upgrade My Sites in SharePoint Server 2016.
In SharePoint Server 2016 the way site collection upgrades are performed has changed. After a server farm
administrator has upgraded the databases, site collections are automatically upgraded.
NOTE
There is no concept of "site collection compatibility modes" in SharePoint Server 2016. You must be running the latest
version at all times.

SharePoint Server 2016 introduces a new site collection upgrade experience. There are three ways to upgrade a
site collection:
In conjunction with content databases upgrade
On-browse upgrade
Manually triggered by using PowerShell.
Content databases upgrade- To upgrade the databases run the Mount-SPContentDatabase cmdlet. After the
databases have been upgraded the site collections are automatically upgraded during database upgrade process
by default.
NOTE
This is the default behavior and recommended method to upgrade databases.
IMPORTANT
If you want to delay the sites upgrade, use the SkipSiteUpgrade parameter of the Mount-SPContentDatabase cmdlet. >
When the parameter is provided, the site collection is upgraded when first browsed.
On-browse upgrade - You do not need to know whether the site collection has pending upgrade, SharePoint
decides it for you during the upgrade process. Once the site is browsed, SharePoint checks if the site needs to be
upgraded, if so, the site will be put in a queue and a timer job will pick it up for upgrade.
Farm administrators can use PowerShell to upgrade a site collection.
Manually trigger site upgrade - You can use the Upgrade-SPSite cmdlet to manually upgrade the site
collections.
NOTE
This is a legacy option to upgrade a site collection.
This option is ideal for databases with large number of sites and for customers who use only a subset of all their
sites.
Verify that site collection upgrade has succeeded
2. On the Site Settings page for the site collection, in the Site Collection Administration section, click Site
collection upgrade.
Farm administrators can use PowerShell to view site collection upgrade status.
Review site collections upgraded to SharePoint Server 2016

After the site collections have been upgraded to SharePoint Server 2016, review your upgraded sites to fix any
issues after you have upgraded a site collection. Use the steps in this section to identify any issues before you
upgrade your production environment.
To verify basic functionality, 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.
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 site
collection upgrade log file to see whether you can get more information about the problem.
For site collection administrators: If site collections are upgraded by using the Mount-
SPContentDatabase cmdlet, there are no separate SiteUpgrade*.log files. The SiteUpgrade logs are inside
Upgrade*.log files.
NOTE
You can retrieve the log files by using PowerShell . > From a PowerShell command prompt type the following syntax:
Get-SPSiteUpgradeSessionInfo -Site <siteUrl> OR $site.UpgradeInfo
in the following format: SiteUpgrade- 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). These file
system logs have more information if you want details about issues.
For additional information on how to troubleshoot error messages, see Troubleshoot site collection
upgrade issues in SharePoint Server 2016.

Large lists
By default, large list query throttling is turned on in SharePoint Server 2016. 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 administrator 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. For more information about large list throttling and how to address
issues with large lists, see Manage lists and libraries with many items.
The following table lists common issues with the style and appearance of your web site after upgrade and how to
address them.
TIP
theme do you want to use? different after the site is upgraded. You may have to re-create
or revise a theme and reapply it.
strict XHTML mode.
See also
Concepts
My Sites are personal site collections that end users can use to store their documents, connect with other users,
and follow and discover content. Upgrading My Sites differs from upgrading other site collections because My
Sites consist of both the shared My Site Host site collection (also known as the My Site Host) and the My Site
Personal site collection. In SharePoint Server 2013, the personal site collection was used to store a user's
documents. In SharePoint Server 2016, the personal site collection contains OneDrive for Business,
followed content, and so on.
Plan to upgrade My Sites

Consider whether you have to upgrade from classic-mode to claims-based authentication in SharePoint
Server 2013. For more information, see Migrate from classic-mode to claims-based authentication in
SharePoint Server
IMPORTANT
upgrades, see Get started with upgrades to SharePoint Server 2016
Upgrade My Sites
about upgrades, see Upgrade to SharePoint Server 2016
IMPORTANT
Once you upgrade your My Site Host and personal site collections, you cannot undo the upgrade. > Some of the items in
the following list require additional steps to be performed. These additional steps are discussed in the sections that follow this
procedure. It is recommended when upgrading the entire server farm, that you also upgrade My Sites.
Server 2016 farm for a database attach upgrade.
Copy databases to the new farm for upgrade to SharePoint Server 2016 and Create the SharePoint Server
attach method. For more information, see Upgrade service applications to SharePoint Server 2016. Ensure
the My Site Host URL field on the User Profile Service application is left blank because this field will be
updated during the upgrade process. For more information, see Configure My Site settings for the User
Profile service application
6. Set the compatibility range settings for site creation on the My Sites web application. Use
MinCompatibilityLevel = 15 and MaxCompatibilityLevel= 15 for your compatibility range settings.
2013 My Sites.
application to ensure the correct configuration settings are applied to the web application. For more
information, see Configure My Sites in SharePoint Server.
Cau t i on
Upgrade the My Site Host site collection

Where:
Upgrade the personal site collection

2016 My Site Host has a hidden, automatic upgrade web part on it. When a user visits the My Site Host, and if the
compatibility range settings allow 2013 user interface mode, an automatic upgrade of the user's My Site starts.
This upgrade process is performed per user and may take some time to finish.
Alternative procedure for upgrading My Sites

You may have constraints that restrict you from upgrading your My Sites to SharePoint Server 2016 My Sites. For
example, you are upgrading your entire server farm but you have customizations on your My Sites that you have
not tested on SharePoint Server 2016. In this scenario, you may not want to upgrade your My Sites until you
complete your testing.
If you want to upgrade your server farm but keep your My Sites as SharePoint Server 2013 My Sites, change the
previous procedure for upgrading My Sites as follows:
Step 6: Use MinCompatibilityLevel = 14 and MaxCompatibilityLevel= 14 for your compatibility range
settings on the My Sites web application.
Step 12: do not perform this step.
When you are ready to perform the upgrade of your My Sites:
Set MinCompatibilityLevel = 15 and MaxCompatibilityLevel= 15 for your compatibility range settings on
the My Sites web application.
Upgrade the My Site Host as described in Step 12
Upgrade the personal site collections as described in Step 13
IMPORTANT
Alternative procedure for upgrading the personal site collection

Administrators may choose these alternate methods of upgrading the personal site collections if they do not want
their users experiencing the automatic upgrade of their My Site on their first visit to the My Site Host:
Forced upgrade. If you use the forced upgrade path, users will not experience an automatic upgrade the
first time they visit their My Site. Instead, their My Site will already be upgraded for them. A farm
administrator can perform a forced upgrade of all My Sites in the farm by running the following command
at the SharePoint 2016 Management Shell command prompt:
Get-SPSite -limit all |where {$_.CompatibilityLevel -eq '14'} | where {$_.RootWeb.WebTemplateId -eq 21}
| upgrade-spsite -versionupgrade
IMPORTANT
Before performing a forced upgrade, you should confirm that the My Site Host was upgraded successfully. You can
verify this by either making sure that the My Site Host has the SharePoint Server 2016 user interface, or by
inspecting the ULS logs to make sure that no errors were encountered during the upgrade process.
Cau t i on
Using the forced upgrade approach may take lots of time to complete depending on the number of My
Sites you are upgrading. This will affect your server farm's performance and the farm will be in read-only
mode during the complete upgrade process.
Deferred site collection upgrade. The deferred site collection upgrade process uses the compatibility
range settings to allow administrators to upgrade their databases and keep their site collections in
SharePoint Server 2010 mode. When the compatibility range settings allow both 2010 user interface mode
and 2013 user interface mode (MinCompatibilityLevel = 14 and MaxCompatibilityLevel= 15), the owner of
the My Site will see a red banner at the top of their My Site. From the banner, they can request an
evaluation site collection of their My Site to preview before upgrading to the SharePoint Server 2013 user
interface. The evaluation site cannot be converted to a regular My Site because it is a temporary site which
will eventually be deleted. The deferred site collection upgrade path is performed per user.
Cau t i on
Using the deferred site collection upgrade may result in the mixed user interface mode issue. Be sure to
stage and test your upgrade carefully before you do this in production. When you encounter the mixed user
interface mode on your My Sites, new users who do not have a My Site cannot create new My Sites.
Troubleshoot a My Site upgrade

If users are experiencing issues, such as mixed user interface modes or they cannot upgrade their My Site to the
SharePoint Server 2013 user interface mode, verify that the following steps were completed:
The My Site Host was upgraded to a SharePoint Server 2016 My Site Host.
The compatibility range settings allow site creation in 2013 user interface mode.
The SPSite.CanUpgrade property on the personal site collection of the user requesting the upgrade is set to
true. An administrator may allow or restrict certain site collections from being upgraded by setting this
property at the site collection level.
NOTE
See also
Other Resources
Video: Cleanup of databases after upgrade
procedure
Listen to two Microsoft Field Engineers as they talk about best practices on how to cleanup databases after an
upgrade procedure.
For a list of the sample scripts to use, see Post-upgrade scripts

For additional information on how to handle cleanup of a database, see Post Upgrade Cleanup - Missing Server
Side Dependencies
Deploy software updates for SharePoint Server 2016
and 2019
Microsoft periodically releases software updates for SharePoint Server 2016 and 2019. The following articles
provide information about the software update process for SharePoint Server 2016 and 2019.
Articles about software updates for SharePoint Server 2016 and 2019
CONTENT DESCRIPTION
Software updates overview for SharePoint Server 2016 Provides an overview of the software update process for
Install a software update for SharePoint Server 2016 Learn how to install a software update on servers in a
SharePoint farm.
Video demo of Zero Downtime Patching in SharePoint Server Learn how to patch a software update on servers in a
2016 SharePoint farm.
SharePoint Server 2016 zero downtime patching steps Learn the steps to patch a software update on servers in a
SharePoint farm.
Video: How to enable Remote Windows PowerShell to use Learn how to enable remote Powershell to use with servers in
with SharePoint Server a SharePoint farm.
NOTE
The articles above reference SharePoint Server 2016 but the same process is applicable to SharePoint Server 2019.
Software updates overview for SharePoint Server
2016 and 2019
Administrators update SharePoint Server 2016 or SharePoint Server 2019 to deploy or update assemblies that
provide functionality and to upgrade databases. A successful update follows a methodical approach that minimizes
interruptions in service. Review information in this article to learn about the process before you begin the update
process.
NOTE
This article applies to both SharePoint Server 2016 and SharePoint Server 2019.
Before you begin software updates

Before you begin the software update process, review the following information about permissions, hardware
requirements, and software requirements.
Account permissions and security settings in SharePoint Server 2016
Information in this article is for all IT professionals who maintain SharePoint Server 2016. However, specific
instructions to install a software update are intended for IT professionals who have to deploy software updates on
a farm of servers that host SharePoint Server 2016.
Information in this article applies to the following products:
SharePoint Server 2016 Language Packs
SharePoint Server 2019 Language Packs
NOTE
The process that installs software updates in stand-alone environments of SharePoint Server 2016 or 2019 is a simpler
process than the process that installs software updates in a server farm and does not require all the steps that are required
for a server farm.
Micrososft releases Public Updates each month. The first update is known as the language independent update.
This update will often include both feature and security fixes. It is also known as the 'sts-x-none' patch.
The second type of patch is the language dependent patch. This patch covers all language packs, including English
installations. This patch is required to fully update the farm, although may not be released every month. This patch
is also known as the 'wssloc' patch.
IMPORTANT
If a lanaguage dependent patch isn't available for a given month, update to the latest previosuly available language
dependent patch. For example, if applying the July 2019 Public Update for SharePoint Server 2016, install the language
indepdendnt update for July 2019 and the language dependent patch from April 2019. If you do not install the language
dependent patch, you may encounter missing or incorrect functionality.
Software update terminology

To understand how to implement software updates in SharePoint Server 2016, it is important to understand the
terminology for the core components.
Term Definition Comment
Public Update (PU) A PU is a rollup update that contains all

previous critical on-demand hotfixes to
date. Additionally, a PU contains fixes
for issues that meet the hotfix
acceptance criteria. These criteria may
include the availability of a workaround,
the effect on the customer, the
reproducibility of the problem, the
complexity of the code that must be
changed, or other reasons.
patch A compiled, executable installer file that

contains updates to one or more
products. Examples of packages are the
executable (.exe) files that you
download to install a service pack,
public update (PU), or hotfix. Packages
are also known as MSI files.
software update A software update is any update,

update rollup, service pack, feature
pack, critical update, security update, or
hotfix that is used to improve or to fix a
software product that is released by
Microsoft Corporation.
upgrade Process by which you change an In SharePoint Server 2016, for build-to-
environment to use a newer version of build upgrades, you can use either in-
software. You can upgrade to a minor place or database-attach methods. For
release, such as an update or patch, or version-to-version upgrade, only
to a major release. An upgrade to a database-attach is supported. For more
minor release is called a build-to-build information about version-to-version
upgrade. An upgrade to a major release upgrade, see Overview of the upgrade
is called a version-to-version upgrade. process to SharePoint Server 2016. For
an overview of the steps for in-place
and database-attach upgrade for build-
to-build upgrades, see Install a software
update for SharePoint Server 2016
For a complete list of terminology about software updates, see Description of the standard terminology that is
used to describe Microsoft software updates.
Software update features
SharePoint Server 2016 has features that facilitate the end-to-end software update experience. Some of these
features are as follows:
Backward compatibility between an updated services farm and non-updated content farm.
There is full support for automatic updates that use Windows Server Update Services (WSUS ), Windows
Update, and Microsoft Update.
NOTE
An automatic update copies the binary files to the farm servers, but you must complete the software update by
running the upgrade on the servers.
Administrators can use the SharePoint Central Administration website or Microsoft PowerShell to monitor
the status of an update.
Software update process

The process that deploys updates in a SharePoint Server 2016 environment is a two-phase process: patching and
build-to-build upgrade.
Each phase has specific steps and results. It is possible to postpone the build-to-build upgrade phase.
Cau t i on
Although we try to ensure the highest level of backwards compatibility, the longer you run in such a state, the
greater the chance of finding a case where farm behavioral issues might occur.
Patch phase
The patch phase involves running the update on each SharePoint Server in the farm. There may be one or two
patches that are required to be run, the language independent update and language dependent update.
NOTE
No specific order of installation in a farm is required.
The patch phase has two steps, the patch deployment step and the binaries deployment step. During the patch
deployment step, new binary files are copied to the server running SharePoint Server 2016. Services that use files
that the patch has to replace are temporarily stopped. Stopping services reduces the requirement to restart the
server to replace files that are being used. However, in some instances you have to restart the server.
The second step in the patch phase is the binaries deployment step. In this step, the installer copies support
dynamic link library (.dll) files to the appropriate directories on the server that is running SharePoint Server 2016.
This step ensures that all the web applications are running the correct version of the binary files and will function
correctly after the update is installed. The update phase is complete after the binaries deployment step.
The next and final phase to deploy software updates is the build-to-build upgrade phase. This phase modifies
database schemas, updates objects in the farm, and updates site collections.
Build-to -build upgrade phase
The build-to-build upgrade phase requires the administrator to run the Configuration Wizard or psconfig from
the SharePoint Managmeent Shell.
NOTE
No specific order of execution of the Configuration Wizard in a farm is required.
After you finish the patch phase, you must complete the update installation by starting the build-to-build upgrade
phase. The build-to-build upgrade phase is task intensive and, therefore, takes the most time to finish. The first
action is to upgrade all the SharePoint processes that are running. After you upgrade the processes, the databases
are crawled and upgraded. After you complete a farm upgrade on one server, you have to complete the process on
all other servers to maintain compatibility.
Software update strategy

NOTE
The information in this section is valid if you farm is not in a high availability (HA) environment. If you have an HA
environment, follow the instructions at SharePoint Server 2016 zero downtime patching steps.
The update strategy that you select is based primarily on one of the following factors:
The amount of downtime that is acceptable to install the update.
The additional staff and computing resources that are available to reduce downtime.
As you determine 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.
Software update deployment cycle

The cycle that is used for upgrading SharePoint Server 2016 farms and servers also applies to deploying software
updates, which are a subset of an upgrade phase. We recommend that you use the update cycle in the following
illustration as a guide to deploy software updates.
Step 1: Learn about requirements for software updates
During this phase of the cycle, you learn about requirements 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 for SharePoint Server 2016. 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 the strategy that you want to use to update the farm. Depending on your requirements, you can use
one of the following strategies:
In-place
Database-attach
For more information about the update strategy to use, see Install a software update for SharePoint Server 2016
Downtime reduction
Research and assess the options that are available to reduce downtime. First, check for 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 additional time into your schedule. Consider
using read-only content databases and doing parallel upgrades to reduce downtime.
Common issues
Identify and address common issues such as missing or out-of-date dependencies and lack of space on the servers
where you will install the update.
Step 2: Prepare for software updates
To prepare for the software update, document the environment and plan an update strategy to ensure that the
update will go as planned in the expected downtime window.
Document the environment
You document the environment 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 Microsoft 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 ExportIPFSAdminObjects command to collect and export InfoPath
administrator deployed forms only.
Plan the update strategy
During the Learnd 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
The two final requirements for the update strategy are a communication plan and an update schedule.
It is important to communicate with site owners and users about what to expect during an upgrade. An
administrator should inform users about downtime and the risk that the upgrade may take longer than expected or
that some sites may need some rework after upgrade.
Create a benchmark schedule for update operations that contains the start times of operations that are 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.
Stop the upgrade and resume operations in the non-upgraded farm.
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 ready for updates
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 ready for
updates:
Solutions
Features
Site definitions
Web Parts
Step 3: Test software update deployment
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.
Build a test farm
Build a test farm that represents 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 in 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.
Step 4: Implement software updates
The update strategy that you use determines 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
Deploy customizations
Use solutions whenever possible so that you can deploy individual files or components.
Reduce downtime
Reduce downtime by using techniques such as read-only databases and update parallelism.
Monitor progress
The refined techniques that you use to monitor the software update in the test environment apply when you
deploy the update in the production environment. Use the Upgrade and Migration page in Central
Administration to monitor available status indicators. 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, when you use
Central Administration to monitor updates, you can identify farm servers that you must update.
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 No hyperlink

any action to be taken by the
administrator.
Installation required Farm server is missing an .msi file that Hyperlink to the Patch Deployment
is set to mandatory for all farm servers State page
or has a patch level below the individual
farm-wide effective patch version.
Upgrade in progress Farm server is currently undergoing an Hyperlink to the Upgrade Status page
upgrade operation.
Upgrade available Farm server is running in backward- Hyperlink to the Upgrade and
compatibility mode. Migration page
Upgrade required Farm server is outside the backward- Hyperlink to the Upgrade and
compatibility mode range with one or Migration page
more databases.
Upgrade blocked If an upgrade is available and any farm Hyperlink to the Patch Deployment
server requires installation, the State page
remaining servers that do not require
installation will be set to this status
unless they are currently undergoing an
upgrade.
Installed Indicates that no action is required Not applicable
Missing/Required Displayed if a product is required on Not applicable

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 Not applicable

on each server
Superseded Displayed if an update is no longer Not applicable

required on a server because a newer
patch supersedes it
Log files and PowerShell commands are other tools to monitor the update process.
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, communicate this information
to users of the farm.
Step 5: Validate the success of software updates

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 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. These issues mainly occur during a version-
to-version upgrade. Look for the following issues:
Unghosted files that are, ASP.NET (.aspx) pages that a user has modified within the site collection, and now
behave differently than expected or have rendering issues caused by recent upgrades of the files on the
server.
User interface version mismatch
HTML and XHTML compliance
Other 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 you can troubleshoot minor issues and then resume or restart the update. Be prepared to roll back
the update if you cannot resolve issues.
Install a software update for SharePoint Server 2016
Before you begin

requirements, software requirements, and update processes.
Software updates overview for SharePoint 2016
Prepare to deploy software updates for SharePoint 2016
NOTE
While the steps in this article refer to SharePoint Server 2016, they are applicable to SharePoint Foundation 2013, SharePoint
Server 2013, and SharePoint Server 2019 unless otherwise noted.
To perform the procedures in this article, you must have the following memberships and roles:
securityadmin fixed server role on the SQL Server instance
db_owner fixed database role on all databases that are to be updated
Local administrator on the server on which you run the Microsoft PowerShell cmdlets
Before you install an update, verify that the following conditions are satisfied:
All front-end web servers are load balanced together and are in rotation with the load balancer.
All farm servers are operating properly. For Search, you can view server status by using the Microsoft
PowerShell cmdlet Get-SPEnterpriseSearchStatus or by going to Central Administration > Manage Service
Applications > Search_service_application_name.
All databases are active and operating properly.
Do not start the update if any of the preceding conditions are not satisfied. Resolve all issues before you continue.
SharePoint Server 2016 can handle certain upgrade failures after the patching phase finishes. However, if the
build-to-build upgrade fails, you might have to restore from a backup. Therefore, make sure that you perform a full
backup before you start the update process. After the restore is complete, you can resume the update. Completed
tasks do not run again. For more information, see the following resources:
Test and troubleshoot an upgrade to SharePoint 2016
Determine the update strategy

Before you start to deploy a software update, verify that the update strategy that you plan to use is optimal for your
SharePoint Server 2016 environment. There are several factors, such as downtime reduction, cost, and complexity
that determine the strategy to use to deploy a software update. For more information about how the database-
attach process works, see the diagrams in Overview of the upgrade process from SharePoint 2013 to SharePoint
Server 2016.
NOTE
Certain links in this article go to content that is about version-to-version upgrade rather than build-to-build upgrade.
However, the general process is similar for the two types of upgrade. For example, the database upgrade phase is essentially
the same for build-to-build upgrade and version-to-version upgrade.
Monitor installation progress

Monitor the process that deploys updates to verify that the update is proceeding as planned. There might be issues
that block the update or that 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 page in Central Administration as the primary tool to
view product and patch installation status, data status, and update status in real time.
After Setup runs, you can also view the log files and use Microsoft PowerShell to check installation progress.
Initial state
The following illustration shows the farm topology that is used as an example for each patching scenario that is
described in this article.
When you are ready to continue, perform only one of the following procedures in this article to install the update:
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

In this scenario you disable incoming requests to the front-end web servers, thus effectively shutting down the
entire farm. Then you install the update on all the farm servers. This strategy combines the update and the build-to-
build upgrade phase that is described in the Software updates overview for SharePoint Server 2016 section of
Overview of the upgrade process from SharePoint 2013 to SharePoint Server 2016.
The following illustration shows the steps that are required to install the update on the farm. You can use the
illustration as a guide as you go through the steps in the procedure that follows ("To install an update without
backward compatibility").
To install an update without backward compatibility

1. Notify users that the farm will not be available while you are installing the update.
2. Remove all 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.
3. Run the update executable file to install the update on the application server that hosts Central
Administration (APP -1).
4. Run the update executable file to install the update on all other application servers that host Search
components (APP -2). To do this, perform the procedure Host Search components which appears later in this
article, and then return to the next step in this procedure. Do not run the SharePoint Products Configuration
Wizard on these servers at this time.
5. Review the upgrade log files to verify that all the application servers were updated successfully.
The upgrade log file and the upgrade error log file are located at %COMMONPROGRAMFILES%\Microsoft
Shared\Web server extensions\16\LOGS. Upgrade log file names are in the following format:
Upgrade-YYYYMMDD -HHMMSS -SSS.log, where YYYYMMDD is the date and HHMMSS -SSS is the time
errors and warnings in a shorter file that is named Upgrade-YYYYMMDD -HHMMSS -SSS -error.log.
6. Log on to the first web server (WEB -1).
7. Run the executable file to install the update on the web server.
8. Run the executable file to install the update on the remaining web servers (WEB -2, WEB -3, and WEB -4).
9. Review the upgrade log files to verify that all the web servers were updated successfully.
10. Run the SharePoint Products Configuration Wizard on the Central Administration server (APP -1). This will
upgrade the configuration database and upgrade each content database. For information about how to run
the wizard, see Install SharePoint Server 2016 across multiple servers in the article Install SharePoint 2013
across multiple servers for a three-tier farm.
11. Run the SharePoint Products Configuration Wizard on the other application servers.
12. Run the SharePoint Products Configuration Wizard on the first web server (WEB -1).
NOTE
Run the configuration wizard to ensure that if an update fails for a specific server, the error is not propagated to the
other web servers. For example, a failed update for one server could make the update fail for one or more site
collections.
13. Repeat the preceding step for each remaining web server.
14. Verify update completion and success. For more information, see Verify database upgrades in SharePoint
Server 2016.
15. 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.
16. Notify users that the farm is available. You are finished installing the update and using this article.

This scenario takes advantage of the backward compatibility of SharePoint and the deferred upgrade feature to
reduce the farm 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 database content is being upgraded.
This update scenario uses two phases to install the update on farm servers. These phases are as follows:
1. Install the update on the farm servers.
2. Perform a build-to-build upgrade to complete the patching process.
IMPORTANT
During the update phase, the farm can continue to be in production with minimal downtime. However, during the build-to-
build upgrade phase, the farm will be unavailable. If users 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, see the Software updates overview for SharePoint Server 2016 section in Overview of the
upgrade process from SharePoint 2013 to SharePoint Server 2016.
Update phase
illustration as a guide as you go through the steps in the following procedure, "To install the update".
To install the update

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. On each web server that is out of the load-balancing rotation (WEB -1 and WEB -2), run the executable file to
install the update. Do not run the SharePoint Products Configuration Wizard on these servers. Verify that
these web servers were updated successfully by reviewing the upgrade log files.
The upgrade log file and the upgrade error log file are located at %COMMONPROGRAMFILES%\Microsoft
Shared\Web server extensions\16\LOGS. Upgrade log file names are in the following format:
Upgrade-YYYYMMDD -HHMMSS -SSS.log, where YYYYMMDD is the date and HHMMSS -SSS is the time
errors and warnings in a shorter file that is named Upgrade- YYYYMMDD -HHMMSS -SSS -error.log.
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.
4. Add the updated web servers (WEB -1 and WEB -2) back into the load-balancing rotation.
5. On each web server that is out of the load-balancing rotation, run the executable file to install the update. Do
not run the SharePoint Products Configuration Wizard on these servers at this time. Verify that both of the
web servers were updated successfully by reviewing the upgrade log files.
6. Add the updated web servers (WEB -3 and WEB -4) back to the load-balancing rotation.
7. Install the update on all application servers that host Search components (APP -1 and APP -2). To do this,
perform the procedure Install a software update for SharePoint Server 2016 which appears later in this
article, and then return to the next step in this procedure. Do not run the SharePoint Products Configuration
Wizard at this time.
8. If your farm has additional application servers that do not host Search components, run the update
executable file to install the update on these servers. Do not run the SharePoint Products Configuration
9. Review the upgrade log files to verify that these application servers were updated successfully.
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 steps that upgrade the farm servers to finish the patching process. During this
process, the sites that are being upgraded will not be available to users.
Use the preceding illustration as a guide to follow the steps in the following procedure.
IMPORTANT
Monitor the status of the upgrade on each server before you upgrade the next server in the sequence. We recommend that
you create a backup of the farm before you begin to 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 (step 8 in the following 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 3 and 4 in the following
procedure) each time and then resume farm operation (step 8 in the following procedure). You can repeat
the process over successive outage windows until you upgrade all content 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 SQL Server volume at a time. Start the upgrade for
each content database that will occur in parallel several minutes apart to prevent lock contention as the
upgrade process starts. In addition, limit the number of content databases that you upgrade on a single web
server or application server. Each additional upgrade process will consume a relatively large amount of
resources. The typical number of content databases that you can upgrade per web server 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 server 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 PowerShell cmdlets to upgrade specific service
applications. Notes for a software update might indicate that you have to upgrade a specific service so that it
will continue to operate after patching. This applies to a service that cannot operate in backward
compatibility mode, for example.
You can create a short offline period to upgrade the service without having to upgrade the complete farm.
The additional PowerShell cmdlets to upgrade specific service applications should be in the notes if this is
required.
3. (Optional) Use the PowerShell Upgrade-SPContentDatabase cmdlet to upgrade each content database.
For more information, see Upgrade-SPContentDatabase.
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. On the Central Administration server (APP -1), do one of the following:

Run the following commands at the PowerShell command prompt:
cd \Program Files\Common Files\Microsoft Shared\web server extensions\16\bin

PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd
secureresources
IMPORTANT
The SharePoint Products Configuration Wizard also starts an immediate upgrade of the configuration database and all 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 or PSConfig (as in step 4 of this procedure) on the
remaining application server (APP -2).
6. Run the SharePoint Products Configuration Wizard or PSConfig (as in step 4 of this procedure) on the web
servers (WEB -1 to WEB -4).
2013.
8. Add the upgraded web servers (WEB -1 to WEB -4) back into rotation in the load balancer.
You are finished installing the update and using this article.
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. You
install the update on a new farm and route user traffic to the new farm after updates are complete.
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 Upgrade content databases from SharePoint 2013 to
Use the preceding illustration as a guide to follow the recommended steps in the following procedure.
To install the update by using the database-attach method
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 Create the SharePoint 2016 farm for a database attach upgrade.
NOTE
If the original farm uses a database mirror, configure mirroring after you deploy 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, 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 Upgrade content databases from
SharePoint 2013 to SharePoint Server 2016 and Run a farm that uses read-only databases in SharePoint Server.
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.
NOTE
Steps 4 through 14 do not apply to SharePoint Foundation 2013, SharePoint Server 2016, and SharePoint Server
2019.
4. If you are patching the User Profile Service service application database, you must export the User Profile
Synchronization Service encryption key from the old database and then import the key to the new database.
This key is also known as the Microsoft Identity Integration Server (MIIS ) key, the Synchronization Service
encryption key, and the Forefront Identity Manager 2010 (FIM 2010) key. If you do not export and then
import the key correctly, the Synchronization Service will not start. To export the encryption key, complete
these steps:
5. Use farm administrator credentials to log on to the computer that contains the old User Profile Service
service application database.
6. Open the Command Prompt window, and then change to the following folder:
%Program Files%\Microsoft Office Servers\15.0\Synchronization Service\Bin\
7. Type the following command, and then press Enter:
miiskmu.exe /e <Path>
Where <Path> is the full path of the file to which you want to export the key.
8. Back up the content databases on the existing farm. For more information, see Plan for backup and recovery
in SharePoint Server.
9. To import the encryption key, perform these steps:
10. Use farm administrator credentials to log on to the computer that contains the new User Profile Service
11. Attempt to start the User Profile Synchronization service. Because you have not yet imported the encryption
key, the service will not start. Confirm that the service did not start by using the ULS log or by making sure
that the status of the service is Stopped.
miiskmu.exe /i <Path> {0E19E162-827E -4077-82D4-E6ABD531636E }
Where <Path> is the full path of the file to which you exported the key.
14. (Optional) To check that the encryption key was imported correctly, at the command prompt, type the
following command, and then press Enter:
miiskmu.exe /c {0E19E162-827E -4077-82D4-E6ABD531636E }
15. Restore the content databases to the new database server.
16. Create service applications on the new farm for each existing service application in the old farm.
Duplicate all the settings from your existing farm.
17. Use the database-attach method to create the databases on the new farm. For more information, see
Upgrade databases from SharePoint 2013 to SharePoint Server 2016 and Attach and restore read-only
content databases in SharePoint Server.
18. Verify that there are no issues with the new farm.
19. 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.
20. Allow time for users to switch from cached DNS, and then decommission the old farm.
2016.
Install a software update on servers that host Search components

Perform the procedures in this section only when they are pointed to from other procedures in this article. This
includes the following procedures which are in this section:
Update servers that host Search components during farm downtime
Update servers that host Search components with minimal downtime
Determine server availability groups for update with minimal downtime
1. Pause the Search service application by typing the following commands at the PowerShell command prompt:
$ssa=Get-SPEnterpriseSearchServiceApplication
2. On each server that hosts one or more Search components, stop the Search-related Windows services in the
following order:
3. SPTimerV4
4. OSearch16
5. SPSearchHostController
IMPORTANT
Verify that each service is stopped before you stop the next service.
6. On each server that hosts one or more Search components, run the update executable file to install the
update.
7. On each server that hosts one or more Search components, start the Search-related Windows services in
the following order:
9. OSearch16
10. SPTimerV4
11. Verify that all Search components become active after the update by typing the following command at the
Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where {$_.State -ne "Active"} | fl
Rerun the command until no Search components are listed in the output.
6. Resume the Search service application by typing the following command at the PowerShell command prompt:
Resume-SPEnterpriseSearchServiceApplication -Identity $ssa
7. Verify that the farm is crawling updated content and able to index new and modified documents. To do this, you
can add or modify an item in a site collection, perform a crawl for the Local SharePoint sites content source, and
then perform a search for the item and verify that it appears in the search results.
1. Divide the servers that host Search components into two availability groups to minimize downtime during
their update and build-to-build upgrade. (As long as one of the groups is active and healthy, the farm can
serve queries and crawl and index content.) For instructions about how to divide the servers into two
availability groups, see the procedure Determine server availability groups for update with minimal
downtime later in this article.
2. Pause the Search service application by typing the following command at the PowerShell command prompt:
3. On each server in server availability group 1, stop the Search-related Windows services in the following
order:
4. SPTimerV4
5. OSearch16
IMPORTANT
7. On each server in availability group 1, run the update executable file to install the update.
8. On each server in availability group 2, stop the Search-related Windows services in the same order that was
prescribed for stopping them for availability group 1. Again, it is important to verify that each service is
stopped before you stop the next service.
9. On each server in availability group 1, start the Search-related Windows services in the following order:
11. OSearch16
12. SPTimerV4
13. Wait until all Search components associated with availability group 1 are active. To determine which
components are active, type the following command at the PowerShell command prompt:
Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where {$_.State -eq "Active"} | fl
Rerun the command until all Search components that are associated with availability group 1 are listed in the
output.
9. On each server in availability group 2, start the Search-related Windows services in the same order that was
prescribed for starting them for availability group 1.
output.
11. Resume the Search service application by typing the following command at the PowerShell command prompt:
12. Verify that the farm is crawling updated content and able to index new and modified documents. To do this, you
can add or modify an item in a site collection, perform a crawl for the Local SharePoint sites content source, and
then perform a search for the item and verify that it appears in the search results.
1. Start a SharePoint 2016 Management Shell on any server in the farm.
2. Determine the primary Search administration component and the server that hosts the component by
typing the following commands at the PowerShell command prompt:
Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where { (($_.State -ne "Unknown") -and ($_.Name -match
"Admin")) } | ForEach {if (Get-SPEnterpriseSearchStatus -SearchApplication $ssa -Component $_.Name -Primary) {
Get-SPEnterpriseSearchTopology -SearchApplication $ssa -active | Get-SPEnterpriseSearchComponent -identity
$($_.Name) } }
3. Determine the set of servers in availability group 1. These servers must fulfill the following three requirements:
The set must contain one or more, but not all, of the following types of Search components:
Content processing component
Query processing component
Analytics processing component
Crawl component
Index component
The set must contain one or more, but not all, of the index components for each index partition.
The set must contain a Search administration component that is not the primary component that was
identified in step 2 in this procedure.
4. Determine the set of servers in availability group 2. This set must contain all remaining servers that host Search
components, including the server that hosts the primary Search administration component that was identified in
step 2 of this procedure.
Install a software update on servers that host Distributed Cache

Prior to restarting a server from running a software update or Configuration Wizard, you must stop Distributed
Cache to prevent unallocated cache fractions. Follow the process outlined here to gracefully shut down Distributed
Cache.
IMPORTANT
Do not use Stop-SPDistributedCacheServiceInstance -Graceful as this will terminate Distributed Cache prior to the
cache being transferred to another server in the farm.
Troubleshoot software updates on servers that host Search componenets

Issue: After an update you may no longer have proper registry key or file system permissions.
Resolution: Run the following command:
See also
Other Resources
SharePoint updates
Video demo of Zero Downtime Patching in
Overview
One of the new features in SharePoint Server 2016 is Zero Downtime patching.
Zero Downtime patching doesn't demand any server downtime while patching a SharePoint Server 2016 farm,
but does require that your farm be set up in a Highly Available (HA) configuration (so that SharePoint roles are
hosted on more than one server). That way, patching can be done in batches where certain of the redundant
servers are taken out of load balancing, patched, replaced, and tested for soundness before the other servers
follow through the same process.
There is a two-step process to patch a server in a SharePoint Server 2016 farm. First, you install the binaries of the
patch to each server, this is called the patch phase. Second, after you finish the patch phase, you must complete the
update installation by starting the build-to-build upgrade phase.
During Zero downtime patching, users can add and edit files and use search just as at any other time, accessing the
servers still handled by the load balancer. Likewise, though the database schemas may differ between the patched
and unpatched sides of the farm, SharePoint Server 2016 operates in a backward-compatible mode, and its
databases are able to properly function, until patching completes.
This SharePoint tutorial explains how to patch a SharePoint Server 2016 HA farm from beginning to end,
including the installation of the binary files on all servers, and the build-to-build (B2B ) upgrade itself.
IMPORTANT
During the demonstration, the graceful shut down of Distributed Cache Service was discussed and demonstrated. The
environment depicted is a test farm and the process shown is NOT how a customer should do this in a live environment.
Important: If you are actively using areas such as Microblogs, Newsfeeds etc. you will instead need to use the
following steps to gracefully shut down the Distributed Cache Service on each Distributed Cache Server during
the patch and upgrade sequence:
Gracefully STOP Distributed Cache Service
$instanceName ="SPDistributedCacheService Name=AppFabricCachingService"
$serviceInstance = Get-SPServiceInstance | ? {($.service.tostring ()) -eq $instanceName -and ($.server.name) -eq
$env:computername}
$serviceInstance.Unprovision()
Start Distributed Cache Service
$instanceName ="SPDistributedCacheService Name=AppFabricCachingService"
$serviceInstance = Get-SPServiceInstance | ? {($.service.tostring ()) -eq $instanceName -and ($.server.name) -eq
$env:computername}
$serviceInstance.Provision()
For reference, here is an overview of the steps, however for further detail on SharePoint patching please watch the
video.
1. Remove the Front-end web server (SPWEB01) from the Load balancer.
2. Patch the front-end web server (SPWEB01) by using the STS & WSS Packages.
3. Restart the front-end web server (SPWEB01).
4. Add the front-end web server (SPWEB01) back into the Load balancer.
5. Remove the front-end web server (SPWEB02) from the Load balancer.
6. Patch the front-end web server (SPWEB02).
7. Restart the front-end web server (SPWEB02) computer.
8. Patch the following Application servers: SPAPP01, SPDCH01, and SPSRCH01 in parallel, and then restart
the computers.
9. Patch the following Application servers: SPAPP02, SPDCH02, and SPSRCH02 in parallel, and then restart
the computers.
10. With the front-end web server (SPWEB02) out of the Load balancer (See step 7), Open the SharePoint
2016 Management Shell, and then run following PSConfig command:
secureresources -cmd services -install
NOTE
In the video, syntax is condensed to save time, but the full syntax listed in Step 10 is the recommend one to run.
11. Once the upgrade is complete, add the front-end web server (SPWEB02) back into the Load balancer. Once
the front-end web server (SPWEB02) has been added to the Load balancer, remove the front-end web
server (SPWEB01).
12. On the front-end web server (SPWEB01) computer, run the PSConfig command from step 10.
13. Add the front-end web server (SPWEB01) back into the Load balancer.
14. On the Application server (SPAPP01), run the PSConfig command from Step 10.
15. On the Distributed Cache server (SPDCH01), run the PSConfig command from Step 10.
16. On the Search server (SPSRCH01), run the PSConfig command from Step10.
17. Once the upgrade has completed run the same steps (14-16) on 02 series servers (SPAPP02, SPDCH02,
SPSRCH02).
NOTE
We recommend to test pages throughout to ensure patching and upgrading of servers is complete.
During the video the following Microsoft PowerShell script was used to take Servers out of the Azure Service
Management Internal Load Balancer.
#Remove the SPWEB01 Azure Load Balanced EndPoint
$svc=<"NameYourLBService">
$vmname=<"NameofYourVM">
$epname="TCP-80-80"
Get-AzureVM -ServiceName $svc -Name $vmname | Remove-AzureEndpoint -Name $epname | Update-AzureVM
#Add the SPWEB01 AzureEndpoint back
$ilb="minroleilb"
$prot="tcp"
$locport=80
$pubport=80
$epname="TCP-80-80"
$lbsetname=<"NameYourLB">
Get-AzureVM -ServiceName $svc -Name $vmname | Add-AzureEndpoint -Name $epname -LbSetName $lbsetname -Protocol
$prot -LocalPort $locport -PublicPort $pubport -DefaultProbe -InternalLoadBalancerName $ilb | Update-AzureVM
# Remove the SPWEB02 Azure Load Balanced EndPoint for the patch install and build to build (B2B) phase
$epname="TCP-80-80-2"
#Add for the B2B SPWEB02 AzureEndPoint to ILB
$prot="tcp"
$locport=80
$pubport=80
$epname="TCP-80-80-2"
# B2B for SPWEB01::::: Phase Remove the SPWEB01 Azure Load Balanced EndPoint
$svc=<"NameYourLBService">
$epname="TCP-80-80"
#Add the SPWEB01 AzureEndpoint back
$ilb="minroleilb"
$prot="tcp"
$locport=80
$pubport=80
$epname="TCP-80-80"
For additional information about the Microsoft PowerShell for Azure cmdlets, see Get-AzureVM and Add-
AzureEndpoint
Related Topics
Video: How to enable Remote Windows PowerShell to use with SharePoint Server
SharePoint Server zero downtime patching steps

Zero downtime patching (ZDP ) is available in SharePoint Server 2016 and SharePoint Server 2019. Let users
keep working on, saving, and searching documents as you patch your SharePoint Server 2016 or SharePoint
Server 2019 farm.
NOTE
The steps in this article and information about Zero downtime patching also apply to SharePoint Server 2019.
Zero downtime patching is a method of patching and upgrade developed in SharePoint Online. It was made to let
administrators patch the service at the same time as users kept using their subscriptions. In other words, this
tested method is designed to allow patching while people actively work with their files, and search crawls and
renders results, on the SharePoint Server farm. That's what's meant by 'zero down time'.
A couple of things to note as we discuss ZDP (we'll talk about these elements later in the article).
Your ZDP experience could be enhanced by using MinRole in SharePoint Server 2016 or 2019, but
MinRole is not a requirement.
Why could MinRole help?
Your farm must leverage high availability (HA) to reap the benefits of ZDP. A highly available SharePoint
Server 2016 farm is a requirement for ZDP.
Why is High Availability required?
It's important to remember that the goal of ZDP is uptime for your users, so, in this article, all the decisions
involved in patching and rebooting your farm will be made with that bias in mind.
IMPORTANT
Even if all the servers in your SharePoint Server 2016 or 2019 farm were configured to use the 'Custom' role, you can still
manually configure a highly available farm. There are documents on TechNet that will help you construct highly available
farms, and the principals of fault tolerance (having redundant hardware) and high availability (having systems and software
in place to support failover and continuation of uptime) are the same. Be aware that in more complex Highly Available or
Custom farms, you should take special care to patch the Search servers in a way that supports HA, for example, patch one
index replica at a time and never patch or upgrade index replicas from the same partition at the same time.
The ZDP Process

This example uses ZDP against a SharePoint Server 2016 farm set up using MinRole. The example environment
looks like this:
To break this structure down, two web-front ends (WFEs) (SPWeb01 and 02) are connected to a load balancer,
both are fielding requests at this point. There are two Application Servers (SPApp01 and 02), two Distributed
Cache servers (SPDCH01 and 02) and two Search Servers (SPSRCH01 and 02). Behind this structure, but not
directly included in the ZDP process, is a SQL Server cluster (for example, SQL Server Always-On).
Ideologically, you can draw a line through the middle of the farm in this diagram, from top to bottom. On one side
of the line are all the servers ending in '01' (column 1), and the redundant servers in '02' are on the other (column
2). We'll make use of this dual construction to keep the farm up for users while patching.
For the most part, everything you do on one side of the line (to the 01 servers) you'll exactly repeat for 02. Of all
the steps involved in the relatively simple, two phase ZDP process, those taken with the WFEs (SPWeb01 and 02)
are the most complex. We'll start there.
NOTE
General information on Software Updates for SharePoint Server 2016 can be found here. Notice that the article links out to
documentation on permissions settings for SharePoint Server 2016. Review these articles as needed, and remember that
part of patching involves database updates. If you've changed SQL Server permissions for SharePoint accounts post-
installation, for example, you'll need to review these articles.
Make sure you've rebooted and tested your WFEs before you take either out of the load balancer to avoid
situations where the WFE to be patched first is taken out of rotation, and other WFEs don't handle the resulting
load. All servers in the farm should be fresh from a reboot and healthy before you patch. Also, consider stopping
Search crawls and Profile Imports during the upgrade or patch window.
IMPORTANT
You should enable the side-by-side file copy process before you Upgrade. Running in side-by-side ensures that all the web
front ends in the farm serve the same static content during the upgrade, even if static files on a given WFE are being
upgraded or replaced. Side-by-side is built in to PSCONFIG but must be enabled. This feature makes sure users have the
same experience of the sites when browsing SharePoint and working on their files, even while file-system files are being
changed and updated.
To enable side-by-side upgrade capabilities, you will need to open SharePoint 2016 Management Shell and run the following
commands on all your SharePoint servers:
$webapp = Get-SPWebApplication <webappURL>
$webapp.WebService.EnableSideBySide = $true
$webapp.WebService.update()
Please note that administrators can opt out of side-by-side by setting the 'enableSideBySide' value to $false. Be aware that
this could impact what users see when browsing. They may see upgraded UI in one browse, and not, in another, or may
experience issues if, for example, javascript files are being changed or upgraded at the time of their browse.
Phase 1 - Patch install

The first phase is getting the patch binaries on the servers and installing them there.
1.
Take the first WFE (SPWeb01) out of the load balancer and patch it with the 'STS' and 'WSS' packages.
Reboot the server when patching is done.
Return the server to rotation in the load balancer.
2.
Take the second WFE (SPWeb02) out of the load balancer and patch it with the 'STS' and 'WSS' packages.
Reboot the server when patching is done.
Leave this server out of the load balancer until the entire upgrade is complete.
NOTE
If you aren't running the upgrade in a maintenance window and the farm has a lot of load, you can return this WFE
to the network load balancer until you're ready to run PSCONFIG.
3.
For each of SPApp, SPDCH, and SPSRCH in column 1, patch with 'STS' and 'WSS' packages.
Reboot them when they're done. (The work sent by SPWeb01 will fall on servers in column 2).
4.
Now you repeat the 'patch and reboot' for column 2. For each of SPApp02, SPDCH02, and SPSRCH02 in
column 2, patch with 'STS' and 'WSS' packages.
Reboot them when they're done. (As you can see, work sent by SPWeb01 will now fall on servers in column
1.)
Phase 2 - PSCONFIG upgrade
Every node in the SharePoint Server 2016 farm has the patches installed, and all have been rebooted. It's time to
do the build-to-build upgrade.
NOTE
During the ZDP process, you can run Upgrade-SPContentdatabase to reduce the overall time it will take to finish running
PSCONFIG. Consider this if you have a large number of databases, or select large databases.
1.
Return to the WFE that is out of load-balanced rotation (SPWeb02), open the SharePoint 2016
Management Shell, and run this PSCONFIG command:
PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd
After the command completes, return this WFE (SPWeb02) to the load balancer. This server is fully patched
and upgraded.
TIP
The last step in the PSCONFIG process ensures that updates to the User Interface (UI) are copied from the /layouts
folder to a version-specific folder. This is part of the side-by-side UI update that lets users browsing your farm have
one experience of the UI until the upgrade is completed, and you're ready to switch over to the new interface.
To be sure the side-by-side copy was successful, check the associated logfile. By default, this is located under:
C:\program files\common files\Microsoft shared\web server extensions\16\logs. (Your root drive letter may vary!)
If, for some reason, PSCONFIG didn't successfully copy UI files, please run this command to manually copy them
Copy-SidebySideFiles!
2.
Remove SPWeb01 from the load-balancer. > Open theSharePoint 2016 Management Shell and run the
same PSCONFIG command:
Return this WEF (SPWeb01) to the load balancer. It's also fully patched and upgraded now.
Both WFEs are patched and upgraded. Move on to the remainder of the farm, but be sure that the required
Microsoft PowerShell commands are run one server at a time and not in parallel. That means, for all of
column 1, you'll run the commands one server at a time. Then you'll run them, one server at a time, for
servers in column 2 with no overlapping. The end-goal is preserving uptime. Running the PSCONFIG
commands serially is the safest and most predictable means of completing the ZDP process, so that's what
we'll do.
3.
For all remaining servers in column 1 (SPApp01, SPDCH01, SPSRCH01), run the same PSCONFIG
command in the SharePoint 2016 Management Shell. Do this on each server, one at a time, until all servers
in column 1 are upgraded.
IMPORTANT
Remember to gracefully remove the Distributed Cache before running PSCONFIG and add the Distributed Cache to
the server again after completion.
4.
For all remaining servers in column 2 (SPApp02, SPDCH02, SPSRCH02), run the same PSCONFIG
command in the SharePoint 2016 Management Shell. Do this on each server, one at a time, until all servers
in column 2 are upgraded.
IMPORTANT
Remember to gracefully remove the Distributed Cache before running PSCONFIG and add the Distributed Cache to
the server again after completion.
IMPORTANT
After all servers have been through PSCONFIG successfully, remember to run the SharePoint 2016 Management
Shell command below to switch to the new user interface files and complete the side-by-side process:
$webapp.WebService.SideBySideToken = <current build number in quotes, ex: "16.0.4338.1000">
$webapp.WebService.update()
Now you're done, and the farm has been fully upgraded while in use and without downtime.
Why could MinRole help?

When you talk about ZDP you should also address the concept of MinRole. MinRole is an option in the installation
of SharePoint Server 2016. It breaks the configuration of a farm into roles like Front End (WFE ), Application
Server (App), Distributed Cache (DCache), Search, or Custom (for custom code or third party products). This
configuration will give you four servers on average - two WFEs, two App servers, two DCache servers, and two
Search servers.
By default, WFEs are tweaked for low -latency, and the App servers for high-throughput. Likewise, bundling search
components so that calls don't have to leave the box on which they originate makes the Search servers work more
efficiently. One of the biggest benefits of MinRole is that it builds-in fault tolerance.
Why is High Availability required?

HA is a broad topic in SharePoint. There are entire whitepapers and articles about it online, such as this
documentation via TechNet. To simplify the concept, at least for this article, realize that ZDP (and also MinRole)
originated in SharePoint Online (SPO ). In SPO, virtualized servers have redundancies built in, so that two of the
same role of server from the same SharePoint farm won't live on the same host or rack. This makes SPO more
fault-tolerant. You can model the same situation by having two of each SharePoint Server role on separate hosts
on different racks in your own datacenter, with a shared router or cabling between racks to make for quicker
communication. You can also simply have two physical servers for each SharePoint Server role set up in a test
environment (choosing separate power bars for each half of your farm, and making sure that routing between the
set of servers is fast and, if possible, bypasses wider network traffic for lower latency).
The goals here are high availability and fault tolerance. That means top priorities are separating the roles across
racks or servers, making sure you have two of every role, facilitating quick network traffic between these two tiers,
and making sure your set up has systems in place to monitor and automatically failover database servers. In terms
of manually installing services in SharePoint (as when choosing the 'Custom' role) it is important that the services
have redundancy inside the farm. For example, Distributed Cache is clustered, your farm has multiple WFEs, you
set up Application and Search servers in pairs. That way, in the event that one server has a serious issue, the other
can handle user load.
In examples used here, I draw out physical servers to make concepts easier to grapple with. When it comes time to
plan for ZDP, you should draw out your own environment, wherever it lives (complete with rack names/numbers,
and server names where each SharePoint Server role can be found). This is one of the quickest ways to isolate any
violations of the goals of role redundancy and fault tolerance that might have snuck into your setup, no matter the
size your setup may be.
Related Topics
Video demo of Zero Downtime Patching in SharePoint Server 2016
Video: How to enable Remote Windows PowerShell
to use with SharePoint Server

By using Remote Microsoft PowerShell, you can make the administration of a SharePoint farm easier. Watch the
following video to learn how to enable it.

about performing an upgrade to SharePoint 2013.
Downloadable resources about upgrade

Download the following content for information about upgrade.
CONTENT DESCRIPTION
SharePoint 2013 - Upgrade Process model Describes the steps in the process for a database-attach
upgrade.
SharePoint 2013 - Test Your Upgrade Process model See a visual display of information about how to test the
upgrade process.
SharePoint 2013 Upgrade Worksheet Use this worksheet to record information about your
environment while you test upgrade.
Articles about upgrade

CONTENT DESCRIPTION
Get started with upgrades to SharePoint 2013 Find resources to help you understand how to upgrade
databases and site collections from SharePoint 2010 Products
to SharePoint 2013.
Plan for upgrade to SharePoint 2013 Find resources about how to plan to upgrade from
SharePoint 2010 Products to SharePoint 2013.
Test and troubleshoot an upgrade to SharePoint 2013 Find resources about how to test and troubleshoot an
upgrade from SharePoint 2010 Products to SharePoint 2013.
Upgrade databases from SharePoint 2013 to SharePoint Find resources to help you perform the steps to upgrade
Server 2016 databases from SharePoint 2010 Products to SharePoint
2013.
Upgrade site collections to SharePoint 2013 Find out how to upgrade a site collection to SharePoint 2013.
Advanced upgrade scenarios for SharePoint 2013 Learn how to upgrade to SharePoint 2013 in advanced
scenarios, such as from Office SharePoint Server 2007 or
Windows SharePoint Services 3.0, from FAST Search Server, or
when using content type syndication.
Get started with upgrades to SharePoint 2013

appropriately. These articles help you understand how the process of upgrading from SharePoint 2010 Products
to SharePoint 2013 works. These articles also include overviews of how to upgrade service applications.
understanding upgrade for SharePoint 2013.
Downloadable resources about upgrade to SharePoint 2013

Download the following content for information about upgrade.
CONTENT DESCRIPTION
SharePoint 2013 Products Preview - Upgrade Process model Describes the steps in the process for a database attach
upgrade
Articles about understanding upgrade

CONTENT DESCRIPTION
What's new in SharePoint 2013 upgrade Find out about new requirements, approaches, and features
that are available for upgrading to SharePoint 2013.
Overview of the upgrade process from SharePoint 2010 to Get a visual overview of the steps involved in performing an
SharePoint 2013 upgrade.
Upgrade overview videos for SharePoint 2013 View this series of short overview videos to understand how
upgrade works for SharePoint 2013.
Services upgrade overview from SharePoint 2010 to SharePoint 2010 Products included several service
SharePoint Server 2013 applications, some of which have databases that can be
upgraded when you upgrade to SharePoint 2013. Find out
which service application databases can be upgraded and
what steps that you must take before, during, and after
upgrade for your service applications.
Upgrade farms that share services (parent and child farms) to In SharePoint Server 2010, it was possible to configure parent
SharePoint 2013 farms and child farms to share services. In such an
environment, the parent farm hosts one or more service
applications from which one or more child farms consume
services. Learn how to approach upgrading these
environments to SharePoint 2013.
Best practices for upgrading from SharePoint 2010 to Get off to the right start - review these best practices for
SharePoint 2013 testing and performing an upgrade to SharePoint 2013.
CONTENT DESCRIPTION
Review supported editions and products for upgrading to Understand the requirements for upgrade. And if you are
SharePoint 2013 planning to change SKUs or products during upgrade,
understand which upgrade paths are supported.
See also
Other Resources
Plan for upgrade to SharePoint 2013
What's new in SharePoint 2013 upgrade

SharePoint 2013 does not support in-place upgrade for an existing environment. You must use the database-attach
upgrade method to upgrade your databases to a new environment that is based on SharePoint 2013. Also, to
provide more flexibility to farm administrators and site administrators, the upgrade process has changed to
separate upgrade of the software and databases from upgrade of the sites.
In-place upgrade of the farm is not supported

An upgrade to SharePoint Server 2010 or SharePoint Foundation 2010 provided an option to install the new
version over the earlier version on the same hardware. This was called an in-place upgrade. During this process,
the complete installation (both databases and sites) was upgraded in a fixed order. Although this was a simple
method, in-place upgrade presented problems in performance and control for a farm administrator. There was no
way to control the order in which content is upgraded, and a failure in a particular site collection could stop the
whole process.
The database-attach upgrade method offers more flexibility, more control, and a better success rate. Therefore, in-
place upgrade is not supported for SharePoint 2013 and database-attach upgrade is the only supported upgrade
method.
To use a database attach upgrade, you complete the following tasks:
1. Create and configure a new farm that is separate from the old farm
2. Copy the content and services databases to the new farm
3. Upgrade the data and sites
You can upgrade the content databases in any order and upgrade several databases at the same time to speed up
the overall process.
For more information, see Overview of the upgrade process from SharePoint 2010 to SharePoint 2013.
Database-attach upgrade is available for some service application

databases
For the SharePoint 2013, you can use the database attach upgrade method to upgrade the following service
application databases:
Business Data Connectivity
This service application is available for both SharePoint 2013 and SharePoint Foundation 2013.
Managed Metadata
This service application is available only for SharePoint 2013.
PerformancePoint
Secure Store
User Profile (Profile, Social, and Sync databases)
For more information, see Services upgrade overview from SharePoint 2010 to SharePoint Server 2013.
Deferred site collection upgrade

In SharePoint 2010 Products, farm administrators use either the in-place upgrade process to upgrade sites
immediately, or the command line to upgrade all sites at the same time or individually. In SharePoint 2013, farm
administrators can now allow site collection owners to upgrade their sites to the new user interface on their own
timeline. The commands for upgrading a site collection are on the Site Settings page in the Site Collection
Administration section. There are also Microsoft PowerShell cmdlets to upgrade site collections to the new user
interface. For more information, see Plan for site collection upgrades in SharePoint 2013, Upgrade a site collection
to SharePoint 2013 and Manage site collection upgrades (SharePoint 2013 Products).
Site collection health checker

Site collection owners or administrators can use a site collection health checker to detect any potential issues with
their site collections and address them before they upgrade sites to the new version. The checker is available after
upgrade also to detect any health issues on an ongoing basis. Note that some issues can be repaired automatically,
but others require manual steps to repair. During a site collection upgrade, if the checker finds issues that can be
repaired automatically, they are repaired at that time. For more information, see Run site collection health checks in
SharePoint 2013.
Upgrade evaluation site collections

In SharePoint 2013, the upgrade of the software and data was separated from the upgrade of the site. This means
that the sites can truly remain running in SharePoint 2010 mode until a site owner or administrator explicitly
upgrades the site to the new user interface. Site collection owners can request an evaluation site, which is a
separate copy of the site, to review the new interface and functionality. After they have reviewed the site and made
necessary changes in their original site, they can then upgrade their sites to the new version. Evaluation sites are
set to automatically expire and be deleted. For more information, see Plan for site collection upgrades in
SharePoint 2013, Upgrade a site collection, and Manage site collection upgrades (SharePoint 2013 Products).
Notifications for life-cycle events

An email message and a status bar notification in a site collection notifies site collection owners when an upgrade
is available. Site collection owners can create an evaluation site from email and control the expiration and deletion
of that site by using email also. A status bar notification in the site collection also informs all users if a site is in
read-only mode. For more information, see Plan for site collection upgrades in SharePoint 2013 and Manage site
collection upgrades (SharePoint 2013 Products).
Throttles for site collection upgrade

To make sure that site collection upgrades do not cause an outage on your farm, there are throttles built in at the
web application, database, and content level. This means that even if 100 site collection owners decide to upgrade
their site collections at the same time, only some are run at the same time, and the rest are put into a queue to run
later. For more information, see Plan for site collection upgrades in SharePoint 2013 and Manage site collection
upgrades (SharePoint 2013 Products).
True "SharePoint 2010" instead of visual upgrade

Visual upgrade in SharePoint 2010 Products lets site owners and administrators see what their site would be like in
the new user interface. However, it is not a true preview because the site itself has already been upgraded to the
new functionality. Consequently, some Web Parts or other elements do not display correctly.
SharePoint 2013 can host sites in both SharePoint 2010 and SharePoint 2013 modes. The installation contains
both SharePoint 2010 and SharePoint 2013 versions of the following types of elements:
Features, site templates, site definitions, and Web Parts
The directories on the file system are duplicated in both the 14 and 15 paths, for example:
IIS support directories:
_Layouts, _Layouts/15
_ControlTemplates, _ControlTemplates/15
Solution deployment, which lets legacy solutions work in 2010 mode
Note that existing SharePoint 2010 Products solutions can be deployed to SharePoint 2013 and continue to
function for 2010 sites, usually without requiring any changes.
Because of these directories, you can continue hosting unupgraded sites in an upgraded environment until all site
collections are ready to upgrade. For more information, see Plan for site collection upgrades in SharePoint 2013.
Log files now in ULS format

The format of the upgrade, upgrade error, and site upgrade log files now comply with the Unified Logging System
(ULS ) conventions for easier review. For more information, see Verify database upgrades in SharePoint 2013.
Overview of the upgrade process from SharePoint
2010 to SharePoint 2013

To upgrade from SharePoint 2010 Products to SharePoint 2013, you use the database-attach method to
upgrade. In the database-attach method, you first create and configure a SharePoint 2013 farm. Then you copy
the content and service application databases from the SharePoint 2010 Products farm, and then attach and
upgrade the databases. This upgrades the data to the new version. Site owners can then upgrade individual site
collections.
This article helps you understand the upgrade sequence so that you can plan an upgrade project. To get
detailed steps for an upgrade, see Upgrade content databases from SharePoint 2010 to SharePoint 2013 and
Upgrade a site collection to SharePoint 2013.
IMPORTANT
This article applies to both SharePoint Foundation 2013 and SharePoint 2013, except for information about how to
upgrade My Sites and specific service applications that are only in SharePoint 2013.
Watch the SharePoint 2013 Upgrade: Overview video
Create the SharePoint 2013 farm

The first stage in the upgrade process creates the new SharePoint 2013 farm:
1. A server farm administrator installs SharePoint 2013 to a new farm. The administrator configures farm
settings and tests the environment.
2. A server farm administrator sets the SharePoint 2010 Products farm to read-only so that users can
continue to access the old farm while upgrade is in progress on the new farm.
Copy the SharePoint 2010 Products databases
service application databases from the SQL Server instance on the SharePoint 2010 Products farm.
SharePoint 2013 farm and sets the databases to read-write on the new farm.
Upgrade SharePoint 2010 Products databases and service
applications
SharePoint Server 2010 and SharePoint Foundation 2010
SharePoint Server 2010 only
2. A server farm administrator creates a web application on the SharePoint 2013 farm for each web
application on the SharePoint 2010 Products farm.
Figure: Upgrade the databases by using Windows PowerShell
Upgrade SharePoint 2010 Products site collections

The final stage in the upgrade process is to upgrade the site collections. In SharePoint 2013, site owners are in
charge of upgrading their sites. The upgrade process for My Sites is slightly different from for other types of
site collections.
Upgrade My Sites
IMPORTANT
A server farm administrator upgrades the My Site host and then individual users can upgrade their My Sites
or the farm administrator can upgrade them by using PowerShell. The following illustration shows four stages
for the My Site host and My Sites during the upgrade process.
NOTE
details and steps, read Upgrade a site collection to SharePoint 2013.
Upgrade other SharePoint 2010 Products site collections

Owners of all other site collections can start to upgrade their sites as soon as they see a notification on their
site's home page that the new version is available. The following illustration shows four stages for a site
collection during the upgrade process.
Stages in upgrading site collections
1. The site owner runs the site collection health checks to determine readiness for upgrade. The site owner
addresses issues before they continue with the next step.
2. Optionally, the site owner requests an upgrade evaluation site collection. A timer job runs to create the
site collection and the site owner receives an email message when the evaluation site collection is ready.
The site owner previews the new user interface. After several days or weeks, the evaluation site
collection expires and is deleted by a timer job.
A server farm administrator can determine the length of time before expiration.
3. When the site owner is ready, the site owner starts the upgrade process. The site collection health
checks are run again automatically. The site owner must address issues before upgrading. If health
checks return no issues, the upgrade starts.
4. When upgrade is complete, the site owner sees the Upgrade Status page that contains the status and a
link to the upgrade logs. The site owner reviews the site to make sure that everything works correctly.
NOTE
upgrade them. For details and steps, read Upgrade a site collection to SharePoint 2013.
See also
Other Resources
Upgrade databases from SharePoint 2010 to SharePoint 2013
Upgrade overview videos for SharePoint 2013

The following six videos (each video is less than five minutes) can help you understand how to upgrade to
SharePoint 2013.
Overview: SharePoint 2013 upgrade process

This video provides a brief overview of the upgrade process for SharePoint 2013 (video 1 of 6).
Watch the SharePoint 2013 Upgrade: Overview video
Related resources
RESOURCE DESCRIPTION
Overview of the upgrade process from SharePoint 2010 to Learn about how to upgrade databases, service applications,
SharePoint 2013 My Sites, and site collections to SharePoint 2013.
Phase 1: Create the SharePoint 2013 farm

This video provides a quick explanation of how to create a farm for use in an upgrade to SharePoint 2013 (video 2
of 6).
Watch the SharePoint 2013 Upgrade: Phase 1 video
Related resources
Create the SharePoint 2013 farm for a database attach Create and configure a SharePoint 2013 farm so that you can
upgrade upgrade databases from SharePoint 2010 Products.
Phase 2: Copy the databases to the new farm

This video provides a quick explanation of how to copy SharePoint 2010 databases to a SharePoint 2013 farm for
upgrade (video 3 of 6).
Related resources
Copy databases to the new farm for upgrade to SharePoint Copy SharePoint 2010 Products content and service
2013 databases to a SharePoint 2013 farm so that you can upgrade
the data to SharePoint 2013.
Phase 3: Upgrade the service applications

This video provides a quick explanation of how to upgrade service applications to SharePoint 2013 (video 4 of 6).
Related resources
Upgrade service applications to SharePoint 2013 Upgrade service applications (Business Connectivity Services,
SharePoint 2013.
Phase 4: Upgrade content databases

This video provides a quick explanation of how to upgrade content databases to SharePoint 2013 (video 5 of 6).
Related resources
Upgrade content databases from SharePoint 2010 to Learn how to upgrade content databases from SharePoint
SharePoint 2013 2010 Products to SharePoint 2013.
Migrate from classic-mode to claims-based authentication in Convert SharePoint 2010 Products or SharePoint 2013 classic-
SharePoint 2013 mode web applications to claims-based authentication or
create new claims-based web applications in SharePoint 2013.
Phase 5: Upgrade site collections

This video provides a quick explanation of how to upgrade site collections to SharePoint 2013 (video 6 of 6).
Related resources
Upgrade a site collection to SharePoint 2013 Learn how site collection administrators can preview a copy of
their sites in SharePoint 2013 mode, and then upgrade their
sites.
See also
Services upgrade overview from SharePoint 2010 to

have databases that can be upgraded when you upgrade from SharePoint Server 2010 to SharePoint Server
2013:
IMPORTANT
The content in this article about the Business Data Connectivity service application applies to both SharePoint Foundation
2013 and SharePoint Server 2013. Other services are available only in SharePoint Server 2013.

Search
In SharePoint Server 2010, the Search service application Administration database contains settings for the
Search service application such as content sources, crawl rules, start addresses, server name mapping, and
federated locations. You can upgrade a Search service application Administration database from
SharePoint Server 2010 to SharePoint Server 2013 by using a database attach approach.
You cannot use the database attach approach to upgrade any other search databases, such as crawl
databases or property databases. (These databases are re-created when you perform a full crawl in the new
farm.) Also, the upgrade process does not preserve or upgrade logical components of the SharePoint
Server 2010 farm topology. After you perform the upgrade, you must manually re-create a topology as
appropriate for the requirements of the organization.
The Secure Store Service uses a database to store information. This database must be upgraded as part of
a services database attach upgrade. You have to upgrade the data for this service application so that any
passwords.
NOTE
My Sites are not available in SharePoint Foundation 2010 or SharePoint Foundation 2013.
Search Administration Search_Service_Application_DB_ ID
User Profile: Profile and Social databases User Profile Service Application_ProfileDB_ ID
User Profile Service Application_SocialDB_ ID
User Profile Service Application_SyncDB_ ID
The steps to upgrade these service application databases are included in Upgrade content databases to
upgrade:
Excel Services
You can enable this service by using the Farm Configuration Wizard, but you must make sure that you re-
create all trusted data connections. For more information, see Manage Excel Services trusted data providers
templates. For more information, see Configure InfoPath Forms Services (SharePoint Server 2010).
Office Web Apps
If you installed Office Online with SharePoint 2010 Products, Office Online will not be available after you
upgrade to SharePoint 2013 Products. You must deploy Office Online Server and then connect SharePoint
2013 Products it to after the content databases are upgraded. You do not have to wait until the site
collections are upgraded because Office Online Server supports both the 2010 and 2013 site collection
modes in SharePoint 2013 Products. For more information, see Office Web Apps.
See also
Other Resources
Upgrade farms that share services (parent and child
farms) to SharePoint 2013

Some services in SharePoint 2010 Products can be shared across multiple farms. A services farm hosts services
such as Business Data Connectivity service, Search, and User Profiles that other farms consume. When you
upgrade to SharePoint Server 2013, you first upgrade the services farm, and then upgrade the farms that consume
those services. This article describes how to upgrade farms that share services.
Before you begin, make sure that you have reviewed the overall upgrade process described in Overview of the
upgrade process from SharePoint 2010 to SharePoint 2013.
NOTE
This article applies to both SharePoint Server 2013 and SharePoint Foundation 2013. However, only the Business Data
Connectivity service is available in SharePoint Foundation 2013. The other services are available only in SharePoint Server
2013.
Process for upgrading farms that share services

To upgrade farms that share services, you follow these steps:
1. Starting status: services farm and content farm running SharePoint 2010 Products
In your SharePoint 2010 Products environment, you have one or more content farms that use services from a
services farm. The services farm provides cross-farm services and Enterprise Search indexes the content on the
content farm.
Pre-upgrade state: 2010 content and services farms
2. Create the SharePoint Server 2013 services farm

Create a new farm to host the service applications, and install and configure SharePoint Server 2013.
Create 2013 Services farm
3. Upgrade the Search service application and optionally index the content in the SharePoint 2010
Products content farm
Upgrade the Search service application administration database and run a search crawl against the SharePoint
2010 Products content farm to create the index.
4. Upgrade the other service applications.

Upgrade the databases for the other service applications.
Upgrade other service applications
5. Switch the services connection to SharePoint Server 2013 services farm
Change the SharePoint 2010 Products content farm to consume services from the SharePoint Server 2013
services farm and retire the SharePoint 2010 Products services farm.
Switch connection to 2013 services farm
6. Create SharePoint Server 2013 content farm

Create a new farm to host content, and install and configure SharePoint Server 2013.
Create 2013 content farm
7. Upgrade and index the 2013 content farm
Upgrade the data in the SharePoint Server 2013 content farm. Configure it to consume services from the
SharePoint Server 2013 services farm. Index the SharePoint Server 2013 content farm.
Upgrade and index the 2013 content farm
8. Retire the SharePoint 2010 Products content farm

Now that the SharePoint Server 2013 content farm uses services from a SharePoint Server 2013 services farm,
you can retire the SharePoint 2010 Products content farm.
Retire 2010 content farm
If more than one content farm uses services from the SharePoint 2010 Products services farm, repeat steps 5
through 7 for the remaining content farms until all farms are upgraded and are using services from SharePoint
Server 2013. Except for the order of steps in this process, the process to create and upgrade each farm follows the
database-attach upgrade steps outlined in Upgrade content databases from SharePoint 2010 to SharePoint 2013.
This process does not explain how to upgrade site collections. For more information about how to upgrade sites,
see Upgrade a site collection to SharePoint 2013.
See also
Other Resources
Best practices for upgrading from SharePoint 2010 to
SharePoint 2013

To increase your chances of a successful and faster upgrade to SharePoint 2013, follow these best practices to test
and complete an upgrade.
Best practices for testing upgrade

To understand your environment before you upgrade it, and to plan for the time that an upgrade will require, you
should try one or more trial upgrades. The goal of testing upgrade is to find and fix issues and develop confidence
in the outcome before the real upgrade. To develop an accurate trial of the upgrade process from SharePoint 2010
Products to SharePoint 2013, follow these best practices:
1. Know what is in your environment. Do a full survey first.
Document the hardware and software in your environment, where server-side customizations are installed
and used, and the settings that you need. This helps you plan the trial environment and also helps you
recover if upgrade fails. A worksheet is available to record information about your environment.
2. Make your test environment as similar as possible to your real environment.
If possible, use the same kind of hardware and use the same settings, the same URLs, and so on to
configure it. Minimize the differences between your test environment and your real environment. As you
introduce more differences, you are likely to spend time resolving unrelated issues to make sure that they
will not occur during the actual upgrade.
3. Use real data.
Use copies of your actual databases to run the tests. When you use real data, you can identify trouble areas
and also determine upgrade performance. You can also 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. Make sure that you find issues with the different kinds and sizes of sites, lists, libraries, and
customizations that are present in your environment. If you cannot test all data because of storage
concerns, try going over the data in several passes, removing the old trial copies before going on to the
next batch.
4. Run multiple tests.
A single test can tell you whether you will encounter big problems. Multiple tests will help you find all the
issues that you might face and help you estimate a more accurate timeline for the process. By running
multiple tests, you can determine the following:
The upgrade approaches that will work best for your environment
The downtime mitigation techniques that you should plan to use
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 the errors and are ready to upgrade
your production environment.
5. Do not ignore errors or warnings.
Even though a warning is not an error, a warning could lead to problems in the upgrade process. Resolve
errors, but also investigate warnings to make sure that you know the results that a warning might produce.
6. Test the upgraded environment, not just the upgrade process.
Check your service applications and run a search crawl and review the log files.
For more information about how to test upgrade, see Use a trial upgrade to SharePoint 2013 to find potential
issues and the SharePoint 2013 Products Preview - Test Your Upgrade Process model.
Best practices for upgrading to SharePoint 2013

To guarantee a smooth upgrade from SharePoint 2010 Products to SharePoint 2013, follow these best practices:
1. Ensure that the environment is fully functioning before you begin to upgrade.
An upgrade does not solve problems that already exist in your environment. Therefore, make sure that the
environment is fully functioning before you start to upgrade. For example, if you are not using web
applications, 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 2013
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 estimated upgrade schedule.
2. Perform a trial upgrade on a test farm first.
Copy your databases to a test environment and perform a trial upgrade. Examine the results to determine
the following:
Whether the service application data was upgraded as expected
The appearance of upgraded sites
The time to allow for post-upgrade troubleshooting
The time to allow for the upgrade process
Try a full search indexing crawl. For more information, see Use a trial upgrade to SharePoint 2013 to find
potential issues.
3. Plan for capacity.
Ensure that you have enough disk, processor, and memory capacity to handle upgrade requirements. For
more information about system requirements, see Hardware and software requirements for SharePoint
2013. For more information about how to plan the disk space that is required for upgrade, see Plan for
performance during upgrade to SharePoint 2013 and Performance planning in SharePoint Server 2013
4. Clean up before you upgrade
Issues in your environment can affect the success of upgrade, and unnecessary or very large amounts of
data can affect upgrade performance for both databases and site collections. If you don't need something in
your environment, consider removing it before upgrade. If there are issues detected, try to resolve them
before you start to upgrade. For more information, see Clean up an environment before an upgrade to
SharePoint 2013.
5. Back up your databases.
Perform a full backup of your databases before you upgrade. That way, you can try upgrade again if it fails.
6. Optimize your environment before upgrade.
Be sure to optimize your SharePoint 2010 Products environment to meet any limits or restrictions, either
from your business or governance needs or from the SharePoint 2013 boundaries and limits before
upgrade. This will help reduce errors during the upgrade process and prevent broken lists or sites after
upgrade. For more information about limits in the product, see Software boundaries and limits for
SharePoint 2013. For more information about large lists and how to address the lower limit on site
collections, see Clean up an environment before an upgrade to SharePoint 2013.
7. (Optional) Set the original databases to read-only if you want to keep your original environment available
while you upgrade.
If you expect a long outage period while you upgrade, you can set the databases in the original
environment to read-only. Users can continue to access the data but cannot change it. For more
information, see Upgrade content databases from SharePoint 2010 to SharePoint 2013.
8. After upgrade, review the Upgrade Status page and upgrade logs to determine whether you must address
issues. 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. Verify all the sites and test them before you consider
the upgrade finished. For more information, see Verify database upgrades in SharePoint 2013 and Review
site collections upgraded to SharePoint 2013.
9. Defer upgrade for site collections until you can get updated customizations to support 2013 mode.
If you wait until the customizations are available, you can complete the initial upgrade of database and
services without significantly affecting use of the existing sites in 2010 mode.
10. Make sure that the appropriate service pack or update is applied to your 2010 environment. If you are
using remote blob storage (RBS ) in your environment, you must be running Service Pack 1 for SharePoint
2010 Products in your environment before you start the upgrade process.
See also
Other Resources
Review supported editions and products for
upgrading to SharePoint 2013

When you plan an upgrade process, make sure that you verify that the intended upgrade path is supported. This
article describes the editions and products that are supported and unsupported to upgrade to SharePoint Server
2016.
Be aware that in-place upgrade is not supported for upgrades to SharePoint 2013. This includes upgrades across
editions, such as from SharePoint Foundation 2013 to SharePoint Server 2016. For more information, see What's
new in SharePoint 2013 upgrade.
IMPORTANT
Upgrade from a pre-release version of SharePoint 2013 to the release version of SharePoint 2013 is not supported. > Pre-
release versions are intended for testing only and should not be used in production environments. Upgrading from one pre-
release version to another is also not supported.
Supported topologies
For SharePoint 2013, the only upgrade method is the database-attach upgrade method. Because this method
upgrades the databases instead of installing in place over an existing environment, you can attach the databases
from a stand-alone installation to server farm (Complete) installation if you want to expand your environment.
Figure: Upgrade to either stand-alone or server farm (Complete) topologies
Before you create your new SharePoint 2013 environment and attach and upgrade the databases, determine the
type and size of the environment that you need.
Physical topology guidance
The SQL Server topology — in addition to network, physical storage, and caching considerations — can
significantly affect system performance. To learn more about how to map your solution design to the farm size and
hardware that will support your business goals, see Performance planning in SharePoint Server 2013. For more
information about requirements, see Hardware and software requirements for SharePoint 2013.
Supported editions for upgrade

The following table lists the editions available for SharePoint Server 2010 and the supported and unsupported
ending editions when you upgrade to SharePoint Server 2016. Note that in-place upgrade is not supported.
Database-attach upgrade is the only supported upgrade method.
STARTING EDITION SUPPORTED ENDING EDITION UNSUPPORTED ENDING EDITION
SharePoint Server 2010, Standard SharePoint Server 2013, Standard SharePoint Server 2013, Enterprise
edition edition edition
You can convert to Enterprise edition
after upgrade.
SharePoint Server 2010, Enterprise SharePoint Server 2013, Enterprise SharePoint Server 2013, Standard
Edition edition edition.
SharePoint Server 2010, Trial edition SharePoint Server 2013, Trial edition SharePoint Server 2013, full product
(either edition)
You can't upgrade directly from a trial
version to the full product, but you can
convert to the full product after
upgrade.
Supported cross-product upgrades

The following table lists which Microsoft server products can be upgraded to SharePoint Foundation 2013 or
SharePoint Server 2013. Note that in-place upgrade is not supported. Database-attach upgrade is the only
supported upgrade method.
STARTING PRODUCT SUPPORTED ENDING PRODUCTS UNSUPPORTED ENDING PRODUCT
SharePoint Foundation 2010 SharePoint Foundation 2013

SharePoint Foundation 2013 SharePoint Server 2013
SharePoint Server 2010 SharePoint Server 2013 SharePoint Foundation 2013
SharePoint Server 2013 SharePoint Server 2013 SharePoint Foundation 2013
Search Server 2010 SharePoint Server 2013 SharePoint Foundation 2013
Project Server 2010 with SharePoint Project Server with SharePoint Server
Server 2010, Enterprise Edition 2013, Enterprise Edition

In order to have a successful upgrade to SharePoint 2013, you must plan for the upgrade. This section contains
articles that help you plan and prepare for upgrading from SharePoint 2010 Products to SharePoint 2013.
To understand how the upgrade process works, see the articles in Get started with upgrades to SharePoint 2013.
how to plan for upgrade.
CONTENT DESCRIPTION
Determine strategy for upgrade to SharePoint 2013 Understand how to minimize downtime and plan for special
cases during an upgrade to SharePoint 2013.
Create a plan for current customizations during upgrade to Learn how to identify and evaluate the customizations in your
SharePoint 2013 environment, and determine whether you will upgrade them,
and how.
Plan for site collection upgrades in SharePoint 2013 Plan to upgrade site collections to SharePoint 2013. Plan for
upgrade evaluation sites, notifications, and throttling.
Plan for performance during upgrade to SharePoint 2013 Understand upgrade performance and how to plan for the
space and time that is required to upgrade to SharePoint
2013.
Create a communication plan for the upgrade to SharePoint Create a plan to coordinate and communicate with the
2013 upgrade team, site owners and users, and stakeholders.
Clean up an environment before an upgrade to SharePoint Make sure that your environment is in a healthy state, and
2013 delete unnecessary items before you upgrade to SharePoint
2013.
See also
Other Resources

When you upgrade your environment to SharePoint 2013, you want to limit how much downtime that users
experience. You might also have a special case that you must address during upgrade. This article describes how to
minimize downtime and work with these special cases.
In addition to the information in this article, make sure that you read Review supported editions and products for
upgrading to SharePoint 2013 to understand exactly which upgrade situations are valid and lead to successful
upgrades.
How to minimize downtime during upgrade

The following table lists the techniques that you can use during upgrade to reduce the time that users cannot
access their content or to potentially increase upgrade performance.
Read-only databases You can use read-only databases to continue to provide read-only access to content
during the upgrade process. For this approach, you set the databases to read-only on the original farm while
the upgrade is in progress on another farm. This method reduces perceived downtime for users. Also, if you
encounter a problem with upgrade, you can restore the read-only farm to read-write and restore access to
users while you rework your plans before you try upgrade again.
Parallel database upgrades 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
results in faster overall upgrade times for your environment. However, you must monitor the progress and
your servers to make sure that the performance is acceptable, and for large databases, parallel upgrades can
be slower than single upgrades.
For more information about upgrade performance, see Plan for performance during upgrade to SharePoint
2013 and Use a trial upgrade to SharePoint 2013 to find potential issues.
The instructions for using these techniques are included in Upgrade content databases from SharePoint 2010 to
SharePoint 2013.
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 how to approach upgrade for each case.
CASE UPGRADE APPROACH
Upgrading an environment that uses forms-based Additional steps are required to upgrade when you are using
authentication? forms-based authentication. For more information, see
Configure forms-based authentication for a claims-based web
application in SharePoint Server.
CASE UPGRADE APPROACH
Upgrading very large databases? In general, very large databases — especially 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. For more information about how long upgrade might
take for your environment, see Plan for performance during
upgrade to SharePoint 2013.
Upgrading from the server products in the Office 2007 Use a database attach upgrade method to upgrade to
release? SharePoint 2010 Products, and then upgrade to SharePoint
2013.
Upgrading from SharePoint Foundation 2010 to SharePoint Attach and upgrade the content databases from SharePoint
2013? Foundation 2010 to SharePoint 2013.
Changing languages? You have two choices, depending on whether a single site or
your whole environment is changing languages:
To change the multiple user interface (MUI) 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 available. Wait for the new language packs to be
released before you try to upgrade those sites. To change the
installation language for your environment, set up your new
environment in the new language, and then attach and
upgrade your databases in the new language.
See also
Other Resources
Plan for performance during upgrade to SharePoint 2013
Create a plan for current customizations during
upgrade to SharePoint 2013

If you have extensively customized your sites based on SharePoint 2010 Products, you must determine how you
want to handle your customizations when you upgrade to SharePoint 2013. 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.
Identify customizations in your environment

As part of an 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 SharePoint 2013 to find
potential issues.
Evaluate the customizations

After you have identified the customizations, think about the potential upgrade effect of each one. The following
table describes types of customizations and the kind of effect they can have during upgrade.
CATEGORY OF CUSTOMIZATION TYPES OF CUSTOMIZATIONS POTENTIAL EFFECT ON UPGRADE
Visually-affecting Master pages Should not affect database upgrade.

Themes For site upgrades: likely to work well in
Web Pages 2010 mode, but need changes to work
Web Parts in 2013 mode.
Custom JavaScript Test carefully in both modes.
Custom CSS files
Data structure affecting Content types Can affect database upgrade if content
List types or list type names conflict with new
Web templates content or list types in the product, or if
Site definitions templates or definitions are missing.
Non-visually affecting Web services Might not be compatible with

Windows services SharePoint 2013. Test carefully to
HTTP handler determine effect. Be prepared to
HTTP module remove or replace.
Now that you know what customizations that you have, and what type that they are, 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?
Does it do something that you cannot do with standard features in the product?
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 every customization, you can also think about your overall approach for customizations. You can
choose from among these options:
Keep the customizations, don't upgrade the sites You can continue to run the site in 2010 mode in the
upgraded environment. Although you can use this approach to keep the same functionality, you will be
unable to take advantage of the features and capabilities that are available in the new version. Use this
approach only temporarily - eventually you must address the issue (such as before an upgrade to the next
version of the product).
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, change your design slightly if you want, or move to a more manageable
design.
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. In
fact, the site collection health-checker checks for unghosted pages and can reset the pages to the default
versions. 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 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 2013.
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 on MSDN.
Custom site templates If you have custom site templates (a site template that has
been customized and saved as a WSP template) that you want
to continue to use after you upgrade to SharePoint 2013, you
must plan to recreate them in 2013 mode before you upgrade
your site collection. You have to create them again because
custom site templates apply to specific versions and don't
always look or work the same way in subsequent versions.
Furthermore, if you used a template to make various 2010
sites, they could all require manual adjustments to ensure that
they work and render properly in SharePoint 2013.
"Fabulous 40" application templates Microsoft is not creating new versions of these templates.
Environments that contain sites based on these templates can
be upgraded as long as the templates are installed. But there
might be issues when you try to upgrade the site collections.
Make sure that you test each site before you upgrade the
production environment. For more information, see
Troubleshoot database upgrade issues in SharePoint 2013.
Feature Evaluate, then redesign or redeploy if it is necessary.
Workflows and server controls Depends on the solution. Contact the vendor to discover
whether there is an updated solution. If a workflow is
compatible with the new version, redeploy.
Event handler Most event handlers will continue to work without changes.
However, if the code for the event handler makes calls to APIs
which were deprecated, you will have to rewrite it, and then
redeploy it as a feature.
Managed paths (inclusions/exclusions) Re-create inclusions to make sure that you can access all site
collections under those paths.
Exclusions were not used in SharePoint 2010 Products. If you
had any remaining from an earlier version, they do not have
to be re-created.
Themes Re-create your themes following the SharePoint 2013 theming

guidance, or select a new theme available in SharePoint 2013.
For more information, see Branding issues that may occur
when upgrading to SharePoint 2013 [Migrated].
Master pages and CSS files Rework to accommodate the new user experience. For more
information, see Branding issues that may occur when
upgrading to SharePoint 2013 [Migrated].
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 in both 2010 and 2013
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.
Test to verify that there have not been changes to any object
models or Web services that you call from the Web Part.
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 reset the page to the default
template. There is a site collection health rule that will identify
files in this status inside a site collection. There is a link from
that rule to the page where they can reset to 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 with the same provider name (exactly. This
includes the letter case) on a test farm and make sure that it
works correctly.
Custom search solutions that use SQL syntax Rework to use FQL syntax and KQL syntax.
Custom search solutions in SharePoint 2013 do not support
SQL syntax. Search in SharePoint 2013 supports FQL syntax
and KQL syntax for custom search solutions. You cannot use
SQL syntax in custom search solutions using any technologies.
This includes the query server object model, the client object
model, and the Search REST service. Custom search solutions
that use SQL syntax with the index server object model and
the Query web service that were created in SharePoint Server
2010 will not work when you upgrade them to SharePoint
2013. Queries submitted via these applications will return an
error. For more information about how to use FQL syntax and
KQL syntax, see Keyword Query Language (KQL) syntax
reference and FAST Query Language (FQL) syntax reference.
While you are reviewing customizations in your environment, you should also make sure that the environment is
not using any features or elements that are deprecated. For example, Web Analytics from SharePoint 2010
Products are not available in SharePoint 2013 and you should turn them off before upgrading. Also, SQL Server
Search queries are not available in SharePoint 2013. For more information, see Changes from SharePoint 2010 to
SharePoint 2013.
Some methods of deploying customizations might require additional steps in SharePoint 2013. The following table
lists issues that you might encounter for specific methods of deploying customizations.
DEPLOYMENT METHOD RECOMMENDATION
Customizations deployed as MSI files Contact the vendor for updated files. Most likely, you will have
to get a replacement file compatible with SharePoint 2013.
Manually deployed features, files, or changes You can re-deploy them to the equivalent directory in
SharePoint 2013. However, consider packaging them into a
deployable solution package for easier administration.
Sandboxed solutions No special steps. Sandboxed solutions are upgraded with the
content databases.
DEPLOYMENT METHOD RECOMMENDATION
Solution packages Deploy to SharePoint 2013 again. Make sure that you deploy
it to the appropriate directory (/14 or /15), depending on the
version.
Note that you can no longer add partial trust solution
packages to the \bin directory. Any files deployed to the \bin
directory must be full trust. Be sure to test any such solutions
to make sure that deploying them in full trust does not
introduce security vulnerabilities. Also, update any deployment
scripts to make sure that they specify the correct trust level.
For more information, see Install-SPSolution.
Administrator-deployed form templates You must extract them from SharePoint Server 2010 and
redeploy them to SharePoint 2013. For more information, see
Upgrade service applications to SharePoint 2013.
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 were changed.
Cau t i on
Some predefined file types — such as document icons or actions — can be carried forward in a supportable
way, although this does not occur automatically. Do not copy over the old version files as that can cause
other issues, instead, make the same changes to the new version file Modifications to other predefined files,
such as server-side ASPX pages, will be lost during upgrade if you reset to the site template or if you don't
make the same changes in the new version files. Depending on the files that were changed and the extent of
these changes, the upgrade experience can vary significantly.
SharePoint databases that were changed, either by directly changing data or changing the schema. This
includes 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 make sure 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 as described on the following page on MSDN: Developer Best Practices Resource Center.
See also
Other Resources
Deploy custom features to upgraded site collections in SharePoint Server 2013
Plan for site collection upgrades in SharePoint 2013

When you upgrade from SharePoint 2010 Products to SharePoint 2013, site collections are not upgraded when
you upgrade the content databases to a new version. The upgrade process is split to allow site collection
administrators to decide when to upgrade their site collections. For a visual overview of the upgrade process, see
Overview of the upgrade process from SharePoint 2010 to SharePoint 2013.
Server farm administrators can control settings for upgrading site collections, such as settings for upgrade
evaluation site collections, notifications, and upgrade throttling. This article helps you plan the settings to use to
controlling the upgrade of a site collection.
Determine the site collections that farm administrators should upgrade

By default, site collection administrators are in charge of when they upgrade their site collections, and they
perform the upgrade themselves. However, under certain circumstances a farm administrator should probably
perform the upgrade. For example, for sites that meet the following characteristics, the upgrade team at the farm
level should perform tests before upgrade, and potentially upgrade the site collection:
Extremely important sites
If a site is very important to your business, farm administrators should carefully test it before they upgrade
it, and then upgrade it themselves to make sure that the site collection is available for users as quickly as
possible.
Very large sites
By default, if a site collection administrator starts to upgrade a site that is larger than 10 MB or with more
than 10 subsites, the site is added to the upgrade queue, instead of being upgraded immediately. For very
large site collections (larger than 10 GB ), we recommend that you have a farm administrator upgrade the
site collections instead of allowing the site collection administrators to start the upgrade. This way, the farm
administrators can test these sites and then monitor the progress of the upgrade.
Highly-customized sites
Carefully test sites that are based on custom site definitions or that have many other customizations before
you upgrade them. If there are issues with server-side customizations, then farm administrators should
address them, test again, and then perform the upgrade so that they can troubleshoot any issues that occur.
If there are issues with the design of a site, a designer and site collection administrator can address them.
Farm administrators can upgrade sites by using PowerShell. For more information, see Upgrade a site collection to
SharePoint 2013.
Plan settings for upgrade notifications, self-service upgrade, and site

collection creation
When a site collection is available to upgrade, a status bar on a site indicates that site collection administrators can
upgrade it. They can choose to upgrade the site collection then, or be reminded later.
Farm administrators can determine whether to allow site collection administrators to upgrade their sites at all. You
can set a property to prevent the site collection administrators from starting to upgrade, which also turns off the
notification in the status bar. Then you can perform the upgrades yourself by using PowerShell. If you choose to
upgrade some sites centrally, you should have a plan to decide when each site will be upgraded and who will verify
the site after upgrade.
Although administrators can upgrade all site collections immediately, we do not recommend this, for the following
reasons:
You would risk that some sites would have unforeseen issues that you'd have to address. This could create
or prolong an outage.
A high volume of issues could arrive at your helpdesk or troubleshooting process when users start to work
with upgraded sites at the same time.
You can control settings for site collection upgrade and site creation. You can determine the following:
Whether the site collection administrator can upgrade the site collection.
Which mode (2010 or 2013, or both) can be used when a user creates a site collection.
For example, you might want users to keep creating 2010 mode sites for a while, until most of site
collections are upgraded, or you might want to force new sites to be created in 2013 mode so that you don't
have to upgrade them later.
Properties that control site collection upgrade and site creation
PROPERTY DESCRIPTION
SPSite.AllowSelfServiceUpgrade Determines whether an upgrade notification can be set for a

site collection.
Default is true - notifications are set automatically.
If set to false, the upgrade notification will not appear on the
status bar.
SPWebApplication.CompatibilityRange Determines in which modes a site collection can be created.

For example, 2010 mode (14) or 2013 mode (15). The
following ranges are available:
OldVersions Use this range to enable users to create only
2010 mode sites.
NewVersion Use this range to enable users to create only
2013 mode sites.
AllVersions Use this range to enable users to create either
2010 or 2013 mode sites.
You can use these ranges or set your range by using the
New-Object command to set the
Microsoft.Shareoint.SPCompatibilityRange property.
For more information about how to set these properties, see Manage site collection upgrades (SharePoint 2013
Products).
You can also control settings upgrade notifications. You can determine the following:
Whether to add a link to more information from the Upgrading now status bar.
How many days to wait before reminding a site collection administrator about upgrade if they choose
Remind me later on the status bar.
If a user clicks Remind me later, the current date is added to the number that is set for the
UpgradeReminderDelay and the notification is hidden until that new date occurs. For example, if the setting
is 30, then the notification will appear 30 days from the current date.
The following properties control site collection upgrade notifications:
Properties that control upgrade notifications
PROPERTY DESCRIPTION
SPWebApplication.UpgradeMaintenanceLink Adds another link to the upgrading now status message so

that users can follow it, and find more information.
Default is empty.
SPWebApplication.UpgradeReminderDelay Sets the number of days to suspend the upgrade notification

in the status bar after a user clicks Remind me later.
Default is 30 days.
If set to 0, then the upgrade notification is not removed from
the status bar and the notification cannot be set to Remind
me later.
For more information about how to set these properties, see Manage site collection upgrades (SharePoint 2013
Products).
Plan for upgrade evaluation sites

Site collection administrators can request a preview of their site collection. This preview site is called an upgrade
evaluation site collection. An upgrade evaluation site collection enables site collection administrators to see their
site's content in a new, separate copy of the site that is running on the SharePoint 2013. Unlike visual upgrade in
SharePoint Server 2010, the upgrade evaluation site collection is a complete copy of the site collection. It is
separate from the original and has its own URL. Actions that the site collection administrators perform in the
upgrade evaluation site collection do not affect the original site. Both the original site and the upgrade evaluation
site are available for search, and timer jobs that run for all site collections also run on the upgrade evaluation sites.
When a site collection administrator requests an evaluation site collection, the request is added to a timer job
(known as "Create Upgrade Evaluation Site Collections") which runs one time per day. This timer job creates a full
copy of the site collection at a unique URL. Upgrade evaluation site collections are set to expire automatically and
be deleted. The default time for expiration is 30 days, which can be configured by setting a value for the web
application or by changing a value on the evaluation site collection itself.
Farm administrators can choose to prevent users from creating upgrade evaluation sites by setting the
SPSite.AllowSelfServiceUpgradeEvaluation property for a site collection.
Timer jobs create and delete upgrade evaluation sites. The following timer jobs are used:
Timer jobs for upgrade evaluation site collections
JOB NAME DESCRIPTION WHEN RUN
Create Upgrade Evaluation Site Creates upgrade evaluation sites. Runs daily, between 1:00 and 1:30 AM
Collections (job-create-upgrade-eval-
sites)
Delete Upgrade Evaluation Site (job- Deletes expired upgrade evaluation Runs daily, between 1:00 and 1:30 AM
delete-upgrade-eval-sites) sites and sends notifications for sites
near their expiration date.
Upgrade site collections (job-upgrade- Upgrades site collections in the queue Runs every 1 minute
sites) for a content database.
You can decide when and how often these timer jobs run, and you can also run them manually.
How the upgrade evaluation site collections are created
The Create Upgrade Evaluation Site Collections job timer collects the list of site collections that were queued for
evaluation sites, and then copies the sites to new URLs and Site IDs. It also adds the sites to the upgrade queue so
that they will be picked up by the Upgrade Site Collections timer job later. To create the copy of the site:
1. If you have an Enterprise version of SQL Server, the Create Upgrade Evaluation Site Collections job timer
takes a snapshot of the database and reads the data from the snapshot to a destination database (with the
source database being the default target). This doesn't affect the read-only status of the source site
throughout the whole process.
2. For other versions of SQL Server that do not have snapshot capabilities, the Create Upgrade Evaluation
Site Collections job timer backs up a site collection and restores it to a new URL. This makes the source site
read-only for the whole duration of the process.
The Upgrade Site Collections job collects the list of site collections that were queued for upgrade and then
upgrades the queued sites from oldest to newest. The recently added evaluation site is then upgraded (or at least
upgrade is tried).
Plan site collection upgrade throttling and queues

To make sure that site collection upgrades do not cause an outage on your farm, there are throttles built in at the
web application, database, and content level. This means that even if 100 site collection administrators decide to
upgrade their site collections at the same time, only some are run at the same time, and the rest are put into a
queue to run later.
Site collection upgrades are throttled:
Throttle levels for site collection upgrade
MAXIMUM NUMBER OF SITE COLLECTIONS PROPERTY THAT CONTROLS THE

LEVEL THAT CAN BE UPGRADED AT A TIME THROTTLE SETTING
Web application Default is 5 per web application SPWebApplication.SiteUpgradeThrottleS

instance. ettings
Additional requests are queued. AppPoolConcurrentUpgradeSession
Limit
MAXIMUM NUMBER OF SITE COLLECTIONS PROPERTY THAT CONTROLS THE
LEVEL THAT CAN BE UPGRADED AT A TIME THROTTLE SETTING
Content database Default is 10 per content database. SPContentDatabase.ConcurrentSiteUpg

Additional requests are queued. radeSessionLimit
If multiple sites are queued in one
content DB, only one site at a time will
be upgraded by one timer service
instance. That behavior is by design.
The
ConcurrentSiteUpgradeSessionLimit
throttle affects all forms of site
upgrades, including the ones that
happen directly in w3wp (end-user
initiated or in process upgrades) and
administrative tools like Windows
PowerShell (unless the farm
administrator explicitly overrides the
throttle, see below). The timer service
has its own mechanism for distributing
load independent of anything related to
site upgrade. Content databases are
distributed throughout the timer
service instances in the farm, and all
jobs for a given content database are
processed by one and only one timer
service instance, in a serial process. This
means that only one site collection is
being processed by the timer service in
a given content database at a time, but
different timer service instances could
be processing the queue for multiple
different content databases at once.
While for independent reasons the
timer service is not parallelized for
processing a single content database,
the timer service is not the only way
that site collections can be upgraded. If
the site collection is small, it will be
upgraded synchronously in the process
where the upgrade was initiated -
typically w3wp.exe, but it could also be
Windows PowerShell if the -QueueOnly
flag was not specified. The concurrency
limit primarily takes effect in this
scenario.
Content of a site collection (size and Default is that a site that is more than SPWebApplication.SiteUpgradeThrottleS
number of subwebs) 10 MB, or has more than 10 subwebs, ettings UsageStorageLimit and
cannot be upgraded in a self-service SubwebCountLimit
manner by the site collection
administrator, but must be upgraded by
the farm administrator.
The following illustration shows the relationship between the web application and content database upgrade
throttle limits.
Upgrade throttles and the site upgrade queue for web applications and content databases
In this illustration, the content database contains fifteen sites, and all sites were requested to start upgrade.
1. Because of the web application throttle limit, only five sites can start to upgrade for web application 1 -
instance 1 on Web server 1.
2. An additional five sites start to upgrade on web application 1 - instance 2 on Web server 2.
3. Because of the content database throttle, five sites are sent to the upgrade queue to wait their turn.
You can use the default throttling settings, or you can specify your own values for how many site collections can be
upgraded at the same time. Farm administrators can also override throttle settings when they upgrade a site by
using PowerShell. Exercise caution when you change these values and make sure that you verify the settings that
you want to use in a test environment before you implement them in production. If you increase throttling too
much, you could create performance problems in your environment. For example, too many parallel upgrades
could affect site rendering. For information about how to change these settings, see Manage site collection
upgrades.
About site collection modes

In order to make it possible to upgrade site collections separately from upgrading content databases, SharePoint
2013 introduces the concept of site collection "modes" (also known as compatibility levels). Site collections are in
2010 mode in the new environment until they are specifically upgraded to 2013 mode. You can create new site
collections in either mode. Although farm administrators can configure this setting, the default setting is to create
sites in 2010 mode). When a site collection is in 2010 mode, the user interface resembles the SharePoint 2010
Products interface, and only features that were available in SharePoint 2010 Products are enabled. In 2013 mode,
the interface and features are updated to SharePoint 2013.
You have to make sure that the solution packages, features, and other custom components are available for both
site modes. For more information, see Create a plan for current customizations during upgrade to SharePoint
2013.
Train site collection administrators
It is important to train users about how to upgrade their site collections and how to review their sites in an
upgrade evaluation site collection. Educated users are prepared and know what to expect, which will minimize
helpdesk support and frustrations.
Inform users about changes and new features. Also, let them know about possible issues that they can expect. For
instance, they might have issues with customizations, such as pages that do not display correctly. For information
about general upgrade issues, see Review site collections upgraded to SharePoint 2013 and Troubleshoot site
collection upgrade issues in SharePoint 2013.
Explain to site collection administrators that their upgrade evaluation sites are copies, and any changes they make
there will not persist in their upgraded sites. There is also a notification bar in the preview site that indicates that it
is a copy.
By default, site collection administrators control upgrade for their sites. They can use upgrade evaluation site
collections to preview the new user interface and features. This gives them time to make sure that everything
works correctly, and they can address any issues in their original site before upgrading it. When site collection
administrators are ready, they can upgrade their sites.
We recommend that you have a plan and set a time limit for how long to allow site collection administrators to
postpone upgrade of their sites. For example, each site collection administrator may be given 90 days to work with
his or her site collection administrators to evaluate and then upgrade their sites. This time limit makes sure that
users are given a reasonable time to become familiar with the new user interface and to resolve any issues in their
sites. Ensure that you communicate the time limit to the users, and that they know that you can force through an
upgrade of all sites. Also, you can use a PowerShell command to check the compatibility level for sites in a content
database so that you can see how many sites are in 2010 mode and how many are in 2013 mode. For more
information, see Manage site collections upgrades.
It is important to tell site collection administrators that as long as sites use the 2010 mode, new features will not be
available. However, as soon as sites are upgraded to the new version, application features automatically appear.
See also
Other Resources
Manage site collection upgrades
Create a communication plan for the upgrade to
SharePoint 2013

It is important that you communicate with users during the upgrade process from SharePoint 2010 Products to
SharePoint 2013. Site users have to know what to expect when they visit their sites again after you have upgraded
the environment. Site owners have to know how they can help prepare for upgrade and what they have to do to
upgrade their site collections in SharePoint 2013 and My Sites in SharePoint 2013. Both site users and site owners
have to know when the upgrade will occur. As part of the planning process, determine the following:
Who are the members of the 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 a communication plan so that the upgrade team, stakeholders, and users know
what to expect before, during, and after the upgrade.
Who is a member of the upgrade team?

For small deployments in which sites were not customized extensively, 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 Server administrators perform 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 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.
Server security teams You must coordinate with your security teams, such as the Active Directory Domain
Services (AD DS ) team, to verify accounts and permissions or to take advantage of the new policy settings
that you can apply for SharePoint 2013.
Network teams You must coordinate with the network teams, especially if you must switch DNS to point to
your new farm, or add the new servers to the network infrastructure.
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 might be an
option for users after their sites are upgraded.
Services administrators You must communicate with the administrators for service applications, such as
the Business Data Connectivity service, to make sure that they are ready for the upgrade and they can
review or reconfigure the appropriate settings in the new version.
IT or application Helpdesk leadership and personnel If you have a helpdesk for your company, make
sure that they know about the timing for the upgrade and are prepared for questions after upgrade.
Helpdesk should be a key stakeholder for planning and testing so that they can be understand the potential
changes from an upgrade and the effect that it will have on users.
Site collection owners You must notify site collection owners when the upgrade process is about to occur.
Warn them about any issues that you find when you run the pre-upgrade checker or when you upgrade
their sites. You must also communicate with site collection owners about their role in upgrade. Site collection
owners can upgrade their own sites in SharePoint 2013. Site collection owners can run health checks and
review upgrade evaluation sites before they upgrade their sites.
Site designers and developers and third-party solution providers If you have custom templates, Web
Parts, Web services, or other custom elements that are associated with your sites, you must work with the
associated site designers and developers or third-party solution providers. Because custom elements can fail
or perform differently in an upgraded environment, you have to make sure that designers or developers can
create new versions of these custom elements or verify that these elements were upgraded correctly.
Because their work can have a big influence on the upgrade schedule, work with these stakeholders early in
the process. For more information about potential issues with custom elements, see Use a trial upgrade to
SharePoint 2013 to find potential issues.
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 occur and what they should expect.
Sponsors and other stakeholders Other people in your organization might be 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 service application 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 very important 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 must work together to determine the dates and times to perform the upgrade. We
recommend that you choose an upgrade window to occur when site usage is lowest. For small single-server
deployments, upgrade may be completed in less than a day. Larger deployments can take more time, up to a
weekend. 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 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 trial upgrade so that they know the general timeline and their roles in the process.
After you perform a trial upgrade to find issues. 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 were done to their sites, such as site templates and changes to
core Active Server Page Extension (ASPX) files.
After the environment is upgraded so that they can review the sites and make any changes that are needed.
When you are ready for them to upgrade their site collections.
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 the environment will be upgraded In particular, you must also inform them if their sites will be
unavailable during the upgrade.
When their sites will upgraded Site collection owners should communicate to their site users about the
timeline for upgrading the site collection. If you, as a server farm administrator, are upgrading a site, you
should communicate when that will occur.
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. You can also
point them to available content, such as What's New article. For more information about feature changes,
see What's new.
How to obtain help If they find an issue with their site after upgrade, how can they obtain help in
addressing it?
You can use the new system status bar in the site collections to notify users of these items. For more information
about how to set notifications for the status bar, see Plan for site collection upgrades in SharePoint 2013 in the
article Plan for site collection upgrades in SharePoint 2013.
See also
Other Resources
Clean up an environment before an upgrade to
SharePoint 2013

Before you start to upgrade from SharePoint 2010 Products to SharePoint 2013, 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.
Items to clean up
Many of these items can be removed or repaired by using Stsadm command-line tool or PowerShell cmdlets.
IMPORTANT
To use the Stsadm command-line tool, you must be a member of the Administrators group on the local computer. > To use
PowerShell cmdlets in the SharePoint Management Shell, you must have the following memberships: > securityadmin fixed
server role on the SQL Server instance. > db_owner fixed database role on all databases that are to be updated. >
Delete unused or underused site collections and subwebs

You do not want to upgrade content that you do not have to keep. If it was unused for a long time and is not
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 frequently updated).
For more information about how to delete site collections and subwebs, see the following articles:
Remove-SPSite
Remove-SPWeb
Check large lists (lists with lots of data)
By default, large list query throttling is turned on in SharePoint 2010 Products. This behavior has not changed in
SharePoint 2013. 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. If you are upgrading content from the server products in the
Office 2007 release, check any large lists 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. For more information about large list throttling and how to address issues with large
lists, see Manage lists and libraries with many items.
Delete excess columns from wide lists (lists with too many columns) or remove wide lists
Wide lists are lists with more columns than fit in a single rowspan in the content database. During upgrade, the
underlying storage in the database is changed to a sparse table structure, and a very wide list can cause upgrade to
fail. Use the Test-SPContentDatabase command in PowerShell to look for wide lists in the content databases and
then remove excess columns, or remove the wide list before you upgrade.
For more information about maximum column sizes in a list, see Column limits.
Consider moving site collections into separate databases
If you have 5,000 or more site collections in a database, consider breaking them out into multiple databases. In
SharePoint 2010 Products, there was a default warning at 9,000 site collections and a hard limit at 15,000 site
collections. In SharePoint 2013, 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
an upgrade process by upgrading multiple databases in parallel.
For more information about site collection limits, see Content database limits. For more information about how to
move site collections to a new database, see Move site collections between databases in SharePoint Server.
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 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 Stsadm -o EnumAllWebs
operation with the - includefeatures and - includewebparts parameters to identify these customizations in your
environment. This operation identifies Web Parts, features, event handlers, and setup files that are being used in
your environment. The EnumAllWebs command also specifies which files are used by which sites. Changes were
made to the EnumAllWebs command in the February 2011 Cumulative update to make it return both site
collection and web-level features. For more information, and to get the cumulative update, see Description of the
SharePoint Foundation 2010 cumulative update package (SharePoint Foundation server-package): March 3, 2011.
You can remove a feature during site collection upgrade. Simple features can also be removed by deprecating
them in the template. You can use feature upgrade to remove more complex features. For more information, see
Upgrading Features and Feature Upgrade Overview on MSDN.
For more information about how to identify customizations in your environment, see Use a trial upgrade to
SharePoint 2013 to find potential issues. If customizations are not being used, delete them. For more information
about how to manage these kinds of customizations, see Features and Templates and Solutions and Web Part
Packages on MSDN.
Remove PowerPoint Broadcast sites
These sites and site templates are not available in SharePoint 2013 because the Office Online Server are now
installed separately from the SharePoint 2013 environment. Sites based on these templates will not work in
SharePoint 2013. Remove these types of sites before you upgrade.
You can use the Get-SPSite PowerShell command together with the following options to find these sites:
Get-SPSite | Where-Object{$_.RootWeb.Template -eq "PowerPointBroadcast#0"}
This will return all sites that use that template.

You can also use the Get-SPSite and Remove-SPSite PowerShell commands together with the following options
to remove these sites:
Get-SPSite | Where-Object{$_.RootWeb.Template -eq "PowerPointBroadcast#0"} | Remove-SPSite
Be sure to back up these sites before you remove them. For more information, see Get-SPSite and Remove-
SPSite.
Remove FAST Search Center sites
You cannot upgrade FAST Search Center sites to the 2013 experience. Existing FAST Search Center sites can
continue to work in 2010 mode after upgrade. If you want the new functionality, you must create new Enterprise
Search Center sites in 2013 mode.
Finish Visual Upgrades in SharePoint 2010 Products
During an upgrade from the server products in the Office 2007 release to SharePoint 2010 Products, you could
allow site owners to use Visual Upgrade to keep sites in the old experience on the upgraded environment. When
you upgrade to SharePoint 2013, all sites that are still in the old experience in SharePoint 2010 Products are
automatically upgraded to the 2010 experience. If you want the opportunity to address any issues and review the
sites before they are switched to the new experience, upgrade them to the new experience in your SharePoint 2010
Products environment and review them before you upgrade them to SharePoint 2013. We recommend that you
finish visual upgrades before you upgrade to SharePoint 2013. Finishing visual upgrades before you upgrade
provides the following benefits:
You can address issues while you still have the server products in the Office 2007 release components
available.
You can have users be involved in reviewing and fixing issues in their sites.
You can roll back to the old experience temporarily if it is necessary. You cannot roll back when you are in
the SharePoint 2013 experience.
You avoid adding potential errors to the upgrade process. The fewer operations occurring during upgrade,
the better. Trying to troubleshoot errors is more difficult when you have more processes involved. And users
might think that upgrade has caused an issue when it's really the experience changing to the new version. If
you have an issue with how the site interface is displaying, how will you know whether it is an old issue
from the site that was forced through visual upgrade, a problem with the 2010 mode in SharePoint 2013, or
a problem with a new CSS file?
To check for sites in the old experience, on the SharePoint 2010 Products environment, you can use the Get-
SPSite PowerShell command.
To check for and upgrade sites still in the old experience in the SharePoint 2010 Products environment
by using PowerShell
cmdlets.
NOTE
2. On the Start menu, click All Programs.

3. Click Microsoft SharePoint 2010 Products.
4. Click SharePoint 2010 Management Shell.
5. At the PowerShell command prompt, type the following command to return all site collections that are in or
have subwebs in the old experience:
Get-SPSite | ForEach-Object{$_.GetVisualReport()}
6. At the PowerShell command prompt, type the following command to upgrade those sites to the new
experience:
Get-SPSite | ForEach-Object{$_.VisualUpgradeWebs()}
For more information, see Get-SPSite and Manage visual upgrade (SharePoint Server 2010).
Repair data issues
Make sure that you repair all 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
Forcedeletelist: Stsadm operation
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 databases, or if
a 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 instead of the current
version.
Before you upgrade, use the Enumallwebs operation in stsadm command-line tool to discover which sites
are in which content databases and compare the results. Also, examine each site collection in the results and
check whether it is listed as missing in the site map. Being listed as missing indicates that it is an orphaned
site. For more information, see Enumallwebs: Stsadm operation. If you find duplicate or orphaned sites, you
can use the Remove-SPSite cmdlet in PowerShell to remove the duplicate or orphaned sites from the
database.
For more information, see Remove-SPSite.
Check variations
In publishing environments, check for any variations that must be fixed. For more information, see
Variationsfixuptool: Stsadm operation.
How to make structural changes

To make structural changes to your environment, such as moving site collections or changing how your databases
are allocated, you can use the following methods:
Move-SPSite Use this to move site collections between databases. If a database is very large or contains
lots of site collections, you can move sites to address this to make upgrade more efficient. Also, you can
move all collaboration sites into one database and all My Sites into another to make the upgrade
administration easier for those different sets of sites. 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 Move-SPSite.
Export-SPWeb and Import-SPWeb Use this method to move subwebs or site collections inside a farm or
between farms. For more information, see Export-SPWeb and Import-SPWeb.
See also
Other Resources
Test and troubleshoot an upgrade to SharePoint
2013

Before you upgrade from SharePoint 2010 Products to SharePoint 2013, you should take time to test an
upgrade process and understand the issues that you might face in an actual upgrade. After you perform a test
upgrade, or after you upgrade your actual databases, you might find issues that have to be addressed. After you
address issues, you can restart the upgrade to try again.
about how to test and troubleshoot upgrade.
Downloadable resources about how to test and troubleshoot upgrade

Download the following content for information about how to test and troubleshoot upgrade.
CONTENT DESCRIPTION
SharePoint 2013 Products Preview - Test Your Upgrade See a visual display of information about how to test the
Process model upgrade process.
Articles about how to test and troubleshoot upgrade

CONTENT DESCRIPTION
Use a trial upgrade to SharePoint 2013 to find potential Find out how to plan for success by testing upgrade by using
issues your actual data in either a physical or virtual environment.
Troubleshoot database upgrade issues in SharePoint 2013 Follow these recommendations to troubleshoot any issues
that occur during database-attach upgrade. You can also
look up common issues and discover how to address them.
Troubleshoot site collection upgrade issues in SharePoint Follow these recommendations to troubleshoot any issues
2013 that occur during a site collection upgrade. You can also look
up common issues and discover how to address them.
Branding issues that may occur when upgrading to Learn how to address issues with branding in an upgraded
SharePoint 2013 [Migrated] site, such as custom CSS, custom themes, and custom master
pages and page layouts.
Restart a database-attach upgrade or a site collection If you encounter errors during upgrade, you can address
upgrade to SharePoint 2013 them by using the troubleshooting article, and then use this
article to restart or resume upgrade.
See also
Other Resources
Use a trial upgrade to SharePoint 2013 to find
potential issues

Before you start an upgrade from SharePoint 2010 Products to SharePoint 2013, you should test the upgrade
process to make sure that you know exactly what you have to do to have a successful upgrade. A trial upgrade to
test the process can reveal the following issues:
Whether an upgrade plan will work or if you must make adjustments.
The customizations that are in your environment so that you can plan to deal with them during upgrade.
Whether you should upgrade your hardware to make an upgrade run more efficiently and more quickly.
The timing for upgrade, or how long upgrade will take for your environment.
What you must 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 perform the actual process. Through testing, you can discover the following
issues:
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?
Whether you must adjust any scripts or commands that are used during the upgrade process, especially if
you are relying on any scripts that were used in upgrading to SharePoint 2010 Products.
Whether you have the right plan to address any outages.
This article describes basic steps for testing upgrade, and it gives recommendations for reviewing the results and
adjusting an upgrade plan based on what you learn during the tests.
In addition, the following resources can be helpful when you test the upgrade process:
SharePoint 2013 - Test Your Upgrade Process model
Download the SharePoint 2013 Products Preview - Test Your Upgrade Process model poster to see a visual
display of information about how to test the upgrade process.
See best practices for testing the upgrade process in Best practices for upgrading from SharePoint 2010 to
SharePoint 2013.
Set up a test environment

You can use either virtual or physical hardware to test the upgrade process. Every environment is unique.
Therefore, 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 upgrade will go is to perform a series of trial
upgrades.
Here are some things to consider when you create your test environment:
Make your test farm as similar as possible to your real farm — for example, hardware, software, and
available space.
Use the same URLs in your test farm as in your real farm. Otherwise, you will waste time diagnosing issues
that relate to the URLs that will not occur in the real upgrade. You can do this by using the same URLs and
testing only from computers that have host file changes.
Use the different computer names for your web and application servers.
This will prevent Active Directory Domain Services (AD DS ) conflicts.
Use separate servers that run SQL Server for your test farm
If you are using the same servers that run SQL Server for your test and production farm, you can affect the
performance of your production farm while you run your tests. We recommend that you use different SQL
Server computers (not just instances) for your production and test farms.
Use the same database names in your test environment.
That way, you can validate any scripts that you use to manage your environment. Again, make sure that you
use separate servers that are running SQL Server or you risk affecting your production environment.
Be sure that you transfer all the settings and customizations to the test environment. The section Identify
and install customizations provides information about collecting this information.
Make sure that actions that you take in the test environment do not affect the live environment. Be cautious with
the following:
External data connections
Even though you are working with a copy of the environment, the link to the data source is real. Changes
that you make to the data in the test environment affect the production environment.
Running commands against a live database still in production
Make sure that you use copies of your databases for testing, not a live version in your production
environment. For example, if you run Test-SPContentDatabase against a live database, instead of a copy,
you might affect performance on your production environment.
Using a virtual test environment
When you test by using a virtualized environment, you do not have to have lots 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.
However, virtual environments might not have the same performance metrics as physical environments. If your
production environment is physical, you must consider this difference when you calculate the time that is required
to upgrade your production environment. Generally, you can get better performance estimates if you use a
physical server for SQL Server. Make sure that it has similar performance specifications to your server that runs
SQL Server in your production environment.
Distribution of servers in a virtual test environment
Using a physical test environment

When you test by using a physical environment, you must replicate your proposed production 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. 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 proposed production farm, use at least two
servers for that role in the test farm to test for such issues.
Distribution of servers in a physical test environment
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 that you have to identify, see
Create a plan for current customizations during upgrade to SharePoint 2013.
Use the Stsadm -o enumallwebs operation on all content databases in your SharePoint 2010 Products
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. For more information, see
Enumallwebs: Stsadm operation.
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.
Create a list of all customizations that you find. Identify the source of the customizations, if it is 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.
TIP
Whom do you contact about customizations that you did not create? > Contact Microsoft if you have problems with a
template that you downloaded from the Microsoft website. > Contact your third-party solution vendor if you have problems
with a template or component that they supplied you for the earlier version. An upgraded version may be available.
After you identify all the customizations, copy them to the appropriate servers in your test farm. Ensure that the
following customizations are deployed:
Solutions - by default legacy solutions are deployed to the /14 directories. Use the CompatibilityLevel
parameter when you install the solutions to deploy them to the /15 directories. For more information, see
Install-SPSolution.
Custom Master Pages
Custom JavaScript
Custom CSS files (including those for themes)
Custom workflow actions (must be included in actions file)
Confirm large list query throttling settings to make sure that large lists are displayed as expected.
When you test customizations, use the following guidance:
Check for visual changes.
Check for behavioral changes.
Test in both 2010 and 2013 mode site collections.
Look for any language or resource loading issues.
This is an issue that can occur when customizations exist in 2010 mode and new customizations replace
them in 2013 mode. Because there is only one global directory for language resources, there can be an
issue loading the correct file. Make sure that replacement 2013 customizations include the 2010 resources
so that the customizations can continue to work correctly in both modes.
Validate that upgrade did not affect customizations. Ensure that customizations do not block site collection
upgrade.
You can use the Test-SPContentDatabase Microsoft PowerShell cmdlet before you attach a database to
SharePoint 2013 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 issue found.
Copy real data to the test environment and upgrade databases

You cannot achieve your testing goals unless you use your actual data. Use the Microsoft SQL Server backup and
restore tools to create a copy of your content and services databases.
There is no better way to tell what may occur during upgrade than to perform the test on a copy of all the data.
However, this might not always be a realistic option for initial testing. You can test in phases by testing one
database at a time (if the databases are large) so that you can make sure that you test whatever is unique about
that dataset. 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 that you support in your environment.
The size and complexity of the data subset closely resembles 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 whole volume of
data for your environment.
After you copy the data, take a first pass through the upgrade process to see what happens. This is just the
preliminary round. Follow the steps in Upgrade content databases from SharePoint 2010 to SharePoint 2013 to
try the database attach upgrade process.
When you test the upgrade process, make sure that you test services that are shared across farms. Consider all
states, such as the following:
A SharePoint Server 2010 farm connected to a SharePoint 2013 services farm.
A SharePoint 2013 farm connected to a SharePoint 2013 services farm.
Different version farms for different services.
Use the test environment to find any security, configuration, compatibility, and performance issues for service
applications.
Review results after you upgrade databases

After your test upgrade has finished, you can review the results and revisit your plans. Look at the log files, look at
the upgraded sites, and review your customizations. How did upgrade work for your environment? What did you
discover? What do you have to rethink about the upgrade plan?
Review the log files
Review 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\15\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).
The format of the log files complies with the Unified Logging System (ULS ) conventions. 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 tries
will be listed in the log file.
Review sites in 2010 mode
Verify that the site collections that were not upgraded work as expected in 2010 mode. Sites should look and
behave as they did in SharePoint 2010 Products. Some changes are expected. For example, Office Online and the
web analytics features have changed in SharePoint 2013 and sites that used these features will be affected. For
information about specific things to look for, see Overview of the upgrade process from SharePoint 2010 to
SharePoint 2013.
Run upgrade again, if it is necessary
If you have to, you can restart the upgrade process for a database by using the Upgrade-SPContentDatabase
Microsoft PowerShell cmdlet. For more information about this cmdlet, see Upgrade-SPContentDatabase. For
more information, see Restart a database-attach upgrade or a site collection upgrade to SharePoint 2013.
Upgrade site collections and My Sites

After you have tested and validated upgrade for the content and services databases, you can test the upgrade
process for site collections. Follow the steps in Upgrade a site collection to SharePoint 2013 to test the site
collection upgrade process. If you have My Sites in your environment, see Overview of the upgrade process from
SharePoint 2010 to SharePoint 2013 for more information about the process of upgrading them.
NOTE
Content about My Sites applies only to SharePoint 2013.
Review results after you upgrade site collections

Review upgraded sites visually to identify any issues that have to be addressed before you run the upgrade process
on your production environment. For more information about specific things to look for, see Overview of the
Review the site collection upgrade log files to check for any issues, starting from the top down. Check the
summary section near the end of the log file to see a count of issues and the actual upgrade status (if there is no
status, that means that the upgrade process failed and site upgrade must be retried). The site collection log files are
stored both in the site collection itself (in the _catalogs/Upgrade document library), and on the file system. The file
system log file has more information if you want details about issues. The file system version of the site upgrade
log file is located at %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS. The log
files are named in the following format: SiteUpgrade- 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).
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 fallback plan and
make sure that it works before you begin your real upgrade.
See also
Other Resources
Plan for performance during upgrade to SharePoint 2013
Troubleshoot database upgrade issues in SharePoint
2013

Even after you test the upgrade process to identify potential issues, you might experience unexpected issues during
an upgrade from SharePoint 2010 Products to SharePoint 2013. If you experience issues after upgrade, the sooner
you detect and fix them, the better the end-user experience will be.
This article includes a list of common issues and describes general principles to help you identify and address
upgrade issues. After you identify and address the issues, you can resume upgrade. For more information about
how to resume upgrade, see Restart a database-attach upgrade or a site collection upgrade to SharePoint 2013.
General principles to identify issues

Check the upgrade status to see where upgrade stopped (if it did stop), and check log files to find 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 indicate 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. Review the Upgrade Status page in the SharePoint Central Administration website.
For more information about how to check upgrade status, see Verify database upgrades in SharePoint 2013.
2. Review the following log files:
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\15\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 upgrade log files, see Verify database upgrades in SharePoint 2013. For
more information about the trace log file, see Trace Logs 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.
Be sure to install all server-side customizations, such as features, Web Parts, and so on. Be sure to install
customizations to the correct location in your new farm. For example, additional style sheets that you must
have for SharePoint 2010 Products should be installed in the /14 path, not the new /15 path so that site
collections that you have not upgraded can use them. Also, make sure that that you transfer all unique
settings from the Web.config files for each web application to the new servers.
2. Configuration issues in the server farm, web application, or service applications, such as managed paths or
service applications that are not started.
3. Additional issues that you discover on a site-by-site basis, starting with high-profile or very important sites.
As you identify and fix the top-level issues, you can try to run upgrade again to see whether any issues that
occurred later in the upgrade process have also been fixed.
Common issues
Check to see whether any of the following issues cause an upgrade error or warning.
Q: I want to upgrade from a pre -release version of SharePoint 2013
A: Upgrade from a pre-release version of SharePoint 2013 to the release version of SharePoint 2013 is not
supported.
Pre-release versions are intended for testing only and should not be used in production environments.
Upgrading from one pre-release version to another is also not supported.
Q: The log says I have missing templates, features, or other server-side customizations
A: Identify all server-side customizations and install them before you upgrade
One common error during upgrade is missing server-side files — either files that were installed with SharePoint
2010 Products 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. Check this inventory to make sure that all the files that are needed for your customizations are installed in
your new environment.
You can use the test-spcontentdatabase Microsoft PowerShell cmdlet before you upgrade the database to
identify 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 ]
WARNING 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) was 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 were not 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-SPContentDatabase Microsoft PowerShell cmdlet
on a test server to determine whether any other files for that database are missing. If you only run upgrade again,
the error might not appear in the log files, even though it might still be occurring.
Q: The log file says that something is not right with my farm, web application, or service application
configuration settings
A: Verify your farm and web application settings.
A: Create and start missing service applications
A: Verify that managed paths (included 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.
Q: I see errors and warnings during upgrade about connectivity or corruption
A: Verify your power connections and connection to the network and to SQL Server. Loss of connectivity to
data sources can cause errors. If your servers cannot connect to the databases, they cannot be upgraded.
Q: I ran out of disk space
A: Free some space, or increase the size of the transaction log file before you resume upgrade. If you run out
of space (for example, for transaction log files on your database servers), upgrade cannot continue.
For more information, see Managing the Size of the Transaction Log File.
Q: I see an error about authentication
A: Make sure that the web application is using the right authentication method.
A mismatch in authentication methods can cause problems when you upgrade. The following resources can help if
you have a mismatch between authentication methods:
Classic-to-claims authentication
Make sure that the web applications that you created in SharePoint 2013 use the same authentication
method that was used in SharePoint 2010 Products. Claims-based authentication is the default
authentication method for web applications in SharePoint 2013. If the web application was using classic
mode, you can either update it to claims before you upgrade the database, or create the web application in
classic mode and then migrate it to claims. For more information about how to create a web application that
uses classic mode, and then migrating to claims, see [Create web applications that use classic mode
authentication in SharePoint Server]/previous-versions/office/sharepoint-server-
2010/gg276326(v=office.14)) and Migrate from classic-mode to claims-based authentication in SharePoint
2013
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 in SharePoint
Server to upgrade forms-based authentication providers.
Q: SQL Server says I don't have permissions
A: If you receive an error about an unknown account, or if a database is not upgraded, check the
permissions for the database. In particular, between instances of SQL Server, make sure that you verify that
security is configured correctly. Check that the login accounts that you use have the appropriate fixed roles
and permissions on the databases, and that they will still be valid if you upgrade across domains.
A: Make sure the account that you use to attach the databases is a member of the db_owner fixed database
role for the databases that you want to upgrade.
Q: A database will not upgrade
**A: ** Verify that the database is not set to read-only. You cannot upgrade a database that is set to read-only.
Make sure that you set the databases to read-write before you attach and upgrade the databases.
Q: I changed a database name during restore, but I cannot find the files that have that name
**A: ** When you rename a database at restore time, you must also rename the database and log file names in
the file system (the MDF and LDF files) so that they match.
Q: I cannot back up the Search service application Administration database
**A: ** Before you can back up the Search service application Administration database, you must stop the
Search service on your SharePoint Server 2010 farm. To stop the Search service, on the original farm, on the
Start menu, click Administrative Tools, and then click Services. Right-click SharePoint Server Search 14,
and then click Stop. Be sure to start the service again after you back up the database.
Q: Trusted connections are not working for Excel Services after upgrade
**A: ** You must manually create all trusted data connections for Excel Services after upgrade.
Q: My workflows are no longer associated correctly
**A: ** Verify that the Workflow Auto Cleanup timer job is turned off. If you had disabled the Workflow Auto
Cleanup timer job in your SharePoint 2010 Products environment, make sure that you disable this timer job in
the new environment also. If this timer job is enabled in the new environment and disabled in the SharePoint
2010 Products environment, you might lose workflow associations when you upgrade.
Q: I migrated users from classic authentication to claims-based authentication after upgrade. But some users
have information that is out of date
**A: ** For issues with user profiles, make sure that that the User Profile to SharePoint Full Synchronization
job was run.
If you started the User Profile to SharePoint Full Synchronization job (either automatically or manually)
before the migration process was complete, some users might not be migrated. You can run the following
cmdlet in Microsoft PowerShell after the migration is complete to clear the sync data, and then you can run
the User Profile to SharePoint Full Synchronization job again to include the additional users.
$database = Get-SPContentDatabase "DatabaseName"

[Microsoft.Office.Server.UserProfiles.WSSProfileSynch]::ClearSyncDataForContentDatabase($database)
Where DatabaseName is the name of the content database for the site collection associated with the out-of-
date user profile.
**A: ** Verify that the user exists in the Active Directory domain.
If the user does not exist, you can designate the user as deleted in the UserInfo table. If the user does exist,
you can run the migration again. For more information, see Migrate from classic-mode to claims-based
authentication in SharePoint 2013.
See also
Other Resources
Verify database upgrades in SharePoint 2013
[Restart a database-attach upgrade or a site collection upgrade to SharePoint 2013](/previous-
versions/office/sharepoint-server-2010/ff382638(v=office.14)
Troubleshoot site collection upgrade issues in
SharePoint 2013

When you upgrade a site collection to SharePoint 2013, errors can occasionally occur. This article helps you
understand those errors and address them.
For more information about how to review UI issues in sites, see Review site collections upgraded to SharePoint
2013.
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 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. Review the upgrade status page for your site collection.
On the Site Settings page for the site collection, in the Site Collection Administration section, click Site
collection upgrade. On the Site Collection Upgrade page, click Review Site Collection Upgrade
Status.
2. If pages don't render, check the Site Settings page. 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 doesn't
work, check the site collection upgrade log file for information about the problem.
3. Review the site collection upgrade log files. You can review the site collection upgrade logs from the
following locations:
For site collection administrators: There are also log files for site collection upgrade stored inside the
site collection itself, in the Maintenance Logs catalog at (http:///_catalogs/MaintenanceLogs/YYYYMMDD -
HHMMSS -SSS.txt , where YYYYMMDD is the date and HHMMSS -SSS is the time (hours in 24-hour clock
format, minutes, seconds, and milliseconds).
Common issues
Check to see whether any of the following issues are causing an upgrade error, a warning, or a problem in your
site.
Q: I don't see a UI control on the page that used to be there
A: Reset the page to the default version (that is, reghost it).
Making changes to the site UI can cause problems in site upgrades. If a page was customized to place a UI control
in a non-standard location, you can reset the page to the default version to recover the control.
To reset the page, you can use the Reset to site definition link under Site Actions on the Site Settings page or
use the Reset to Template command in SharePoint Designer.
Q: The view on a large list is not working any longer
A: Create indexed columns, folders, or new views for large lists. You might have to add the indexed column to
your existing views.
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. You 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. For more information about large list
throttling and how to address issues with large lists, see Manage lists and libraries with many items.
Q: I see an error about a duplicate content type name
A: Rename content types or fields that conflict with default names.
Occasionally, custom elements (such as a content type) may have a name that conflicts with a name in the new
version.
In the upgrade log files, you may see an error 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 third-party content type was added to the specified site in SharePoint Server 2010.
During upgrade to SharePoint 2013 its name conflicted with the default content type by the same name. Rename
the third-party content type in the specified site to a different name and run upgrade again. For more information,
see Create or customize a content type.
NOTE
Either renaming or removing a content type can cause any customizations dependent on that content type to stop working.
Q: My site looks ugly, doesn't behave as expected, or I see script errors

A: Either edit the page or reset the page to the default version, or remove or replace the custom files.
A problem with custom or inline JavaScript or CSS files can cause these issues. For more information, see
Branding issues that may occur when upgrading to SharePoint 2013 [Migrated].
Q: Custom content in my site disappeared or doesn't work
A: Change the master page, or change the content so that it doesn't require specific zones.
The master page might have different zone layouts and the content might no longer reference it correctly.
As a last resort, you can also reset the page to the default version. However, if you reset the page, you
might lose zone specific content. For more information, see Branding issues that may occur when
upgrading to SharePoint 2013 [Migrated].
Q: I receive an error that says a control or page cannot render
A: Do one of the following:
If a Web Part was added that is not installed, contact the farm administrator to have it installed. If is a
Web Part that is no longer available or not supported, then use the Web Part maintenance view to
remove the Web Part from the page (remove, do not just close the Web Part).
If a page was directly edited, either edit it again to remove the control or Web Part or reset the page
to the default version.
A Web Part or other control might have been added to the page that is not installed or is no longer
supported. Either a Web Part was added to a zone or the page was directly edited to add a control or
Web Part reference directly inline (possibly on a master page).
A SharePoint feature may need to be activated. For more information, see Enable or disable site
collection features and Open and use the Web Part Maintenance Page.
Q: I receive an error that I cannot create a subsite based on a site template because the site template uses the
2010 experience version and my site collection is in the 2013 experience version
A: Recreate the site template in the 2013 experience.
To recreate the site template, create a new subsite based on the 2013 experience, customize it again to
match the template that you had, and then save the customized subsite as a template (on the Site Settings
page, click Save site as template).
Q: I receive an error when I try to upgrade a FAST Search Center site to the 2013 experience
A: Recreate the site by using the Enterprise Search Center template.
FAST Search Center sites cannot be upgraded to the 2013 experience. Existing FAST Search Center sites
can continue to work in 2010 mode after upgrade. If you want the new functionality, you must create new
Enterprise Search Center sites in 2013 mode.
Q: My custom branding doesn't look right or there are issues in my upgraded site
A: Create an evaluation site collection, and then re-create the master page in the SharePoint 2013 site.
To support the new faster, more fluid UI in SharePoint 2013, changes have been made to the default master pages
and CSS files. For this reason, you cannot apply a master page created in SharePoint 2010 to a site in SharePoint
2013. However, when you upgrade your SharePoint 2010 site to SharePoint 2013, the master page is reset to use
the default master page in SharePoint 2013. Therefore, after upgrade, your site will not appear with its custom
branding.
To resolve this, you should first create an evaluation site collection, and then re-create the master page in the
SharePoint 2013 site. For more information, see Branding issues that may occur when upgrading to SharePoint
2013 [Migrated].
Q: My upgraded site does not render at all; instead, I see an "unexpected error" with a correlation ID
A: Your custom branding may use a custom master page that contains a custom content placeholder.
If your custom master page contains a custom content placeholder, and if custom page layouts also contain this
custom content placeholder, then an error may prevent the home page of your site from rendering at all after
upgrade. Instead, after upgrade, you may see the error message "An unexpected error has occurred." For more
information, see Branding issues that may occur when upgrading to SharePoint 2013 [Migrated].
See also
Other Resources
Branding issues that may occur when upgrading to
SharePoint 2013

SharePoint 2013 introduces a new user interface that is lightweight, fast, and fluid. This UI is built by using new
CSS styles, themes, and master pages. To get this new experience, you must upgrade to the new UI. But the
significant changes that were made to support the new UI may break the upgrade story for some scenarios where
you use custom branding.
In SharePoint 2010 Products, you may have branded your site in one of several different ways:
Applying a custom style sheet to your site that overrides the SharePoint default styles.
Applying a custom theme (THMX file) to your site.
Copying and changing a master page that is included with SharePoint 2013.
Creating a completely new custom master page in a publishing site, where the custom master page uses
custom styles and is referenced by custom page layouts.
When you upgrade your site collection to SharePoint 2013, these types of customizations will not work as is
because the default CSS styles, themes, and master pages have changed. Instead, you must create your custom
branding again. This requires you to use the new styles, themes, or master pages available in SharePoint 2013, and
then apply the newly re-created design to the upgraded site collection.
Changes to the default SharePoint styles, themes, and master pages were necessary to create a faster and more
fluid user interface, and to make subsequent upgrades more predictable.
For this reason, if your site collection contains custom branding, we recommend that, before you upgrade, you first
create an evaluation site collection where you can test and re-create your custom branding in a SharePoint 2013
environment. For more information about an evaluation site collection, see Upgrade a site collection.
The following sections list branding issues that may occur when you upgrade to SharePoint 2013.
Custom CSS
The most common way to apply custom branding to a SharePoint 2010 Products site is to create a CSS file that
contains styles that override the default SharePoint styles.
To make the new UI faster and more fluid, SharePoint 2013 introduced fundamental changes in how CSS is
implemented:
CSS file sizes are reduced.
Nesting of CSS selectors is limited.
CSS inheritance is used whenever possible.
Classes are defined in only one place.
Related classes are grouped in the CSS file.
Inline styles and the !mportant declaration are not used because they cannot be overridden.
Styles use a consistent structure and naming convention.
In SharePoint 2013, styles use a consistent structure and naming convention.
NAMING PART MS- <FEATURE>- <NAME>
Explanation Indicates this is a Microsoft The name of the feature with A descriptive name of the
class. which this item is associated, item, such as title, link, and
or "core" if it's used as part so on
of the core UI.
Because of these changes in how SharePoint 2013 implements CSS, when you upgrade, custom CSS styles will
not be applied to your site. To resolve this, you should first create an evaluation site collection and then use that site
as the environment where you can identify the new SharePoint 2013 styles that you have to override. Create a CSS
file for these styles, and then apply that CSS to your upgraded site.
Custom theme
In SharePoint 2010 Products, you can use an Office program such as PowerPoint 2010 to create a THMX file. Then
you can upload that theme file to SharePoint 2010 Products and apply the theme to your site.
In SharePoint 2013, the theming engine was improved so that theming is faster and more flexible, and so that
themes can be more easily upgraded moving forward. The theming model uses comment-style markup in the CSS
and then replaces parts of the CSS based on parameters such as fonts and color schemes that users select. Themes
in SharePoint 2013 are defined by XML files:
SPColor.xml defines the color palette, in which slots now have semantic names so that it's more clear what
UI elements will be affected when you change a color value. Also, themes now support setting opacity.
SPFont.xml defines the font scheme and supports multiple languages, web-safe fonts, and web fonts.
But there is no support to upgrade a THMX file from SharePoint 2010 Products to SharePoint 2013. If you applied
a custom theme to the SharePoint 2010 Products site, when you upgrade to SharePoint 2013, the theme files
remain in place. But the theme is no longer applied to the site, and the site reverts to the default theme.
To resolve this, you should first create an evaluation site collection and then use the new theming features in
SharePoint 2013 to create the theme again. For more information about the new themes, see the following articles
on MSDN:
Themes overview in SharePoint 2013
How to: Deploy a custom theme in SharePoint 2013
Color palettes and fonts in SharePoint 2013
How to: Create a master page preview file in SharePoint 2013
IMPORTANT
Moving forward, if you want to use custom branding, and if you want that branding to work after future upgrades, we
recommend that you use themes to implement your design. Themes will have upgrade support when future updates are
available. If themes don't work for your scenario or you must have more extensive branding, we recommend that you use a
publishing site together with Design Manager. But understand that if you invest in building custom master pages and page
layouts, you may have to rework or update your design files during and after each SharePoint upgrade.
Copy and change a master page that ships with SharePoint 2013
In SharePoint 2010 Products, a common way to make minor customizations to the UI is to copy and change a
master page that ships with SharePoint 2010 Products. For example, you might change the master page to remove
or hide capabilities from users.
When you upgrade a SharePoint 2010 Products site to SharePoint 2013, the master page is reset to use the default
master page in SharePoint 2013. Therefore, after upgrade, your site will display its custom branding. The custom
master page that was created in SharePoint 2010 Products still lives in the site, but you should not apply the old
master page to the new site because the new site will not display as expected.
To support the new UI in SharePoint 2013, changes were made to the default master pages. For this reason, you
cannot apply a master page that was created in SharePoint 2010 Products to a site in SharePoint 2013.
To resolve this, you should first create an evaluation site collection, and then create the master page again in the
SharePoint 2013 site. After you verify that the new master page works as expected, move the master page to the
new site collection and apply it to the site. If the sites are publishing sites, you can use Design Manager to export
and then import the master page as part of a design package. Otherwise, you can move the master page as part of
a sandboxed solution or by uploading the file to the master page gallery.
IMPORTANT
SharePoint Foundation 2013 does not support publishing sites. You'll need SharePoint 2013 to use publishing sites.
Custom master page in a publishing site

If you want a fully branded site such as a corporate communications intranet site, you use a publishing site that has
a fully custom master page and custom page layouts that are attached to the custom master page.
When you upgrade a SharePoint 2010 Products site to SharePoint 2013, the master page is reset to use the default
master page in SharePoint 2013. Therefore, after upgrade, your site will not display its custom branding. The
custom master page and page layouts created in SharePoint 2010 Products still live in the site, but you should not
apply the old master page to the new site because the new site will not display as expected.
To resolve this issue, you should first create an evaluation site collection that is a publishing site, and then create the
master page again in the SharePoint 2013 site. After you verify that the new master page works as expected,
complete the following steps:
1. Export the master page as part of a design package.
2. Import the design package into the new site collection,
3. Apply the new master page to the site.
Custom content placeholders on a custom master page

IMPORTANT
If your custom master page contains a custom content placeholder, and if custom page layouts also contain this custom
content placeholder, an error may prevent the home page of your site from rendering at all after upgrade. Instead, after
upgrade, you may see the error message: "An unexpected error has occurred."
To determine whether you have this issue, you can create an evaluation site collection that is also a publishing site,
and then set the master page to the master page that ships with SharePoint 2013. If the site still displays, you don't
have this issue. If the site doesn't display and you get an "unexpected error" with a correlation ID, you likely have
this issue.
To resolve this issue, do the following:
1. Create an evaluation site collection that is a publishing site collection.
2. Create a SharePoint 2013 master page.
3. Add the custom content placeholder to the 2013 master page.
4. Apply the new master page to the site.
5. Create a page layout that does not contain the custom content placeholder.
The page layout will be associated with the new master page that was applied to the site.
6. Change all the pages that use the old page layout to use the new page layout.
You can manually edit each page individually in the browser and use the option on the Ribbon, or you can
use the client-side object model for SharePoint to update pages programmatically.
7. Delete the old page layout that contains the custom content placeholder.
We recommend that you do not add custom content placeholders to your custom master page or page layouts.
See also
Other Resources
Troubleshoot site collection upgrade issues in SharePoint 2013
Overview of Design Manager in SharePoint 2013
Restart a database-attach upgrade or a site
collection upgrade to SharePoint 2013

In some cases, you might have to restart upgrade to finish a database-attach upgrade from SharePoint 2010
Products to SharePoint 2013. For example: if a template or language pack is missing from the environment, or if
you lose the connection to SQL Server, you will have to resolve the issue and then restart upgrade. You might also
need to retry or restart a site collection upgrade if it was unable to complete.
NOTE
elements. Be sure that any custom elements that you must have are installed on your front-end web servers before you
start the upgrade process. You can use the Test-SPContentDatabase Microsoft PowerShell cmdlet to identify any custom
elements that your sites might be using. For more information, see Use a trial upgrade to SharePoint 2013 to find potential
issues in the article "Use a trial upgrade to find potential issues."
Restart upgrade for a database by using PowerShell

If the upgrade ran into issues during the database-attach upgrade, you can restart the upgrade process for the
database after you have addressed the issue by using a Microsoft PowerShell cmdlet.
To restart upgrade for a database by using PowerShell
cmdlets.
NOTE

3. Click SharePoint 2013.
5. At the Microsoft PowerShell command prompt (PS C:\>), type the following command:
Upgrade-SPContentDatabase <Name>
Where:
Name is the database name that you want to upgrade.
You can also use the -id parameter and provide the database GUID instead of a database name. 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 and Get-SPContentDatabase.
Restart upgrade for a site collection

If upgrade ran into issues during a site collection upgrade, you can restart the upgrade process for the site
collection after you have addressed the issue. You can use either the Site Settings page or a PowerShell cmdlet to
restart upgrade for a site collection.
To restart upgrade for a site collection
collection upgrade.
3. On the Site Collection Upgrade page, click Upgrade this Site Collection.
This option starts to upgrade your site collection. A box opens to verify that you want to start the process.
4. Click I'm ready to start the actual upgrade.
NOTE
The site collection health checks are run automatically in repair mode before the upgrade starts. The results from the
health checks are included in the upgrade log for the site collection. If there is an error, you must address it before
you can continue to upgrade.
The upgrade starts, and the Upgrade status page for the site collection is displayed. This page
automatically updates while the upgrade is in progress and displays information about the process, such as
the following:
Errors or warnings
When the upgrade started
Where you can find the upgrade log file
After the upgrade is complete, the Upgrade status page is displayed in the new user interface with the
message, Upgrade Completed Successfully.
5. Click Let's see the new site to go to the home page.
Farm administrators can restart upgrade by using PowerShell.
To restart upgrade for a site collection by using PowerShell
cmdlets.
NOTE

4. Click SharePoint 2013 Management Shell,.
Upgrade-SPSite <http://site> -VersionUpgrade [-Unthrottled]
Where:
<http://site> is the URL for the site collection.
Add the option -Unthrottled option to skip the site collection upgrade queue and start the upgrade
immediately.
For more information, see Upgrade-SPSite.
See also
Other Resources
SharePoint 2013

After you learn about the upgrade process, plan for your upgrade, and test your upgrade process by following the
steps in the articles in Test and troubleshoot an upgrade to SharePoint 2013, you are ready to perform a database-
attach upgrade to SharePoint 2013. Follow the steps in this section for both a trial upgrade and your actual
upgrade for your production farm.
upgrading databases to SharePoint 2013.
Downloadable resources about upgrading databases

Download the following content for information about upgrading databases.
CONTENT DESCRIPTION
SharePoint 2013 Products Preview - Describes the steps in the process for a
Upgrade Process model database-attach upgrade
Articles about upgrading databases

The following articles about how to upgrade databases are available to view online. Writers update articles on a
continuing basis as new information becomes available and as users provide feedback.
CONTENT DESCRIPTION
Checklist for database-attach upgrade Use this checklist to make sure that you
(SharePoint 2013) follow all necessary steps as you
prepare for upgrade, perform the
upgrade, and perform post-upgrade
steps.
Create the SharePoint 2013 farm for a Create and configure a SharePoint
database attach upgrade 2013 farm so that you can upgrade
databases from SharePoint 2010
Products.
Copy databases to the new farm for Copy SharePoint 2010 Products
upgrade to SharePoint 2013 content and service databases to a
SharePoint 2013 farm so that you can
upgrade the data to SharePoint 2013.
Upgrade service applications to Upgrade service applications (Business

SharePoint 2013 Connectivity Services, Managed
Metadata, Secure Store, User Profiles,
Search) to SharePoint 2013.
CONTENT DESCRIPTION
Upgrade content databases from Learn how to upgrade content

SharePoint 2010 to SharePoint 2013 databases from SharePoint 2010
Products to SharePoint 2013.
Verify database upgrades in SharePoint Verify that the upgrade for your
2013 databases has succeeded and that you
are ready to begin to upgrade sites.
Migrate from classic-mode to claims- Convert SharePoint 2010 Products or

based authentication in SharePoint SharePoint 2013 classic-mode web
2013 applications to claims-based
authentication or create new claims-
based web applications in SharePoint
2013.
See also
Other Resources
Checklist for database-attach upgrade (SharePoint
2013)

This checklist helps you confirm that you follow all the steps that you must follow as you prepare for upgrade,
perform the upgrade, and perform post-upgrade steps. This checklist applies only to upgrade of the content and
service application databases. It does not apply to upgrade of My Sites or other site collections. For more
information, see Upgrade a site collection to SharePoint 2013.
Some steps include notes about how long that step might take. These rough estimates only give you a relative
idea of the duration of the step. To discover 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 Use a trial upgrade
to SharePoint 2013 to find potential issues.
IMPORTANT
The steps in this article apply to both SharePoint Foundation 2013 and SharePoint 2013, except for the steps about how to
upgrade the service applications, which apply mostly to SharePoint 2013 (the Business Data Connectivity service application
applies to both).
Prepare for upgrade

Follow these steps in order before you start an upgrade to SharePoint 2013:
Pre-upgrade steps
STEP NOTES
[] Create an inventory of server-side Complete this step for the whole

customizations in the environment environment. Check each web server to
Create an inventory of the server-side make sure that you don't miss any
customizations in your environment customizations. Keep the inventory up
(solutions, features, Web Parts, event to date as you prepare for the upgrade.
handlers, master pages, page layouts,
CSS files, and so on). 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.
STEP NOTES
[] Clean up your environment Complete this step one time for the
Before you begin to upgrade, make whole environment.
sure that your environment is This process might take days or weeks
functioning in a healthy state and that to finish.
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 an upgrade to
SharePoint 2013.
[] Test the upgrade process Perform this step multiple times, until
Try out upgrade in a test environment you are prepared to perform the actual
to find any issues and determine how upgrade.
long your actual upgrade might take.
Detailed steps: Use a trial upgrade to
SharePoint 2013 to find potential issues
Complete the database attach upgrade

Follow these steps in order while you upgrade the content and service application databases for your
environment.
Prepare the new environment
STEP NOTES
[] Install and configure SharePoint Complete these steps on each server in

2013 and any language packs your farm.
Install the prerequisite software, and This step might take one hour or more,
then install and configure SharePoint depending on the number of servers
2013. are in your environment.
[] Configure service applications Complete this step one time for the
Enable and configure the services that whole environment.
you need in your new environment.
Do not configure the following service
applications - you will configure them
while you upgrade their databases later
in the process:
Search
STEP NOTES
[] Configure general farm settings Complete this step one time for the
Reapply any general farm settings that whole environment.
you must have from your previous farm
— such as blocked file types, e-mail
setting, 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 SharePoint 2013 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 Server 2010) .
Detailed steps for this phase: Create the SharePoint 2013 farm for a database attach upgrade.
Back up and restore databases
STEP NOTES
[] Record the passphrase for the Complete this step one time for each
Secure Store service application Secure Store service application in the
The Secure Store service application environment.
uses a passphrase to encrypt
information. You must record this
passphrase so that you can use it in the
new environment.
[] Set the previous version databases Complete this step for each content
to be read-only database in your environment.
If you want your original environment Depending on your organization, you
to remain available to users in a read- might need a database administrator to
only state, set the databases to read- complete this step.
only before you back them up.
[] Back up databases Complete this step for each content

Back up all the content databases and database and supported service
the following service application application database in your
databases before you begin the environment.
database attach upgrade process: This step can take an hour, several
Business Data Connectivity hours, or longer, depending on your
Managed Metadata dataset and your environment.
PerformancePoint Depending on your organization, you
Search Administration might need a database administrator to
Secure Store complete this step.
User Profile: Profile, Social, and Sync
databases
STEP NOTES
[] Export the encryption key for the Complete this step one time for each
User Profile service application User Profile service application in the
The User Profile Service service environment.
application requires an encryption key
that is stored separately from the
database and is needed if you want to
upgrade the User Profile Sync database.
[] Restore a backup copy of the Complete this step for each content
databases database and supported service
Restore the databases from the backup. application database in your
environment.
This step can take an hour or longer,
depending on your dataset and your
environment.
Depending on your organization, you
might need a database administrator to
complete this step.
[] Set the restored databases to be Complete this step for each content
read-write database and supported service
Before you can attach and upgrade the application database in your
databases that you copied to the new environment.
environment, you must set them to Depending on your organization, you
read-write. might need a database administrator to
complete this step.
Detailed steps for this phase: Copy databases to the new farm for upgrade to SharePoint 2013
Upgrade service application databases
STEP NOTES
[] Start the service application Complete this step one time for the
instances whole environment.
Start the following service instances
from Central Administration:
Start the instance of the Search service
application by using PowerShell.
[] Upgrade the Secure Store service Complete this step one time for each
application Secure Store service application in the
Use PowerShell to create the new previous environment.
service application and upgrade the
database, create a proxy and add it to
the default proxy group, and then
restore the passphrase from the
STEP NOTES
[] Upgrade the Business Data Complete this step one time for each
Connectivity service application Business Data Connectivity service
Use PowerShell to create the new service application in the previous
service application and upgrade the environment.
database. You do not have to create a
proxy for the Business Data
Connectivity service application.
> [!NOTE]> The Business Data
Connectivity service application is
available in both SharePoint Foundation
2013 and SharePoint 2013.
[] Upgrade the Managed Metadata Complete this step one time for each
service application Managed Metadata service application
Use PowerShell to create the new in the previous environment.
database, and then create a proxy and
add it to the default proxy group. You
must upgrade the Managed Metadata
service application before you can
upgrade the User Profile service
application.
[] Upgrade the User Profile service Complete this step one time for each
application User Profile service application in the
add it to the default proxy group. After
you have created the User Profile
service application, you must import
the Microsoft Identity Integration
Server Key (MIIS) encryption key.
Finally, you can start the User Profile
Synchronization service.
[] Upgrade the PerformancePoint Complete this step one time for each
Services service application PerformancePoint Services service
Use PowerShell to create the new application in the previous
service application and upgrade the environment.
add it to the default proxy group.
[] Upgrade the Search service Complete this step one time for each
application Search service application in the
add it to the default proxy group.
> [!NOTE]> This step applies to only
SharePoint 2013. Although SharePoint
Foundation 2013 includes search
functionality, it is not the same Search
service application that is in SharePoint
2013 and it cannot be upgraded.
STEP NOTES
[] Verify that all of the new proxies are Complete this step one time for the
in the default proxy group whole environment.
Use the Get-
SPServiceApplicationProxyGroup
cmdlet to verify that all of the service
application proxies are in the default
proxy group.
Detailed steps for this phase: Upgrade service applications to SharePoint 2013.
STEP NOTES
[] Create and configure web Complete this step one time for the
applications whole environment.
Create a web application for each web
application that existed in the old
environment. If the desire is to use
Windows Claims Authentication, create
the new Web Applications in Windows
Claims mode instead of Classic mode.
[] Reapply server-side customizations Make sure that you reapply

Manually transfer all server-side customizations to all web servers in the
customizations to your new farm. Refer farm.
to the inventory that you created in the
upgrade worksheet to make sure that
you install all components that your
sites depend on to work correctly.
When you install solutions, make sure
that you add it to the appropriate path
(/14 or /15). If you want a solution to
be available to both paths, install it two
times, and the second time use the
CompatibilityLevel parameter when
you install it, and it will be installed to
the /15 path.
[] Verify custom components Complete this step for each content

Use the Test-SPContentDatabase database in your environment.
Microsoft PowerShell cmdlet to verify Running the cmdlet takes only a few
that you have all the custom minutes, but addressing issues might
components that you need for that take longer.
database.
Detailed steps for this phase: Upgrade content databases from SharePoint 2010 to SharePoint 2013.
Attach and upgrade content databases
STEP NOTES
STEP NOTES
[] Attach a content database to a web Complete this step for one content
application database in your environment.
Attach the content database that This step might take several minutes or
contains the root site collection first. several hours, depending on your
For My Sites, attach the content dataset and hardware on the web
database that contains the My Site host servers, database servers, and storage
before attaching databases that contain subsystem.
the My Sites.
You must perform this action from the
command line. Use the Mount-
SPContentDatabase Microsoft
PowerShell cmdlet.
[] Verify upgrade for the first Complete this step for the content
database database that you just attached.
Verify that upgrade succeeded for the
first database, and review the site to
see whether there are any issues.
Detailed steps: Verify database
upgrades in SharePoint 2013.
[] Attach remaining databases Complete this step for each of the

Attach and upgrade the remaining remaining content databases in your
content databases in your environment. environment.
You must complete this action from the This step might take several minutes or
command line. several hours, depending on your
dataset, whether you are upgrading
multiple databases in parallel, and the
hardware on the web servers, database
servers, and storage subsystem.
[] Monitor upgrade progress Complete this step for each content

Use the Upgrade Status page in the database that you upgrade.
SharePoint Central Administration This step might take several minutes,
website to monitor progress as your an hour, several hours, or days,
databases are upgraded. depending on your content.
Detailed steps: Verify database
[] Verify upgrade for the remaining Complete this step for each of the
database remaining content databases in your
Verify that upgrade succeeded for the environment.
remaining databases. This step might take several minutes,
Detailed steps: Verify database an hour, several hours, or days,
upgrades in SharePoint 2013. depending on your content.
Detailed steps for this phase: Upgrade content databases from SharePoint 2010 to SharePoint 2013.
Complete post-upgrade steps

Follow these steps in order after you perform a database-attach upgrade.
Post upgrade steps for database attach upgrade
STEP NOTES
STEP NOTES
[] Verify that site collections are Complete this step one time for your
working as expecting in 2010 mode whole environment.
Review the site collections and make
sure that they work in 2010 mode
before you begin to upgrade any site
collections. You can use a similar review
list as the one provided for upgraded
sites in Review site collections upgraded
to SharePoint 2013
> [!NOTE]> If the SharePoint 2013
Web Application was created in
Windows Claims mode, complete the
next step prior to testing site
collections.
[] Migrate user accounts to claims Complete this step one time for every
authentication, if it is necessary web application that has changed
By default, new web applications in authentication methods.
SharePoint 2013 use claims
authentication. If you were using classic
authentication in the previous
environment, you must migrate the
users to claims authentication. For
more information, see Migrate from
classic-mode to claims-based
authentication in SharePoint 2013.
[] Update links that are used in any Complete this step one time for your
upgraded InfoPath form templates whole environment.
For a database-attach upgrade, you
exported and imported all InfoPath
form templates in your environment
when you created the new
environment. After upgrade, you can
now update the links that are used in
those upgraded form templates to
point to the correct URLs by using a
Microsoft PowerShell cmdlet.
For more information, see Configure
InfoPath Forms Services (SharePoint
Server 2010).
[] Configure your Search topology Complete this step one time for your
The architecture for the Search service whole environment.
has changed for SharePoint 2013. Plan
and configure your Search topology to
suit your environment and the new
architecture. For more information, see
Scale search for Internet sites in
SharePoint Server and Manage the
search topology in SharePoint Server.
[] Start a full crawl Complete this step one time for your
After all content is upgraded and all whole environment.
settings are configured, you can start a A full crawl can take several hours or
full search crawl of your content. For days to complete, depending on how
more information, see Start, pause, much content is in your environment.
resume, or stop a crawl in SharePoint
Server.
STEP NOTES
[] Back up your farm Complete this step one time for your
Back up your farm so that you have a whole environment.
current backup of your upgraded
environment before you start to
upgrade site collections. For more
information, see Back up farms in
SharePoint Server.
See also
Other Resources
Create the SharePoint 2013 farm for a database attach upgrade
Copy databases to the new farm for upgrade to SharePoint 2013
Create the SharePoint 2013 farm for a database
attach upgrade

When you upgrade from SharePoint 2010 Products to SharePoint 2013, you must use a database attach upgrade,
which means that you upgrade only the content for your environment and not the configuration settings. Before
you can upgrade the content, you must configure a new server or server farm by using SharePoint 2013. This
article lists the items that you have to configure when you create that new environment.
Phase 1 of the upgrade process: Create SharePoint 2013 farm
This is the first phase in the process to .

upgrade SharePoint 2010 Products
data and sites to SharePoint 2013. The
process includes the following phases
that must be completed in order:
Create the SharePoint 2013 farm for a
database attach upgrade (this phase)
Copy databases to the new farm for
upgrade to SharePoint 2013Upgrade
service applications to SharePoint
2013Upgrade content databases from
SharePoint 2010 to SharePoint
2013Upgrade a site collection to
SharePoint 2013For an overview of the
whole process, see Overview of the
upgrade process from SharePoint 2010
to SharePoint 2013 and the Upgrade
Process model Download the upgrade
process model
IMPORTANT
Although this article applies to both SharePoint Foundation 2013 and SharePoint 2013, the following sections apply only to
SharePoint 2013: > The section explains how to export the encryption key for the User Profile service application. > The
section explains how to configure service applications, except for the Business Data Connectivity service application which
applies to SharePoint Foundation 2013 and SharePoint 2013.
Before you begin

Before you create the SharePoint 2013 farm, review the following information and take any recommended
actions.
software requirements for SharePoint 2013.
features and functionality that you want in the SharePoint 2013 farm.

to know what is in your SharePoint 2010 Products environment before you can start to build your SharePoint
2013 environment. Gather information such as the following:
Quota templates
Managed paths
Customizations
You also have to turn off or remove services or components in the SharePoint 2010 Products environment that
could cause errors in the upgrade process. The following services or components should be removed or stopped
before you back up your databases:
Web Analytics The architecture for the Web Analytics service application is different in SharePoint 2010
Products. The presence of SharePoint Server 2010 Web Analytics information in your content databases
could cause an error during upgrade. Stop the Web Analytics service application before you back up the
content databases. Features and web parts from Web Analytics in SharePoint Server 2010 will not exist in
SharePoint 2013, even for a site collection in 2010 mode. Remove any Web Analytics web parts or features
from SharePoint Server 2010 site collections before upgrade.
For more information about this change to Web Analytics, see Changes from SharePoint 2010 to
SharePoint 2013.
PowerPoint Broadcast Sites The Office Online have changed into a separate server product, Office
Online Server, which can serve multiple SharePoint farms for viewing and editing documents. Because of
this change, PowerPoint Broadcast sites cannot be upgraded to SharePoint 2013. For more information
about how to install and use Office Online Server with SharePoint 2013, see Deploy Office Web Apps
(Installed on SharePoint 2010 Products).

Secure Store database. For more information, see Working with encryption keys.
Export the encryption key for the User Profile service application
The User Profile Service service application requires an encryption key that is stored separately from the
database and is needed if you want to upgrade the User Profile Sync database. You must export the Microsoft
Identity Integration Server Key (MIIS ) encryption key from your SharePoint Server 2010 environment. You will
import this exported key to the SharePoint 2013 environment after you upgrade the User Profile service
application databases. By default, the key is located on the server that is running SharePoint Server 2010 and that
is hosting the Microsoft Forefront Identity Manager services in the following directory: < root directory
drive>\Program Files\Microsoft Office Servers\14.0\Synchronization Service\Bin.
IMPORTANT
This section applies only to SharePoint 2013, not SharePoint Foundation 2013.
To export the encryption key for the User Profile service application
Administrators group on the server on which you are running the command.
3. To export the key, type the following at the command prompt, and then press ENTER:
miiskmu.exe
4. In the Microsoft Identity Integration Server Key Management Utility wizard, verify that Export key set is
selected, and then click Next.
5. In the Account Name box, type the account name for the farm administrator.
6. In the Password box, type the password for the farm administrator.
7. In the Domain box, type the domain that contains the farm administrator account, and then click Next.
8. In the Specify export file name and location box, type or click browse to select the path and file name
to use for the exported key, and then click Next.
The key is exported as a file that has a .BIN file name extension.
9. Verify the information, and then click Finish.
A message appears indicating that the key was successfully exported.
10. Click Close to close the Microsoft Identity Integration Server Key Management Utility.
Install SharePoint 2013 in a new environment

Before you can upgrade your databases, you must use SharePoint 2013 to configure a new server or server farm.
The first step in creating your new environment is to install SharePoint 2013 or SharePoint Foundation 2013 and
configure your new server or server farm. You must do the following:
NOTE
SharePoint 2013.
IMPORTANT
these service applications by upgrading the service application databases, do not use the Farm Configuration
Wizard to configure these service applications when you set up your new farm.
For step-by-step instructions for these tasks, see Install for SharePoint 2013.

some service applications that can be upgraded from SharePoint 2010 Products to SharePoint 2013. The steps in
Install for SharePoint 2013 describe how to use the Farm Configuration Wizard to enable all service applications.
However, you should not use the Farm Configuration Wizard to enable the service applications that you want to
upgrade.
Search
For an overview of how to upgrade these service applications, see Services upgrade overview from SharePoint
2010 to SharePoint Server 2013. The steps that you must follow to upgrade these service application databases
are included in the Upgrade service applications to SharePoint 2013 section.
The following services in SharePoint 2013 also require additional steps to enable and configure when you
upgrade:
Excel Services
You can use the Farm Configuration Wizard to enable this service, but you must make sure that you create
all trusted data connections again. For more information, see Configure Excel Services in SharePoint.
This service is not part of the Farm Configuration Wizard. To use this service, use the Configure InfoPath
Forms Services link on the General Application Settings page in Central Administration to configure it.
To continue to use form templates from your previous environment, export all administrator-deployed
form templates (.xsn files) and data connection files (.udcx files) from your SharePoint Server 2010
environment, and then import them to your new SharePoint 2013 environment. For more information, see
Configure InfoPath Forms Services (SharePoint Server 2010)
Office Web Apps
Office Online Server is a new stand-alone server product that delivers Office on the web functionality on
your private network. You install and managed it separately from SharePoint 2013. It cannot be installed
on the same server or virtual machine instance as SharePoint 2013. For more information, see Deploy
Office Web Apps Server 2013.

configuration settings from your SharePoint 2010 Products farm, such as the following:
For more information, see Configure incoming email for a SharePoint Server farm and Configure
outgoing email for a SharePoint Server farm.
Blocked file types
For more information, see Types of files that cannot be added to a list or library.
For more information, see Configure usage and health data collection in SharePoint Server.
Diagnostic logging
For more information, see Configure diagnostic logging in SharePoint Server.
IMPORTANT
If you had disabled the Workflow Auto Cleanup timer job in your SharePoint 2010 Products 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 SharePoint 2010 Products environment, you might lose workflow associations when you upgrade. For more information
about this timer job, seeDisable preservation of workflow history (SharePoint Server 2010) Disable preservation of workflow
history (SharePoint Server 2010).
In a standard installation, the next step would be to create web applications. However, for upgrade, you create
web applications later in the process, after you upgrade the service application databases. For more information,
see Create web applications.

2010 Products data and sites to SharePoint 2013.
SharePoint 2013
See also
Other Resources
SharePoint 2013

When you upgrade from SharePoint 2010 Products to SharePoint 2013, you must use a database attach upgrade,
which means that you upgrade only the content for your environment and not the configuration settings. After
you have configured a new SharePoint 2013 environment, you can copy the content and service application
databases from the SharePoint 2010 Products environment to the SharePoint 2013 environment. You use a
backup and restore process to copy the database, and you can also choose to set the databases to read-only in the
SharePoint 2010 Products environment so that users can continue to access their information, but not change it.
This article contains the steps that you take to copy the databases.
This is the second phase in the process .

to upgrade SharePoint 2010 Products
database attach upgradeCopy
databases to the new farm for upgrade
to SharePoint 2013 (this phase)
Upgrade service applications to
SharePoint 2013Upgrade content
databases from SharePoint 2010 to
SharePoint 2013Upgrade a site
collection to SharePoint 2013For an
overview of the whole process, see
Overview of the upgrade process from
SharePoint 2010 to SharePoint 2013
and the Upgrade Process model
Download the upgrade process model
IMPORTANT
Although this article applies to both SharePoint Foundation 2013 and SharePoint 2013, the sections about how to back up
and restore service application databases apply only to SharePoint 2013. (The exception is the section about the Business
Data Connectivity service application which applies to SharePoint Foundation 2013 and SharePoint 2013).
Before you begin

Studio on both the SharePoint 2010 Products and SharePoint 2013 environments and has access to a
network location that can be accessed from both environments to store the copies of the databases.
Make sure that the appropriate service pack or update is applied to your 2010 environment. If you are
using remote blog storage (RBS ) in your environment, you must be running Service Pack 1 for SharePoint
2010 Products in your environment before you start the upgrade process.

To maintain user access to your original environment, set the SharePoint 2010 Products databases to read-only
before you back up the databases. Even if you don't want to maintain access over the long term, set the databases
to read-only to make sure that you capture all the data in the backup so that you restore and upgrade the current
state of the environment without allowing additional changes to be made. If the databases are set to read-only,
users can continue to view content. However, they will be unable to add or change content.
IMPORTANT
Perform this step in the SharePoint 2010 Products environment.

Properties.
Back up the SharePoint 2010 Products databases by using SQL Server

tools
upgrade. Repeat the procedure for the following databases in the SharePoint 2010 Products server farm:
Search Administration Search_Service_Application_DB_ ID
User Profile: Profile, Social, and Sync databases User Profile Service Application_ProfileDB_ ID
User Profile Service Application_SocialDB_ ID
User Profile Service Application_SyncDB_ ID
NOTE
The Business Data Connectivity service application is available in both SharePoint Foundation 2010 and SharePoint Server
2010. The other service applications are available only in SharePoint Server 2010. Although SharePoint Foundation 2010
includes search functionality, it is not the same Search service application that is in SharePoint Server 2010 and it cannot be
upgraded.
You do not have to back up the configuration or admin content databases, because you recreated these databases
when you set up the SharePoint 2013 server farm. Upgrading the configuration or admin content databases and
the Central Administration site collection is not supported.
IMPORTANT
Perform this step in the SharePoint 2010 Products environment.

8. 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.
SharePoint 2010 Products uses in your environment.
IMPORTANT
Before you can back up the Search service application Administration database, you must stop the Search service on your
SharePoint Server 2010 farm. To stop the Search service, on the original farm, on the Start menu, click Administrative
Tools, and then click Services. Right-click SharePoint Server Search 14, and then click Stop. Be sure to start the service
again after you back up the database.
Copy the backup files to the SharePoint 2013 environment

Copy the backup files that you created in the previous procedure from the SharePoint 2010 Products
environment to the SharePoint 2013 environment.

After you configure the new SharePoint 2013 server farm, you can restore the backup copies of the databases to
SQL Server. Start with one database, and then verify that the restoration has worked before you restore the other
databases.
IMPORTANT
again. > Perform this step in the SharePoint 2013 environment.

2. After you connect to the appropriate instance of the SQL Server 2008 Database Engine, in Object Explorer,
expand the server name.
4. In the Restore Database dialog box, on the General page, type the name of the database to be restored in
the To database list.
TIP
make that change. Be sure to also change the database and log file names in the file system (the MDF and LDF files)
so that they match.
6. To specify the source and location of the backup sets to restore, click From device, and then use the
ellipsis ( ...) to select the backup file.

SharePoint 2013 farm before you attach and upgrade them.
IMPORTANT
Perform this step in the SharePoint 2013 environment.

Properties.

SharePoint 2010 Products data and sites to SharePoint 2013.
Next phase: Upgrade service applications to SharePoint 2013
See also
Other Resources

When you upgrade from SharePoint 2010 Products to SharePoint 2013, you must use a database attach
settings. After you have configured the SharePoint 2013 environment, and copied the content and service
application databases, you can upgrade the service applications to SharePoint 2013. This article contains the
steps that you take to upgrade the service applications.

2010 Products data and sites to SharePoint 2013. The
completed in order:
Create the SharePoint 2013 farm for a database attach
upgradeCopy databases to the new farm for upgrade to
SharePoint 2013Upgrade service applications to SharePoint
2013 (this phase) Upgrade content databases from
SharePoint 2010 to SharePoint 2013Upgrade a site collection
to SharePoint 2013For an overview of the whole process, see
Overview of the upgrade process from SharePoint 2010 to
SharePoint 2013 and the Upgrade Process model Download
the upgrade process model.
IMPORTANT
Although this article applies to both SharePoint Foundation 2013 and SharePoint 2013, the sections about how to
upgrade service applications apply only to SharePoint 2013. (The exception is the section about how to upgrade the
Business Data Connectivity service application which applies to SharePoint Foundation 2013 and SharePoint 2013).
Before you begin

Before you create the SharePoint 2013 farm, review the following information and take any recommended
actions.
Make sure that you have configured a SharePoint 2013 farm, recorded the Secure Store passphrase, and
backed up the User Profile Synchronization encryption key. For more information, see Create the
SharePoint 2013 farm for a database attach upgrade.
TIP
variables, you must use IDs for the service applications and service application proxies when you specify the identity

Secure Store service, User Profile service, and Search service. Most of these service instances can be
started from Central Administration. However the SharePoint Server Search service instance must be
started by using PowerShell.
applications:
NOTE
The Business Data Connectivity service application is available for upgrade both from SharePoint Foundation 2010 to
SharePoint Foundation 2013 and SharePoint Server 2010 to SharePoint 2013. The other service applications are available
for upgrade only from SharePoint Server 2010 to SharePoint 2013. Although SharePoint Foundation 2013 includes search
functionality, it is not the same Search service application that is in SharePoint 2013 and it cannot be upgraded.

1. Start the SharePoint Central Administration website.
2. In Central Administration, on the Application Management page, in the Service Applications section,
click Manage Services on Server.
7. Next to the User Profile Service, click Start.
cmdlets.
NOTE
2. Start the SharePoint Management Shell. .


environment.
cmdlets.
NOTE

Where:
4. To upgrade the Secure Store service application, at the Microsoft PowerShell command prompt, type the
following command:

Where:
TIP
Where:
TIP
application IDs.
local farm.
passphrase.
Where:
TIP

NOTE
The Business Data Connectivity service application is available in both SharePoint Foundation 2013 and SharePoint 2013.

cmdlets.
NOTE


Where:
applications.
4. To upgrade the Business Data Connectivity service application, at the Microsoft PowerShell command
prompt, type the following command:

Where:
TIP

database, and then create a proxy and add it to the default proxy group. You must upgrade the Managed
Metadata service application before you can upgrade the User Profile service application.
cmdlets.
NOTE

Where:
applications.
4. To upgrade the Managed Metadata service application, at the Microsoft PowerShell command prompt, type

Where:
TIP
5. At the Microsoft PowerShell command prompt, type the following command to create a proxy for the
Managed Metadata service application:
Where:
TIP
the local farm.

To upgrade the User Profile service application, you create the new service application and upgrade the database,
and then create a proxy and add it to the default proxy group and then start the User Profile Synchronization
service. After you have created the User Profile Service service application, you must import the Microsoft
Identity Integration Server Key (MIIS ) encryption key.
NOTE
You must upgrade the Managed Metadata service application before you can upgrade the User Profile service application.

cmdlets.
NOTE

Where:
applications.
4. To upgrade the User Profile service application, at the Microsoft PowerShell command prompt, type the
following command:
$upa = New-SPProfileServiceApplication -Name 'User Profile Service Application' -ApplicationPool
$applicationPool -ProfileDBName 'User Profile Service Application_ProfileDB' -SocialDBName 'User Profile
Service Application_SocialDB'
-ProfileSyncDBName 'User Profile Service Application_SyncDB'
Where:
User Profile Service Application is the name that you want to give the new User Profile service application.
TIP
User Profile Service Application_ProfileDB is name of the User Profile service application Profile database
that you want to upgrade.
User Profile Service Application_SocialDB is name of the User Profile service application Social database
User Profile Service Application_SyncDB is name of the User Profile service application Sync database
> [!NOTE]
> The **SocialDBName** and **ProfileSyncDBName** parameters are optional. Use these parameters if you have
Social and Sync databases that you want to upgrade. If you do not specify these parameters, new Social and
Sync databases are created for you.
This command sets a variable, $upa, that you use when you create the proxy later.
5. Type the following command to create a proxy for the User Profile service application:
New-SPProfileServiceApplicationProxy -Name ProxyName -ServiceApplication $upa -DefaultProxyGroup
Where:

$upa is the variable that you set earlier to identify the new User Profile service application.
TIP
If you do not use the variable $upa, then you must use an ID to identify the User Profile service application instead
application IDs.
DefaultProxyGroup adds the User Profile service application proxy to the default proxy group for the local
farm.
After you have created the User Profile Service service application, you can start the User Profile
Synchronization service.
Start the User Profile Synchronization service
1. Start the SharePoint Central Administration website.
2. In Central Administration, on the System Settings page, under Servers click Manage services on
Server.
3. Next to the User Profile Synchronization Service, click Start.
4. In the Select the User Profile Application section, select the User Profile service application that you
upgraded.
5. In the Service Account Name and Passwordsection, type the account name and password to use for
the User Profile Synchronization service.
After you have started the User Profile Synchronization service, you must import the Microsoft Identity
Integration Server Key (MIIS ) encryption key. Import this key to the following directory: < root directory
drive>\Program Files\Microsoft Office Servers\15.0\Synchronization Service\Bin.
To import the encryption key for User Profile service application
Administrators group on the server on which you are running the command.
3. To import the key, type the following at the command prompt, and then press ENTER:
miiskmu.exe /i Path {0E19E162-827E-4077-82D4-E6ABD531636E}
Where:
Path is the path and file name for the key that you want to import.
You might also have to enter a user name and password. These are the credentials for the farm administrator.
IMPORTANT
Use the GUID as specified. This GUID is fixed.
For more information, see Install a software update (SharePoint Server 2010).

cmdlets.
NOTE

Where:
applications.
4. To upgrade the PerformancePoint Services service application, at the Microsoft PowerShell command prompt,

Where:
application.
TIP

Where:
TIP
local farm.

To upgrade the Search service application, you create the new service application and upgrade the database, and
then create a proxy and add it to the default proxy group.
NOTE
This section applies to only SharePoint 2013. Although SharePoint Foundation 2013 includes search functionality, it is not
the same Search service application that is in SharePoint 2013 and it cannot be upgraded.

cmdlets.
NOTE

Where:
applications.
4. To upgrade the Search service application, at the Microsoft PowerShell command prompt, type the following
command:

Where:
TIP
SearchServiceApplicationDBName is the name of the Search service application Administration database

NOTE
A Search service application upgrade might fail because of an issue that occurs during upgrade, such as network or
SQL Server latency. If an error message appears during the Search service application upgrade, do the following:

You must follow several steps to create the Search service application proxy and add it to the default proxy
group. You must complete separate actions to find the ID for the Search service application, create the
new proxy, get the proxy ID, and then add the proxy to the default proxy group.
5. Type the following command to get the ID for the Search service application and store it as a variable:

6. Type the following command to create a proxy for the Search service application:
Where:
TIP
If you do not use the variable $ssa, then you must use an ID to identify the Search service application instead of a
name. To find the ID, you can run the Get-SPServiceApplication cmdlet to return a list of all service application
IDs.

7. Type the following command to get the Search service application proxy ID for the proxy you just created and
set it as the variable $ssap:

8. Type the following command to add the Search service application proxy to the default proxy group:
Add-SPServiceApplicationProxyGroupMember -member $ssap -identity " "
Where:
$ssap is the variable that you set earlier to identify the ID for the proxy you just created for the Search
TIP
If you do not use the variable $ssap, then you must use an ID to identify the Search service application proxy
You use an empty identity parameter (" ") to add it to the default group.
Use the following procedure to verify that the steps to create the proxies and add them to the default proxy
group worked.
cmdlets.
NOTE

$pg = Get-SPServiceApplicationProxyGroup -Identity " "

$pg.Proxies
Where:
You use an empty identity parameter (" ") to specify the default proxy group.

2010 Products data and sites to SharePoint 2013.
Next phase: Upgrade content databases from SharePoint
2010 to SharePoint 2013
See also
Other Resources
Upgrade content databases from SharePoint 2010
to SharePoint 2013

When you upgrade from SharePoint 2010 Products to SharePoint 2013, you must use a database attach
settings. After you have configured the SharePoint 2013 environment, copied the content and service
application databases, and upgraded the service applications, you can attach and upgrade the content
databases to SharePoint 2013. This article explains the steps you take to attach and upgrade the content
databases to SharePoint 2013.
This article does not provide steps for how to upgrade a site collection. The process to upgrade site collections
is separate from the process for upgrading the databases. For steps to upgrade a site collection, see Upgrade a
site collection to SharePoint 2013.
This is the fourth phase in the process .

to upgrade SharePoint 2010 Products
database attach upgradeCopy
databases to the new farm for
upgrade to SharePoint 2013Upgrade
service applications to SharePoint
2013Upgrade content databases from
SharePoint 2010 to SharePoint 2013
(this phase) Upgrade a site collection
to SharePoint 2013For an overview of
the whole process, see Overview of
the upgrade process from SharePoint
2010 to SharePoint 2013 and the
Upgrade Process model Download the
upgrade process model
IMPORTANT
This article applies to both SharePoint Foundation 2013 and SharePoint 2013.
Before you begin


Create a web application for each web application that existed in the SharePoint 2010 Products environment.
For each web application, do the following:
settings.
For example, if you use Windows Classic authentication in your old environment, and you want to
continue to use it, then you must create a web application that uses Windows Classic authentication.
Because claims-based authentication is now the default option for SharePoint 2013, you must use
PowerShell to create a web application that uses Windows Classic authentication. If the desired outcome
is to use claims-based authentication, create the new Web Application in SharePoint 2013 as a claims-
based web application rather than Windows Classic authentication.
To migrate to claims authentication, see Migrate from classic-mode to claims-based authentication in
SharePoint 2013.
Recreate included paths.
For more information, see Configure email integration for a SharePoint Server farm.
Enable self-service site creation for any web application that used it in the previous environment.
Recreate any self-service site creation settings.
solutions, or other elements. Make sure that all custom elements from the SharePoint 2010 Products
environment are installed on your front-end web servers before you upgrade any content databases.
In this step, you manually transfer all customizations to your new farm. Make sure to install any components
that your sites depend on to work correctly, such as the following:
Custom Web Parts
Custom Web services
Custom assemblies
Ensure that you transfer all unique settings from the Web.config files for each web application to the
new servers.
InfoPath is available in SharePoint Server 2010 only.
SharePoint 2013 can host sites in both SharePoint 2010 Products and SharePoint 2013 modes. The installation
for SharePoint 2013 contains both SharePoint 2010 Products and SharePoint 2013 versions of many elements.
The directories on the file system are duplicated in both the 14 and 15 paths, for example:
There are also two versions of the IIS support directories: _Layouts, _Layouts/15 and _ControlTemplates,
_ControlTemplates/15.
Be sure to install customizations to the correct location in your new farm. For example, additional style sheets
for SharePoint 2010 Products should be installed in the /14 path, not the new /15 path so that site collections
that you haven't upgraded can use them. If you want a solution to be available to both paths, install it two times,
and the second time use the CompatibilityLevel parameter when you install it, and it will be installed to the
/15 path. For more information, see Install-SPSolution.
For more information about how to update customizations for use in SharePoint 2013, 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 Install and manage solutions for
SharePoint Server.

enumallwebs operation in the SharePoint 2010 Products environment and use the includefeatures and
includewebparts parameters. This operation can report the templates, features, Web Parts, and other custom
elements that are used for each site. For more information about how to use the enumallwebs operation, see
Enumallwebs: Stsadm operation (Office SharePoint Server) and Clean up an environment before an upgrade to
SharePoint 2013.
You can also use the Get-SPWeb Microsoft PowerShell cmdlet in your SharePoint 2010 Products environment
to see template that are associated with each site and then verify that the template is installed in your
SharePoint 2013 environment. For more information about this operation, see Get-SPWeb.
Before you attach the content databases to the web applications, use the Test-SPContentDatabase Microsoft
PowerShell cmdlet to verify that you have all the custom components that you must have for that database.
cmdlets.
NOTE

Where:

database
the web application that you specify. However, for SharePoint 2013, the process does not upgrade the site
collections.
When you attach a content database, for a web application that spans multiple content databases, make sure
that you attach the content database that contains the root site collection first. When you attach a content
database, include the root site for the web application in the first content database that you attach. In other
words, before you continue, examine the root of the web application in the SharePoint 2010 Products server
farm to determine the first site collection. After you attach the database that contains the root site, 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 attaches the content databases and the site
collections inside that database. Make sure that you do not add new site collections until you have restored all
the content databases.
TIP
For My Sites, attach the content database that contains the My Site host before attaching databases that
contain the My Sites.
By default, when you created the web applications in the new SharePoint 2013 environment, a content
attached your SharePoint 2010 Products databases, and then you can delete the default databases.
IMPORTANT
You must use the Mount-SPContentDatabase cmdlet to attach a content database to a web application.
upgrading.
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.
NOTE
elements. Be sure that all custom elements from the SharePoint 2010 Products environment are installed on your front-
end web servers in the SharePoint 2013 environment before you start the upgrade process. Use the test-
spcontentdatabase Microsoft PowerShell cmdlet to identify custom elements that your sites might be missing.

cmdlets.
NOTE
Where:
For more information, see Mount-SPContentDatabase.
TIP
To upgrade from SharePoint Foundation 2010 to SharePoint 2013, attach the SharePoint Foundation 2010 content
databases directly to the SharePoint 2013 environment. Just follow the same steps in this article, but use the SharePoint
Foundation 2010 databases and a SharePoint 2013 farm. The upgrade process will upgrade the version and the product
at the same time.
Verification: Verify upgrade for the first database

After you attach a database, you can use the Upgrade Status page in Central Administration to check the
status of upgrade on your databases. After the upgrade process is complete, you can review the upgrade log
file to see whether upgrade produced issues. You can use a PowerShell cmdlet to check the upgrade status for
all the content databases. For more information about verifying and troubleshooting upgrade, see Verify
database upgrades in SharePoint 2013 and Test and troubleshoot an upgrade to SharePoint 2013.
%COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\15\LOGS. The upgrade log
file contains more detailed information than the upgrade error log. Be sure to check the summary at the
the file.
Where
An example for an upgrade error log is Upgrade-20120105-132126-374-error.log, and an example for
an upgrade log is Upgrade-20120105-132126-374.log.
NOTE
The format of the upgrade log for SharePoint 2013 is based on the same structure as ULS. > The upgrade log file
includes the name of the content database being upgraded.

cmdlets.
NOTE

upgrade to SharePoint2013.

databases. You can perform parallel database attach upgrades to upgrade more than one database at a time.
Use separate Command Prompt windows to run multiple upgrades. It is recommended that you separate the
start time for each new database upgrade session by several minutes to prevent issues with temporary locks
set for the web application during attachment. Otherwise you might receive an error on the upgrade session.
The wait time to clear temporary locks varies depending on the number of site collections, or the speed of the
Verification: Verify upgrade for additional databases

After you upgrade all 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.
Next steps
Verify that site collections are working as expecting in 2010 mode.
Visually review site collections. You can use a similar review list as the one provided for upgraded sites in
Review site collections upgraded to SharePoint Server 2016.
By default, new web applications in SharePoint 2013 use claims authentication. If you were using classic
authentication in the previous environment, you must migrate the users to claims authentication. For
more information, see Migrate from classic-mode to claims-based authentication in SharePoint 2013.
are used in those upgraded form templates to point to the correct URLs by using a Microsoft
PowerShell cmdlet.
For more information, see Configure InfoPath Forms Services (SharePoint Server 2010).
Configure your Search topology
The architecture for the Search service has changed for SharePoint 2013. Plan and configure your
Search topology to suit your environment and the new architecture. For more information, see Scale
search for Internet sites in SharePoint Server and Manage the search topology in SharePoint Server.
Back up your farm
Although SharePoint Foundation 2013 includes search functionality, it is not the same Search service
application that is in SharePoint 2013. These steps apply only to SharePoint 2013.
After your farm is ready, you can enable access to users, and then start to upgrade site collections. For
information about how to upgrade site collections, see Upgrade a site collection to SharePoint 2013.
This is the fourth phase in the process to upgrade

SharePoint 2010 Products data and sites to SharePoint
2013.
Next phase: Upgrade a site collection to SharePoint 2013
See also
Other Resources
Verify database upgrades in SharePoint 2013

After you upgrade databases to SharePoint 2013, you must verify that the content was successfully upgraded to
the new version. You can verify the status of the database-attach upgrade (is it still in progress, or has it been
completed successfully or with errors or failures?) to see whether 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
In some cases, you might have to restart upgrade to finish upgrading your databases. For more information
about how to restart upgrade, see Restart a database-attach upgrade or a site collection upgrade to SharePoint
2013. For information about how to restart a site collection upgrade, see Manage site collection upgrades to
SharePoint 2013.

errors or warnings.
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 in a shorter file and is named Upgrade- YYYYMMDD -HHMMSS -SSS -error.log.
The format of the log files complies with the Unified Logging System (ULS ) conventions. 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 tries will be listed in the log file.
If you find blocking issues in the log file, you can resolve the issues and then restart upgrade to continue with
the process.
Check upgrade status for databases
The Upgrade Status page lists the upgrade sessions and gives details about the status 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.
status.

following items:
Site collections
Are sites that were not upgraded working as expected in 2010 mode?
Search
Run a crawl, and review the log files.
See also
Other Resources
Restart a database-attach upgrade or a site collection upgrade to SharePoint 2013
Migrate from classic-mode to claims-based
authentication in SharePoint 2013

Claims-based authentication is an essential component to enable the advanced functionality of SharePoint 2013.
To move classic-mode web applications from SharePoint 2010 Products to SharePoint 2013, you can convert
them to claims-based web applications within SharePoint 2010 Products, and then migrate them to SharePoint
2013. The procedures in this article illustrate various supported scenarios.
The PowerShell Convert-SPWebApplication cmdlet in SharePoint 2013 converts classic-mode web
applications to claims-based web applications.
Cau t i on
After you convert a web application to claims-based authentication, you cannot revert it to classic-mode
authentication.
Convert SharePoint 2010 Products classic-mode web applications to

claims-based authentication in SharePoint 2010 Products and then
upgrade to SharePoint 2013
In SharePoint 2010 Products, complete the following procedure to convert an existing web application to claims-
based authentication. After you convert the web application to claims-based authentication, complete the
additional step to migrate the web application to SharePoint 2013. To complete this procedure, you need the
following information:
The URL of the web application that you are converting: http://yourWebAppUrl
A user account to set as a site administrator: yourDomain\yourUser
To convert a SharePoint 2010 Products web application to claims-based authentication
You must read about_Execution_Policies (https://go.microsoft.com/fwlink/p/?LinkId=193050).
cmdlets.
NOTE
permissions. For additional information about PowerShell permissions, see Permissions and Add-SPShellAdmin.
2. From the PowerShell command prompt, type the following to set the specified user account as an
administrator for the site:
$WebAppName = "http://<yourWebAppUrl>"
$wa = get-SPWebApplication $WebAppName
$wa.UseClaimsAuthentication = $true
$wa.Update()
Where:
<yourWebAppUrl> is the URL of the web application.
3. From the PowerShell command prompt, type the following to configure the policy to enable the user to have
full access:
$account = "yourDomain\yourUser"
$account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()
$wa = get-SPWebApplication $WebAppName
$zp = $wa.ZonePolicies("Default")
$p = $zp.Add($account,"PSPolicy")
$fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
$p.PolicyRoleBindings.Add($fc)
$wa.Update()
For more information, see Get-SPWebApplication.

4. From the PowerShell command prompt, type the following to perform user migration:
$wa.MigrateUsers($true)
5. After user migration completes, type the following from the PowerShell command prompt to perform
provisioning:
$wa.ProvisionGlobally()
For more information, see New -SPClaimsPrincipal.

After you complete the previous procedures, you might experience one or more of the following issues:Users
who submit valid credentials when accessing the migrated web application 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, 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 on the web application after migration, make sure that 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.
To migrate a claims-based SharePoint 2010 Products web application to SharePoint 2013
1. In SharePoint 2013, create a claims-based web application. For more information, see Create claims-
based web applications in SharePoint Server.
2. Attach the two existing SharePoint 2010 Products content databases to the newly created SharePoint
2013 claims-based web application. For more information, see Attach or detach content databases in
SharePoint Server.
NOTE
When you attach the SharePoint 2010 Products content databases to the SharePoint 2013 claims-based web
application, the databases will be upgraded to the SharePoint 2013 database format but will not be claims-enabled.
Convert SharePoint 2010 Products classic-mode web applications to

SharePoint 2013 claims-based web applications
In SharePoint 2013, complete the following procedure to convert an existing SharePoint 2010 Products classic-
mode web application to a SharePoint 2013 web application that uses claims-based authentication.
To convert a SharePoint 2010 Products classic-mode web application to a SharePoint 2013 claims-
based authentication
cmdlets.
NOTE
2. In the SharePoint 2013 environment, on the Start menu, click All Programs.
5. Change to the directory where you saved the file.
$ap = New-SPAuthenticationProvider -UseWindowsIntegratedAuthentication -DisableKerberos

New-SPWebApplication -name "ClaimsWebApp" -Port 80 -ApplicationPool "ClaimsAuthAppPool" -
ApplicationPoolAccount (Get-SPManagedAccount "<domainname>\<user>") -AuthenticationMethod NTLM -
AuthenticationProvider $ap
Where:
<domainname>\ <user> is the domain to which the server belongs and the name of the user account.
7. Attach the two existing SharePoint 2010 Products content databases to the new SharePoint 2013 claims-
mode web application. For more information, see Attach or detach content databases in SharePoint
Server.
NOTE
When you attach the SharePoint 2010 Products content databases to the SharePoint 2013 claims-mode web
application, the databases are upgraded to the SharePoint 2013 database format. You have to verify that the
content databases work correctly after you have attached them.
Convert-SPWebApplication -Identity <yourWebAppUrl> -From Legacy -To Claims -RetainPermissions [-Force]
Where:
<yourWebAppUrl> is the URL of the web application.
NOTE
Convert-SPWebApplication converts the content databases to claims-based authentication. You have to verify that the
users can access the web application after you have converted the content databases.
9. If necessary, attach a third SharePoint 2010 Products content database to the new SharePoint 2013
claims-mode web application, and verify that the content database working correctly after you have
attached it.
Convert-SPWebApplication -Identity <yourWebAppUrl> -From Legacy -To Claims -RetainPermissions [-Force]
Verify that users can access the web application after you have converted the content databases to claims-based
authentication. For more information, see New -SPWebApplication, Get-SPManagedAccount, and Convert-
SPWebApplication.
Convert SharePoint 2013 classic-mode web applications to claims-

based web applications
In SharePoint 2013, complete the following procedures to first create a classic-mode Web application, and then
convert it to claims-based authentication.
To create a classic-mode Web application in SharePoint 2013
2013 cmdlets.
NOTE
permissions. For additional information about PowerShell permissions, see Permissions and Add-
SPShellAdmin.
From the PowerShell command prompt, type the following:
New-SPWebApplication -Name <Name> -ApplicationPool <ApplicationPool> -AuthenticationMethod

<WindowsAuthType> -ApplicationPoolAccount <ApplicationPoolAccount> -Port <Port> -URL <URL>
Where:
<Name> is the name of the new web application that uses classic-mode authentication.
<WindowsAuthType> is either "NTLM" or "Kerberos". Kerberos is recommended.
NOTE
For more information, see New-SPWebApplication.
NOTE
After you successfully create the web application, when you open the Central Administration page, you see a health
rule warning that indicates that one or more web applications is enabled with classic authentication mode. This is a
reflection of our recommendation to use claims-based authentication instead of classic mode authentication.
To convert a SharePoint 2013 classic-mode web application to claims-based authentication

From the PowerShell command prompt, type the following:
Convert-SPWebApplication -Identity "http:// <servername>:port" -From Legacy -To Claims -

RetainPermissions [-Force]
Where:
<servername> is the name of the server.
Verify that users can access the web application after you have converted it to claims-based authentication.For
more information, see New -SPWebApplication, Get-SPManagedAccount, and Convert-SPWebApplication.
Migrate SharePoint 2010 Products classic-mode web applications to

SharePoint 2013 classic-mode web applications
In SharePoint 2013, complete the following procedure to create a classic-mode web application, and then
migrate an existing SharePoint 2010 Products classic-mode Web application to SharePoint 2013.
To migrate a SharePoint 2010 Products classic-mode web application to SharePoint 2013
cmdlets.
NOTE
New-SPWebApplication -name "ClassicAuthApp" -Port 100 -ApplicationPool "ClassicAuthAppPool" -

ApplicationPoolAccount (Get-SPManagedAccount "<domainname>\<user>")
Where:
<domainname>\ <user> is the domain to which the server belongs and the name of the user account.
3. Attach the two existing SharePoint 2010 Products content databases to the new SharePoint 2013 classic-
mode web application. Verify that the content databases work correctly after you have attached them. For
more information, see Attach or detach content databases in SharePoint Server.
For more information, see New -SPWebApplication and Get-SPManagedAccount.
See also
Other Resources
Upgrade site collections to SharePoint 2013

upgrading site collections to SharePoint 2013.
Downloadable resources how to upgrade site collections

Download the following content for information about how to upgrade site collections.
CONTENT DESCRIPTION
SharePoint 2013 Products Preview - Upgrade Process model Describes the steps in the process for a database-attach
upgrade.
Articles about how to upgrade site collections

CONTENT DESCRIPTION
Run site collection health checks in SharePoint 2013 Run the site collection health checks to verify your site is
running well. Check each site before you upgrade to
SharePoint 2013.
Upgrade a site collection to SharePoint 2013 Site collection administrators can preview a copy of their sites
in SharePoint 2013 mode, and then upgrade their sites.
Review site collections upgraded to SharePoint 2013 Review site collections after you have upgraded them to
SharePoint 2013.
Manage site collection upgrades to SharePoint 2013 Farm administrators manage the upgrade queue and
throttling settings and upgrade site collections to SharePoint
2013.
See also
Other Resources

SharePoint 2013 includes a set of rules that you can run against a site collection to verify that it is working as
expected. These rules are part of the site collection health checks. You can run the health checks from the Site
Settings page or by using Microsoft PowerShell.
If you are upgrading a site collection to SharePoint 2013, the first step in the process is to run the health checks.
Upgrade step 1: Run site collection health checks
For a visual overview of the entire upgrade process, see Overview of the upgrade process from SharePoint 2010
to SharePoint 2013.
You run the health checks manually to prepare for an upgrade. In addition, the health checks are run automatically
in repair mode when you start to upgrade a site collection. You can also run the health checks at any time to verify
that a site is working as expected. The site collection pre-upgrade health checks examine a site collection and list
potential upgrade issues, such as missing or unsupported elements. For example, the results itemize customized
files so that you can identify the custom file and reset it to the default template in the site definition, if you want.
After you run the checks, a report lists potential issues. The report also has information about how to address the
issues.
The site collection health checker includes the following rules:
Site collection health check rules
RULE NAME DESCRIPTION RULE ID
Conflicting Content Types This rule checks for conflicts between befe203b-a8c0-48c2-b5f0-
existing content types and content 27c10f9e1622
types that are created when you
upgrade the site to SharePoint 2013. A
conflict occurs when both content types
have the same name.
Customized Files This rule checks for any files that were cd839b0d-9707-4950-8fac-
customized (or unghosted) in the site f306cb920f6c
collection or subsites. When run in
repair mode, it can reset the page to
the default (reghost the file).
Missing Galleries This rule checks for all default galleries ee967197-ccbe-4c00-88e4-
and reports if any are missing from the e6fab81145e1
site collection or subsites.
RULE NAME DESCRIPTION RULE ID
Missing Parent Content Types This rule checks for missing parent a9a6769f-7289-4b9f-ae7f-
content types. If a missing parent 5db4b997d284
content type is found, you can either
delete the orphaned content type or
associate the orphaned content type
with a different parent content type.ge
Missing Site Templates This rule checks to make sure that the 5258ccf5-e7d6-4df7-b8ae-
template the site is based on is available 12fcc0513ebd
and reports if any elements are missing.
Unsupported Language Pack This rule checks to make sure that the 99c946f7-5751-417c-89d3-
References language packs that are used by the b9c8bb2d1f66
site collection exist and are referenced
correctly by the site collection.
Unsupported MUI References This rule checks to make sure that the 6da06aab-c539-4e0d-b111-
multi-user interface elements that are b1da4408859a
used by the site collection exist and are
referenced correctly by the site
collection.
Before you begin

This is the first step in upgrading a site collection. Before you upgrade a site collection, you must have already
configured the environment that uses SharePoint 2013 and upgraded the databases. For more information about
these steps, see Upgrade content databases from SharePoint 2010 to SharePoint 2013.
Run the site collection pre-upgrade health checks by using Site

Settings
Site collection owners can run the site collection health checks from the Site Settings page in their site collections.
To run the pre-upgrade checks for a site collection
collection health checks.
3. On the Run site collection health checks page, click Start checks.
A report lists all checked issues and issues that you should resolve.
4. Resolve all issues, and then click Try it again to verify that you fixed them.
Run the site collection pre-upgrade health checks by using PowerShell

Farm administrators can use the following PowerShell cmdlets to run the site collection health checks and to repair
issues: Test-SPSite and Repair-SPSite.
To run the site collection health checks in test mode by using PowerShell
Either a site collection administrator or be granted full read (for test mode) for the web application by policy.
For more information about permission policies for web applications, see Manage permission policies for a
web application in SharePoint Server.
cmdlets.
NOTE

Test-SPSite -Identity <RuleID>]
Where:
<RuleID> is ID for a specific rule that you want to run.
To run the site collection health checks in repair mode by using PowerShell
Either a site collection administrator or be granted full control (for repair mode) for the web application by
policy. For more information about permission policies for web applications, see Manage permission
policies for a web application in SharePoint Server.
cmdlets.
NOTE

Repair-SPSite -Identity <RuleID>]
Where:
<RuleID> is ID for a specific rule that you want to run.
Additional steps
If you are performing an upgrade to SharePoint 2013, you can start the site collection upgrade after you have
addressed all issues from the health checks. You can create an upgrade evaluation site to try the new user interface
for your site, or you can upgrade your site collection directly. To learn about how to create evaluation site
collections or upgrade a site collection, see Upgrade a site collection to SharePoint 2013.
See also
Other Resources

After a server farm administrator has upgraded the databases, site collection administrators can upgrade
individual site collections. When site collection administrators first browse to their sites after the database
has been upgraded, a notification bar at the top of the site indicates that their sites can be upgraded. The
choices are to Start now or Remind me later. Start now begins the site collection upgrade process.
To upgrade a site collection, site collection administrators complete the following steps:
1. Run the site collection health checks to verify the site is ready to upgrade. For more information, see
Run site collection health checks in SharePoint 2013.
2. Create an upgrade evaluation site to preview the differences between versions. (Optional)
3. Upgrade the site collection.
4. Verify that upgrade was successful and the site works as expected. For more information, see Review
site collections upgraded to SharePoint 2013.
This article discusses the second and third steps, and includes procedures for performing these tasks from
Site Settings. For information about using Microsoft PowerShell cmdlets to upgrade sites from the
command line, see Manage site collection upgrades (SharePoint 2013 Products).
Upgrade step 2: Request evaluation site collection and Step 3: Upgrade the site
For a visual overview of the upgrade process, including site collection upgrade, see Overview of the upgrade
process from SharePoint 2010 to SharePoint 2013. For more information about how farm administrators
can control site collection upgrades, see Manage site collection upgrades to SharePoint 2013. For more
conceptual information about site upgrade, including how to plan for upgrade, see Plan for site collection
IMPORTANT
If you upgrade from SharePoint Server 2010 to SharePoint 2013, there are special considerations for My Sites. (My
Sites are not available in SharePoint Foundation 2013.) Make sure that you upgrade the My Site Host site collection
before you allow users to access their individual My Sites in SharePoint 2013. This makes sure that the server
software and database changes are complete so that users can upgrade their individual My Sites successfully. > A
user can upgrade his or her My Site by following the steps to upgrade a site collection later in this article, or a farm
administrator can upgrade My Sites by using PowerShell. >
Create an upgrade evaluation site (Optional)

As a site collection administrator, you can request a preview of your site collection; this is called an upgrade
evaluation site collection. An upgrade evaluation site collection enables you to see your site's content in a
new, separate copy of the site that is running on the SharePoint 2013. Unlike visual upgrade in SharePoint
Server 2010, the upgrade evaluation site collection is a complete copy of the site collection, separate from
the original. Actions that you take in the upgrade evaluation do not affect the original site.
When you request an evaluation site collection, the request is added to a Timer job (named "Create Upgrade
Evaluation Site Collections") which runs once a day. You will receive an e-mail message when the upgrade
evaluation site is available. This might take up to 24 hours. The message includes a link to the evaluation
site. Upgrade evaluation site collections are set to automatically expire (after 30 days by default). If yours
expires before you have finished evaluating the changes, you can request another upgrade evaluation site
collection.
To request an upgrade evaluation site collection
3. On the Step up to SharePoint 2013 page, click Try a demo upgrade.
This option starts the process of generating an upgrade evaluation site collection.
4. In the Create Upgrade Evaluation Site Collection box, click Create Upgrade Evaluation Site
Collection.
A box opens and informs you that a demo site request was received.
5. Click Close to close the box.
You will receive an e-mail message when the upgrade evaluation is available. The e-mail message will
contain a link to the site collection. Review the site and confirm that your site collection will look and
behave as expected in the new user interface.
After you have reviewed the upgrade evaluation and made any necessary changes in your original site
based on your evaluation, you can upgrade your site collection.
Farm administrators can use PowerShell to request an upgrade evaluation site collection. For more
information, see Manage site collection upgrades (SharePoint 2013 Products).

After you run the pre-upgrade checks and optionally review an upgrade evaluation site collection, you can
upgrade your site collection to SharePoint 2013.
IMPORTANT
You cannot upgrade FAST Search Center sites to the 2013 experience. Existing FAST Search Center sites can continue
to work in 2010 mode after upgrade. If you want the new functionality, you must create new enterprise Search Center
sites in 2013 mode. > To enable users to preview Word or PowerPoint search results in a SharePoint 2013 Search
Center, do each of the following: > Before you upgrade content site collections, upgrade the SharePoint Server 2010
enterprise Search Center site collection to 2013 mode. > Ensure that SharePoint 2013 is configured to use Office
Online. For more information, see Deploy Office Web Apps Server and Configure SharePoint 2013 to use Office Web
Apps.
To upgrade a site collection

3. On the Site Collection Upgrade page, click Upgrade this Site Collection.
This option starts the process of upgrading your site collection. A box opens to verify that you want to
start the process.
4. Click I'm ready to start the actual upgrade.
NOTE
The site collection health checks are run automatically in repair mode before the upgrade starts. The results
from the health checks are included in the upgrade log for the site collection. If there is an error, you must
address it before you can continue to upgrade.
The upgrade starts, and the Upgrade status page for the site collection is displayed. This page
automatically updates while the upgrade is in progress and displays information about the process,
such as the following:
Errors or warnings
When the upgrade started
Where you can find the upgrade log file
After the upgrade is complete, the Upgrade status page is displayed in the new user interface with
the message, Upgrade Completed Successfully.
5. Click Let's see the new site to go to the home page.
Farm administrators can use PowerShell to upgrade a site collection. For more information, see Manage site
collection upgrades to SharePoint 2013.
Verification
To verify that upgrade has succeeded, check the Upgrade status page for the site collection.
View upgrade status in Site Settings
2. On the Site Settings page for the site collection, in the Site Collection Administration section,
click Site collection upgrade.
Farm administrators can use PowerShell to view site collection upgrade status. For more information, see
Manage site collection upgrades to SharePoint 2013.
Additional steps
Next, review your upgraded site collection to be sure that everything is working as expected. For more
information see Review site collections upgraded to SharePoint 2013.
See also
Other Resources

Use these steps in your test environment to identify any issues before you upgrade your production
environment. And review your upgraded sites to fix any issues after you have upgraded a site collection.
To verify basic functionality, 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.
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
site collection upgrade log file to see whether you can get more information about the problem.
For site collection administrators: There are also log files for site collection upgrade stored inside the
site collection itself, in the Maintenance Logs catalog at
(http:///_catalogs/MaintenanceLogs/YYYYMMDD -HHMMSS -SSS.txt , where YYYYMMDD is the date
and HHMMSS -SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds).
For farm administrators: The site collection upgrade log file and the upgrade error log file are located
at %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS. The logs are
named in the following format: SiteUpgrade- YYYYMMDD -HHMMSS -SSS.log, where YYYYMMDD is the
These file system logs have more information if you want details about 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 the custom Web Parts before you
test an upgrade, and then review the page for any missing or broken Web Parts after the trial upgrade.
Do all the Web Parts from your original site appear in your If a Web Part zone exists in a customized (unghosted) page,
upgraded site? 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
SharePoint Designer 2013, look for missing Web Parts in the
bottom zone or other zones, or check whether the Web
Parts were closed. For more information about how to work
with Web Parts and Web Part zones in SharePoint Designer
2013, see the SharePoint Designer Help system.
Are there any broken Web Parts pages and are the Web Either in Edit Mode for the page in the browser or in
Parts displayed correctly (in the correct zone, location, and SharePoint Designer 2013, drag the Web Part into the
size)? 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 2013. If you see
additional 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 2013 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 2013, 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.
Are any Web Parts pages still checked out? If you check out a page to make changes, make sure that
you check in the page again.
Are your Excel Web Access Web Parts working correctly? Did Verify all connections and external data sources.
you create your connections again correctly? Are external
data sources still working?
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 turned on in SharePoint 2013. 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 administrator 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. For more information about large list throttling and how to address issues
with large lists, see Manage lists and libraries with many items.
The following table lists common issues with the style and appearance of your web site after upgrade and how
to address them.
TIP
theme do you want to use? different after the site is upgraded. You may have to re-
create or revise a theme and reapply it.
strict XHTML mode.
Customized (unghosted) pages

Customized (also known as unghosted) pages are pages that were edited and are now unique versions of the
pages for the site, instead of the default template pages. The following table lists issues with customized pages
that can occur after upgrade and how to address them.
Are your customizations still in place? 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
instead 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 appearance and behavior
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 in SharePoint 2010
Products), 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 If you want the new functionality and features, you must
environment, or do you want to update to the new reset any customized pages to use the template. Resetting
functionality and look? the page basically discards the customizations and attaches
your page to the appropriate master page. Any
customizations that 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
Other Resources
Restart a database-attach upgrade or a site collection upgrade to SharePoint 2013
Manage site collection upgrades to SharePoint 2013

Even though site collection administrators can now upgrade their own sites to SharePoint 2013, server farm
administrators can still control when and whether a site collection is upgraded by managing the upgrade queue.
You can also view and manage the upgrade throttling settings for a web application or content database to
manage your farm's performance for site collection upgrades.
Before you begin to upgrade site collections to SharePoint 2013

Farm administrators can control settings for site collection upgrade, such as notifications, throttling, and the
upgrade queue, and can upgrade site collections by using PowerShell. Before you change these settings or
upgrade a site collection, you should understand the settings and the implications for making changes. For more
information about the settings for site collection upgrade, see Plan for site collection upgrades in SharePoint
2013. For information about how to upgrade a site collection from the Site Settings page, see Upgrade a site
collection to SharePoint 2013.
Control upgrade notifications and self-service upgrade

When a site collection is available to upgrade, site collection administrators see a status bar on their sites
indicating that they can upgrade them. They can choose to upgrade the site collection then or be reminded later.
You can control settings for these notifications and control whether site collection administrators can upgrade
their site collections. For more information about these properties, see Plan for site collection upgrades in
SharePoint 2013.
To view the upgrade notification and self-service upgrade settings by using PowerShell
cmdlets.
NOTE

3. At the PowerShell command prompt, type the following commands to view the upgrade notification
settings for a web application:
$wa=Get-SPWebApplication <URL>
$wa.UpgradeReminderDelay
$wa.UpgradeMaintenanceLink
Where:
<URL> is URL for the web application that you want to check.
This command returns the Upgrade reminder delay setting for the specified web application.
4. At the PowerShell command prompt, type the following command to view the self-service upgrade setting for
a site collection:
$site=Get-SPSite <URL>
$site.AllowSelfServiceUpgrade=<Value>
Where:
<URL> is URL for the site collection that you want to affect.
<Value> is either 'true' to allow site collection administrators to upgrade the site, or 'false' to not show
them the notification and not allow them to upgrade.
For more information, see Get-SPWebApplication and Get-SPSite.
To change the upgrade notification and self-service upgrade settings for a web application by using
PowerShell
cmdlets.
NOTE

3. At the PowerShell command prompt, type the following command to change the upgrade notification
$wa.UpgradeReminderDelay=<Value>
$wa.UpgradeMaintenanceLink='<LinkURL>'
Where:
<URL> is URL for the web application that you want to affect.
<Value> is the numeric value that you want to set for the delay (for example, 10 for 10 days).
<LinkURL> is a link where the user can find more information.
4. At the PowerShell command prompt, type the following command to change the self-service upgrade setting
for a site collection:
$site=Get-SPSite <URL>
$site.AllowSelfServiceUpgrade=<Value>
Where:
<URL> is URL for the site collection that you want to affect.
<Value> is either 'true' to allow site collection administrators to upgrade the site, or 'false' to not show
them the notification and not allow them to upgrade.
Control the compatibility range for site creation modes

You can control which mode (2010 or 2013, or both) can be used when a user creates a site collection. The
CompatibilityRange property on a web application controls the site modes available for a web application. You
can view or change the settings for CompatibilityRange by using PowerShell.
To view the compatibility range for site creation modes for a web application by using PowerShell
cmdlets.
NOTE

3. At the PowerShell command prompt, type the following commands to view the compatibility range
# Stores the web application at that URL as a variable
$wa.CompatibilityRange
# Returns the CompatibilityRange for the specified web application
Where:
This command returns the compatibility range for the specified web application. For example:
MaxCompatibilityLevel MinCompatibilityLevel DefaultCompatibilityLevel Singular

--------------------- --------------------- ------------------------- --------
15 14 15 False
4. At the PowerShell command prompt, type the following commands to view the maximum, minimum, and
default settings for a specific range:
[Microsoft.SharePoint.SPCompatibilityRange]::<RangeName>
Where:
RangeName is one of the following values: OldVersions, NewVersion, AllVersions.
This command returns the compatibility range for the specified value. For example, for NewVersion:

--------------------- --------------------- ------------------------- --------
15 15 15 True

To change compatibility range for site creation modes for a web application by using PowerShell
cmdlets.
NOTE

3. At the PowerShell command prompt, type the following command to change the compatibility range
settings to a specific range:
$wa.CompatibilityRange = [Microsoft.SharePoint.SPCompatibilityRange]::<RangeName>
# Specifies which range to use
$wa.Update()
# Updates the CompatibilityRange setting to use only the range you specified
# Returns the new CompatibilityRange for the web application
Where:
<URL> is URL for the web application that you want to change.
RangeName is one of the following values: OldVersions, NewVersion, AllVersions.
4. At the PowerShell command prompt, type the following command to change the values for the
CompatibilityRange manually:
$range = New-Object Microsoft.SharePoint.SPCompatibilityRange(<Integer>,<Integer>)
# Creates a new compatibility range from <Integer> to <Integer>
$wa.CompatibilityRange = $range
# Specifies which range to use
$wa.Update()
#Updates the CompatibilityRange setting to use only the range you specified with $range
# Returns the new CompatibilityRange for the web application
Where:
<URL> is URL for the web application that you want to change.
Integer is a number to use as the minimum or maximum value. For example, (14,15) would set the
MinCompatibilityLevel to 14 (2010) and the MaxCompatibilityLevel to 15 (2013). The
DefaultCompatibilityLevel is automatically set to the lower of the MaxCompatibilityLevel and the current
major version (for example, 15).
This command sets and then returns the range that you specified. For example:

--------------------- --------------------- ------------------------- --------
15 14 15 False
Control the queue for upgrades of sites to SharePoint 2013

Every site that is set to upgrade is added to the queue, even if it is processed immediately. A site is removed from
the queue after it is upgraded, or if it has encountered an error that must be addressed by a site collection or
server administrator. If an unexpected failure occurs during the process (such as a power outage or service
interruption), the site remains in the queue and the timer service will try the upgrade again automatically. Server
farm administrators can manage the queue to remove a site from the queue, add a site to the queue, or upgrade a
site manually.
Server farm administrators can manage the queue to do the following:
Determine site collections that are in the upgrade queue.
Each web application has its own upgrade queue. You can show the sites that are in the queue for a specific
content database associated with that web application.
See all sites that are currently being upgraded.
You can view the queue and filter it to show only the sites that are currently being upgraded for a specific
content database.
Add a site collection to the upgrade queue.
If you want to upgrade a site collection, you can add it to the queue.
Remove a site collection from the upgrade queue.
You can remove a site collection from the upgrade queue. Stop the timer job, remove the site from the
queue, and then restart the timer job to resume upgrade for the remaining sites in the queue. You cannot
remove a site collection from the queue if it is currently being upgraded.
The following procedure contains steps to view and manage the site collection upgrade queue.
To manage the upgrade queue by using PowerShell
cmdlets.
NOTE

3. To view all site collections in the queue for a content database, at the PowerShell command prompt, type
Get-SPSiteUpgradeSessionInfo -ContentDatabase <DatabaseName> -ShowInProgress -ShowCompleted -ShowFailed |ft
Where:
<DatabaseName> is name of the database that you want to check. You can also use the GUID for the
database instead of the name.
For more information, see [Get-SPSiteUpgradeSessionInfo](/powershell/module/sharepoint-server/Get-

SPSiteUpgradeSessionInfo?view=sharepoint-ps).
4. To see all sites that are currently being upgraded, at the PowerShell command prompt, type the following
command:
Get-SPSiteUpgradeSessionInfo -ContentDatabase <DatabaseName> -ShowInProgress
Where:
For more information, see Get-SPSiteUpgradeSessionInfo.
5. To see whether a particular site is in the queue, at the PowerShell command prompt, type the following
command:
Get-SPSiteUpgradeSessionInfo -Site <http://site>
Where:
<http://site> is URL for the site collection you want to add to the upgrade queue.
For more information, see [Get-SPSiteUpgradeSessionInfo](/powershell/module/sharepoint-server/Get-

SPSiteUpgradeSessionInfo?view=sharepoint-ps).
6. To add a site collection to the upgrade queue, at the PowerShell command prompt, type the following
command:
Upgrade-SPSite <http://site> -VersionUpgrade -QueueOnly
Where:
<http://site> is URL for the site collection you want to add to the upgrade queue.
For more information, see Upgrade-SPSite.
7. To remove a site collection from the upgrade queue, at the PowerShell command prompt, type the following
command:
Remove-SPSiteUpgradeSessionInfo -Identity <URL>
Where:
<URL> is URL for the site collection you want to add to the upgrade queue.
For more information, see Remove-SPSiteUpgradeSessionInfo.
Control site throttle settings for upgrade to SharePoint 2013

You can view and change the upgrade throttle settings for a content database and web application by viewing and
setting the SPContentDatabase.ConcurrentSiteUpgradeSessionLimit and
SPWebApplication.SiteUpgradeThrottleSettings properties. For descriptions of the properties that control
throttle levels and the default values, see Plan for site collection upgrades in SharePoint 2013.
For more information about web application properties, see SPWebApplication Properties. For more information
about content database properties, see SPContentDatabase Properties.
The following procedure provides steps to view upgrade throttling settings for a web application.
To view the upgrade throttle settings for a web application by using PowerShell
cmdlets.
NOTE

$wa = Get-SPWebApplication <URL>

$wa.SiteUpgradeThrottleSettings
Where:
This command returns the set of throttling settings for the specified web application. For example:
AppPoolConcurrentUpgradeSessionLimit : 5
UsageStorageLimit : 10
SubwebCountLimit : 10
Name :
TypeName : Microsoft.SharePoint.Administration.SPSiteUpgradeThrottleSettings
DisplayName :
Id : ca76dda0-7050-4c6b-a126-05917da39f8a
Status : Online
Parent : SPWebApplication Name=SharePoint - 80
Version : 8222
Properties : {}
Farm : SPFarm Name=SharePoint_ConfigUpgradedPersistedProperties : {}

You can change the upgrade throttle settings for a web application. The following procedure provides steps to
change the upgrade throttling settings for a web application.
To change the upgrade throttle settings for a web application by using PowerShell
cmdlets.
NOTE
$wa.SiteUpgradeThrottleSettings.AppPoolConcurrentUpgradeSessionLimit=<Value>
$wa.SiteUpgradeThrottleSettings.UsageStorageLimit=<Value>
$wa.SiteUpgradeThrottleSettings.SubwebCountLimit=<Value>
Where:
<URL> is URL for the web applications that you want to affect.
Value is the numeric value that you want to set for that limit (for example, 8).
This command changes the throttling settings for a web application to the value that you supply.
For more information, see Set-SPWebApplication.
The following procedure provides steps to view upgrade throttling settings for a content database.
To view the throttle settings for a content database by using PowerShell
cmdlets.
NOTE

$db = Get-SPContentDatabase <DatabaseName>

# Stores the database name as a variable to use in the next command
$db.ConcurrentSiteUpgradeSessionLimit
# Returns the value for the limit for that database
Where:
This command returns the set of throttling settings for the specified content database.
For more information, see Get-SPContentDatabase.
You can change the upgrade throttle settings for a content database. The following procedure provides steps to
change the upgrade throttling settings for a content database.
To change the throttle settings for a content database by using PowerShell
cmdlets.
NOTE

$db = Set-SPContentDatabase <DatabaseName>

# Stores the database name as a variable to use in the next command
$db.ConcurrentSiteUpgradeSessionLimit=<value>
# Changes the limit to the value you specify.
Where:
<DatabaseName> is name of the database that you want to affect. You can also use the GUID for the
<value> is a numeric value to set the property to, such as 9.
This command changes the throttling settings for the specified content database to the value that you supply.
For more information, see Set-SPContentDatabase.
Create upgrade evaluation site collections by using PowerShell

Site collection administrators can request a preview of their site collection. This preview site is called an upgrade
evaluation site collection. Farm administrators can request an upgrade evaluation site collection by using
PowerShell.
To request an upgrade evaluation site collection by using PowerShell
Either a site collection administrator or be granted full control (for repair mode) for the web application by
policy. For more information about permission policies for web applications, see Manage permission
policies for a web application in SharePoint Server.
cmdlets.
NOTE

Request-SPUpgradeEvaluationSiteCollection -identity URL to site
Where:
URL to site is the URL to a site collection in 2010 mode.
For more information, see Request-SPUpgradeEvaluationSite.
Upgrade site collections by using PowerShell

You can upgrade a single site collection or all site collections in a specific database by using PowerShell.
To upgrade a single site collection in a database by using PowerShell
cmdlets.
NOTE

Upgrade-SPSite <http://site> -VersionUpgrade [-Unthrottled]
Where:
<http://site> is the URL for the site collection.
Add the option -Unthrottled option to skip the site collection upgrade queue and start the upgrade
immediately.
This cmdlet upgrades the specific site collection to 2013 mode. For more information, see Upgrade-SPSite.
To upgrade all site collections in a database, use PowerShell. However, because sites can continue to run in 2010
mode in the SharePoint 2013 environment, this is not a necessary procedure for most environments. If you do
choose to upgrade all site collections immediately, site collection owners do not have an opportunity to use an
upgrade evaluation site to preview the new user interface or change their original site before upgrading. We do
not recommend that you upgrade all site collections immediately as part of your initial upgrade. However, you
might want to upgrade all site collections after some time has passed and all customizations were verified in 2013
mode.
To upgrade all site collections in a database by using PowerShell
cmdlets.
NOTE

Get-SPSite -ContentDatabase <DBName> -Limit All | Upgrade-SPSite -VersionUpgrade -QueueOnly
Where:
<DBName> is the name of the content database for which you want to upgrade all site collections.
The QueueOnly parameter adds the site collections to the upgrade queue. This allows the timer job to perform
parallel upgrades when it is possible and can save time. The sites are upgraded in the order in which they are
added to the queue.
This cmdlet upgrades all site collections in the specific content database to 2013 mode.
View upgrade status by using PowerShell

You can view upgrade status for all databases, for a single site collection, or for all site collections.
To view upgrade status for a single site collection by using PowerShell
cmdlets.
NOTE

Get-SPSiteUpgradeSessionInfo -Site <http://site>
Where:
<http://site> is the URL of the site collection.
This cmdlet returns the upgrade status for the specified site collection together with information about the
upgrade session and a link to the log files for more information. For more information, see Get-
SPSiteUpgradeSessionInfo.
4. Or, you can use the following command to view the information about a specific site collection upgrade:
$sc = Get-SPSite <http://site>

# Sets a variable for the site collection
$sc.CompatibilityLevel
# Returns the compatibility level for the site collection (either 14 or 15 for 2010 or 2013 mode)
$sc.UpgradeInfo
# Returns the upgrade information for the site collection
Where:
<http://site> is the URL of the site collection.
This command returns the compatibility level and upgrade information (such as a pointer to the log file) for the
specified site collection. If the compatibility level is "15," then it has been upgraded to 2013 mode. For more
information, see Get-SPSite.
To view upgrade status for a single database by using PowerShell
cmdlets.
NOTE

Get-SPSiteUpgradeSessionInfo -ContentDatabase <DatabaseName> -ShowInProgress -ShowCompleted -ShowFailed
Where:
<DatabaseName> is the name of the database that you want to check.
This cmdlet returns any site collections that have an upgrade in progress, completed, or failed and lists their
status, plus a link to the log files for more information. You can use only one parameter to find only in progress,
completed, or failed upgrades. For more information, see Get-SPSiteUpgradeSessionInfo.
To view upgrade status for all site collections by using PowerShell
cmdlets.
NOTE

Get-SPSite -Limit All
This cmdlet returns the URL for all site collections in the environment and the compatibility level (14 or 15) for
each site collection.
See also
Other Resources
My Sites are site collections owned by the user for the user to store their documents, connect with other users,
follow and discover content, and so on. Upgrading My Sites differs from upgrading other site collections because
My Sites consist of both the shared My Site Host site collection (also known as the My Site Host) and the My Site
Personal site collection. In SharePoint Server 2010, the personal site collection was used to store a user's
documents. In SharePoint Server 2013, the personal site collection contains OneDrive for Business, followed
content, and so on.
Upgrading My Sites terms and concepts

Compatibility range settings. The compatibility range settings control which user interface mode sites are
created or displayed in (2010 user interface mode or 2013 user interface mode). The compatibility range
settings allow administrators to separate the upgrade of site collections from the upgrade of content
databases. To control the user interface mode, an administrator can set the MinCompatibilityLevel and the
MaxCompatibilityLevel properties on a web application. For more information, see Manage site collection
upgrades to SharePoint 2013
Mixed user interface modes. During an upgrade, a user's My Site may display both the SharePoint Server
2010 and SharePoint Server 2013 master pages. When this happens, the My Site is displaying mixed user
interface modes which may cause confusion for users. The mixed user interface modes are affected by the
combination of the version of the My Site Host, and the compatibility range settings. When experiencing the
mixed user interface modes on My Sites, users will not lose any data.
IMPORTANT
If you follow the section titled Upgrade My Sites, you will not encounter mixed user interface modes.
Planning considerations for upgrading My Sites

Consider whether you have to upgrade from classic-mode to claims-based authentication in SharePoint
Server 2013. For more information, see Migrate from classic-mode to claims-based authentication in
SharePoint 2013
IMPORTANT
upgrades, see Get started with upgrades to SharePoint 2013
Procedure to upgrade My Sites

about upgrades, see Overview of the upgrade process from SharePoint 2010 to SharePoint 2013
IMPORTANT
Once you upgrade your My Site Host and personal site collections, you cannot undo the upgrade.
IMPORTANT
Some of the items in the following list require additional steps to be performed. These additional steps are discussed in the
sections that follow this procedure. It is recommended when upgrading the entire server farm, that you also upgrade My
Sites.
Copy databases to the new farm for upgrade to SharePoint 2013 and Create the SharePoint 2013 farm for a
database attach upgrade.
attach method. For more information, see Upgrade service applications to SharePoint 2013. Ensure the My
Site Host URL field on the User Profile Service application is left blank because this field will be updated
during the upgrade process. For more information, see Configure My Site settings for the User Profile
service application
6. Set the compatibility range settings for site creation on the My Sites web application. Use
MinCompatibilityLevel = 15 and MaxCompatibilityLevel= 15 for your compatibility range settings.
2010 My Sites.
application to ensure the correct configuration settings are applied to the web application. For more
information, see Configure My Sites in SharePoint Server.
Cau t i on
Upgrading the My Site Host

Where:
Upgrading the personal site collection

2013 My Site Host has a hidden, automatic upgrade web part on it. When a user visits the My Site Host, and if the
compatibility range settings allow 2013 user interface mode, an automatic upgrade of the user's My Site starts.
This upgrade process is performed per user and may take some time to finish.
Alternative procedure for upgrading My Sites

You may have constraints that restrict you from upgrading your My Sites to SharePoint Server 2013 My Sites. For
example, you are upgrading your entire server farm but you have customizations on your My Sites that you have
not tested on SharePoint Server 2013. In this scenario, you may not want to upgrade your My Sites until you
complete your testing.
If you want to upgrade your server farm but keep your My Sites as SharePoint Server 2010 My Sites, change the
previous procedure for upgrading My Sites as follows:
Step 6: Use MinCompatibilityLevel = 14 and MaxCompatibilityLevel= 14 for your compatibility range
settings on the My Sites web application.
When you are ready to perform the upgrade of your My Sites:
Set MinCompatibilityLevel = 15 and MaxCompatibilityLevel= 15 for your compatibility range settings on
the My Sites web application.
Upgrade the My Site Host as described in Step 12
Upgrade the personal site collections as described in Step 13
IMPORTANT
Alternative procedure for upgrading the personal site collection

Administrators may choose these alternate methods of upgrading the personal site collections if they do not want
their users experiencing the automatic upgrade of their My Site on their first visit to the My Site Host:
Forced upgrade. If you use the forced upgrade path, users will not experience an automatic upgrade the
first time they visit their My Site. Instead, their My Site will already be upgraded for them. A farm
administrator can perform a forced upgrade of all My Sites in the farm by running the following command
at the SharePoint 2013 Management Shell command prompt:
Get-SPSite -limit all |where {$_.CompatibilityLevel -eq '14'} | where {$_.RootWeb.WebTemplateId -eq 21}
| upgrade-spsite -versionupgrade
IMPORTANT
Before performing a forced upgrade, you should confirm that the My Site Host was upgraded successfully. You can
verify this by either making sure that the My Site Host has the SharePoint Server 2013 user interface, or by inspecting
the ULS logs to make sure that no errors were encountered during the upgrade process.
Cau t i on
Using the forced upgrade approach may take lots of time to complete depending on the number of My Sites
you are upgrading. This will affect your server farm's performance and the farm will be in read-only mode
during the complete upgrade process.
Deferred site collection upgrade. The deferred site collection upgrade process uses the compatibility
range settings to allow administrators to upgrade their databases and keep their site collections in
SharePoint Server 2010 mode. When the compatibility range settings allow both 2010 user interface mode
and 2013 user interface mode (MinCompatibilityLevel = 14 and MaxCompatibilityLevel= 15), the owner of
the My Site will see a red banner at the top of their My Site. From the banner, they can request an evaluation
site collection of their My Site to preview before upgrading to the SharePoint Server 2013 user interface.
The evaluation site cannot be converted to a regular My Site because it is a temporary site which will
eventually be deleted. The deferred site collection upgrade path is performed per user.
Cau t i on
Using the deferred site collection upgrade may result in the mixed user interface mode issue. Be sure to
stage and test your upgrade carefully before you do this in production. When you encounter the mixed user
interface mode on your My Sites, new users who do not have a My Site cannot create new My Sites.
Troubleshooting a My Site upgrade
If users are experiencing issues, such as mixed user interface modes or they cannot upgrade their My Site to the
SharePoint Server 2013 user interface mode, verify that the following steps were completed:
The My Site Host was upgraded to a SharePoint Server 2013 My Site Host.
The compatibility range settings allow site creation in 2013 user interface mode.
The SPSite.CanUpgrade property on the personal site collection of the user requesting the upgrade is set to
true. An administrator may allow or restrict certain site collections from being upgraded by setting this
property at the site collection level.
NOTE
See also
Other Resources
Advanced upgrade scenarios for SharePoint 2013

how to upgrade to SharePoint 2013 in advanced scenarios.
CONTENT DESCRIPTION
Search-first migration from FAST Search Server for SharePoint Learn how to perform a search-first migration from Microsoft
2010 to SharePoint Server 2013 FAST Search Server 2010 for SharePoint to Microsoft
SharePoint 2013.
How to upgrade an environment that uses content type Upgrade the Managed Metadata service application and site
syndication (SharePoint Server 2013) collections that use content type syndication and share the
service applications to the old farm.
Deploy custom features to upgraded site collections in Learn supported scenarios for deploying custom features to
SharePoint Server 2013 upgraded site collections in a SharePoint Server 2013 farm
that has been upgraded from SharePoint Server 2010.
For descriptions of additional cross-product upgrade paths that are allowed, see the following articles:
Search-first migration from FAST Search Server for
SharePoint 2010 to SharePoint Server 2013

This article describes how to perform a search-first migration from Microsoft FAST Search Server 2010 for
SharePoint to SharePoint Server 2013.
Introduction to search-first migration (SharePoint Server 2013)

Upgrading from FAST Search Server 2010 for SharePoint to SharePoint 2013 provides significant improvements
in enterprise search capabilities. However, policy or resource constraints in an organization may pose challenges
that prevent or postpone a complete upgrade. Even if your organization is not ready to perform a complete
upgrade from FAST Search Server 2010 for SharePoint, you can take advantage of new SharePoint 2013 search
capabilities by performing a search-first migration.
To be able to configure and use certain features, such as Result sources, you must perform a full migration of your
farm from FAST Search Server 2010 for SharePoint to SharePoint 2013.
When you've completed a search-first migration, you run your system in "mixed mode." Mixed mode is when a
FAST Search Server 2010 for SharePoint Enterprise Search Center is used to consume SharePoint 2013 search.
Users can still use the FAST Search Server 2010 for SharePoint Enterprise Search Center, but queries will be sent
to the SharePoint 2013 index.
Running your system in mixed mode means that you do not upgrade the content of your farm or the site collection
to SharePoint 2013. The FAST Search Server 2010 for SharePoint farm can continue to provide other FAST Search
Server 2010 for SharePoint functionality for your organization. FAST Search Server 2010 for SharePoint features,
such as content databases and the Business Data Catalog, are not migrated or upgraded as part of a search-first
migration. Functionality that is not related to search does not have to be configured in the new SharePoint 2013
farm. Some FAST Search Server 2010 for SharePoint features will only work in backward compatibility mode.
Your organization can complete the product upgrade at any time.
NOTE
Due to the many architectural changes between FAST Search Server 2010 for SharePoint and SharePoint 2013, not all
configurations and features can be migrated. If you are unsure of the implications of a migration from FAST Search Server
2010 for SharePoint to SharePoint 2013, we strongly recommend that you contact a trusted Microsoft partner or Microsoft
Consulting Services for guidance.
For more information, see:

Features with limitations
Supported migration path

Search-first migration supports only the partial migration of search capabilities from a FAST Search Server 2010
for SharePoint farm to a SharePoint 2013 farm.
High-level search-first migration steps
Make sure that you have a FAST Search Server 2010 for SharePoint production farm with at least one Search
service application. This production farm must also be configured and operating with enterprise search
functionality.
To complete a search-first migration:
1. Install SharePoint 2013 on a single server with an additional dedicated SQL Server.
See also: Install SharePoint 2013 on a single server with SQL Server
2. On the SharePoint 2013 SQL Server, install:
PowerShell Snapins for SQL Server
3. On the FAST Search Server 2010 for SharePoint farm, back up these databases:
FAST Search Administration database
FAST Content Search Service Application database
FAST Query Search Service Application database
4. Download the search-first migration scripts from TechNet Gallery. For details and guidance on using these
scripts, refer to the PDF included in the download package.
Edit the environment variables in the scripts.
Save and copy the scripts to the SQL Server and to the SharePoint 2013 server.
5. On the SharePoint 2013 SQL Server, run the search-first migration scripts.
6. On the SharePoint 2013 server, run the search-first migration scripts.
7. Build out the new SharePoint 2013 farm topology. For instructions on how to do this, see Manage the
search topology in SharePoint Server.
8. On the SharePoint 2013, start crawling.
NOTE
For information about limitations, see Search-first migration from FAST Search Server for SharePoint 2010 to SharePoint
Server 2013.
Summary of search-first migrated features

FEATURE NAME MIGRATED
Crawled properties Yes
Custom managed properties created in addition to the default Yes

set
New mappings to default managed properties Yes
Content sources Yes
Crawl rules Yes
Crawl schedules Yes
Scopes and scope filters Yes

In most cases, scopes and scope filters work after migration,
but you cannot edit or change them.
Scope filters usually contain Path: or Site: restrictions.
SharePoint 2013 does not tokenize the URLs. When you apply
a scope filter, you might not obtain the same results after
migrating to SharePoint 2013.
If the migration is complete, that is to say, if both content
source and front end are upgraded to SharePoint 2013, Result
sources replace the Scopes feature.
Federated locations Yes
Best Bets Yes
Visual Best Bets Visual Best Bets are converted to Best Bets
Synonyms tied to Best Bets and Visual Best Bets Yes
Synonyms used for query expansion No
Promotions and demotions No
Inclusion and exclusion dictionaries (entity extraction, No

spellcheck)
Optional processing dictionaries No
Content processing extensibility No
Large scale index configuration No

FEATURE NAME MIGRATED
Managed properties for "people search" No
Business Connectivity Services (BCS) connector and its No

associated configuration
Custom connectors and their associated configuration No
Rank profile No
NOTE
A FAST Search Server 2010 for SharePoint rank profile can't be converted to a SharePoint 2013 ranking model.
Features with limitations

When you run SharePoint 2013 in mixed mode, certain features will function with limitations. You'll have to use
manual workarounds for these features to work correctly. The following sections explain:
Limitations when you migrate from FAST Search Server 2010 for SharePoint Search Center to SharePoint
Server 2013
Limitations after a full migration to SharePoint Server 2013
Limitations when you migrate from FAST Search Server 2010 for SharePoint Search Center to SharePoint Server
2013
FEATURE NAME LIMITATION
Document previews Document previews is not a backward compatible feature

because SharePoint 2013 can't render Document previews
that are generated by a FAST Search Server 2010 for
SharePoint content farm.
Duplicate documents link in the search results page The Duplicate documents link is displayed in the search results
page. However, it displays no duplicate documents when it is
clicked. To avoid confusion, you can disable this link by editing
the XSLT file in the Core results Web Part.
Author refiner The Author managed property was redefined and replaced by
the managed property DisplayAuthor in SharePoint 2013.
The migration script migrates the Author refiner without
changing it. To make the Author refiner work, you must
manually edit the XSLT in the refinement panel, and change
the Author to DisplayAuthor .
Site refiner In SharePoint 2013, the managed property SPSiteURL is

used to populate the site refiner. If there are problems with the
site refiner after migration, verify that:
The properties Basic:4 and ows_SPSiteURL are mapped to
SPSiteURL .
RespectPriority of SPSiteUrl is set to true .
Limitations after a full migration to SharePoint Server 2013

FEATURE NAME LIMITATION
Best Bets SharePoint 2013 does not support Best Bets. The feature's
been replaced by query rules. Best Bets are not automatically
converted to query rules, so you have to create new query
rules.
Front end It isn't possible to automatically upgrade the FAST Search

Server 2010 for SharePoint front end.
How to upgrade an environment that uses content
type syndication (SharePoint Server 2013)

Content type syndication, or content type publishing, occurs when you publish a content type from a content type
"hub" site collection to one or more "consuming" site collections. For more information, see Introduction to content
types and content type publishing and Plan to share terminology and content types (SharePoint Server 2010).
Suppose that you use content type syndication in SharePoint Server 2010. Now you want to upgrade to
SharePoint 2013, but you want to upgrade some site collections now and others later. In this situation, you have to
follow a specific process to make sure that all content types can continue to work across versions.
Content type syndication uses the backup and restore mechanism in SharePoint Server to publish the content
types across site collections. And backup and restore does not work across versions in the following scenarios:
Between 2010 and 2013
Between sites in 2010 mode on a 2013 farm and those in 2013 mode on a 2013 farm
For this reason, you have to set up sharing with multiple Managed Metadata service applications and proxies to be
able to publish content types to each site collection in the appropriate version. A proxy is a connection that
associates a service application with a web application.
Initial state
This article uses a specific example environment to show how to configure the service applications and
connections (proxies) before you upgrade the site collections. At the start, this example environment contains the
following components:
A Managed Metadata service application
A site collection based on the Document Center template
This site collection acts as a content type hub (ContentTypeHub1) that contains the document and document
set content types.
Two consuming site collections that are also based on the Document Center template
The content type hub publishes documents and document set content types to these site collections.
The following illustration shows this example environment before the start of the upgrade process.
SharePoint 2010 farm with content type syndication
Here is more information about this illustration:
The Managed Metadata service application has a Content Type Hub property that is set to point to the
ContentTypeHub1 site collection.
For information about how to share content types, see Plan to share terminology and content types
The following Managed Metadata connection properties are selected:
This service application is the default storage location for Keywords.
This service application is the default storage location for column specific term sets.
Consumes content types from the Content Type Gallery at <URL>.
Push-down Content Type Publishing updates from the Content Type Gallery to sub-sites
and lists using the content type.
For information about connection properties, see Managed metadata connections and Update a
managed metadata service connection.
A document content type (Doc1) and a document set content type (DocSet1) were published from
ContentTypeHub1 to the two consuming sites.
For information about publishing content types, see Publish a content type from a content publishing hub.
Both consuming site collections contain document libraries that use the two content types, and documents
that are based on the two published content types are stored in those libraries.
Back up the data and create a duplicate content type hub in the
SharePoint 2010 environment
If you want to continue to use any of the consuming site collections in the 2010 environment but upgrade others,
you must upgrade your environment so that you have a 2010 version of the content type hub and a 2013 version.
The following illustration and list describe the steps to take to back up the databases and sites in preparation for
upgrade, and to create a duplicate content type hub to continue service site collections in the SharePoint 2010
environment.
Original server farm for SharePoint Server 2010
1. Use SQL Server Management Studio to back up the database for the Managed Metadata service
application.
Name the backup something that you can remember, such as ManagedMetadata2010DB.bak.
2. Use SQL Server Management Studio to back up the database or databases that contain the content type
hub and consuming site collections.
Name the backup something that you can remember, such as 2010ContentHubDB.bak.
3. Use Central Administration or the Backup-SPSite Microsoft PowerShell cmdlet to perform a site collection
backup of the original content type hub.
For more information, see Back up a site collection in SharePoint Server 2010.
Clear the following Managed Metadata connection properties:
Push-down Content Type Publishing updates from the Content Type Gallery to sub-sites and lists
using the content type.
For information about connection properties, see Update a managed metadata service connection.
4. Create a web application to host a duplicate of the content type hub.
For information, see Create a web application (SharePoint Server 2010).
5. Use the Restore-SPSite Microsoft PowerShell cmdlet to restore a copy of the original content type hub.
Use the following syntax:
Restore-SPSite <URL> -path <path>
Where:
<URL> is the URL for the new web application.
<path> is the path of the backup file.
For information, see Restore a site collection in SharePoint Server 2010.
After you restore the site collection, you can change the name to ContentTypeHub2.
6. Use SQL Server Management Studio to back up the database that contains the duplicate content type hub.
You now have SQL Server backups of the databases for the Managed Metadata service application, the consuming
site collections, and a copy of the content type hub (now in a separate database from the consuming site
collections). In the next section, you create and configure the 2013 farm, restore these databases, and upgrade
them to 2013.
Restore databases and upgrade the Managed Metadata service

application and site collections to SharePoint 2013
Now you can create the SharePoint 2013 environment, and restore the databases that you backed up from the
2010 environment. After you restore them in SQL Server Management Studio, you can upgrade the Managed
Metadata service application, upgrade the content databases, and create the site collections.
The following illustration shows the steps to follow to restore and upgrade the databases and site collections to the
2013 environment.
NOTE
Make sure that no other managed metadata service applications are in the 2013 environment.
New SharePoint 2013 farm

1. Use SQL Server Management Studio to restore the databases for the Managed Metadata service
application and the two content databases for the original content type hub (ContentTypeHub1) and
consuming sites, and the duplicate content hub.
2. Use PowerShell to create a Managed Metadata service application and use the restored database. This
upgrades the information from the Managed Metadata service application in the original farm and also
creates a connection (or proxy) for the new Managed Metadata service application (Managed Metadata 1).
For information, see Upgrade the Managed Metadata service application.
3. For the new Managed Metadata connection (proxy), in Central Administration, clear the following
properties:
For more information, see Update a managed metadata service connection.
4. Create a web application to host the upgraded content type hub (ContentTypeHub1) and consuming site
collections. Be sure to use the same authentication method as was used in the 2010 environment.
For information, see Create web applications.
5. Test, and then attach the content database that contains the original content type hub (ContentTypeHub1)
and consuming site collections to upgrade the database.
For information, see Verify custom components and Attach a content database to a web application and
upgrade the database.
NOTE
When you upgrade the content database, the site collections remain in 2010 mode in the 2013 farm. Do not upgrade
the site collections to 2013 mode yet. You upgrade the site collections later in this process.
6. Use the Set-SPMetadataServiceApplication Microsoft PowerShell cmdlet to configure the upgraded

Managed Metadata service application to point to the upgraded content type hub. Use the following syntax:
Set-SPMetadataServiceApplication -Identity "<ServiceApplication>" -HubURI "<HubURI>"
For information, see Set-SPMetadataServiceApplication.

7. Upgrade the ContentTypeHub1 site collection to 2013 mode.
For information, see Upgrade a site.
8. Upgrade the content database that contains the duplicate content type hub (ContentTypeHub2 in the old
farm) and name it ContentTypeHub3. Leave the ContentTypeHub3 in 2010 mode.
For information, see Attach a content database to a web application and upgrade the database.
At this point, you have the following site collections in the 2013 environment:
SITE COLLECTION SITE COLLECTION MODE (VERSION) DESCRIPTION
ContentTypeHub1 2013 mode Content type hub for sites in 2013

mode
ContentTypeHub3 2010 mode Content type hub for sites in 2010

mode
ConsumingSite1 2010 mode Consumes shared content types
ConsumingSite2 2010 mode Consumes shared content types
Create additional Managed Metadata service applications and republish

the content types
Now you are ready to create the Managed Metadata service applications that will serve content type hubs and
consuming site collections running in 2010 mode in both the 2010 farm and the 2013 farm. After you create and
configure those service applications, you share the Managed Metadata service application that is used for sites in
2013 mode (and that also serves as the term store for both farms) (Managed Metadata 1), and the Managed
Metadata service application that is used for sites in the 2010 farm (Managed Metadata 3). After you share the
service applications, you can republish the content types in both farms.
The following illustration shows the steps to create additional Managed Metadata service applications and
republish the content types. All of these steps are performed in the new 2013 farm.
Create Managed Metadata service applications and re-publish content types.
1. In Central Administration, create a Managed Metadata service application (Managed Metadata 2) and set
the Content Type Hub property to the duplicate content type hub in the new farm (ContentTypeHub3).
When you use Central Administration to create a Managed Metadata service application, the Managed
Metadata connection (proxy) is created at the same time as the service application. For more information,
see Create a managed metadata service application.
For the new Managed Metadata connection, clear the following properties:
2. In Central Administration, create a Managed Metadata service application (Managed Metadata 3) and set
the Content Type Hub property to the original content type hub in the 2010 environment
(ContentTypeHub1 in the 2010 farm).
When you use Central Administration to create a Managed Metadata service application, the Managed
Metadata connection (proxy) is created at the same time as the service application. For more information,
see Create a managed metadata service application.
For the new Managed Metadata connection, clear the following properties:
3. Share the Managed Metadata 1 and Managed Metadata 3 service applications to the 2010 environment.
Do not share Managed Metadata 2 with the 2010 environment. It is used only for sites in the 2013 farm.
For more information, see Share service applications across farms in SharePoint Server.
At this stage, the 2010 environment has two additional connections (proxies), one for each service
application that was shared in the previous step.
4. Republish the content types in the 2013 environment:
On the 2013 content type hub that was upgraded to 2013 mode (ContentTypeHub1), republish all of the
content types that were published before (Doc1 and DocSet1).
On the 2013 duplication content type hub that is in 2010 mode (ContentTypeHub3), republish all of the
content types that were published before (Doc1 and DocSet1).
For more information, see Publish a content type from a content publishing hub.
5. Republish the content types in the 2010 environment:
On the 2010 content type hub (ContentTypeHub2), republish all of the content types that were published before
(Doc1 and DocSet1).
Configure connections (proxies)

The final phase in the process is to configure the connections (proxies) for all of the Managed Metadata service
applications.
The following illustration shows the connections (proxies) between the farms and the order in which they are
configured.
Configure connections (or proxies) for the Managed Metadata service applications across the 2010 and
2013 farms
1. On the 2010 farm, on the Manage Service Applications page in Central Administration, set the following
properties for the Connection to the Managed Metadata service (Managed Metadata 3):
This enables ContentTypeHub2 in the 2010 farm to consume content types that are published through the
Managed Metadata 3 service application.
2. On the 2010 farm, on the Manage Service Applications page in Central Administration, set the following
properties for the Connection to the Managed Metadata service (Managed Metadata 1):
This enables ContentTypeHub2 in the 2010 farm to consume terms from the term store in the Managed
Metadata 1 service application.
3. On the 2013 farm, for the connection (Managed Metadata 3) for the 2010 mode content type hub
(ContentTypeHub3), clear the following properties:

This causes ContentTypeHub3 to be unable to consume any resources from the Managed Metadata 3
service application. Managed Metadata 3 is only used to provide content type syndication to the 2010 farm.
4. On the 2013 farm, for the connection (Managed Metadata 2) for the duplicate content type hub
(ContentTypeHub3), select the following properties:

This enables ContentTypeHub3 on the 2013 farm to consume content types that are published through the
Managed Metadata 2 service application.
5. On the 2013 farm, for the connection for the upgraded content type hub (Managed Metadata 1), select the
following properties:
This enables ContentTypeHub1 and any consuming sites in 2013 mode on the 2013 farm to consume
content types that are published through the Managed Metadata 1 service application, and all content type
hubs can consume terms from the term store in the Managed Metadata 1 service application.
Final state
When you have finished, the Managed Metadata connections (proxies) should be as seen in the following
illustration:
New server farm for SharePoint Server 2013
Where:
Managed Metadata 1 is the service application that is used for content type syndication for the consuming
sites in the 2013 farm that are in 2013 mode. This service application is also used for all term store
operations in both the 2010 and 2013 farm.
sites in the 2013 farm that are still in 2010 mode.
sites in the 2010 farm.
Recommendations for how to manage content type syndication across

the 2010 and 2013 farms
Now that you have two environments (2010 and 2013) that share content types, you must be careful how you
manage shared content types when you create or change a shared content type.
When you add a content type, you must make sure that the content type ID is the same on all three Content Type
Hubs. To do this, follow this procedure:
1. On the 2013 farm, on the ContentTypeHub1, manually create the new content type and publish it.
2. Identify the content type ID for that content type.
TIP
You can use Microsoft PowerShell or the object model to extract the content type ID by using code. The content type
ID is also encoded in the URL for the content type in the Content Type gallery. So an easier way to find the content
type ID is to navigate to the Content Type Gallery for a site, and then click the content type. The URL to that content
type contains a parameter, ctype, which is in fact the content type ID for that content type. For example,
ctype=0x010100C0EE90869D5B8B46A4448713A9F8984C.
3. Create a content type that uses that ID on both of the other content type hubs (ContentTypeHub2 and
ContentTypeHub3), and then publish it.
To create a content type that has a specific ID, you can't use the user interface. You have to use XML or the
object model. For more information, see Creating Content Types.
When you add a new field to a content type, make sure that the field ID is the same on all three Content Type
Hubs. To do this, follow this procedure:
1. On the 2013 farm, on the ContentTypeHub1, manually create the new field for the content type and
republish the content type.
2. Use the object model or Microsoft PowerShell to extract the SchemaXML property of the
SPContentType.
3. Add the extracted property to the corresponding content type on both of the other content type hubs
(ContentTypeHub2 and ContentTypeHub3).
4. Republish the updated content type from the other content type hubs (ContentTypeHub2 and
ContentTypeHub3).
The following article on MSDN provides an example of how to use the object model to manipulate content
types: SPContentType class.
Deploy custom features to upgraded site collections
in SharePoint Server 2013

This article describes how to deploy custom features through solution packages to a SharePoint Server 2013 farm
that has been upgraded from SharePoint Server 2010. It includes information and procedures for supported
scenarios. It also introduces feature masking.
Things you need to know

This section describes prerequisite information that you need to know before you start. This includes the following:
Who needs to read this and why
This article is for IT professionals who must work with developers to deploy and maintain full-trust code based
custom features across multiple site collections on a SharePoint Server 2013 farm. You should read this article to
learn how you can use legacy custom features when you upgrade to SharePoint 2013, and what to do to help
ensure that they work seamlessly for your users when site collections are upgraded from compatibility mode. It
links to additional articles that provide more details for your developers.
After a SharePoint Server 2010 farm is upgraded to SharePoint Server 2013, all site collections run in SharePoint
2010 compatibility mode. They remain in this mode until each site collection is upgraded to SharePoint 2013
mode. This way, your users can use the SharePoint Server 2010 user interface and functionality they're familiar
with until you upgrade the individual site collection. You can also use the legacy custom features that you might
have used in SharePoint Server 2010. You eventually will want to upgrade your site collections to SharePoint 2013
mode to take advantage of the new features and functionality it provides. When you make this upgrade, custom
features that worked in SharePoint 2010 compatibility mode might no longer work. You need to make sure that
there is continuity across SharePoint modes with the same features that are being used. This article describes how
to do this.
Microsoft PowerShell cmdlets that you need to be familiar with
For the purposes of this article, you should be familiar with the following Microsoft PowerShell cmdlets:
NAME WHAT DOES THIS DO? EXAMPLE
Add-SPSolution Adds the solution to the farm's solution Add-SPSolution -LiteralPath

store. c:\contoso_solution.wsp
Install-SPSolution Deploys a solution that has been added Install-SPSolution -Identity

to the farm's solution store. contoso_solution.wsp -
GACDeployment -CompatibilityLevel
15
Uninstall-SPSolution Retracts a deployed solution. Uninstall-SPSolution -Identity

contoso_solution.wsp
Remove-SPSolution Removes a deployed solution. Remove-SPSolution -Identity

contoso_solution.wsp
NOTE
For more information about how to use PowerShell and the minimum permissions required to run a PowerShell for
SharePoint cmdlet, see Use Windows Powershell to administer SharePoint 2013.
Overview of deploying a solution package

To understand the following sections, you should understand how a custom feature is deployed to a SharePoint
2013 farm.
When you upgrade from SharePoint Server 2010 to a SharePoint 2013 farm, adding your custom features is an
important step.
Figure: Add custom features in the upgrade process
You can use a solution package to add your customizations to the new farm. A solution package is a distribution
package that delivers your custom SharePoint 2013 development work to the web servers or the application
servers in your server farm. You can use solutions to package and deploy custom features, site templates, web
templates, layout pages, web parts, cascading style sheets, and timer jobs.
To deploy a solution package to a SharePoint 2013 farm, you need to:
1. Add the solution package to the farm. Use the Add-SPSolution PowerShell cmdlet to upload the
SharePoint solution package to the farm. This adds the solution to the farm's solution store, located in the
farm's configuration database.
2. Deploy the solution package to the farm. Use the Install-SPSolution PowerShell cmdlet to deploy the
SharePoint solution package to the farm. This unpacks the solution package and copies all files that are
contained with a custom feature to a "Feature" directory located on the farm's front-end web server. A
subfolder for each custom feature is created and includes a Feature.xml file. This file defines the feature's
base properties and the elements bound to it, as well as one or more element manifest files (elements.xml)
that define the elements that make up the feature.
NOTE
For more information about how to deploy a solution package to a SharePoint 2013 farm, see Install and manage solutions
for SharePoint Server.
The Install-SPSolution PowerShell cmdlet also includes a compatibility-level parameter to deploy the solution
package to locations in the root folder that are designated for either SharePoint 2010 mode or SharePoint 2013
mode site collections. These are the "14" and "15" root folders ( hives), and when you deploy the solution, files such
as features, layout files, images, and control templates are added here.
Figure: SharePoint 2010 and 2013 Root folders
You should also be aware that when you deploy a solution package to a SharePoint 2013 farm, some files are
copied to specific locations regardless of the compatibility level. For more details about where files are copied to,
see Planning Deployment of Farm Solutions for SharePoint 2013.
Site collections in either mode in the farm point to their corresponding hive so that they can use the custom
features that are provided in the solution package.
Figure: Deploy legacy custom features after you upgrade to SharePoint Server 2013
The custom feature might have been tested to work correctly in both SharePoint 2010 and SharePoint 2013 mode.
If so, the feature assembly files can be identical. For example, if the custom feature, Feature1, is known to work in
SharePoint 2013 and SharePoint 2010 modes, the same solution package can be used to deploy the same custom
feature (Feature1) to the "14" and "15" folders.
However, if testing shows that the legacy custom feature might not work in site collections in SharePoint 2013
mode, you might need to make the following changes:
Update the solution package to include conditional logic that enables functionality that is based on
SharePoint site collection mode.
Create a new and separate solution package with updated functionality for the feature when it is used by
upgraded site collections.
Feature masking involves using a new and separate solution package for the same feature for upgraded sites and
site collections (when a feature is scoped to a site or site collection). Feature masking allows upgraded site
collections to automatically find and use the correct custom feature assemblies. This way, your users can seamlessly
use the same custom feature.
Legacy custom features in a SharePoint Server 2013 farm
When you use legacy custom features in a SharePoint 2013 farm, you might find yourself in one of the following
three situations:
The custom feature provided by the solution package currently works for site collections in SharePoint 2010
mode. It also works for site collections in SharePoint 2013 mode.
mode. It also works for site collections in SharePoint 2013 mode. You should also account for additional
custom feature functionality that you might want to incrementally add in the future for site collections in
SharePoint 2013 mode.
mode. But it doesn't work for site collections in SharePoint 2013 mode.
Supported scenarios
When you deploy custom features to a SharePoint 2013 farm that has been upgraded from SharePoint Server
2010, three different deployment scenarios are supported:
Scenario 1 Legacy solution for SharePoint 2010 compatibility mode, and

functionality is expected to remain the same when upgraded
to SharePoint 2013 mode.
Scenario 2 Legacy solution for SharePoint 2010 compatibility mode, but

rebuilt the solution to incrementally add functionality for
SharePoint 2013 mode.
Scenario 3 Legacy solution for SharePoint 2010 compatibility mode, and

build a new solution to implement new functionality for
SharePoint 2013.
NOTE
For details about where solution package files are installed in the farm based on compatibility level, see the TechNet blog
post, Planning Deployment of Farm Solutions for SharePoint 2013.
Scenario 1: Legacy solution for SharePoint 2010 compatibility mode, and functionality is expected to remain the
same when upgraded to SharePoint 2013
In this scenario, the custom feature that is provided through the solution package currently works correctly in site
collections in SharePoint 2010 compatibility mode. Additionally, it's expected to work when the site collection is
upgraded to SharePoint 2013 mode. For example, a custom Web Part was created for SharePoint 2010. It was
tested to work in SharePoint 2013 without a change to the code. You know that you can add it to your SharePoint
2013 farm, and it works for users in site collections in SharePoint 2010 compatibility mode and when you upgrade
the site to SharePoint 2013.
Because the custom feature is expected to work in both SharePoint modes, you can use the same custom feature
assemblies. However, it's important to deploy the solution package for both SharePoint modes, which you can do
with a parameter when you're using the Install-SPSolution cmdlet. Feature masking is not used in this scenario
because site collections in both modes use the same code (duplicate feature assemblies located in the
corresponding 2010 and 2013 mode folders).
The steps for this scenario include the following:
1. Create the solution package containing the custom feature.
2. Add the solution package to the farm. You can do this through the Add-SPSolution PowerShell cmdlet. For
example:
Add-SPSolution -LiteralPath c:\Solution.wsp
3. Deploy the solution package.

4. Deploy the solution package for SharePoint 2010 compatibility. You can do this by using the Install-
SPSolution PowerShell cmdlet. Make sure to set the -CompatibilityLevel parameter to 14. For example:
Install-SPSolution -Identity Solution.wsp -CompatibilityLevel 14 -GAC …
NOTE
The -CompatibilityLevel parameter in Install-SPSolution Windows PowerShell cmdlet also allows you the option to install a
solution package to both the 14 and 15 root directories at the same time. You can do this by using the values of "14,15" or
"All". For example: > Install-SPSolution -Identity Solution.wsp -CompatibilityLevel 14, 15 -GAC … > For more
information about the CompatibilityLevel parameter in the Install-SPSolution Windows PowerShell cmdlet, see Install-
SPSolution .
NOTE
When you use the Install-SPSolution command to install both SharePoint modes, use the same solution name and ID.
Scenario 2: Legacy solution for SharePoint 2010 compatibility mode, but rebuilt the solution to incrementally
add functionalities for SharePoint 2013
In this scenario, the custom feature works correctly in SharePoint Server 2010. You want to build a solution
package by adding this feature to a SharePoint 2013 farm, but you also want to make sure that you can
incrementally add functionality for site collections in SharePoint 2013 mode that are using this solution package.
For example, a custom Web Part was created for SharePoint 2010. It was tested to work in SharePoint 2013
without a change to the code. However, you know that you might want to add additional functionality for your
SharePoint 2013 users, but you still want to use the same feature assemblies to allow for backward compatibility.
Because the custom feature is expected to work in both SharePoint modes, you can use the same custom feature
assemblies. You must install the solution package for both SharePoint modes as you did for the previous scenario.
The key difference in this scenario is that the solution package must include logic that enables feature functionality
that is conditionally based on site collection compatibility.
For example, let's say you have a method named Sample() implemented in a custom feature that was designed for
SharePoint 2010. If you want to change its implementation in SharePoint 2013 mode, your code should include
conditional logic that uses the SPSite.CompatibilityLevel property:
void Sample()
{
if (site.CompatibilityLevel == 14) { /*Existing O14 implementation*/}
else {/*New O15 implementation*/}}
}
By doing this, the same feature assembly serves both SharePoint 2010 and SharePoint 2013 versions of the
feature. Feature masking isn't used in this scenario either because you're not only using the same feature assembly
but also the same solution package. The same files for the custom feature are copied to the "14" and "15"
\Template\Features directories. For more information, see the "Planning Considerations" section of the TechNet
blog post, Planning Deployment of Farm Solutions for SharePoint 2013.
1. Create the solution package containing the custom feature. Include conditional logic that enables feature
functionality that is based on site collection compatibility.
2. Add the solution package to the farm. You can do this by using the Add-SPSolution PowerShell cmdlet.
For example:
Add-SPSolution -LiteralPath c:\Solution.wsp
3. Deploy the solution package.

5. Install the solution package for SharePoint 2013 compatibility. You can do this by using the Install-
NOTE
The CompatibilityLevel parameter in Install-SPSolution Microsoft PowerShell cmdlet also allows you the option to install a
solution package to both the 14 and 15 root directories at the same time. You can do this by using the values of "14,15" or
"All". For example: > Install-SPSolution -Identity Solution.wsp -CompatibilityLevel 14, 15 -GAC … > For more
information about the -CompatibilityLevel parameter in the Install-SPSolution Microsoft PowerShell cmdlet, see Install-
SPSolution .
NOTE
When you use the Install-SPSolution command to install for both SharePoint modes, use the same solution name and ID.
Scenario 3: Legacy solution for SharePoint 2010 compatibility mode, and build a new solution to implement new
functionalities for SharePoint Server 2013
In this scenario, the custom feature is known to work correctly in SharePoint Server 2010, but it's known not to
work in SharePoint 2013. You need to create a new and separate solution package in which the functionality of the
custom feature has been fixed to work correctly in SharePoint 2013. In this scenario, you have two different
solution packages with different feature assemblies. This scenario uses feature masking. As users are moved from
compatibility mode to SharePoint 2013, they are "masked" from the fact that the custom feature they are using has
moved from one different code base to another.
In this scenario, you need to add and deploy two separate solution packages that contain two different feature
assemblies. Both versions of the feature must have the same name, feature ID, and feature manifest location, even
though the feature assemblies and resources are different.
Feature masking requirements
SOLUTION PACKAGE - 2010 SOLUTION PACKAGE - 2013

REQUIREMENT SAME OR DIFFERENT MODE EXAMPLE MODE EXAMPLE
Solution package names Different POC14 POC15
Solution package IDs Different 000000-0000-0000-0000- 11111111-1111-1111-

000000000000 1111-111111111111
Feature name Same Feature1 Feature1

SOLUTION PACKAGE - 2010 SOLUTION PACKAGE - 2013
REQUIREMENT SAME OR DIFFERENT MODE EXAMPLE MODE EXAMPLE
Feature ID Same 12345 12345
Feature XML folder names Same POC15\Features\Feature1.fe POC15\Features\Feature1.fe

ature\ ature\
Feature manifest location Same POC15_Feature1\Feature1.T POC15_Feature1\Feature1.T

emplate.xml emplate.xml
Figure: Solution packages for feature masking

1. Create two different solution packages with different names. The versions of the feature that you're
deploying must have the same feature name and ID.
2. Add the solution package for SharePoint 2010 compatibility to the farm. You can do this through the Add-
SPSolution PowerShell cmdlet. For example:
Add-SPSolution -LiteralPath c:\POC14.wsp
3. Add the solution package for SharePoint 2013 compatibility to the farm. You can also do this through the
Add-SPSolution PowerShell cmdlet. For example:
Add-SPSolution -LiteralPath c:\POC15.wsp
4. Deploy the solution package for SharePoint 2010 compatibility. You can do this through the Install-
Install-SPSolution -Identity POC14.wsp -CompatibilityLevel 14 -GAC …
5. Install the solution package for SharePoint 2013 compatibility. You can also do this through the Install-
Install-SPSolution -Identity POC15.wsp -CompatibilityLevel 15 -GAC …
Uninstalling a solution package
You will no longer need the legacy solution package you deployed for SharePoint 2010 compatibility mode site
collections once all site collections have been upgraded to SharePoint 2013 mode. When this happens, the legacy
solution package can be retracted and removed from your SharePoint Server 2013 farm. You can do this through
the Uninstall-SPSolution and Remove-SPSolution PowerShell cmdlets.
IMPORTANT
We recommend using the Uninstall-SPSolution PowerShell cmdlet when retracting a solution from a SharePoint Server
2013 farm. Retracting a solution through Central Administration will retract the solution from both the SharePoint 2010 and
SharePoint 2013 root folders by default. This is especially important to note when you are using feature masking to deploy a
custom feature.
To retract and remove the solution package:

1. Retract the SharePoint 2010 mode solution package from the farm: You can do this through the Uninstall-
SPSolution Windows PowerShell cmdlet. For example:
Uninstall-SPSolution -Identity POC14.wsp -CompatibilityLevel 14
IMPORTANT
Make sure to use the CompatibilityLevel parameter to " 14 " to retract the solution package for 2010 compatibility
mode only. For example: Uninstall-SPSolution POC14.wsp -CompatibilityLevel 14
2. Remove the solution package from the farm's solution store: You can do this through the Remove-
SPSolution PowerShell cmdlet. For example:
Remove-SPSolution -Identity POC14.wsp
Other Considerations
This section includes information on additional considerations, including the following:
Deploy a feature in site collections using mixed mode
Master Page considerations
Deploy a feature in site collections using mixed mode
If your custom feature is farm or web application scoped, you can deploy it even though not all site collections
within the farm or web application have been upgraded to SharePoint 2013 compatibility mode.
For web application scoped features, if the root site collection has not been upgraded, you won't be able to activate
the feature using the Install-SPSolution PowerShell cmdlet. You must instead use the SharePoint Central
Administration site to activate the feature.
Master Page Considerations
Regarding branding customizations, custom master pages are reset by default to seattle.master after a site
collection upgrade in SharePoint 2013. If you are using the feature masking scenario, you need to reset any custom
master pages that you have created for SharePoint 2013 site collections. For details about how to do this, see the
MSDN article Use Feature upgrade to apply new SharePoint Server 2013 master pages when upgrading from
SharePoint 2010.
NOTE
For more information about the branding considerations you need to make when you upgrade site collections in SharePoint
2013, see Branding issues that may occur when upgrading to SharePoint 2013.
See also
Other Resources
Create a plan for current customizations during upgrade to SharePoint 2013
SharePoint 2013 and SharePoint Online solution pack for branding and site provisioning
Branding issues that may occur when upgrading to SharePoint 2013

Microsoft periodically releases software updates for SharePoint 2013. The following articles and related resources
provide information about the software update process for SharePoint 2013.
CONTENT DESCRIPTION
Software updates overview for SharePoint Server 2013 Provides an overview of the software update process for
SharePoint 2013.
Prepare to deploy software updates for SharePoint 2013 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 for SharePoint Server Learn how to install a software update on servers in a
SharePoint farm.
Update Workflow in SharePoint Server Learn the steps required to keep workflow up to date in
Software updates overview for SharePoint Server
2013

Administrators update SharePoint 2013 to deploy or update assemblies that provide functionality and to upgrade
databases. A successful update follows a methodical approach that minimizes interruptions in service. Review
information in this article to learn about the process before you begin the update process.
Before you begin

requirements, and software requirements.
Terminology
To understand how to implement software updates in SharePoint 2013, it is important to understand the
terminology for the core components.
Term Definition Comment
Cumulative Update (CU) A CU is a rollup update that contains all

previous critical on-demand hotfixes to
date. Additionally, a CU contains fixes
for issues that meet the hotfix
acceptance criteria. These criteria may
include the availability of a workaround,
the effect on the customer, the
reproducibility of the problem, the
complexity of the code that must be
changed, or other reasons.
patch A compiled, executable installer file that

contains updates to one or more
products. Examples of packages are the
executable (.exe) files that you
download to install a service pack,
cumulative update (CU), or hotfix.
Packages are also known as MSI files.
software update A software update is any update,

update rollup, service pack, feature
pack, critical update, security update, or
hotfix that is used to improve or to fix a
software product that is released by
Microsoft Corporation.
upgrade Process by which you change an In SharePoint 2013, for build-to-build
environment to use a newer version of upgrades, you can use either in-place or
software. You can upgrade to a minor database-attach methods. For version-
release, such as an update or patch, or to-version upgrade, only database-
to a major release. An upgrade to a attach is supported. For more
minor release is called a build-to-build information about version-to-version
upgrade. An upgrade to a major release upgrade, see Overview of the upgrade
is called a version-to-version upgrade. process from SharePoint 2010 to
SharePoint 2013. For an overview of
the steps for in-place and database-
attach upgrade for build-to-build
upgrades, see Install a software update
(SharePoint 2013)
For a complete list of terminology about software updates, see Description of the standard terminology that is
used to describe Microsoft software updates.
Features
SharePoint 2013 has features that facilitate the end-to-end software update experience. Some of these features are
as follows:
Backward compatibility between an updated services farm and non-updated content farm.
There is full support for automatic updates that use Windows Server Update Services (WSUS ), Windows
Update, and Microsoft Update.
NOTE
An automatic update copies the binary files to the farm servers, but you must complete the software update by
running the upgrade on the servers.
Administrators can use the SharePoint Central Administration website or Microsoft PowerShell to monitor
the status of an update.
Intended audience and scope

Information in this article is for all IT professionals who maintain SharePoint 2013. However, specific instructions
to install a software update are intended for IT professionals who have to deploy software updates on a farm of
servers that host SharePoint 2013.
Information in this article applies to the following products:
SharePoint 2013
SharePoint 2013 language pack
Microsoft Filter Pack
NOTE
The process that installs software updates in stand-alone environments of SharePoint 2013 is a simpler process than the
process that installs software updates in a server farm and does not require all the steps that are required for a server farm.
Software update process

The process that deploys updates in a SharePoint 2013 environment is a two-phase process: patching and build-
to-build upgrade.
Each phase has specific steps and results. It is possible to postpone the build-to-build upgrade phase.
Cau t i on
Although we try to ensure the highest level of backwards compatibility, the longer you run in such a state, the
greater the chance of finding a case where farm behavioral issues might occur.
Patch phase
The patch phase has two steps, the patch deployment step and the binaries deployment step. During the patch
deployment step, new binary files are copied to the server running SharePoint 2013. Services that use files that the
patch has to replace are temporarily stopped. Stopping services reduces the requirement to restart the server to
replace files that are being used. However, in some instances you have to restart the server.
The second step in the patch phase is the binaries deployment step. In this step, the installer copies support
dynamic link library (.dll) files to the appropriate directories on the server that is running SharePoint 2013. This
step ensures that all the web applications are running the correct version of the binary files and will function
correctly after the update is installed. The update phase is complete after the binaries deployment step.
The next and final phase to deploy software updates is the build-to-build upgrade phase. This phase modifies
database schemas, updates objects in the farm, and updates site collections.
Build-to -build upgrade phase
After you finish the patch phase, you must complete the update installation by starting the build-to-build upgrade
phase. The build-to-build upgrade phase is task intensive and, therefore, takes the most time to finish. The first
action is to upgrade all the SharePoint processes that are running. After you upgrade the processes, the databases
are crawled and upgraded. After you complete a farm upgrade on one server, you have to complete the process on
all other servers to maintain incompatibility.
Software update strategy

The update strategy that you select is based primarily on one of the following factors:
The amount of downtime that is acceptable to install the update.
The additional staff and computing resources that are available to reduce downtime.
As you determine 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.
Software update deployment cycle

The cycle that is used for upgrading SharePoint 2013 farms and servers also applies to deploying software
updates, which are a subset of an upgrade phase. We recommend that you use the update cycle in the following
illustration as a guide to deploy software updates.
Learn
During this phase of the cycle, you learn about requirements 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 for SharePoint 2013. 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 the strategy that you want to use to update the farm. Depending on your requirements, you can use
one of the following strategies:
In-place
Database-attach
For more information about the update strategy to use, see Install a software update (SharePoint 2013)
Downtime reduction
Research and assess the options that are available to reduce downtime. First, check for 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 additional time into your schedule. Consider
using read-only content databases and doing parallel upgrades to reduce downtime.
Common issues
Identify and address common issues such as missing or out-of-date dependencies and lack of space on the servers
where you will install the update.
Prepare
To prepare for the software update, document the environment and plan an update strategy to ensure that the
update will go as planned in the expected downtime window.
You document the environment 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 Microsoft 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 ExportIPFSAdminObjects command to collect and export InfoPath
administrator deployed forms only.
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 an upgrade to SharePoint 2013.
The two final requirements for the update strategy are a communication plan and an update schedule.
It is important to communicate with site owners and users about what to expect during an upgrade. An
administrator should inform users 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 for
the upgrade to SharePoint 2013.
Create a benchmark schedule for update operations that contains the start times of operations that are 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.
Stop the upgrade and resume operations in the non-upgraded farm.
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 ready for updates
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 ready for
updates:
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 SharePoint 2013 to find potential issues.
Build a test farm
Build a test farm that represents 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 in 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 determines 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
Deploy customizations
Use solutions whenever possible so that you can deploy individual files or components.
Reduce downtime
Reduce downtime by using techniques such as read-only databases and update parallelism. For more information,
see the "How to minimize downtime during upgrade" section in Determine strategy for upgrade to SharePoint
2013.
Monitor progress
The refined techniques that you use to monitor the software update in the test environment apply when you
deploy the update in the production environment. Use the Upgrade and Migration page in Central
Administration to monitor available status indicators. 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, when you use
Central Administration to monitor updates, you can identify farm servers that you must update.
The following tables describe the status information that is available in Central Administration.
No action required Farm server does not currently require No hyperlink

any action to be taken by the
administrator.
Installation required Farm server is missing an .msi file that Hyperlink to the Patch Deployment
is set to mandatory for all farm servers State page
or has a patch level below the individual
farm-wide effective patch version.
Upgrade in progress Farm server is currently undergoing an Hyperlink to the Upgrade Status page
upgrade operation.
Upgrade available Farm server is running in backward- Hyperlink to the Upgrade and
compatibility mode. Migration page
Upgrade required Farm server is outside the backward- Hyperlink to the Upgrade and
compatibility mode range with one or Migration page
more databases.
Upgrade blocked If an upgrade is available and any farm Hyperlink to the Patch Deployment
server requires installation, the State page
remaining servers that do not require
installation will be set to this status
unless they are currently undergoing an
upgrade.
Installed Indicates that no action is required Not applicable
Missing/Required Displayed if a product is required on Not applicable

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 Not applicable

on each server
Superseded Displayed if an update is no longer Not applicable

required on a server because a newer
patch supersedes it
Log files and PowerShell commands are other tools to monitor the update process.
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, communicate this information
to users of the farm.
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 issues that occurred during the deployment. Resolve these issues and then
resume or restart the update as appropriate. For more information about event log files, see Configure diagnostic
logging in SharePoint Server.
User interface or experience issues
Any user interface or user experience issues will surface on site pages. These issues mainly occur during a version-
to-version upgrade. Look for the following issues:
Unghosted files that are, ASP.NET (.aspx) pages that a user has modified within the site collection, and now
behave differently than expected or have rendering issues caused by recent upgrades of the files on the
server.
User interface version mismatch
HTML and XHTML compliance
Other 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 you can troubleshoot minor issues and then resume or restart the update. Be prepared to roll back
the update if you cannot resolve issues.
Prepare to deploy software updates for SharePoint
2013

This article describes the required and recommended tasks to complete before you install software updates on
servers in a SharePoint 2013 farm.
Read and follow these sections sequentially to prepare for updates:
Verify account permissions and security settings
Determine an update approach
Back up 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 the security settings that are in place on the farm.
For more information, see Account permissions and security settings in SharePoint 2013.
Determine an update approach

There are two basic options for deploying a software update on a farm: in-place and database-attach.
NOTE
Because the action of installing a software update is related to a software upgrade, documentation about software upgrades
applies to deploying software updates.
Here are the differences between the two update approaches:

In-place update: This approach is easier. With this method, the amount of required downtime 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 - You install an update on all the farm servers at the same
time and upgrade content. Backward compatibility between update versions on different servers
enables you to install the update binary files and postpone update completion to a later time. You
cannot reduce downtime using this method. It depends entirely upon the size and complexity of the
farm.
In-place with backward compatibility - You install an update in stages and use postponed upgrade
(that is, do not run the upgrade process on the databases or site collections) with backward
compatibility to reduce downtime.
Database attach: This approach is more complex than an in-place update, and it requires more personnel
and hardware resources. This update method uses a new farm to install updates while users continue to
work with existing content on the original farm.
When you use either the in-place with backward compatibility method or the database-attach method, you can use
a postponed upgrade. You can choose to upgrade the content databases 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, to determine an update approach to use.
You can use either the SharePoint Products Configuration Wizard or Microsoft PowerShell cmdlets to upgrade
your content with any method that you choose to use to update your servers
Back up the environment

To ensure that you can recover the existing environment if an update fails, we recommend that you back up the
SharePoint 2013 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 you can back up
individually:
Configuration settings
Web applications
Search
Secure store service
Site collections
Logs
Apps
For more information about how to determine what you need to back up and the method to use, see Prepare to
back up and restore farms in SharePoint Server. After you determine the farm elements that you will back up, refer
to the articles listed in Backup solutions in SharePoint Server. These articles provide detailed instructions and
guidance to back 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.

Be sure to document the farm, including all custom components in the farm, in case you need to rebuild. For more
information about how to create an inventory of customizations, see Create a plan for current customizations
during upgrade to SharePoint 2013. In addition, document unique things about your farm, such as the following:
Large lists
Sites that have large access control lists (ACLs)
Sites that are critical to your organization
Setting for alternate access mappings
Internet Information Services (IIS ) settings that apply to the web application (that is, URL, port numbers,
and so on.)
Web application security (web application policies and authorization providers)
Web.config
Changes to Docicons.xml and AllowedFileTypes
Other service or web application related settings that you have customized
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
Language packs
All these items are updated separately from an update of SharePoint 2013. 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 2013. Language packs are usually only updated when service packs are released.
Obtain the software update and prepare the installation source

(optional)
If the servers on which you want to install SharePoint 2013 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 complete 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:
/extract:
The /extract switch prompts you to provide a folder name for the files. Here's an example of a folder name
for x64 systems:
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 save
to media or save as an ISO file.
Slipstream package
SharePoint farm deployments require that all servers have the same patch level when joining the farm. It may also
be desired to have a specific patch level when building a new farm. To do this, the update packages can be
slipstreamed into the SharePoint installation media. The steps to slipstream an update are outlined below.
Copy the SharePoint installation media to a read-write location, such as the local disk of the SharePoint
server, for example, C:\SharePointInstall.
Within the extracted SharePoint installation folder, there is an Updates folder, C:\SharePointInstall\Updates.
This is the folder where the slipstreamed packages will reside.
Download the necessary package(s) to bring the new server to the desired patch level.
Extract each package to the target location. This can be done via the Command Prompt/PowerShell using
the following example.
ubersrv2013-kb4092476-fullfile-x64-glb.exe /extract:C\SharePointInstall\Updates
With the extraction complete, run the Setup from the installation location, C:\SharePointInstall\setup.exe . Setup
will automatically apply the update during the installation process of SharePoint.
See also
Other Resources
Before you begin

requirements, software requirements, and update processes.
Software updates overview for SharePoint 2016
Prepare to deploy software updates for SharePoint 2016
NOTE
While the steps in this article refer to SharePoint Server 2016, they are applicable to SharePoint Foundation 2013,
SharePoint Server 2013, and SharePoint Server 2019 unless otherwise noted.
To perform the procedures in this article, you must have the following memberships and roles:
securityadmin fixed server role on the SQL Server instance
db_owner fixed database role on all databases that are to be updated
Local administrator on the server on which you run the Microsoft PowerShell cmdlets
Before you install an update, verify that the following conditions are satisfied:
All front-end web servers are load balanced together and are in rotation with the load balancer.
All farm servers are operating properly. For Search, you can view server status by using the Microsoft
PowerShell cmdlet Get-SPEnterpriseSearchStatus or by going to Central Administration > Manage
Service Applications > Search_service_application_name.
All databases are active and operating properly.
Do not start the update if any of the preceding conditions are not satisfied. Resolve all issues before you
continue.
SharePoint Server 2016 can handle certain upgrade failures after the patching phase finishes. However, if the
build-to-build upgrade fails, you might have to restore from a backup. Therefore, make sure that you perform a
full backup before you start the update process. After the restore is complete, you can resume the update.
Completed tasks do not run again. For more information, see the following resources:
Determine the update strategy

Before you start to deploy a software update, verify that the update strategy that you plan to use is optimal for
your SharePoint Server 2016 environment. There are several factors, such as downtime reduction, cost, and
complexity that determine the strategy to use to deploy a software update. For more information about how the
database-attach process works, see the diagrams in Overview of the upgrade process from SharePoint 2013 to
NOTE
Certain links in this article go to content that is about version-to-version upgrade rather than build-to-build upgrade.
However, the general process is similar for the two types of upgrade. For example, the database upgrade phase is
essentially the same for build-to-build upgrade and version-to-version upgrade.
Monitor installation progress

Monitor the process that deploys updates to verify that the update is proceeding as planned. There might be
issues that block the update or that 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 page in Central Administration as the primary tool
to view product and patch installation status, data status, and update status in real time.
After Setup runs, you can also view the log files and use Microsoft PowerShell to check installation progress.
Initial state
The following illustration shows the farm topology that is used as an example for each patching scenario that is
described in this article.
When you are ready to continue, perform only one of the following procedures in this article to install the
update:
Use the database attach method for high availability of existing content

In this scenario you disable incoming requests to the front-end web servers, thus effectively shutting down the
entire farm. Then you install the update on all the farm servers. This strategy combines the update and the build-
to-build upgrade phase that is described in the Software updates overview for SharePoint Server 2016 section
of Overview of the upgrade process from SharePoint 2013 to SharePoint Server 2016.
illustration as a guide as you go through the steps in the procedure that follows ("To install an update without
backward compatibility").
To install an update without backward compatibility

1. Notify users that the farm will not be available while you are installing the update.
2. Remove all 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.
3. Run the update executable file to install the update on the application server that hosts Central
Administration (APP -1).
4. Run the update executable file to install the update on all other application servers that host Search
components (APP -2). To do this, perform the procedure Host Search components which appears later in
this article, and then return to the next step in this procedure. Do not run the SharePoint Products
Configuration Wizard on these servers at this time.
5. Review the upgrade log files to verify that all the application servers were updated successfully.
The upgrade log file and the upgrade error log file are located at
%COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\16\LOGS. Upgrade log file
names are in the following format: Upgrade-YYYYMMDD -HHMMSS -SSS.log, where YYYYMMDD is the
The upgrade error log file combines all errors and warnings in a shorter file that is named
Upgrade-YYYYMMDD -HHMMSS -SSS -error.log.
6. Log on to the first web server (WEB -1).
7. Run the executable file to install the update on the web server.
8. Run the executable file to install the update on the remaining web servers (WEB -2, WEB -3, and WEB -4).
9. Review the upgrade log files to verify that all the web servers were updated successfully.
10. Run the SharePoint Products Configuration Wizard on the Central Administration server (APP -1). This
will upgrade the configuration database and upgrade each content database. For information about how
to run the wizard, see Install SharePoint Server 2016 across multiple servers in the article Install
11. Run the SharePoint Products Configuration Wizard on the other application servers.
12. Run the SharePoint Products Configuration Wizard on the first web server (WEB -1).
NOTE
Run the configuration wizard to ensure that if an update fails for a specific server, the error is not propagated to
the other web servers. For example, a failed update for one server could make the update fail for one or more site
collections.
13. Repeat the preceding step for each remaining web server.
Server 2016.
15. 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.
16. Notify users that the farm is available. You are finished installing the update and using this article.

This scenario takes advantage of the backward compatibility of SharePoint and the deferred upgrade feature to
reduce the farm 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 database content is being upgraded.
This update scenario uses two phases to install the update on farm servers. These phases are as follows:
1. Install the update on the farm servers.
2. Perform a build-to-build upgrade to complete the patching process.
IMPORTANT
During the update phase, the farm can continue to be in production with minimal downtime. However, during the build-
to-build upgrade phase, the farm will be unavailable. If users 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, see the Software updates overview for SharePoint Server 2016 section in Overview of
the upgrade process from SharePoint 2013 to SharePoint Server 2016.
Update phase
illustration as a guide as you go through the steps in the following procedure, "To install the update".
To install the update

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. On each web server that is out of the load-balancing rotation (WEB -1 and WEB -2), run the executable file
to install the update. Do not run the SharePoint Products Configuration Wizard on these servers. Verify
that these web servers were updated successfully by reviewing the upgrade log files.
The upgrade log file and the upgrade error log file are located at
%COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\16\LOGS. Upgrade log file
names are in the following format: Upgrade-YYYYMMDD -HHMMSS -SSS.log, where YYYYMMDD is the
The upgrade error log file combines all errors and warnings in a shorter file that is named Upgrade-
YYYYMMDD -HHMMSS -SSS -error.log.
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.
4. Add the updated web servers (WEB -1 and WEB -2) back into the load-balancing rotation.
5. On each web server that is out of the load-balancing rotation, run the executable file to install the update.
Do not run the SharePoint Products Configuration Wizard on these servers at this time. Verify that both
of the web servers were updated successfully by reviewing the upgrade log files.
6. Add the updated web servers (WEB -3 and WEB -4) back to the load-balancing rotation.
7. Install the update on all application servers that host Search components (APP -1 and APP -2). To do this,
perform the procedure Install a software update for SharePoint Server 2016 which appears later in this
article, and then return to the next step in this procedure. Do not run the SharePoint Products
Configuration Wizard at this time.
8. If your farm has additional application servers that do not host Search components, run the update
executable file to install the update on these servers. Do not run the SharePoint Products Configuration
9. Review the upgrade log files to verify that these application servers were updated successfully.
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 steps that upgrade the farm servers to finish the patching process. During
this process, the sites that are being upgraded will not be available to users.
Use the preceding illustration as a guide to follow the steps in the following procedure.
IMPORTANT
Monitor the status of the upgrade on each server before you upgrade the next server in the sequence. We recommend
that you create a backup of the farm before you begin to 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 (step 8 in the following 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 3 and 4 in the following
procedure) each time and then resume farm operation (step 8 in the following procedure). You can repeat
the process over successive outage windows until you upgrade all content 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 SQL Server volume at a time. Start the
upgrade for each content database that will occur in parallel several minutes apart to prevent lock
contention as the upgrade process starts. In addition, limit the number of content databases that you
upgrade on a single web server or application server. Each additional upgrade process will consume a
relatively large amount of resources. The typical number of content databases that you can upgrade per
web server 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 server 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 PowerShell cmdlets to upgrade specific service
applications. Notes for a software update might indicate that you have to upgrade a specific service so
that it will continue to operate after patching. This applies to a service that cannot operate in backward
compatibility mode, for example.
You can create a short offline period to upgrade the service without having to upgrade the complete farm.
The additional PowerShell cmdlets to upgrade specific service applications should be in the notes if this is
required.
3. (Optional) Use the PowerShell Upgrade-SPContentDatabase cmdlet to upgrade each content
database. For more information, see Upgrade-SPContentDatabase.
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. On the Central Administration server (APP -1), do one of the following:

Run the following commands at the PowerShell command prompt:
cd \Program Files\Common Files\Microsoft Shared\web server extensions\16\bin
secureresources
IMPORTANT
The SharePoint Products Configuration Wizard also starts an immediate upgrade of the configuration database and all
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.
remaining application server (APP -2).
web servers (WEB -1 to WEB -4).
2013.
8. 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. You
install the update on a new farm and route user traffic to the new farm after updates are complete.
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 Upgrade content databases from SharePoint 2013 to
Use the preceding illustration as a guide to follow the recommended steps in the following procedure.
To install the update by using the database-attach method
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 Create the SharePoint 2016 farm for a database attach upgrade.
NOTE
If the original farm uses a database mirror, configure mirroring after you deploy 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, 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 Upgrade content databases
from SharePoint 2013 to SharePoint Server 2016 and Run a farm that uses read-only databases in SharePoint
Server.
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.
NOTE
Steps 4 through 14 do not apply to SharePoint Foundation 2013, SharePoint Server 2016, and SharePoint Server
2019.
4. If you are patching the User Profile Service service application database, you must export the User Profile
Synchronization Service encryption key from the old database and then import the key to the new
database. This key is also known as the Microsoft Identity Integration Server (MIIS ) key, the
Synchronization Service encryption key, and the Forefront Identity Manager 2010 (FIM 2010) key. If you
do not export and then import the key correctly, the Synchronization Service will not start. To export the
encryption key, complete these steps:
5. Use farm administrator credentials to log on to the computer that contains the old User Profile Service
miiskmu.exe /e <Path>
Where <Path> is the full path of the file to which you want to export the key.
8. Back up the content databases on the existing farm. For more information, see Plan for backup and
recovery in SharePoint Server.
9. To import the encryption key, perform these steps:
10. Use farm administrator credentials to log on to the computer that contains the new User Profile Service
11. Attempt to start the User Profile Synchronization service. Because you have not yet imported the
encryption key, the service will not start. Confirm that the service did not start by using the ULS log or by
making sure that the status of the service is Stopped.
miiskmu.exe /i <Path> {0E19E162-827E -4077-82D4-E6ABD531636E }
Where <Path> is the full path of the file to which you exported the key.
14. (Optional) To check that the encryption key was imported correctly, at the command prompt, type the
following command, and then press Enter:
miiskmu.exe /c {0E19E162-827E -4077-82D4-E6ABD531636E }
15. Restore the content databases to the new database server.
16. Create service applications on the new farm for each existing service application in the old farm.
Duplicate all the settings from your existing farm.
17. Use the database-attach method to create the databases on the new farm. For more information, see
Upgrade databases from SharePoint 2013 to SharePoint Server 2016 and Attach and restore read-only
18. Verify that there are no issues with the new farm.
19. 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.
20. Allow time for users to switch from cached DNS, and then decommission the old farm.
2016.
Install a software update on servers that host Search components

Perform the procedures in this section only when they are pointed to from other procedures in this article. This
includes the following procedures which are in this section:
1. Pause the Search service application by typing the following commands at the PowerShell command prompt:
2. On each server that hosts one or more Search components, stop the Search-related Windows services in
3. SPTimerV4
4. OSearch16
IMPORTANT
6. On each server that hosts one or more Search components, run the update executable file to install the
update.
7. On each server that hosts one or more Search components, start the Search-related Windows services in
9. OSearch16
10. SPTimerV4
11. Verify that all Search components become active after the update by typing the following command at the
Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where {$_.State -ne "Active"} | fl
Rerun the command until no Search components are listed in the output.
6. Resume the Search service application by typing the following command at the PowerShell command
prompt:
7. Verify that the farm is crawling updated content and able to index new and modified documents. To do this,
you can add or modify an item in a site collection, perform a crawl for the Local SharePoint sites content
source, and then perform a search for the item and verify that it appears in the search results.
1. Divide the servers that host Search components into two availability groups to minimize downtime
during their update and build-to-build upgrade. (As long as one of the groups is active and healthy, the
farm can serve queries and crawl and index content.) For instructions about how to divide the servers into
two availability groups, see the procedure Determine server availability groups for update with
minimal downtime later in this article.
2. Pause the Search service application by typing the following command at the PowerShell command
prompt:
3. On each server in server availability group 1, stop the Search-related Windows services in the following
order:
4. SPTimerV4
5. OSearch16
IMPORTANT
8. On each server in availability group 2, stop the Search-related Windows services in the same order that
was prescribed for stopping them for availability group 1. Again, it is important to verify that each service
is stopped before you stop the next service.
9. On each server in availability group 1, start the Search-related Windows services in the following order:
11. OSearch16
12. SPTimerV4
output.
9. On each server in availability group 2, start the Search-related Windows services in the same order that
was prescribed for starting them for availability group 1.
output.
11. Resume the Search service application by typing the following command at the PowerShell command
prompt:
12. Verify that the farm is crawling updated content and able to index new and modified documents. To do this,
you can add or modify an item in a site collection, perform a crawl for the Local SharePoint sites content
source, and then perform a search for the item and verify that it appears in the search results.
1. Start a SharePoint 2016 Management Shell on any server in the farm.
2. Determine the primary Search administration component and the server that hosts the component by
typing the following commands at the PowerShell command prompt:
Get-SPEnterpriseSearchStatus -SearchApplication $ssa | where { (($_.State -ne "Unknown") -and ($_.Name -
match "Admin")) } | ForEach {if (Get-SPEnterpriseSearchStatus -SearchApplication $ssa -Component $_.Name -
Primary) { Get-SPEnterpriseSearchTopology -SearchApplication $ssa -active | Get-SPEnterpriseSearchComponent
-identity $($_.Name) } }
3. Determine the set of servers in availability group 1. These servers must fulfill the following three
requirements:
The set must contain one or more, but not all, of the following types of Search components:
Crawl component
Index component
The set must contain one or more, but not all, of the index components for each index partition.
The set must contain a Search administration component that is not the primary component that was
identified in step 2 in this procedure.
4. Determine the set of servers in availability group 2. This set must contain all remaining servers that host
Search components, including the server that hosts the primary Search administration component that was
identified in step 2 of this procedure.
Install a software update on servers that host Distributed Cache

Prior to restarting a server from running a software update or Configuration Wizard, you must stop Distributed
Cache to prevent unallocated cache fractions. Follow the process outlined here to gracefully shut down
Distributed Cache.
IMPORTANT
Do not use Stop-SPDistributedCacheServiceInstance -Graceful as this will terminate Distributed Cache prior to the
cache being transferred to another server in the farm.
Troubleshoot software updates on servers that host Search componenets

Issue: After an update you may no longer have proper registry key or file system permissions.
Resolution: Run the following command:
See also
Other Resources
SharePoint updates
Update Workflow in SharePoint Server 2013
Run cmdlets after software updates are installed

It is important that any Cumulative Updates (CU ) for SharePoint Server 2013 and Workflow Manager are installed
in a coordinated fashion. After an update has been performed, several Microsoft PowerShell cmdlets must be run
in order to maintain the connection between the SharePoint Server 2013 farm and the Workflow Manager farm.
Run the following PowerShell cmdlets as an administrator from the SharePoint Management Shell after the
updates have been installed for SharePoint Server 2013, Workflow Manager, and Workflow Manager Client.
IMPORTANT
The latest update level must be installed on SharePoint Server 2013, Workflow Manager, and Workflow Manager Client
before you run the update cmdlets.
$credential = [System.Net.CredentialCache]::DefaultNetworkCredentials
$site = Get-SPSite(<siteUri>)
$proxy = Get-SPWorkflowServiceApplicationProxy
$svcAddress = $proxy.GetWorkflowServiceAddress($site)
Copy-SPActivitiesToWorkflowService -WorkflowServiceAddress $svcAddress -Credential $credential -Force $true
NOTE
Because workflow supports environments with multiple Site Subscriptions, the $site Site Collection address determines the
proper configuration location for workflow settings.
Troubleshooting steps for workflow updates

Make sure all components are on the latest patch level. This includes SharePoint Server 2013, Workflow
Manager, and Workflow Manager Client.
Verify the $proxy connection settings using the following commands:
$proxy.GetWorkflowServiceAddress($site)
Inspect any errors displayed in the SharePoint Designer user interface or any errors shown in the
SharePoint Workflow Status user interface.
Test and troubleshoot an upgrade to SharePoint
Server 2016
Before you upgrade from SharePoint Server 2013 with Service Pack 1 (SP1) to SharePoint Server 2016, you
should take time to test an upgrade process and understand the issues that you might face in an actual upgrade.
After you perform a test upgrade, or after you upgrade your actual databases, you might find issues that have to be
addressed. After you address issues, you can restart the upgrade to try again.
The following articles provide information about how to test and troubleshoot upgrade.
CONTENT DESCRIPTION
Troubleshoot site collection upgrade issues in SharePoint Follow these recommendations to troubleshoot any issues
Server 2016 that occur during a site collection upgrade. You can also look
up common issues and discover how to address them.
Troubleshoot site collection upgrade issues in
When you upgrade a site collection to SharePoint Server 2016, errors can occasionally occur. This article helps you
understand those errors and address them.
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 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. Review the upgrade status page for your site collection.
On the Site Settings page for the site collection, in the Site Collection Administration section, click Site
collection upgrade. On the Site Collection Upgrade page, click Review Site Collection Upgrade
Status.
2. If pages don't render, check the Site Settings page. 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 doesn't
work, check the site collection upgrade log file for information about the problem.
3. Review the site collection upgrade log files. You can review the site collection upgrade logs from the
following locations:
For site collection administrators: There are also log files for site collection upgrade stored inside the site
collection itself, in the Maintenance Logs catalog at (http:///_catalogs/MaintenanceLogs/YYYYMMDD -
HHMMSS -SSS.txt , where YYYYMMDD is the date and HHMMSS -SSS is the time (hours in 24-hour clock
format, minutes, seconds, and milliseconds).
Common issues
Check to see whether any of the following issues are causing an upgrade error, a warning, or a problem in your
site.
Q: I don't see a UI control on the page that used to be there
A: Reset the page to the default version (that is, reghost it).
Making changes to the site UI can cause problems in site upgrades. If a page was customized to place a UI control
in a non-standard location, you can reset the page to the default version to recover the control.
To reset the page, you can use the Reset to site definition link under Site Actions on the Site Settings page or
use the Reset to Template command in SharePoint Designer.
Q: The view on a large list is not working any longer
A: Create indexed columns, folders, or new views for large lists. You might have to add the indexed column to
your existing views.
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. You 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. For more information about large list
throttling and how to address issues with large lists, see Manage lists and libraries with many items.
Q: I see an error about a duplicate content type name
A: Rename content types or fields that conflict with default names.
Occasionally, custom elements (such as a content type) may have a name that conflicts with a name in the new
version.
In the upgrade log files, you may see an error 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 third-party content type was added to the specified site in SharePoint Server 2013 with
Service Pack 1 (SP1). During upgrade to SharePoint Server 2016 its name conflicted with the default content type
by the same name. Rename the third-party content type in the specified site to a different name and run upgrade
again. For more information, see Create or customize a site content type.
NOTE
Either renaming or removing a content type can cause any customizations dependent on that content type to stop working.
Q: My site looks ugly, doesn't behave as expected, or I see script errors

A: Either edit the page or reset the page to the default version, or remove or replace the custom files.
A problem with custom or inline JavaScript or CSS files can cause these issues.
Q: Custom content in my site disappeared or doesn't work
A: Change the master page, or change the content so that it doesn't require specific zones.
The master page might have different zone layouts and the content might no longer reference it correctly.
As a last resort, you can also reset the page to the default version. However, if you reset the page, you might
lose zone specific content.
Q: I receive an error that says a control or page cannot render
A: Do one of the following:
If a Web Part was added that is not installed, contact the farm administrator to have it installed. If is a
Web Part that is no longer available or not supported, then use the Web Part maintenance view to
remove the Web Part from the page (remove, do not just close the Web Part).
If a page was directly edited, either edit it again to remove the control or Web Part or reset the page
to the default version.
A Web Part or other control might have been added to the page that is not installed or is no longer
supported. Either a Web Part was added to a zone or the page was directly edited to add a control or
Web Part reference directly inline (possibly on a master page).
A SharePoint feature may need to be activated. For more information, see Enable or disable site
collection features and Open and use the Web Part Maintenance Page.
Q: My upgraded site does not render at all; instead, I see an "unexpected error" with a correlation ID
A: Your custom branding may use a custom master page that contains a custom content placeholder.
If your custom master page contains a custom content placeholder, and if custom page layouts also contain this
custom content placeholder, then an error may prevent the home page of your site from rendering at all after
upgrade. Instead, after upgrade, you may see the error message "An unexpected error has occurred."
See also
Concepts
Sites

The following articles are included in this section:
Articles about sites and site collections in SharePoint Server

CONTENT DESCRIPTION
Plan sites and site collections in SharePoint Server Learn the critical decisions that you need to make in your
SharePoint Server 2016 and SharePoint 2013 site planning
process.
Manage site collections in SharePoint Server Use these articles to learn how to manage site collections in
SharePoint Server 2016 and SharePoint 2013.
Manage web parts in SharePoint Server Helps you prepare to manage security for web parts pages
and controls that are used with SharePoint Server 2016 and
SharePoint 2013.
Permissions planning for sites and content in SharePoint Learn about how to plan permissions for sites and site content
Server for SharePoint Server 2016.
Overview of managing digital assets in SharePoint Server 2013 Learn about the asset library and how you can use it to store
and share image, audio, or video files.
Overview of OneDrive for Business in SharePoint Server Learn about OneDrive for Business in SharePoint Server.
Plan sites and site collections in SharePoint Server

Every SharePoint Server site belongs to only one site collection and a site collection is made up of one top-level
site and all sites below it. As shown in the following figure, a site collection is the top level of organization in a
SharePoint Server web application. The number of site collections you can have in a single web application
depends on the capacity of your server infrastructure. For more information about SharePoint Server boundaries,
see Software boundaries and limits for SharePoint Servers 2016 and 2019. For more information about
SharePoint Server site collections, see Overview of sites and site collections in SharePoint Server.
Figure: Structure of a site collection in SharePoint Server
The SharePoint Server 2019 modern experience is similar to the experience in SharePoint Online. The modern
experience is compelling, flexible, and easier to use. The main difference is hub sites aren't available in SharePoint
Server. We do recommend in SharePoint Server 2019 that you create site collections for each unit of work instead
of creating subsites. This will make it easier when migrating your SharePoint farm to SharePoint Online. For more
information about the modern experience in SharePoint Server 2019, see Differences between SharePoint Server
2016 and 2019.
Sites and site collections planning principles

We recommend that you use these rules to plan your sites and site collections:
Use one web application per farm to support all your site collections and sites.
Keep your internally facing (intranet) SharePoint Server solution in a separate SharePoint Server farm from
your externally facing (Internet) solution.
Use host-named site collections instead of path-named site collections and place them in the default zone.
Use path-named collections when you need to use alternate access mappings (AAMs).
Methods of site and site collection organization

There are many ways your sites can be organized. Having a plan in place to help govern your site deployments will
help you avoid random, unorganized site growth, enable better management of your SharePoint infrastructure,
and provide a better user experience.
Understand business needs
The first step in planning your site structure is to inventory the business problems and needs that you are using
SharePoint Server to address. Then map your business needs to the site type best suited to meet them. This
mapping will tell you the types of sites you will need. At the highest level, you will need sites that fall under the
Collaboration category, the Enterprise category, the Publishing category, or the Custom category. For more
information about the types of sites and how they are categorized, see Overview of sites and site collections in
SharePoint Server.
Models for site collections
After you determine which 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
Web Parts
Often share a common navigation scheme
The main goal of site collection planning is to put a structure in place that your organization can grow in without
creating unnecessary management overhead. Here is a generic model for an intranet SharePoint Server farm that
meets many needs.
Figure: Model of an intranet SharePoint Server farm
Internal Collaboration and Publishing You can create a site collection to host your internal team and
communication sites. In SharePoint Server 2019 you can create either new modern experience, or classic
experience, team and community site collections. These can be broken down into two major categories. One
branch can be organized around your company's internal hierarchy, with divisional portals hosting subsites for the
individual long standing teams to use to store their content, collaborate, and publish their work out to the rest of
the organization. Another peer branch can be for ad hoc or v-teams or project teams. These teams have members
from across the long standing teams and need to have a collaboration and publishing space for a limited period of
time.
Internal Enterprise Applications You can create a site collection to host sites and resources that everyone in
your company will use. For example, your company intranet, enterprise search, My Sites, and records repositories.
It is best practice to keep document center sites and records center sites in separate site collections.
Internet Presence It is best practice to place your company Internet presence in a separate SharePoint Server
farm. Site collections of this type host resources that are available to anonymous users on the Internet. For
example, you might use an Internet presence site to provide news articles or reviews that are tagged with
metadata to categorize articles so that users can search or browse for information. For more information about
how to design SharePoint Server for an Internet presence, see Overview of publishing to Internet, intranet, and
extranet sites in SharePoint Server and Plan the logical architecture for cross-site publishing in SharePoint Server.
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. Other examples are SharePoint
Server 2019, modern Team and Communications sites. If other sites use the same database, their
performance could be affected. By putting the knowledge base site in a separate site collection with its own
database, you can free up resources 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 — depends 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.
Creating too many sites below a top-level site in a site collection might affect performance and usability.
The maximum recommended number of sites and subsites in a site collection is 250,000 sites. We
recommend staying below 2,000 subsites per site collection. The maximum recommended number of site
collections per farm is 500,000 Personal Sites plus 250,000 for all other site templates. For more
information, see Site collection limits.
Once you have your site collection plan in place, you can move on to planning the organization of the sites in
those site collections.
Plan sites by organizational hierarchy
Plan the basic sites that you need based on the scale and structure of your organization. Some sites for larger
divisions or projects can also combine information that is found on all the smaller subsites that are devoted to
smaller long standing teams or v-teams that are responsible for time limited projects. Using modern Team and
Communication sites in SharePoint Server 2019 are a great way to create site collections for each unit of work
instead of creating subsites.
Use the following guidelines when you plan sites that are based on your organizational structure:
Divisional or team sites Plan to create one site per team under a divisional rollup site. 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 surfaces content that is stored on other subsites. It makes it possible for users across
divisions to find information, and experts. 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.
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 change 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 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 publishing sites
By using a publishing site, authors can create and modify content in the form of web pages and documents, and
they can use an approval process to make the content available to users who have the appropriate levels of
viewing permissions. The publishing process involves creating content and then submitting it for approval. After
content is approved, it is made available, or published, to the website for readers. This publishing occurs according
to either a default schedule or a customized schedule, based on the needs of the project. Publishing sites can be
used as intranet, extranet, or Internet sites, depending on the audience.
For example, you might use a publishing site for an Internet site that publishes press releases. The public relations
team creates press releases, uses the publishing workflow to approve new content, and specifies when it should be
made available to consumers. As another example, you might use a publishing site for a corporate intranet site,
where company news is made available to employees. Page authors can specify the target audience for their
content, which makes the content viewable by only the members of the designated groups.
You can use one of two ways to make published content available to users: author-in-place, or cross-site
publishing. With the author-in-place method, you use a single site collection to author content and make it
available to readers of your site. With the cross-site publishing method, you use one or more site collections to
author content, and one or more site collections to control the design of the site and the display of the content. For
more information, see Overview of publishing to Internet, intranet, and extranet sites in SharePoint Server.
Plan other sites
You can plan to make it possible for site users to create additional sites. For example, you can plan to give a My
Site to each team member who uses a site. A My Site is a team site that is based on SharePoint Server and has
public and private views. You can also 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 more information, see Configure self-service site creation in SharePoint Server 2019.
For information about the kinds of sites that you can create, see Overview of sites and site collections in
SharePoint Server.
Inventory your farm

To help you with site and site collection planning, the Microsoft PowerShell command-line will inventory your
entire SharePoint Server farm and get the properties of each site collection and site. It saves the results in a
comma separated file (CSV ). Use this inventory to identify what your site collection and site hierarchy are in each
web application, and then plan where you want to add new sites.
To inventory a SharePoint farm by using Windows PowerShell
In the Farm Administrators group
Server cmdlets.
If you don't have permissions, contact your Setup administrator or SQL Server administrator to
SPShellAdmin.
2. Open the SharePoint Management Shell.
Get-SPWebApplication -IncludeCentralAdministration | Get-SPSite -Limit All | Get-SPWeb -Limit All |

Select-Object URL, Title, Description, ParentWeb, AssociatedOwnerGroup, SiteAdministrators,
WebTemplate, UIVersion, QuickLaunchEnabled, TreeViewEnabled, Language, Locale, Author, HasUniquePerm |
Sort URL | export-csv <file location and name.csv>
Where:
URL is the address of the site.
Title is name of the site as configured in site settings and displayed on the title bar of the site.
Description is the value in the description field in the sites properties.
ParentWeb is the site immediately above the inventoried site in the hierarchy.
AssociatedOwnerGroup is the group that owns the site.
Site Administrations are the current users who are listed as the sites primary and secondary site
administrators.
Web Template is the type of site template that the site was created from.
UIVersion is the SharePoint Server version of the site.
QuickLaunchEnabled indicates if the site has the Quick Launch enabled in the vertical navigation.
TreeViewEnabled indicates if the site has the tree view enabled for the Quick Launch.
Language is the language the site was created in.
Locale is the locale of the site.
Author is who created the site.
HasUniquePerm indicates if the site inherits permissions from its parent site or implements unique
permissions.
<file location and name.csv> is the location where you want to save the csv file and the name you
want to give it. For example, 'C:\FarmReports\1.csv'.
For more information, see the PowerShell reference for SharePoint Server article, SharePointServer.
NOTE
We recommend that you use Microsoft 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
Software boundaries and limits for SharePoint Servers 2016 and 2019
Overview of publishing to Internet, intranet, and extranet sites in SharePoint Server
Other Resources
Overview of SharePoint site collections
Overview of sites and site collections in SharePoint
Server

A site collection is made up of one top-level site and all sites below it. As shown in the following figure, it is the top
level of organization in a SharePoint Server web application. The number of site collections you can have in a
single web application depends on the capacity of your server infrastructure. For more information about
SharePoint Server boundaries, see Software boundaries and limits for SharePoint Servers 2016 and 2019.
Figure: Structure of a site collection in SharePoint Server 2016
The SharePoint Server 2019 modern experience is similar to the experience in SharePoint Online. The main
difference is Hub sites aren't available in SharePoint Server. We do recommend that you use the same process as
in SharePoint Online, create site collections for each unit of work instead of creating subsites. This will make it
easier when migrating your SharePoint farm to SharePoint Online.
The following guidelines show the relationship between SharePoint Server sites and site collections, and content
databases:
All content in a site collection must be stored in a single content database. You can't store a site collection's
content across multiple content databases.
You can scale up content databases that support a site collection. You can also scale-out a content database
at the web application level to support additional site collections.
A site collection can exist in only one content database, but one content database can host the content for
multiple site collections.
A site can't exist outside of a site collection and can only exist in one site collection but a site collection can
host many sites.
Overview of SharePoint site collections

You create a site collection to host sites that have something in common. For example, the sites might be in a
common administrative boundary or share common branding. The site collection might be created to house all
the sites and content for a business unit. Or, a single site collection might have become too large to manage, and it
must be split into smaller ones. Lastly, some site collections are created exclusively to host specific SharePoint
Server functionality, such as Enterprise Search Center or to host My Sites. Site collections are a way of organizing
sites for a common purpose. We recommend ahat you create site collections for each unit of work instead of
creating subsites.
SharePoint Server supports two types of site collections: host-named site collections and path-based site
collections. In a path-based site collection, all the subsites in the site collection will share a root or parent URL
(DNS name). For example, Team A could have a site collection at http://contoso.com/sites/teamA, and Team B
would have a site collection at http://contoso/sites/teamB. All sites in either site collection would have the
http://contoso.com/sites/teamA or /teamB root. The only way to have a different URL root is to create a different
web application.
To better align with SharePoint Online best practices, you should use host-named site collections. Host-named site
collections allow you to assign custom names to each site collection that you create in a web application. For
example, you can have two site collections in the same web application addressed like this:
http://TeamA.contoso.com and http://TeamB.contoso.com. This is much more scalable and has been heavily tested
in SharePoint Online.
Because site collections and sites exist in a parent-child relationship, there are aspects of control and functionality
that can be configured at the site collection level and used at the site level. This provides many benefits as follows:
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.
SharePoint Server 2019 offers the choice to create modern Team and Communication sites like in
SharePoint Online, or keep the classic experience. Using the modern experience site collections is inline
with our recommendation to create site collections for each unit of work to make it easier when you decide
to migrate to SharePoint Online.
For farm administrators, site collections can be moved between content databases. By doing this, farm
administrators can manage the size of their content databases.
For site authors, shared site columns, content types, web parts, authoring resources, workflows, and other
site collection features provide a consistent authoring environment.
For site users, a site collection's unified navigation, branding, and search tools provide a unified website
experience.
Every site collection starts as a single, top-level site. Because it is a site, its structure and functionality is based on a
site template. SharePoint Server provides many site templates, plus you can also create and use your own as
needed. The following tables describe the site collection templates that are available in SharePoint Servers 2016
and 2019.
Table: Site templates in SharePoint Servers 2016 and 2019
TYPE NAME DESCRIPTION AVAILABILITY
Collaboration Team Site A place to work together Site collection and site
with a group of people.
offers a modern and classic
team site.
Collaboration Blog A site for a person or team Site collection and site
to post ideas, observations,
and expertise that site
visitors can comment on.
Collaboration Developer Site A site for developers to Site collection only

build, test, and publish apps
for Office.
Collaboration Project Site A site for managing and Site collection and site
collaborating on a project.
This site template brings all
status, communication, and
artifacts relevant to the
project into one place.
Collaboration Community Site A place where community Site collection and site
members discuss topics of
common interest. Members
can browse and discover
relevant content by
exploring categories, sorting
discussions, by popularity or
by viewing only posts that
have a best reply. Members
gain reputation points by
participating in the
community, such as starting
discussions and replying to
them, liking posts, and
specifying best replies.
Enterprise Document Center A site to centrally manage Site collection and site
documents in your
enterprise.
Enterprise In-Place Hold Policy Center A site to manage policies to Site collection only
preserve content for specific
amounts of time.
Enterprise eDiscovery Center A site to manage the Site collection only

preservation, search, and
export of content for legal
matters and investigations.
Enterprise Records Center This template creates a site Site collection and site
designed for records
management. Records
managers can configure the
routing table to direct
incoming files to specific
locations. The site also lets
you manage whether
records can be deleted or
modified after they are
added to the repository.
Enterprise Business Intelligence Center A site for presenting Site collection and site
Business Intelligence
content.
Enterprise Compliance Policy Center A site to manage policies Site collection and site
and delete documents after
specified times.
Enterprise Enterprise Search Center A site focused on delivering Site collection and site
an enterprise-wide search
experience.
Note:
Search Centers should be
separate site collections
because they search for
information across a
company portal or division.
If you create a Search Center
as a subsite, you might have
to create some workarounds
for a full customization. For
more information, see
Customizing the Search
Center.
Enterprise My Site Host A site used for hosting Site collection only
personal sites (My Sites) and
the public People Profile
page.
Enterprise Community Portal A site for discovering Site collection only

communities.
Enterprise Basic Search Center A site focused on delivering Site collection and site
a basic search experience. It
includes a welcome page
with a search box that
connects users to a search
results page and an
advanced search page. This
Search Center will not
appear in navigation.
Note:
Center.
Enterprise Visio Process Repository A site for viewing, sharing, Site collection and site
and storing Visio process
diagrams. It includes a
versioned document library
and templates for Basic
Flowcharts, Cross-functional
Flowcharts, and BPMN
diagrams.
Note:
The Visio Process Repository
site template will be
removed in the next version
of SharePoint Server.
Publishing Publishing Portal A starter hierarchy for an Site collection only

Internet-facing site or a
large intranet portal. This
site can be customized easily
with distinctive branding.
Typically, this site has many
more readers than
contributors and it is used
to publish web pages with
approval workflows.
Publishing Enterprise Wiki A site for publishing Site collection and site
knowledge that you capture
and want to share across
the enterprise.
Publishing Product Catalog A site for managing product Site collection only
catalog data that can be
published to an Internet-
facing site through search.
Publishing Communication Site Available in SharePoint Site collection only

Server 2019 only as a
modern experience. A site
for publishing dynamic,
modern content to people in
your organization to keep
them informed and engaged
on topics, events, or
projects.
Custom <Select template later…> Create an empty site and Site collection only
pick a template for the site
at a later time.
The following table describes the 2013 experience version site templates that are available in SharePoint 2013.
Table: 2013 experience version site templates in SharePoint 2013
Collaboration Team Site A place to work together Site collection and site,
with a group of people. Server and Foundation
Blog A site for a person or team Site collection and site,

to post ideas, observations, Server and Foundation
and expertise that site
visitors can comment on.
Develop Site A site for developers to Site collection and site,

build, test, and publish apps Server and Foundation
for Office.
Project Site A site for managing and Site collection and site,
collaborating on a project. Server only
This site template brings all
status, communication, and
artifacts relevant to the
project into one place.
Community Site A place where community Site collection and site,

members discuss topics of Server only
common interest. Members
can browse and discover
relevant content by
exploring categories, sorting
discussions, by popularity or
by viewing only posts that
have a best reply. Members
gain reputation points by
participating in the
community, such as starting
discussions and replying to
them, liking posts, and
specifying best replies.
Enterprise Document Center A site to centrally manage Site collection and site,
documents in your Server only
enterprise.
eDiscovery Center A site to manage the Site collection only, Server

preservation, search, and only
export of content for legal
matters and investigations.
Records Center This template creates a site Site collection and site,
designed for records Server only
management. Records
locations. The site also lets
you manage whether
records can be deleted or
modified after they are
added to the repository.
Business Intelligence A site for presenting Site collection and site,

Center Business Intelligence Server only
content.
Enterprise Search Center A site focused on delivering Site collection and site,
an enterprise-wide search Server only
experience.
Note:
Center in the MSDN Library.
My Site Host A site used for hosting Site collection only, Server
personal sites (My Sites) and only
the public People Profile
page.
Community Portal A site for discovering Site collection only, Server

communities. only
Basic Search Center A site focused on delivering Site collection and site,
a basic search experience. It Server and Foundation
includes a welcome page
with a search box that
connects users to a search
results page and an
advanced search page. This
Search Center will not
appear in navigation.
Note:
Center in the MSDN Library.
Visio Process Repository A site for viewing, sharing, Site collection and site,
and storing Visio process Server only
diagrams. It includes a
versioned document library
and templates for Basic
Flowcharts, Cross-functional
Flowcharts, and BPMN
diagrams.
Note:
The Visio Process Repository
site template will be
removed in the next version
of SharePoint Server.
Publishing Publishing Portal A starter hierarchy for an Site collection only, Server
Internet-facing site or a only
large intranet portal. This
site can be customized easily
with distinctive branding.
Typically, this site has many
more readers than
contributors and it is used
to publish web pages with
approval workflows.
Enterprise Wiki A site for publishing Site collection and site,

knowledge that you capture Server only
and want to share across
the enterprise.
Product Catalog A site for managing product Site collection only, Server
catalog data that can be only
published to an Internet-
facing site through search.
Blank Publishing site A blank site for expanding Site only, Server only
your website and quickly
publishing web pages.
Contributors can work on
draft versions of pages and
publish them to make them
visible to readers. The site
includes document and
image libraries for storing
web publishing assets.
Publishing Site with A site for publishing web Site only, Server only
workflow pages on a schedule by
using approval workflows. It
includes document and
image libraries for storing
web publishing assets. By
default, only sites with this
template can be created
under this site.
Custom <Select template later…> Create an empty site and Site collection only, Server
pick a template for the site and Foundation
at a later time.
The following table describes the 2010 experience version site templates that are available in SharePoint 2013.
Table: 2010 experience version site templates in SharePoint 2013
Collaboration Team Site Same functionality as the Site collection and site,
2013 Team site. Server and Foundation
Blank Site A blank site for you to Site collection and site, Site collection and site,
customize based on your Server and Foundation Server and Foundation
requirements.
Document Workspace A site for colleagues to work Site collection and site, Site collection and site,
together on a document. It Server and Foundation Server and Foundation
provides a document library
for storing the primary
document and supporting
files.
Blog Same functionality as the Site collection and site, Site collection and site,
2013 Blog site. Server and Foundation Server and Foundation
Group Work Site This template provides a Site collection and site, Site collection and site,
groupware solution that Server and Foundation Server and Foundation
enables teams to create,
organize, and share
information. It includes a
Group Calendar, Circulation,
Phone-Call Memo, a
document library, and other
basic lists.
Visio Process Repository Same functionality as the Site collection and site, Site collection and site,
2013 Visio Process Server only Server and Foundation
Repository. Site collection and site,
Server and Foundation
Meetings Basic Meeting Workspace A site to plan, organize, and Site collection and site,
capture the results of a Server and Foundation
meeting. It provides lists for
managing the agenda,
meeting attendees, and
documents.
Blank Meeting Workspace A blank meeting site for you Site collection and site, Site collection and site,
to customize based on your Server and Foundation Server and Foundation
requirements.
Decision Meeting A site for meetings that Site collection and site, Site collection and site,
Workspace track status or make Server and Foundation Server and Foundation
decisions. It provides lists for
creating tasks, storing
documents, and recording
decisions.
Social Meeting Workspace A site to plan social Site collection and site, Site collection and site,
occasions. It provides lists Server and Foundation Server and Foundation
for tracking attendees,
providing directions, and
storing pictures of the event.
Multipage Meeting A site to plan, organize, and Site collection and site, Site collection and site,
Workspace capture the results of a Server and Foundation Server and Foundation
meeting. It provides lists for
managing the agenda and
meeting attendees in
addition to two blank pages
for you to customize based
on your requirements.
Enterprise Document Center A site to centrally manage Site collection and site,
documents in your Server only
enterprise.
Records Center This template creates a site Site collection and site, Site collection and site,
designed for records Server only Server only
management. Records
locations.
Business Intelligence Center Same functionality as the Site collection only, Server Site collection and site,
2013 Business Intelligence only Server only
site.
Enterprise Search Center A site for delivering the Site collection and site, Site collection and site,
search experience. It includes Server only Server only
a search box with scopes for
general searches and for
people searches. You can
add and customize tabs to
focus on other search
scopes or result types.
My Site Host Same functionality as the Site collection only, Server Site collection and site,
2013 My Site Host site. only Server only
Basic Search Center A site for delivering the Site collection and site, Site collection and site,
search experience. The site Server and Foundation Server only
includes pages for search
results and advanced
searches.
FAST Search Center A site for delivering the FAST Site collection and site, Site collection and site,
search experience. Server only Server only
Publishing Publishing Portal Same functionality as the Site collection only, Server
2013 Publishing Portal site. only
Enterprise Wiki Same functionality as the Site collection only, Server Site collection only, Server
2013 Enterprise Wiki site. only only
Publishing Site with Same functionality as the 2010 site only, Server only Site collection only, Server
Workflow 2013 Publishing Site with only
Workflow site.
Custom <Select template later…> Same functionality as the Site collection only, Server
2013 <Select template and Foundation
later…> option.
Web Databases Assets Web Database Create an assets database to 2010 site only
keep track of assets,
including asset details and
owners.
Charitable Contributions Create a database to track 2010 site only 2010 site only
Web Database information about
fundraising campaigns
including donations made
by contributors, campaign-
related events, and pending
tasks.
Contacts Web Database Create a contacts database 2010 site only 2010 site only
to manage information
about people that your
team works with, such as
customer and partner.
Issues Web Database Create an issues database to 2010 site only 2010 site only
manage a set of issues or
problems. You can assign,
prioritize, and follow the
progress of issues from start
to finish.
Projects Web Database Create a project tracking 2010 site only 2010 site only
database to track multiple
projects and assign tasks to
different people.
NOTE
The Web Databases site templates that are available through the 2010 experience sites in SharePoint 2013 are no longer
available in the 2013 experience sites in SharePoint 2013. In SharePoint Server 2016, you create an Access database by
creating a new app, instead of creating a site.
IMPORTANT
Some SharePoint 2010 Products site templates, such as the Document Workspace Site templates, were deprecated and are
not available as an option in SharePoint 2013. Existing sites that were created by using these deprecated site templates and
then upgraded will continue to operate in SharePoint 2013. The deprecated site templates will be removed completely from
the next version of SharePoint.
Examples of solutions that benefit from being implemented as site collections are as follows:
Team collaboration site A site collection to support authoring and collaboration tasks. Often, this kind of
site includes collaborative content that is not published but only used internally. For example, a team
collaboration site collection might contain a site for each team in your organization to use to plan projects,
coordinate tasks, record meeting notes, and store team documents.
Published Internet site A site collection for publishing content to anonymous Internet readers. A small
number of authors create and publish content for many readers. For example, you might use a published
Internet site to provide information about company products or services to customers. You can implement
publishing sites in a single site collection, where authoring and publishing tasks are performed on the same
site. You can also implement publishing sites as two or more site collections that separate the stages of
authoring and publishing. Content is created on one or more authoring site collections, and is displayed on
one or more publishing site collections by using the Cross-Site Collection Publishing feature in SharePoint
Server. For information about how to decide which publishing method to use, see Plan for Internet,
intranet, and extranet publishing sites in SharePoint Server. For information about cross-site publishing,
see Plan for cross-site publishing in SharePoint Server.
Overview of SharePoint sites

You create sites in your site collection to partition your content so that you can have finer control of the
appearance and the permission to the content. You can also have different features available on the various sites in
your site collection. You can use a site template with its default configuration, or you can change the site's default
settings through site administration, and then save the site as a new template. For more information, see Create
and use site templates.
NOTE
You cannot save a SharePoint publishing site collection or site as a template. If you activate the SharePoint Server Publishing
Infrastructure feature on a non-publishing site collection, the Save site as template link is removed from the Site Actions
section on the Site Settings page.
You can configure the following items for a site:

Templates Sites in a site collection can each use different templates.
Language If language packs were installed on the web server, you can select a specific language to use
together with the site template when you create a new site. The user interface that appears on the site is
displayed in the language that was selected when the site was created. Content and other items created by
users are displayed in the language in which they are created. For more information, see Plan for
multilingual sites in SharePoint Server and Install or uninstall language packs for SharePoint Servers 2016
and 2019.
Security You can define unique user groups and permissions for each site.
Navigation You can fine-tune your site's navigation experience by configuring unique navigation links in
each part of your site's hierarchy. Site navigation often 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 Overview of site navigation in SharePoint Server.
In SharePoint Server publishing sites, you can use managed navigation to create a site navigation that is
derived from a tightly managed taxonomy. For more information, see Overview of managed navigation in
SharePoint Server.
Web pages Each site can have a unique welcome page and other pages.
Site layouts Each site can have a unique layout or master pages.
Themes You can change colors and fonts on a site. For more information, see Overview of themes in
SharePoint Server.
Regional settings Each site can have custom regional settings, such as locale, time zone, sort order, time
format, and calendar type.
Search Each site can have custom search settings. For example, you can specify that a particular site never
appears in search results.
Content types Each site can have unique content types and site columns.
Workflows You can make each site have unique workflows.
Apps You can install apps for SharePoint to deliver specific information or functionality to a SharePoint
site. An app for SharePoint is a small, easy-to-use, stand-alone application that solves a specific end-user or
business need.
See also
Concepts
Plan sites and site collections in SharePoint Server
Overview of site navigation in SharePoint Server
Overview of site policies in SharePoint Server
Plan self-service site creation in SharePoint Server

Organizations have two ways to create site collections in their web applications. One way is to restrict site
collection creation to Farm Administrators. The Farm Administrators create site collections either through the
SharePoint Central Administration website or through the SharePoint Management Shell. This provides tight
control. Another way is to enable Self Service Site Creation, to let users with the necessary rights create site
collections under predefined paths. For information about using Microsoft PowerShell to create self-service sites
with the SPSiteMaster cmdlets, see SharePointServer.
NOTE
My Sites and the policies feature are not available in SharePoint Foundation 2013 and Self-Service Site Creation is disabled by
default.
Determine who can create sites and a method for site creation
By default, new site collections can only be created by using Central Administration or the SharePoint
Management Shell, by members of the Farm Administrators group. If your organization wants to tightly control
and manage the environment so only a few people are allowed to add top-level sites, this is the method to use.
However, if you have any of the following requirements, then self-service site creation might be the better choice
for your organization:
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 Creation Self-Service Site Creation enables 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 create a site user
interface can be customized or replaced with a custom form 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 Creation 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. For more information, see Configure self-service site creation in SharePoint Server 2019.
Self-Service Site Creation can also be configured to create sites instead of site collections. When enabled,
users can create a new site quickly and easily from their personal site. Clicking the new site link from the
Sites page creates a new site. The site is created by using the Team Site template and will have separate
permissions. The site creator can add additional users to the new site.
Subsites of existing sites Limit users to creating subsites of existing sites, instead of 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 be either 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.
My Sites Allow users to create personal sites (also known as My Sites). Personal sites are site collections
stored under the /personal path of the web application. Personal sites are created for individual users, so
they are not the appropriate method to use if you are trying to create sites for groups or communities. Self-
Service Site Creation is used to create My sites For more information on My Sites, see Configure My Sites
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 Quotas.
Plan for Self-Service Site Creation

When you enable users to create site collections, they must have Use Self-Service Site Creation permission on the
host site collection. When you enable users to create sites, they must have Create Subsites permission on the
parent site. This capability can affect the security for your web server. You enable Self-Service Site Creation 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.
NOTE
Self-service site creation only creates path based site collections. You cannot create host-named site collections with self-
service site collections.
NOTE
In SharePoint Foundation 2013, Self-Service Site Creation is disabled by default. When you enable Self-Service Site Creation,
users can use the site creation page (http://<server>/_layouts/15/scsignup.aspx) to create a new site or site collection.
NOTE
If you want to use a path other than /sites for Self-Service Site Creation, you must add the path as a wildcard inclusion.
If you enable Self-Service Site Creation, you should consider the following:
We recommend that you should require a secondary site contact. Administrative alerts, such as those for
when quotas are exceeded, or checking for unused websites, 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.
NOTE
You can also configure Self-Service Site Creation to apply a quota template to any site collections that are created.
Consider requiring a retention policy. When users create a site or site collection, they must select a policy to
apply. For more information on site policies see, Overview of site policies in SharePoint Server.
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 website notifications, so that sites that are forgotten or no longer of value can be identified.
Because Self-Service Site Creation creates new top-level websites on an existing web application, any new sites
automatically conform to the web application's default quota settings, unused website notification settings, and
other administrative policies.
You can configure Self-Service Site Creation in a variety of ways to meet your needs. For example, if you have a
web application dedicated to My Sites, you can enable Self-Service Site Creation but select to hide the new site
link so that no one can use it to create new sites or site collections. You can also create a custom form that users
utilize to create a site or site collection.
Plan for custom site creation processes

You can also 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 that 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 Creation 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.
See also
Configure self-service site creation in SharePoint Server 2019
Configure self-service site creation in SharePoint
Server 2019

The self-service site creation experience in SharePoint supports creating new sites in a different web application,
regardless of whether the web application is hosted on the local farm or a remote farm. This gives greater flexibility
and control in managing SharePoint farms.
Self-service site creation updates for SharePoint Server 2019 offers the following:
The ability to create sites in other web applications and in web applications hosted in remote SharePoint
farms.
By default the SharePoint home page and team sites only use modern site templates when self-service site
creation is enabled. If you want users to only create classic sites you can add the
(/_layouts/15/scsignup.aspx) page for users to use classic site templates.
The ability for farm administrators to hide the Create Site link from the SharePoint home page, so users
have to go through their IT organization to create new sites.
Configure self-service site creation in the SharePoint Central

Administration website
SharePoint Farm Administrators control self-service site creation in different web applications on local or remote
farms in Central Administration. This is controlled in the When users select the Create site command, create:
section on the Self-service Site Creation Management page in Central Administration.
To configure self service site creation
1. Open Central Administration and under Application Management, click Manage web applications.
2. In the Manage web applications page, click the web application you want and then click Self-Service Site
Creation in the banner.
3. In the Self-Service Site Creation Management page, you can configure this feature in either Site Collections
or Sites.
4. To create sites in the same web application, select This web application.
5. To create sites in a different web application on the local farm, select The following web application and
then select the web application from the drop-down field. Ensure self service site creation is enabled in the
target web application.
NOTE
When you enable self-service site creation, a link to create a site is added to the SharePoint home page.
NOTE
When configuring self-service site creation on remote farms, both farms must be running SharePoint Server 2019. We don’t
support self-service site creation in remote farms if the remote farms are running an older version of SharePoint.
To create sites in a different web application or a remote farm

1. In the local farm hosting the SharePoint home page, use the Map to External Resource control in
Alternate Access Mappings (AAM ) to provide the URL of the web application where you want to create sites.
2. In the local farm that hosts the SharePoint home page, on the Self-service Site Collection Management page
for the web application that hosts the SharePoint home page, select The following web application, and
then select the remote web application from the drop-down field.
3. In the remote farm, use the Map to External Resource control in AAM to provide the URL of the web
application that hosts the SharePoint home page.
4. In the remote farm, on the Self-service Site Collection Management page for the web application where you
want to create the sites, ensure self-service site creation is enabled.
NOTE
For cross-web application scenarios, you must create the AAM on both web applications to ensure the form reads from the
correct named path.
Self-service site creation in the SharePoint home page supports AAM

zones
The self-service site creation experience in the SharePoint home page supports non-Default Alternate Access
Mapping zones. This applies to sites created in the same web application, sites created in a different web application
on the local farm, and sites created in a different web application on a remote farm. When creating sites in a
different web application on a remote farm, make sure that an external resource has been created in AAM on both
the local farm and the remote farm.
SharePoint will treat the external resource as an external web application. The external resource on the local farm
should be fully populated with the URLs and zones of the web application on the remote farm. And conversely, the
external resource on the remote farm should be fully populated with the URLs and zones of the web application on
the local farm. Be sure that the zones of the local web application and the remote web application are synchronized.
For more information, see Plan alternate access mappings for SharePoint Server and Configure alternate access
mappings for SharePoint Server.
See also
Plan self-service site creation in SharePoint Server
Enable SharePoint home page in SharePoint Server
2019 farms
What is SharePoint home?

SharePoint home is a modern UX page, available out-of-box- in SharePoint Server 2019 with appropriate
configurations, where a user can easily find and access their SharePoint sites and portals. It is a personalized
experience that allows users to view activities in the sites they follow, discover news across their sites and much
more. SharePoint home replaces the Sites.aspx experience in SharePoint Server 2016. The Sites tile in the app
launcher is also renamed as SharePoint. To access SharePoint home, click the App Launcher and then click
SharePoint.
A user can also click on the word “SharePoint” in the top bar to visit SharePoint home page.
The SharePoint home page experience includes the following features:

Search box: When a user clicks in the search box a list of best-match sites is available in the drop-down list
to provide a “zero-time search” experience.
Featured links: These are links that are important and useful for your organization. Anyone who is an
admin of the My Site Host site can set these links.
Create Site: With the Self-Service Site Creation (SSSC ) feature you can give users the ability to create a
new modern site collection, Communication or Team sites. For more information, see Configure self-service
site creation in SharePoint Server 2019.
News from sites: Display recent news from Following and Suggested sites.
Following: Display sites that you are following in a card format. Users will see top activities in those sites
and can unfollow sites.
Suggested: These sites that have the most activity that you’re not following.
For more information, see the “2019” section in Find news, sites, and portals in SharePoint.
Requirements to enable the SharePoint home page

1. Managed Metadata Service Application
2. Search Service Application
3. Enterprise Search Center site
4. My Site Host site
5. User Profile Service Application
6. Import profiles from Active Directory, if required
7. Distributed Cache (Optional) Note that content following normally requires distributed cache. SharePoint
home will show followed sites and may not require distributed cache directly. If your SharePoint home
doesn't show content following, then deploy distributed cache in your farm.
SharePoint home page in a hybrid environment

SharePoint home page works best when Search and List of Followed sites are stored in a user’s My Site. In a
SharePoint Server hybrid environment, the SharePoint home page is not rendered on SharePoint Server 2019.
Instead, when you click SharePoint from the App Launcher, you’re re-directed to the SharePoint home page in the
cloud.
Troubleshooting SharePoint home page

If you find any issues with the SharePoint home page, first check items in the following list.
1. SharePoint home page looks different for users. This is expected and depends on user activity and timing of
the changes.
2. Check the User Profile Service application to make sure it's provisioned, started, and working.
3. Check that the affected user has a working user profile.
4. Ensure the SharePoint home page site collection is configured with a pointer to the Enterprise Search
Center.
5. Check the Search Service application and crawling status.
6. If you're running Distributed Cache, check for any service issues.
7. When following a site that isn't shown on the SharePoint home page, check that “following” is functional in
your farm.
See also
Concepts
Create a User Profile service application in SharePoint Server
Configure profile synchronization by using SharePoint Active Directory Import in SharePoint Server
Manage the Distributed Cache service in SharePoint Server
Congiure self-service site creation in SharePoint Server 2019
Overview of site policies in SharePoint Server

Even with good governance, SharePoint sites can multiply and quickly grow out of control. Sites are created as
they are needed, but sites are rarely deleted. Sites that are no longer needed but aren't deleted, require storage
space and they also might be unwanted for compliance reasons.
You can use site policies to help control site excess. A site policy defines the life-cycle of a site by specifying when
the site will be closed and when it will be deleted. When you close or delete a site, any sub-sites are also closed or
deleted. If an Exchange mailbox is associated with a site, the mailbox is deleted from Exchange Server when the
site is deleted.
When you close a site, you specify that the site is no longer used so that the site can eventually be deleted
according to a schedule. A closed site does not appear in other places where sites are aggregated — for example,
Outlook, Outlook on the web (formerly known as Outlook Web App), or Project Server — but users can still
modify a closed site and its content by using the URL to reach the site.
SharePoint site policy options

A site policy specifies the conditions under which to close or delete a site automatically. These conditions have the
following four options:
Do not close or delete the site automatically. If a policy that has this option is applied to a site, the site
owner must delete the site manually.
Delete the site automatically. If a policy that has this option is applied to a site, the site owner may close
the site manually, but the site will be deleted automatically. A policy that deletes the site automatically
specifies a rule for when to delete the site, and has the following options:
What action triggers the site to be deleted, and how long to wait after the trigger occurs before
deleting the site. The trigger can be either site creation or site closure. For example, you can create a
policy that deletes a site three months after the site is closed, or a policy that deletes a site one year
after the site is created.
Whether to have SharePoint Server send a notification email message to the site owner a specified
amount of time before the site is scheduled to be deleted.
Whether to allow site owners to postpone deletion of the site.
Close the site automatically and delete the site automatically. This option gives the same choices for
how to delete the site automatically, and also requires you to specify how long after its creation time the site
will be closed.
NOTE
A site owner can re-open a closed site by going to the Site Closure and Deletion page from the Site Settings menu.
Run a workflow to close the site, and delete the site automatically. This option gives the same
choices for how to delete the site automatically, and also requires you to specify a workflow to run. When
the workflow finishes running, SharePoint Server 2016 closes the site. You specify the name of the
workflow, how long after the site is created to run the workflow, and whether to rerun the workflow
periodically until the site is closed.
A site policy can also specify that if it is applied to the root site in a site collection, when the root site is closed, the
root site and all sub-sites become read-only.
Site policies are also available in SharePoint Server 2019 modern Team and Communication sites. You must first
activate the Site Polcy feature before it appears on the Site Settings page.
Defining SharePoint site policies

You define site policies from the root site of a site collection by going to the Site Policies page from the Site
Collection Administration menu. The policies are then available in every site in the site collection. Site owners
can apply a policy to a site by going to the Site Closure and Deletion page from the Site Settings menu. Site
owners can also close a site by using the Site Closure and Deletion page.
NOTE
To delete a site manually, a site owner must select Delete this site on the Site Settings menu. The Site Closure and Deletion
page shows when a site will be deleted automatically. However, it does not provide an option for the site owner to delete the
site manually.
If the site collection in which you define site policies is a content type hub, then you can publish policies and share
them across site collections.
Using SharePoint site policies with self-service site creation

Site policies are especially valuable when you use them together with self-service site creation. When a farm
administrator enables self-service site creation on a web application, the farm administrator can specify that users
must classify each newly created site by selecting a policy to apply to the site. The farm administrator can specify
that site classification is required, optional, or hidden from the user. By using site policies together with self-service
site creation, you can let users create their own sites, but also make sure that the sites will be deleted after a
certain time.
See also
Other Resources
Overview of document deletion policies in SharePoint Server
Overview of in-place hold in SharePoint Server

Site navigation are the sets of controls and links in your site collections, sites and pages that help orient users to
where they are and help them easily get to other relevant locations. For example, you can configure site navigation
to help users get to other sites in the site collection or you can configure it so that the top navigation and the
vertical navigation controls are dynamically generated based on context of what the user is looking at. A well
planned site navigation strategy make SharePoint Server sites easier to use.
SharePoint Server has many features that use search technology to provide site owners with ways to display
content dynamically on web pages. For more information about search-driven sites, see Plan for cross-site
publishing in SharePoint Server.
Navigation controls overview

Navigation controls can be displayed on master pages, page layouts, and — by using Web Part zones — directly in
a page's content.
By default, SharePoint Server bases its navigation model on the hierarchical structure of the site collection. By
using the navigation features, you can link any site to any other in the hierarchy and to pages in those sites.
Additionally, you can create links to arbitrary locations, such as to an external website.
Managed Navigation - When you use managed navigation, you create a term set that represents the navigation
hierarchy, and navigation controls display data from the term set. You can change the navigation hierarchy by
changing the term set. For more information, see Overview of managed navigation in SharePoint Server.
Managed navigation is disabled by default in all site templates except the Publishing Portal site collection
template.
Navigation links are subject to security trimming. This means that if a site user does not have permissions to the
destination SharePoint Server site or page of the link, then that link is not displayed. Pages, sites, and links that are
manually added to navigation can be configured to be available only to members of a particular audience. Users
who are not members of that audience cannot see links to sites and pages that are targeted to that audience.
Common Navigation Controls

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. A master page often includes the top
navigation control (where links are presented on drop-down menus) and the vertical navigation control.
You can apply your own custom styles to these navigation controls by using Design Manager and an HTML editor
of your choice.
Top Link Bar
The Top link bar control displays 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 navigation, and each site has its own unique top navigation. Site owners can
customize the top navigation for a specific site.
Site owners can choose to inherit the top navigation 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 navigation 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 navigation 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 navigation configuration features include the following:
Linking to the web pages of all the top-level sites in SharePoint Server only
Linking to specified external sites
Linking to specified sites or pages that are anywhere in the site.
Organizing links under headings in SharePoint Server only.
Manually sorting the items on the top link bar
Restricting the maximum number of items to show at the global navigation level in SharePoint Server only
All top link bar features, such as linking to external sites, can be defined uniquely for each site. If you are on a top
level site, you can add, move or rearrange the links by clicking EDIT LINKS
By using Design Manager you can additionally customize the appearance and functionality of the top link bar in
SharePoint Server only.
Quick Launch
Quick launch typically highlights the important content in the current site, such as lists and libraries. It is common
for it to appear on the left of each page in a site.
Quick launch configuration features include the following:
Linking to sites that are on the same level of the site hierarchy as the current site in SharePoint Server only
Linking to specific external sites or to pages in the current site
Organizing links under headings.
Manually sorting the items in Quick Launch
Restricting the maximum number of items to show at the navigation level in SharePoint Server only
If you want to add, remove, or rearrange the links, click EDIT LINKS in the vertical navigation. You can also add,
remove, rearrange links or create new headings in Site Settings for the site. To enable or disable Quick Launch,
click the gear icon in the upper-right corner and then click Site Settings. In the Look and Feel area, click Tree
view, and then select the Enable Quick Launch check box.
Just as you customize top navigation, you can also customize the appearance and functionality of vertical
navigation by using Design Manager in SharePoint Server.
Tree view
Tree view appears on the left side of the page. If you have enabled Quick launch and Tree view, Tree view will
appear below Quick launch. Tree view displays site content, such as lists, libraries, and sites that are in the current
site, in a hierarchical structure.
By default, tree view navigation is turned off. To enable tree view, click the gear icon in the upper-right corner and
then click Site Settings. In the Look and Feel area, click Tree view, and then select the Enable Tree View check
box.
Metadata navigation
Metadata navigation displays metadata about library and list content in the tree view navigation, and lets users
filter library or list content based on specified fields. Site administrators can configure metadata navigation by
using the Metadata Navigation Settings page for a list or library to configure the navigation hierarchies and key
filters that are available to users. Metadata navigation is displayed only when a user views the list or library for
which metadata navigation was configured.
Managed navigation
Managed navigation enables you to define and maintain the navigation on your site by using term sets. This
method supplements the existing SharePoint navigation based on site structure. You create the managed
navigation structure by adding terms to the navigation term set in the Term Store Management tool. You can copy
the navigation term set and translate it into the same languages that are used for variations labels. For more
information, see Overview of managed navigation in SharePoint Server.
Navigation Web Parts

A Web Part is a control that authors can insert into a Web Part zone on a page and configure. The Summary Links,
Table of Contents, Content Query, and Content Search controls each have Web Part counterparts that page
authors can insert into Web Part zones on pages. The Web Parts have the same configuration features and the
same functionality as their related controls. However, they can be configured when they are inserted on the page
instead of when the site designer inserts them on the layout of the page. To make navigation Web Parts available
for page authors to insert on a page, you can include one or more Web Part zones on a page layout, or you can
include a Rich Text Editor control on a page, which will allow users to add Web Parts directly to the Rich Text Editor
Web Part.
The following navigation Web Parts are available only for non-Publishing sites:
Content Rollup - Categories Displays categories from the Site Directory
Content Rollup - Site Aggregator Displays sites of your choice.
Content Rollup - Sites in Category Displays sites from the Site Directory in a specific category.
Social Collaboration - Tag Cloud Displays the most popular subjects being tagged inside your
organization.
If you make it possible for authors to insert navigation Web Parts on pages, you reduce the control that you have
over your site's navigation because authors can then control part of the navigation experience of site users. This
might be appropriate in a loosely controlled environment, such as a collaboration site in an organization, where
individual authors must be able to point users to content that is related to the author's work. It is less appropriate
in a more tightly controlled environment, such as an Internet presence site, in which the navigation experience is
planned and implemented in a consistent, controlled way by the site designers and planners.
NOTE
If you want to include Web Part zones on page layouts but prevent authors from inserting navigation Web Parts into these
zones, you can change the permissions that are required to use navigation Web Parts in the Web Parts gallery of your site
to make those Web Parts unavailable to authors based on their permission level.
See also
Concepts
Overview of managed navigation in SharePoint Server
Manage web parts in SharePoint Server
Plan for multilingual sites in SharePoint Server

SharePoint Server and SharePoint Online have features that enable you to support users in different regions or
users who speak different languages. You can use these features to create websites in different languages, or to
enable users to view sites in their preferred language.
For information about how to create multilingual sites, see Choose the languages you want to make available for a
site's user interface and Create a multi-language website.
IMPORTANT
This section does not apply to SharePoint Foundation 2013.
About SharePoint multilingual sites

The SharePoint Server multilingual sites feature enables you to work in multiple languages, to provide content to
users in more than one language, or both. The multilingual sites feature, offers the following:
Create, manage, and read content in different languages.
Navigate a site in a preferred language.
Collaborate with people in different regions, in different languages, in the same application.
Manage personal sites by using a preferred language.
Search and browse content across a company by using a preferred language.
There are three ways that you can provide multilingual sites for users:
1. You can create sites in languages different from the one that was used to install SharePoint.
This option creates a site in which the site user interface appears in the language that is selected when the
site is created. For example, if the English version of SharePoint is installed, but Japanese is selected when
the site is created, the site user interface will appear in Japanese. This option only affects the site
administration pages and user interface, and does not affect content created on the site. For more
information, see Install or uninstall language packs for SharePoint Servers 2016 and 2019 or Install or
uninstall language packs for SharePoint 2013.
2. You can use the multilingual user interface to enable users to view the site user interface in their
preferred language.
This option creates a site in one language, but can show the site user interface in another language, based
on the preferred language of the user. For example, if the site is created in English, but the user's preferred
language is Spanish, and the Spanish language pack is installed and enabled for the site, the site user
interface for that user appears in Spanish. This option only affects the site administration pages and user
interface, and does not affect content created on the site. For information about the multilingual user
interface, see Plan for the multilingual user interface in SharePoint Server.
3. You can use the variations feature to make publishing content available in different languages on
different sites.
NOTE
You can only use the variations feature on sites that you create with one of the Publishing site templates, or on a site
where the SharePoint Server Publishing Infrastructure feature is activated.
This option creates a source variation site that is used to author content in one language, and then syncs
that content to one or more target variation sites where it can be translated and consumed in other
languages. For example, you can author and publish content in English for http://contoso.com/en, and use
variations to sync content to http://contoso.com/fr, where you can translate it to French and publish it.
Unlike the first two options, the variations feature does not affect site administration pages or the user
interface; it affects only content. You can create the variation sites in different languages, and you can enable
the multilingual user interface for users who create content for the variation sites. For information about
variations, see Variations overview in SharePoint Server.
NOTE
Only options 1 and 2 require that language packs be installed. But if you want to create variation sites in other languages, or
enable the multilingual user interface on variation sites, you must also install language packs for option 3. For information
about language packs, see Install or uninstall language packs for SharePoint Servers 2016 and 2019 or Install or uninstall
language packs for SharePoint 2013.
For information about how to decide whether to use multilingual user interface features, the variations feature, or
both, see Introduction to multilingual features.
If your organization supports 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 do the following:
Determine the languages and locales that you must support.
Determine the language pack requirements for sites and users.
Decide whether you want to use the variations feature.
NOTE
Although Office SharePoint Server 2007 and Windows SharePoint Services 3.0 supported internationalized domain names
(IDNs), SharePoint 2013, SharePoint Server 2016, and SharePoint Server 2019 don't. If you currently use IDNs with Office
SharePoint Server 2007 or Windows SharePoint Services 3.0 and you plan to upgrade or migrate to either SharePoint 2013
or SharePoint Servers 2016 or 2019, you must stop using IDNs, delete any IDN settings, and set up a non-IDN environment
before you upgrade or migrate to SharePoint Servers 2016 and 2019.
Determine language and locale requirements

The following reasons establish a need to create sites in multiple languages:
You want to provide content to users in different regions or countries, and you want to provide content to
each region or country in its specific language.
You want to provide content to customers whose business spans many geographic areas.
You are required by government regulation or organizational policy to provide content in more than one
language.
Consult all potential site owners to determine your language requirements. Record the list of sites and the default
language for each site in a spreadsheet. 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 is created for a specific language, the
default language of the site cannot be changed. But a user who is logged on to the site can use the multilingual
user interface to view the site in the user's preferred language.
NOTE
If users change their preferred language, some site elements, such as column names, might still appear in the default site
language.
Do not assume that you have to create a site collection or site 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 site collections or sites in multiple languages. For example, the
document library for an English site collection can contain documents that are written in French, Spanish, and
Japanese. For publishing sites, content can be created in any language. You do not have to create a site collection
or site in a specific language to show pages that contain content in other languages.
When you plan multilingual sites, you should also consider which locales are necessary to support your sites.
Locale is a regional setting that specifies the way numbers, dates, and times are shown on a site. But locale does
not change the language in which the site is viewed. For example, selecting the Thai locale changes the default
sort order of list items, and uses the Buddhist calendar instead of the default calendar. But it does not change the
site user interface language to Thai. Locale is a setting that is configured independently of the language specified
when a site is created. In your spreadsheet, record any locales that you want to use with specific languages. The
site locale can be changed, but only until any of the lists on the site are indexed.
Determine language pack requirements

SharePoint language packs enable you to create site collections and sites in multiple languages without requiring
separate installations of SharePoint Server. A farm administrator must install language packs on all web and
application servers in the SharePoint farm before sites can be created in languages other than the default
language. For more information, see Install or uninstall language packs for SharePoint Servers 2016 and 2019 or
Install or uninstall language packs for SharePoint 2013. When you create a site collection or a site and select a
language, the user interface text that appears on the site collection or site is shown in the selected language. For
example, when you create a site in French, the toolbars, navigation bars, lists, and column headings for that site
appear in French. Likewise, if you create a site in Arabic, the site administration pages and user interface, such as
toolbars, navigation bars, lists, and column headings for that site, appear in Arabic, and the default left-to-right
orientation of the site changes to a right-to-left orientation to correctly show Arabic text.
If your site will have users who can't work in the default language that you plan to use for the site, you should
install language packs that will enable users to work in their preferred 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:
Site administration pages
Ribbon elements
List and site column headers
Site settings interface
Templates for new lists, document libraries, and sites
Managed metadata term sets and terms
For more information about what is supported by the multilingual user interface, see Plan for the multilingual
user interface in SharePoint Server.
NOTE
Language packs provide translation only of the user interface. They do not translate content that is created and shown in
content pages or Web Parts. You can use the Machine Translation service to enable users to automatically translate
documents. For more information, see Turn on automated document translation in SharePoint Server.
The list of available languages that you can use to create a site collection or site, and which you can enable for the
multilingual user interface, is generated by the language packs that are installed on the web and application
servers of the server farm. By default, site collections and sites are created in the language in which SharePoint
Server was installed. For example, if you install the Spanish version of SharePoint Server, the default language for
site collections and sites is Spanish. If you must create site collections or sites in a language other than the default
SharePoint Server language, you must first install the language pack for that other language on the web and
application servers before you can select another language in which to create a site. For example, if you are
running the French version of SharePoint Server and you want to create sites in French, English, and Spanish, you
must install the English and Spanish language packs on the web and application servers before you can create the
English and Spanish sites.
NOTE
Every time that a language pack is installed, you must rerun the SharePoint Products Configuration Wizard, which stops and
restarts Internet Information Services (IIS), the SharePoint Administration Service, and the SharePoint Timer Service. To
minimize interruption of service to your users, you should plan to install all language packs before your sites go live.
Based on the language requirements of your site collections or sites, determine the language packs that must be
installed on every web and application server. In your spreadsheet, for each site, record the list of language packs
that you want to make available as alternative languages. For information about which language packs are
available, see Language Packs for SharePoint Server 2019, Language Packs for SharePoint Server 2016 and
Language Packs for SharePoint Server 2013.
The following table lists when language packs are or are not required:
Table: When language packs are required
TO DO THE FOLLOWING ARE LANGUAGE PACKS REQUIRED?
Create sites in different languages. Yes
Enable the multilingual user interface on sites. Yes
Use the variations feature to create multilingual content. No
Create variation sites in different languages. Yes
Enable the multilingual user interface on variation sites. Yes
Even though you specify a language for a site, some user interface elements such as error messages, notifications,
or dialog boxes might not appear in the language that you choose. This is because SharePoint Server relies on
several supporting technologies — such as the .NET Framework, Microsoft Windows Workflow Foundation,
ASP.NET, and SQL Server — and some of these supporting technologies are localized into 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, site collection
administrators, or site owners, and is not seen by site users.
NOTE
Error logs that SharePoint Server stores on the server are always in English.
For information about how to install language packs, see Install or uninstall language packs for SharePoint
Servers 2016 and 2019 and Install or uninstall language packs for SharePoint 2013.
Decide whether to use site variations

NOTE
You can only use the variations feature on sites that you create with one of the Publishing site templates, or on a site where
the SharePoint Server Publishing Infrastructure feature is activated.
NOTE
The variations feature is not available in SharePoint Foundation 2013.
The SharePoint Server variations feature enables site owners to make the same content available to specific
audiences across different sites by maintaining customizable copies of the content from the source variation site in
each target variation site. For a multilingual site, you might want to use the primary language of your organization
as the source variation site. You can create the target variation sites in the same language as the source variation
site, or in the language the target variation site is intended to support. If you plan to create the target variation
sites in other languages, verify that the corresponding language packs are installed. For more information about
variations, see Variations overview in SharePoint Server.
When you plan for multilingual sites, consider whether you have to create content that will be shared across sites,
but must be changed to meet regional requirements or translated to meet language requirements. If you think
there is a possibility that you might have to set up variations sites, you should plan for them beforehand. It is very
difficult to integrate variations sites into a site collection after the site structure is implemented. The following
factors can affect your ability to easily move to using variations sites later in the life of your site:
Custom code Code that contains references to the location of the root variations site.
Site customizations Site navigation, Master Pages, and other customizations.
Search Search scopes must be created for each variation label, and the site properties of each variations
site must be changed.
If you plan to translate content on your variations sites, you must decide whether to use human translation or
machine translation. If you plan to use machine translation, make sure that the language to which you want to
translate content is available for the Machine Translation service. For more information about how to plan for
variations, see Plan for variations in SharePoint Server.
See also
Concepts
Plan for the multilingual user interface in SharePoint Server
Variations overview in SharePoint Server
Other Resources
Plan for the multilingual user interface in SharePoint
Server

The multilingual user interface (MUI) feature enables users to display the user interface of a SharePoint Server or
SharePoint Online site in the language they prefer, instead of the default language that was selected when the site
was created. This article describes the use and benefits of the MUI feature, explains how the feature works, and
lists the other features and functionality that are supported by the feature. It also describes how to add and edit
application content, and how to export and import content for translation. It explains how to use the MUI feature
with managed metadata, and describes the limitations of the feature. Finally, this article describes how to plan for
using the MUI feature in a SharePoint Server site solution.
For information about how to plan for multilingual sites, see Plan for multilingual sites in SharePoint Server.
How the multilingual user interface works

By default, when a new site is created, it is created in the default language of the SharePoint Server installation on
the server. A farm administrator must install language packs on all web and application servers in the SharePoint
farm before sites can be created in languages other than the default language. For more information, see Install or
uninstall language packs for SharePoint Servers 2016 and 2019 and Install or uninstall language packs for
SharePoint 2013.
After language packs are installed on the server, the Language settings link is added to the Site Settings page.
Site collection administrators and site owners use the Language Settings page to specify which alternate
languages the site will support. After the site collection administrator or site owner has enabled alternate
languages for a site, the next time that a user logs on to the site, SharePoint Server uses one of the following rules
to determine the language in which to display content to the user:
1. If the User Profile service application is started on the SharePoint Server farm, the language preferences
stored in the user profile are used. For information about how to add a list of languages to user profile
settings in SharePoint Server, see Add, edit, or delete custom properties in SharePoint Server user profiles.
For information about how to add a list of languages to user profile settings in SharePoint Online
Administration Center, see Add and edit user profile properties.
2. If no language preference is defined in the user profile, the language preferences stored in the user's
language settings for the site collection are used.
3. If no language preference is defined in the user's site collection language settings, the language preferences
stored in the user's web browser are used.
4. If no language preference is defined in the user's web browser, the default site language is used.
The MUI feature only displays site's user interface elements in a user's preferred language. It does not translate
content or display content such as documents or list items in an alternate language. To translate webpage content,
you use the variations feature in SharePoint Server or SharePoint Online.
SharePoint Server provides three methods that you can use to change 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.
For information about how to install language packs, see Install or uninstall language packs for SharePoint
Servers 2016 and 2019. For information about how to let individual users change the language that is used to
display their site's user interface, see Choose the languages that you want to make available for a site's user
interface.
Use and benefits of the multilingual user interface feature

The MUI feature enables users to collaborate in a single site by using another language that they prefer, regardless
of which language was selected when the site was created. For example, the default language for a site could be
English, and a user whose preferred language is French will view the site in French, whereas a user whose
preferred language is Spanish will view the site in Spanish.
When you create a site and install language packs on all the web and application servers, you can specify the
default site language. The site will use that language to display the site's user interface, such as site navigation and
administrative pages. If you want to enable site users to view the site's user interface in a preferred language, you
can use the Language Settings page to specify alternate languages that you want to make available to users.
When a user logs on to the site, the users preferred language is used to display the site's user interface. All sites
within that domain name are displayed in the user's preferred language. This does not change the default site
language. Other users who view the site see the site's user interface displayed either in the default site language or
in their preferred language. The site's user interface is changed only for those users who have specified a preferred
language in which to view the site.
The MUI feature, lets team members work on documents and projects in a shared language while they view the
site and perform tasks in their preferred language. In addition to team collaboration, the MUI feature enables
farm, site collection administrators, and site owners to perform administrative tasks in their preferred language.
For example, farm administrators can view the administrative links and instructions on the SharePoint Central
Administration website in their preferred language.
The MUI feature 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 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 users who have their preferred
language set to German logs on to the site, the name of the document library is displayed as
"Mannschaftsberichte." But users who have their preferred language set to English still see the document library
name displayed as "Team Reports."
What is supported by the multilingual user interface

When a user views a site in a preferred language, certain elements of the user interface are displayed in the
preferred language. Generally, most user interface elements can be displayed in the preferred language, but user-
created content cannot be. The following list includes examples of items that are supported by the MUI feature:
Settings pages, such as those in the _layouts and the _admin virtual directories.
SharePoint 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.
List views.
Web Part titles, descriptions, custom properties, and import error messages.
The Blog site template.
Not all user interface elements are displayed in the preferred language. The following list includes examples of
items that aren't supported by the MUI feature:
Global breadcrumbs.
User-created content, such as list item data, documents and web pages in libraries, custom permission
levels, and groups.
For more detailed information about the user interface elements that are not supported by the MUI feature, see
Limitations of the multilingual user interface.
Managing application content

Application content includes 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. The MUI feature enables users to add or edit application content either in the default site
language or in one or more alternate languages. You can also choose to export and import application content for
bulk translation.
Adding and editing application content
When users add or edit application content, the following rules apply:
When users view a site in the default site language, any new application content that they create
is displayed in the default site language, even when the site is viewed in another language.
For example, if the default site language is English, when a user views the site in English and creates a new
document library named "Team Documents," the library title is still displayed as "Team Documents" when
the user views the site in French.
When users view a site in another language, any new application content that they create is
displayed in that language, even when the site is viewed in the default site language, or in any
other language.
For example, if the default site language is English, and a user views the site in German and adds a
document library named "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 default site language or into an alternate language, users must first change
the language preference either in their user profile, or in their web browser settings, to display the site in
the language they want to use, and then change the user interface string. The exception to this behavior is if
the Overwrite Translations option is enabled. For more information, see Overwriting translated
application content.
When a site is displayed in a user's preferred language, any changes that are made to existing application content
strings are changed for that language only. The strings that are associated with specific application content in the
default site language and any alternate languages remain unchanged. To translate application content strings, such
as a document library title into the default site language or into any alternate languages, the user must change the
language preferences in the browser or user profile to display the site in the default or switch language, and then
make the change to the user interface strings.
Overwriting translated application content
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 default site language will overwrite any changes that were made
to those same user interface elements in switch languages.
By default, when a user views a site in the default site language, any changes that are made to existing application
content are changed for the default site language only. The strings that are associated with specific application
content in the alternate languages remain unchanged. If the Overwrite Translations option is enabled, the
strings that are associated with that application content for every language are replaced with the new default site
language string. For example, if the default site language 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 default site language. If the
Overwrite Translations option is enabled, the title is changed to "Team Documents" for every alternate language,
and it must be re-translated.
Exporting and importing translated application content
The MUI 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 changed application content in
the default site language or in one of the alternate languages. To export content, you use the Export Translations
link on the Site Settings page. When you export application content for an alternate language, you can choose 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 are translated, you use the Import Translations link on the Site Settings page to import the
.resx file.
Using the multilingual user interface with managed metadata

You can create multilingual managed metadata to use with a SharePoint Server solution. Use the Term Store
Management Tool, to create a term set and associate multiple labels, one for each language that you want to
support, with each term in the set. When a user views the site in the user's preferred language, the terms are
displayed by using the labels that correspond to the preferred language.
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 MUI feature. This section describes additional limitations that apply when you use the MUI feature with
shared components and site templates.
Shared components
Shared components, such as 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.
Lists
List views are MUI-enabled, but list items are not because they are user-created content. List items will continue to
display the values that were entered when they were created, regardless of the user's preferred language.
Permissions
The following properties that are associated with permissions are not MUI-enabled. They are always displayed in
the default 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.
Custom permission level names and descriptions These include any custom permission levels that
were created or changed by a user.
User information User information such as About Me, Title, and Department.
Search site templates
Many of the Search site limitations are not actually related to MUI features, but are architectural designs that
affect the user interface. The following limitations are a mix of MUI and architectural limitations for Search sites:
Search Search indexes content in the default language of the SharePoint Server installation. Even if content
is provided in alternate languages, that content is only searchable by using the default site language. For
example, if your preferred language is German, and the default site language is English, a search for
"Freigegebene Dokumente" returns no results. A search for "Shared Documents" does return results.
Search Web Part properties Title, description, and custom properties are MUI-enabled. But if the default
search prompt for the search box is customized, its customized value will be displayed for all languages.
Refinement Panel Web Part The Refinement Panel Web Part is not MUI-enabled. Term store labels that
are displayed in the Refinement Panel Web Part are always displayed from the search index, which only
stores items in the default site language. For example, if your preferred language is Italian, and the default
site language is English, and you have a document that uses term store labels that contain values for both
languages, the Refinement Panel Web Part will display only the English label.
NOTE
This does not apply to the Taxonomy Refinement Panel Web Part, which displays the same language labels as the
ones used in managed navigation.
Plan to use the multilingual user interface

Planning to use the MUI feature with a SharePoint Server site involves the following tasks:
Determine site language requirements.
Plan to install Public Update.
Plan to translate application content.
Determine site language requirements
Before you can use the MUI feature in SharePoint Server sites, the farm administrator must install language packs
on all web and application servers so that they are available to use on sites. Decide which language packs are
needed, and when they will be installed on the server. Site collection administrators or site owners must configure
the language settings for individual sites to make specific languages available to site users. You must decide which
languages are needed for each site, and plan to have the site collection administrators or site owners enable
specific languages for the sites that they manage. For information about how to plan multilingual sites, see Plan
for multilingual sites in SharePoint Server. For information about how to install language packs, see Install or
uninstall language packs for SharePoint Servers 2016 and 2019 and Install or uninstall language packs for
SharePoint 2013.
Plan to install Public Update
If language packs are updated as part of a public update for SharePoint Server, you must update the language
packs on the servers when the public update is installed. You should plan to coordinate with the farm
administrator to monitor the release of public update and any associated language packs so that you know about
updated language packs that must be installed for users.
Plan to translate application content
If you plan to enable the MUI feature on your site to provide users a way to collaborate while they use their
preferred language, you must decide whether the default MUI feature is sufficient, or whether application content
must also be translated. If you have application content that must 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 is needed, or will you export resource files in the
languages that are needed for the site, and have them all translated at the same time? If users create new
application content in an alternate language, you must plan for who will translate that content into the
default site language and for each alternate language. 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 alternate languages.
Who will translate the application content? Will resource files be translated by someone within your
organization, or will you 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 default site language to
overwrite string values in alternate 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?
See also
Concepts
Plan for multilingual sites in SharePoint Server
Variations overview in SharePoint Server
Plan for variations in SharePoint Server
Other Resources
Overview of themes in SharePoint Server

Themes give you a quick and easy way to change the look and feel of any site in SharePoint Server. They are pre-
designed collections of web page elements, such as fonts, color schemes, layout, and background pictures that
come with SharePoint Server. In SharePoint Server, you can apply a theme to a site, and then preview it before
committing the change. You can change the theme of a site any number of times. For more information about
themes, see Themes overview for SharePoint 2013. Note that this article still applies to SharePoint Server.
Using themes is one way to change the look and feel of a site. Themes are part of the larger, updated branding and
design capabilities in SharePoint Servers 2016 and 2019.
The SharePoint Server 2019 modern experience includes new Team and Communication sites. These modern sites
contain visually compelling web parts that you can customize. For more information, see What is a SharePoint
team site? and What is a SharePoint communication site?
This article includes an overview of themes and how they work. This article does not describe how to create
custom themes, called composed looks, or how to upload and manage themes in a theme gallery. It also doesn't
discuss how to plan for the overall branding of sites by using master pages or cascading style sheets.
About themes
Themes enable lightweight branding of a SharePoint Server site by allowing a site owner or a user who has
designer rights to make changes to the color palette, site layout, font scheme, and background of a site. Themes are
applied and customized directly in the user interface, and do not require knowledge of cascading style sheets or
master pages.
By default, a theme is only applied to the site for which it is selected. It is not inherited by any subsites unless you
are working with a publishing site., Or, if the publishing feature was enabled for a site, you can choose to either
inherit the theme from the parent site or specify a theme that will be used by the site. When working publishing
sites and you want more control over your customizations than themes can provide, use Design Manager.
NOTE
Themes were redesigned in SharePoint 2013 to simplify the process of customizing sites by changing the site layout, color
palette, font scheme, and background image. The themes user interface has been redesigned and there is a set of new file
formats related to themes. The themes remain the same in SharePoint Server 2016. Themes created in SharePoint 2010
Products cannot be used on SharePoint Server sites. However, they can still be used on site collections that have not been
upgraded and are running in 2010 mode.
Components of the themes experience

The following section provides an overview of the terminology and user interface components that comprise the
themes experience in SharePoint Server.
The following list describes the themes terminology used in this article:
Design A design, or composed look, is the color palette, font scheme, background image, and master page
that determine the look and feel of a site. When used to discuss the overall look of a site, design and theme
can be used interchangeably.
Image The background image used for the site. You can change this in any of the pre-configured themes.
Color palette A color palette, or color scheme, is the combination of colors that are used in a site. You can
select from a number of predefined color combinations.
Site layout A master page defines how all the elements are structured on the page. There are two site
layouts available for each of the pre-configured themes.
Font scheme Defines the fonts used in a site. You can select from a list of available fonts.
Theme gallery
You can access thumbnails of themes and apply them to a site through the Change the look gallery available in
site settings.
The theme gallery can be accessed in the following ways:
Click Settings, and then click Change the look, or
On the Site Settings page, under Web Designer Galleries, click Themes, or
On the home page, click the What's your style? tile. This link isn't available in SharePoint Server 2019
modern team or communication sites.
Master page gallery
The master page gallery lists the master page files, and their corresponding preview files (.preview ), that are used
by the themes user interface. The preview files are used to render the thumbnail images in the design gallery. If a
master page does not have a corresponding preview file, it cannot be used in the design gallery.
To access the master page gallery, on the Site Settings page, under Web Designer Galleries, click Master
pages.
Composed looks list
The composed looks list shows the designs that are available to the design gallery. A design includes the design
name, master page URL, color palette URL, image URL (optional), font scheme URL (optional), and display order
number.
To access the composed looks list, on the Site Settings page, under Web Designer Galleries, click Composed
looks.
Ways to use themes

There are three ways to use themes on a site:
Use a preinstalled theme.
Modify a preinstalled theme.
Upload a custom theme (composed look) to the gallery.
Use a preinstalled theme
SharePoint Server comes with preinstalled themes, including the default SharePoint theme. When a new site is
created, it will use the default SharePoint theme.
Modify a preinstalled theme
When a preinstalled theme is modified, a new theme called Current is created automatically after the theme
changes have been applied. There can only be one Current theme for a site. SharePoint Server does not provide a
way to save themes within the user interface. If you modify a preinstalled theme, apply the changes (thereby
creating a new theme called Current), and then modify a second preinstalled theme. The second preinstalled theme
becomes the Current theme when the settings are applied.
To save a modified theme, create a new list item in the composed looks list that contains the same master page,
color palette, font scheme, and background image URLs of the modified theme (the modified theme is called
Current in the composed looks list).
Upload your own Composed Looks files to the theme gallery
You can create custom themes by creating additional color palettes and font schemes and uploading them to the
theme gallery. The new color palettes and font schemes are then available to you when you choose to modify a
design in the design gallery. Similarly, if you want to have additional site layouts to choose from, you can upload
additional master pages, and corresponding preview files, to the master page gallery. For more information, see
SharePoint site theming.
You can create new designs by creating new list items in the composed looks list. Create a new list item and specify
the master page, color palette, font scheme, and background image for the new design.
See also
Other Resources
Use composed looks to brand SharePoint sites
Branding SharePoint sites in the SharePoint add-in model
Change the look of your SharePoint site
Plan for site maintenance and management in
SharePoint Server

Every site and site collection in your SharePoint Server farm uses system resources, such as storage, processing,
and network. If sites are unused or abandoned they use resources but don't deliver any business value, and so they
are using storage space that could be used somewhere else. Out-of-control sites use system resources beyond
what your original plan may have allocated to them. In both cases, access to system resources is being denied and
performance will suffer, overhead increases, and manageability decreases. To help you avoid these issues, you need
to plan for managing your sites and site collections. This article tells you about the tools you can use to manage
sites and site collections in SharePoint Server.
Quotas
The first step in controlling the amount of resources that your sites and site collections use is to establish and apply
quota templates. Quotas let you control how much data a site collection can hold and then lock the site to further
content when site storage reaches a maximum size. With quotas you can also control the amount of resources,
such as processor and memory, that a site or site collection can use. Quotas let you set storage limit values and
warning limit values as well as resource utilization limits which applications cannot exceed. Once you configure and
apply quotas, you reduce the impact of issues caused by out-of-control site collections. For more information on
working with quotas and how to configure them, see Create, edit, and delete quota templates in SharePoint Server.
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 which quota
template to use. Note that sites created by using Self-Service Site Management use the default quota for the
web application.
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 email 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 they are blocked from completing that task
with very little notice.
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.
Create a plan to back up site content often. Determine or discover how often backups will be made, and the
process for restoring content when necessary. For more , see Plan for backup and recovery in SharePoint
Server.
Usage reports
Quotas prevent site collections as a whole from exceeding the limits you set, but within a site collection, some sites
and pages will be used more than others. In order to balance your system resources you need to be aware of highly
used pages and sites and of underused or abandoned sites. The highly used sites may need more resources and
underused or abandoned ones should be archived or deleted. 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
allow 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
content database contains 100 sites, and one of those sites is taking up more than 50 percent of the space, then you
might need to move that site collection to a different content database. This will ensure that you preserve some
room for additional growth, while maintaining the ability to back up and restore the databases.
In SharePoint Server usage reports let you track the number of hits and number of unique users for a site or site
collection on a daily and monthly basis. Before you can view the reports, a farm administrator must configure
usage and data collection. For more information, see Configure usage and health data collection in SharePoint
Server. For more information on viewing and using usage reports, see View usage reports in SharePoint Server.
Site and site collection deletion

You need to plan how you will handle sites that become inactive after a project has ended, or sites that users
created just to test some ideas, but 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 email message to site owners to see if they consider their site active. If the owner does not respond to
the email message (after a specified number of messages over a specified length of time), the site can be deleted.
For more information on managing unused site collections, see Manage unused site collections in SharePoint
Server.
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. Usually a site that was created, 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 email message to site owners to see if their sites are inactive. After the first
email message, if the site administrator does not respond, you can continue with additional notices at daily,
weekly, or monthly intervals.
If you want to automatically delete unused sites. If the site administrator does not respond to multiple email
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.
If you are going to automatically delete unused sites, how many email 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.
See also
Concepts
Manage unused site collections in SharePoint Server
Create, edit, and delete quota templates in SharePoint Server
Configure usage and health data collection in SharePoint Server
Delete and restore site collections in SharePoint Server
Create a site collection in SharePoint Server
Manage site collections in SharePoint Server

The following articles provide information about how to create and delete site collections, how to manage site
collection administrators, how to use quota templates to manage site collection storage limits, and how to create
connections between specific types of sites in SharePoint Server.
NAME DESCRIPTION
Create a site collection in SharePoint Server How to create a site collection based on an existing Web
application or create a Web application and then create a site
collection within that application.
Delete and restore site collections in SharePoint Server How to delete the content, user information, and site
hierarchy that comprise a site collection and restore a site
collection that has been deleted.
Types of files that cannot be added to a list or library How to restrict files from being uploaded or downloaded
based on their file name extension.
Manage the lock status for site collections in SharePoint How to add or remove a lock from a site collection.
Server
View all site collections in SharePoint Server How to see the list of site collections.
Manage a connection to a document center or a records How to connect a web application to a SharePoint Server
center in SharePoint Server document center or records center and how to modify and
delete connections.
Change site collection administrators in SharePoint Server How to change site collection administrators for SharePoint
Server site collections by using Central Administration or the
SharePoint 2016 Management Shell.
Create, edit, and delete quota templates in SharePoint Server How to create, edit, and delete site quota templates for a
SharePoint Server site collection.
See also
Administration of SharePoint Server

A site collection is a grouping of websites under a common top-level site 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. For
info about creating site collections in SharePoint Online, see Create a site collection.
Before you begin

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 email alert to the site collection administrator. For more information,
see Create, edit, and delete quota templates in SharePoint Server.
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 in SharePoint
Server.
Create a site collection by using Central Administration

You typically use the SharePoint Central Administration website to create a site collection in a stand-alone
deployment.
To create a site collection by using Central Administration
To create a site collection, you must be a member of the Farm Administrators SharePoint group on the
computer that is running the SharePoint Central Administration website.
2. Open Central Administration and 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, choose the tab you want for the site
collection ( Collaboration, Enterprise, or Publishing), and then select the template that you want to use
for the top-level site in the site collection. You can also click the Custom tab to create an empty site and
apply a template later.
A description for the template that you select appears below the list of templates.
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.
Assigning 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 available.
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 and then click OK.
Create a site collection by using Microsoft PowerShell

You typically use Microsoft 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 PowerShell
local Administrators group on the server on which you are running the PowerShell cmdlets.
3. At the command prompt, type the following commands:
Get-SPWebTemplate
$template = Get-SPWebTemplate "STS#0"
New-SPSite -Url "<URL for the new site collection>" -OwnerAlias "<domain\user>" -Template $template
This example retrieves a list of all available site templates and then creates a site collection by using the
Team Site template. For more information, see New -SPSite and Get-SPWebTemplate.
We recommend that you use Microsoft 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
Delete and restore site collections in SharePoint
Server

If you've 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 the hierarchy of sites that comprise the collection. Deleting a
site collection, also permanently destroys 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 website.
Subsites of the top-level website, their contents, and user information.
NOTE
You should back up a site collection before you delete it. For more information, see Plan for backup and recovery in
SharePoint Server.
If the site collection is associated with a Project Server service application, you must remove the association and
delete the Project Web App before you delete the site collection. You can remove the site collection association
with the Project Server service application from service application settings page in the SharePoint Central
Administration website.
Before you begin

Before you delete a site collection, ensure that a backup copy of the site collection and all of its contents exists.
There are two recycle bins in SharePoint and the retention time for each is as follows:
Site Recycle Bin (First-Stage) = 30 days
Site Collection (Second Stage) = 50% of the site quota
The maximum possible retention time for an item is 30 days. If you don't reach the second stage quota limit, the
deleted item stays in one of the recycle bins for 30 days. If an item is deleted and resides in the first stage recycle
bin, it is retained for the entire 30 days since it will still count against your quota. If an item is deleted and resides
in or is moved to the second stage recycle bin, it does not count against your quota unless it's a deleted SharePoint
web application, but the retention time for this item could be less than the 30 days if the total amount of content in
the second stage bin exceeds the 50% of the site quota.
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
To delete a site collection, the user account that is performing this procedure must be a member of the
Farm Administrators SharePoint group.
2. Open Central Administration.
3. On the Central Administration website, click Application Management.
4. On the Application Management page, in the Site Collections section, click Delete a site collection.
5. On the Delete Site Collection page, in the Site Collection list, click Change Site Collection.
The Select Site Collection webpage dialog box appears.
6. In the Web Application list, click Change Web Application.
The Select Web Application webpage dialog box appears.
7. 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.
8. Click the relative URL of the site collection that you want to delete, and then click OK.
9. Read the Warning section and verify that the site collection information is correct.
10. On the Delete Site Collection page, click Delete.
Delete a site collection by using Microsoft 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 PowerShell
1. Verify that you meet the following minimum requirements:
Local Administrators group on the server on which you are running the Microsoft PowerShell
cmdlets.
3. At the PowerShell command prompt, type the following command, and then press ENTER:
Remove-SPSite -Identity "<URL>" -GradualDelete
Where: <URL> is the unique address 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 to use 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
Restore a site collection by using Microsoft PowerShell

If you've accidentally deleted a site collection, you can restore it using PowerShell.
When a site collection (that is, a SPSite object) is accidentally deleted in SharePoint Server, the deleted site
collection is stored in the SPDeletedSite object, not the SPSite object. To restore a deleted site collection, you
must use the Restore-SPDeletedSite cmdlet or programmatically access the object model.
SharePoint Server 2019 users can restore items that they've deleted themselves, and also items that other users in
the site have deleted. Users need edit permission on the deleted items so they're visible in their SharePoint recycle
bin.
See also
Concepts
Overview of sites and site collections in SharePoint Server
Manage the lock status for site collections in
SharePoint Server

You use the lock status of a site collection to control the actions allowed on a site collection.
The following table describes the locking options that are available in SharePoint Server.
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 (blocks additions, updates, and deletions) Prevents users from adding, updating, or deleting content.
When a user attempts to add, update, or delete content, the
user receives an error message that informs the user that
access is denied and that the user does not have permission
to perform the action or access the resource. A read-only lock
can be either site collection administrator controlled if the site
collection is archived or farm administrator controlled
No access Prevents users from accessing the site collection and its
content. Users who attempt to access the site receive an error
page that informs the user that the website declined to show
the webpage.
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 in SharePoint Server.
IMPORTANT
The steps in this article apply to SharePoint Server 2016, SharePoint Foundation 2013, and SharePoint Server 2013.
Manage the lock status for a site collection by using Central

Administration
Use this procedure to lock or unlock a site collection by using the SharePoint Central Administration website.
To manage the lock status for 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. Open Central Administration. On the Application Management page, in the Site Collections section,
click Configure quotas and locks.
3. If the site collection you want is not 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.
4. 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. Choose whether you want this to be farm administrator controlled or site collection
administrator controlled.
No access to prevent users from accessing the site collection and its content. Users who attempt to
access the site receive an error message.
5. 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.
6. Click OK when you are done.
Manage the lock status for a site collection by using Microsoft

PowerShell
Use this procedure to lock or unlock a site collection by using PowerShell.
To manage the lock status for a site collection by using PowerShell
1. Verify that you meet the following minimum requirements: See Add-SPShellAdmin.
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 message.
For more information, see Set-SPSite.
See also
Concepts
Create, edit, and delete quota templates in SharePoint Server
Other Resources
Manage site collections and global settings in the SharePoint admin center
View all site collections in SharePoint Server

A site collection is a group of websites that have the same owner and share administrative settings, for example,
permissions, and quotas. 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
Refer to the following table in step 3.
ITEM DESCRIPTION
URL The URL of the site collection.
Title The current title for site collection.
Description The current description for the site collection.
Primary administrator The primary administrator for the site collection.
Email address The email address for the primary administrator.
Database name The content database that is used by the site collection.

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 website.
2. Open Central Administration. 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.
3. To display more information about a site collection, in the URL column, click the site collection.
The table just before this procedure appears on the right side of the page.
4. 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 Microsoft PowerShell
2. Open SharePoint Management Shell.
Get-SPWebApplication | Get-SPSite -Limit All | Format-Table -Property URL,ContentDatabase
NOTE
This command displays the URLs of all the web applications in a server farm and the site collections in each web
application.

We recommend that you use Microsoft 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
Manage a connection to a document center or a
records center in SharePoint Server

A connection is a path used for sending documents to a document center or a records center. The connection
specifies the web application that documents will be sent from, the document center or records center that they will
be sent to, and certain aspects of how the documents are sent. A records center is a site that is designed for records
management.
Connections are created by a farm administrator in SharePoint Server. The farm administrator configures the
connection to copy content, to move content, or to move the content and leave a link in the source site collection.
NOTE
The destination document or record center must already exist before you perform the procedures for this task. You also need
the URL of the destination document or record center for the procedures in this article.
Create a connection
Use this procedure to create a connection to a document repository or a records center.
To create a connection
1. To create a connection, you must be a member of the Farm Administrators group.
2. On the SharePoint Central Administration website, click General Application Settings and in the
External Service Connections section, select Configure Send To Connections.
3. On the Configure Send To Connections page, in the Web Application field, select the web application
that hosts the site collections from which documents will be sent.
4. In the Tenant Settings section, select Allow sites to send to connections outside their tenancy if you
want tenants on this farm to able to send content to other tenants on this farm.
5. In the Send To Connections list, select New Connection.
6. In the Display name field, type a name for this connection. This is the name that users will see as one of the
options to which to send a document.
7. In the Send to URL field, enter the URL to the Content Organizer for the destination site. (To find the
correct URL go to the Site Settings page, in the Site Administration section, click Content Organizer
Settings, and then look in the Submission Points section of the Content Organizer : Settings page of
the destination repository.) Use Click here to test if you want to confirm that you have entered a URL to a
Content Organizer.
8. To display this connection in the list that appears when a user clicks Send To, select Allow manual
submission from the Send To menu.
9. In the Send To action list, select one of the following values:
Copy Select this option to create a copy of the document and send the copy to the destination
repository.
Move Select this option to delete the document from its current location and move the document to
the destination repository. Users will no longer be able to access the document from its original
location.
Move and Leave a Link Select this option to delete the document from its current location, move it
to the destination repository, and leave a link at the current location indicating that the document has
been moved. When a user clicks this link, a page will appear that displays the URL of the document
and the document's metadata.
10. In the Explanation dialog box, type the information to be added to the audit log when the user sends a
document by using this connection. If you selected Move and Leave a Link in the previous step, the page
that appears when the user clicks the link will also display the explanation.
11. Click Add Connection to create the connection, and then click OK when you are finished configuring
connections.
NOTE
The Allow sites to send to connections outside their tenancy option applies to all site subscription connections in a web
application, and is not used when you add, modify, or delete a single connection.
Modify a connection
Use this procedure to modify an existing connection to a document repository or a records center.
To modify a connection
1. To modify a connection, you must be a member of the Farm Administrators group.
2. On the Central Administration website, click General Application Settings, and select Configure Send
To Connections.
that contains the site collections that use this connection.
4. In the Send To Connections list, select the connection that you want to modify.
5. Modify any of the connection settings as described in the previous procedure.
6. Click Update Connection to modify the connection, and then click OK when you are finished configuring
connections.
Delete a connection
Use this procedure to delete an existing connection to a document repository or a records center.
To delete a connection
1. To delete a connection, you must be a member of the Farm Administrators group.
2. On the Central Administration website, click General Application Settings, and select Configure Send
To Connections.
that contains the site collections that use this connection.
4. In the Send To Connections list, select the connection that you want to delete.
5. Click Remove Connection to delete the connection, and then click OK when you are finished configuring
connections.
See also
Concepts
Other Resources
Change site collection administrators in SharePoint
Server

A site collection administrator in SharePoint Server can configure the appearance and behavior of the site,
configure search settings and site directory settings, and allocate storage space. A site collection must have one
primary site collection administrator and can have one secondary site collection administrator. The primary and
secondary site collection administrators receive administrative email alerts for the site collection. The primary and
secondary site collection administrators are automatically added to the SharePoint Site Collection Administrators
group. You can add as many additional accounts as you want to the SharePoint Site Collection administrators
group, but only the primary and secondary site collection administrators will receive administrative alerts for the
site collection. All members of the SharePoint Site Collection Administrators group have full administrative
permissions to the site collection.
Change the primary or secondary site collection administrator

Use this procedure when you want to make a user a primary or secondary site collection administrator for a
specific site collection.
Cau t i on
A site collection can have only one primary site collection administrator and one secondary site collection
administrator. The steps in this procedure describe how to change either of them. Any user who is removed as a
site collection administrator is removed from the site collection administrators group for the site collection.
To change the primary or secondary site collection administrator by using Central Administration
To add a site collection administrator, you must be a member of the Farm Administrators group on the
computer that is running Central Administration.
2. In Central Administration, click Application Management. On the Application Management page, in
the Site Collections section, click Change site collection administrators.
3. On the Site Collection Administrators page, click the arrow next to the site collection name, and then
select Change Site Collection if the site collection you want is not already selected.
4. 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.
5. In the Primary site collection administrator or 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.
6. Click OK.
To add a primary or secondary site collection administrator by using Microsoft PowerShell
3. At the PowerShell command prompt, type the following command to replace the secondary site collection
administrator:
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 secondary site collection
administrator. You can specify different parameters to configure different settings for a site collection. For more
information, see Set-SPSite.
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
To remove a site collection administrator, you must be a member of the Farm Administrators group on
the computer that is running Central Administration.
2. In Central Administration, select Application Management. On the Application Management page, in
the Site Collections section, click Change site collection administrators.
3. On the Site Collection Administrators page, click the arrow next to the site collection name, and then
click Change Site Collection.
4. 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.
5. 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.
6. To remove the secondary site collection administrator, select the administrator's name, and then press the
Delete key.
7. Click OK.
See also
Concepts
Other Resources
Manage administrators for a site collection
Create, edit, and delete quota templates in
SharePoint Server

You control how much data a site collection can hold and the quantity of resources it can use by using quotas. For
more information about how to plan quotas, see Quotas.
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. 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.
Before you begin

Before you perform this procedure, confirm the following:
Outgoing email is configured.
For more information, see Configure outgoing email for a SharePoint Server farm.
The Disk Quota Warning timer job is running.
For more information about default timer jobs for SharePoint Server, see Timer job reference for
SharePoint Server.
The quota template options on the quota template page in Central Administration are available only if you
have already created one or more quota templates. The first time that you use this page, you will be given
only the option to create a new 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
You are a member of the Farm Administrators group on the computer that is running the SharePoint
Central Administration website.
2. On the Central Administration home page, click Application Management. On the Application
Management page, in the Site Collections section, click Specify quota templates.
3. On the Quota Templates page, in the Template Name section, click Create a new quota template.
4. 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.
5. 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 email 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.
6. In the Sandboxed Solutions with Code Limits section, set the values for a template for sandboxed
solutions.
In the Limit maximum usage per day to box, type the daily usage in points.
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.
If you do not want to send a warning email message, clear the Send warning e-mail when usage per
day reaches check box, and then 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
3. 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.
4. 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.
Even though you can delete a quota template if necessary, we do not recommend that you do this. Since deleting
a quota template will not delete quota values from sites that were created by using the quota template. Instead,
we recommend that you use the object model to perform minor fixes in the quota template.
To delete a quota template
3. In the Template Name section, expand the Template to modify list, and then click the template that you
want to delete.
4. At the bottom of the Quota Templates page, click Delete, and then click OK.
Change the settings of a quota template

NOTE
A 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

You must be a member of the Farm Administrators group.
3. On the Quota Templates page, in the Template Name section, in the Template to modify list, select the
template that you want to change.
4. 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 email 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.
5. 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 email 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.
6. 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 so the quota template 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
Management page, in the Site Collections section, click Configure quotas and locks.
3. 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.
4. In the Site Quota Information section, expand the Current quota template list, and select the new
quota template to apply, and then click OK.
To change the quota template for a site collection by using Microsoft PowerShell
3. At the Microsoft PowerShell command prompt, type the following command:
Set-SPSite -Identity "<Site>" -QuotaTemplate "<Template>"
Where:
<Site> is the URL or GUID of the site collection whose quota template that you want to change.
<Template> is the name or GUID of the replacement quota template.
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
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, 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. Select the Limit site storage to a maximum of check box, and then type the new maximum value in
megabytes.
7. If you want to send site storage notification email 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 email 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 PowerShell
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 bytes.
NOTE
The new storage limit overrides the limit set in the quota template that is currently applied to the site collection.

For information about how to use 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, an excerpt from the book Inside Microsoft SharePoint
2010 on MSDN.
See also
Concepts
Manage the lock status for site collections in SharePoint Server
Manage unused site collections in SharePoint Server
NOTE
To send email notifications, you must configure outgoing email settings. For more information, see Configure outgoing email
for a SharePoint Server farm.
Site usage confirmation and deletion can help to free resources that are used by site collections 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.
Before you begin

Before completing the procedure in this article, you should determine the following:
How long to wait before you check whether a site collection is inactive.
How often to send email notifications to site owners to see whether their sites collections are inactive. After
the first email notification, if the site collection owner does not respond, you can continue to send additional
notices at daily, weekly, or monthly intervals.
Whether you want to automatically delete unused site collections or delete a site collection if the owner
does not respond to multiple email notifications. If you delete site collections without an owner's approval,
we recommend that you first back up the site.
If you plan to automatically delete unused site collections, determine how many email notifications you will
send to the site owner before you do so. By default, 28 daily notices are sent before site collection 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 email notification
contains links to confirm whether a site collection is active or inactive. After an email notification is sent to
the site collection owner, there are three possible results:
If the site collection owner confirms that the site collection is active by clicking the confirmation link
in the email notification, the certification date of the site collection is renewed.
The site collection owner continues to receive periodic email 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, email 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 collection:
Require a secondary site collection owner when users create site collections. By default, the site collection
creator is listed as the 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 site collections

Use this procedure to manage unused site collections. You can follow these steps to determine the schedules for
notifying site collection owners of site collection inactivity before deleting unused site collections.
To manage unused site collections
1. Verify that you meet the following minimum requirements:
You must be a member of the Farm Administrators group on the computer running the SharePoint
2. In Central Administration, on the Application Management page, in the Site Collections section, click
Confirm site use and deletion.
3. 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.
4. In 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 collection creation or after the site
collection usage is confirmed, to start to send notifications. The default number of days is 30, and the
maximum is 365.
Specify a daily, weekly, or monthly schedule for email notifications. By default, the schedule is daily.
You can also specify the exact time to run the check for the site collection usage. By default, the 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
Delete and restore site collections in SharePoint Server

In SharePoint Server, 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
then, 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.
You can use web parts on web parts pages, wiki pages, content pages, and publishing pages.
The web parts infrastructure in SharePoint Server 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.
NOTE
The apps for SharePoint add functionality to a site. Site owners can add apps for SharePoint to SharePoint sites so that they
and other users of the site can use the application. For more information, see Add apps for SharePoint to a SharePoint site.
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 that are responsible for configuring permissions on Web Parts pages
and Web Parts.
Table: Security roles to configure Web Parts and Web Parts pages
RECOMMENDED
ROLE CATEGORY APPLIES TO DESCRIPTION GUIDELINES
Developer Input Validation Web Part code Input validation refers Building Secure
to how your ASP.NET Pages and
application filters, Controls
scrubs, or rejects Creating Web Parts
input before For SharePoint
additional processing.
This includes
verification that the
input that your
application receives is
valid and safe.
RECOMMENDED
ROLE CATEGORY APPLIES TO DESCRIPTION GUIDELINES
Server administrator Authentication IIS Authentication is the Plan for user

process where an authentication
entity validates the methods in
identity of another SharePoint Server
entity, typically
through credentials
such as a user name
and password.
Site administrator/ Authorization Site collections Authorization is the Authorization and

Server administrator process that provides Authentication
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.
Server administrator Configuration .NET Framework Configuration Code Access Security

Management configuration management Microsoft Windows
encompasses a broad SharePoint Services
range of settings that and Code Access
allow an Security
administrator to Using Code Access
manage the Web Security with ASP.NET
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.
Thank you to Waqas Sarwar, Microsoft MVP, for providing the following article about web part security in
SharePoint Server 2016, SharePoint 2016 Central Admin - Security - Manage Web Part security.
The following articles about managing web parts in SharePoint Server are available in this section:
CONTENT DESCRIPTION
Configure and deploy web parts in SharePoint Server How to secure and deploy web parts in SharePoint Server.
Edit existing web parts in SharePoint Server How to edit web parts and web part properties in SharePoint
Server,
See also
Concepts
Configure and deploy web parts in SharePoint Server
Edit existing web parts in SharePoint Server
Other Resources
Add, edit, minimize, or delete a Web Part from a page
Using web parts on pages

SharePoint Server 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. 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 can deploy a web part to SharePoint Server by right
clicking the project and selecting Deploy. The destination for the web part is determined by the trust level
established with the SharePoint server when the developer created the project in Visual Studio.
SharePoint Server 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 they provide a broad range of
settings that server administrators use to manage the Web application and its environment. For more information
about ASP.NET configuration files, see Machine.Config and Web.Config Explained in "Securing Your ASP.NET
Application and Web Services".
Configuration options
ASP.NET web parts are deployed to either the SharePoint Server bin directory or to the Global Assembly
Cache (GAC ).
Bin directory Stored in the bin folder under the root directory of your Web application.
Advantages of this location:
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.
Disadvantages of this location:
To run your web part everywhere, you must deploy your assembly to the Bin directory on each SharePoint
Server 2016 server with the MinRole Front-end and Application server roles, and each SharePoint 2013
server with web and application role installed.
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.
Advantages of this location:
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.
Disadvantages of this location:
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 configure 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, the Bin directory and its contents are assigned minimal code access security permissions. 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.
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.
Cau t i on
The WSS_Minimal and WSS_Medium entries in the Web.config file are case sensitive.
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 use 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 Microsoft PowerShell to deploy the web part.
To manually deploy and configure a web part
You must be a member of the local Administrators group on the server hosting SharePoint Server.
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:
<SafeControl Assembly="<YourWebPartName>, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"
Namespace="<YourWebPartNamespace>" TypeName="*" Safe="True" AllowRemoteDesigner="True"/>
Where:
<YourWebPartName> is the name of the web part that is being deployed.
<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 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. After you create a CAB file, follow these steps to deploy the
web part.
To deploy the web part by using Microsoft PowerShell
3. At the PowerShell command prompt (PS C:\>), type the following command, and then press ENTER:
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.
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.
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
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.
See also
Concepts
Other Resources
How to: Deploy, Publish, and Upgrade SharePoint Solutions on a Remote Server
Edit existing web parts in SharePoint Server

SharePoint Server web parts can be edited to change their view, appearance, layout and other properties. Editing a
SharePoint Server web part can be fast and simple, and done right on the page where the web part is found. The
procedure for editing a SharePoint Server web part is the same for all web parts, but the editable properties for
each may be different. In all cases you'll be using your Web browser and be working on each SharePoint Server
web part individually. This topic will cover this common procedure and describe the overall process for SharePoint
Server web part editing. Specific properties for each web part will not be covered as help for these is available
from right inside your browser on your SharePoint Server site page.
The SharePoint Server 2019 modern experience includes the Team, Community, and Communication sites. These
pages are pre-populated with unique web parts, like the Hero, News, Events, and Documents web parts. For more
information, see Classic and modern web part experiences and Using web parts on SharePoint Online pages.
Editing a SharePoint Server 2016 web part

The procedure for editing a SharePoint Server web part involves editing the page the web part is on, and then
editing the web part itself. This procedure is the same for all web parts and can be used on any web parts on the
page you edit. Keep in mind, since that this procedure describes how to edit any web part, it covers only the
procedure to take you to the step where the web part is ready to edit and its properties are available for editing, it
will not describe any of the properties available for editing for any specific web part. Specific web part property
information is available for many web parts individually on the page you're editing using the SharePoint Server
online help found right next to your username and the settings Gear icon on every SharePoint Server page in the
form of a Question Mark icon.
How to edit web parts
1. Confirm that you have administrative rights to the page and all web parts you will edit.
2. Browse to the SharePoint Server site that contains the web part or parts you will edit.
3. On the SharePoint Ribbon, select the Page tab.
4. Select Edit.
NOTE
Notice that all web parts on the page now display borders and are individually selectable.
5. Move your mouse over the upper right corner of the web part you will edit.
NOTE
Notice that a small drop-down arrow and a check-box become visible when you hover over the corner. The check-
box allows you to select the web part. When the check-box is selected the web part tab shows in the Ribbon and
allows several options including viewing the Web Part Properties, Minimize, and the option to Delete the web
part.
6. The drop-down arrow allows similar choices with the addition of the Export option. Export allows you to
save the entire selected Web-Part in the .webpart file format for import and use on another page or
SharePoint Server site.
7. The editable properties for the selected web part are available by selecting Web Part Properties, from the
Web Part tab in the Ribbon, or Edit Web Part from the drop-down arrow.
8. That's it. You're editing a SharePoint Server web part.
9. When you've completed editing, to save your work and return to the normal page view, select the Page tab
in the Ribbon, and then click Save. This will save your work and exit the edit mode and return you to your
normal page view.
TIP
If you've made a mistake, or aren't happy with the revisions you've made to the page or its web parts, you can
choose to Stop Editing and then Discard changes. Select the Page tab in the Ribbon, and then select the drop-
down arrow below the Save icon. Select Stop Editing, the Save Changes dialog appears. Select Discard changes.
IMPORTANT
One last thing, the SharePoint Server online help available via the help icon question mark. This help is available for all
elements on the page, including web parts. When you have selected a web part, if you want additional help, click the help
icon question mark and a SharePoint Help window will open. The default topics will display for the item on the page you've
selected and you can search for additional topics. For web parts the search terms Configure Web Part will return many
related results.
See also
Concepts
Configure properties of the Search Box Web Part in SharePoint Server
Configure properties of the Search Results Web Part in SharePoint Server
Configure properties of the Refinement Web Part in SharePoint Server
Configure properties of the Search Navigation Web Part in SharePoint Server
Use the Hero web part
What is a SharePoint communication site?
Permissions planning for sites and content in
SharePoint Server

Some sites in an 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 sites and site content. You can manage permissions by using SharePoint groups,
which control membership. Fine-grained permissions also help to secure content at the item and document level.
The following articles about how to plan security for sites and content are available here, Get help with
permissions in SharePoint.
User permissions and permission levels in SharePoint
Server

Default permission levels are predefined sets of permissions that you can assign to individual users, groups of
users, or security groups, based on the functional requirements of the users and on security considerations.
SharePoint Server permission levels are defined at the site collection level and are inherited from the parent object
by default.
Default permission levels

Default permission levels are made up of a set of permissions that enable users to perform a collection of related
tasks. SharePoint Server includes seven permission levels. You can customize the permissions contained within
five of these permission levels. You cannot customize the permissions within the Limited Access and Full Control
permission levels.
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, see Manage permissions for a web application in SharePoint Server.
The following table lists the default permission levels for team sites in SharePoint Server.
PERMISSION LEVEL DESCRIPTION PERMISSIONS INCLUDED BY DEFAULT
View Only Enables users to view application pages. View Application Pages
The View Only permission level is used View Items
for the Excel Services Viewers group. View Versions
Create Alerts
Use Self Service Site Creation
View Pages
Browse User Information
Use Remote Interfaces
Use Client Integration Features
Open
Limited Access Enables users to access shared View Application Pages

resources and a specific asset. Limited Browse User Information
Access is designed to be combined with Use Remote Interfaces
fine-grained permissions to enable Use Client Integration Features
users to access a specific list, document Open
library, folder, list item, or document,
without enabling them to access the
whole site. Limited Access cannot be
edited or deleted.
Read Enables users to view pages and list Limited Access permissions, plus:
items, and to download documents. View Items
Open Items
View Versions
Create Alerts
Use Self-Service Site Creation
View Pages
Contribute Enables users to manage personal Read permissions, plus:

views, edit items and user information, Add Items
delete versions in existing lists and Edit Items
document libraries, and add, remove, Delete Items
and update personal Web Parts. Delete Versions
Browse Directories
Edit Personal User Information
Manage Personal Views
Add/Remove Personal Web Parts
Update Personal Web Parts
Edit Enables users to manage lists. Contribute permissions, plus:

Manage Lists
Design Enables users to view, add, update, Edit permissions, plus:

delete, approve, and customize items or Add and Customize Pages
pages in the website. Apply Themes and Borders
Apply Style Sheets
Override List Behaviors
Approve Items
Full Control Enables users to have full control of the All permissions
website.
If you use a site template other than the team site template, you will see a different list of default SharePoint
permission levels. For example, the following table shows additional permission levels provided with the
publishing template.
Restricted Read View pages and documents. For View Items

publishing sites only. Open Items
View Pages
Open
Approve Edit and approve pages, list items, and Contribute permissions, plus:
documents. For publishing sites only. Override List Behaviors
Approve Items
Manage Hierarchy Create sites; edit pages, list items, and Design permissions minus the Approve
documents, and change site Items, Apply Themes and Borders, and
permissions. For Publishing sites only. Apply Style Sheets permissions, plus:
Manage permissions
View Web Analytics Data
Create Subsites
Manage Alerts
Enumerate Permissions
Manage Web Site
User permissions
SharePoint Server includes 33 permissions, which are used in the default permission levels. You can configure
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 certain objects, such as personal views and
private Web Parts. The following tables describe what each permission is used for, the dependent permissions, and
the permission levels in which it is included.
List permissions
INCLUDED IN THESE
PERMISSION LEVELS BY
PERMISSION DESCRIPTION DEPENDENT PERMISSIONS DEFAULT
Manage Lists Create and delete lists, add View Items, View Pages, Edit, Design, Full Control,
or remove columns in a list, Open Manage Hierarchy
and add or remove public
views of a list.
Override List Behaviors Discard or check in a View Items, View Pages, Design, Full Control
document that is checked Open
out to another user, and
change or override settings
that allow users to read/edit
only their own items.
Add Items Add items to lists, and add View Items, View Pages, Contribute, Edit, Design, Full
documents to document Open Control
libraries.
Edit Items Edit items in lists, edit View Items, View Pages, Contribute, Edit, Design, Full
documents in document Open Control
libraries, and customize Web
Part pages in document
libraries.
Delete Items Delete items from a list, and View Items, View Pages, Contribute, Edit, Design, Full
documents from a Open Control
document library.
View Items View items in lists, and View Pages, Open Read, Contribute, Edit,
documents in document Design, Full Control
libraries.
Approve Items Approve a minor version of Edit Items, View Items, View Design, Full Control
list items or document. Pages, Open
Open Items View the source of View Items, View Pages, Read, Contribute, Edit,
documents with server-side Open Design, Full Control
file handlers.
View Versions View past versions of a list View Items, Open Items, Read, Contribute, Edit,
item or document. View Pages, Open Design, Full Control
INCLUDED IN THESE
Delete Versions Delete past versions of list View Items, View Versions, Contribute, Edit, Design, Full
items or documents. View Pages, Open Control
Create Alerts Create alerts. View Items, View Pages, Read, Contribute, Edit,
Open Design, Full Control
View Application Pages View forms, views, and Open All

application pages.
Enumerate lists.
Site permissions
INCLUDED IN THESE
Manage Permissions Create and change View Items, Open Items, Full Control
permission levels on the web View Versions, Browse
site and assign permissions Directories, View Pages,
to users and groups. Enumerate Permissions,
Browse User Information,
Open
View Web Analytics Data View reports on Web site View Pages, Open Full Control
usage.
Create Subsites Create subsites such as View Pages, Browse User Full Control
team sites, Meeting Information, Open
Workspace sites, and
Document Workspace sites.
Manage Web Site Grants the ability to perform View Items, Add and Full Control
all administration tasks for Customize Pages, Browse
the web site, as well as Directories, View Pages,
manage content. Enumerate Permissions,
Browse User Information,
Open
Add and Customize Pages Add, change, or delete View Items, Browse Design, Full Control
HTML pages or Web Part Directories, View Pages,
pages, and edit the website. Open
Apply Themes and Borders Apply a theme or borders to View Pages, Open Design, Full Control
the whole website.
Apply Style Sheets Apply a style sheet (.css file) View Pages, Open Design, Full Control
to the website.
Create Groups Create a group of users that View Pages, Browse User Full Control
can be used anywhere Information, Open
within the site collection.
INCLUDED IN THESE
Browse Directories Enumerate files and folders View Pages, Open Contribute, Edit, Design, Full
in a website by using Control
SharePoint Designer 2013
and Web DAV interfaces.
Use Self-Service Site Create a website using Self- View Pages, Browse User Read, Contribute, Edit,
Creation Service Site Creation. Information, Open Design, Full Control
View Pages View pages in a website. Open Read, Contribute, Edit,

Design, Full Control
Enumerate Permissions Enumerate permissions on Browse Directories, View Full Control

the website, list, folder, Pages, Browse User
document, or list item. Information, Open
Browse User Information View information about Open All

users of the website.
Manage Alerts Manage alerts for all users View Items, View Pages, Full Control
of the website. Open, Create Alerts
Use Remote Interfaces Use SOAP, Web DAV, the Open All
Client Object Model, or
interfaces to access the
website.
Use Client Integration Use features that launch Use Remote Interfaces, All
Features client applications. Without Open, View Items
this permission, users must
work on documents locally
and then upload their
changes.
Open Enables users to open a None All

website, list, or folder to
access items inside that
container.
Edit Personal User Enables users to change Browse User Information, Contribute, Edit, Design, Full
Information their own user information, Open Control
such as adding a picture.
Personal permissions
INCLUDED IN THESE
Manage Personal Views Create, change, and delete View Items, View Pages, Contribute, Edit, Design, Full
personal views of lists. Open Control
Add/Remove Personal Web Add or remove personal View Items, View Pages, Contribute, Edit, Design, Full
Parts Web Parts on a Web Part Open, Update Personal Web Control
page. Parts
INCLUDED IN THESE
Update Personal Web Parts Update Web Parts to display View Items, View Pages, Contribute, Edit, Design, Full
personalized information. Open Control
See also
Other Resources
Manage permissions for a web application in SharePoint Server
Overview of the Contribute permission level in
SharePoint Server
About updating web files

Web files enable you to implement various customization options for a web page. Web files can contain scripts (for
example, 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 name extensions.
A member of the Farm Administrators group can use Microsoft PowerShell cmdlets to configure web files that
have the following file name extensions:
.ascx
.aspx
.asmx
.master
.jar
.swf
.xap
.xsf
.xsn
The tasks that require the Add and Customize Pages permission in SharePoint Server include the following:
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
Users with the default Contribute permission level in SharePoint Server can perform 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

To add or edit Web Parts that developers have marked as unsafe for editing, SharePoint Server users must have the
Add and Customize Pages permission.
By default, the following Web Parts are marked as safe for editing 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
See also
Concepts
User permissions and permission levels in SharePoint 2013
Best practices for using fine-grained permissions in
SharePoint Server

Fine-grained permissions can influence security on a SharePoint farm. Potential performance issues can occur
when you use fine-grained permissions. The following information helps you address issues when an environment
is experiencing issues that incorrect use or scale of fine-grained permissions might have caused.
You can avoid fine-grained permissions by doing the following:
Break permission inheritance as infrequently as possible.
Use groups based on folder membership to assign permissions.
Due to a change in SharePoint Server search continuous crawl capabilities that now include security
information, we no longer recommend that you avoid using SharePoint groups to manage dynamic user
and group memberships. Prior to SharePoint Server, using dynamic memberships in SharePoint groups
could cause search results to not show up correctly for all members until a full crawl occurred after the
membership change. Now with the continuous crawl capability including security information a dynamic
membership or other security change will be picked up sooner (default value is 15 minutes) and be used by
search query result trimming.
Assign permissions at the highest possible level. As part of this strategy, consider the following techniques:
Put documents that require fine-grained permissions in document libraries that are defined to
support each group of permissions Keep the document libraries in a separate site collection or site.
Use different document publish levels to control access. Before a document is published, the
advanced permissions and versioning settings can be set for users who can only approve items in the
document library.
For non-document libraries (lists), use the ReadSecurity and WriteSecurity permission levels.
When a list is created, the owners can set the Item-level permissions to either Read access or Create
and Edit access.
Before you begin

Fine-grained permission reference for SharePoint Server
Troubleshoot common fine-grained permissions issues for SharePoint Server
Best practices to avoid common limit issues of fine-grained permissions

If your business requirement must use fine-grained permissions, consider the following recommended best
practices:
Ensure that you do not have too many items at the same level of hierarchy in the document libraries,
because the time that is required to process items in the views increases.
Use event handlers to control edit permission. You can have an event handler that registers an event using
the SPEventReceiverType.ItemUpdating and SPEventReceiverType.ItemUpdated methods, and then
use code to control whether the update should be allowed. This is very powerful, because you can make
security decisions based on any metadata of a list or item, without affecting the view -rendering
performance.
Use the AddToCurrentScopeOnly method to assign Limited Access membership in a SharePoint group.
The key element in this principle is to redesign the architecture so that scope membership does not cause
Access Control List (ACL ) recalculation at the parent document library and web. For additional information
about scope changes, Issue 3: Use fine-grained permissions by scope structure changes (2010 only).
When working with fine-grained permissions, it is easy to unintentionally encounter limits that prevent
permissions from resolving. This section describes some of these limits and best practices on how to set them to
allow permissions to resolve correctly.
Too many scopes in a list
There is a built-in limit of 50,000 scopes per list or document library. After 50,000 scopes are reached addition of
new scopes in a given list or document library is prohibited.
Best practices:
Only set unique scopes on parent objects such as folders.
Do not create a system with many uniquely-permissioned objects below an object that has many scopes.
If your business requires more than 50,000 uniquely permissioned items in a list or document library, then
you must move some items to a different list or document library.
Change the built-in scope limit
Change the built-in scope limit by using a Microsoft PowerShell script.
To change the built-in scope limit by using Windows PowerShell
2016 cmdlets.
NOTE

$webapp = Get-SPWebApplication http://<serverName>

$webapp.MaxUniquePermScopesPerList
$webapp.MaxUniquePermScopesPerList = <Number of scope limit>
Where:
Where <serverName> is the name of the application server in the SharePoint farm.
Where <Number of scope limit> is the maximum number of unique permissions scopes that you
want to allow per SharePoint list. Often, the effective limit is much smaller than 50,000 if many
scopes exist at the same hierarchical level. This is because display checks for items below that
hierarchical level must be checked against all scopes above them. This limitation can cause the
effective number of scopes allowed in a particular query to be reduced to 1,000 to 2,000.
NOTE
Too many members in a permission scope

As described earlier, a binary ACL is calculated when the membership of the associated permission scope changes.
This includes when a new limited access member is added. As the scope membership number increases, the time
that is required to recalculate the binary ACL increases.
The problem can be made worse as the addition of users at a child object's unique scope will cause its parent
scopes to be updated with the new Limited Access members, even if this ultimately results in no change to the
parent scope membership. When this occurs, the binary ACL for the parent scopes must also be recalculated, at the
expense of more processing time, even if it ultimately results in the same ACL.
Best practice:
Rely on group membership instead of individual user membership in permission scopes. For example, if a single
group can be used instead of 1,000 individual users, the scope will be 999 membership entries smaller for the
permission scope and any of its parent scopes. Also, the single group will be updated with Limited Access rights
instead of updating each user who has Limited Access rights. This also helps increase the speed of Limited Access
rights push and ACL recalculation on the parent scope objects.
IMPORTANT
Using a SharePoint group will cause a full crawl of the index. If possible, use a domain group.
Very deep scope hierarchy

As indicated earlier, the hierarchical depth of permission scopes can affect the work that is required to add Limited
Access users to parent scopes. The larger the number of unique scopes above an item, up to and including the
uniquely permissioned web, the larger the number of additions that must occur. If a scope hierarchy is very deep, a
scope membership change can take a very long time to occur, as each membership change in the deepest scope
item will have to iteratively update parent scopes with a membership addition for the explicitly added user or group
that has Limited Access rights. Additionally this will increase the number of binary ACLs that have to be
recalculated, with an according performance effect.
Best practice:
Reduce the numbers of uniquely permissioned parent objects. This reduces the number of scopes that have to be
updated with Limited Access members when any child object's scope changes.
Overview of security groups in SharePoint Server

You can manage users of SharePoint sites more efficiently if you assign permission levels to groups instead of to
individual users. A SharePoint group is a set of individual users and can also include Active Directory Domain
Services (AD DS ) groups.
Introduction
In AD DS, 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, AD DS manages the users for you.
NOTE
For ease of security management, we do not recommend the following items when you manage AD DS groups. > Assign
permission levels directly to AD DS 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, security groups in SharePoint sites do not provide full visibility of what is occurring. 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 that have 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 one another.
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 that is named "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. Therefore, 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 website (at the permission level that 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 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 Office SharePoint Designer.
View sites in My Network Places.
Upload or edit documents in document libraries, such as wiki libraries.
IMPORTANT
To improve security for sites, lists, or libraries, do not enable anonymous access. 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 in SharePoint Server.
See also
Other Resources
Permissions planning for sites and content in SharePoint Server
Manage permission policies for a web application in SharePoint Server
Determine permission levels and groups in SharePoint
Server

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.
The most important decision about your site and content security in SharePoint Server 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 yours 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 for team sites in SharePoint Server. 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 Edit Use this group to grant people Edit

permissions to the SharePoint site.
Owners Full Control Use this group to grant people Full

Control permissions to the SharePoint
site.
Viewers View Only Use this group to grant people View

Only permissions to the SharePoint site.
If you use a site template other than the team site template, you will see a different list of default SharePoint
groups. For example, the following table shows the additional groups provided by a publishing site template.
Restricted Readers Restricted Read to the site, plus Limited Members of this group can view pages
Access to specific lists and documents, but cannot view
historical versions or review user rights
information.
Style Resource Readers Read to the Master Page Gallery and Members of this group are given Read
Restricted Read to the Style Library. permission to the Master Page Gallery
and Restricted Read permission to the
Style Library. By default, all
authenticated users are a member of
this group.
> [!NOTE]> Do not remove all
authenticated users from this group.
Because Master Page Gallery and Style
Library are shared across all sites in the
site collection and must be accessible to
all users of all sites. If you remove all
authenticated users from the group,
anyone with this permission level on a
subsite will not be able to render the
site. SharePoint will not automatically
add or remove users of subsites to or
from this group as needed.
Designers Design, Limited Access Members of this group can to view, add,
update, delete, approve, and customize
the layout of site pages by using the
browser or SharePoint Designer 2013.
Approvers Approve, plus Limited Access Members of this group can edit and
approve pages, list items, and
documents.
Hierarchy Managers Manage Hierarchy, plus Limited Access Members of this group can create sites,
lists, list items, and documents.
TIP
The Limited Access permission level is used to give groups access to a specific list, library, folder, document, or item, without
giving them access to the entire site. Do not remove this permission level from the groups listed above. If this permission
level is removed, the groups might not be able to navigate through the site to get the specific items with which they need to
interact.
Make most users members of the Visitors or Members groups. By default, users in the Members group can
contribute to the site by adding or removing items or documents, but cannot change the structure, site settings, or
appearance of the site. The Visitors group has read-only access to the site, which means that they can see pages
and items, and open items and documents, but cannot add or remove pages, items, or documents.
If the default groups do not map to the exact user groups in your organization, you can create custom groups.
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 in SharePoint 2013.
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, the users might be unable to perform their tasks, or they
could perform tasks that you did not want them to perform.
By default, the following permission levels are available:
**View Only ** Includes permissions that enable users to view pages, list items, and documents.
**Limited Access ** Includes permissions that enable users to view specific lists, document libraries, list
items, folders, or documents, without giving access to all the elements of a site. You cannot edit this
permission level directly.
NOTE
If this permission level is removed, group members might be unable to navigate the site to access items, even if they
have the appropriate permissions for an item within the site.
**Read ** Includes permissions that enable users to view items on the site pages.
**Edit ** Includes permissions that enable users to add, edit and delete lists; can view, add, update and delete
list items and documents.
**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 view, add, update, delete, approve, and customize the
layout of site pages by using the browser or SharePoint Designer 2013.
**Full Control ** Includes all permissions.
For more information about permissions that are included in the default permission levels, see User permissions
and permission levels in SharePoint 2013.
The following additional permission levels are provided with the publishing template by default:
**Approve ** Includes permissions to edit and approve pages, list items, and documents.
**Manage Hierarchy ** Includes permissions to sites and edit pages, list items, and documents.
**Restricted Read ** Includes permissions to view pages and documents, but not historical versions or
permissions information.
Determine whether you need custom permission levels or groups

The default groups and permission levels provide a general framework for permissions, covering many
organization types and roles within those organizations. However, they might not map exactly to how the users are
organized or to the many different tasks that the 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 obvious in the default groups. For
example, if in addition to Approvers, Designers, and Hierarchy Managers, you have a set of people who are
tasked with publishing content to the site, you might want to create a Publishers group.
There are well-known names for unique roles within your organization that perform very different tasks in
the sites. For example, if you are creating a public site to sell your organization's products, you might want to
create a Customers group that replaces Visitors or Viewers.
You want to preserve a one-to-one relationship between Windows security groups and the SharePoint
groups. For example, if your organization has a security group that is named Web Site Managers, you might
want to use that name as a group name for easy identification when you manage 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 make sure that that the change does not adversely
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, members of the Contributors group can create and own subsites,
and can potentially invite malicious users to their subsites or post unapproved content. If you customize the Read
permission level to include the View Usage Data permission that is typically part of the Full Control permission
level, all members of the Visitors group can see usage data, which could 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 the users must have to do their jobs, and
you want to add that permission.
A default permission level includes a permission that the users do not have to have.
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, instead of change all of the permission levels To manage permissions for a web application, see Manage
permissions for a web application in SharePoint Server.
If you must make several changes to a permission level, create a custom permission level that includes all of the
permissions that you need.
You might want to create additional permission levels if either of the following conditions is true:
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.
NOTE
Some permissions depend on other permissions. If you clear a permission that another permission depends on, the other
permission is also cleared.
Choose administrators and owners for the
administration hierarchy in SharePoint Server

This article describes the administrator roles that correspond to the SharePoint Server server and site hierarchy.
Many people can be involved in managing SharePoint Server. Administration of SharePoint Server occurs at the
following levels:
Server or SharePoint farm
Shared services
Web application
Sites
Document library or list
Individual items
Levels of administration
Most levels of the server and site hierarchy have a corresponding administration group. The administration groups
that have administrative permissions at different levels are described in the following list:
Server or farm level
Farm Administrators group Members of the Farm Administrators group have Full Control
permissions to and responsibility for all servers in the server farm. Members can perform all
administrative tasks in Central Administration for the server or server farm. They can assign
administrators to manage service applications, which are instances of shared services. This group
does not have access to individual sites or their content.
Windows Administrators group Members of the Windows Administrators group on the local
server can perform all farm administrator actions. Administrators on the local server can perform
additional tasks, such as installing new products or applications, deploying Web Parts and new
features to the global assembly cache, creating new Web applications and new Internet Information
Services (IIS ) Web sites, and starting services. Like farm administrators, members of this group on
the local server have no access to site content, by default.
NOTE
Farm administrators and members of the local Administrators group can take ownership of specific site
collections if it is 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 in a farm. However, these
administrators cannot create service applications, access any other service applications in the farm, or
perform any farm-level operations, such as 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.
Site level
Site collection administrators These administrators have the Full Control permission level on all
Web sites in 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 message. 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.
Plan site permissions in SharePoint Server

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 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 in SharePoint Server.
Plan for site permissions

When you create permissions, you must balance the ease of administration and performance against the
requirement 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-privileged: Users should have only the permission levels or individual
permissions they must have 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 that you trust to change the structure,
settings, or appearance of the site should be in the Owners group.
3. Use permission levels instead of assign individual permissions.
NOTE
You can create additional SharePoint groups and permission levels if that you must have more control over the actions that
the 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. > SharePoint Foundation 2013
and SharePoint Server use Check Permissions to determine a user or group's permissions on all resources in 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 in a site have fine-grained permissions applied, and when some sites
have subsites with unique permissions and others with inherited permissions. As much as possible, arrange sites
and subsites, and lists and libraries so they can share most permissions. Separate sensitive data into their own lists,
libraries, or subsites.
For example, it's much easier to manage a site that has permission inheritance as described in the following table.
SECURABLE OBJECT DESCRIPTION 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 Inherited, with unique permissions at
or two sensitive documents the document level
SiteA/SubsiteB Group shared project information Inherited
SiteA/SubsiteB/ListB Non-sensitive data, but with one or two Inherited, with unique permissions at
sensitive items the item level
SiteA/SubsiteB/LibraryB Non-sensitive documents, but with a Inherited, with unique permissions at

special folder that contain sensitive the folder and document level
documents
Overview of site permissions in SharePoint Server

This article helps you understand the concepts behind access control at the site collection, site, subsite, and site
content (list or library, folder, item or document) levels.
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 in 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 the users by using SharePoint groups? Groups have no
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 how to use groups to help manage permissions, see Choose security groups
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
Server 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 (and 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 how to
customize permission levels, see Configure custom permissions in SharePoint Server.
The default permission levels are Limited Access, Read, Contribute, Design, and Full Control. For
information about default permission levels and the permissions included in each level, see User
permissions and permission levels (SharePoint Server 2010).
SharePoint group A SharePoint group is a group of users who are defined at site collection level for easy
administration 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 instead of 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 in a site inherit permissions from
the site. You can use list-level, folder-level, and item-level permissions to additional 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 shows the relationships among
permissions, users and groups, and securable objects.
Relationships among permissions, users and groups, and securable objects
About permission inheritance

Permissions on securable objects in 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.
Stopping inheriting permissions copies the groups, users, and permission levels from the parent object to the child
object, and then breaks the inheritance. When you remove a user's permissions, that change will affect the child
object. We propagate the delete regardless of the status of inheritance. 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 administration, 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.
Overview of managing digital assets in SharePoint
Server 2013

This article describes digital assets (also known as rich media) and defines key terms that are used in relation to
managing digital assets in SharePoint Server 2013. It also explains aspects of managing digital assets by using the
assets library in SharePoint Server 2013, describes the primary users of an asset library, and outlines common
scenarios for using the asset library in SharePoint Server 2013.
For more information about how to plan a solution for managing digital assets, see Plan digital asset libraries in
Increasing numbers of office workers create or reuse images and other rich media assets as part of their daily
tasks. Often, however, no centralized repository exists at the departmental or enterprise level that is optimized for
storing these assets. A centralized repository lets users easily discover and reuse rich media assets that others
have already created. The asset library in SharePoint Server 2013 can save an organization time and other
resources by providing a specialized repository for storing and managing digital assets. Users no longer have to
look for assets in multiple locations over the network, or re-create assets from scratch. By using a centralized
repository for managing digital assets, the organization also exerts tighter control over brand-sensitive content
and can make sure that only approved assets for products are made available to the appropriate users.
About managing digital assets

A digital asset is an image, audio, or video file, or other reusable rich content fragment that an organization uses in
applications across the enterprise. The asset library in SharePoint Server 2013 enables users to easily create,
discover, and reuse existing digital assets within the organization.
In SharePoint Server 2013 you use an asset library to store and share digital assets with users. The asset library is
a SharePoint Server 2013 library template that is customized to use content types designed specifically for storing
and cataloging rich media assets.
An effective solution for managing digital assets specifies the following:
The metadata to provide for each kind of asset.
The amount of storage space that is required for the assets, and the performance issues to consider for
serving the assets to users.
Where to store assets at each stage of the life cycle of an asset.
How to control access to an asset at each stage of its life cycle.
How to move assets within the organization as team members contribute to creation, review, approval,
publication, and disposition of assets.
Which policies to apply to assets so that asset-related actions are audited, assets are retained or disposed of
correctly, and assets that are important to the organization are protected.
How assets are treated as corporate records, which must be retained according to requirements and
corporate guidelines.
For information about how to plan a digital asset solution by using SharePoint Server 2013, see Plan digital asset
libraries in SharePoint Server 2013.
Users of an asset library

Users of an asset library in SharePoint Server 2013 generally fall into one of the following three categories:
Asset creators. This includes people who create individual assets, such as graphic artists, video producers,
or marketing copywriters, and who submit assets to the asset library. For example, a graphic artist might
create a product logo in multiple resolutions and sizes, and in both color and black and white, and then
upload all versions of the logo to the asset library for use by other members of a product marketing team.
Asset managers. This includes people who manage the assets in the library. They are in charge of the end-
to-end workflow from the time that an asset is first submitted, through publication, to the time when an
asset expires. They are also in charge of managing and organizing assets in the library. For example, an
asset manager might take multiple versions of a product logo and categorize them appropriately in the
library, add important metadata such as keywords, and set a date after which the asset cannot be used.
Asset consumers. This includes people who have to find and use assets from the library to create other
work products. For example, web designers can use a product logo from the asset library when they create
marketing pages for product websites.
Depending on the scenario, there can be crossover between these users. For example, users who have permission
to upload assets to the library may also have permission to categorize and manage the assets they submit to the
archive. Asset creators can also be asset consumers if they look for and use assets that are added to other work
products, which in turn are uploaded as separate assets. For example, a video producer might use a product logo
while making a marketing video for a product, and then upload the video to the library as a separate asset.
Managing digital assets in SharePoint Server 2013

SharePoint Server 2013 provides a library template named Asset Library that is customized to use new image,
audio, and video content types designed specifically for storing and cataloging rich media assets. These new
content types use new column types such as Preview, Picture Size, Date Picture Taken, and Length (seconds) that
contribute to the metadata for a particular asset. The asset library also has a preview mode that displays a
thumbnail and some of this metadata when you rest the pointer over an asset. Enterprise keywords can be
assigned to assets to make them more easily discovered by searching. Keywords can be assigned by an asset
creator when a new asset is uploaded, or keywords can be added later by an asset manager. Users can rate assets,
a capability that provides additional metadata for assets. The metadata can then be used when assets are
displayed in a Web Part. For example, if you have a library of training videos that users have viewed and rated, you
can use a Web Part to display the top-rated videos on a web page.
Asset creators and asset managers work directly in the asset library to upload, categorize, and manage assets.
Asset consumers can browse the library to find assets for inserting into projects in other applications. Asset
consumers can browse an asset library from Office applications and insert an asset into the open application, such
as Word or PowerPoint.
You can display digital assets to users in SharePoint Server 2013 in the following ways:
Allow users to browse the asset library.
Insert a Web Part into a web page on a team site.
Use the video field control on a publishing page on a publishing site.
Use the Content Query Web Part.
The specific methods that you use to display assets to users of the asset library will vary depending on who the
users are, how they have to use assets from the library, and which methods for displaying assets are most
appropriate for a scenario.
In addition to the features that are part of the asset library, you can take advantage of SharePoint Server 2013
features such as workflows, routing, rules, and policies. These features help manage the assets as they come into
the asset library, track the progress of assets, automate publication of assets on approval, and set the expiration for
assets.
Scenarios for using the asset library

Users with Edit permissions can add an asset library to any SharePoint Server 2013 site collection or site. The
following table describes possible scenarios in which you might use a digital asset library.
SCENARIO DESCRIPTION
Corporate brand library The asset library stores branded corporate assets such as
logos, artwork, and other digital assets, and workflows and
policies help manage the content. Creative teams can submit
digital assets to the asset library where they are reviewed and
published. Content stewards manage and edit the digital
assets to make sure that they are correctly tagged and
organized. Information workers and extranet partners who
want corporate logos or brand assets use the library to find
the content they require.
Divisional portal The asset library is a repository for images and rich media files
for a single portal site. In this scenario, any contributor or
designer can upload logos and images to the library for other
people to view and use. The content is typically managed by
contributors, and there is minimal workflow or policy
associated with adding and managing content. For example,
the divisional portal library might have multiple contributors
but only a few approvers. Authors and web designers of the
site use content in the library by viewing, downloading, and
inserting it into their work products, such as documents or
presentations.
Team site Similar to a divisional portal but smaller. The asset library is a
repository for images and rich media for a single team site. In
this scenario, any team member can upload assets to the
library for other team members to view and use. The content
is managed as necessary by contributors, and there is minimal
workflow or policy. Team members use content in the library
by viewing, downloading, and inserting it into their work
products, such as documents or presentations.
Corporate archive The asset library stores pictures, video, documents, and other
assets that have historical value to the organization. Users can
submit current and past items, which are collected, scanned,
organized, and tagged by curators who manage the library so
that other users can browse, search, and view archived
content.
Divisional media sharing site The asset library stores audio and video files. In this scenario,
anyone can contribute to the library, and there is minimal or
no management of items in the library. Ratings are enabled
for the library, and are combined with social tagging of assets
to drive the structure and presentation of assets within the
library.
Plan digital asset libraries in SharePoint Server 2013

The SharePoint Server 2013 asset library is a special kind of document library. It is a collection of media files —
such as image, audio, and video files — that is shared with other site users.
For information about how to manage digital assets, see Overview of managing digital assets in SharePoint
Server 2013.
Asset library overview

Asset libraries are collections of media files on SharePoint Server 2013 that you share with other site users. As
part of planning for managing digital assets, you must decide which kind of asset library best fits the needs of the
organization. Because the asset library is a SharePoint Server 2013 library with specialized content types for
digital assets, you use many of the same methods that you use to plan a document management solution.
You can use an asset library in the following two ways:
As a general document library for digital assets at the team level. The asset library stores images,
audio, and video files for use by a team. A site owner might give everyone on the team permissions to
upload, organize and manage assets, or you might restrict the task of organizing and managing assets to a
small subset of people on the team.
NOTE
SharePoint Server 2013 does not support live streaming of audio or video content.
As a centralized repository for digital assets for the organization. In this situation, you use content
approval and workflow for all assets that are added to the library. People who have different roles might be
responsible for separate stages of the approval process. For example, graphic designers and audio or video
producers could upload assets to the library. But a content manager might be responsible for triaging
incoming assets, assigning additional metadata to the assets, and approving them for publication.
For more information about scenarios in which you might use a digital asset library, see the Scenarios for using
the asset library section in Overview of managing digital assets in SharePoint Server 2013.
Plan for asset libraries

Planning the asset libraries for a digital asset solution consists of the following major steps:
1. Identify roles for managing digital assets
2. Analyze asset usage
3. Plan organization of asset libraries
4. Plan content types
5. Plan content governance for digital assets
6. Plan workflows
7. Plan policies
8. Other uses for an asset library
Identify roles for managing digital assets
The first step in planning a digital asset library is to determine the participants and stakeholders for the solution.
Find out who creates digital assets in the organization, what kinds of assets they create, who manages the assets,
and who maintains the servers on which the assets are stored. For more information and for a worksheet to
record the data that you collect, see Identify users and analyze document usage in SharePoint Server.
Analyze asset usage
After you identify who works on assets, determine the kinds of assets they work on, and how they use the assets.
This helps you determine how to structure the asset libraries, how many libraries are required, which content
types to use for the assets, and which information management policies to apply to the asset libraries. Because the
size of most digital assets is much larger than standard documents, you must also plan for storage capacity. For
more information and for a worksheet to record the data that you collect, see Identify users and analyze document
usage in SharePoint Server.
Plan organization of asset libraries
As you plan the asset libraries, you decide where you should create them, how they must be used, how many are
needed, and how to organize them. You use the same methods to plan asset libraries as you do to plan document
libraries. This section describes the following steps for planning asset libraries:
Determine how many asset libraries are needed
Decide where you want to create each asset library
Choose a fixed or collaborative library
Decide how to organize the asset library
Determine how many asset libraries are needed. This determination, as in the earlier analysis and planning
steps, also depends on how the asset library will be used. For example, if you have individual teams that must use
asset libraries for collaboration, and who must use content governance such as versioning while they work on
assets, you can create an asset library for each team site. You can then let the teams manage their own assets. If
you want the asset library to serve as a large-scale centralized repository that is used by many teams, you might
create a single asset library. Then, you can adjust the permissions to manage how people use, manage, and search
the library. For more information, see Plan document libraries in SharePoint 2013.
NOTE
If you enable the disk-based cache for a web application, every site collection within that web application will use the cache.
If you do not have to have the disk-based cache for most the sites, consider putting in a separate web application only
those site collections that contain an asset library that requires the disk-based cache.
Decide where you want to create each asset library. Where you create the asset library depends on how you
plan to use it. For an asset library that will be used at the team level, you might create the asset library at the site
level. For a centralized repository, you might create the asset library at the site collection level. If the asset library
will be used with a web publishing site, put the library in the same site collection as the publishing site so that
asset files that are used by publishing pages are available to the publishing site. Use your asset analysis to
determine who creates and uses assets, and how those assets are used. This will help you decide where asset
libraries are needed in the enterprise.
Choose a fixed or collaborative library. Depending on the scenario, the asset library will be either a fixed
library or a collaborative environment. In a fixed library, completed assets are checked in and the library is read-
only. In a collaborative environment, versioning is enabled for the library, and users who have appropriate
permissions can both read and write to existing assets.
Decide how to organize the asset library. You can plan to store all assets in the root of the asset library, and
use custom views to display assets to library users based on certain criteria. You can also use folders to hold assets
based on criteria that you specify. For example, you might put video files in one folder and audio files in another.
Or, you might create folders based on products and put all assets related to a particular product into the product
folder. Refer to your asset analysis to determine the most common scenarios for how assets are used in your
organization.
Plan content types
The content types included in an asset library are image, audio, and video. You can either use these content types
or create custom content types that are derived from them, depending on the classification needs of your
organization. For example, you might create two separate content types for posters and product logos, and derive
the base characteristics for those new content types from the image content type. This arrangement lets you
associate separate properties for the two new content types, specify different workflows, or set different
information management policies based on the content types. For more information, see Plan content types and
workflows in SharePoint 2013.
Plan content governance for digital assets
You plan the appropriate degree of control for each content type and storage location for digital assets. For
example, if the asset library is a collaborative solution, you can use versioning to store successive iterations of
assets in the library, and can require users to check assets in and out before working on assets. You can also
specify an approval process by which assets must be approved before they can be made available to an audience.
For more information, see Plan document versioning, content approval, and check-out controls in SharePoint
2013.
Plan workflows
You use workflows to perform management tasks on assets in the asset library in the same manner as you use
workflows in a document library. Important considerations include the following:
Do assets have to be reviewed and approved before they can be used by asset consumers?
Who is responsible for managing the expiration of assets?
Are assets retained or deleted after expiration?
For more information, see Plan content types and workflows in SharePoint 2013.
Plan policies
For each content type that you want to use in the asset library, you must plan the information management
policies that specify how assets are audited, retained, and labeled. For more information, see Plan for information
management policy in SharePoint Server.
IMPORTANT
SharePoint Server 2013 does not automatically apply Information Rights Management (IRM) protection to audio or video
content that is stored in a SharePoint Server 2013 asset library. Additionally, when audio or video assets stored in
SharePoint Server 2013 are viewed by a user, copies of those assets might be stored in the user's local browser cache. The
SharePoint Server 2013 media player supports playing IRM-protected audio and video formats where the Digital Rights
Management protection was applied by an external IRM provider that is supported by Silverlight 3 or later versions. For
more information, see Digital Rights Management (DRM) (https://go.microsoft.com/fwlink/p/?LinkId=154933).
Other uses for an asset library

The following table lists additional uses for an asset library in SharePoint Server 2013.
FEATURE DESCRIPTION
Podcasts Users can enter the URL for the library RSS feed into their
podcast application to receive updates when new audio and
video files are added to the asset library. For more
information about how to upload audio and video files, see
Set up an Asset Library to store image, audio, or video files.
Suggested Content Browser Locations When you are using a publishing site, the URL for an asset
library in a separate site can be added to the Suggested
Content Browser Locations list for the publishing site. This lets
content creators access the asset library when they insert
assets into web pages within SharePoint Server 2013, or
within Office applications, such as Word.
Content Organizer When you are using an asset library as a centralized

repository, consider using the Content Organizer site feature
to automate the routing of assets that are uploaded to the
library by users. When the Content Organizer site feature is
activated, a new library named Drop Off Library is
automatically created. This lets you create rules that specify
how assets added to this library are routed to other libraries,
such as the asset library. For example, you can specify that all
audio assets are stored in one folder of the asset library,
whereas all video assets are stored in another folder.
An advantage to using the Content Organizer is that certain
metadata fields can be required to receive user input when
new assets are added. This helps control how different types
of assets are routed. In addition, this can automate some of
the content management work and reduce the workload of
administering the asset library and managing the assets it
contains. For more information, see Configure the Content
Organizer to route documents
Published links Members of the Administrators group on the local computer

can add links to SharePoint sites and lists from client
applications in Office such as Word, Excel, and PowerPoint.
These links appear on the My SharePoint Sites tab of the
Open, Save, and Save As dialog boxes when you open and
save documents from these applications. Users can manually
add links to their published link lists by browsing to a library
and clicking Connect to Office. For more information, see
Add or delete links to Office client applications (SharePoint
Server 2010).
Plan for permissions and security

Planning for permissions and security in an asset library is the same as planning for permissions and security in a
document library. For information about the available default groups, permission levels, and when to use custom
groups or levels, see Determine permission levels and groups in SharePoint 2013.
Plan for storage and performance

Because an asset library is a specialized kind of document library, determining storage requirements for digital
assets resembles determining storage requirements for documents. The primary difference is that asset libraries
typically contain fewer assets than document libraries contain. But the assets in an asset library are larger than
those in a document library. When you plan for storage, analyze the content to determine how many assets will be
stored in the asset library, and the average size of those assets. For example, if you have 50,000 assets and the
average file size is 10 megabytes (MB ), you must have at least 500 gigabytes (GB ) of storage on the database
server. If you will be using the asset library to store video files, you must determine the average size of those files.
By default, the maximum video file upload size is 250 MB. If you know that you have to support larger video files,
you can increase the file upload size up to 2 GB for every web application by using Central Administration. If you
will be using the disk-based binary large object (BLOB ) cache, you must also make sure that the front-end web
server has sufficient disk space in which to store the cached files.
Depending on the type of digital asset files that will be stored in the asset library, you should enable the disk-
based BLOB cache and Bit Rate Throttling to provide better performance for users. It is usually a good idea to
enable the disk-based BLOB cache. When the BLOB cache is enabled, it stores specified file types on the front-end
web server to reduce the load put on the database server when those files are requested and served to users.
The video renditions feature lets users upload multiple renditions of a video. The video renditions can have
different codecs and formats, or different bit rates. A user can choose the rendition to play. By default, the video
with the lowest bit rate is chosen.
If you will be using the asset library to serve audio and video files to users, we recommend that you always enable
the BLOB cache, and that you enable Bit Rate Throttling on the server. Bit Rate Throttling controls the rate at
which audio and video files are downloaded to the client so that overall performance on the site is not affected.
For more information about the disk-based cache, see Plan for caching and performance (SharePoint Server
2010). For information about how to enable and configure Bit Rate Throttling, see Bit Rate Throttling Readme
(https://go.microsoft.com/fwlink/p/?LinkId=154962).
Plan for metadata and Search

The addition of metadata that helps describe the type and content of a digital asset greatly improves the
discoverability of content in an asset library. When you plan an asset library, remember that rich media files are
not automatically searchable because they do not contain text that a search engine can index. The metadata that is
used to describe digital assets can include information such as the title, description, author, copyright, and
enterprise keywords that provide additional details about the asset. Some metadata, such as the size and
dimensions of an image, is entered automatically when the asset is uploaded to the asset library. Other metadata
is added manually. For example, an asset creator might add a text description of an image when the asset is
uploaded. Or, a library manager might add keywords and update approval status during triage of incoming assets
or performance of administrative task.
SharePoint Server 2013 includes many improvements for video search. Users can use the Search Navigation Web
Part to filter the search results to display only video results. The video search results page shows a thumbnail for
each video. Users can click the thumbnail to go to the video player page or pause on the thumbnail to view
additional information such as who uploaded the video, when it was uploaded, number of views, and so on. The
video search results page also provides video-specific search refiners. Users can refine the search results by length
of video, people in the video, and upload date.
Plan for video thumbnails

Thumbnail preview images are created automatically when a video is uploaded to an asset library. Content
authors can also choose a frame from the video or upload a picture and use that as the thumbnail preview image.
For automatic thumbnail creation to work, you must install the Desktop Experience feature on the front-end web
server that hosts SharePoint Server 2013. For more information, see Desktop Experience Overview.
Plan for Web Parts and web pages

SharePoint Server 2013 has many Web Parts and field controls that take advantage of the content types in an
asset library. Web Parts are added to web zones in Web Part pages by content owners. Field controls are added to
publishing pages by site developers and designers. Examples of Web Parts and field controls that are used to
display digital assets include the following:
Media Web Part and field control. Used to display embedded video in a web page.
Image Web Part and field control. Used to display images on a web page.
Content Query Web Part. Used to display items from all sites in a site collection, a selected site or subsite,
or a specific list or library. The query can be configured to return a list of items based on list and content
types, and can be filtered and targeted to a specific audience.
Content Search Web Part. Used to display content that was crawled and added to the search index. You
can configure the Web Part and choose the video content type from the query builder.
When you design web pages for sites, consider which fields to expose to users in web pages and Web Parts to
help users find the assets they need. You can customize the information that is displayed when a user rests the
pointer on an asset in the asset library by editing the Thumbnail view in the Library Settings page. For more
information about Web Parts and field controls, see Understanding Field Controls and Web Parts in SharePoint
Server 2007 Publishing Sites.
Plan for client support

SharePoint Server 2013 supports HTML5 and Silverlight media players. The HTML5 media player is the default
media player that is used to play all video files that are compatible with the HTML5 <video> element
implementation for the current browser. SharePoint Server 2013 selects the player automatically, depending on
the video format. If the video format cannot be played on the HTML 5 media player, the system uses the
Silverlight media player.
To use the Silverlight media player, Silverlight 3, or later versions, must be installed on the client computers. For
more information about Silverlight 3, see Silverlight Overview (https://go.microsoft.com/fwlink/p/?
LinkId=154002).
For more information about the media formats that are supported by Silverlight media players, see Supported
Media Formats, Protocols, and Log Fields.
See also
Concepts
Overview of managing digital assets in SharePoint Server 2013
Overview of OneDrive for Business in SharePoint
Server
NOTE
While OneDrive for Business is used in both SharePoint Server on-premises and Office 365 environments, this article
describes how it works in SharePoint Server. For more information about how it works in an Office 365 environment, see
What is OneDrive for Business?.
OneDrive for Business is the default document library in a user's What's new in social computing in SharePoint
Server 2013 in SharePoint Server or in Office 365. The contents of this library can optionally be synchronized
with one or more of the user's computers or devices.
By using OneDrive for Business, you can help ensure that business files for your users are stored in a central
location. Storing business files in one location makes it easy for users to share and collaborate on documents. If
you're using OneDrive for Business in Office 365, you can also reduce your on-premises storage costs by moving
your users' files to the cloud.
OneDrive for Business is different from the consumer OneDrive service in that OneDrive for Business is based on
SharePoint and is meant for storing a user's business documents and files. Consumer OneDrive is a separate
service that is meant for personal use.
Why use OneDrive for Business in a SharePoint Server on-premises

environment?
While OneDrive for Business in Office 365 may serve as an optimal storage solution for many businesses, some
businesses may be restricted from saving their company data to the cloud for various reason, including:
Business rules that prohibit transmitting data over the internet
Industry rules
Compliance standards
Additionally, your environment may require your IT-staff to have strict control on updates that are applied in your
environment. One of the reasons may be that you have specialized third-party applications or customization that
have only been tested to work with specific versions of a product or service.
For these types of customers, OneDrive for Business can be implemented in a SharePoint Server on-premises
environment, providing your business users with the sync and storage features provided by OneDrive for
Business, but keeping all of your data within your on-premises environment.
Additionally, updates to SharePoint Server and the services run on it (such as OneDrive for Business) are
controlled internally by you.
How does it work?

In SharePoint Server, OneDrive for Business is simply the document library in a user's MySite. This provides
personal storage for your users, either directly through the document library in their My Site, or as a save location
in Office 2013 or Office 2016. While OneDrive for Business in Office 365 files are saved to the cloud, in OneDrive
for Business in a SharePoint Server on-premises environment, user files are stored in the SharePoint Content
database in the SQL Server that you are using for SharePoint Server. User storage quotas are set through site
settings for the web application that is hosting the My Site host site.
Synchronizing files
To synchronize OneDrive for Business files, you need to use a sync client. Sync clients automatically synchronize
files between OneDrive for Business and a user's computer or a mobile device. They are available for a variety of
operating systems and mobile devices. The OneDrive for Business Windows sync client is also included as part of
an Office installation.
When you're using OneDrive for Business in SharePoint Server, you can synchronize your files to a variety of
devices, but those devices need to be connected to the network where SharePoint Server resides in order for the
sync to work. Synchronizing is mostly useful for laptops that are used while disconnected from your corporate
network at times, such as when traveling. This differs from usingOneDrive for Business in Office 365, in which an
Internet connection is required since files are synchronized from your users device to Office 365 instead of to an
on-premises location in your network.
OneDrive for Business hybrid

If you use SharePoint Server and want to take advantage of cloud storage for your users' business documents,
you can set up OneDrive for Business in Office 365 and have your users automatically redirected to Office 365
when they click the OneDrive for Business link in SharePoint Server.
By using Office 365 for document storage, you can take advantage of cloud storage without having to migrate all
of your workloads to Office 365.
Setting up OneDrive for Business hybrid requires configuring Office 365 if you haven't already, and configuring
your OneDrive for Business in your SharePoint Server environment to "redirect" to OneDrive for Business in
Office 365. For information about planning OneDrive for Business hybrid, see Configure hybrid OneDrive for
Business - roadmap.
Getting started
Setting up OneDrive for Business in SharePoint Server requires configuring a User Profile Service application and
setting up My Sites. For detailed planning information, see Plan for OneDrive for Business in SharePoint Server.
For more information about syncing OneDrive for Business files in SharePoint Server 2016 or 2013, see Sync
SharePoint files with the OneDrive for Business sync client (Groove.exe).
Plan for OneDrive for Business in SharePoint Server
OneDrive for Business - Office 365 or SharePoint Server

One of the first planning considerations you should make is if you truly want to use OneDrive for Business in
SharePoint Server, or if you would be better suited to use OneDrive for Business in Office 365. Many companies
select to use OneDrive for Business in an on-premises environment due to industry restrictions (for example,
finance or government), or business rules that prohibit transmitting their data over the internet. If your company
isn't restricted by either, you should also explore the possibility of using OneDrive for Business in Office 365. The
key benefits in using OneDrive for Business in Office 365 is that you only need an internet connection to use it,
versus being connected to your network, and that user storage is provided by your Office 365 service.
NOTE
For more information about OneDrive for Business in Office 365, see What is OneDrive for Business?
Setting up OneDrive for Business

To make OneDrive for Business in SharePoint Server available to your users, you need to configure the following
services in SharePoint Server Central Administration:
REQUIRED SERVICE WHAT DOES IT DO?
Managed Metadata service Manages metadata across all sites in your organization.
User Profile Service Application Stores information about users, and is required for My Sites.
My Sites Provides a personal site for individual users in an organization,

and is where the user's document library resides.
NOTE
For detailed information about how to set up each service as required for OneDrive for Business, see Set up OneDrive for
Business in a SharePoint Server on-premises environment.
Using the OneDrive for Business sync client

The OneDrive for Business sync clients give users the convenience of local storage of their files. Sync clients also
enable users to take documents offline. Users then can use those documents when they're disconnected from
SharePoint Server. Later, when the client computer or device reconnects to SharePoint Server, the files are
synchronized.
In a SharePoint Server on-premises environment, you may have the option to save directly to your document
library (for example, from Office 2016), which is where files are synchronized from your OneDrive for Business
local folder anyway. When the OneDrive for Business sync client is used in an on-premises environment, it's
primary benefit is for synchronizing files on laptops that are used while disconnected from your corporate network
at times, such as when traveling.
The sync client also provides your users the added convenience of working with files directly from the local
OneDrive for Business sync folder. Work with and saving your files directly in the folder is more convenient than
opening your My Sites document library.
IMPORTANT
Use the OneDrive for Business sync client for Groove.exe when using OneDrive for Business in a SharePoint Server on-
premises environment. The OneDrive for Business Next Generation sync client (OneDrive.exe) is currently not supported to
work in a SharePoint Server on-premises environment.
Changes in file location

If a user wants to change the location on their computer or device to which data is synchronized, they must stop
synchronizing the folder and then set up a new synchronization. Setting up a new synchronization allows them to
choose a new location.
Similarly, if you change the URLs of your SharePoint Server My Site host, users must stop the synchronization to
the old location and set up a new synchronization to the new URL.
Stopping a synchronization and starting a new one to the same OneDrive for Business library won't cause the loss
of any data in the OneDrive for Business library. But users must re-synchronize all files to their local computer or
device. This process may take some time and shouldn't be interrupted.
Network bandwidth considerations
There are several situations in which OneDrive for Business sync clients can cause unusually high network
bandwidth usage:
When you first roll out OneDrive for Business and users are synchronizing all of their files for the first time.
When you change the URL of the My Site host and users are required to re-synchronize their files.
Be mindful of the potential impact of these changes on your network.
Data security
Sync clients use the http:// or https:// protocol of the site that they're synchronizing with to transfer data. If the
OneDrive for Business site uses a Secure Socket Layer (SSL ) connection (https://), then the data being transferred
by the sync client is encrypted; otherwise, it's not.
Office 365 uses SSL for OneDrive for Business connections by default. If you're using SharePoint Server, we
recommend configuring your My Site host to use SSL for any connections that will occur outside your corporate
domain. If you're using Active Directory directory services, you can configure the Group Policy setting Sync Only
On Domain Network. The setting requires an SSL connection for OneDrive for Business clients that connect to
SharePoint Server from outside the organization's intranet.
Data on local disks on both server and Windows client computers can be encrypted by using Windows BitLocker
Drive Encryption.
Data on local devices
Once a document library is synchronized with a computer or mobile device, the files continue to exist there. Files
remain on the computer or device even if the user's My Site and their user account are deleted. In this situation,
although the files remain on the computer or device, the user can't synchronize the files with SharePoint Server
again.
If storing files on a client workstation is against your corporate policy, you can remove synchronization
functionality from document libraries in SharePoint Server.
Moving to a hybrid environment

At a later time, you might explore the possibility of using OneDrive for Business in Office 365 for various reasons,
such as keeping your on-premises sites and customizations in their current state, but offloading the personal
storage aspect of it to the cloud. This would also provide your users access to their business files while not
connected to the corporate network.
NOTE
For more information about configuring a hybrid environment for OneDrive for Business in SharePoint Server, see Configure
hybrid OneDrive for Business - roadmap.
Upgrading from OneDrive for Business in SharePoint Server

If you are using OneDrive for Business in SharePoint Server, you can upgrade to OneDrive for Business in
SharePoint Server as part of the upgrade process. You can do this as part of the process to upgrade your My Sites
Host site collection, which allows you the option to also upgrade the My Sites personal site collections, which are
used to store your OneDrive for Business user files.
NOTE
For more information, see Upgrade the My Site Host site collection.
Set up OneDrive for Business in a SharePoint Server
on-premises environment
NOTE
This article describes how to set up OneDrive for Business in a SharePoint Server on-premises environment, and does not
describe OneDrive for Business in an Office 365 environment. For more information about administering OneDrive for
Business in Office 365, see OneDrive for Business admin help.
When setting up OneDrive for Business in your SharePoint Server on-premises environment, an IT-administrator
will need to go through the following steps:
Set up the required services
Enable the Recently Shared Items (RSI) cache to quickly populate the Shared with Me view
Verify that OneDrive for Business is available to your users
Before proceeding with setup, please review planning considerations you might need to address that are described
in Plan for OneDrive for Business in SharePoint Server.
Set up the required services

Setting up OneDrive for Business in a SharePoint Server on-premises environment requires the following services
to be running on your farm:
My Sites
Let's look at how to set up each.
NOTE
The following provides basic steps to configure the Managed Metadata and Users Profile service applications to provide
OneDrive for Business functionality in SharePoint Server. Careful planning is required for both services if you intend to use
them for additional functionality in SharePoint Server. For more information, about managed metadata, see Plan for
managed metadata in SharePoint Server.

First, let's create a Managed Metadata service application.
To create a Managed Metadata service application
1. In Central Administration, under Application Management, click Manage service applications.
2. Click New, and then click Managed Metadata Service.
3. Type a name for the service application in the Name box.
4. In the Database Name box, type a name for the database.
5. Under Application Pool, choose SharePoint Web Services Default from the Use existing application
pool list.
6. Click OK.
My Sites
The first thing we need to do is to create a web application for the My Sites site. We recommend that My Sites be
in a separate web application, although the web application can be in an application pool that is shared with other
collaboration sites, or it can be in a separate application pool but in a shared IIS website.
To create a web application
1. In Central Administration, in the Application Management section, click Manage web applications.
2. On the ribbon, click New.
3. On the Create New Web Application page, in the Authentication section, select the authentication
mode that will be used for this web application.
4. 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 website on which to install your new web application.
Click Create a new IIS web site, and then type the name of the website in the Name box.
You can also provide the port number, host header, or path for the new IIS website.
5. In the Security Configuration section, select an authentication provider, whether to allow anonymous
access, and whether to use Secure Sockets Layer (SSL ).
If you want to use an existing application pool, click Use existing application pool, and then select the
application pool from the drop-down menu.
If you want to create a new application pool, click Create a new application pool, type the name of the
application pool, and either select the account that the application pool will run under or create a new
managed account for the application pool to run under.
7. In the Database Name and Authentication section, select the database server, database name, and
authentication method for your new web application.
the name of a specific failover database server that you want to associate with a content database.
available to the web application.
12. When the Application Created page appears, click OK.
Next, we need to create the site collection that will host users' My Sites.
To create a My Site Host site collection
1. On Central Administration, in the Application Management section, click Create site collections.
2. On the Create Site Collection page, in the Web Application section, select the web application that you
just created for My Sites.
4. In the Web Site Address section, select the path of the URL for the My Site host. In most cases, you can
use the root directory (/).
5. In the Template Selection section, click the Enterprise tab, and then select My Site Host.
6. In the Primary Site Collection Administrator section, type the user name (in the form <DOMAIN>\
<user name>) for the user who will be the site collection administrator.
template in the Select a quota template list.
9. Click OK.
The Top-Level Site Successfully Created page will appear when the My Site Host site collection is created.
Although you can click the link to browse to the root of the site collection, doing this results in an error because the
user profile cannot be loaded. This behavior is to be expected; user profiles are not imported at this point.
Next, let's create a User Profile service application.
To create a User Profile service application
2. Click New, and then click User Profile Service Application.
4. Under Application Pool, choose SharePoint Web Services Default from the Use existing application
pool list.
5. In the My Site Host URL box, type the URL of the My Site Host that you created.
6. Optionally change other settings to meet the needs of your organization. The default settings work fine for
hybrid environments.
7. Click OK.
Enable the Recently Shared Items (RSI) cache to quickly populate the
Shared with Me view
This step allows your users to immediately view files that are shared explicitly with them in their OneDrive for
Business Shared with Me View.
The Shared with Me view in OneDrive for Business lets users to see which documents and folders that users have
shared directly with them. By default, the Shared with Me view is populated once a shared item is crawled and re-
indexed through search. This means that your crawling/indexing schedule may cause some latency between the
when the item was shared and when the it appears in the user's Shared with Me View.
Your users will still be able to open the shared items or folder if they are sent a link (for example, through an email
notification), they just won't be able to see the items listed in the Shared with me View until the items have been
crawled and indexed. For more information about how files are shared in OneDrive for Business, see Share
OneDrive files and folders.
To eliminate this latency in your SharePoint Server environment, your IT administrator can enable the Recently
Shared Items (RSI) cache. The RSI cache is provisioned on the My Site host and it is used to populate the Shared
with Me view until the file permission changes resulting from the sharing action are crawled. The RSI cache is
disabled by default in SharePoint Server.
RSI doesn't support a multi-farm scenario where the My Site Host is not on the content farm. This site collection
typically has a URL such as http://<hostname>/my. If the My Site Host is not on the content farm, sharing will be
broken.
IMPORTANT
The RSI list contains information identifying the sharing action, including the name of the shared file and who it was shared
with. If you choose to enable RSI, this information will be viewable by the My Site Host admin and those to whom My Site
Host access has been delegated.
To enable the RSI list in the My Site Host, run the following PowerShell command:
$msh = Get-SPSite | where {$_.RootWeb.WebTemplateId -eq 54}

Enable-SPFeature "RecentlySharedItems" -Url $msh.Url
If you need to disable the RSI list in the My Site Host, run the following PowerShell command:
$msh = Get-SPSite | where {$_.RootWeb.WebTemplateId -eq 54}

Disable-SPFeature "RecentlySharedItems" -Url $msh.Url
Verify that OneDrive for Business is available to your users

Use the following procedure to check if OneDrive for Business is available to your users.
1. Have a user open a SharePoint Server site (for example, their own My Site: http://<hostname>/my).
2. In the top left corner of the page, click on the app launcher, which will display the OneDrive tile.
3. Click on the OneDrive tile, which should display your OneDrive for Business documents page.
See Also
Create a User Profile service applications in SharePoint Server
Configure the OneDrive for Business modern user
experience

As part of the November 2016 public update for SharePoint Server 2016 (Feature Pack 1), a new modern user
experience for OneDrive for Business is included. This modern user experience is turned on automatically when
you install the public update. However, you can use Microsoft PowerShell to toggle the user experience off and on
if you need to.
The OneDrive for Business modern user experience requires an active Software Assurance contract at the time it is
enabled, either by installation of the PU or by manual enablement. If you don't have an active Software Assurance
contract at the time of enablement, then you must turn the OneDrive for Business modern user experience off.
Turn the OneDrive for Business modern user experience off
Make sure you have permissions to administer SharePoint Server with Windows PowerShell, and log in to a
server in your SharePoint farm. Open the SharePoint 2016 Management Shell as administrator and run the
following script:
$Farm = Get-SPFarm
$Farm.OneDriveUserExperienceVersion =
[Microsoft.SharePoint.Administration.OneDriveUserExperienceVersion]::Version1
$Farm.Update()
Turn the OneDrive for Business modern user experience on

Make sure you have permissions to administer SharePoint Server with Windows PowerShell, and log in to a
server in your SharePoint farm. Open the SharePoint 2016 Management Shell as administrator and run the
following script:
$Farm = Get-SPFarm
$Farm.OneDriveUserExperienceVersion =
[Microsoft.SharePoint.Administration.OneDriveUserExperienceVersion]::Version2
$Farm.Update()
Search

Learn about planning, configuring and deploying search in SharePoint Server.
CONTENT DESCRIPTION
Plan search Create a well-designed plan to install and configure search in

SharePoint Server.
Configure enterprise search Learn how to configure enterprise search in SharePoint Server.
Administer search Learn how to manage the search schema and the search
topology in SharePoint Server.
Search center scenarios Learn how to develop Search Center scenarios in SharePoint
Server.
Plan search in SharePoint Server

The following articles provide information about the planning you need to do to deploy search in SharePoint
Server.
Articles about planning search

The following articles about planning search in SharePoint Server are available to view online. Writers update
articles on a continuing basis as new information becomes available and as users provide feedback.
CONTENT DESCRIPTION
Overview of search architecture in Learn about the different search

SharePoint Server components and databases and their
role within the search topology.
Plan enterprise search architecture in Learn how to plan a small, medium or

SharePoint Server 2016 large enterprise search architecture.
Scale enterprise search in SharePoint Learn which approach to use to scale

Server your enterprise search architecture for
performance and availability.
Scale search for Internet sites in Determine hardware requirements and

SharePoint Server review considerations to scale out
search topologies for Internet sites for
performance and availability.
Best practices for organizing content for Learn how to organize SharePoint
search in SharePoint Server Server content and metadata to make
the content easier to find.
Understanding result sources for search Use a result source in SharePoint Server
in SharePoint Server to specify a provider to get search
results from, and optionally to narrow a
search to a subset of those results.
Plan crawling and federation in Plan to crawl or federate results from

SharePoint Server different kinds of content and plan to
apply the appropriate settings.
Overview of the search schema in Learn how the search schema is used to
SharePoint Server build up the search index. The search
schema contains the mapping from
crawled properties to managed
properties and the settings on the
managed properties.
CONTENT DESCRIPTION
Plan to transform queries and order Learn how to transform user queries to
results in SharePoint Server provide more relevant SharePoint
Server search results and to improve
the way search results are displayed.
Overview of search result ranking in Learn how SharePoint Server uses

SharePoint Server ranking models to calculate the
relevance rank of search results and
how you can influence the order of
search results by using query rules, the
search schema and ranking models.
Overview of analytics processing in Learn how the Analytics Processing

SharePoint Server Component analyzes content and user
actions to improve search relevance.
Overview of search architecture in SharePoint Server

The search architecture contains search components and databases. How you structure the search architecture
depends on where you intend to use search: for the enterprise or for Internet sites. When building the search
architecture, you should take into account considerations such as high availability and fault tolerance, the volume
of your content and the estimated amount of page views and queries per second.
For information about search topologies for different use cases: see the technical diagrams Enterprise search
architectures for SharePoint Server 2016 and Internet sites search architectures for SharePoint Server 2016.
Overview of search components and search databases

The following tables show an overview of all the available search components and search databases. For more
information about how search components and databases interact, see the Search architectures for SharePoint
Server 2016 technical diagram.
Search components
SEARCH COMPONENT NAME DESCRIPTION
Crawl component Crawls content sources to collect crawled properties and

metadata from crawled items and sends this information to
the content processing component.
Content processing component Transforms the crawled items and sends them to the index
component. This component also maps crawled properties to
managed properties.
Analytics processing component Carries out search analytics and usage analytics.
Index component Receives the processed items from the content processing
component and writes them to the search index. This
component also handles incoming queries, retrieves
information from the search index and sends back the result
set to the query processing component.
Query processing component Analyzes incoming queries. This helps optimize precision,
recall and relevance. The queries are sent to the index
component, which returns a set of search results for the
query.
Search administration component Runs the system processes for search, and adds and initializes
new instances of search components.
Search databases
SEARCH DATABASE NAME DESCRIPTION

SEARCH DATABASE NAME DESCRIPTION
Crawl database Stores tracking information and historical information about

crawled items such as documents and URLs. It also stores
information such as the last crawl time, the last crawl ID and
the type of update (add, update, delete) during the last crawl.
Link database Stores unprocessed information that is extracted by the

content processing component and information about search
clicks. The analytics processing component analyzes this
information.
Analytics reporting database Stores the results of usage analysis.
Search administration database Stores search configuration data.
About the crawl component

The crawl component crawls the content sources. You can crawl lots of content sources, for example file shares,
SharePoint Server content, line of business applications and many more. To retrieve information, the crawl
component connects to the content sources by invoking the appropriate indexing connector or protocol handler.
After retrieving the content, the crawl component passes crawled items to the content processing component.
For more information about crawling content sources, see Plan crawling and federation in SharePoint Server.
About the content processing component

The content processing component processes crawled items and sends these items to the index component. The
content processing component performs operations such as document parsing and property mapping. It also
performs linguistics processing such as language detection and entity extraction. The component transforms
crawled items into artifacts that are included in the search index. The content processing component also writes
information about links and URLs to the link database.
For more information about content processing, see Plan crawling and federation in SharePoint Server.
About the analytics processing component

The analytics processing component performs two types of analyses: search analytics and usage analytics. This
component uses information from these analyses to improve search relevance, create search reports, and
generate recommendations and deep links.
Search analytics is about extracting information, such as links, the number of times an item is clicked,
anchor text, data related to people, and metadata, from the link database. This information is important to
relevance.
Usage analytics is about analyzing usage log information received from the front-end via the event store.
Usage analytics generates usage and statistics reports.
The results from the analyses are added to the items in the search index. In addition, results from usage analytics
are stored in the analytics reporting database.
For more information, see Overview of analytics processing in SharePoint Server.
About the index component

You can divide the search index into discrete portions, called index partitions. The search index is the aggregation
of all index partitions. Each index partition holds one or more index replicas that contain the same information. To
achieve fault tolerance and redundancy, create additional index replicas for each index partition and distribute the
index replicas over multiple servers.
The index component is the logical representation of an index replica. In the search topology, you have to
provision one index component for each index replica.
The index component:
Receives processed items from the content processing component and writes those items to an index file.
Index files are stored on a disk in the server that hosts the index component.
Receives queries from the query processing component and returns result sets.
For more information about the search schema and the search index, see Overview of the search schema in
SharePoint Server.
About the query processing component

The query component analyzes and processes queries and results. It performs linguistics processing such as
word breaking and stemming. When the query processing component receives a query from the search front-
end, it analyzes and processes the query to optimize precision, recall and relevance. The processed query is
submitted to the index component. The index component returns a result set based on the processed query to the
query processing component, which in turn processes that result set, before returning it to the search front-end.
For more information, see Plan to transform queries and order results in SharePoint Server.
About the search administration component

The search administration component runs the system processes for search. This component performs
provisioning, which is to add and initialize instances of the other search components.
About the crawl database

The crawl database stores tracking information and historical information about crawled items. For example, it
stores information about the last crawl time, the last crawl ID and the type of update during the last crawl.
About the link database

The link database stores information extracted by the content processing component. In addition, it stores
information about search clicks; the number of times people click on a search result from the search result page.
This information is stored unprocessed, to be analyzed by the analytics processing component.
About the analytics reporting database

The analytics reporting database stores the results of usage analytics. In addition, it stores statistics information
from the analyses. SharePoint Server uses this information to create Excel reports that show different statistics.
About the search administration database

The search administration database stores search configuration data, such as the topology, crawl rules, query
rules, and the mappings between crawled and managed properties. It also stores the access control list (ACL ) for
the crawl component. There can be only one search administration database per search service application.
See also
Manage the search topology in SharePoint Server
Plan enterprise search architecture in SharePoint
Server

Before you set up your enterprise search architecture, there are quite a few things that require careful planning.
Step by step, we'll help you to plan a small, a medium, large, or an extra large-size enterprise search architecture.
Are you familiar with the components of the search system in SharePoint Server, and how they interact? By
reading Overview of search architecture in SharePoint Server and Search architectures for SharePoint Server
2016 (or Search architectures for SharePoint Server 2013) before you get going, you'll become familiar with
search architecture, search components, search databases, and the search topology. When planning a search
architecture, here are some suggestions about what to consider:
Step 1: How much content do I have?
Step 2: What size search architecture for how much content?
Choose to run the servers physically or virtually
Choose hardware resources for the host servers
Plan storage performance
Choose how your search architecture supports high availability
Step 4: How to check that my search architecture performs well?
Test the storage I/O subsystem
Test the search performance

The volume of content that you have in your search index affects what resources you need to host the farm. Work
out approximately the number of items that you plan on making searchable. Here are some examples of items:
documents, web pages, SharePoint list entries, and images. Remember that each entry in a SharePoint list counts
as one item.
When you have established a figure, multiply it by what you think the expected growth of that content will be over
the next 12 months.
For example, if you're starting out with 12,000 indexed items, and you expect the volume of that content to triple
over the next 12 months. You should plan for 36,000 searchable items.
Step 2: What size search architecture for how much content?

It's not always easy to assess how big or small to make your search architecture. The size of your search
architecture depends on the volume of your content, the crawl rate, the query throughput, and the level of high
availability that you require. There are sample search architectures that we advise using as a basis to plan your
own farm. The sample search architecture that you choose depends on how much content has to be searchable:
VOLUME OF CONTENT (SHAREPOINT 2016) SAMPLE SEARCH ARCHITECTURE VOLUME OF CONTENT (SHAREPOINT 2013)
0-20 million items Small search farm 0-10 million items
0-80 million items Medium search farm 0-40 million items
0-200 million items Large search farm 0-100 million items
0-500 million items Extra large search farm Not supported
Although these sample search architectures use virtual machines, you can use both physical servers and virtual
machines according to the strategy of the overall SharePoint Server solution of your search architecture.
Small search farm
We've estimated that this search architecture can crawl 50 documents per second, and serve in the order of 10
queries per second. If you have up to 20 million items in a SharePoint Server 2016 farm, the small search farm
will probably be the most suitable farm for you. With a crawl rate of 50 documents per second, it takes search 110
hours to crawl 20 million items in the first full crawl.
Medium search farm

queries per second. If you have between 20 and 80 million items in a SharePoint Server 2016 farm, the medium
search farm will probably be the most suitable farm for you. With a crawl rate of 200 documents per second, it
takes search 280 hours to crawl 80 million items in the first full crawl.
Large search farm
queries per second. If you have between 80 and 200 million items in a SharePoint Server 2016 farm, the large
Extra large search farm

Microsoft tested this search architecture and measured that it can crawl 300-500 documents per second, and
serve in the order of 10 queries per second. Only SharePoint Server 2016 supports this size search architecture. If
you have up to 500 million items, a farm similar to the extra large search farm is a good starting point. With a
crawl rate of 500 documents per second, it takes search about 300 hours to crawl 500 million items in the first full
crawl.
Creating a search farm of this size requires you to carefully plan and tune the farm to get the performance you
want. You might find it advantageous to seek expert guidance. It's also important to plan how to back up and
restore a search farm of this size, and how to recover the farm if your data center has a major outage. We
recommend that you practice backup, restore and recovery.

Now that you've determined the volume of your content and chosen a sample search architecture, the next step is
to plan the hardware you'll need, as described in this section:
General storage
Minimum hardware resources for the small search farm
Minimum hardware resources for the medium search farm
Minimum hardware resources for the large search farm
Minimum hardware resources for the extra large search farm
Choose storage
Search component IOPS requirements
Search database IOPS requirements
If you're using one of the architectures that we've estimated for you, then you'll be running your search
architecture on virtual machines. Note also that although a virtual environment is easier to manage, its
performance level can sometimes be slightly lower than that of a physical environment. A physical server can host
more search components on the same server than a virtual server. You'll find useful guidance in Overview of farm
virtualization and architectures for SharePoint 2013.
It's also possible to run your search architecture on physical servers. In the sample farm architectures, just move
the search components from the virtual machines to the host server and take away the virtual machines. Each
physical server can host up to four index components, but only one of each type of the other search components.
If you for example change the medium sample search architecture to use physical servers, you'll find that you
have two content processing components on Host E. The solution is to take away one of the content processing
components. This works because crawling, processing of content, and processing of analytics depend on the
amount of resources that are available, not the number of content processing components.

Each search component and search database requires a minimum amount of hardware resources from the host
server to perform well. But, the more hardware resources you have, the better the performance of your search
architecture will be. So it's a good idea to have more than the minimum amount of hardware resources. The
resources each search component requires depends on the workload, mostly determined by the crawl rate, the
query rate, and the number of indexed items.
For example, when hosting virtual machines on Windows Server 2008 R2 Service Pack 1 (SP1), you can't use
more than four CPU cores per virtual machine. With Windows Server 2012 or newer, you use eight or more CPU
cores per virtual machine. Then you can scale out with more CPU cores for each virtual machine instead of scaling
up with more virtual machines. Set up servers or virtual machines that host the same search components, with
the same hardware resources. Let's use the index component as an example. When you host index partitions on
virtual machines, the virtual machine with the weakest performance determines the performance of the overall
search architecture.
General storage
Make sure that each host server has enough disk space for the base installation of the Windows Server operating
system and for the SharePoint Server program files. The host server also needs free hard disk space for
diagnostics such as logging, debugging, and creating memory dumps, for daily operations, and for the page file.
Normally, 80 GB of disk space is enough for the Windows Server operating system and for the SharePoint Server
program files.
Add storage for the SQL log space for each database server. If you don't set the database server to back up the
databases often, the SQL log space uses lots of storage. For more information about how to plan SQL databases,
see Storage and SQL Server capacity planning and configuration (SharePoint Server) .
The minimum storage that the analytics reporting database requires can vary. This is because the amount of
storage depends on how users interact with SharePoint Server. When users interact frequently, there usually are
more events to store. Check the amount of storage your current search architecture uses for the analytics
database, and assign at least this amount for your redesigned topology.
This table shows the minimum amount of hardware resources that each application server or database server
needs.
NETWORK
SERVER ON HOST STORAGE RAM PROCESSOR 1 BANDWIDTH
Application A, B 500 GB2,3 32 GB2,3 1.8 GHz 8x CPU 1 Gbps

server that has cores2,3
query processing
and index
components.
Application A, B 200 GB 8 GB 1.8 GHz 4x CPU 1 Gbps

server that has cores
crawl, search
administration,
analytics and
content
processing
components.
Database server C, D 100 GB 16 GB 1.8 GHz 4x CPU 1 Gbps

that has all cores
search databases.
1The number of CPU cores is specified here, not the number of CPU threads.
2With SharePoint Server 2013 the minimum amount of resources needed are 500 GB storage, 16 GB RAM, and
four CPU cores.
3With SharePoint Server 2016 you can also use 250 GB storage, 16 GB RAM, and four CPU cores, but then each
index component can only hold 10 million items and the search farm only supports the same volume of content
as a SharePoint Server 2013 search farm.
needs.
NETWORK
Application A, B, C, D 500 GB2,3 32 GB2,3 1.8 GHz 8x CPU 1 Gbps

query processing
and index
components.
NETWORK
SERVER ON HOST STORAGE RAM PROCESSOR BANDWIDTH

an index
component.
Application E, F 300 GB 8 GB 1.8 GHz 4x CPU 1 Gbps

analytics and
content
processing
components.

crawl, search
administration,
and content
processing
components.
Database server G, H 400 GB 16 GB 1.8 GHz 4x CPU 1 Gbps

that has all cores
search databases.
four CPU cores.
needs.
NETWORK
Application A, B, C, D, E, G, H 500 GB2, 3 32 GB2, 3 1.8 GHz 8x CPU 1 Gbps

server that has cores2, 3
query processing
and index
components.
Application A, B, C, D, E, F, G, 500 GB2, 3 32 GB2, 3 1.8 GHz 8x CPU 1 Gbps

server that has H, I, J cores2, 3
an index
component.
NETWORK
Application K, L, M, N 300 GB 8 GB 1.8 GHz 4x CPU 1 Gbps

servers that have cores
analytics and
content
processing
components
Application K, L 100 GB 8 GB 1.8 GHz 4x CPU 1 Gbps

crawl and search
administration
components
Database server O, P, Q, R 500 GB 16 GB 1.8 GHz 4x CPU 1 Gbps

that have search cores
databases
four CPU cores.
needs. You can only build this sample farm with SharePoint Server 2016.
NETWORK
Application A-X 500 GB 32 GB 1.8 GHz 8x CPU 1 Gbps

index
components.
Application Y, Z 500 GB 32 GB 1.8 GHz 8x CPU 1 Gbps

query processing
and index
components.
Application AA-AF 100 GB 8 GB 1.8 GHz 4x CPU 1 Gbps

crawl, search
administration,
or content
processing
components
NETWORK
Application AG, AH 800 GB 8 GB 1.8 GHz 4x CPU 1 Gbps

analytics
processing
components
Database servers AI-AL 500 GB 16 GB 1.8 GHz 4x CPU 1 Gbps

databases
The speed of the storage affects the search performance. Make sure that the storage you have is fast enough to
handle the traffic from the search components and databases. Disk speed is measured in I/O operations per
second (IOPS ).
The way you decide to distribute data from the search components and from the operating system across your
storage, has an impact on search performance. It's a good idea to:
Split the Windows Server operating system files, the SharePoint Server program files, and diagnostics logs
across three separate storage volumes or partitions with normal performance.
Store the search component data on a separate storage volume or partition with high performance.
NOTE
You can set a custom location for search component data when you install SharePoint Server on a host. Any search
component on the host that needs to store data, stores it in this location. To change this location later, you have to
reinstall SharePoint Server on that host.
Choose storage
For an overview of storage architectures and disk types, see Storage and SQL Server capacity planning and
configuration (SharePoint Server). The servers that host the index or analytics processing components, or search
databases, require storage that can maintain low latency, while providing sufficient I/O operations per second
(IOPS ). The following tables show how many IOPS each of these search components and databases require.
If you deploy shared storage like SAN/NAS, the peak disk load of one search component typically coincides with
the peak disk load of another search component. To get the number of IOPS search requires from the shared
storage, you need to add up the IOPS requirement of each of these components.
USE OF SEPARATE STORAGE

COMPONENT NAME COMPONENT DETAILS IOPS REQUIREMENTS VOLUME/PARTITION
Index component Uses storage when merging 300 IOPS for 64 KB random Yes
the index and when reads.
handling and responding to 100 IOPS for 256 KB
queries. random writes.
200 MB/s for sequential
reads.
writes.
Analytics component Analyzes data locally, in bulk No Yes

processing.
Crawl component Stores downloaded content No Yes

locally, before it sends it to a
content processing
component. Storage is
limited by network
bandwidth.
DATABASE NAME IOPS REQUIREMENTS TYPICAL LOAD ON I/O SUBSYSTEM.
Crawl database Medium to high IOPS 10 IOPS per 1 document per second
(DPS) crawl rate.
Link database Medium IOPS 10 IOPS per 1 million items in the

search index.
Search administration database Low IOPS Not applicable.
Analytics reporting database Medium IOPS Not applicable.

If you aren't familiar with high availability strategies, here's an article that will get you started: Create a high
availability architecture and strategy for SharePoint Server. Your search architecture supports high availability
when you host redundant search components and databases on separate fault domains. All of the sample search
architectures host redundant search components on independent servers.
For each redundant host server in your search architecture, you should plan to install:
1. Redundant networking
2. Redundant power supplies with independent wiring or an uninterruptable power supply (UPS ).
Step 4: How to check that my search architecture performs well?

Before you deploy your search architecture to a production environment, you'll need to check that it performs
well. Here's a checklist of what to do:
1. Test that the index components use a storage I/O subsystem that has enough IOPS. See Test the storage
I/O subsystem.
2. Deploy the search architecture to a pilot environment. Make sure that the pilot environment is
representative of the production environment.
3. Test the search performance of the pilot environment. See Test the search performance
For an overview of testing in general in SharePoint , see Performance testing for SharePoint Server 2013.
Test the storage I/O subsystem
To test the storage I/O subsystem, run the most important disk operations and measure the IOPS. You can use the
SQLIO tool to run these tests. See SQLIO Disk Subsystem Benchmark Tool.
Set up the test environment
You don't need to set up the whole search architecture, or install SharePoint Server. It's enough to set up a test
environment that produces a realistic workload for the storage I/O subsystem.
Let's consider the case for local storage. For example, if host A in the medium search farm uses a local disk, you
need to install the two virtual machines and run the disk operation tests on both virtual machines at the same
time.
You need a different set-up for shared storage. If for example the workload from all the index components in the
medium search farm plus other unrelated workloads share the same storage, you need to:
1. Install the eight virtual machines in host A, B, C, and D, and set up the sources of the unrelated workloads.
2. Make sure that the unrelated workload is applied to the shared storage at the same time as you run
simultaneous disk operation tests on all the virtual machines in host A, B, D, and D.
Create a test file
1. Create a 1 GB test file by using the command sqlio.exe -t32 -s1 -b256 1g . This command creates a file
named "1g".
2. Save the test file on the storage device that you want to test. For example: on the hard disk of Host A in the
medium farm.
3. Concatenate the test file to a sufficiently large test file. For example: 256 GB, with the command
copy 1g+1g+1g+…+1g testfile .
4. Restart the server. This will ensure that caching does not skew the test results.
Run tests
It's a good idea to measure:

The performance of medium sized random accesses (see test number one and two below ).
Read and write throughput for large transfers (see test number three and four below ).
The table below shows the SQLIO commands that you should use to run each test. All the commands assume
that the "testfile" exists in the current directory. Each test runs for 300 seconds.
TEST NUMBER SCOPE COMMAND
1 64 KB read [IOPS] sqlio.exe -kR -t4 -o25 -b64 -

frandom -s300 testfile
2 256 KB write [IOPS] sqlio.exe -kW -t4 -o25 -b256 -

3 100 MB read [MB/s] sqlio.exe -kR -t1 -o1 -b100000 -

4 100 MB write [MB/s] sqlio.exe -kW -t1 -o1 -b100000 -

Example results for local disk storage
The sample results in the table below show a deployment where at least 50 percent of the disk subsystem capacity
was in use before adding the test file.
The disk controller and the spindles of the disk strongly influence these results.
If you test on empty disks, you'll get elevated results because the test file will be in the most optimal tracks across
all spindles (short stroking). This can increase performance by up to two or three times. You'll get unrealistically
high results if you test a hard disk that optimizes away accesses on uninitialized storage space, or storage
containing all zeros, for example dynamic VHD/VHDX files. In this case, use a very large test file that contains real
data, rather than generating a synthetic test file using SQLIO commands.
Disk layout Test 1 Test 2 Test 3 Test 4
Recommende 300 100 200 200

d minimum
IOPS during
ordinary
operations
4x 1 TB 7200 1181 206 284 296

RPM NLSAS in
RAID5 on Dell
H710 RAID
controller
(64kB stripe
size, 64kB
block size)
8x 1TB 7200 2082 337 610 645

RPM NLSAS in
RAID5 on Dell
H710 RAID
controller
(64kB stripe
size, 64kB
block size)
16x 1TB 7200 3763 595 1173 1181

RPM NLSAS in
RAID5 on Dell
H710 RAID
controller
(64kB stripe
size, 64kB
block size)
16x 1TB 7200 3613 545 1139 1164

RPM NLSAS in
RAID50 (2x8)
on Dell H710
RAID
controller
(64kB stripe
size, 64kB
block size)
16x 1TB 7200 4030 1146 970 775

RPM NLSAS in
RAID10 on
Dell H710
RAID
controller
(256kB stripe
size, 64kB
block size)
4x 32385 3781 1714 1319
SmartStorage
Optimus
800GB SSDs
in RAID5 on
Dell H710
RAID
controller
(64kB stripe
size, 64kB
block size)
4x 31747 7149 1643 1798

SmartStorage
Optimus
800GB SSDs
in RAID0 on
Dell H710
RAID
controller
(256kB stripe
size, 64kB
block size)
Test the search performance

Here's a checklist of what to do to test your search architecture:
1. Choose content to run tests on
2. Choose terms and phrases to test query performance
3. Measure search performance
Choose content to run tests on
Choose content that represents your production content well. If you choose content that's only there for test
purposes, make sure you've got different types of items, not just one item that you've duplicated many times. The
reason for this is that the query processor will spend time detecting duplicated items, which will affect search
performance, and your results won't be representative of a production environment.
Set up one or more content sources to crawl the content. Verify that you have the required user account and
network access.
Choose terms and phrases to test query performance
The number of results you get for a query is called the recall.
To test query performance, you'll first need to create a set of terms and phrases to use as queries. Alternatively,
collect queries from an existing installation. Make sure that the set contains terms and phrases that have low recall
and high recall, and that the terms and phrases are relevant to your environment.
Examples
If you search for a product number in a product catalog, it's likely that there's only one number for one
product. Therefore, you'll get your search results fast. This is low recall.
If you search for a common term like "presentation" on a company intranet, it's likely that you'll get many
results, and it may take longer to get them. This is high recall.
If, for example, your content is related to human resources, use search terms that relate to this area.
Measure search performance
SharePoint Server collects search performance measurements in the Crawl Health Reports and Query Health
Reports. You can find these reports in Central Administration, under Search Administration.
It's a good idea to measure search performance first with a synthetic load, and then with a small set of live users,
and live content. When you use live users and live content, you can observe how the search architecture is
performing. If your content increases faster than you intended, it might be worth considering using the next size
search architecture. Or, if your users are more active than anticipated, then we suggest that you increase the
amount of storage space of the analytics database.
Scale enterprise search in SharePoint Server

Sometimes it's necessary to scale your search topology, for example:
Because your search environment has grown in amount of content or number of users, or both.
Because you've identified a bottleneck while monitoring your search solution and this bottleneck might
affect the search performance.
Because your search environment has specific performance requirements that weren't addressed when you
implemented one of the recommended search architectures described in Plan enterprise search
architecture.
How to scale your search topology

1. Redesign your search topology:
If you're scaling because your search environment has grown, follow the guidance in Redesign enterprise
search topology for more content and users in SharePoint 2016.
If you're scaling because you have specific performance requirements or to remove a bottleneck, follow the
guidance in Redesign enterprise search topology for specific performance requirements in SharePoint 2016.
2. Implement the redesigned topology either on new servers, servers in your existing farm, or a combination.
Follow the guidance in Manage the search topology in SharePoint Server.
Redesign enterprise search topology for more
content and users in SharePoint

Over time most search environments grow, both in amount of content and number of users. At some point the
search environment outgrows the capacity and performance of your search architecture. The solution is to scale
the topology of your search architecture:
1. Redesign your topology (this article)
2. Implement the redesigned topology (Manage the search topology in SharePoint Server)
Are you familiar with the components of the search system in SharePoint Server, and how they interact? By
reading Overview of search architecture in SharePoint Server and Search architectures for SharePoint Server 2016
(or Search architectures for SharePoint Server 2013) before you get going, you'll become familiar with search
architecture, search components, search databases, and the search topology.
In this article, we'll show you step-by-step how to redesign your search topology.
Step 2: What size search architecture should I scale to?
After you've followed these steps you'll know:
How many of each type of search component and search database your topology needs.
Which application servers and database servers to deploy each search component on.
What hardware resources each application server and database server needs.

The volume of content that you have in your search index affects what resources you need to host the farm. Check
how many items that are searchable in your existing search environment. You find this number on the Search
administration page in the SharePoint Central Administration website. To open the search administration page
click Manage service applications in Central Administration and then click the name of the Search service
application.
Estimate how much you expect the number of searchable items to grow over the next 12 months and design the
search topology for that amount. For example, if you have 8,000,000 indexed items, and you expect the volume of
that content to grow 50% over the next 12 months. You should design for 12,000,000 searchable items.
Step 2: What size search architecture should I scale to?

It's not always easy to assess how big or small to make your search architecture. The size of your search
architecture depends on the volume of your content, the crawl rate, the query throughput, and the level of high
availability that you require. There are sample search architectures that were tested by Microsoft that we advise
using as a basis for your own farm. Compare your current search architecture with the sample search architectures
and determine which sample best represents your current search architecture. Then consider which sample search
architecture to scale to. The sample search architecture that you choose depends on how much content has to be
searchable:
VOLUME OF CONTENT (SHAREPOINT 2016) SAMPLE SEARCH ARCHITECTURE VOLUME OF CONTENT (SHAREPOINT 2013)
0-20 million items Small search farm 0-10 million items
0-80 million items Medium search farm 0-40 million items
0-200 million items Large search farm 0-100 million items
0-500 million items Extra large search farm Not supported
Although these sample search architectures use virtual machines, you can use both physical servers and virtual
machines according to the strategy of the overall SharePoint Server solution of your search architecture.
Small search farm
queries per second. If you have up to 20 million items in a SharePoint Server 2016 farm, the small search farm will
probably be the most suitable farm for you. With a crawl rate of 50 documents per second, it takes search 110
hours to crawl 20 million items in the first full crawl.
Medium search farm

queries per second. If you have between 20 and 80 million items in a SharePoint Server 2016 farm, the medium
Large search farm
queries per second. If you have between 80 and 200 million items in a SharePoint Server 2016 farm, the large
Extra-large search farm

Microsoft tested this search architecture and measured that it can crawl 300-500 documents per second, and serve
in the order of 10 queries per second. Only SharePoint Server 2016 supports this size search architecture. If you
have up to 500 million items, a farm similar to the extra large search farm is a good starting point. With a crawl
rate of 500 documents per second, it takes search about 300 hours to crawl 500 million items in the first full crawl.
Creating a search farm of this size requires you to carefully plan and tune the farm to get the performance you
want. You might find it advantageous to seek expert guidance. It's also important to plan how to back up and
restore a search farm of this size, and how to recover the farm if your data center has a major outage. We
recommend that you practice backup, restore and recovery.

Now that you've determined the volume of your content and chosen a new topology to move to, the next step is to
plan the hardware you'll need, as described in this section:
General storage
Choose type of storage
When you originally planned your search architecture, you decided to use physical servers or virtual machines, or
a mix. Consider whether that decision still is valid. For example, if you move from the medium to the large sample
search architecture, you might find it easier to manage the increased number of servers when you use virtual
machines. Note also that although a virtual environment is easier to manage, its performance level can sometimes
be slightly lower than that of a physical environment. A physical server can host more search components on the
same server than a virtual server. You'll find useful guidance in Overview of farm virtualization and architectures
for SharePoint 2013.
The small, medium, large, or extra large search architecture samples run on virtual machines, but they can also run
on physical servers. In the sample farm architectures, just move the search components from the virtual machines
to the host server and take away the virtual machines. Each physical server can host up to four index components,
but only one of each type of the other search components. If you for example change the medium sample search
architecture to use physical servers, you'll find that you have two content processing components on Host E. The
solution is to take away one of the content processing components. This works because crawling, processing of
content, and processing of analytics depend on the amount of resources that are available, not the number of
content processing components.
up with more virtual machines. Set up servers or virtual machines that host the same search components, with the
same hardware resources. Let's use the index component as an example. When you host index partitions on virtual
machines, the virtual machine with the weakest performance determines the performance of the overall search
architecture.
General storage resources
Make sure that each host server has enough disk space for the base installation of the Windows Server operating
system and for the SharePoint Server program files. The host server also needs free hard disk space for
program files.
see Storage and SQL Server capacity planning and configuration (SharePoint Server).
storage depends on how users interact with SharePoint Server. When users interact frequently, there usually are
more events to store. Check the amount of storage your current search architecture uses for the analytics database,
and assign at least this amount for your redesigned topology.
needs.
NETWORK
Application A, B 500 GB2,3 32 GB2,3 1.8 GHz 8x CPU 1 Gbps

query processing
and index
components.
Application A, B 200 GB 8 GB 1.8 GHz 4x CPU 1 Gbps

crawl, search
administration,
analytics and
content
processing
components.
Database server C, D 100 GB 16 GB 1.8 GHz 4x CPU 1 Gbps

that has all cores
search databases.
four CPU cores.
index component can only hold 10 million items and the search farm only supports the same volume of content as
a SharePoint Server 2013 search farm.
needs.
NETWORK

query processing
and index
components.
NETWORK

an index
component.

analytics and
content
processing
components.

crawl, search
administration,
and content
processing
components.
Database server G, H 400 GB 16 GB 1.8 GHz 4x CPU 1 Gbps

that has all cores
search databases.
four CPU cores.
needs.
NETWORK
Application A, B, C, D, E, G, H 500 GB2,3 32 GB2,3 1.8 GHz 8x CPU 1 Gbps

query processing
and index
components.
Application A, B, C, D, E, F, G, 500 GB2,3 32 GB2,3 1.8 GHz 8x CPU 1 Gbps

server that has H, I, J cores2,3
an index
component.
NETWORK
Application K, L, M, N 300 GB 8 GB 1.8 GHz 4x CPU 1 Gbps

analytics and
content
processing
components
Application K, L 100 GB 8 GB 1.8 GHz 4x CPU 1 Gbps

crawl and search
administration
components
Database server O, P, Q, R 500 GB 16 GB 1.8 GHz 4x CPU 1 Gbps

databases
2With SharePoint Server 2013 the minimum amount of resources needed are 500 GB RAM, 16 GB RAM, and four
CPU cores.
needs. You can only build this sample farm with SharePoint Server 2016.
NETWORK
Application A-X 500 GB 32 GB 1.8 GHz 8x CPU 1 Gbps

index
components.
Application Y, Z 500 GB 32 GB 1.8 GHz 8x CPU 1 Gbps

query processing
and index
components.
Application AA-AF 100 GB 8 GB 1.8 GHz 4x CPU 1 Gbps

crawl, search
administration, or
content
processing
components
Application AG, AH 800 GB 8 GB 1.8 GHz 4x CPU 1 Gbps

analytics
processing
components
NETWORK
Database servers AI-AL 500 GB 16 GB 1.8 GHz 4x CPU 1 Gbps

databases
second (IOPS ).
The way that you decide to distribute data from the search components and from the operating system across your
storage, affects search performance. It's a good idea to:
Split the Windows Server operating system files, the SharePoint Server program files, and diagnostic logs
Store the search component data on a separate storage volume or partition. For index components, this
storage must also have high performance.
NOTE
component on the host that needs to store data, stores it in this location. To change this location later, you have to
reinstall SharePoint Server.
configuration (SharePoint Server 2013). The servers that host the index, analytics processing, and the search
administration components, or search databases, require storage that can maintain low latency, while providing
sufficient I/O operations per second (IOPS ). The following tables show how many IOPS each of these search
components and databases require.

the index and when handling reads.
and responding to queries. 100 IOPS for 256 KB
random writes.
reads.
writes.

processing.

content processing
limited by network
bandwidth.
(DPS) crawl rate.

search index.
availability architecture and strategy for SharePoint Server. When you host redundant search components and
databases on separate fault domains, an outage in one part of the farm doesn't take down the complete service.
But, search performance will degrade because the search components can't share the load any longer. To reduce
the possibility of losing a single server it's a good idea to improve local redundancy. For each host server in your
search architecture:
Use RAID storage on each server.
Install multiple redundant network connections on each server.
Install multiple redundant power supplies with independent wiring or an uninterruptible power supply
(UPS ) for each server.
All of the sample search architectures host redundant search components on independent servers. In the sample
search architectures, the rightmost host in each host pair is redundant. Here's the large search architecture with
outlined redundant hosts:
Redesign enterprise search topology for specific
performance requirements in SharePoint

If your search environment has specific performance requirements that weren't met by following the guidance in
Plan enterprise search architecture in SharePoint Server 2016, then the solution is to scale the topology of your
enterprise search architecture:
1. Redesign your topology (this article)
2. Implement the redesigned topology (Manage the search topology in SharePoint Server)
Are you familiar with the components of the search system in SharePoint Server 2016, and how they interact? By
reading Overview of search architecture in SharePoint Server and Search architectures for SharePoint Server
2016 (or Search architectures for SharePoint Server 2013) before you get going, you'll become familiar with
search architecture, search components, search databases, and the search topology.
In this article, we'll show you step-by-step how to redesign your search topology to meet specific performance
requirements:
Step 1: What are the specific performance requirements?
Step 2: Which search components should I scale?
Step 3: Choose to run the servers physically or virtually
Step 4: Which server to host which search component or database?
After you've followed these steps you'll know:
How many of each type of search component and search database your topology needs.
Which application servers and database servers to deploy each search component on.
What hardware resources each application server and database server needs.
Step 1: What are the specific performance requirements?

Ensure that you understand the business needs behind the specific performance requirements. For example, news
and financial search require fresh data that are indexed near real-time, while litigation support services require
ingestion of batches of data that are indexed once. Express the performance requirements in one or more of these
ways:
The number of indexed items.
How many items the search solution must crawl per second and with what latency.
How many queries the search solution must serve per second and with what latency.
In addition to these performance requirements, your environment might also have requirements for the relevancy
of query results and for the search topology to be redundant. Sometimes you don't have a specific performance
requirement, but you've identified a bottleneck in the search architecture that might affect performance. We'll
cover that too.
Step 2: Which search components should I scale?

To deliver higher performance or to remove a bottleneck, you can add more search components to do the job or
you can add more resources to the servers hosting search components. Adding more search components is known
as scaling out, while adding more resources to the servers is known as scaling up. Which search components to
scale out, or which servers to scale up, depends on the performance metric to improve, or the bottleneck to
remove. Here are some examples:
If the environment requires a higher query rate and the CPU resources for indexing are a bottleneck, add
another index replica to each partition of the index. This lets search serve more queries in parallel.
If CPU resources for processing crawled content are a bottleneck, scale out the number of content
processing components. You can also scale up the content processing components by running them on
servers with more or faster CPUs. Either way of scaling implies more CPU resources for processing content.
If the analytics components don't complete their analyses quickly enough, scale up the processor resources,
disk IOPS or network bandwidth of the servers hosting analytics components.
Note that we don't support unlimited scale-out of the number of search components or databases. Look up the
maximum limits in Search limits and stay within these limits to ensure timely and robust communication between
the search components and databases. If it's necessary, reduce the capacity of your search architecture by reducing
the number of search components.
In the following sections we have guidelines for you on which search components or databases to scale to satisfy
each requirement:
How to handle more items in the index
How to increase the ingestion rate and the freshness of results
How to reduce query latency and increase query throughput
How to decrease analytics processing time
How to make your search components and databases redundant
How to handle more items in the index
When the amount of indexed items increases while the indexed items change at the same rate as before, increase
the capacity of your search topology by scaling out these search components and databases:
SEARCH COMPONENT OR DATABASE GUIDELINE
Index component Use one index partition for each 20 million 1 indexed items.
Each partition contains one or more replicas of the partition.
All partitions must have the same number of replicas. An
index component represents one index replica. So, if you want
two replicas of the index then you'll need twice as many index
components as index partitions.
For example, a redundant index with 80 million2 items requires
four partitions. Eight index components represent the four
partitions when using two replicas for each partition.
SEARCH COMPONENT OR DATABASE GUIDELINE
Crawl database Use one crawl database for each 20 million items in the
content corpus. For example, an index with 100 million items
requires five crawl databases.
If the increased amount of indexed items implies a higher
crawl rate, you also need more IOPS resources to serve the
crawl databases. If your crawl rate is one document per
second then the crawl database needs about 10 IOPS.
Link database Use one link database for each 60 million items in the content
corpus. For example, an index with 100 million items requires
two link databases.
If the added content implies a higher crawl rate, you might
need more IOPS resources to serve the link databases.
Analytics reporting database How many analytics reporting databases you need, depends
on how the search environment uses analytics, and how often.
In general, add an analytics reporting database when the
analytics performance starts decreasing. For example, when
the nightly update of the database starts to take more time.
This might happen when the database reaches a size of 250
GB, or 20 million rows in total, or when the number of views
per day reaches 500,000 unique items.
110million items with SharePoint Server 2013, or with SharePoint Server 2016 running with less resources than
500 GB storage, 32 GB RAM, and eight CPU cores.
240million items with SharePoint Server 2013, or with SharePoint Server 2016 running with less resources than
500 GB storage, 32 GB RAM, and eight CPU cores.
How to increase the ingestion rate and the freshness of results
There are some situations where you might need to increase the ingestion rate. One example is if your
environment requires very fresh results and the content volume is close to the upper item limit for your search
architecture, or the content changes often. Content might change often if people used to archive files on a team
site, but now they store their files on OneDrive for Business while they work on them. Search indexes all the
changes people make to their files.
It's useful to understand which factors influence how quickly search can ingest items:
How quickly search can crawl items. This depends on:
The speed of the connection between the crawl components and the content sources.
The type and average size of the items to crawl.
The performance of the SQL server hosting the crawl databases.
The amount of CPU and memory resources that the crawl components have.
How much content processing each item requires before indexing.
How many partitions the index has. More partitions lets search spread the load of indexing.
Here's what to do:
1. Check the freshness of the results in your farm by looking at the age distribution of the crawled items. In the
SharePoint Central Administration website, go to Crawl Health Reports and select Crawl Freshness.
What age distribution that's acceptable for your farm depends on your business requirements. Here's an
example: If the Crawl Freshness page shows that it takes four hours to index 90% of the content, but your
requirement is 30 minutes, then increase the ingestion rate.
2. On the Crawl Freshness page, identify in which periods of the day that results aren't fresh enough.
3. Follow the guidelines to increase the ingestion speed in these time periods.
GUIDELINE
Improve freshness for a specific content source
Increase processing resources for crawling
Increase processing resources for the crawl database
Increase processing and memory resources for content processing
Increase the number of index partitions
Improve freshness for a specific content source
Check the crawl schedule, and identify which content sources that search crawls in the time periods where
freshness is low. If the freshness is low for a specific content source, consider the following:
Increase the speed of the connection between the server hosting the crawl component and that content
source. It's the crawl rate, downloading items from content sources, and passing items to the content
processing component that drives the need for network bandwidth for the crawl component.
If the content source is SharePoint, that farm might need more, and dedicated, crawl targets. Read about
crawl targets in Manage crawl load (SharePoint 2010).
Improve the performance of the content database. Learn how in Best practices for SQL Server in a
Increase processing resources for crawling
If the crawl component often uses 100% of the processor resources, consider adding another crawl component or
adding more processor resources to the servers hosting crawl components. It's the crawl rate, discovery of links,
and management of crawling that drives the need for processor resources. Normally, crawling is fast enough when
you use two crawl components in search architectures like the small and medium sample search architectures that
Microsoft has estimated. Search architectures like the large and extra-large samples might need more than two
crawl components.
Increase processing resources for the crawl database
Check whether the SQL servers hosting crawl databases have enough resources. Read how to do this in Best
practices for SQL Server in a SharePoint Server farm.
If all the crawl databases use a lot of processor resources, consider adding more processor resources to the SQL
server hosting the databases or add another SQL server with the same number of crawl databases as the existing
SQL servers. If you for example have two SQL servers that each has three crawl databases, add another SQL
server with three crawl databases.
If only one or a few crawl databases use a lot of processor resources, this means that the load is uneven across the
crawl databases. Consider rebalancing the content across all crawl databases. Note that during rebalancing search
pauses crawling, so results are less fresh while rebalancing and until crawling has caught up with the changes that
took place during the pause. You trigger rebalancing with the Balance button on the Databases page. In Search
Administration, go to Crawl Log and select Databases.
Increase processing and memory resources for content processing
If the content processing component uses close to 100% of the CPU resources, consider adding more content
processing components, or adding more CPU resources to the servers hosting content processing component.
If you notice that memory restarts often, consider increasing the amount of memory on the servers hosting
content processing components. 2 GB working memory per CPU core is a good rule of thumb.
Increase the number of index partitions
Check the content processing activity. You find this by going to Search Administration, selecting Crawl Health
Report and then selecting Content Processing Activity. If indexing is the activity that takes most time, consider
dividing the index into more partitions. More index partitions lets search spread the load of indexing.
If you add more partitions on a running installation, the index repartitions itself. It can take several hours, or days,
for the index to repartition. How long time it takes depends on the state of the farm when repartitioning begins.
How to reduce query latency and increase query throughput
How many queries search can serve per second is known as query throughput. Query throughput depends on the
time search uses to process a query and any time the query waits because a processing resource isn't available.
The sum of the processing and waiting time is known as query latency. Reducing query latency increases query
throughput. To reduce query latency, follow one or both of these guidelines:
GUIDELINE
Reduce the processing time for queries
Reduce the waiting time for queries
Reduce the processing time for queries
Consider adding more partitions to the index. More partitions mean fewer items in each partition. Fewer items
mean that each partition responds faster to queries. But too many partitions aren't good either. Because the query
processing component has to merge the responses from each partition to produce an answer to a query, a merge
takes more time when the index has more partitions. All partitions must have the same number of replicas.
When you add more partitions on a running installation, the index repartitions itself. It can take several hours, or
days, for the index to repartition. How long time it takes depends on the state of the farm when repartitioning
begins.
Reduce the waiting time for queries
Consider these actions:

Add more replicas of the index. When you add more replicas, search distributes queries across the replicas
and works on them in parallel. An index component represents one index replica. All partitions must have
the same number of replicas, so add one index component to each partition of the index. When you add
index components as replicas to existing partitions on a running installation, search automatically seeds the
new replicas with data from the index partition. It can take several hours before the new replicas are
operational.
Add more memory to the servers hosting index components.
On the servers hosting index components, switch to faster storage for the index, for example a Solid State
Drive (SSD ).
Add more processor resources to the servers hosting index components. Then the components handle
more queries per second. For example, if the server has a 2 GHz CPU, one core can handle:
5 queries per second when you have 1 million items in the index.
2 queries per second when you have 5 million items in the index.
1 query per second when you have 10 million items in the index.
Add more processor resources to the servers hosting query processing components. Then the components
handle more queries per second, especially when queries are infrequent and complex. It's the query rate
and the number of query transforms that drive the need for processor resources for the query processing
component. A query processing component typically needs one CPU core per 4 queries per second.
How to decrease analytics processing time
Analytics processing takes place every night. The analytics processing component stores intermediate data on the
server hosting the component, and stores the results of the analysis in the analytics reporting database. If a fault
hinders processing of analytics, this will not affect document crawling or answering queries. But the query results
won't have optimal relevance.
Consider these actions:
If your environment requires optimal relevance for query results and analytics processing isn't fast enough
to satisfy this, add more disks (spindles) or faster disks.
If the analytics processing starts to take more time than usual, add an analytics reporting database. You
might see such an increase when the database reaches a size of 250 GB, or 20 million rows in total, or when
the number of views per day reaches 500,000 unique items.
If the analytics processing takes more than 24 hours to complete, either add more analytics processing
components, or add more processor resources to the servers hosting analytics processing components. It's
the number of items in the index and the activity on the site that drives the need for processor resources.
If the analytics processing never completes, or you get health alerts for the disks on the servers hosting
analytics components, add more disk space to the servers. For the analytics component to process the
larger amount of intermediate data faster, consider adding more analytics processing components or more
processor resources to the server hosting the analytics processing component.
How to make your search components and databases redundant
Your search architecture supports high availability when you host redundant search components and databases on
separate fault domains. We recommend designing your search topology with redundant search databases and
components. All the sample search architectures that Microsoft tested have redundant search components and
databases, you might find it useful to study these samples when working on your own topology (see Enterprise
Search Architectures for SharePoint 2016).
Follow these guidelines:
GUIDELINES
Make the index redundant
Make crawling, content processing, query processing, analytics processing, and search administration redundant
Make search databases redundant
Make the index redundant
Your index is redundant if it has two or more index replicas per index partition. If a server hosting an index replica
fails, this might reduce performance but search can still serve queries and index items. But if the environment
requires the same performance at all times, search needs more redundant index components. For example: You
designed your search topology with two replicas per partition to reduce the waiting time for queries and your
environment requires a short waiting time for queries all the time. Increase the number of index replicas per
partition.
All partitions must have the same number of replicas. An index component represents one index replica. So, if you
want two replicas of the index then you'll need twice as many index components as index partitions. For example,
with SharePoint Server 2016a redundant index with 80 million items requires four partitions. Eight index
components represent the four partitions when using two replicas for each partition.
If you add index components as replicas to existing partitions on a running installation, search automatically seeds
the new replicas with data from the index partition. It can take several hours before the new replicas are
operational.
Make crawling, content processing, query processing, analytics processing, and search administration redundant
Let's use the crawl component as an example. If you need to take down one of the servers hosting a crawl
component for maintenance, this might reduce the freshness of results but search can still crawl all the content. But
if the environment requires the same freshness of results all the time, search needs more redundant crawl
components. For example: You designed your search topology with three crawl components and you want the
same freshness of results even if two crawl component servers fail. Add two more crawl components.
The search administration component is an exception to this principle. One search administration component has
enough capacity for any size search topology. So, two search administration components are enough for
redundancy.
Content processing components balance the load among each other, so redundant content processing components
increase the capacity to process items.
Make search databases redundant
To make your search databases redundant, use the high availability alternatives that SQL server offers (see Create
a high availability architecture and strategy for SharePoint Server).
Step 3: Choose to run the servers physically or virtually

When you originally planned your search architecture, you decided to use physical servers or virtual machines, or
a mix. Consider whether that decision still is valid. If you now have many more search components, you might
want to use virtual machines to make managing the architecture easier. For example, it's easier to replace a faulted
virtual machine than a physical machine. Note also that although a virtual environment is easier to manage, its
performance level can sometimes be slightly lower than that of a physical environment. A physical server can host
more search components on the same server than a virtual server. You'll find useful guidance in Overview of farm
virtualization and architectures for SharePoint 2013.
Step 4: Which server to host which search component or database?

Now that you've redesigned your search topology, your next step is to assign the search and database components
to physical or virtual servers. There isn't one optimal way to assign search components to physical servers or
virtual machines, but we've got guidelines for you:
One search component type per server
Each physical server or virtual machine can only host one search component of each type. The index component is
an exception. Physical servers or virtual machines can host up to four index components. You can read about these
limits in Search limits.
Separate bulk processing and real-time components from each other
Avoid mixing bulk processing and real time processing search components on the same physical server or virtual
machine. Crawl, content processing, and analytics processing components perform bulk processing. Index and
query processing components perform real time processing.
Don't mix competing search components
Avoid mixing search components on a physical server or machine if the components will compete for the same
resources. Here's a table that illustrates the relative amount of resources that each component needs.
For example, it might not be a good idea to put a crawl and analytics processing component on the same server
because they both use a lot of network bandwidth. But, if the physical server or virtual machine has enough
network capacity, the components won't compete.
Another example is the extra-large search architecture sample that Microsoft has estimated. Here we've put the
crawl and search administration components on separate virtual machines. This is good for the speed of crawling
because the two components otherwise might compete for processor resources.
Use failure domains
Assign redundant search components to hosts in separate failure domains.

The next step is to plan the hardware you'll need:
Choose amount of hardware resources for the host servers
General storage
Minimum resources for the index component
Minimum resources for the analytics processing component
Minimum resources for the crawl, content processing, query processing, and search administration
component
Minimum resources for search databases
Choose amount of hardware resources for the host servers
up with more virtual machines. Set up servers or virtual machines that host the same search components, with the
same hardware resources. Let's use the index component as an example. When you host index partitions on virtual
machines, the virtual machine with the weakest performance determines the performance of the overall search
architecture.
General storage
Make sure that each host server has sufficient disk space for the base installation of the Windows Server operating
system and for the SharePoint Server 2016 program files. The host server also needs free hard disk space for
2016 program files.
see Storage and SQL Server capacity planning and configuration (SharePoint Server).
storage depends on how users interact with SharePoint Server 2016. When users interact frequently, there usually
are more events to store. Check the amount of storage your current search architecture uses for the analytics
database, and assign at least this amount for your redesigned topology.
Minimum resources for the index component
These are the minimum resources a server or virtual machine must have to host one index component, or to host
one index component and one query processing component:
Storage Memory Processor Network bandwidth
500 GB for the index1 32 GB1 64-bit, 8 cores minimum1 , 2 . 2 Gbps
1With SharePoint Server 2013 the minimum amount of resources are 500 GB storage, 16 GB RAM, and four CPU
cores.
2You can use 16
GB RAM and four CPU cores with SharePoint Server 2016, but then each index component can
maximum hold 10 million items (instead of 20 million items).
Minimum resources for the analytics processing component
These are the minimum resources a server or virtual machine must have to host one analytics processing
component:
300 GB for local processing 8 GB 64-bit, 4 cores minimum, 2 Gbps

of analytics but 8 cores recommended.
If the server hosts one analytics processing component and one or more bulk processing components, increase
memory to 16 GB.
Minimum resources for the crawl, content processing, query processing, and search administration component
These are the minimum resources a server or virtual machine must have to host one of these components:
Not required 8 GB 64-bit, 4 cores minimum, 2 Gbps

but 8 cores recommended.
If the server hosts two or more of these components, increase memory to 16 GB.
The query processing component requires good network bandwidth. It's the number of index partitions and the
size of queries and results that drive this need for network bandwidth. For example, 20 queries per second per
query processing component (20 QPS/QPC ) and an index with 20 index partitions results in 200 Mbps incoming
traffic and 100 Mbps outgoing traffic for the server or virtual machine hosting the query processing component.
Minimum resources for search databases
These are the minimum resources a server or virtual machine must have to host one or more search databases:
The storage that the 8 GB for small deployments. 64-bit, 4 cores. 2 Gbps
analytics reporting database
requires varies with how the 16 GB for medium
search environment uses deployments
analytics, and how often.
Use the current amount of
storage for the analytics
reporting database as a
guideline.

second (IOPS ).
The way that you decide to distribute data from the search components and from the operating system across
your storage, affects search performance. It's a good idea to:
Split the Windows Server operating system files, the SharePoint Server 2016 program files, and diagnostic
logs across three separate storage volumes or partitions with normal performance.
Store the search component data on a separate storage volume or partition. For index components, this
storage must also have high performance.
NOTE
You can set a custom location for search component data when you install SharePoint Server 2016 on a host. Any
search component on the host that needs to store data, stores it in this location. To change this location later, you
have to reinstall SharePoint Server 2016.
configuration (SharePoint Server 2016). The servers that host the index, analytics processing, and the search
administration components, or search databases, require storage that can maintain low latency, while providing
sufficient I/O operations per second (IOPS ). The following tables show how many IOPS each of these search
components and databases require.

the index and when handling reads.
and responding to queries. 100 IOPS for 256 KB
random writes.
reads.
writes.

processing.

content processing
limited by network
bandwidth.
(DPS) crawl rate.

search index.

availability architecture and strategy for SharePoint Server. When you host redundant search components and
databases on separate fault domains, an outage in one part of the farm doesn't take down the complete service.
But, search performance will degrade because the search components can't share the load any longer. To reduce
the chance of losing a single server it's a good idea to improve local redundancy. For each host server in your
search architecture:
Use RAID storage on each server.
Install multiple redundant network connections on each server.
Install multiple redundant power supplies with independent wiring or an uninterruptable power supply
(UPS ) for each server.
All of the sample search architectures host redundant search components on independent servers. In the sample
search architectures, the rightmost host in each host pair is redundant. Here's the large search architecture with
outlined redundant hosts:
Scale search for Internet sites in SharePoint Server

This article lists the minimum hardware requirements for virtual machines and physical servers for search
topologies for Internet sites.
This article also provides basic guidance on the scaling of search topologies to improve performance and
availability.
Introduction
This article lists the minimum requirements and gives guidance about how and when to scale out search
topologies for Internet sites.
For examples of topologies, see the technical diagram Internet sites search architectures for SharePoint Server
2016.
For an overview and a description of search components and the overall search architecture, see Overview of
search architecture in SharePoint Server and the technical diagram Search architectures for SharePoint Server
2016.
Hardware requirements for search topologies for Internet sites

The following tables show the hardware requirements for servers that host a medium search topology for
Internet sites. The hardware requirements apply to:
Application servers and Web servers that contain search components.
Database servers that contain search databases.
The minimum listed RAM requirements for a server that hosts a search component is the total required amount
of RAM for that server. For example, if you are hosting a content processing component, a search administration
component and a crawl component on one server, the total amount of minimum required RAM for that server is
24 GB.
Each server must have sufficient disk space for the base installation of the Windows Server operating system and
sufficient disk space for diagnostics such as logging, debugging, creating memory dumps, and so on. For
production use, the server also needs additional free disk space for day-to-day operations and for the page file.
Follow the guidance on free disk space and page file size corresponding to your Windows Server installation.
NOTE
The medium search topology example is optimized for physical hardware, but you can deploy it on virtual machines as well.
Application servers and Web servers hosting search components
SEARCH COMPONENT ON THE

PHYSICAL SERVER RAM HARD DISK PROCESSOR
SEARCH COMPONENT ON THE
PHYSICAL SERVER RAM HARD DISK PROCESSOR
Index component 48 GB for each server in the 500 GB additional disk **All components:**64-bit, 4
farm that hosts an index space, preferably a separate cores minimum, 8 cores
component, a query disk volume/partition. recommended.
processing component and
the Web front end.
Analytics processing 24 GB for each server in the 300 GB additional disk

component farm that hosts an analytics space, preferably a separate
processing component, a disk volume/partition.
crawl component, a content
processing component
and/or a search
administration component.
Crawl component Content See the requirements listed 80 GB for system drive.
processing component for the analytics processing
component.
Query processing See the requirements listed

component for the index component.
Search administration See the requirements listed

component for the analytics processing
component.
Database servers hosting search databases
COMPONENT MINIMUM REQUIREMENTS
Processor 64-bit, 4 cores for small topologies.

64-bit, 8 cores for medium topologies.
RAM 8 GB for small topologies.

16 GB for medium topologies.
Hard disk 80 GB for system drive.

Hard disk space depends on the amount of content.
Performance considerations for a medium Internet sites topology

A medium Internet sites (FIS ) topology is optimized for a corpus size of 3,400,000 items, processing
approximately 100-200 documents per second, depending on language, and a usage pattern of 85 page views per
second, which corresponds to 100 queries per second.
Performance considerations
WHAT TO CONSIDER WHY THIS IS IMPORTANT

WHAT TO CONSIDER WHY THIS IS IMPORTANT
Cache The query and its results are cached with Windows Server
AppFabric, in key-value pairs: the query being the key and
the results being the value. For each query, there is an
approximate 50% cache ratio. This means that if you have a
usage pattern of 200 queries per second, about 100 queries
are sent to the search index and the other 100 queries are
cached. The results from the cache have lower query latency
than those that you retrieve from the search index. For
example, results for front-page queries that are often run are
likely to be cached.
Continuous crawl We recommend that you enable continuous crawl with an

interval of one minute, instead of the default interval of 15
minutes. You can only enable continuous crawl on SharePoint
content sources.
Anonymous access With anonymous access, users do not have to use credentials
to log on to a SharePoint Internet site. Anonymous queries
are cached, so they are cheaper because of lower query
latency. You must enable anonymous access in two locations:
on the web front-end and on the site.
Query latency Query latency is influenced by caching, anonymous access

and by other factors such as the number and complexity of
query rules that are applied and triggered. Also, consider the
disks on which the search index is stored; a disk that has
multiple spindles can improve the access speed of the disk
and reduce query latency.
See also
Change the default search topology in SharePoint Server
Manage search components in SharePoint Server
Manage the index component in SharePoint Server
Best practices for organizing content for search in
SharePoint Server

These best practices for organizing SharePoint Server content and applying useful metadata will help make sure
that the right content is included in the search index and that the right content is returned in search results.
Keep your most important content in SharePoint

If possible, keep your most important content in SharePoint, and crawl and index as much premium content as
possible. If you cannot crawl and index the content, consider federating results from other sources into your local
search results.
Try to organize content with similar value and importance into nearby site structures. The search system will
automatically infer the relative importance, but you can also influence the importance of sites directly by defining
authoritative pages. For more information, see the section Specify authoritative pages.
It is important to know what content to crawl and include in the search index, but it is also important to know what
content not to crawl. For example, you do not want to crawl and index backup file shares. You should also establish
routines for archiving obsolete content, deleting low -quality content and encourage users to add expiration dates
to announcements.
Organize content in hierarchies and use natural language

By organizing SharePoint content in natural hierarchies, you not only make it is easier for users to understand
where they can find and file their content, but you also make it easier for the search system to rank the content and
return search results that better match the user's intent.
FLAT STRUCTURE STRUCTURE WITH HIERARCHY
http://Europe http://sales
http://Asia http://sales/Europe
http://sales/Asia
URLs and other metadata of files, such as file names, are analyzed linguistically by the search system. If you use
natural language for URLs and for metadata, the search system can more easily understand what information is in
the site or file and give it an appropriate ranking in the results. It is much easier for the search system (and users)
to understand a URL and file name like http://sales/Europe/presentations/phones.ppt than it is to make sense of
http://slseur/p_phones.ppt.
Encourage users to enter rich and consistent metadata for their sites
and content
Metadata is data that provides additional information about one or more aspects of sites and content, such as who
created the content or site, when was it created, and what the purpose of the content or the site is. Consistent and
rich metadata increases the quality of the content itself, and it also enables the search system to more easily
discover relationships between content, and to provide more targeted and relevant search results.
These are some examples of important metadata that you should encourage users to provide:
Title of a document
Description of a site
The author(s) of a document
The date the content was created
For some document types, such as PowerPoint and Word, the search system extracts additional metadata such as
headings and subheadings from inside the content, and uses this information to return the right search results and
to provide rich document summaries and previews.
To provide the right search results for people, it is also important that My Sites and user profile data is entered so
that this information can be used as metadata by the search system.
Managing multilingual content

The search system detects the language of most content automatically. These recommendations help prevent that
the search system detects the wrong language:
If possible, keep content in different languages on different sites. If the search system cannot detect the
language of a particular content item, it assumes that it is in the language of the site where it is stored.
Avoid mixing languages in content and that content's metadata. Use the same language in the metadata as
the language that is used in the content itself.
Avoid mixing languages in a single piece of metadata. This is mostly applicable to URLs.
Specify authoritative pages

You can use the Authoritative Pages feature in the Search service application to specify SharePoint sites that
contain the most relevant information. Search results from authoritative pages are ranked higher in the search
results.
You can specify three degrees of authority, and you can also specify non-authoritative sites. When you identify a
site as an authority, sites that are connected to the authoritative page via hyperlinks are also boosted in the results,
based on their proximity to the authoritative page. A most-authoritative page contains or links to the most relevant
information. URLs designated as non-authoritative are ranked lower than other sites.
We recommend that you only specify a small number (four-five) of authoritative pages. If you specify lots of
authoritative pages, it is difficult to predict the effects on the ranking of search results.
For more information, see Configure authoritative pages in SharePoint Server.
Plan crawling and federation in SharePoint Server

Before users can perform searches in SharePoint Server, you must crawl or federate the content that you want
them to be able to search. When you crawl content, the Search service builds a search index that users can run
queries (search requests) against. You can also configure the Search system to display search results from an
external provider (such as Bing) alongside the results from the local search index. The process of getting search
results from an external provider and displaying the results locally is called federation.
Plan content sources

A content source is a definition of a group of crawl settings such as which hosts to crawl, the type of content that
will be crawled (such as SharePoint content or file shares), a crawl schedule, and how deep to crawl.
When you create a Search service application, the service application automatically provides the pre-configured
content source Local SharePoint sites. You can use this content source to specify how to crawl all SharePoint
content in web applications that are associated with the Search service application.
If you have only one type of content (for example, all content is of type SharePoint sites or type file shares), you
might need only one content source. However, if you have different types of content or unique requirements per
host, you might want to define multiple content sources. Plan to create additional content sources when you have
to do the following:
Crawl different types of content — for example, file shares and data in a line-of-business application
Crawl some content on different schedules than other content
Limit or increase the quantity of content that is crawled
Set different priorities for crawling different sites
Keep some types of content fresher than others
You can create a large number of content sources in each Search service application, but there is overhead
associated with each content source. Therefore, we recommend that you create the smallest number of content
sources that satisfy your other operational requirements, such as differences in crawl priority and crawl
scheduling. Each content source can contain up to 100 start addresses.
Plan to crawl different kinds of content
You can crawl only one kind of content per content source. For example, you can create a content source that
contains start addresses for SharePoint sites and another content source that contains start addresses for file
shares, but you cannot create a single content source that contains start addresses to both SharePoint sites and
file shares. The following table lists the kinds of content sources that you can configure.
USE THIS KIND OF CONTENT SOURCE FOR THIS CONTENT

USE THIS KIND OF CONTENT SOURCE FOR THIS CONTENT
SharePoint sites SharePoint sites from the same farm or different SharePoint
Server farms.
SharePoint sites from the same farm or different SharePoint

Server 2019, SharePoint Server 2016, SharePoint Server
2013, SharePoint Server 2010, SharePoint Foundation 2010,
or Microsoft Search Server 2010 farms.
SharePoint sites from the same farm or different Office

SharePoint Server 2007, Windows SharePoint Services 3.0, or
Search Server 2008 farms.
Web sites Other web content in your organization that is not located in
SharePoint sites.
Content on web sites on the Internet.
File shares Content on file shares in your organization.
Security note: When the Search service crawls a file share, if

the permissions on a file on the share are different from the
permissions on folders that contain the file, then the
permissions on the file take precedence and are used for
security trimming of search results. Therefore, to ensure that
only appropriate items appear in search results, make sure
that the permissions for files on file shares are appropriate.
For cases in which file permissions are not appropriate, you
can delete particular items from the search index or from
search results. For more information, see Delete items from
the search index or from search results in SharePoint Server.
Exchange public folders Exchange 2007 and Exchange Server 2010 public folders.
Lotus Notes E-mail messages stored in Lotus Notes databases.
Note: Unlike all other kinds of content sources, the Lotus

Notes content source option does not appear in the user
interface until you have installed and configured the
appropriate prerequisite software. For more information, see
Configure and use the Lotus Notes connector for SharePoint
Server (also applies to SharePoint Server).
Documentum Content from the EMC Documentum system.
Note: You can't crawl EMC Documentum content before you

have installed and configured the appropriate prerequisite
software and the Microsoft SharePoint Indexing Connector
for Documentum. For more information, see Configure and
use the Documentum connector in SharePoint Server (also
applies to SharePoint Server).
Line-of-business data Business data that is stored in line-of-business applications.
Custom repository Content sources that can only be crawled after a custom
connector is installed and registered.
Content sources for line-of-business data

Business data content sources require that the applications hosting the data are specified in an Application Model
in a Business Data Connectivity service application. You can create one content source to crawl all applications
that are registered in the Business Data Connectivity service, or you can create separate content sources to crawl
individual applications. For more information, see Search connector framework in SharePoint 2013 (This MSDN
article also applies to SharePoint Server).
Often, the people who plan for integration of business data into site collections are not the same people involved
in the overall content planning process. Therefore, include business application administrators in content
planning teams so that they can advise you how to integrate the business application data into content and
effectively present it in the site collections.
Crawl content on different schedules
Consider defining content sources with different schedules for the following reasons:
To accommodate down times and periods of peak usage.
To more frequently crawl content that is more frequently updated.
To crawl content that is located on slower servers separately from content that is located on faster servers.
To continuously crawl a SharePoint content source because of high freshness demands. For more
information, see Manage continuous crawls in SharePoint Server.
Reasons to do a full crawl
Reasons for a Search service application administrator to do a full crawl for one or more content sources include
the following:
A Search service application has just been created and the preconfigured content source Local
SharePoint sites has not been crawled yet.
Some other content source is new and has not been crawled yet.
The Search service application administrator has changed a content source.
A software update or service pack was installed on servers in the farm. See the instructions for the
software update or service pack for more information.
A Search service application administrator or site collection administrator added or changed a managed
property. A full crawl of all affected content sources is required for the new or changed managed property
to take effect.
You want to detect security changes that were made to local groups on a file share after the last full crawl
of the file share.
You want to resolve consecutive incremental crawl failures. If an incremental crawl fails a large number of
consecutive times for any particular content, the system removes the affected content from the search
index.
Crawl rules have been added, deleted, or modified.
You want to replace a corrupted search index.
The permissions for the user account that is assigned to the default content access account have changed.
The system does a full crawl even when an incremental crawl or continuous crawl is scheduled under the
following circumstances:
A search administrator stopped the previous crawl.
A content database was restored, or a farm administrator has detached and reattached a content database.
A full crawl of the content source has never been done from this Search service application.
The crawl database does not contain entries for the addresses that are being crawled. Without entries in
the crawl database for the items being crawled, incremental crawls cannot occur.
Limit or increase the quantity of content that is crawled
The options available in the properties for each content source vary depending on the content source type that
you select. You can use crawl setting options to limit or increase the quantity of content that is crawled. For each
content source, you can specify how extensively to crawl the start addresses. Most content source types allow you
to specify how many levels deep in the hierarchy from each start address to crawl. This behavior is applied to all
start addresses in a particular content source. If you have to crawl some sites at deeper levels, you can create
additional content sources that include those sites. The following table describes best practices when you
configure crawl setting options.
FOR THIS KIND OF CONTENT SOURCE IF THIS PERTAINS USE THIS CRAWL SETTING OPTION
SharePoint sites You want to include the content that is Crawl only the SharePoint site of each
on the site itself and you do not want start address.
to include the content that is on
subsites, or you want to crawl the
content that is on subsites on a
different schedule.
SharePoint sites You want to include the content on the Crawl everything under the host name
site itself. of each start address.
-or-
You want to crawl all content under the

start address on the same schedule.
Web sites Content available on linked sites is Crawl only within the server of each
unlikely to be relevant. start address.
Web sites Relevant content is located on only the Crawl only the first page of each start
first page. address.
Web sites You want to limit how deep to crawl Custom — Specify the number of
the links on the start addresses. pages deep and number of server hops
to crawl.
Note: For a highly connected site, we

recommend that you start with a small
number, because specifying more than
three pages deep or more than three
server hops can crawl the entire
Internet.
File shares Content available in the subfolders is Crawl only the folder of each start
Exchange public folders unlikely to be relevant. address.
File shares Content in the subfolders is likely to be Crawl the folder and subfolders of each
Exchange public folders relevant. start address.
Business data All applications that are registered in Crawl the whole Business Data Catalog
the Business Data Catalog metadata metadata store.
store contain relevant content.
FOR THIS KIND OF CONTENT SOURCE IF THIS PERTAINS USE THIS CRAWL SETTING OPTION
Business data Not all applications that are registered Crawl selected applications.
in the BDC metadata store contain
relevant content.
-or-
You want to crawl some applications on

a different schedule.
Plan connectors
The crawler uses connectors (known as "protocol handlers" in earlier versions of SharePoint Server) to acquire
and index content. For the most commonly-used protocols, SharePoint Server provides and automatically uses
the appropriate connectors. To crawl content that requires a connector that is not provided by default, you must
first install a third-party connector or build a custom connector. For a list of connectors that are installed by
default, see Default connectors in SharePoint Server (also applies to SharePoint Server).
Other considerations when planning content sources
For content repositories that are of the same type, such as SharePoint sites, your decision about whether to use
one or more content sources depends largely upon administrative considerations. To make administration easier,
organize content sources in such a way that updating content sources, crawl rules, and crawl schedules is
convenient for administrators.
You can't crawl the same start addresses by using multiple content sources in the same Search service
application. For example, if you use a particular content source to crawl a site collection and all its subsites,
you cannot use a different content source to crawl one of those subsites separately on a different schedule.
Administrators often update content sources. Changing a content source requires a full crawl for that
content source. Therefore, consider creating separate content sources so that you can run multiple full
crawls at the same time if necessary, and so that a full crawl for any particular content source is less time-
consuming.
Plan crawl rules to optimize crawls
Crawl rules apply to all content sources in the Search service application. You can apply crawl rules to a particular
URL or set of URLs to do the following things:
Avoid crawling irrelevant content by excluding one or more URLs. This also helps reduce the use of server
resources and network traffic.
Crawl links on the URL without crawling the URL itself. This option is useful for sites that have links of
relevant content when the page that contains the links does not contain relevant information.
Enable complex URLs to be crawled. This option directs the system to crawl URLs that contain a query
parameter specified with a question mark. Depending upon the site, these URLs might not include
relevant content. Because complex URLs can often redirect to irrelevant sites, it is a good idea to enable
this option only on sites where you know that the content available from complex URLs is relevant.
Enable content on SharePoint sites to be crawled as HTTP pages. This option enables the Search system to
crawl SharePoint sites that are behind a firewall or in scenarios in which the site being crawled restricts
access to the Web service that is used by the crawler (a crawl component in the search topology).
Specify whether to use the default content access account, a different content access account, or a client
certificate for crawling the specified URL.
Because crawling content consumes resources and bandwidth, it is better to include a smaller amount of content
that you know is relevant than a larger amount of content that might be irrelevant. After the initial deployment,
you can review the query and crawl logs and adjust content sources and crawl rules to be more relevant and
include more content.
Plan crawler authentication
When the crawler accesses the start addresses that are listed in content sources, the crawler must be
authenticated by, and granted access to, the servers that host that content. By default, the system uses the default
content access account. Or, you can use crawl rules to specify a different content access account to use when
crawling particular content. Whether you use the default content access account or a different content access
account specified by a crawl rule, the content access account that you use must have at least read permissions on
all content that is crawled. If the content access account does not have read permissions, the content is not
crawled, is not indexed, and therefore is not available to queries.
We recommend that the account that you specify as the default content access account has access to most of
your crawled content. Only use other content access accounts when security considerations require separate
content access accounts.
For each content source that you plan, determine the start addresses that cannot be accessed by the default
content access account, and then plan to add crawl rules for those start addresses.
IMPORTANT
Ensure that the domain account that is used for the default content access account or any other content access account is
not the same domain account that is used by an application pool associated with any Web application that you crawl.
Doing so can cause unpublished content in SharePoint sites and minor versions of files (that is, history) in SharePoint sites
to be crawled and indexed.
Another important consideration is that the crawler must use the same authentication protocol as the host server.
By default, the crawler authenticates by using NTLM. You can configure the crawler to use a different
authentication protocol, if it is necessary.
If you are using claims-based authentication, make sure that Windows authentication is enabled on any Web
applications to be crawled.
Plan content processing

The crawler crawls content repositories specified by content sources and then feeds the contents and metadata of
crawled items to the content processing component. The content processing component reads and parses the
crawled properties and then reports the properties to the Search Administration database.
You can map crawled properties to managed properties and configure property settings by editing the search
schema. The content processing component reads the search schema and uses it to carry out the mapping. Only
managed properties are included in the search index. Managed properties can be used to create refiners, for
example. For more information, see Overview of the search schema in SharePoint Server.
Include or exclude file types
Content from any file type can be included in the search index. In order for content to be indexed, it must first be
crawled by a crawl component and then parsed by a content processing component. A crawl component can
crawl a file only if the file extension is included in the list of file name extensions on the Manage File Types page.
A content processing component can parse the contents of a crawled file only under the following conditions:
The content processing component has a format handler that can parse the file format.
The content processing component is enabled to parse files that have the file format and file name
extension.
If the content processing component is unable to parse a file, the search index will only include file properties,
such as the file name.
By default, SharePoint Server satisfies these requirements for many types of files and it can crawl and parse these
file types without your having to install additional format handlers. For an overview of the file types, see Default
crawled file name extensions and parsed file types in SharePoint Server.
NOTE
You can extend the initial collection of file formats that SharePoint Server can parse by adding third-party filter-based
format handlers, known as iFilters. A third party iFilter can override a built-in format handler.
When you plan to include content in the search index from content repositories that have file types that are not
on the Manage File Types page, review the following:
To crawl the file type, add the file type to the Manage File Types page.
To parse the file type:
If SharePoint Server does not have a format handler for the format, install a third-party filter-based
format handler for the file format on each server that hosts a content processing component in the
Search service application.
Enable parsing of the file format and file name extension on each server that hosts a content
processing component in the Search service application
For more information, see Add or remove a file type from the search index in SharePoint Server.
Plan to use (custom) entity extractors
You can configure the search system to look for "entities" in unstructured content, such as in the body text or the
title of a document. These entities can be words or phrases, such as product names. To specify which entities to
look for, you can create and deploy your own dictionaries.
The extracted entities are stored in the search index as separate managed properties, which are automatically
configured to be searchable, queryable, retrievable, sortable and refinable. You can use those properties in search
refiners, for example, to help users filter their search results.
For companies, you can use the pre-populated company extraction dictionary that SharePoint Server provides.
In addition, you can deploy several types of custom entity extractors in the form of custom entity extraction
dictionaries. You deploy these dictionaries using Microsoft PowerShell. The entries in these dictionaries (single or
multiple words) will be matched on words or parts of words in the content in a case-sensitive or case-insensitive
way. For more information, see Create and deploy custom entity extractors in SharePoint Server.
CUSTOM ENTITY EX TRACTOR / DICTIONARY DESCRIPTION
Word Extraction Case-insensitive, maximum 5 dictionaries. For example, the

entry "anchor" would match "anchor" and "Anchor", but not
"anchorage".
Word Part Extraction Case-insensitive, maximum 5 dictionaries. For example, the

entry "anchor" would match "anchor", "Anchor" and within
"anchorage".
CUSTOM ENTITY EX TRACTOR / DICTIONARY DESCRIPTION
Word Exact Extraction Case-sensitive, maximum 1 dictionary. For example, the entry
"anchor" would match "anchor", but not "Anchor" or
"Anchorage".
Word Part Exact Extraction Case-sensitive, maximum 1 dictionary. For example, the entry
"anchor" would match "anchor" and within "anchorage", but
not "Anchor".
About result sources and federation

In SharePoint Server, you use a result source to specify the URL of a provider to get search results from, a
protocol to use to get those results, and other related settings. For example, the preconfigured default result
source is Local SharePoint Results.
You can add result sources that specify external search providers (such as remote search engines or feeds) from
which to get search results. This is called federation.
About federation
When you use federation, users can search for and retrieve content that has not been crawled by servers in the
local farm. For example, federation can provide search results from a web-search provider such as Bing, or
perhaps from a private data set that you do not have access to crawl.
Federation can also be a good solution for a geographically distributed organization that wants to provide search
access to content at its various locations when each location has its own search index. Because each location
provides search results from its own index, it is not necessary to deploy a centralized search service that builds
and accesses a single, unified index. In this context, federation can provide advantages such as the following:
Low bandwidth requirements ─ An organization that is geographically dispersed might not have the
high network bandwidth that is required to crawl and index large amounts of remote content. When an
organization uses federation, the main data that is transmitted for search across the wide-area network is
only a set of search results from each federated content repository.
Freshness of search results ─ Each division within an organization can crawl the local content more
quickly than a centralized search deployment would be able to crawl all of the content in the entire
organization.
Divisional search variability ─ When an organization uses federation, each division within the
organization can provide and control its own search environment. Each division can tailor search to its
own requirements and preferences, with its own user experience and its own search connectors, for
example. A centralized search portal would not allow for such differences.
Limited size of search indexes ─ A large, geographically distributed organization might have millions of
documents. It might not be practical for the organization to have a single, unified search index because of
the infrastructure that would be required to support such a large index. Federation enables users in each
division to perform a single search to find relevant content that is distributed across multiple smaller
search indexes in the organization.
Using result sources for federation
To use federation in SharePoint Server, you select one of the following protocols in the Protocol section on the
Add/Edit Result Source page:
TO GET FEDERATED SEARCH RESULTS FROM THIS KIND OF
YOU SELECT THIS PROTOCOL PROVIDER
Remote SharePoint The index of a search service in another SharePoint Server

farm
OpenSearch 1.0/1.1 An external search engine or feed that uses the OpenSearch
protocol, such as Bing
Exchange Exchange Server 2013
NOTE
On the Add/Edit Result Source page, when you select one of the protocols shown in the preceding table, you must also fill
in other related fields on the page to fully specify the result source.
See also
Understanding result sources for search in SharePoint Server
Configure result sources for search in SharePoint Server
Manage crawling in SharePoint Server
Default connectors in SharePoint Server
Default crawled file name extensions and parsed file types in SharePoint Server
Search connector framework in SharePoint 2013
Overview of the search schema in SharePoint Server

The search index is the center of search. What is in your search index determines what people will find when they
look for information by entering search queries or by interacting with internet or intranet pages.
This article describes how content is collected in and retrieved from the search index by using the search schema.
The search schema contains crawled properties, crawled property categories, the crawled to managed property
mapping and the managed property settings. Managed property settings define what you can search for and
how, for example if you can refine or query on a property.
Crawling and crawled properties

To build up the search index, you must first crawl content. You can crawl various content sources, for example
SharePoint Servercontent, file shares or user profiles. The contents and metadata of the items that you crawl are
represented as crawled properties.
Each item that has been crawled and passed on to the content processing component has crawled properties
associated with it. Examples of properties are Author, Title, and Creation Date. Any new crawled properties will
be discovered automatically.
Crawled properties are grouped into categories that are based on the IFilter or protocol handler of the item.
Example categories are Office (crawled properties from Word documents, Excel worksheets, and so on),
Business Data (crawled properties from for example databases), and Web (crawled properties from web sites).
For more information about crawling, see Plan crawling and federation in SharePoint Server.
Managed properties and property mapping

To include the contents and metadata of crawled properties in the search index, you must map crawled properties
to managed properties. Only managed properties are written to the search index.
Managed properties can have many settings. The settings on the managed property determine how the contents
can be shown in search results and how people can search for it.
You can map multiple crawled properties to a single managed property. For example, you can map both the
"Writer" and "Author" crawled properties to the "Author" managed property. Or, you can map a single crawled
property to multiple managed properties.
Also, the order in which crawled properties are mapped to a managed property can determine the content of a
managed property. For example, a managed property can have multiple crawled properties mapped to it and can
be set to includes all values from all crawled properties mapped to it. But, if you give the crawled property
containing the SharePoint title priority over another title in the mapping, it will show the SharePoint title in the
search results.
A set of default mappings between crawled and managed properties has been defined, see Overview of crawled
and managed properties in SharePoint Server.
Some crawled property types automatically generate a new managed property and a mapping between the
crawled and managed property. For example, all site columns from SharePoint libraries have this automatic
generation and mapping. When you create a site column in a list, and you crawl that list, a crawled property, a
managed property, and a mapping between the crawled and managed property is automatically created for the
site column.
You can change the default mapping or any other mapping from crawled to managed properties, create new
mappings, or create new managed properties. When you create a new managed property, or when you change
certain settings on existing managed properties, a full crawl must complete before the managed property and its
value is included in the search index. If the new or changed property is in a SharePoint library or list, you can
reindex that individual library or list without starting a full crawl of the entire SharePoint content source. This has
the same effect as a full crawl.
See the table Managed property settings overview later in this article for more information.
The search schema

The search schema is stored in the Search Administration database. The search schema contains:
The mapping between crawled properties and managed properties. This can be a mapping from one
crawled property to one managed property, from one to many, many to one or even a many to many
mapping.
How the managed properties should be written to the search index. For example, to which full-text index
the values of the managed properties should be written and to which weight group (context).
The settings for the different managed properties. For example, if you can search on, query on, or refine
search results by particular managed properties.
Crawled property categories that group properties according to their IFilter or protocol handler. If you edit
a crawled property category, your changes apply to all of the crawled properties within the category. This
can influence performance and how items are saved in the search index.
Search schema updates are propagated through the search system every minute.
Multiple search schemas
You can create multiple search schemas. The main search schema is defined in the Search service application and
can be edited in the Central Administration. Site collection administrators and tenant administrators can change
the search schema for a particular site collection or tenant. For example, a site collection administrator can
customize what is included in the search index by changing the search schema for that site collection and, by
doing this, customize the search experience for that site collection. Site owners can view the search schema, but
not change it.
NOTE
You can't view or change the site collection search schema in Central Administration. To view or make changes in the search
schema for a site collection, you have to use Site Collection Administration.
The search index

The search index consists of a set of files in folders on a server. The content processing component processes
crawled items, uses the search schema to map crawled properties to managed properties, and translates the
managed properties into a format that is written to the search index. In addition to various full-text indexes, there
are separate indexes of the managed properties that are marked as retrievable and those that are marked as
queryable. There is also a separate index for attribute vectors, and there are numeric indexes.
Index update groups
Whenever an item changes, it must be re-indexed after it has been crawled again. To reduce the re-indexing load,
SharePoint Server introduces several separate index update groups.
Default Contains he majority of managed properties. This index update group contains all managed
properties that do not belong to the Security, Link, Usage or People index update groups.
Security Contains the document Access Control List (ACL ) managed property
Link Contains the managed properties related to link structure
Usage Contains the managed properties related to usage data
People Contains the managed properties related to people search
Each update group is stored in a different folder in the search index.
Full-text index
A full-text index contains all the text from the searchable managed properties that are stored in that full-text
index. Each full-text index is divided into weight groups, also referred to as contexts. The different contexts relate
to the relative importance of a managed property, which is one of the ranking features that are used to calculate
the total relevance rank of a search result. The number, or ID, of a context is not important; the ranking model
determines its relative importance by assigning a contribution weight to a particular context. A higher
contribution weight results in a higher ranking score. For more information, see the section Influence the ranking
of search results by using the search schema in the article Overview of search result ranking in SharePoint
Server.
There are two pre-defined full-text indexes other than the default full-text index: the SharePoint Terms full-text
index ( SpTermsIdx ) and the People index ( PeopleIdx ).
Most managed properties are already mapped to a suitable context and full-text index by default. We do not
recommend changing the context of any of the existing searchable managed properties.
Managed property settings overview

Settings on the managed properties determine how content is saved in the search index and if and how people
can search for and retrieve it.
The search schema can be edited in Central Administration, Site Collection Administration and Tenant
Administration. Site administrators can view the search schema, but they can't edit the search schema. The
following table describes the different settings and whether they are available for editing on different
administrator levels.
FULL CRAWL OR
REINDEX SHAREPOINT
LIST/LIBRARY
MANAGED PROPERTY REQUIRED AFTER
SETTING WHAT IT DOES EXAMPLE AVAILABLE IN CHANGING SETTING
Searchable Enables querying If the property is Central Yes

against the content "author", a simple Administration / Site
of the managed query for "Smith" Collection
property. The content returns items that Administration /
of this managed contain the word Tenant
property is included "Smith" and items Administration
in the full-text index. whose author
property contains
"Smith".
FULL CRAWL OR
REINDEX SHAREPOINT
LIST/LIBRARY
Advanced Searchable Enables viewing and Central Yes

Settings changing the full-text Administration / Site
index that the Collection
managed property is Administration /
written to. It also Tenant
allows you to change Administration
the context of the
managed property
for the relevance rank
calculation. We do
not recommend
changing the context
of any of the existing
managed properties.
For more information,
see the section
Influence the ranking
of search results by
using the search
schema in the article
Overview of search
result ranking in
SharePoint Server.
Queryable Enables querying If the managed Central From disabled to

against the specific property is "author", Administration / Site enabled.
managed property. the query must Collection
The managed contain Administration /
property name must "author:Smith". Tenant
be included in the Administration
query, either specified
in the query itself or
included in the query
programmatically.
Retrievable Enables the content Central From disabled to

of this managed Administration /Site enabled.
property to be Collection
returned in search Administration
results. Enable this /Tenant
setting for managed Administration
properties that are
relevant to present in
search results.
Allow multiple values Allows multiple values If this is the "author" Central Yes
of the same type in managed property, Administration
this managed and a document has
property. multiple authors,
each author name will
be stored as a
separate value in the
managed property.
FULL CRAWL OR
REINDEX SHAREPOINT
LIST/LIBRARY
Refinable Yes - active: Enables If the "author" Central From disabled to

using the property as managed property is Administration enabled (if not
a refiner for search set to Refinable, you already set to
results in the front can set up Author as Sortable)
end. You must a refiner in your
manually configure search front-end later.
the refiner in the web
part.
Yes - latent: Enables

switching refinable to
active later, without
having to do a full re-
crawl when you
switch.
Both options require

a full crawl to take
effect.
IMPORTANT: If you
select Yes - active or
Yes - latent, you must
also make the
managed property
Queryable.
Not supported in the

modern search
experience.
Sortable Yes - active: Enables Use for large result Central From disabled to
sorting the result set sets that cannot be Administration enabled (if not
based on the sorted and retrieved already set to
property before the at the same time. Refinable)
result set is returned.
Yes - latent: Enables

switching sorting to
active later without
having to do a full re-
crawl when you
switch.
Both options require

a full crawl to take
effect.

modern search
experience.
FULL CRAWL OR
REINDEX SHAREPOINT
LIST/LIBRARY
Alias Defines an alias for a Use an alias if you Central No

managed property if don't want to or don't Administration / Site
you want to use the have permission to Collection
alias instead of the create a new Administration /
managed property managed property. Tenant
name in queries and Administration
in search results. Use
the original managed
property and not the
alias to map to a
crawled property.
Token normalization Enables returning The query "curacao" Central Yes

results independent will also match Administration / Site
of letter casing and "Curaçao", "curacao" Collection
diacritics used in the and "Curacao". Administration /
query. Tenant
Administration
Complete matching By default, search If a managed Central Yes

returns partial property "Title" Administration / Site
matches between contains "Contoso Collection
queries against a Sites", only the query Administration /
managed property Title: "Contoso Sites" Tenant
and the content of will give a result. Administration
the managed
property.
Select Complete
Matching for search
to return exact
matches instead.
Language neutral Select language If the crawled Central Yes

tokenization neutral tokenization if property for a Administration / Site
(SharePoint Server you have multilingual product identifier is Collection
2019 only) content and the mapped to a the Administration /
managed property managed property Tenant
contains tags that are “ProductID”, then Administration
based on metadata search uses language
term sets or other neutral tokenization
identifiers. for queries against
"ProductID".
By default, search
depends on language
when it breaks
queries and content
into parts
(tokenization). For
example, a document
library containing
both English and
Chinese product
datasheets where
product identifiers
have non-
alphanumerical
characters, such as
FULL CRAWL OR
“11.132-84-115#4”. REINDEX SHAREPOINT
When search LIST/LIBRARY
MANAGED PROPERTY processes a REQUIRED AFTER
SETTING WHAT IT DOES
datasheet, it detects EXAMPLE AVAILABLE IN CHANGING SETTING
its language, and
tokenizes everything
in it according to that
language. When
users search for a
product identifier,
search tokenizes their
query according to
the language setting
of the SharePoint site
they’re on. If the site
is set to English, and
the user searches for
a product identifier
that was tokenized as
Chinese text, the
tokens might not
match, and the users
get no results.
To make results
better for users, map
the crawled property
for the product
identifier to a new
managed property,
“ProductID”, with
language neutral
tokenization enabled.
Instruct users to
search for product
identifiers against the
new managed
property, like this:
ProductID:”11.132-8”.
FULL CRAWL OR
REINDEX SHAREPOINT
LIST/LIBRARY
Finer query Use this setting to If you have a Central No

tokenization help users get better managed property Administration / Site
(SharePoint Server search results when "Product identifier" Collection
2019 only) they search in that contains Administration /
managed properties “11.132-884-115#4”, Tenant
that contain searches like Administration
metadata with non- ProductID:”132-884”
alphanumeric will likely get results.
characters. This
setting makes queries
against the managed
property slower.
Users who prefer to

quickly enter a query
and then browse the
results to find the
datasheet they’re
looking for, typically
enter queries like
ProductID:”132-884”.
Because search by
default breaks
content for the
search index into
smaller parts than it
does for queries,
search might not find
matches for these
queries. When the
query is tokenized
finer, it’s more likely
that there are
matches between the
tokens in the search
index and in the
query. Users can also
query for the middle
or last part of the
product identifier.
Users who search for

a datasheet and
expect to only get
results that match
the full product
identifier, typically
write queries like
ProductID:”11.132-
884-115#4”. Finer
query tokenization
doesn’t make a
difference for such
queries.
FULL CRAWL OR
REINDEX SHAREPOINT
LIST/LIBRARY
Mappings to crawled The list shows all the Central Yes

properties crawled properties Administration / Site
that are mapped to Collection
this managed Administration /
property. A managed Tenant
property can get its Administration
content from one or
more crawled
properties.
You can either include

content from all
crawled properties or
include content from
the first crawled
property that is not
empty, based on a
specified order.
FULL CRAWL OR
REINDEX SHAREPOINT
LIST/LIBRARY
Company name Enables the system to Central Yes

extraction extract company Administration / Site
name entities from Collection
the managed Administration /
property when Tenant
crawling new or Administration
updated items. The
extracted entities can
later be used to set
up refiners.
There is one pre-

populated dictionary
for company name
extraction. The
system saves the
original managed
property content
unchanged in the
index, and, in
addition, copies the
extracted entities to
the managed
property
"companies". The
"companies"
managed property is
configured to be
searchable,
queryable,
retrievable, sortable
and refinable.
You can edit the

company name
dictionary in the Term
Store.

see Manage company
name extraction in
SharePoint Server.

modern search
experience.
FULL CRAWL OR
REINDEX SHAREPOINT
LIST/LIBRARY
Custom entity Enables one or more Central Yes

extraction custom entity Administration / Site
extractors to be Collection
associated with this Administration
managed property.
This enables the
system to extract
entities from the
managed property
when crawling new or
updated items. The
extracted entities can
later be used to set
up refiners.

see Create and
deploy custom entity
extractors in
SharePoint Server.

modern search
experience.
See also
Manage the search schema in SharePoint Server
Overview of crawled and managed properties in SharePoint Server
Understanding result sources for search in SharePoint
Server

This article provides a brief overview of result sources in SharePoint Server.
NOTE
The modern search experience in SharePoint Server 2019 gets its results from the default result source. If you change the
default result source it impacts both the classic and modern search experiences.
What is a result source?

When a user issues a query, the search system associates the query with a result source to provide search results.
The result source is a definition that specifies each of the following:
A search provider or source URL to get search results from — for example, the search index of the local
SharePoint Search service
A protocol to use to get search results — for example, the OpenSearch protocol
A query transform, which can narrow results from the given search provider or URL to a specified subset
— for example, a subset that has a particular content type
A result source can also specify other settings, such as an authentication method to use when requesting results
from a provider.
An example of a pre-configured result source is "Local Video Results". This result source specifies the local
SharePoint search index as the provider and "Local SharePoint" as the protocol, and it has a query transform that
specifies that it will return only files that have file extensions that correspond to videos, such as MP4. The "Local
Video Results" result source is used by the Videos search experience, or search vertical, on the default enterprise
Search Center results page.
The following screen shot shows the four search experiences that are available on a default enterprise Search
Center results page. The user can choose one of these search experiences before submitting a query from the
search box.
The following table shows the result sources that are used by the four search experiences that are available on a
default enterprise Search Center results page. Each search experience uses a different result source.
Search experiences and corresponding result sources
THIS SEARCH EXPERIENCE USES THIS PRECONFIGURED RESULT SOURCE
Everything Local SharePoint Results

THIS SEARCH EXPERIENCE USES THIS PRECONFIGURED RESULT SOURCE
People Local People Results
Conversations Conversations
Videos Local Video Results
Available result sources

SharePoint Server provides 16 pre-configured result sources, which are available in all sites and site collections in
web applications that consume a Search service application. The pre-configured result sources are shown in the
following table. You can view details about result sources from the Manage Result Sources page.
Pre-configured result sources
THIS RESULT SOURCE SPECIFIES THESE ITEMS IN THE LOCAL SHAREPOINT INDEX
Conversations Discussions in microblogs, newsfeed posts, and community

sites
Documents Microsoft Office documents and PDF documents
Items matching a content type Items that match a content type that the incoming query
specifies
Items matching a tag Documents or list items that match a managed metadata
term that the incoming query specifies
Items related to current user Documents or list items that are related to the user in a way
that the query template specifies
Local People Results People items from the profile database of the User Profile
service application
Local Reports and Data Results Excel, Office Data Connection (ODC), or Report Definition
Language (RDL) items, or items in a report library
Local SharePoint Results All items from the local SharePoint search index except People
items
Local Video Results Videos
Pages
Pictures Photos and images
Popular Documents and list items sorted by view count
Recently changed items Documents and list items sorted by Modified date
Recommendations Documents and list items that you recommend for the
incoming query
THIS RESULT SOURCE SPECIFIES THESE ITEMS IN THE LOCAL SHAREPOINT INDEX
Wiki SharePoint wiki pages
From the Manage Result Sources page, you can create other result sources in either of the following two ways:
You can click New Result Source. For more information, see Configure result sources for search in
SharePoint Server.
You can point to the arrow next to an existing result source, click Copy, and then modify the copy as
necessary and save it with a new name.
Result source protocols and URLs

A result source specifies one of four protocols to use to get search results, as shown in the following table.
Result source protocols
A RESULT SOURCE THAT SPECIFIES THIS PROTOCOL GETS SEARCH RESULTS FROM THIS SEARCH PROVIDER
Local SharePoint The search index of the local Search service
Remote SharePoint The search index of a Search service hosted in another farm
OpenSearch 1.0/1.1 An external search provider (such as a remote search engine

or feed) that uses the OpenSearch protocol to provide search
results
Exchange Exchange Web Services
A result source that uses a protocol other than "Local SharePoint" must also specify a URL from which to get
search results, as shown in the following table.
Result source URLs
A RESULT SOURCE THAT USES THIS PROTOCOL MUST SPECIFY THIS URL
Remote SharePoint The address of the root site collection of the remote
SharePoint Server farm
OpenSearch 1.0/1.1 The URL of the RSS feed of a search provider that uses the
OpenSearch protocol
Exchange An Exchange Web Services URL
Who can create result sources?

Result sources can be created at the Search service application level, site collection level, or site level. This enables
Search service application administrators, site collection administrators, and site owners to create and use result
sources to meet their specific requirements for providing search results to users. When you create a result source
at the Search service application level, for example, the result source is available to any query rule that is created
at the same level, and also to any query rule that is created for a site collection or site that is in a web application
that consumes that Search service application. For information about levels and permissions for result sources,
see Create a result source in Configure result sources for search in SharePoint Server.
Specifying a result source to use for a query
A query is initially associated with a result source according to the search experience in which the user performs
the query. For example, if a user clicks People below a search box (see the screen shot earlier in this article) to
specify the People search experience, the query uses the "Local People Results" result source.
A Search Box Web Part is always associated with a particular Search Results Web Part. When a user types a query
in a search box, the Search Box Web Part sends the query to the associated Search Results Web Part. That Search
Results Web Part specifies the result source for the query; by default, this result source is "Local SharePoint
Results". You can set a different result source as the default. You can also edit any Search Results Web Part to
specify a different result source for it to use. For example, you might add a new search experience called "Reports",
and create a search results page for displaying search results for that search experience. You could then edit the
default Search Results Web Part that is on the new Reports results page to specify an appropriate result source for
that search experience. An example of such a result source would be a SharePoint site that contains content types
that correspond to reports. For more information, see the following resources:
Set a result source as default in Configure result sources for search in SharePoint Server
You can configure the search system so that a query becomes associated with an additional or a different result
source under certain conditions. One way to do this is to create a query rule that displays search results from
another result source if a query is more frequently performed in that result source than in the one that the user
performed it on. For example, let's say that a user queries on "keynote speech" in the Conversations search
experience but the query is more popular in the Videos search experience. In that case, you could configure an
action that also displays results from the Videos result source in a separate result block. For more information, see
the following resources:
Transforming queries with query rules in Plan to transform queries and order results in SharePoint Server
Manage query rules in SharePoint Server
When you create a query rule, on the Manage Query Rules page you specify a result source to which the rule will
apply. Then on the Add/Edit Query Rule page, in the Context section, you can add or remove result sources to
which the rule will apply. When a query is submitted to any result source other than those that you set as
applicable, the rule cannot fire. For example, if you create a query rule that you want to fire only for people
searches, you would specify "Local People Results" as the result source to which the rule applies.
Narrowing search results by using a query transform

You can configure the search system so that it interprets the intent of user queries and then modifies queries
accordingly to provide more targeted search results. One way to do this is to use the Query Transform section
that is part of the definition of each result source. For example, to provide a Videos search experience, in the result
source you could configure a query transform to specify a SharePoint site from which to get search results for
video queries.
You can also modify queries in the Web Part that issues a query, and in query rules. A user query is transformed
first by any modifications that were configured in the Web Part, then by any query rules that fire, and finally by the
query transform in the result source for the query. The query rules and result sources can take the modified query
as input and modify the query again. However, the modifications made to a query by a result source cannot be
modified further, because the query transform in a result source modifies the query last. For more information,
see Plan to transform queries and order results in SharePoint Server.
Each pre-configured result source uses a query transform and thus provides an example of how you can use a
query transform to narrow search results. On the Manage Result Sources page, you can click each result source to
see how it uses a query transform. For example, you can click the pre-configured "Local People Results" result
source to see that it uses the following query transform to provide people-related results from the profile
database:
{?{searchTerms} ContentClass=urn:content-class:SPSPeople}
For more information, see Building search queries in SharePoint 2013
(https://msdn.microsoft.com/library/jj163973.aspx).
See also
Query variables in SharePoint Server
Default connectors in SharePoint Server
Transforming queries in result sources
About result sources and federation
Plan to transform queries and order results in
SharePoint Server

You can add query transforms to a Web Part, add query rules that transform queries when certain conditions are
met, and you can transform all queries directed to a result source to create a specialized search experience.
SharePoint Server contains a number of predesigned search experiences, or search verticals, such as "Videos",
"People" and "Conversations". These all contain predefined query transforms to optimize the search experience.
You can also design your own search experiences that include your own query transforms, for instance for
"Music" or "Pictures".
Understanding query transforms and query variables

You can configure a query transform to replace certain properties of a query, such as the result source that the
query will use to get search results from, or the sort order that it will use when it displays search results.
A query transform can contain query variables. Query variables are placeholders for values, and when a query is
actually run, the query variables are replaced with specific values.
The following table shows some examples of query variables.
A QUERY TRANSFORM REPLACES THIS QUERY VARIABLE: WITH THIS:
{User.Name} The name of the user who typed the query.
{Site.URL} The site where the user typed the query.
{Today} Today's date.
{SearchBoxQuery} The query that the user typed.
{searchTerms} The query that the user typed, as changed by the most
recent transform.
See Query variables in SharePoint Server for an overview of all the available query variables.
When a query transform replaces the incoming query, it uses a query template . A query template is a query
that includes query variables, for example "{searchTerms} contenttype:picture".
If you, for example, want to create a Pictures search vertical that only returns pictures in the search results, you
could configure a query transform that uses the query template "{searchTerms} contenttype:picture" to add
"contenttype:picture" to all queries. If a user then types the query "moon" in the Pictures vertical, the transform
replaces the query variable "{searchTerms}" with "moon" and changes the query to "moon contenttype:picture".
You can configure query transforms in three places:
In a Web Part
In a query rule
In the result source
A user query is transformed first by the Web Part, then by any query rules that apply, and finally by the result
source. When you configure a transform in a result source, you know that the transform changes will not be
discarded or overridden, because the result source transforms the query last.
Using the Query Builder to write and test query transforms

The Query Builder helps you write and test query transforms. To build queries you use Keyword Query
Language (KQL ), and you can also add query variables. You can test the query from within the Query Builder by
setting temporary test values for the query variables, run the query and preview the search results.
For more information about building search queries and for KQL syntax examples, see Building search queries
in SharePoint 2013 (MSDN ). For an overview of all the available query variables, see Query variables in
SharePoint Server.
Transforming queries for a Web Part

You can transform queries in search Web Parts, such as the Content Search Web Part and the Search Results
Web Part. Query transforms on a Web Part can be overridden by a query rule or by a query transform on the
result source.
Query transforms in a Web Part are most often used to specify the result source that the queries should be sent
to. For example, if you want to create a search experience that is customized for searching for pictures only, you
would first create a result source with a query transform that returns only pictures. Then, you would create a
Web Part that has a query transform that changes any query run in that Web Part to use your new Pictures
result source instead of the default one.
Another common use of query transforms in Web Parts is to make changes that are specific to one Web Part.
For example, after creating the Pictures result source, you could add a Web Part with a query transform that
uses the Pictures result source and in addition restrict the search results to only show recently modified
pictures.
Transforming queries with query rules

You use query rules to try to capture the real intent behind a user query, and to return results that better match
that intent. For each query rule you can specify under which conditions the rule should be applied, and also
which actions the rule should trigger when it is applied. Most often you create query rules that apply to one site,
but you can also create query rules that apply to a site collection or to all site collections in a Search service
application.
The first step in creating a query rule is to specify the context of the rule. The minimum requirement is that you
specify which result source the query must target for the query rule to be applied. To create a rule that only
applies to people search, for example, you would specify that the context is the result source Local People
Results. Optionally, you can include a user segment or topic category in the context of a query rule.
The next step is to specify the conditions that will cause the rule to be applied. If you want the query rule to
apply to all queries, you can remove all conditions.
The following table shows the available query rule conditions.
QUERY RULE CONDITION DESCRIPTION EXAMPLE

QUERY RULE CONDITION DESCRIPTION EXAMPLE
Query matches keyword exactly Apply the query rule when the query You specify "picture; pic" as the
exactly matches a word or phrase that keywords. The query rule will apply
you specify. when users type the query "picture" or
"pic" in a search box. The rule will not
apply if a user types "pictures" or
"sunny picture".
Query contains action term Apply the query rule when the query If a query contains the phrase
contains a term in the form of a single "download", the user is probably not
word or phrase that indicates that the looking for items that contain the word
user is trying to do something. The "download", but is probably trying to
term must be at the beginning or end download something.
of the query and might be a verb, a
command, or a filter.
Query matches dictionary exactly Apply the query rule when the query
exactly matches a dictionary entry. This
entry can be a term in the term store,
or an entry in the people names
dictionary.
Query more common in source Apply the query rule if the user's query You can create a query rule that checks
is more commonly performed against a if a query is more commonly
different result source than the current performed in a Video vertical. It will
one. This condition uses an analysis of make video results more prominent if
queries that users entered in the it is.
various result sources.
Result type commonly clicked Apply the query rule if the query often If this is a query where people often
ends in users clicking results of a click the result type "pictures", it may
particular result type. When you create be appropriate to provide picture-
a new result type, you can indicate that related results in a result block.
these clicks should be recorded to be
used in query rules.
Advanced query text match Apply the query rule if the query To match all phone numbers that are
matches a regular expression. It also in the format nnn-nnn-nnnn, you
allows you to use variations of the specify the regular expression "(?
keyword, dictionary and action term (\d{3}))?-?(\d{3})-(\d{4})".
conditions explained earlier, but with
more advanced control.
The final step is to specify which actions the query rule should trigger when it is applied. Optionally, you can
specify the start and end date for a query rule to be active.
The following table shows the available query rule actions.
QUERY RULE ACTION DESCRIPTION EXAMPLE
Add promoted results Show promoted results (known as Best For the query "sick leave", you can for
Bets in earlier versions of SharePoint instance add a link to a Human
Server) above ranked results. Resources site above all ranked results.
Promoted results are best used when
an item is not indexed or if it has a
poor document summary. In other
cases, consider changing the ranking of
the results.
QUERY RULE ACTION DESCRIPTION EXAMPLE
Add result blocks Add a block of results that contains a For a query that contains "Contoso
small subset of results that are related sales report", a query rule could use a
to a query in a specific way. You can taxonomy dictionary to recognize
promote a result block, or you can "Contoso" as a customer, and then
rank it with other search results. display a result block with results
about "Contoso" from your customer
The query transform specified for the relationship management (CRM)
result block transforms a copy of the system.
original query.
You can also specify which display

template should be used to display the
result block.
Change ranked results by changing the Add a query transform that changes For a query that contains "download
query the original query. For example, the toolbox", a query rule could recognize
transform can promote or demote the word "download" as an action term
certain results. and boost search results that point to
a particular download site on your
Changing the ranking of search results, intranet.
such as boosting appropriate results
by their site or URL, is a common
alternative to adding promoted results.
Changing ranked results by changing
the query has the advantage that the
results are security trimmed and
refinable. Also, the search results will
disappear if the document is no longer
available. You can change the sorting
order of the search results dynamically,
based on several variables such as file
extension or specific keywords. You can
either promote or demote results, and
you can specify how much the results
should be promoted or demoted.
For more information, see the section

Influence the ranking of search results
with query rules in Overview of search
result ranking in SharePoint Server.
Transforming queries in result sources

For each result source, you can specify that all search results from that result source should be transformed in a
specific way. For example, the pre-configured "Local Video Results" result source uses a query transform to
return only video results from the local SharePoint index.
SharePoint Server provides a number of preconfigured result sources with predefined query transforms out-of-
the-box. You can also create new result sources and apply different query transforms on them. You can create
more than one result source per search provider, and you can set different query transforms on each result
source.
A user query is transformed first by the Web Part, then by any query rules that apply, and finally by the result
source. When you configure a transform in a result source, you know that the transform changes will not be
discarded or overridden, because the result source transforms the query last. You can re-use a result source
query transform in Web Parts or result blocks, and you can create query rules or result types that are only
applied to results from certain result sources.
Changing the way results are shown by using result types
With result types, you can conditionally change how search results are displayed. To customize the appearance
of a group of related results, you can create a display template in HTML and associate the display template with
a result type. You can create rules to specify when to show the display template, and you can prioritize these
rules.
How the search system processes a query

When someone enters a query or clicks on an element that triggers a query, the search system sends the query
to the query processing component. This component processes the query and then sends it to the appropriate
search providers to retrieve results. A search provider can be a local search index or a remote source. After the
results are collected from the search providers, the query processing component performs additional processing
and then returns the results so that they can be displayed.
The search system processes a query by doing the following:
1. Applying any Web Part transforms.
2. Applying any query rules. A query rule action can either transform the original query or it can trigger a
parallel query that is transformed for a result block.
3. Applying any query transforms on result sources.
4. Parsing the query and creating a query syntax tree for internal use.
5. Processing the query linguistically by performing word breaking, stemming, spelling correction, and
synonym expansion.
6. Appending user-access information to the query. This specifies the user who is performing the query and
the permissions that the user has.
7. Sending the query to the search index or another search provider.
8. Collecting and merging search results from all search providers and sending them back to the query
processing component.
9. Evaluating the search results against result types. If a result matches a particular result type, the result is
displayed by using the display template that you have specified for the result type.
10. Applying additional security trimming, if appropriate.
See also
Manage the Search Center in SharePoint Server
Disaster recovery best practices and strategies for
SharePoint search

Learn how to implement best practice disaster recovery for search in a SharePoint Server farm.
This article gives best practice guidance that you can use to develop a supported disaster recovery (DR ) strategy
for search in SharePoint Server. Many of the approaches used for disaster recovery in earlier versions of
SharePoint Server don't provide the same level of recovery for SharePoint Server. We examine these approaches
and provide replacement options together with the benefits and limitations that you need to know about.
Introduction
This article bridges the gap between documentation that provides a roadmap for implementing a disaster recovery
strategy and documentation that gives you the specific commands to configure disaster recovery for the
SharePoint ServerSearch Service Application (SSA). We describe several typical disaster recovery scenarios and
examine the benefits and limitations of each approach. It's unrealistic to think that these scenarios are a perfect fit
for your organization, but you can use them as a guide for a DR strategy that meets your organization's specific
requirements.
Disaster recovery for SharePoint Server and its supporting technologies is a complex topic, and there are many
sources of information dedicated to explaining the planning needed to help ensure that your business objectives
are met if there is an event that activates your disaster recovery plan.
As a best practice, we recommend that you start by clearly identifying and quantifying Recovery Time Objectives
(RTOs) and Recovery Point Objectives (RPOs) for your organization. RTO, the time that is required to recover from
a disaster, and RPO, the data measured in time that you can lose from the same disaster, are key metrics for
disaster recovery planning. These two business-driven metrics set the stage for the following:
Backup and restore procedures, media, and storage
Location where you recover to
Size and complexity of your recovery solution
You can't develop an effective recovery strategy and evaluate technical solutions without these benchmarks.
IMPORTANT
Focus on business continuity and IT recovery requirements, instead of the required steps to create a DR strategy.
Although the scope of this article is disaster recovery for SharePoint Server search, we recommend that you read
Choose a disaster recovery strategy for SharePoint Server in preparation for developing a disaster recovery
strategy.
Search service application architecture

Before looking at the different ways to develop a disaster recovery strategy, the following table provides a
description of the components in SharePoint Server search and how they contribute to the end-user search
experience. The search application components and databases described in the following table provide a context
for a disaster recovery strategy.
Search service components
COMPONENT OR DATABASE DESCRIPTION
Index component Serves as the logical representation of an index replica.
The index component includes:
Index partitions
You can divide the index into discrete portions, each holding a
separate part of the index.
The search index is the aggregation of all index partitions. An

index partition is stored in a set of files on a disk.
Index replicas
Each index partition holds one or more index replicas that

contain the same information.
Query processing component Analyzes and processes search queries and results.
Administration component Runs system processes that are required for search. There can
be more than one search administration component per
Search service application, but only one is active at a time.
Crawl component Crawls content based on what is specified in the crawl

database.
Content processing component Carries out various processes on the crawled items, such as
document parsing and property mapping.
Analytics processing component Carries out search analytics and usage analytics.
Search administration database Stores the search configuration data. There is only one search
administration database per search service application.
Crawl database Stores the crawl history and manages crawl operations.
Link database Stores some of the information extracted by the content

processing component. It also stores clickthrough information.
Analytics reporting database Stores the results of usage analytics.
There are multiple ways to distribute search components to provide a highly available and highly scalable search
topology, as shown in the following diagram. In this diagram, search components are deployed on different
application servers to provide redundancy. In addition, the application servers are deployed on different
virtualization host servers, which provides another level of fault tolerance and provides scalability.
For more information about distributing search components on farm servers, see Plan enterprise search
architecture in SharePoint Server 2016 and search technical diagrams at Search in SharePoint Server 2016.
To appreciate the complexities of developing a search disaster recovery strategy, you must understand how
documents are referenced within the Search Service Application index and databases. It is this referencing system
that currently makes it impossible to use any form of replication or log shipping technology to copy the search
indexes between SharePoint Server farms.
Overview of the Search service application index structure

Because the structure of the SharePoint Search service application index is so complex, an in-depth description is
beyond the scope of this article. In simple terms, the index consists of many small pieces that are a series of
updatable groups of data. These updatable groups can be thought of as partitions over columns in a table. By
default, there are six of these groups in the search index. These groups are as follows:
Main: contains the bulk of the fields, full text stored here.
ACLs: involves security trimming and fast security crawling.
Path and Title: contains the path and the title.
Recommendations: note that this data is updated daily.
Social Colleagues (People): involves a separate update group for people fields.
Social Tags: contains social tagging.
Think of each update group as an index structure for the fields within that group, similar in structure to a SQL
Server database. The update groups are partitioned at the storage level into files that each contains a chunk of the
index structure. Each of these files contains a different piece of the overall index. Content is distributed over these
partitions by using an identifier for each unique document. This identifier is the DocID, which is also a counter.
When a new search service application is created, the counter starts at zero. The DocID is incremented by one
every time that a new item is discovered during a crawl, and the counter continues to increase over time as new
items are discovered. The counter value is never decremented. Even if a document is deleted, its corresponding
counter value is never reused. Adding and removing documents or items from libraries and lists over time also
means that the DocID is not consecutive within any site or library. Therefore, it's impossible to predict the DocID
of any document in the search corpus.
Where this presents a challenge for any search replication strategy is the fact that in any two farms, there is no
guarantee or even the probability that the DocID values will match for any one document in the farm. Because the
DocID values won't match, it's impossible to replicate index data or analytic data that is linked to the DocID value.
Search results won't be valid because the same document will have a different DocID on each farm.
When we examine how to create a full fidelity DR strategy for the Search Service Application, it's important that
the following two things occur:
The components and databases that are storing data needed for configuration and querying are identified
and correctly restored to the target DR farm using an appropriate method.
The target DR farm is appropriately scaled with the right number of components to support the size of the
search service.
Both of these activities will be referenced in the following sections and technical details included in the
implementation sections.
Common disaster recovery techniques

In earlier versions of SharePoint, there are multiple ways to help ensure that you had a failover Search Service
Application populated with up-to-date indexes and near 100 percent search freshness. The following examples
show approaches that were typically used for disaster recovery.
Crawling read-only content databases was an option, where SQL Server Log shipping methods were used
to maintain a copy of the production content databases attached to the DR farm in read-only mode. This
means that an SSA hosted on the DR farm could be configured to crawl the databases via a read-only web
application on the DR farm. Any configuration changes had to be implemented at the SSA level on both
farms to help ensure a full fidelity experience for end users in the event of a failover.
With the dual-crawl option, the recovery farm also crawls the production farm, and therefore the same
content was discovered and indexed. Configuration changes to managed properties or crawled file types,
installed IFilters, and so on had to be implemented in both production and DR farms, but this was easily
managed by using a suitable change control policy.
Other options for disaster recovery strategies did not offer the same level of search index freshness, but if index
freshness or the time to recover was not mission critical, then they are valid options. Typically, these options are
more complex to configure and implement. The following examples are typical of approaches.
The SSA Search Administration database could be backed up independently. The SSA Search
Administration database is backed up independently using conventional SQL Server backup approaches
and used on the DR farm to create a SSA using Microsoft PowerShell. This restores the search
configuration but not the indexes. A full crawl is needed to populate the search indexes and complete the
recovery.
A full SSA backup and restore. A full SSA backup and restore is performed using Microsoft PowerShell
or using the the SharePoint Central Administration website interface. This backs up the SSA databases and
search indexes, which enables them to be restored on the DR farm to populate the SSA on that farm.
Starting with SharePoint Server 2013, significant changes in the search architecture and how configuration
elements are stored means we have to think differently about search disaster recovery. The following sections
describe these changes and how they affect the disaster recovery choices that are available.
Configuration and functional changes to the search experience
The Site Administration pages in SharePoint Server provide options that support a flexible configuration of the
search experience. The new configuration options for sites and site collections means that site administrators can
make search configuration changes that previously could only be made by farm or search administrators. The next
screen capture shows the two locations where you can configure search options—under Site Collection
Administration or under Search.
You can make a configuration change to a search item, such as Query Rules or Result Sources, from the list under
Site Collection Administration or Search, and the result will be the same. However, the location where a change is
stored directly affects disaster recovery. All of the changes made in a site collection or a web application, the
change will only be stored in the Search Service Application (SSA) administration database. Unless this database is
restored from a backup to the disaster recovery farm, then configuration changes won't be available in the
recovered environment.
Another new feature in SharePoint Server Search is the ReIndex Now capability that allows administrators at the
Site Collection, Web, and List levels to request a reindex of the container during the next crawl. This feature is
managed completely within the content database, and therefore an administrator requesting this within the DR
farm will trigger the same event in the Production farm when the next crawl runs on the DR farm.
Search analytics-driven user recommendations
In SharePoint Server Search the processing of search and usage analytics is handled by a component called the
Analytics processor. This component has the following responsibilities:
Handles the processing of Search Analytic information
Processes usage analytics
Provides relational information that the content processor uses to support the search recommendations
feature
Provides statistical information about document popularity (for example, page visits and clicks) that the
content processor uses to improve relevancy and ranking calculations
To read more on the individual analytics processes, see Overview of analytics processing in SharePoint Server for
detailed information.
The processed information is stored in the Search Index and also by the Reporting and Links databases. Therefore,
the only method capable of making sure that this processed information is replicated to the DR farm in a
synchronized state is a full Search Service Application backup and restore.
Service application backup and restore improvements
The approach that satisfies all of the DR requirements for capturing configuration and index data is service
application backup and restore. These operations were invested in significantly to reduce the RTO and RPO
compared to earlier versions of SharePoint. Support for changing the number of threads used in the backup and
restore processes plus improvements in supporting both full and differential backup and restore operations are all
key gains in this area.
When adopting the approach of a full Search service application backup and restore as the DR strategy, overall
RPO is governed by two things. The time since the last full service application backup is the RPO, and the time that
is required to actually carry out a service application restore is the RTO. Both of these times are likely to increase in
duration as the indexed content in the Search service application increases, so careful management of the
expectation for service restoration in the event of a disaster being declared is needed. We recommended
conducting frequent test restores as part of your service continuity management exercises to make sure that any
SLA against required RTO and RPO can still be met. The following table summarizes the backup and restore
options for the Search service application.
OPTION LIMITATIONS
Crawl the read-only databases in the DR farm. No site collection or web level search configuration changes
are replicated to the DR farm.
Performa dual-crawl production farm. No site collection or web-level search configuration changes
are replicated to the DR farm.
Analytics-driven search index updates are not replicated to the

DR farm.
Restore the Search Administration database on the DR farm Analytics-driven search index updates are not restored to the
and re-create the service. DR farm. This is because the index will be empty when the
service application is created, and a full crawl will be needed.
Do a full SSA backup and restore. No limitations on search index fidelity but restoring a large
service application may take serveral hours and impact the
RTO during a failover.
Supported techniques for recovery

There is only one supported disaster recovery technique that will provide a full fidelity recovery, including all
analytics processing improvements to the search index and all search configuration items at the Service
Application, Site Collection, and web levels within the production farm. This approach requires a full backup of the
Search service application followed by a full restore of the service application to the DR farm. The indexes and
configuration will be restored to the same point in time that the backup was taken, so if the backup was several
days old, a new crawl will be required to bring the indexes up to date. The specific steps for this approach are
described later in the paper.
It is also supported to take a backup of the Search service application administration database and restore that in
the DR site. By using Microsoft PowerShell, administrators can create a new Search service application by using
the backup. However, this will only recover the actual configuration of the search service application and any
customized search settings within the SharePoint sites and webs—it won't recover the search index. A full crawl
will be required to populate the corpus for searching. In addition, it can't recover the analytical augmentation of the
search indexes because the signals used to generate that are only resident on the production farm.
There is another approach that might be employed if the main purpose of having to include search in the DR
strategy is to help guarantee search index freshness at failover time. By using one of two methods, the index can be
maintained in a very fresh state but with the introduction of complex configuration and several limitations. The
complexity comes in because either the crawlers in the DR farm have to be configured to crawl the production
farm or the content databases have to be replicated in a readable state to the DR farm to support local crawling.
This approach has limitations in that the configuration of the Search service application in production is not
replicated in any way to DR, and search index updates from the processing of analytic data is also missing. If these
limitations are acceptable, then this is a very flexible way to help guarantee high index freshness and search
availability in the DR farm.
A final approach is to actually combine the two techniques described earlier into a single strategy that provides
high search index freshness on failover but adds the possibility of also performing a full restore to bring the
analytics information and search configuration over to the DR farm.
In this case, both a full backup and remote or local crawling would be employed and a process for the restore made
available if it is needed. A typical reason to start the full restore process is if the failover to the DR site is more than
a temporary interruption to normal service and failing back to production isn't possible in an agreed time period.
In that case, the restore process would be invoked to help ensure that the full fidelity search experience was
available in the DR site. A new crawl would then be initiated to bring the search index up to full freshness.
There are implications to consider when restoring a Search service application that uses the overwrite option. The
service application will be offline during the restore, which means no updates or queries will be processed. For a
business where search is not a critical function, this is likely not to be a problem. But if search query functionality
must be available during the restore, then another option can be considered. The alternative option is to always
create a new Search service application during the restore process, and when the restore is complete, run a new
crawl to get the index freshness up to date. After the crawl finishes, switch the service application association to the
new service application and carry on working without interruption. The older service application could then be
deleted. The biggest challenge is one of capacity in that basically double the index and database space would be
required to host two service applications in parallel. The criticality of search services will dictate whether this is
something that the business must accommodate.
With all these things considered, it is worth investigating the expected RPO and RTO requirements of the Search
service application. Currently, Office 365 SharePoint supports an RPO and RTO of one week for the search service
application. If you consider what this means, it implies that configuration items, analytics processed information,
and search freshness could all be a maximum of one week out of date when a restore is performed. Once again,
depending on the expected rate of change in the environment and the criticality of the search setup, it may be
prudent to run daily or even subdaily backups to help make sure that an optimal RPO and RTO can be achieved for
the business. There is no requirement to maintain multiple backup copies as you would do with content backups
because the search content is very fluid and transient, so at most one or two full backups would be retained.
Service application backup and restore
The following information is a brief summary of the key points contained in the Search Backup and Restore
articles:
Back up Search service applications in SharePoint Server
Restore Search service applications in SharePoint Server
The frequency at which search service backups must be taken will be influenced by many things, but primarily the
RPO required by the business will be the key driver. As the search index becomes larger, the time taken to both
back up and restore the service application will get longer and longer. Only one search backup can occur at a time,
and the time for the backup to complete is the minimum RPO that can be achieved. The duration for the restore to
complete on the DR farm is therefore the minimum RTO that can be achieved, and like backup time, this will
extend over time. If the backup or restore times begin to encroach on the required service level agreements (SLAs)
for search RPO and RTO, then the business must make some decisions on following a more flexible if lesser fidelity
approach, as described here later, or adjusting the SLAs to meet an achievable target.
Backing up the search service application
To back up the search service application, you can use either Microsoft PowerShell or the Central Administration
User Interface. The PowerShell cmdlet required is as follows:
Backup-SPFarm -Directory <Backup Folder> - BackupMethod <Full | Differential> -Item <Full Path to Search Service
Application>
Here's an example:
Backup-SPFarm -Directory \\server\searchbackup - BackupMethod Full -Item "Farm\Shared Services\Shared Services
Applications\Contoso Search Service Application"
This example will take a full backup of the Search service application named Contoso Search Service Application
and store the backup files in the location \server\searchbackup.
NOTE
The BackupMethod switch will only apply to the search databases. In all cases, the search indexes are fully backed up
regardless of the option chosen.
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 might 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 for storing the backup file.
Restoring the search service application
To restore a SharePoint Server Search service application, the backup must have completed successfully, and if
backups are taken frequently, then the ID of the specific backup to be restored is needed. This ID can be easily
obtained in several ways. The simplest is to open the Backup and Restore History page on the production farm
where the backup was taken and enter the Backup Directory Location. This provides a list of all the entries in the
backup and restore manifest file (psbrtoc.xml). In the following screen shot, a backup ID of {149fc816-8927-4a32-
9437-6e05c2869ab7} can be easily seen.
The alternative to using the backup and restore history page is to directly open the backup and restore manifest
and examine it for the desired entry. Because the size of this file will grow with every backup and restore
performed, examining this file may not be the optimum approach—especially if there is a high frequency of backup
and restore operations.
The following example shows typical entries in spbrtoc.xml, and you can see that the backup ID can easily be
identified.
<?xml version="1.0" encoding="utf-8"?>

<SPBackupRestoreHistory>
<SPHistoryObject>
<SPId>149fc816-8927-4a32-9437-6e05c2869ab7</SPId>
<SPRequestedBy>REDMOND\pkmacct</SPRequestedBy>
<SPBackupMethod>Full</SPBackupMethod>
<SPRestoreMethod>None</SPRestoreMethod>
<SPStartTime>01/11/2016 02:30:27</SPStartTime>
<SPFinishTime>01/11/2016 02:38:48</SPFinishTime>
<SPIsBackup>True</SPIsBackup>
<SPConfigurationOnly>False</SPConfigurationOnly>
<SPBackupDirectory>\\server\backups\spbr0000\</SPBackupDirectory>
<SPDirectoryName>spbr0000</SPDirectoryName>
<SPDirectoryNumber>0</SPDirectoryNumber>
<SPTopComponent>Farm\Shared Services\Shared Services Applications\Search Service Application
Prod</SPTopComponent>
<SPTopComponentId>013aa694-673d-46d1-9313-fbba6df691e7</SPTopComponentId>
<SPWarningCount>0</SPWarningCount>
<SPErrorCount>0</SPErrorCount>
</SPHistoryObject>
</SPBackupRestoreHistory>
Another available method is to use the Get-SPBackupHistory cmdlet, which can also provide the same information
as the spbrtoc.xml file.
The next two examples show how to perform the restore operation using the Restore-SPFarm cmdlet.
Restore-SPFarm -Directory <BackupFolder> -Item "<ServiceApplicationName>" -RestoreMethod Overwrite [-BackupId
<GUID>]
Restore-SPFarm -Directory \\server\searchbackup - Item "Farm\Shared Services\Shared Services
Applications\Contoso Search Service Application" -RestoreMethod New -BackupID "149fc816-8927-4a32-9437-
6e05c2869ab7"
NOTE
If no backup ID is provided, then the most recent available backup from the directory is used.
The RestoreMethod you use determines how the process will flow after it runs the Restore-SPFarm cmdlet.
If the new option is chosen, then the administrator running the cmdlet is prompted to provide a location on the
new farm for each component and database in the backup. This can be especially useful if the server farm topology
and naming convention in the DR farm does not exactly match production, which is a frequently encountered
scenario. If the Search service application is being restored to a farm that was built with matching names and
server topology, then the overwrite option can be used. Typically this option is only used when restoring to the
same farm that is the source of the backup.
NOTE
To use the overwrite option, there has to have been at least one restore using the new option. If this is not the case, an
existing Search service application that uses identical configuration and naming must be available on the DR farm.
When restoring a search service application, it will be automatically paused during and after the restore. To resume
the service application after the restore finishes, use the following PowerShell command.
$ssa = Get-SPEnterpriseSearchServiceApplication <SearchServiceApplicationName> $ssa.ForceResume($ssa.IsPaused())
Also of particular note to the administrator is the process that is used to restore a Search service application that
has multiple replicas per partition. The restore process will only restore to one of the replicas within each partition,
and a background task will handle the replication of the partition information to all other replicas for each partition.
Search indexing and querying is online and functional during this process, but the administration pages for the
Search service application may well show the replicas as degraded until this operation is complete.
Combined disaster recovery approach
As already mentioned, with service application backup and restore being the only supported approach to
maintaining a full fidelity DR solution, it becomes especially challenging to achieve a low RPO/RTO for search.
Time to back up and time to restore can become extended over time as the indexed corpus becomes larger. This
could lead to a much longer than desired RPO and RTO.
One approach that can be employed to overcome the challenges of achieving low RPO/RTO is to adopt a two-
pronged approach to the solution. The following list shows this solution:
Use crawling of read-only content databases, or dual-crawl the production site to maintain an acceptable
level of search index freshness in the DR farm.
Take Search service application backups, and either periodically restore them to the DR farm or have them
available in case the primary site is not recoverable.
If crawling read-only databases in the DR farm is the preferred choice, then you must consider the fact that
changes in the production farm won't be replicated to the recovery farm. As we mentioned, this includes the search
service analytics updates to the index and changes to configuration items such as result sources, query rules, and
schema modifications. If you adopt a combined approach, then it's very important to understand all the
implications and put in place a suitable strategy. Currently, there is no supported way to circumvent the loss of the
analytics updates, but steps can be taken to work around updates to configuration changes. You could try actions
similar to the following examples.
Ensure that all custom result sources, query rules, and search schema changes regarded as business critical are
made at the search service application level in Central Administration and not within site collections or subsites.
For example, consider a corporate intranet portal that has a dependency on specific query rules to manage the
content on the home page. These rules would be created on the production farm and manually replicated to the
DR farm to help make sure that this configuration is available. Similarly, custom mappings of crawled properties to
managed properties must be implemented at the service application level in both farms.
It is possible to capture the site-level and web-level search configuration items and export them to an XML file by
using PowerShell. For example, the next PowerShell example will export configuration items from the site
"http://intranet.contoso.com" to an XML file that is named intranetcontosocom.xml. This approach was published
to the SharePoint community and is used with their permission. You can view this blog post at Importing and
Exporting Search Configuration Settings in SharePoint 2013
Add-PSSnapin Microsoft.SharePoint.PowerShell-ea 0
[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client") | Out-Null
[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.search") | Out-Null
$context = New-Object Microsoft.SharePoint.Client.ClientContext("http://intranet.contoso.com")
$searchConfigurationPortability = New-Object
Microsoft.SharePoint.Client.Search.Portability.searchconfigurationportability($context)
$owner = New-Object Microsoft.SharePoint.Client.Search.Administration.searchobjectowner($context,"SPSite")
$value = $searchConfigurationPortability.ExportSearchConfiguration($owner)
$context.ExecuteQuery()
[xml]$schema = $value.Value
$schema.OuterXml | Out-File intranetcontosocom.xml -Encoding UTF8
NOTE
In the previous example, we export the configuration from SPSite. You can use the SearchObjectLevel enumeration to
obtain these settings: SSA, SPSiteSubscription, SPSite, and SPWeb.
The next example shows how to import the settings that you obtain from another environment.
[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client") | Out-Null
[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.search") | Out-Null
$context = New-Object Microsoft.SharePoint.Client.ClientContext("http://dr.contoso.com")
$searchConfigurationPortability = New-Object
Microsoft.SharePoint.Client.Search.Portability.searchconfigurationportability($context)
$owner = New-Object Microsoft.SharePoint.Client.Search.Administration.searchobjectowner($context,"SPSite")
[xml]$schema = gc .\schema.xml
$searchConfigurationPortability.ImportSearchConfiguration($owner,$schema.OuterXml)
$context.ExecuteQuery()
You can customize these examples to develop a search configuration export/import process that supports your
requirements for a combined disaster recovery solution.
When crawling read-only content databases in the DR farm, the site map table in the SharePoint configuration
database will not be updated to register newly created sites in the production farm. This means that those sites plus
the content within them will not be indexed during full or incremental crawls. To overcome this, it is important to
periodically run the following PowerShell command that will refresh the site map on the DR farm for all content
databases on the given web application.
Get-SPContentDatabase -WebApplication https://intranet.contoso.com | %
{$_.refreshsitesinconfigurationdatabase()}
By crawling the read-only databases and updating the site map periodically, a high level of index freshness can be
maintained in the DR farm. The second stage of the combined approach is what to do with the Search service
application backups. There are two real choices here, shown in the following list but note that the selected choice
will depend on the needs of the business.
If the business can operate successfully and meet its primary functions without having full fidelity search—
that is, the core configuration elements in the search admin service application and the ability to maintain a
high search index freshness allow the business to function in the DR site—then they may never restore the
service application into DR. Restoring the search service application may only be required if it becomes
clear that the primary site will not be available for a long time. This means that a failback to the primary site
is not possible, and therefore restoring the search service application fully is needed to bring all business
functions that depend on search back online. A specific time period could be selected to trigger the restore.
If there will be a requirement to maintain as much full fidelity search as possible at the DR site if there is
failover, then periodic backup and restore processes could be performed. Possible scenarios are daily or
weekly backup and restore procedures that are used together with read-only database crawling to maintain
freshness as close as possible to 100 percent. The problem is when the search index is so large that it takes
many hours to complete the restore, therefore introducing some risk to the RTO/RPO objectives.
This combined approach is clearly more complex than a simple backup and restore, but the benefits outweigh the
challenges if the business needs meet the requirements to implement such a solution.
Additional resources
For additional information, we recommend that you use the following resources.
In addition to the options that are provided in these articles and in this paper, there are other methods that you can
use to back up and restore the search service application in SharePoint Server. These methods are more fine
grained and involve independently restoring the search indexes and search databases to a new farm. We haven't
covered these steps, but if you are considering a scripted approach, we recommend that you start by reviewing the
following resources.
Get-SPEnterpriseSearchServiceApplicationBackupStore
Restore-SPEnterpriseSearchServiceApplication
Restore-SPEnterpriseSearchServiceApplicationIndex
Back up and restore a search service application in SharePoint 2013 using VSS . .
Overview of search result ranking in SharePoint
Server

The search engine calculates the relevance rank, that is to say, the order in which the search results for a query
appear. The ranking model is at the core of this calculation. In most cases, you can influence relevance by using
the available SharePoint Server ranking models in combination with query rules without having to consider
customizing any ranking models.
What is a ranking model?

There are several ranking models in SharePoint Server that are optimized for specific cases. These ranking
models provide an effective ranking of results without any further customization. A ranking model contains a
collection of ranking features to calculate the rank score of a particular item, for example a document, in the
search results. The type of content that is ranked determines the set of ranking features that the ranking model
uses and the relative importance of these different ranking features.
In the classic search experience, for the default search verticals Everything, Videos, Conversations and People,
the search system uses the most appropriate ranking model automatically. If you create your own search vertical,
you can configure which ranking model to use for that vertical.
SharePoint Server provides the following types of ranking models:
General purpose ranking models.
General purpose ranking models compute the relevance rank for most types of search results.
People search ranking models.
People search ranking models compute the relevance rank for search results that are related to people.
They calculate, among other things, how relevant search results are based on social distance and expertise.
Special purpose ranking models.
Special purpose ranking models compute the relevance rank for search results related to various specific
ranking scenarios. For example, there is a ranking model to calculate the ranking score for
recommendations and there are ranking models to calculate relevance ranks for cross-site publishing sites
that have an associated product catalog.
The following table lists the available ranking models in SharePoint Server.
RANKING MODEL TYPE RANKING MODEL NAME DESCRIPTION
General purpose Default Search Model Default ranking model for the Search
service application. This ranking model
ranks most search results, such as the
search results for queries on the result
source "Local SharePoint Results". This
model is used for the search verticals
Everything, Videos and
Conversations.
General purpose Search Ranking Model with Two Linear This ranking model is a copy of the
Stages Default Search Model with the
exception that stage two is a linear
stage instead of a neural net stage. We
recommend that you use a copy of this
model as the base model if you want to
create a custom ranking model.
General purpose O15 MainResultsDefaultRankingModel Ranking model that was used as the
default ranking model for the Search
service application before the
SharePoint Server 2013 cumulative
update of August 2013. The cumulative
update introduces some improvements
to the Default Search Model. This
ranking model was added for backward
compatibility.
General purpose O14 Default Search Model Ranking model that was used as the
default ranking model for the Search
service application in SharePoint Server
2010 and Search Server 2010. This
ranking model was added for backward
compatibility.
General purpose Search Model With Boosted Minspan Ranking model that puts a higher
weight on proximity features than the
Default Search Model. Proximity
features in the ranking model look at
each of the query terms and determine
how close to one another these query
terms occur in the items. Proximity is
only considered in the managed
properties Body and Title.
General purpose Search Model Without Minspan Default Search Model without proximity
features.
People search People Search application ranking Default ranking model for people
model search. This ranking model ranks search
results for people. People search is
based on user profile information from
My Sites that are kept in the User
Profile service application.
People search People Search expertise ranking model Ranking model for people search that
puts a higher weight on expertise.
Expertise is calculated based on how
few levels the person is from the top
position within an organization.
People search People Search expertise social distance Ranking model for people search based
ranking model on expertise with a higher weight on
social distance. Social distance is the
relationship, as defined by their
position in the organization, between
the user who typed the query and the
people who are listed in the search
results.
People search People Search name ranking model Ranking model for people name search.
People search People Search name social distance Ranking model for people name search
ranking model that puts a higher weight on social
distance.
People search People Search social distance model Ranking model for people search that
puts a higher weight on social distance.
Special purpose Catalog ranking model Ranking model for internet facing
websites. This ranking model ranks
search results for websites that use
cross-site publishing and that have a
product catalog associated with the
SharePoint Server site collection.
Special purpose Popularity ranking model Ranking model for popularity based
search. This ranking model ranks
SharePoint Server content based on the
number of times an item that is stored
in SharePoint Server has been accessed.
Special purpose Recommender ranking model Ranking model to rank

recommendations. Recommendations
are based on item-to-item relationships
collected from an analysis of how users
have interacted with items on a site or
with search results.
Special purpose Site suggestion ranking model Ranking model for social suggestions.
Items that other users have clicked will
get a higher ranking.
How does a search result get a rank?

A ranking model computes the relevance rank of a search result. A search result gets a rank through a process
called rank evaluation. The rank evaluation results in a ranking score. Items with the highest score get the
highest position in search results. Search results are sorted in descending order based on their ranking score.
For example, the default search model uses two stages for rank evaluation. During stage one, the ranking model
applies fairly inexpensive ranking features to get a gross ranking of the results. During stage two, the ranking
model applies additional and more expensive rank features to the items with the highest rank. By default, the
search results page shows the ten documents that have the highest ranking score after these two stages of rank
evaluation.
Each ranking model has several ranking features. The relative weight of these ranking features in the overall
ranking calculation varies per ranking model. Ranking features can be query dependent or query independent. To
calculate the final ranking score of a search result, all the calculations of all the ranking features in the ranking
model are combined.
Ranking models use information from the search index, as explained in the following table.
INFORMATION ABOUT A SEARCH INDEX ITEM DESCRIPTION
Content These are the words contained in the items. For items that are
text based, such as documents, this is typically most of the
text. For other types of items, such as videos, there is little or
no content.
Metadata The metadata associated with items such as title, author, URL
and creation date. Metadata is automatically extracted from
most types of items.
Web graph data This is information such as authority (from authoritative

pages settings) and anchor text (from the hyperlinks
associated with the item, and items linking to the item).
File type Some file types can be considered more important for ranking
than others. For example, Word and PowerPoint results are
typically more important than Excel results.
Interaction Information about the number of times a search result is

clicked, and which queries led to a result being clicked.
How can I influence the rank of a search result?

You can influence the ranking of search results in the following ways:
Query rules: define which actions to take when a query matches a condition.
Query rules apply to classic search results, with one exception. Learn what's different for modern search.
Promote particular results to the top of the search results.
Add a result block to promote particular results.
Change the rank by changing the query.
Change the sorting of the ranked results based on managed properties.
Dynamically promote or demote particular results.
Change the ranking model when someone runs a certain query.
See the section Influence the ranking of search results with query rules for more information.
Search schema: configure the context of a managed property.
Change the context of a managed property in Advanced Searchable Settings.
See the section Influence the ranking of search results by using the search schema for more information.
Create and use a custom ranking model.
Custom ranking models only apply to the classic search experience.
Customize a copy of an existing ranking model, deploy it and use this custom model to rank search results.
See the section Influence the ranking of search results by using a custom ranking model for more
information.
In most cases, using the available ranking models in SharePoint Server in combination with query rules should
provide sufficient ways to influence ranking.
Influence the ranking of search results with query rules

If you are not satisfied with the search result ranking for specific queries, we recommend that you try to influence
the ranking for those queries with query rules. In most cases, configuring query rules will help you reach your
goals, and you won't have to consider changing the context of a managed property or creating a custom ranking
model.
For each query rule, you can influence the way you sort, rank and display search results. Each query rule consists
of a query rule condition and a query rule action. Whenever a query matches a query rule condition, the query
rule action that you specify in the query rule triggers.
You can specify the following query rule actions for a query rule:
Add promoted results on top of the ranked search results.
When you add a promoted result, you show this result above the ranked results. For example, for the query
"sick leave", you can add a link to a Human Resources site above all ranked results.
Add a result block.
A result block displays search results as a group. You can configure the query rule to define for which
queries you want to show the results in a result block. In the same manner as you can promote a specific
result, you can promote a result block when a specified query condition applies.
Change the rank by changing the query.
Sort by managed property.
You can change the sorting order of the search results by specifying by which managed property the
search results should be sorted, and if this should be done in ascending or descending order. You
can add more than one sort level. If you sort by one or more managed properties, you do not use a
ranking model to rank the search results.
Dynamic ordering: promote or demote search results.
You can dynamically change the ranking of search results. You can specify when you want to change
the ranking of the search results for a query, and by how much, when a certain condition applies.
The table below shows the conditions that you can set.
Change the ranking model.
You can change which ranking model is used when a query rule fires.
CHANGE RANKING WHEN: DESCRIPTION
Result contains keyword Matches if the result contains the keywords anywhere in its
contents, including meta-data.
Title contains keyword Matches if the result title contains the specified keywords or
phrases.
CHANGE RANKING WHEN: DESCRIPTION
Title matches keyword Matches if the result title exactly matches the specified
keywords or phrases.
URL starts with Matches if the result URL starts with the specified URL.
URL exactly matches Matches if the result URL exactly matches the specified URL.
Content type is Matches if the result is of the content type that you specify.
File extension matches Matches if the result has the specified file extension.
Result has the tag Matches if the result has the specified taxonomy tag as part
of its meta-data.
Manual condition Add any restriction using standard query syntax.
For more information, see Plan to transform queries and order results in SharePoint Server and Manage query
rules in SharePoint Server.
Influence the ranking of search results by using the search schema

You can influence the ranking of search results by changing the context of a searchable managed property in a
full-text index. However, most managed properties are already mapped to a suitable context and full-text index by
default. We do not recommend changing the context of any of the existing searchable managed properties.
However, if you create a new managed property and you want this property to be considered by the ranking
models, you have to map it to a full-text index context.
SharePoint Server has several full-text indexes. Each full-text index has several managed properties that are
stored in that full-text index. In this section, we only discuss the default full-text index and only a few of the default
full-text index contexts in combination with the default search ranking model.
A full-text index contains all the text from the searchable managed properties that are stored in that full-text index.
Each full-text index is divided into weight groups, also referred to as contexts. The different contexts relate to the
relative importance of a managed property, which is one of the ranking features that are used to calculate the
total relevance rank. The number, or ID, of a context is not important; the ranking model determines its relative
importance by assigning a contribution weight to a particular context. A higher contribution weight results in a
higher ranking score.
By default, new managed properties are mapped to context 0, which means that they are returned in the search
results but are not considered by any of the ranking models. If you want a new managed property to be
considered by the default search ranking model, you should map it to the default full-text index and to one of the
contexts shown in the table below. There are more contexts in the default full-text index, but you should only use
the contexts mentioned in the following table. Each ranking model considers the contexts differently; the table
only shows how the Default Search Model considers contexts in the default full-text index.
RELATIVE CONTRIBUTION WEIGHT TO

EXAMPLE OF A MANAGED PROPERTY IN RANKING (DEFAULT SEARCH MODEL AND
CONTEX T THIS CONTEX T DEFAULT FULL-TEX T INDEX)
0 - Used only for recall, not for ranking.
1 Title 0.3610
RELATIVE CONTRIBUTION WEIGHT TO
EXAMPLE OF A MANAGED PROPERTY IN RANKING (DEFAULT SEARCH MODEL AND
CONTEX T THIS CONTEX T DEFAULT FULL-TEX T INDEX)
2 Filename 0.1512
5 Author 0.1581
7 Body 0.0194
For example, you create a new managed property of the type string that contains about ten words or less. You
consider this new managed property to be about as important as the existing managed property Title. In that
case, you should map the new managed property to context 1.
Another example. You create a managed property of the type string that contains lots of words, for example a
description of something. You should map this new managed property to context 7 because it is similar to the
managed property Body, both in length as well as in importance.
IMPORTANT
Map managed properties with similar importance and size (in words) to the same context.
After changing the context of a managed property, it is important to monitor the search results, as the change
may not have the expected or desired consequences. It will take some time before the changes appear in the
search results, because the content has to be re-indexed before changes to the search schema are picked up. If
you have already crawled one or more content sources that include content that contains the managed property
that you changed the context of, you have to do a full re-crawl of those content sources before you can see any
changes in the ranking.
You can change the context of a searchable managed property in the Advanced Searchable Settings, using the
search schema feature in the Search service application. See Overview of the search schema in SharePoint Server
and Manage the search schema in SharePoint Server for more information.
Influence the ranking of search results by using a custom ranking

model
The most advanced way to change the ranking of search results is to create a custom ranking model. In most
cases, the ranking models that SharePoint Server supplies provide good ranking, and you can influence this
ranking with query rules as discussed in Influence the ranking of search results with query rules
Examples of when you may want to create and use a custom ranking model:
You have created a search experience in which query performance is extremely important and you want to
make the ranking model calculations faster.
You have built a custom app and want to create a ranking model that is specific to that app.
You have added a special managed property for a special search experience and want to include this
managed property in the ranking calculations.
Cau t i on
If you create a custom ranking model, this influences all the queries using that ranking model. You should test the
effect of the custom ranking model on many queries.
You can read more about how to create, deploy and use a custom ranking model in the article Customizing
ranking models to improve relevance in SharePoint 2013 on MSDN.
NOTE
If you want to create a custom ranking model for the default search results, use a copy of the Search Ranking Model with
Two Linear Stages as the base model for your custom ranking model, it will be easier to re-tune and customize your
ranking model.
See also
Plan to transform queries and order results in SharePoint Server
Overview of the search schema in SharePoint Server
Create a custom ranking model by using the Ranking Model Tuning App
Overview of analytics processing in SharePoint
Server

To help identify and surface the content that users consider to be the most useful and relevant, the Analytics
Processing Component in SharePoint Server analyzes both the content itself, and also the way that users
interact with it. The results from the analysis are added to the items in the search index so that search relevance
improves automatically over time. Also, the results are used in reports that help search administrators see which
manual steps they can take to improve the search system.
The analytics architecture

The analytics architecture consists of these main parts:
The Analytics Processing Component runs the analytics jobs. For more information, see The different
types of analyses.
The Analytics reporting database stores statistical information, such as usage event counts, from the
different analyses. SharePoint Server uses the information in this database to create Excel reports for the
search administrators. For more information, see Usage analytics and Reports based on analytics
processing.
The Link database stores information about searches and crawled documents. The data in this database is
processed in different sub-analyses. For more information, see Search analytics.
The different types of analyses

The Analytics Processing Component runs two main types of analyses: Search analytics and Usage analytics.
Search analytics analyzes content in the search index, and usage analytics analyzes the user actions.
Search analytics analyzes content that is being crawled and added to the search index.
Usage analytics analyzes user actions, or usage events, such as clicks or viewed items, on the SharePoint
Server site.
Search analytics
Search analytics is a set of analyses that extracts information such as links and anchor text from content as it is
being crawled and processed and stored in the search index. The extracted information is stored in the Link
database together with information about clicks on search results. The information in the Link database is further
processed in several sub-analyses.
Information that results from the search analyses is used to enrich items in the search index with information to
help improve relevance and recall, and is stored in the Reporting database and included in reports.
Analyses in search analytics
ANALYSIS DESCRIPTION
Anchor text processing Anchor text processing analyzes how items in the content
corpus are interlinked. It also includes the anchor texts
associated with the links in the analysis. The Analytics
Processing Component uses the results of the analysis to add
rank points to the items in the search index.
Click Distance The Click Distance analysis calculates the number of clicks
between an authoritative page and the items in the search
index. An authoritative page can be a top level site, for
example http://www.contoso.com, or other pages that are
viewed as important. You can define Authorative pages in
Central Administration.
The Analytics Processing Component uses the results of the

analysis to add rank points to the items in the search index.
Search Clicks The Search Clicks analysis uses information about which items
users click in search results to boost or demote items in the
search index. The analysis calculates a new ranking of items
compared to the base relevance.
The clicks data is stored in the Link database.
Social Tags The Social Tags analysis analyses social tags, which are words
or phrases that users can apply to content to categorize
information in ways that are meaningful to them.
In SharePoint Server, social tags are not used for refinement,

ranking, or recall by default. However, you can create custom
search experiences that use social tags and the information
from this analysis.
Social Distance The Social Distance analysis calculates the relationship

between users who use the Follow person feature. The
analysis calculates first and second level Followings: first level
Followings first, and then Followings of Following.
The information is used to sort People Search results by social

distance.
Search Reports The Search Reports analysis aggregates data and stores the
data in the Analytics reporting database where it's used to
generate these search reports:
Number of queries
Top queries
Abandoned queries
No result queries
Query rule usage
The report information is saved in the Search service

application, and not with the items in the search index. If you
delete the Search service application, the report information
is also deleted.
Deep Links The Deep Links analysis uses information about what people
actually click in the search results to calculate what the most
important sub-pages on a site are. These pages are displayed
in the search results as important shortcuts for the site, and
users can access the relevant sub-pages directly from the
search results.
Usage analytics
Usage analytics is a set of analyses that receive information about user actions, or usage events, such as clicks or
viewed items, on the SharePoint Server site. Usage analytics combines this information with information about
crawled content from the Search analyses, and processes the information. Information about recommendations
and usage events is added to the search index. Statistics on the different usage events is added to the search index
and sent to the Analytics reporting database.
A default set of usage events is defined out of the box. The default events are always registered and analyzed by
SharePoint Server. You can also configure custom event types. For more information about the default usage
events, see The usage events used by Usage analytics.
Analyses in usage analytics
Usage counts The Usage counts analysis analyzes events, such as viewed or
clicked items. The analysis calculates how many times an item
is opened overall , not just from the search result page, but
also, for example, when a document is opened from Word or
clicked in a SharePoint Server library.
The analysis calculates both recent events and all time events,
for all defined event types. By default, recent events is set to
the last 14 days, but you can set it between 1 and 14 days
(on-premises). The statistics data is aggregated on site level,
on site collection level, and on tenant level (SPO).
The usage events are stored temporarily on the web front

end and are pushed to the Search Service Application every
15 minutes. Usage events are kept on disk for up to 14 days
before they are deleted. Every day, the previous full day of
Usage counts data is analyzed.
Usage counts are added to the items in the search index to

improve search relevancy. The information is also stored in
the Analytics reporting database, and can be used to display
popular items on a site.
Recommendations The Recommendations analysis creates recommendations

between items based on how users have interacted with the
items on a site. The analysis uses the same event file as Usage
counts, but looks for patterns in the usage. The analysis
calculates an item-to-item relationship graph and adds the
information to the items in the search index.
The information can be used to display recommendations on

a site, for example "People who viewed this also viewed".
The data is stored in the Analytics reporting database for

recovery purposes. Reports related to recommendations are
based on the Usage counts analysis.
Activity ranking The Activity ranking analysis uses the activity tracking of
usage events (the event rate) to influence search relevancy.
Items that have high usage activity (clicks or views) typically
get a higher activity rank score than less popular items.
The analysis looks for trends in item activity. If you only count
the number of events, older items will typically "win" in
relevancy, because the older documents have had more time
to collect activity. The activity tracking helps newer
documents that have high usage activity get a higher rank.
The usage events used by Usage analytics

SharePoint Server includes the following default usage events:
Views
Recommendations displayed
Recommendations clicked
In addition to the default events, you can add up to twelve custom events. For example, you can add a custom
event that tracks how often an item is accessed from a mobile platform.
All usage events are counted per item, site collection, and tenant (SPO ).
Reports based on analytics processing

The Analytics Processing Component generates data that is used to create the following usage reports:
Popularity Trends An Excel report that shows the daily and monthly count per usage event for a site
collection, site, or specific item in a SharePoint library or list.
NOTE
Unique Users shows the number of unique users per day, while Unique Users per month shows SUM(UU/Day) for
the month.
Most Popular Items Shows ranking per usage event for all items in a library or list, for example the most
viewed items in the library or list. The ranking can be sorted by Recent or Ever.
Privacy protection of the data collected by the Analytics Processing

Component
Parts of the data that the Analytics Processing Component collects are related to personally identifiable
information. SharePoint Server has different features to protect the privacy of this information.
For each usage event, the Analytics Processing Component logs the following information:
The URL of the item where the usage event occurred.
The SiteID, the WebID, and the TenantID where the usage event occurred.
The time and the date when the usage event occurred.
The obfuscated user ID of the person who caused the usage event to occur.
This data is stored in the Search service application before it is processed by the Analytics Processing
Component. The data is automatically removed after 30 days. The following list shows the results of the data
processing:
The total number of usage events.
The total number of unique usage events.
Item-to-item recommendations.
Relevance features.
These results are stored in the analytics reporting database, and in the search index. No user information is stored
as a result of the data processing. The obfuscated user ID is only used when calculating the unique usage event
counts, and calculating item-to-item recommendations.
You can view the results in two usage reports. For more information, see View usage reports in SharePoint
Server.
Usage cookies for sites that have anonymous users
By default, usage cookies are not enabled for a SharePoint Server web application. To generate unique user
counts and item-to-item recommendations for sites that have anonymous users, SharePoint Server enables you
to use usage cookies for a SharePoint web application. When you enable usage cookies, this generates a unique
GUID that is used as a user ID when data is being processed. The GUID is available for the lifetime of the cookie,
and it is used as a user ID when data is being processed. The lifetime of the cookie is 14 days.
IMPORTANT
Local legal restrictions might apply when you enable cookies on sites that have anonymous users.
To enable usage cookies for a SharePoint web application, see Edit general settings on a web application in
SharePoint Server. This article also applies to SharePoint Server 2016.
Configure enterprise search in SharePoint Server

Enterprise search finds the information that's most relevant to an organization's customers, employees, and
partners. Enterprise search empowers them to take action and drive business outcomes.
SharePoint Server 2019 has both a classic and a modern search experience. Both search experiences use the same
search index to find search results, and some settings can impact both experiences. Learn about the differences
between the search experiences in SharePoint Server.
Articles about configuring enterprise search

The following articles reflect the steps to get started with enterprise search in SharePoint Server. The articles are
available to view online and writers update articles on a continuing basis as new information becomes available
and as users provide feedback.
Create and configure a Search service application in The Search service application crawls content and provides
SharePoint Server search results. You can either create it as part of a new
deployment of SharePoint Server, or as needed.
Create a Search Center site in SharePoint Server The Search Center is one classic search interface where users
submit search queries and view search results.
Deploy people search in SharePoint Server In classic search, People search lets users get information
about people in the organization and get links to the
documents that they have authored.
Create and configure a Search service application in
SharePoint Server
Before you begin

If you used the Farm Configuration Wizard after you installed SharePoint Server 2016 or SharePoint Server 2019,
a Search service application might have been created at that time. To verify whether a Search service application
exists, you can click Manage service applications in the Application Management section on the Central
Administration home page. For the remainder of this article, it is assumed that a Search service application does
not exist yet, and that therefore you must create one.
How to create and configure a SharePoint Search service application

When you deploy and configure a Search service application, you perform the following main tasks:
1. Create accounts — Certain domain user accounts are required specifically for a Search service
application.
2. Create a Search service application — A Search service application provides enterprise search features
and functionality.
3. Configure the Search service application — Basic configuration of a Search service application
includes configuring a default content access account, an email contact, and content sources.
4. Configure the Search service application topology — You can deploy search components on different
servers in the farm. You can also specify which instance of SQL Server is used to host the search-related
databases.
Step 1: Create accounts that are required for a SharePoint Search

service application
The following table lists the accounts that are required when a Search service application is created.
ACCOUNT DESCRIPTION NOTES
Search service Windows user credentials for the This setting applies to all Search service
SharePoint Server Search service, which applications in the farm. You can
is a Windows service change this account at any time by
clicking Configure service accounts in
the Security section on the Central
Administration home page.
Search Admin Web Service application Windows user credentials For each of these accounts, you can use
pool the same credentials that you specified
for the Search service. Or, you can
Search Query and Site Settings Web assign different credentials to each
Service application pool account according to the principle of
least-privilege administration.
ACCOUNT DESCRIPTION NOTES
Default content access Windows user credentials for the Search We recommend that you specify a
service application to use to access separate account for the default
content when crawling content access account according to
the principle of least-privilege
administration.
The accounts that you use for the Search service, the Search Admin Web Service application pool, and the Search
Query and Site Settings Web Service application pool must be registered as managed accounts in SharePoint
Server so that they are available when you create the Search service application. Use the following procedure to
register each of these accounts as a managed account.
To register a managed account
1. On the Central Administration home page, in the Quick Launch, click Security.
2. On the Security page, in the General Security section, click Configure managed accounts.
3. On the Managed Accounts page, click Register Managed Account.
4. On the Register Managed Account page, in the Account Registration section, type the user name and
password that you want to use as credentials for the service account.
5. If you want SharePoint Server to manage password changes for this account, select the Enable automatic
password change check box and configure the parameters for automatic password change.
6. Click OK.
Step 2: Create a SharePoint Search service application

Each Search service application has a separate content index. You can create multiple Search service applications
if you want to have different content indexes for different sets of content. For example, if you want to segregate
sensitive content (such as employee benefits information) into a separate content index, you can create a separate
Search service application to correspond to that set of content.
If your SharePoint environment is hybrid, you can index content that resides in SharePoint Server into the Office
365 content index. In this case you need to create a Search service application of type cloud. You can only create
one cloud Search service application per farm, but you can create multiple SSAs in combination with the single
cloud SSA.
NOTE
Each Search service application has its own search topology. If you create more than one Search service application in a
farm, we recommend that you allocate dedicated servers for the search topology of each Search service application.
Deploying several Search service applications to the same servers will significantly increase the resource requirements (CPU
and memory) on those servers.
Use the following procedure to create a Search service application or a cloud Search service application.
To create a Search service application
1. Verify that the user account that is performing this procedure is a member of the Farm Administrators
group for the farm for which you want to create the service application.
2. On the Central Administration home page, in the Application Management section, click Manage
3. On the Manage Service Applications page, on the ribbon, click New, and then click Search Service
Application.
4. On the Create New Search Service Application page, do the following:
Accept the default value for Service Application name, or type a new name for the Search service
application.
To make this a cloud Search service application, in the Search Service Application type section,
checkmark the Cloud Search Service Application box. Otherwise, leave the box unchecked.
In the Search Service Account list, select the managed account that you registered in the previous
procedure to run the Search service.
In the Application Pool for Search Admin Web Service section, do the following:
Select the Create new application pool option, and then specify a name for the application pool in
the Application pool name text box.
In the Select a security account for this application pool section, select the Configurable
option, and then from the list select the account that you registered to run the application pool for
the Search Admin Web Service.
In the Application Pool for Search Query and Site Settings Web Service section, do the following:
Choose the Create new application pool option, and then specify a name for the application pool
in the Application pool name text box.
In the Select a security account for this application pool section, select the Configurable
option, and then from the list select the account that you registered to run the application pool for
the Search Query and Site Settings Web Service.
5. Click OK.
Step 3: Configure the SharePoint Search service application

You configure a Search service application on the Search Administration page for that service application. Use the
following procedure to go to the Search Administration page for a particular Search service application.
To go to the Search Administration page
1. Verify that the user account that is performing this procedure is an administrator for the Search service
application that you want to configure.
2. On the home page of the Central Administration website, in the Application Management section, click
Manage service applications.
3. On the Manage Service Applications page, click the Search service application that you want to configure.
On the Search Administration page, configure the settings as described in the following sections:
Specify the default content access account
Specify the contact email address
Create content sources
Specify the default content access account
When you create a Search service application, the account that you specify for the Search service is automatically
configured as the default content access account. The crawler uses this account to crawl content that does not
have an associated crawl rule that specifies a different account. For the default content access account, we
recommend that you specify a domain user account that has read access to as much of the content that you want
to crawl as possible. You can change the default content access account at any time. For more information, see Use
the default content access account to crawl most content in Best practices for crawling in SharePoint Server.
If you have to crawl certain content by using a different account, you can create a crawl rule and specify a different
account for crawling. For information about how to create a crawl rule, see Manage crawl rules in SharePoint
Server.
Use the following procedure to specify the default content access account.
To specify the default content access account
1. On the Search Administration page, in the System Status section, click the link in the Default content
access account row.
2. In the Default Content Access Account dialog box, in the Account box, type the account that you
created for content access in the form domain\user name.
3. Type the password for this account in the Password and Confirm Password boxes.
4. Click OK.
Specify the contact email address
The Search service writes the contact email address to the logs of crawled servers. The default contact email
address, someone@example.com, is a placeholder. We recommend that you change this to an account that an
external administrator can contact when a crawl might be contributing to a problem such as a decrease in
performance on a server that the search system is crawling.
Use the following procedure to specify the contact email address.
To specify the contact email address
1. On the Search Administration page, in the System Status section, click the link for the Contact e-mail
address.
2. In the Search E -mail Setting dialog box, in the E -mail Address box, type the email address that you want
to appear in the logs of servers that are crawled by the search system.
3. Click OK.
Create content sources in a SharePoint Search service application
In order for users to be able to get search results, the search system must first crawl the corresponding content.
Crawling requires at least one content source. A content source is a set of options that you use to specify the type
of content to crawl, the starting URLs to crawl, and when and how deep to crawl. When a Search service
application is created, a content source named "Local SharePoint sites" is automatically created and configured for
crawling all SharePoint sites in the local server farm, and for crawling user profiles. You can create content sources
to specify other content to crawl and how the system will crawl that content. For more information, see Add, edit,
or delete a content source in SharePoint Server. However, you do not have to create other content sources if you
do not want to crawl content other than the SharePoint sites in the local farm.
If you choose the Standalone installation option when you install SharePoint Server 2016 or SharePoint Server
2019, a full crawl of all SharePoint sites in the farm is automatically performed after installation and an
incremental crawl is scheduled to occur every 20 minutes after that. If you choose the Server Farm installation
option when you install SharePoint Server 2016 or SharePoint Server 2019, no crawls are automatically
scheduled or performed. In the latter case, you must either start crawls manually or schedule times for crawls to
be performed. For more information, see the following articles;
Start, pause, resume, or stop a crawl in SharePoint Server
Best practices for crawling in SharePoint Server
Step 4: Configure the SharePoint Search service application topology

When you create a Search service application, the SharePoint Server Search service is started on the application
server that is hosting the Central Administration website, and search components are deployed to that server. If
you have more than one application server in your farm, you can deploy additional search components on other
application servers, depending on your requirements. You can deploy multiple instances of certain components.
For more information, see the following articles:
Plan enterprise search architecture in SharePoint Server 2016
Plan your search architecture in SharePoint Server for cloud hybrid search
See also
Create a Search Center site in SharePoint Server
Create a Search Center site in SharePoint Server

A Search Center site, or Search Center, provides a classic interface for users to submit search queries and view
search results. A Search Center site is the top-level site of a site collection that a farm administrator creates by
using the Enterprise Search Center template or Basic Search Center template.
Before you begin

Depending on the kind of installation that you performed and the site collection template that you selected at that
time, the farm might already have a Search Center site. To check this, browse to the top-level site for the site
collection that you created during installation. In either case, you can create a Search Center site and grant users
access to it by using the procedures in this article.
To create a SharePoint Search Center site
group.
2. On the home page of the Central Administration website, in the Application Management section, click
Create site collections.
In the Web Application section, select a web application to contain the new site collection. To use a web
application other than the one that is displayed, click the web application that is displayed, and then click
Change Web Application.
In the Title and Description section, in the Title box, type the name for the new Search Center site.
Optionally, type a description in the Description box.
In the Web Site Address section, for the part of the URL immediately after the web application address,
select /sites/, or select a managed path that was previously defined, and then type the final part of the
URL.
Note the address of the new Search Center for future reference.
In the Template Selection section, in the Select a template subsection, click the Enterprise tab, and
select the Enterprise Search Center template.
In the Primary Site Collection Administrator section, in the User name box, type the user name of the
primary site collection administrator for this site collection in the form domain\user name.
(Optional) In the Secondary Site Collection Administrator section, type the user name of a secondary
site collection administrator in the form domain\user name.
In the Quota Template section, select No Quota.
A Search Center site is not intended to be a data repository. Therefore, you do not have to select a quota
template.
Click OK.
4. On the Top-Level Site Successfully Created page, click the link to the Search Center site that you created.
After you create the Search Center site, you must grant site access to users so that they can perform search
queries and view search results. Use the following procedure to grant site access to users.
To grant access to the SharePoint Search Center
1. Verify that the user account that is performing this procedure is a member of the Owners group on the
Search Center site.
2. In a web browser, go to the Search Center site.
3. Open the Site menu by clicking the gear icon in the upper-right portion of the page, and then click Shared
with.
4. In the Shared With dialog box, click Invite people.
5. In the Share <SearchCenterName> dialog box, in the Enter users separated with semicolons text
box, type the names of the Windows user groups and Windows users to whom you want to grant
permissions for submitting queries and viewing search results in the Search Center.
For example, to grant access to the Search Center to all Windows users, type NT Authority\authenticated
users.
6. Click Show options.
7. Clear the Send an email invitation check box.
8. In the Select a group or permission level drop-down list, select <SearchCenterName> Visitors
[Read].
9. Click Share.
Related Topics
Create and configure a Search service application in SharePoint Server 2016
Deploy people search in SharePoint Server

People search is a SharePoint Server feature that allows users to get information about people in the organization
and to get links to the documents that they have authored. Users can access this feature by entering a search query
in the enterprise Search Center search box and clicking the link for the People search vertical.
A search vertical filters search results so that only a certain subset of all relevant results is displayed. SharePoint
Server provides four preconfigured search verticals: Everything, People, Conversations, and Videos. You can
see the links for these search verticals in the Search Navigation Web Part, which is below the search box in the
enterprise Search Center, as shown in the following screen shot.
When a user enters a search query in the search box and then clicks one of the search-vertical links, the Search
system returns search results that correspond to that search vertical only. For example, if the user enters Microsoft
Azure in the search box and then selects the People search-vertical link, the Search system returns only search
results that are people in your organization who are involved with Microsoft Azure.
This article describes the prerequisites that you must complete to make people search possible, and addresses
other considerations related to making people search work.
People search prerequisites

People search has the following prerequisites:
A Search service application must be running in the farm. For more information, see Create and configure a
Search service application in SharePoint Server 2016. The farm must also have a Search Center that uses
the Enterprise Search Center template. For more information, see Create a Search Center site in SharePoint
Server.
A Managed Metadata service application must be running in the farm. For more information, see Overview
of managed metadata service applications in SharePoint Server 2013.
User profile synchronization must be configured in the farm. If this has not been done yet, at a minimum
you must complete the following procedures that are described in Synchronize user and group profiles in
SharePoint Server 2013:
Phase 0: Configure the farm
Phase 1: Start the User Profile synchronization service
For more information, see Overview of profile synchronization in SharePoint Server 2013 and Plan profile
synchronization for SharePoint Server 2013.
Set up people search

To set up people search, you must configure My Sites settings and configure crawling.
Configure My Sites settings
You configure My Sites for a User Profile service application to specify the My Site host location and other
settings. For more information, see Plan for My Sites in SharePoint Server and Configure My Site settings for the
User Profile service application.
After you configure My Sites settings, the next step is to configure crawling.
Configure crawling
When you configure My Sites, the default content access account for search is automatically given Retrieve
People Data for Search Crawlers permissions in the User Profile service application. If you want to use a
different content access account to crawl the profile store, you must make sure that the account has permissions to
crawl the profile store. Use the following procedure to grant access to the profile store for a different account.
To grant access to an account to crawl the profile store
application.
2. Start SharePoint Central Administration.
Click Start, click SharePoint, and then click SharePoint Central Administration.
For Windows Server 2012:
On the Start screen, click SharePoint Central Administration.
If SharePoint Central Administration is not on the Start screen:
Right-click Computer, click All apps, and then click SharePoint Central Administration.
For more information about how to interact with Windows Server 2012, see Common Management Tasks
and Navigation in Windows Server 2012.
4. On the Manage Service Applications page, click the row that contains the User Profile service
application, and then in the ribbon, click Administrators.
5. In the Administrators for User Profile Service Application dialog box, in the To add an account box,
type a user account in the form domain\user name .
6. Click Add.
7. In the Permissions list, select the Retrieve People Data for Search Crawlers check box.
8. Click OK.
After you give the account access to crawl the profile store, you must create a crawl rule to specify that you want to
use that account when you crawl the profile store. Use the following procedure to create a crawl rule for this
purpose.
To create a crawl rule to authenticate to the User Profile service

application
application.
3. On the Manage Service Applications page, click the Search service application for which you want to
create a crawl rule.
4. On the Search Administration page, in the Quick Launch, in the Crawling section, click Crawl Rules.
5. On the Manage Crawl Rules page, click New Crawl Rule.
6. In the Path section, in the Path box, type the start address for the User Profile service application in the
form sps3:// My_Site_host_URL, where My_Site_host_URL is the URL for the Web application where you
deployed the My Sites site collection.
If the web application where you deployed the My Sites site collection uses Secure Sockets Layer (SSL ),
then type the start address in the form sps3s:// My_Site_host_URL.
7. Click Use regular expression syntax for matching this rule if you want to use regular expression syntax
in the path.
8. In the Crawl Configuration section, select Include all items in this path.
9. In the Specify Authentication section, select Specify a different content access account.
10. In the Account box that appears, type the user account to which you gave access to the profile store in the
form domain\user name.
11. Type the password for the account that you specified in the Password and Confirm Password boxes.
12. Clear the Do not allow Basic Authentication check box only if you want to allow the user account
credentials to be sent as plaintext.
NOTE
You should not clear the Do not allow Basic Authentication check box unless you are using SSL to encrypt the
website traffic. For more information, see Plan for user authentication methods in SharePoint Server.
13. Click OK.

For more information, see Manage crawl rules in SharePoint Server.
When you configure My Sites, the starting URL to crawl the profile store (sps3:// My_Site_host_URL or sps3s://
My_Site_host_URL) is automatically added to the preconfigured content source Local SharePoint Sites. We
recommend that you remove the URL of the profile store from the preconfigured content source and then create a
separate content source to crawl only the profile store. This allows you to crawl the profile store on a different
schedule from other crawls.
Use the following procedure to remove the URL of the profile store from the preconfigured content source.
To remove the profile store URL from the preconfigured content source
application.
3. On the Manage Service Applications page, click Search Service Application.
4. On the Search Administration page, in the Quick Launch, in the Crawling section, click Content
Sources.
5. On the Manage Content Sources page, click the link to the preconfigured content source ( Local
SharePoint sites).
6. In the Start Addresses section, remove the URL for the profile store (sps3:// My_Site_host_URL or sps3s://
My_Site_host_URL, where My_Site_host_URL is the URL for the web application where you deployed the
My Sites site collection).
7. Click OK.
Use the following procedure to create a content source that specifies how to crawl the profile store. For
more information, see Add, edit, or delete a content source in SharePoint Server.
To create a content source that specifies how to crawl the profile store
application.
3. On the Manage Service Applications page, click Search Service Application.
4. On the Search Administration page, in the Quick Launch, in the Crawling section, click Content
Sources.
5. On the Manage Content Sources page, click New Content Source.
6. On the Add Content Source page, in the Name section, type a name for this content source.
7. In the Content Source Type section, ensure that SharePoint Sites is selected.
8. In the Start Addresses section, type the start address in the form sps3:// My_Site_host_URL, where
My_Site_host_URL is the URL for the web application where you deployed the My Sites site collection.
If the web application where you deployed the My Sites site collection uses SSL, then type the start address
in the form sps3s:// My_Site_host_URL.
9. In the Crawl Settings section, leave the default value of Crawl everything under the host name for
each start address.
10. In the Crawl Schedules section, do the following:
Select Enable Continuous Crawls or Enable Incremental Crawls.
A continuous crawl automatically provides maximum freshness for the content source without an
incremental crawl schedule. For more information, see Manage continuous crawls in SharePoint Server.
If you select Enable Incremental Crawls, create an incremental crawl schedule.
Optionally create a schedule for full crawls.
11. If you selected Enable Incremental Crawls, in the Content Source Priority section, select the priority for
this content source.
NOTE
The Content Source Priority section does not appear when you specify the content source type as SharePoint
Sites and you select Enable Continuous Crawls.
12. Click OK.
Add data for people search

To get the best results from people search, you should add as much information as you can by adding user profiles
to the profile store and adding information to My Sites.
Add user profiles to the profile store
Before you can obtain meaningful people search results, you must add user profiles to the User Profile service
application. You can do this in the following ways:
Import user profiles from the directory service. For more information, see the following articles:
Plan profile synchronization for SharePoint Server 2013
Synchronize user and group profiles in SharePoint Server 2013
Configure profile synchronization by using SharePoint Active Directory Import in SharePoint Server
Copy user profiles from one farm to another by using the User Profile Replication Engine (UPRE ). For more
information, see Use UPRE to replicate user profiles across multiple farms in SharePoint Server 2013.
Add user profiles manually.
Synchronize with an external data source by using the Business Data Connectivity service. For more
information, see Phase 3: Configure connections and import data from business systems in the article
Synchronize user and group profiles in SharePoint Server 2013.
IMPORTANT
For a test environment, we recommend that you do not synchronize the profile store to a directory service or other external
data source that is in a production environment. Instead, create a copy of the directory service and synchronize the copy
with the profile store.
Use the following procedure to view the user profiles in the User Profile service application.
To view a list of user profiles in the User Profile service application
1. Verify that the user account that is performing this procedure is an administrator for the User Profile service
application.
3. On the Manage Service Applications page, click the User Profile service application.
4. On the Manage Profile Service page, in the People section, click Manage User Profiles.
5. On the Manage User Profiles page, in the Find profiles box, type the name of the domain of which the
users are members.
Do not type the fully qualified domain name. For example, if users are members of the Contoso.com
domain, type Contoso in the Find profiles box.
6. Click Find.
Add information to My Sites
My Sites keep information in the User Profile service application databases. The User Profile service application
stores much of the information that appears in results for people search. People search results become more
useful as users add more information to their My Sites.
The first time that a user accesses their My Site, also known as their personal site, a My Site is created for them
and a profile is automatically added to the User Profile service application.
To add information to a user's My Site, log on as a user for whom a user profile was created in the User Profile
service application, and then go to that user's My Site. In the user's My Site, you can provide information about the
user's expertise and interests. To see how the information that you added affects the people search results that
appear, perform a crawl of the profile store, and then search on the user's name.
Crawl the profile store

You are now ready to crawl the profile store. For information about how to start the crawl, see Start, pause,
resume, or stop a crawl in SharePoint Server.
NOTE
We recommend that you crawl the profile store and wait about two hours after the crawl finishes before you start the first
crawl of the preconfigured content source (that is, local SharePoint sites). After the crawl of the profile store finishes, the
search system generates a list to standardize people's names. This is so that when a person's name has different forms in
search results, the results are displayed in a single group corresponding to one name. For example, all documents authored
by Anne Weiler or A. Weiler or alias AnneW can be displayed in the search results in a result block that is labeled "Documents
by Anne Weiler". Similarly, all documents authored by any of those identities can be displayed under the heading "Anne
Weiler" in the refinement panel if "Author" is one of the categories there.
For information about how to view the status of a crawl, see Start, pause, resume, or stop a crawl for a content
source.
See also
Overview of profile synchronization in SharePoint Server 2013
Manage user profile synchronization in SharePoint Server
Add, edit, or delete a content source in SharePoint Server
Administer search in SharePoint Server

Below are the main areas where you can customize and impact the search experience for your users and make
sure that search is performing the way you want. SharePoint Server 2019 has both a classic and a modern search
experience. Both search experiences use the same search index to find search results, and some settings can impact
both experiences. Learn about the differences between the search experiences in SharePoint Server.
Make sure the content can be found

The content must be crawled and added to the search index for your users to find what they're looking for when
they search in SharePoint Server.
Learn how to manage the index
Learn how to manage crawling
Make the results in the Search Center look great

The Search Center is a classic search experience, which you can customize. Presenting the search results the right
way makes content easier to find. The Search Center comes with several pages, and you can use the different
search Web Parts to help each user find what they're looking for. Learn how to manage the Search Center
Show relevant search results

All search results are not relevant to everyone all the time. There are a number of settings that you can use to
show users the most relevant results. Learn how to manage relevance.
Check logs and reports

See how you can check if the crawler has added content to the search index, and if your users are finding what
they're looking for.
Learn how to view search diagnostics
Learn how to enable query logging
Learn how to enable search alerts
Manage the search topology

To keep search performant, you might need to scale out the search topology by managing the search components.
Learn how to manage the search topology.
Differences between the search experiences in
SharePoint Server

In addition to the classic search experience, SharePoint Server 2019 comes with a modern search experience.
Both search experiences use the same search index to find results.
As a user, the most visual difference is that in modern search, you see results even before you start typing in the
search box, and the results update as you type. Learn about the modern search experience.
As a search administrator, you can’t turn off neither classic nor modern search. Users get the classic search
experience on publishing sites, classic team sites, and in the Search Center. Users get the modern search
experience on the SharePoint home page, communication sites, and modern team sites. There are some
differences between the search experiences from a search administrator's perspective.
Search administrators can customize the classic search experience, but only impact some aspects of the modern
search experience. There aren't separate search settings for the modern search experience. Instead certain of the
classic search settings also apply to the modern search experience:
The search schema determines how content is collected in and retrieved from the search index. Because both
search experiences use the same search index to find search results, any changes you make to the search
schema, apply to both experiences. The following search schema settings don’t affect the modern search
experience:
Sortable
Refinable
Company name extraction
Custom entity extraction
The modern search experience only shows results from the default result source. If you change the default
result source, both search experiences are impacted.
If you temporarily remove a search result, the result is removed in both search experiences.
When you create a promoted result at the tenant level, users can see it in both search experiences. In the
modern search experience, users only see promoted results when they’ve filtered to All result types (default
filter) on the search results page and only when they search across all sites.
Unlike the classic search results page, the modern search results page isn’t built with web parts. You can’t
customize the modern search results page or create additional search results pages.

In a Search Center site, users get the classic search experience. When you create an Enterprise Search Center site
collection as described in Create a Search Center site in SharePoint Server, SharePoint Server creates a default
search home page and a default search results page. In addition, several pages known as search verticals are
created. Search verticals are customized for searching specific content, such as People, Conversations, and Videos,
and they display search results that are filtered and formatted for a specific content type or class.
The following pages are created in an Enterprise Search Center site collection:
default.aspx: the home page for the Search Center, and the page where end-users enter their queries.
results.aspx: the default search results page for the Search Center. It is also the search results page for the
Everything search vertical.
peopleresults.aspx: the search results page for the People search vertical.
conversationresults.aspx: the search results page for the Conversations search vertical.
videoresults.aspx: the search results page for the Videos search vertical.
advanced.aspx: the search page where end-users can apply some restrictions to their search phrases —
for example, limiting the search to an exact phrase.
These pages are located in the Pages library, and they contain Web Parts that you can customize to improve the
end-user search experience. This article describes the Web Parts on these pages, and how you can configure the
different Web Parts settings to improve how search results are displayed.
By default, the Web Parts on the search vertical pages (results.aspx, peopleresults.aspx, conversationresults.aspx,
videoresults.aspx, advanced.aspx) are the same. However the query in the Search Results Web Part is configured
differently for each search vertical page. For each search vertical page, the query in the Search Results Web Part
is directed to a particular result source. This can be a result source that defines the search vertical or any result
source that you want to direct queries to when you create a custom search vertical. For example, for the
peopleresults.aspx search vertical page, the query in the Search Results Web Part is limited to the Local
People Results (System ) result source. For the videoresults.aspx search vertical page, the query in the Search
Results Web Part is limited to the Local Video Results (System ).
The following articles describe how to configure properties for each Web Part that is used in the Enterprise Search
Center site:
Configure properties of the Search Box Web Part in SharePoint Server
Configure properties of the Refinement Web Part in SharePoint Server
Configure properties of the Search Navigation Web Part in SharePoint Server
Configure properties of the Search Box Web Part in
SharePoint Server

By default, the Search Box Web Part is used on the home page for the Search Center (default.aspx), and all search
results pages (results.aspx, peopleresults.aspx, conversationresults.aspx, videoresults.aspx). By changing properties
in the Search Box Web Part you can you can do the following:
Change the Web Part or page where the search results should be displayed — for example, a custom
Search Results Web Part or a custom search results page.
Turn off query suggestions and people suggestions. For more information about query suggestions, see
Manage query suggestions in SharePoint Server
Display links to a search preference page and an advanced search page.
Change the display template that is applied to the Web Part.
Before you begin

NOTE
Because SharePoint Server runs as websites in Internet Information Services (IIS), administrators and users depend on the
accessibility features that browsers provide. SharePoint Server supports the accessibility features of supported browsers. For
more information, see the following resources:
Plan browser support
Accessibility for SharePoint 2013
Accessibility features in SharePoint 2013 Products
Keyboard shortcuts
Touch
Configure properties of the Search Box Web Part

To configure the properties of a Search Box Web Part
1. Verify that the user account that performs this procedure is a member of the Designers SharePoint group
on the Enterprise Search Center site.
2. On the Search Center site home page, click the Settings menu, and then click Edit Page.
3. In the Web Part, click the Search Box Web Part Menu arrow, and then click Edit Web Part.
4. In the Web Part tool pane, in the Properties for Search Box section, expand the Which search results
page should queries be sent to section, and then do the following:
To display the settings that are defined on the Search Settings page, select the Use this site's Search
Settings check box.
To override the settings that are defined on the Search Settings page, clear the Use this site's Search
Settings check box, and then do the following:
To display search results in a Web Part on the page, in the section Send queries to other Web Parts
on this page, select a Web Part.
NOTE
If there are no other Web Parts on a page, search results will be sent to the search results page as specified
on the Search Settings page.
To send queries to a custom search results page, select Send queries to a custom results page URL, and
then type the URL of the custom search results page.
NOTE
You can't send queries to a custom search results page that uses a friendly URL.
5. In the Web Part tool pane, in the Properties for Search Box section, expand the Query Suggestions section,
and then do the following:
To disable query suggestions, clear the Show suggestions check box.
To specify additional properties for query suggestions, change the values in the following fields:
Number of query suggestions: How many query suggestions to display.
Minimum number of characters: How many characters the user must type before query
suggestions are displayed.
Suggestions delay (in milliseconds): How many milliseconds elapse before query suggestions
are displayed.
Number of personal favorites: How many query suggestions are displayed to the user under the
text Are you looking for these again? in the search results. These suggestions are based on search
results that the user has clicked previously. To disable personal favorite results, clear the Show
personal favorite results check box.
To turn on people name suggestions, select Show people name suggestions.
6. In the Web Part tool pane, in the Properties for Search Box section, expand the Settings section, and then do
the following:
To show a link to a search preference page, select Show preferences link.
To show a link to an advanced search page, select Show advanced link, and then in the Advanced search
page URL box, type the URL of the advanced search page that you want to link to.
To apply another display template, in the Search box control Display Template list, select the display
template that you want to apply to the Web Part.
Select the Make the search box have focus when the page is loaded check box to make it possible for
users to immediately type a query in the search box when the page is loaded without first having to click the
search box. By default, this is selected.
See also
How to change the text that is displayed in the Search Box Web Part in SharePoint Server 2013

The Search Results Web Part displays the search results of a query entered in a Search Box Web Part. By default,
the Search Results Web Part is used on all search vertical pages (results.aspx, peopleresults.aspx,
conversationresults.aspx, videoresults.aspx). The Search Results Web Part displays the actual search results and it
also passes the search results to the Refinement Web Part and the Search Navigation Web Part on the same page.
The Search Results Web Part uses a query that is specified in the Web Part to display search results. By default, the
query defined in this Web Part uses the query variable {searchboxquery}. The query variable is a placeholder for a
value. When a query is run, the placeholder is replaced with a value. For example, when a user types the search
phrase yellow in the Search Box Web Part, the {searchboxquery} variable in the Search Results Web Part will
resolve to search all items that contain the phrase yellow .
By changing the properties and query in the Search Results Web Part you can you can do the following:
Limit search results to a result source.
Add query variables or property filters that customize search results for different users.
Promote or demote items or pages within the search results.
Change the sorting of the search results.
Change the display template.
Before you begin

NOTE
Keyboard shortcuts
Touch

To configure the properties of a Search Results Web Part
2. On the search results page, click the Settings menu, and then click Edit Page.
3. In the Search Results Web Part, click the Search Results Web Part Menu arrow, and then click Edit Web
Part.
4. In the Web Part tool pane, in the Search Criteria section, click Change query.
5. On the BASICS tab, do one of the following:
To define your query by using Keyword Query Language (KQL ), select options as described in the following
list:
Select a query
Select a result source to specify which content should be searched.
By default, the following result sources are set for the different search vertical pages:
Everything (results.aspx): Local SharePoint Results (System )
People (peopleresults.aspx): Local People Results (System )
Conversations (conversationresults.aspx): Conversations (System )
Videos (videoresults.aspx): Local Video Results (System )
Keyword filter
You can use keyword filters to add query variables to your query. For a list of available query
variables,see Query variables in SharePoint Server.
You can select pre-defined query variables from the drop-down list, and then add them to the query
by clicking Add keyword filter.
Property filter
You can use property filters to query the content of managed properties that are set to queryable in
the search schema.
You can select managed properties from the Property filter drop-down list. Click Add property
filter to add the filter to the query.
Query text
By default, the query variable {searchboxquery} is defined for this field. You can change the query
text by using KQL. For more information about KQL, see Keyword Query Language (KQL ) syntax
reference. Alternatively you can use the Keyword filter and Property filter lists to build the query.
The keyword query can consist of free-text keywords, property filters, or operators. Use braces to
enclose query variables. The query variables will be replaced with an actual value when the query is
run.
Keyword queries have a maximum length of 2,048 characters.
To define your query by using pre-defined variables, click Switch to Quick Mode. Select options as
described in the following list:
Select a query
Select a result source to specify which content should be searched. If you have shared a document
library or list as catalog, the catalog result source will be displayed in this drop-down list.
Restrict by app
Select an option from the list to restrict results to a specific site, library, list, or URL.
Restrict by tag
You can limit results to content that is tagged with a term from a term set.
Select one of the following options:
Don't restrict by any tag
Search results will not be limited based on tags (default).
Restrict by navigation term of current page
Search results will be limited to content that is tagged with the term of the current page. The
current tag is displayed as the last part of the friendly URL. This option is only meaningful for
sites that use managed navigation.
Restrict by current and child navigation
Search results will be limited to content that is tagged with the term of the current page
(displayed as the last part of the friendly URL ), and content that is tagged with sub-terms of
the current page. This option is only meaningful for sites that use managed navigation.
Restrict on this tag
Search results will be limited to content that is tagged with the tag that you type inside the
box.
Note: When you switch to from Quick Mode to Advanced Mode, the result source that you selected from
Select a query is replaced by a different result source. This result source could affect the search results.
Therefore, make sure that you check the search results that are displayed in the SEARCH RESULT
PREVIEW section, and add query configuration in the Query text field if you need to.
6. The REFINERS tab lists the managed properties that are enabled as refiners in the search schema. You can
specify that the search results returned in the Search Results Web Part should be limited to one or more
values from the refiners. Select a refiner in the list, and then click Add to add it to the query.
Click Show more if you want to define grouping of results. Under Group results, you can specify that the
results should be grouped based on one or more managed properties. This is useful when you are
displaying several variants for a given item, and want to group them under a single result.
7. On the SORTING tab, you can specify how search results should be sorted. This tab is available only if you
use Advanced Mode. If you use Quick Mode, you can define sorting options in the result source.
In the Sort by drop-down list:
8. Select a managed property from the list of managed properties that are set as sortable in the search
schema, and then select Descending or Ascending. To add more sorting levels, click Add sort level.
NOTE
Sorting of search results is case sensitive.
IMPORTANT
If your result source contains sorting, you should not specify sorting in the Search Results Web Part. This is because
the sorting in the result source overrides the sorting that you specify in the Search Results Web Part.
9. Select Rank to sort by relevance rank. You can then specify which ranking model to use or specify dynamic
ordering rules.
(Optional) Select which ranking model to use for sorting in the Ranking Model list.
Under Dynamic ordering, you can specify additional ranking by adding rules that will change the
order of results when certain conditions apply. Click Add dynamic ordering rule, and then specify
conditional rules.
10. On the SETTINGS tab, specify the settings that are listed in the following list.
Query Rules
Select whether to use Query Rules or not.
URL Rewriting
Select if the URL rewrite to the item details page should continue to be relative for each catalog item as
defined when you set up the catalog connection. This option is only meaningful for sites that use managed
navigation and have connected to a catalog that uses anonymous access for the catalog pages. If you select
Don't rewrite URLs, the URLs for catalog items are pointed directly to the library item of the connected
catalog.
Loading Behavior
Select when the search results returned by the Search Results Web Part appear on the web page. The
default option is Async option: Issue query from the browser. Queries will be issued from the end-users
browser after the complete page is received (asynchronous). If you select the synchronous option, Sync
option: Issue query from the server, queries are issued from the server, and the search results are
included in the page response that is sent back from SharePoint (synchronous). Synchronous loading
makes search vulnerable to cross-site request forgery attacks and you should only chose this option after
carefully considering whether this vulnerability can be exploited, learn more.
9. On the TEST tab, you can preview the query that is sent by the Search Results Web Part.
Query text
Shows the final query that will be run by the Search Results Web Part. It is based on the original query
template where dynamic variables are substituted with current values. Other changes to the query may be
made as part of a query rule.
Click Show more to display additional information.
Query template
Shows the content of the query template that is applied to the query.
Refined by
Shows the refiners applied to the query as defined on the REFINERS tab.
Grouped by
Shows the managed property on which search results should be grouped as defined on the REFINERS
tab.
Applied query rules
Shows which query rules are applied to the query.
The Query template variables section shows the query variables that will be applied to the query, and the
values of the variables that apply to the current page. You can type other values to test the effect they will have on
the query. Click the Test Query button to preview the search results.
You can also test how the query works for different user segment terms. Click Add user segment term to add
terms to be added to the query.
Click the Test query button to preview the search results.
Query text
Shows the final query that will be run by the Search Results Web Part. It is based on the original query
template where dynamic variables are substituted with current values. Other changes to the query may be
made as part of a query rule.
10. In the Web Part tool pane, in the Display Templates section, the default selection is Use result types to
display items. This selection will apply different display templates according to the result type of the
search result. For example, if the result type of a search result is a PDF file, the display template PDF Item
will be applied. If the result type of a search result is an image, the Picture Item display template will be
applied. To apply one display template to all result types of the search results, select Use a single template
to display items, and then select the display template that you want to apply.
11. In the Web Part tool pane, in the Settings section, in the Results Settings, to further specify how search
results should be shown, change the values in the following fields:
Number of results per page The number of search results to be displayed per page.
Show ranked results Clear the check box if you want to show only promoted blocks (such as promoted
results or personal favorites) or result controls (such as result counts) instead of the ranked results.
Show promoted results Clear the check box if you do not want to show search results that you have
promoted by using Query rules.
Show "Did you mean?" Clear the check box if you do not want to show query spelling corrections as Did
you mean suggestions. For more information about query spelling corrections, see Manage query spelling
correction in SharePoint Server.
Show personal favorites Clear the check box if you do not want to show personal favorites.
Show View Duplicates link Select the check box if you want to show a View Duplicates link.
Show link to search center Select the check box if you want to show a link to the Search Center.
12. In the Web Part tool pane, in the Settings section, in the Results control settings section, to specify how
search results should be shown, change the values in the following fields:
Show advanced link Clear the check box if you don't want to show a link to the Advanced Search page in
the Web Part.
Show result count Clear the check box if you don't want to show the number of results found in the Web
Part.
Show language dropdown Clear the check box if you don't want to show the language drop-down in the
Web Part.
Show sort dropdown Select the check box if you want to show the sort drop-down in the Web Part.
Show paging Clear the check box if you don't want to show paging in the Web Part.
Show preferences link Clear the check box if you don't want to show a link to the preferences page in the
Web Part.
Show AlertMe link Clear the check box if you don't want to show a link to the Alert Me page in the Web
Part. For more information about search alerts, see Enable search alerts in SharePoint Server.
To disable stemming in a Search Results Web Part

Stemming means that nouns and adjectives in a query are expanded to different possible inflections. For example,
if a person enters the English word "foot" in a query, it is automatically expanded to {"feet"}. Similarly, the word
"overview" is expanded to {"overviews"}.
To disable stemming in a Search Results Web Part
2. On the search results page, click the Settings menu, and then click Edit page.
3. In the Search Results Web Part, click the Search Results Web Part Menu arrow, click Export…, and then
save the Web Part to your computer.
4. Open the Web Part in a text editor — for example, Notepad.
5. Change the value for EnableStemming to false, and then save the file with a new name — for example,
Search_Results_NoStemming.webpart.
6. On the search results page, in the Main Zone, click Add a Web Part.
7. In the Categories section, click the Upload a Web Part arrow.
8. In the Upload a Web Part section, click Browse to find the Web Part file that you have edited, and then
click Upload.
9. To add the customized Search Results Web Part to the search results page, do the following:
Browse to the search results page.
Click the Settings menu, and then click Edit Page.
In the Web Part Zone where you want to add the Web Part, click Add a Web Part.
In the Categories list, select Imported Web Parts.
In the Parts list, select the Web Part that you uploaded, and then click Add.
10. To remove the default Search Results Web Part from the search results page, do the following:
Browse to the search results page.
Click the Settings menu, and then click Edit Page.
In the Web Part, click the Search Results Web Part menu arrow, and then click Delete.
NOTE
Disabling stemming turns it off for all languages except the following: Arabic, Estonian, Finnish, Hebrew, Hungarian, Korean,
Latvian, and Slovak.
See also
Blog series: How to change the way search results are displayed in SharePoint Server 2013
Configure properties of the Refinement Web Part in
SharePoint Server

By default, the Refinement Web Part is used on all search vertical pages (results.aspx, peopleresults.aspx,
conversationresults.aspx, videoresults.aspx). The Web Part filters search results from a Search Results Web Part
into categories to help users narrow search results to help them find what they are looking for. By changing
properties in the Refinement Web Part you can you can do the following:
Specify a different Search Results Web Part from which to filter search results.
Specify which refiners to show in the Web Part.
Change the display template that is applied to each refiner.
Before you begin these procedures, verify the following:
The managed properties that you want to use as refiners are set to refinable and queryable in the search
schema. You can verify or change this by viewing or editing the Main characteristics of the managed
property as described in To add a managed property.
You have done a full crawl of the content source that contains the managed properties that are enabled as
refiners as described in Start, pause, resume, or stop a crawl in SharePoint Server.
Configure properties of the Refinement Web Part

To configure the properties of a Refinement Web Part
2. Browse to the page that contains the Refinement Web Part that you want to configure.
3. Click the Settings menu, and then click Edit Page.
4. In the Web Part, click the Refinement Web Part Menu arrow, and then click Edit Web Part.
5. In the Web Part tool pane, in the Refinement Target section, select the Web Part from which from which to
filter search results. By default, the Search Results Web Part is selected.
6. In the Web Part tool pane, verify that the Choose Refiners in this Web Part is selected.
7. Click Choose Refiners.
8. On the Refinement configuration page, from the Available refiners section, use the buttons to select
which refiners should be shown in the Web Part, and also in what order that they should be shown. If you
have specified an Alias for a refinable managed property, this alias is shown in the Configuration for
section.
9. In the Configuration for section, configure how you want each refiner to appear.
NOTE
If you have a single language site, you can change the refiner display name in the Display name section. For
multilingual sites, you have to change the refiner display language as described in Change the refiner display name.
Change the refiner display name

By default, the name of the managed property that is enabled as a refiner will be used as display name for the
refiner. In many cases, the managed property name is not user-friendly — for example, RefinableString00 or
ColorOWSTEXT. You can change the display name of the refiner by changing a java script file in the master page
gallery.
To change the refiner display name
2. On the Settings menu, click Site Settings.
3. On the Site Settings page, in the Web Designer Galleries section, click Master pages and page
layouts.
4. On the Master Page Gallery page, click Display Templates.
5. On the Display Templates page, click Language Files.
6. On the Language Files page, click the folder that contains the language for which you want to change the
refiner display name.
7. Open the CustomStrings.js file.
8. Add one line to the file for each managed property that is enabled as a refiner for which you want to change
the display name by using the following syntax:
"rf_RefinementTitle_ManagedPropertyName": "Sample Refinement Title for ManagedPropertyName"
For example, you can add the following line to change the display name for the managed property
RefinableInt00 to Price:
"rf_RefinementTitle_RefinableInt00": "Price" .
Add refiner counts to the Refinement Web Part

By default, the Refiner Web Part will not show refiner counts — that is, the number of items for each refiner value.
For example, if you have enabled the managed property Color as a refiner, the refiner values will only show colors
such as Red, Green, and Blue. You can add refiner counts by changing a value in an HTML file so that the refiner
values are shown as Red (10), Green (12), and Blue (8).
To add refiner counts to the Refinement Web Part
2. On the Settings menu, click Site Settings.
3. On the Site Settings page, in the Web Designer Galleries section, click Master pages and page
layouts.
4. On the Master Page Gallery page, click Display Templates.
5. On the Display Templates page, click Filters.
6. Open the Filter_Default.html file.
7. Change the value for ShowCounts to true.
8. Save the file.
Configure properties of the Search Navigation Web
Part in SharePoint Server

The Search Navigation Web Part is configured to display links to the search verticals Everything, People,
Conversations and Videos. It uses search results from the Search Results Web Part so that when users click a
search vertical link, the search results are filtered and displayed following the configuration of the search vertical.
You can also create your own search vertical and add it to be displayed in the Search Navigation Web Part.
By changing properties on the Search Navigation Web Part you can do the following:
Specify a different Web Part from which search results are received.
Change the number of search vertical links to display.
The search vertical properties, such as display name and links, are configured on the Search Settings page for the
corresponding site.
Before you begin

NOTE
accessibility features that browsers provide. SharePoint Server supports the accessibility features of supported browsers.
For more information, see the following resources:

Keyboard shortcuts
Touch
Configure the properties of the Search Navigation Web Part

To configure the properties of a Search Navigation Web Part
3. In the Search Navigation Web Part, click the Search Navigation Web Part menu arrow, and then click
Edit Web Part.
4. In the Web Part tool pane, in the Control section, do the following:
To receive search results from another Web Part on the page, in the Use Current Query from list, select a
Web Part.
To change the number of search vertical links to display before overflowing, in the Maximum Links
Before Overflow box, type a number.
Change the properties of a search vertical in the Search Navigation

Web Part
To change the properties of a search vertical in the Search Navigation Web Part
1. Verify that the user account that performs this procedure is a member of the Owners group on the
Enterprise Search Center site.
2. On the Settings menu for the site, click Site Settings.
3. On the Site Settings page, in the Search section, click Search Settings.
4. On the Search Settings page, in the Configure Search Navigation section, click to select the search
vertical for which you want to change the properties, and then click Edit.
5. In the Navigation Link dialog box, do the following:
To change the display name of a search vertical, in the Title field, type a display name.
To change the URL of the search vertical, in the URL field, type a URL.
NOTE
You can't use a page that uses a friendly URL for your search vertical.
6. On the Search Settings page, click OK to save the changes.
Add a search vertical to the Search Navigation Web Part

Before you start this procedure, verify that you have created a new page for the search vertical. We recommend
that you copy one of the existing search vertical pages — for example, results.aspx, and then modify the copy to
create a new page.
To add a search vertical to the Search Navigation Web Part
1. Verify that the user account that performs this procedure is a member of the Owners group on the
Enterprise Search Center site.
4. On the Search Settings page, in the Configure Search Navigation section, click Add Link.
In the Title field, type a display name.
In the URL field, type the URL to the new search vertical.
Click OK to save the new search vertical.
Manage the search index in SharePoint Server

The following articles describe how you can manage the search index.
SharePoint Server 2019 has both a classic and a modern search experience. Both search experiences use the same
search index to find search results. Learn about the differences between the search experiences in SharePoint
Server.
Articles about managing the search index

The following articles about managing the search index in SharePoint Server are available to view online. Writers
update articles on a continuing basis as new information becomes available and as users provide feedback.
CONTENT DESCRIPTION
Manage the search schema in SharePoint Server Learn how to use the search schema to collect content in the
search index and retrieve content from the search index.
Add or remove a file type from the search index in SharePoint Learn how to add or remove a file type from the SharePoint
Server search index by modifying the list of file types that the search
system crawls.
Delete items from the search index or from search results in Learn how to remove an item from the search index or
SharePoint Server SharePoint search results by removing the URL.
Reset the search index in SharePoint Server Learn how to reset the SharePoint search index.

The search schema in SharePoint Server determines how content is collected in and retrieved from the search
index in SharePoint Server.
Crawled properties are metadata that is extracted from content during crawls. Metadata can be structured content
(such as the title or the author from a Word document), or unstructured content (such as a detected language or
extracted keywords).
You decide which crawled metadata to index by mapping the crawled property to a managed property. Users can
only search on managed properties. You can map multiple crawled properties to a single managed property or
map a single crawled property to multiple managed properties.
NOTE
The search schema applies to both the classic and the modern search experiences, except for the following settings which
don't apply to modern search:
Refinable. Modern search has built-in refiners.
Sortable. Not supported in modern search.
Custom entity extraction. Modern search has built-in refiners.
Company name extraction. Not supported in modern search.
Before you begin

Create a Search service application.
Add one or more content sources and run a full crawl.
To view crawled properties and managed properties

application.
3. Click the Search service application.
4. On the Search Administration page, in the Quick Launch, under Queries and Results, click Search
Schema.
5. On the Managed Properties page, you see an overview of all the managed properties, the settings on the
managed properties and the crawled properties they are mapped to. To view crawled properties, click
Crawled Properties. To view crawled property categories, click Categories.
To add a managed property

application.
Schema.
5. On the Managed Properties page, click New Managed Property.
6. On the New Managed Property page, in the Property name box in the Name and description section,
enter the name of the new managed property. You can also enter a description.
7. In the Type section, select one of the following options for the property:
Text
Integer
Decimal
Date and Time
Yes/No
Double precision float
Binary
8. In the Main characteristics section, select one or several of the following:
Searchable
Advanced searchable settings (optional, if Searchable is selected)
Queryable
Retrievable
Allow multiple values
Refinable
Sortable
Alias
Token normalization
Complete matching
Language neutral tokenization
Finer query tokenization
IMPORTANT
If you want to be able to use this managed property as a refiner, you must select both Refinable and Queryable.
9. In the Mappings to crawled properties section, click Add a mapping.

10. On the Crawled property selection page, select a crawled property to map to the managed property and
then click OK. Repeat this step to map more crawled properties.
11. On the New Managed Property page, in the Mappings to crawled properties section, specify if you want
to include:
All content from all crawled properties mapped to this managed property
Content from the first crawled property that contains a value and, optionally, in which order.
12. In the Company name extraction section, you can optionally select the check box to enable company
name extraction.
13. In the Custom entity extraction section, you can optionally select the check box to enable custom entity
extraction. See Create and deploy custom entity extractors in SharePoint Server for the procedures.
14. Click OK.
You have to perform a full crawl of the content source or sources that contain this new managed property to
include it in the search index. If the new managed property is in a SharePoint Server library or list, you have to
reindex that library or list.For more information see, Overview of the search schema in SharePoint Server.
To edit a managed property

application.
Schema.
5. On the Managed Properties page, find the managed property that you want to edit, or enter its name in
the Filter box.
6. Point to the managed property that you want to edit, click the arrow, and then click Edit/Map property.
7. On the Edit Managed Property page, edit the settings and then click OK.
Some changes on managed property settings require a full crawl to take effect. See the table Search schema
changes that require content to be reindexed for an overview of which changes require you to reindex the
content.
To delete a managed property

application.
Schema.
5. On the Managed Properties page, find the managed property that you want to delete, or enter its name in
the Filter box.
6. Point to the managed property that you want to delete, click the arrow, and then click Delete.
7. Click OK.
If you delete a managed property:Users can no longer run queries using this property.A query rule that uses this
property no longer works.A custom search application or web part that uses this property no longer works.To
delete this property from the search index, you'll have to perform a full crawl. If the deleted property was in a
SharePoint Server library or list, you'll have to reindex that library or list.
To map a crawled property to a managed property

application.
Schema.
5. On the Crawled Properties page, find the crawled property that you want to map to a managed property,
or enter its name in the Filters box.
6. Point to the crawled property that you want to map, click the arrow, and then click Edit/Map property.
7. On the Edit Crawled Property page, in the Mappings to managed properties section, click Add a
Mapping.
8. On the Managed property selection page, select one managed property to map to the crawled property
and then click OK. Repeat this step to map more managed properties to this crawled property.
9. In the Include in full-text index section, check the box if you want to include the content of this crawled
property in the full-text index.
10. On the Edit Crawled Property page, click OK.
You have to perform a full crawl of the content source that includes the crawled property that you've mapped to a
managed property for the new mapping to take effect. If the new mapping is for a SharePoint Server library or
list, you have to reindex that library or list.
To view or edit crawled property categories

application.
2. In Central Administration, in Application Management section, click Manage service applications.
Schema.
5. On the Categories page, find the crawled property category that you want to view or edit.
To view which crawled properties belong to a category, and which managed properties they are mapped
to, click the crawled property category in the Categories page.
To edit a category, point to the crawled property category that you want to edit, click the arrow, and then
click Edit category.
Cau t i on
If you edit a crawled property category, your changes apply to all of the crawled properties within the category.
Changing a crawled property category can influence performance and how items are saved in the search index.
You also have to reindex the content.
Add a managed property using tenant administration or site collection

administration
Tenant administrators and site collection administrators can create a search schema that is specific for their tenant
or site collection. For more information how to manage the search schema for tenants and site collections, see
Manage the search schema in SharePoint Online.
You can create new managed properties for a tenant or a site collection and map crawled properties to them.
Alternatively, you can reuse existing, unused managed properties that do not have crawled properties mapped to
them, and rename them using an Alias. Then, you must map crawled properties to the renamed managed
property with the defined alias.
When you create a new managed property in the tenant or site collection administration, there are some
limitations. For example, the property can only be of type Text or Yes/No, and it can't be refinable or sortable. If
you need a property of a different type, or one that has different characteristics than what is available, follow the
steps under To create a managed property by renaming an existing one.
When you have added a new property to a list or to a library on a SharePoint Server site, or when you have
changed properties that are used in a list or library, the content must be re-crawled before your changes will be
reflected in the search index. Because your changes are made in the search schema, and not to the actual site, the
crawler will not automatically reindex the list or the library. To make sure that your changes are crawled and
reindexed, you can specifically request a reindexing of the list or library. When you do this, the list or library
content will be recrawled and reindexed so that you can start using your new managed properties in queries,
query rules and display templates.
See the table Search schema changes that require content to be reindexed for an overview of which managed
property setting changes require you to reindex the content.
To create a managed property for a tenant or a site collection
1. Verify that the user account that is performing this procedure is an administrator for the tenant or for the
site collection.
2. Go to the Search Schema page for the tenant or for a site collection.
For the tenant, sign in to the Microsoft 365 Admin Center. Then, choose Admin > SharePoint. You're
now in the SharePoint admin center. Click search, and then on the search administration page, click
Manage Search Schema.
For the site collection, on your site, go to Settings, click Site settings and then under Site Collection
Administration, click Search Schema.
3. On the Managed Properties page, click New Managed Property.
4. On the New Managed Property page, in the Property name box in the Name and description section,
enter the name of the new managed property. You can also enter a description.
5. In the Type section, select one of the following options for the property:
Text
Yes/No
6. In the Main characteristics section, select one or several of the available options.
then click OK. Repeat this step to map more crawled properties.
9. On the New Managed Property page, in the Mappings to crawled properties section, specify if you want
to include:
All content from all crawled properties mapped to this managed property
Content from the first crawled property that contains a value and, optionally, in which order.
10. Click OK.
To create a managed property by renaming an existing one
site collection.
2. Go to the Search Schema page for the tenant or for a site collection.
For the tenant, sign in to the Microsoft 365 Admin Center. Then, choose Admin > SharePoint. You're
now in the SharePoint admin center. Click search, and then on the search administration page, click
Manage Search Schema.
For the site collection, on your site, go to Settings, click Site settings and then under Site Collection
Administration, click Search Schema.
3. On the Managed Properties page, find an unused managed property. By unused, we mean that the
property is not mapped to a crawled property: the Mapped Crawled Properties column is empty. See
the Default unused managed properties table for more details. Point to the managed property, click the
arrow, and then click Edit/Map property.
4. On the Edit Managed Property page, in the Main characteristics section, under Alias, enter a name in the
field.
then click OK. Repeat this step to map more crawled properties to this managed property.
7. Click OK.
To reindex a list or library
site collection.
2. Browse to the list or library that you want to recrawl, and then do one of the following:
If you want to perform a full crawl of a library, click the LIBRARY tab, and then, on the ribbon, in the
Settings group, click Library Settings.
If you want to perform a full crawl of a list, click the LIST tab, and then, on the ribbon, in the Settings
group, click List Settings.
3. On the Settings page, in the General Settings section, click Advanced settings.
4. On the Advanced Settings page:
If you want to reindex a library: in the Reindex Library section, click Reindex Document Library.
If you want to reindex a list: in the Reindex List section, click Reindex List.
5. Click OK.
The full reindex of the list or library will be performed during the next scheduled crawl.
Default unused managed properties

The following table provides an overview of the default unused managed properties that you can reuse and
rename using an Alias.
MANAGED PROPERTY MANAGED PROPERTY NAME

MANAGED PROPERTY TYPE COUNT CHARACTERISTICS RANGE
Date 10 Queryable Date00 to Date09
Date 20 Multivalued, Queryable, RefinableDate00 to

Refinable, Sortable, RefinableDate19
Retrievable
Date (SharePoint Server 2 Queryable, Refinable, RefinableDateInvariant00 to

2019) Sortable, Retrievable RefinableDateInvariant01
Date (SharePoint Server 5 Queryable, Refinable, RefinableDateSingle00 to

2019) Sortable, Retrievable RefinableDateSingle04
Decimal 10 Queryable Decimal00 to Decimal09
Decimal 10 Multivalued, Queryable, RefinableDecimal00 to

Refinable, Sortable, RefinableDecimal09
Retrievable
Double 10 Queryable Double00 to Double09
Double 10 Multivalued, Queryable, RefinableDouble00 to

Refinable, Sortable, RefinableDouble09
Retrievable
Integer 50 Queryable Int00 to Int49
Integer 50 Multivalued, Queryable, RefinableInt00 to

Refinable, Sortable, RefinableInt49
Retrievable
String (SharePoint Server 100 Multivalued, Queryable, RefinableString00 to

2013) Refinable, Sortable, RefinableString99
Retrievable
String (SharePoint Server 200 Multivalued, Queryable, RefinableString00 to

2019) Refinable, Sortable, RefinableString199
Retrievable
How to use an Alias: an example

Say that you want to create a managed property that contains employee numbers, and you want users to be able
to search for these by typing "EmployeeID:12345", where "12345" is an example employee number. As this
managed property is not of the type Text or Yes/No, you'll follow the steps in To create a managed property by
renaming an existing one with this input:
Choose an unused managed property of the type integer, see the table Default unused managed
properties. Use any unused property from Int00 to Int49 if you only want users to be able to query on the
employee number, or from RefinableInt00 to RefinableInt49 if you want users to be able to query,
refine, sort etc. on employee number.
Give the property an Alias, in this example EmployeeID.
Map the EmployeeID property to the crawled property that contains the employee numbers.
Search schema changes that require content to be reindexed

MANAGED PROPERTY SETTING ACTION REQUIRES A FULL CRAWL TO REINDEX
Mapping a crawled to a managed Add/Delete mapping Yes

property
Token normalization Enable/Disable Yes
Complete matching Enable/Disable Yes
Lanugage neutral tokenization Enable/Disable Yes
Company name extraction Enable/Disable Yes
Custom entity extraction Enable/Disable Yes
Searchable Enable/Disable Yes
Queryable Enable Yes
Queryable Disable No
Retrievable Enable Yes
Retrievable Disable No
Refinable Enable (if not already Sortable) Yes
Refinable Disable No
Sortable Enable (if not already Refinable) Yes
Sortable Disable No
Alias Add/Delete No
Add or remove a file type from the search index in
SharePoint Server

Before you start, you may want to read Default crawled file name extensions and parsed file types in SharePoint
Server. This article lists the file types that SharePoint Server by default includes in the search index.
If your SharePoint environment is hybrid and uses cloud hybrid search, you can decide what types of files that are
stored in SharePoint Server that you want to add or remove from the Office 365 index. Use the following
procedures on the server that hosts the crawl component in the cloud Search service application.
To add or remove a file type from the search index:
1. Add or remove the file name extension from the list of file name extensions on the Manage File Types page.
See Add or remove file name extensions from the Manage File Types page.
2. Run a full crawl for all content sources that this change might affect.
When the full crawl finishes, the search index will include or exclude properties from files of the type that you have
either added or removed.
To start including content from a file type, in the search index:
1. On a server that hosts a content processing component in the Search service application, check whether the
format of the file type is supported by a built-in format handler or a third-party filter-based format handler
(iFilter). Built-in format handlers are the those that SharePoint Server has by default. See View information
about file formats that can be parsed.
2. If the server does not have a format handler for the file type, install a third-party filter-based format handler
on all servers hosting content processing components in the Search service application. Follow the
installation guidance given by the manufacturer of the third-party format handler.
3. On all servers that host a content processing component in the Search service application, enable parsing
of the format of the file and the file name extension. See Enable or disable parsing of a file format.
When the full crawl finishes, the search index will include content from files of the type that you enabled.
To stop including content from a file type, in the search index:
1. On a server that hosts a content processing component in the Search service application, check whether the
format of the file type is supported by a built-in format handler or a third-party filter-based format handler
(iFilter). Built-in format handlers are those that SharePoint Server has by default.
2. On all servers that host a content processing component in the Search service application, disable parsing
of the format of the file and the file name extension. See Enable or disable parsing of a file format.
When the full crawl finishes, the search index will exclude content from files of the type that you disabled.
Add or remove file name extensions from the Manage File Types page
To add a file name extension to the Manage File Types page
application.
2. In Central Administration, in the Application Management section, click Manage Service Applications.
3. On the Manage Service Applications page, in the list of service applications, click the Search service
application.
4. On the Search Administration page, in the Crawling section, click File types. The Manage File Types page
appears.
5. Click New File Type.
6. In the File extension box, type the extension of the file type that you want to add.
7. Click OK.
8. Verification: make sure that the extension appears in the list of file types on the Manage File Types page.
To remove a file name extension from the Manage File Types page
application.
application.
4. On the Search Administration page, in the Crawling section, click File types. The Manage File Types page
appears.
5. Point to the file type that you want to remove, click the arrow that appears and then click Delete.
6. Click OK to confirm that you want to delete the file type.
7. Verification: make sure that the extension no longer appears in the list of file types on the Manage File
Types page.
View information about file formats that can be parsed

To view information about the file formats that the content processing component has format handlers for, you
have to use Windows PowerShell.
application.
2. Start a SharePoint Management Shell on the server.
3. At the Microsoft PowerShell command prompt, type the following commands:
Get-SPEnterpriseSearchFileFormat -SearchApplication $ssa
The result is a list of all file formats that the content processing component in the Search service
application referenced by `$ssa` can parse. For each file format the list shows:
The file name extension and mime type

The type of format handler that the content processing component uses to parse the format. The entry
"BuiltIn:True" indicates a built-in format handler. The entry "BuiltIn:False" indicates a third-party filter-based
format handler.
The parsing state of the format. The entry "Enabled:True" indicates that parsing is enabled. The entry
"Enabled:False" indicates that parsing is disabled.
Enable or disable parsing of a file format

To enable or disable parsing of a file format, you have to use Windows PowerShell.
To enable parsing of a file format using a built-in format handler
application.
2. Start a SharePoint Management Shell on the server that hosts the content processing component.
Set-SPEnterpriseSearchFileFormatState -SearchApplication $ssa FormatID $TRUE
Where:
FormatID is the identity of the file format.
$TRUE enables the format handler to parse the file type.
4. Restart the SharePoint Search Host Controller service to apply the changes:
Open a command prompt window on the server that hosts the content processing component. On the
Start menu, click All Programs, click Accessories, right-click Command Prompt and then click Run as
administrator.
To stop the SharePoint Search Host Controller, type this command: net stop spsearchhostcontroller
To restart the SharePoint Search Host Controller, type this command: net start spsearchhostcontroller
5. Verification: show the list of file name extensions and file formats that the content processing component can
parse and make sure that the file name extension is there. See View information about file formats that can be
parsed.
To disable parsing of a file format using a built-in format handler
application.
Set-SPEnterpriseSearchFileFormatState -SearchApplication $ssa FormatID $FALSE
Where:
FormatID is the identity of the file format.
$FALSE disables the format handler from parsing the file type.
administrator.
parse and make sure that the file name extension is not there. See View information about file formats that can
be parsed.
To enable parsing of a file format using a third-party filter-based format handler
application.
New-SPEnterpriseSearchFileFormat -SearchApplication $ssa FileNameExtension FileFormat
application/FileApplication
Where:
FileNameExtension is the file name extension of the file type.
FileFormat is the format of the file type. The format is often the name of the application.
application/FileApplication is the mime type of the file type. The mime type must consist of a type and a
subtype. In this example, application is the type and FileApplication is the subtype. For example, for Word
files, the type is application and the subtype is msword. Together they form the complete mime type:
application/msword.
administrator.
parse and make sure that the file name extension is there. See View information about file formats that can be
parsed.
To disable parsing of a file format using a third-party filter-based format handler
application.
Remove-SPEnterpriseSearchFileFormat -SearchApplication $ssa -Identity FileNameExtension
Where:
FileNameExtension is the file name extension of the file type.
administrator.
parse and make sure that the file name extension is not there. See View information about file formats that can
be parsed.
Delete items from the search index or from search
results in SharePoint Server

If you want to remove the metadata of an item from the search index or from the search results, you remove the
URL of that item. To remove a URL from the search index, use the Remove the Item from the Index option that
is available through the crawl log. To remove a URL from search results, use the Search Result Removal feature
that allows for bulk URL removal. This can provide a more efficient method if many search results should be
removed.
NOTE
If your SharePoint environment is hybrid and uses cloud hybrid search, you index your on-premises content in your
search index in Office 365. See Learn about cloud hybrid search for SharePoint for guidance on deleting the metadata
of an on-premises item and deleting on-premises search results from the search index in Office 365.
For SharePoint Server 2019, removing the URL of an item affects both the classic and modern search experiences.
Remove an item from the search index

To remove an item from the search index
application.
2. On the SharePoint Server Central Administration home page, in the Application Management section,
click Manage service applications.
3. On the Manage Search Applications page, click the Search service application.
4. On the Search Administration page, in the Diagnostics section, click Crawl Log.
5. On the Crawl Log page, click URL View.
6. Do one of the following:
If you know the URL of the item that you want to remove, type the URL in the box.
If you do not know the URL of the item that you want to remove, search for it by using the filters Content
Source, Status or Message.
7. Click Search.
8. Find and point to the URL of the item that you want to remove, click the arrow and then click Remove the
item from the Index.
9. In the confirmation dialog that appears, click OK to confirm that you want to remove the item from the
index.
10. Verification: the text Removed from the search index by Admin appears under the URL in the crawl
log.
Remove an item from the search results
To remove an item from the search results
application.
2. On the SharePoint Server Central Administration home page, in the Application Management section,
3. On the Manage Search Applications page, click the Search service application.
4. On the Search Administration page, in the Queries and Results section, click Search Result Removal.
5. On the Exclude URLs From Search Results page, in the URLs to remove box, type the URLs of the items
that you want to remove from the search results.
6. Click Remove Now.
Reset the search index in SharePoint Server

When you reset the search index in SharePoint Server, all content is immediately removed from the search index
and users will not be able to retrieve search results. After you reset the search index, you must perform a full crawl
of one or more content sources to create a new search index. Users will be able to retrieve search results again
when the full crawl is finished and the new search index is created.
NOTE
After a search index reset, a full crawl won't restore all analytics features that are powered by the Analytics Processing
Component. Examples of analytics features are raising or demoting items in search results based on which search results
users have clicked, or displaying the number of times a search result has been viewed. For more information, see Overview of
analytics processing in SharePoint Server.
If you can, you should perform a backup and restore of your Search service application instead of a search index reset. These
procedures will fully restore all features that are powered by the Analytics Processing Component. For more information, see
Back up Search service applications in SharePoint Server and Restore Search service applications in SharePoint Server.
NOTE
If your SharePoint environment is hybrid and uses cloud hybrid search, you index your on-premises content in your search
index in Office 365. See Learn about cloud hybrid search for SharePoint for guidance on deleting metadata of on-premises
items from the search index in Office 365.
Before you begin

Make sure that you are not running a backup of the Search service application.
Reset the search index

Use the following procedure to reset the search index.
To reset the search index
application for which you want to reset the search index.
2. On the SharePoint Central Administration home page, in the Application Management section, click
3. On the Manage Search Applications page, click the Search service application for which you want to reset
the search index.
4. On the Search Administration page, under System Status, verify that the Administrative status of the
Search service application is Running and not Paused.
5. On the Search Administration page, in the Crawling section, click Index Reset.
6. On the Index Reset page, verify that the Deactivate search alerts during reset check box is checked, and
then click Reset Now.
7. In the confirmation dialog box that appears, click OK to confirm that you want to reset the index.
The Search Administration page opens and the System Status is displayed.
After the search index reset is complete, you must perform a full crawl of all the content sources that you want to
include in the search index. For more information, see Add, edit, or delete a content source in SharePoint 2013
Preview. Users will not be able to retrieve search results until you create a new search index. After the full crawl has
completed and a new search index has been created, you must also re-enable search alerts. See Enable search
alerts.

The following articles provide information about how to manage crawling in SharePoint Server and apply to
both the classic and modern search experiences.
CONTENT DESCRIPTION
Best practices for crawling in SharePoint Server Learn how to manage crawls effectively.
Add, edit, or delete a content source in SharePoint Server Learn how to create a content source to specify what type of
content to crawl, schedules for crawling, start addresses, and
crawl priority.
Change the default account for crawling in SharePoint Server Change the user name or password of the account that the
Search service uses by default for crawling.
Start, pause, resume, or stop a crawl in SharePoint Server Learn how to start, pause, resume or stop a full or
incremental crawl of a content source.
Manage continuous crawls in SharePoint Server Learn how to enable continuous crawls of SharePoint content
to help keep the search index and search results as fresh as
possible.
Manage crawl rules in SharePoint Server Learn how to specify a content access account, create crawl
rules to include or exclude directories, and prioritize crawl
rules.
Configure and use the Exchange connector for SharePoint Learn how to create a crawl rule and add a content source to
Server crawl Exchange Server public folders.
Configure and use the Documentum connector in SharePoint Learn how to install and configure the Microsoft SharePoint
Server Indexing Connector for Documentum.
Configure and use the Lotus Notes connector for SharePoint Learn about the administrative roles, required software, user
Server accounts, and processes that are required to install and
operate the Lotus Notes Client and the Lotus Notes
Connector to work with SharePoint Server search.
Configure time-out values for crawler connections in Change how long the SharePoint search crawler will wait for a
SharePoint Server connection to a content repository or for a response to a
connection attempt.
Configure the crawler in case of SSL certificate warnings in Specify whether a SharePoint crawler will crawl a site if there
SharePoint Server is a problem with the site's Secure Sockets Layer (SSL)
certificate.
Configure proxy server settings for Search in SharePoint Specify a proxy server to send requests to crawl content or
Server query federated content repositories.
See also
Search in SharePoint Server
Add, edit, or delete a content source in SharePoint
Server

A content source is a set of options that you use to specify what, when, and how to crawl.
When a Search service application is created, a content source named "Local SharePoint sites" is automatically
created and configured for crawling all SharePoint Server sites in the local server farm. You can create additional
content sources to specify other content to crawl and how the system should crawl that content. After you create a
content source, you can edit or delete it at any time.
Cau t i on
Changing a content source requires a full crawl for that content source.
Before you begin

Create a Search service application
Create, edit, or delete a content source

To get to the Manage Content Sources page
application.
2. On the home page of the SharePoint Server Central Administration website, in the Application
Management section, click Manage service applications.
3. On the Manage Service Applications page, click the Search service application.
4. On the Search Administration Page, in the Crawling section, click Content Sources.
To create a content source

2. On the Add Content Source page, in the Name section, in the Name box, type a name for the new content
source.
3. In the Content Source Type section, select the type of content that you want to crawl.
4. In the Start Addresses section, in the Type start addresses below (one per line) box, type the URLs
from which the crawler should begin crawling.
5. In the Crawl Settings section, select the crawling behavior that you want.
6. In the Crawl Schedules section, to specify a schedule for full crawls, select a defined schedule from the
Full Crawl list. A full crawl crawls all content that is specified by the content source, regardless of whether
the content has changed. To define a full crawl schedule, click Create schedule.
7. To specify a schedule for incremental crawls, select a defined schedule from the Incremental Crawl list.
An incremental crawl crawls content that is specified by the content source that has changed since the last
crawl. To define a schedule, click Create schedule. You can change a defined schedule by clicking Edit
schedule.
NOTE
For a content source that is of type SharePoint Server sites, you can enable continuous crawls. For more
information, see Manage continuous crawls in SharePoint Server.
8. To set the priority of this content source, in the Content Source Priority section, on the Priority list,
select Normal or High.
9. Click OK.
To edit a content source

1. You can edit a content source to change the schedule on which the content is crawled, the crawl start
addresses, the content source priority, or the name of the crawl. Crawl settings and content source type
cannot be changed when you edit a content source.
2. On the Manage Content Sources page, in the list of content sources, point to the name of the content
source that you want to edit, click the arrow that appears, and then click Edit.
3. After you make the changes that you want, click OK.
To delete a content source

source that you want to delete, click the arrow that appears, and then click Delete.
2. Click OK to confirm that you want to delete this content source.
Change the default account for crawling in
SharePoint Server

The account that the SharePoint Server Search service uses by default for crawling is called the default content
access account. It must be a domain account with a password that is current in Active Directory Domain Services
(AD DS ). If the password of this domain account expires, the Search service is not able to use the account to crawl
content.
The password of the default content access account has two additional dependencies on the domain account
password in AD DS:
If you change the password of the account in AD DS, you must make the same change for the password of
the default content access account in SharePoint Server.
If you want to change the password of the default content access account in SharePoint Server, you must
first change the password in AD DS. This is because the credentials that you enter for the default content
access account in SharePoint Server are checked against those in AD DS. If you enter a new password for
the default content access account before the account password is changed in AD DS, an error will result
and the password of the default content access account will not be changed.
The following procedure changes the user name and password for the default content access account. You can
specify a different account for crawling particular URLs by using a crawl rule. If you specify a different account in a
crawl rule and you want to change the password of that account, you must change the crawl rule. For more
information, see Manage crawl rules in SharePoint Server.
To change the default content access account
1. Verify that the account that performs this procedure is a service application administrator for the Search
service application that you want to configure.
change the default content access account.
4. On the Search Administration page for the Search service application, in the System Status section, find
the Default content access account, which is of the form Domain\UserName.
5. Click the default content access account name. The Default Content Access Account dialog box appears.
6. (Optional) In the Account text box, type a new user name.
7. In the Password text box and in the Confirm Password text box, type the new password, and then click
OK.
See also
Manage crawl rules in SharePoint Server
Start, pause, resume, or stop a crawl in SharePoint
Server

When you perform a full crawl for a content source, all content specified by the content source is crawled even if
the content already exists in the search index. You can start a full crawl for each content source separately.
Alternatively, clicking the Start all crawls link on the Manage Content Sources page causes the content
specified in all content sources to be crawled using an incremental crawl, unless either of the following
conditions is true:
The system detects that a full crawl is required.
The content source is of type SharePoint Sites and Enable Continuous Crawls is selected in the Crawl
Schedules section on the Add/Edit Content Source page for the content source. Continuous crawl is a
new crawl schedule option in SharePoint Server that applies only to content sources of type SharePoint
Sites.
Before you begin

Before you can perform the procedures in this article, there must be a Search service application in the farm so
that you can perform crawls. For more information, see Create and configure a Search service application in
SharePoint Server 2016. A Search service application can contain one or more content sources. Each crawl that
you perform is associated with a particular content source, which specifies the content to crawl.
Start, pause, resume, or stop a crawl for a content source

From the Manage Content Sources page, you can start, pause, resume, or stop a crawl for any content source
that does not have continuous crawls enabled.
To start, pause, resume, or stop a crawl for a content source
application.
2. In Central Administration, in the Application Management section, click Manage Service
Applications.
application.
4. On the Search Administration page, in the Crawling section, click Content Sources.
source that you want, click the arrow and then click one of the following menu items. (The value in the
Status column might not automatically refresh when the value changes. To update values in the Status
column, refresh the Manage Content Sources page by clicking Refresh.)
Start Full Crawl. The value in the Status column changes to Crawling Full for the selected content
source.
Start Incremental Crawl. The value in the Status column changes to Crawling Incremental for the
selected content source.
Resume Crawl. The value in the Status column changes back to Crawling Full or Crawling
Incremental for the selected content source.
Pause Crawl. The value in the Status column changes to Paused for the selected content source.
NOTE
Pausing a crawl has the disadvantage that references to crawl components can remain in the
MSSCrawlComponentsState table in the search administration database. This can cause a problem if you want to
remove any crawl components (say, because you want to remove a server that hosts those components from the
farm). However, when you stop a crawl, references to crawl components in the MSSCrawlComponentsState table
are deleted. Therefore, if you want to remove crawl components, it is better to stop crawls than to pause crawls.
For more information about removing crawl components, see Best practices for crawling in SharePoint Server.
Stop Crawl. You must click OK to confirm that you want to stop the crawl. The value in the Status
column changes to Idle for the selected content source.
NOTE
If you stop a full or incremental crawl that is in progress (for example, so that you can change the search topology),
the next time a crawl occurs for that content source, the Search system automatically performs a full crawl.
Disable continuous crawls

From the Manage Content Sources page, continuous crawls can be enabled or disabled, but they cannot be
paused or resumed. If you want to pause a content source that is currently in continuous crawl mode, disable
continuous crawl first. For more information, see Manage continuous crawls in SharePoint Server.
Manage continuous crawls in SharePoint Server

Enable continuous crawls is a crawl schedule option that is an alternative to incremental crawls. This option is
new in SharePoint Server and applies only to content sources of type SharePoint Sites.
Continuous crawls crawl SharePoint Server sites frequently to help keep search results fresh. Like incremental
crawls, a continuous crawl crawls content that was added, changed, or deleted since the last crawl. Unlike an
incremental crawl, which starts at a particular time and repeats regularly at specified times after that, a
continuous crawl automatically starts at predefined time intervals. The default interval for continuous crawls is
every 15 minutes. Continuous crawls help ensure freshness of search results because the search index is kept up
to date as the SharePoint Server content is crawled so frequently. Thus, continuous crawls are especially useful
for crawling SharePoint Server content that is quickly changing.
A single continuous crawl includes all content sources in a Search service application for which continuous crawls
are enabled. Similarly, the continuous crawl interval applies to all content sources in the Search service
application for which continuous crawls are enabled.
You cannot run multiple full crawls or multiple incremental crawls for the same content source at the same time.
However, multiple continuous crawls can run at the same time. Therefore, even if one continuous crawl is
processing a large content update, another continuous crawl can start at the predefined time interval and crawl
other updates. Continuous crawls of a particular content repository can also occur while a full or incremental
crawl is in progress for the same repository.
A continuous crawl doesn't process or retry items that repeatedly return errors. Such errors are retried during a
"clean-up" incremental crawl, which automatically runs every four hours for content sources that have continuous
crawl enabled. Items that continue to return errors during the incremental crawl will be retried during future
incremental crawls, but will not be picked up by the continuous crawls until the errors are resolved.
You can set incremental crawl times on the Search_Service_Application_Name: Add/Edit Content Source page,
but you can change the frequency interval for continuous crawls only by using Microsoft PowerShell.
To enable continuous crawls for an existing content source

application.
applications.
4. On the Search_Service_Application_Name: Search Administration page, in the Quick Launch, under
Crawling, click Content Sources.
5. On the Search_Service_Application_Name: Manage Content Sources page, click the SharePoint content
source for which you want to enable continuous crawl.
6. In the Crawl Schedules section, select Enable Continuous Crawls.
7. Click OK.
8. Verification: On the Search_Service_Application_Name: Manage Content Sources page, verify that the
Status column has the status Crawling Continuous.
To enable continuous crawls for a new content source

application.
applications.
5. On the Search_Service_Application_Name: Manage Content Sources page, click New Content Source.
6. Create a content source of the type SharePoint Sites.
In the Name section, type a name in the Name field.
In the Content Source Type section, select SharePoint Sites.
In the Start Addresses section, type the start address or addresses.
In the Crawl Settings section, select the crawling behavior for all start addresses.
In the Crawl Schedules section, select Enable Continuous Crawls.
7. Click OK.
newly added content source appears and that the Status column has the status Crawling Continuous.
To disable continuous crawls for a content source

application.
applications.
5. On the Search_Service_Application_Name: Manage Content Sources page, click the SharePoint content
source for which you want to disable continuous crawls.
6. In the Crawl Schedules section, clear Enable Incremental Crawls. This disables continuous crawls.
7. To confirm that you want to disable continuous crawls, click OK.
8. Optional: click Edit schedule to change the schedule for incremental crawls, and then click OK.
9. On the Search_Service_Application_Name: Edit Content Source page, click OK.
Status column has changed to Idle. This might take some time, because all URLs that remain in the crawl
queue are still crawled after you disable continuous crawls.
To disable continuous crawls for all content sources

1. Verify that the user account that performs this procedure is an administrator for the Search service
application.
2. Start a SharePoint Management Shell on a server in the farm.
$SSA = Get-SPEnterpriseSearchServiceApplication
$SPContentSources = $SSA | Get-SPEnterpriseSearchCrawlContentSource | WHERE {$_.Type -eq "SharePoint"}
foreach ($cs in $SPContentSources)
{
$cs.EnableContinuousCrawls = $false
$cs.Update()
}
Status column has changed to Idle for all content sources. This might take some time, because all URLs that
remain in the crawl queue are still crawled after you disable continuous crawls.
To change the continuous crawl interval

group.
2. Start a SharePoint Management Shell.
$ssa.SetProperty("ContinuousCrawlInterval",n)
Where:
n is the regular interval in minutes at which you want to continuous crawls to start. The default interval is
every 15 minutes. The shortest interval that you can set is 1 minute.
> [!NOTE]
> If you reduce the interval, you increase the load on SharePoint Server and the crawler. Make sure that you
plan and scale out for this increased consumption of resources accordingly.
See also
Set-SPEnterpriseSearchCrawlContentSource
Manage crawl rules in SharePoint Server

You can add a crawl rule to include or exclude specific paths when you crawl content. When you include a path,
you can provide alternative account credentials to crawl it. In addition to creating or editing crawl rules, you can
test, delete, or reorder existing crawl rules.
Use crawl rules to do the following:
Prevent content on a site from being crawled. For example, if you created a content source to crawl
http://www.contoso.com, but you do not want the search system to crawl content from the subdirectory
http://www.contoso.com/downloads, create a crawl rule to exclude content from that subdirectory.
Crawl content on a site that would be excluded otherwise. For example, if you excluded content from
http://www.contoso.com/downloads from being crawled, but you want content in the subdirectory
http://www.contoso.com/downloads/content to be crawled, create a crawl rule to include content
from that subdirectory.
Specify authentication credentials. If a site to be crawled requires different credentials than those of
the default content access account, create a crawl rule to specify the authentication credentials.
You can use the asterisk (*) as a wildcard character in crawl rules. For example, to exclude JPEG files from crawls
on http://www.contoso.com, create a crawl rule to exclude http://www.contoso.com/\*.jp.
The order of crawl rules is important, because the first rule that matches a particular set of content is the one that
is applied.
To create or edit a crawl rule

application.
Applications.
application.
4. On the Search Administration page, in the Crawling section, click Crawl Rules. The Manage Crawl Rules
page appears.
5. To create a new crawl rule, click New Crawl Rule. To edit an existing crawl rule, in the list of crawl rules,
point to the name of the crawl rule that you want to edit, click the arrow that appears, and then click Edit.
6. On the Add Crawl Rule page, in the Path section:
In the Path box, type the path to which the crawl rule will apply. You can use standard wildcard characters
in the path.
To use regular expressions instead of wildcard characters, select Use regular expression syntax for
matching this rule.
7. In the Crawl Configuration section, select one of the following options:
Exclude all items in this path. Select this option if you want to exclude all items in the specified path
from crawls. If you select this option, you can refine the exclusion by selecting Exclude complex URLs
(URLs that contain question marks (?)) to exclude URLs that contain parameters that use the question
mark (?) notation.
Include all items in this path. Select this option if you want all items in the path to be crawled. If you
select this option, you can further refine the inclusion by selecting any combination of these options:
Follow links on the URL without crawling the URL itself. Select this option if you want to crawl links
contained within the URL, but not the starting URL itself.
Crawl complex URLs (URLs that contain a question mark (?)). Select this option if you want to crawl
URLs that contain parameters that use the question mark (?) notation.
Crawl SharePoint Server content as http pages. Normally, SharePoint Server sites are crawled by
using a special protocol. Select this option if you want SharePoint Server sites to be crawled as HTTP
pages instead. When the content is crawled by using the HTTP protocol, item permissions are not stored.
8. In the Specify Authentication section, perform one of the following actions:
NOTE
This option is not available unless the Include all items in this path option is selected in the Crawl Configuration
section.
To use the default content access account, select Use the default content access account.
If you want to use a different account, select Specify a different content access account and then in the
Account box, type the user account name that can access the paths that are defined in this crawl rule.
Next, in the Password and Confirm Password boxes, type the password for this user account. To prevent
basic authentication from being used, select the Do not allow Basic Authentication check box. The
server attempts to use NTLM authentication. If NTLM authentication fails, the server attempts to use basic
authentication unless the Do not allow Basic Authentication check box is selected.
To use a client certificate for authentication, select Specify client certificate, expand the Certificate
menu, and then select a certificate.
To use form credentials for authentication, select Specify form credentials, type the form URL (the
location of the page that accepts credentials information) in the Form URL box, and then click Enter
Credentials. When the logon prompt from the remote server opens in a new window, type the form
credentials with which you want to log on. You are prompted if the logon was successful. If the logon was
successful, the credentials that are required for authentication are stored on the remote site.
To use cookies, select Use cookie for crawling, and then select Obtain cookie from a URL to obtain a
cookie from a website or server. Or, select Specify cookie for crawlingto import a cookie from your local
file system or a file share. You can optionally specify error pages in the Error pages (semi-colon
delimited) box.
To allow anonymous access, select Anonymous access.
9. Click OK.
To test a crawl rule on a URL

application.
Applications.
application.
4. On the Search Administration page, in the Crawling section, click Crawl Rules.
5. On the Manage Crawl Rules page, in the Type a URL and click test to find out if it matches a rule box,
type the URL that you want to test.
6. Click Test. The result of the test appears below the Type a URL and click test to find out if it matches
a rule box.
To delete a crawl rule

application.
Applications.
application.
5. On the Manage Crawl Rules page, in the list of crawl rules, point to the name of the crawl rule that you
want to delete, click the arrow that appears, and then click Delete.
6. Click OK to confirm that you want to delete this crawl rule.
To reorder crawl rules

application.
Applications.
application.
5. On the Manage Crawl Rules page, in the list of crawl rules, in the Order column, specify the crawl rule
position that you want the rule to occupy. Other values shift accordingly.
Configure and use the Exchange connector for
SharePoint Server
Before you begin

Create a Search service application
Ensure that the crawler has at least Read permission to the Exchange Server public folder.
Create a crawl rule

This following procedure describes how to create a crawl rule. You must create a crawl rule if the default content
access account does not have Read permission to the Exchange Server public folders that you want to crawl.
To create a crawl rule
application.
application.
6. On the Add Crawl Rule page, in the Path section, in the Path box, type the path to which the crawl rule will
apply. You can use standard wildcard characters in the path.
NOTE
When creating a crawl rule, the URL that you type inside the Path box should be in the following form:
_<protocol>://hostname/*_where <protocol> is the protocol that you want to use (typically http or https), and
hostname is the NetBIOS or fully qualified domain name of the server that is running Exchange Server.
7. In the Crawl Configuration section, select Include all items in this path.
8. In the Specify Authentication section, select the type of crawl authentication to use. This section is
available only if Include all items in this path is selected.
9. Click OK.
Add a content source for Exchange Server public folders

Use one of the following procedures to create a content source for Exchange Server public folders. Which
procedure you should follow depends on the Exchange Server version. You can choose to add a content source to
crawl public folders in:
Exchange Server 2007 and Exchange Server 2007 with Service Pack 1 (SP1)
Exchange Server 2007 with Service Pack 2 (SP2) and Exchange 2010
To add a content source for Exchange Server 2007 and Exchange Server 2007 SP1 public folders
application.
6. On the Add Content Source page, in the Name box, type a name for the new content source.
7. In the Content Source Type section, select Exchange Public Folders.
8. In the Start Addresses section, in the Type start addresses below (one per line) box, type the URLs for
the Exchange Server public folders that you want to crawl. These URLs are typically in one of the following
forms:
<protocol>:// host name/public
Where _\<protocol\>_ can be http or https, and _host name_ is the NetBIOS or fully qualified domain name
(FQDN) of the server that is running Exchange Server.
<protocol>:// host name/public/ subfolder
Where _\<protocol\>_ can be http or https, _host name_ is the NetBIOS or FQDN of the server that is running
Exchange Server, and _subfolder_ is the name of the specific subfolder that you want to crawl.
For example, if you want to crawl all subfolders in the public folder on a server that is named exch-01 and that is in
the Contoso domain, and that server does not use SSL, you could type either http://exch-01/public or http://exch-
01.contoso.com. To crawl only a specific subfolder named Bob in the same public folder, type http://exch-
01/public/bob or http://exch-01.contoso.com/bob.
NOTE
For performance reasons, you cannot add the same start addresses to multiple content sources.
10. In the Crawl Schedules section, you can choose to specify when to start full and incremental crawls:
To create a full crawl schedule, click the Create Schedule link below the Full Crawl list.
To create an incremental crawl schedule, click the Create schedule link below the Incremental Crawl list.
11. Click OK.
To add content sources for Exchange Server 2007 SP2 and Exchange 2010 public folders
application.
2. Open a web browser and go to the Outlook Web Access webpage for the Exchange Server that contains the
public folders that you want to crawl.
3. Log on to Outlook Web Access using any user account that has Read permissions on the public folders that
you want to crawl.
4. Go to the public folder that you want to crawl, right-click the folder, and then select Open in New Window.
5. When the new window opens, go to the address bar and copy the complete URL. This is the Outlook Web
Access public folder address.
9. Click New Content Source.
10. On the Add Content Source page, in the Name box, type a name for the new content source.
11. In the Content Source Type section, select Exchange Public Folders.
12. In the Start Addresses section, paste the Outlook Web Access public folder address that you copied in step
5.
14. In the Crawl Schedules section, you can choose to specify when to start full and incremental crawls:
To create a full crawl schedule, click the Create Schedule link below the Full Crawl list.
To create an incremental crawl schedule, click the Create schedule link below the Incremental Crawl list.
15. Click OK.
Configure and use the Documentum connector in
SharePoint Server

This article describes how to install and configure the Microsoft SharePoint Server Indexing Connector for
Documentum.
The Microsoft SharePoint Server Indexing Connector for Documentum enables you to index content that is stored
in the EMC Documentum system. This article describes how to install and configure the Indexing Connector for
Documentum for use with SharePoint Server.
The Indexing Connector for Documentum:
Is a 64-bit connector based on the SharePoint Server Search Connector Framework.
Supports multiple versions of EMC Documentum Content Server.
Indexes Documentum objects and object metadata. See Supported and unsupported Documentum object
types and properties in SharePoint Server.
Supports Documentum security definitions and policies.
Supports Microsoft PowerShell for automated configuration and administration. See Using the
SPEnterpriseSearchDCTMConnectorConfig cmdlet.
Has a configurable search results URL to support multiple Documentum client applications.
Supports file and folder exclusion for crawling.
Before you begin

Before you begin this operation, review the following system prerequisites and requirements:
The supported operating systems are Windows Server 2008 R2, Windows Server 2008 Service Pack 2, and
Windows Server 2012.
One of the following SharePoint 2019, SharePoint 2016, or SharePoint 2013 Products is installed and
configured:
Microsoft SharePoint Server Enterprise
Microsoft SharePoint Server Standard
A Search service application is installed and configured.
A Documentum Foundation Services (DFS ) Server with a version that is compatible with DFS Productivity
Layer 6.7 SP2 is installed on a Windows host.
DFS Productivity Layer 6.7 SP2 is installed and you have access to the .NET assemblies that are included in
the DFS Productivity Layer 6.7 SP2. The Indexing Connector for Documentum uses DFS as the
connectivity API to access Documentum repositories.
Documentum Content Server is installed. The supported versions of Documentum Content Server are
determined by DFS 6.7 SP2. You can find a detailed list in the DFS Productivity Layer 6.7 SP2 release
notes. You can download the release notes from the EMC customer support site https://powerlink.emc.com.
Configure the Indexing Connector for Documentum with -ACLTranslation "Claims" if you have to crawl
Documentum repositories that have Documentum Trusted Content Services (TCS ) enabled. You can also
use this connector configuration to enable automatic mapping between Windows Active Directory users
and Documentum users, regardless of whether the repository has TCS enabled.
Overview
The following steps provide a high-level overview of the tasks that are involved to install and configure the
Indexing Connector for Documentum for use with SharePoint Server.
1. Preparation
1. Ensure that your system meets the system prerequisites and requirements in the section Before you begin.
2. Download the SharePoint Server 2016 Indexing Connector for Documentum from the Microsoft Download
Center.
3. Decide which Documentum content access account to use for crawling.
4. Prepare the SharePoint servers that host a crawl component. On each server:
Set the DFS Productivity Layer .NET assemblies.
Edit the machine.config file to set the Documentum bindings.
2. Install the Indexing Connector for Documentum
1. Install the Indexing Connector for Documentum on each SharePoint server in the farm that hosts a crawl
component.
2. Register the Indexing Connector for Documentum to the Search service application by using Microsoft
PowerShell.
3. Configure the Indexing Connector for Documentum
Configure the Indexing Connector for Documentum on each SharePoint server in the farm that hosts a crawl
component by using the Indexing Connector for Documentum PowerShell cmdlet. Choose one of the following
configurations:
CONFIGURATION ACL TRANSLATION DESCRIPTION SEE THIS SECTION
Support crawling EMC Claims You enable automatic user Configure the Indexing
Documentum Trusted mapping by configuring a Connector for Documentum
Content Services (TCS) separate Security Trimmer to support TCS and
content or regular Sync Service and pre- and automatic user mapping
Documentum content with post-trimmers.
automatic user mapping.
CONFIGURATION ACL TRANSLATION DESCRIPTION SEE THIS SECTION
Support crawling UserMappingTable You manually create a user Configure the Indexing
Documentum content and mapping table in SQL Server Connector for Documentum
use a manually created user to specify how the using a user mapping table
mapping table. Documentum users are
mapped to Active Directory
Domain Services (AD DS) or
Active Directory service
users. You configure the
connector by specifying in
which database you have
created the user mapping
table by using Microsoft
PowerShell.
Support crawling SameAccountName The Indexing Connector for Using the

Documentum content when Documentum assumes that SPEnterpriseSearchDCTMCo
Documentum and Windows Documentum and nnectorConfig cmdlet
user accounts are the same. SharePoint users share the
same account, such as a
shared account in Active
Directory. Once an account
is found that is not valid, the
Indexing Connector for
Documentum discards the
account permission.
Support crawling NoSecurity All users will be able to see Using the
Documentum content all Documentum search SPEnterpriseSearchDCTMCo
without security trimming results. This can be useful if nnectorConfig cmdlet
the search results. you have a public
Documentum repository
that everyone can access,
for example.
4. Configure a Documentum crawl rule and content source in the Search service application by using Central
Administration
1. Create a crawl rule for Documentum.
2. Create a Documentum content source
3. Perform a full crawl.
Prepare the SharePoint servers that host a crawl component

Decide which Documentum content access account to use for crawling
1. You have to specify the Documentum content access account and the password later in the configuration
procedure when you set up crawl rules. The Indexing Connector for Documentum uses the content access
account to retrieve content from the Documentum repository. This account must have the following minimum
permissions:
Read permission to documents that you want to crawl.
Browse permission to cabinets, folders, and records (documents with only metadata) that you want to crawl.
Set the DFS Productivity Layer .NET assemblies
1. Locate the following DFS Productivity Layer .NET assemblies and verify that the version number is
6.7.2000.36 for all files. When extracted to the default path, these files are located in the
%local%\emc-dfs-sdk-6.7\emc-dfs-sdk-6.7\lib\dotnet directory.
Emc.Documentum.FS.DataModel.Core.dll
Emc.Documentum.FS.DataModel.Shared.dll
Emc.Documentum.FS.runtime.dll
Emc.Documentum.FS.Services.Core.dll
2. On each server that hosts a crawl component, log on with an account that is a member of the
Administrators group on that server and deploy the DFS Productivity Layer .NET assemblies to the global
assembly cache %windir%\assembly .
NOTE
You can drag and drop the four DLLs into the global assembly cache ( %windir%\assembly ) to deploy them, but
you might have to turn off User Account Control to do this.
The following procedure explains how to edit the machine.config file on each SharePoint server that hosts a crawl
component to include WCF settings for the DFS Productivity Layer. This is done to make sure that the DFS
Productivity Layer .NET assemblies function correctly.
The WCF settings that you are about to set in Edit the machine.config file allow a maximum of 30 megabytes (MB )
per Documentum content object (the document file plus its metadata) transferred. The administrator can increase
maxReceivedMessageSize in DfsDefaultService binding for larger content.
Edit the machine.config file
1. On each server that hosts a crawl component, open the machine.config file. This file is located in the
directory %windir%\Microsoft.NET\Framework64\v4.0.30319\Config .
2. Copy the following XML snippet to the <configuration> element:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="DfsAgentService" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="10000000" maxBufferPoolSize="10000000" maxReceivedMessageSize="10000000"
messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
<binding name="DfsContextRegistryService" closeTimeout="00:01:00"
openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="10000000" maxBufferPoolSize="10000000" maxReceivedMessageSize="10000000"
messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
maxBytesPerRead="4096" maxNameTableCharCount="16384" />
<transport clientCredentialType="None" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
<binding name="DfsDefaultService" closeTimeout="00:01:00" openTimeout="00:10:00" receiveTimeout="00:20:00"
sendTimeout="00:10:00" allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
maxBufferSize="10000000" maxBufferPoolSize="10000000" maxReceivedMessageSize="30000000" messageEncoding="Text"
textEncoding="utf-8" transferMode="StreamedResponse" useDefaultWebProxy="true">
<readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384" maxBytesPerRead="1048576"
maxNameTableCharCount="16384"/>
<transport clientCredentialType="None" proxyCredentialType="None" realm=""/>
<message clientCredentialType="UserName" algorithmSuite="Default"/>
</security>
</binding>
</basicHttpBinding>
</bindings>
</system.serviceModel>
Install and register the Indexing Connector for Documentum

Install the Indexing Connector for Documentum
1. Download the Indexing Connector for Documentum from the Microsoft Download Center.
2. On each server in the farm that hosts a crawl component, install the Indexing Connector for Documentum
by running the file DCTMIndexConn.exe . Follow the steps in the installation wizard.
Register the Indexing Connector for Documentum to the Search service application
1. Run this procedure on a SharePoint server that hosts a crawl component to register the connector to the
2. Start a SharePoint Management Shell.
3. At the Microsoft PowerShell command prompt, type the following command(s):
New-SPEnterpriseSearchCrawlCustomConnector -SearchApplication "<name of your Search service application>" -
Protocol "dctm" -ModelFilePath "<%CommonProgramFiles%\Microsoft Shared\Web Server
Extensions\15\CONFIG\SearchConnectors\Documentum\MODEL.xml>" -Name "Microsoft SharePoint 2016 Indexing
Connector for Documentum"
Where:
<name of your Search service application> is the name of the Search service application that you are
registering the connector to.
<%CommonProgramFiles%\Microsoft Shared\Web Server
Extensions\15\CONFIG\SearchConnectors\Documentum\MODEL.xml> is the path of the Indexing
Connector for Documentum model file. The default location is given in this example.
Configure the Indexing Connector for Documentum

You configure the connector settings with the Indexing Connector for Documentum PowerShell cmdlet (
Set-SPEnterpriseSearchDCTMConnectorConfig ). The settings are stored in
%CommonProgramFiles%\Microsoft Shared\Web Server
Extensions\15\CONFIG\SearchConnectors\Documentum\DCTMConfig.xml
and must be the same on each SharePoint Server 2016 server that hosts a crawl component.
Which PowerShell cmdlet parameters you use and which additional configuration steps you must perform
depends on configuration mode you choose.
Configure the Indexing Connector for Documentum to support TCS

and automatic user mapping
The following procedures explain how to configure the indexing connector for Documentum to support TCS. The
procedures also show how to enable automatic user mapping by configuring the Security Trimmer Sync Service
and create and deploy custom pre- and post-security trimmers. After completing these procedures, your
Documentum user credentials will be automatically synced with Windows Active Directory Domain Services (AD ),
search results will be trimmed accordingly and users will only be able to retrieve Documentum search results that
they have permission to see.
The Security Trimmer Sync Service maps Documentum users to AD users by looking at the Documentum fields
user_os_domain, user_login_name, user_source and user_ldap_dn. If the user_ldap_dn field is populated, the
Security Trimmer Sync Service will try to extract a domain from the first DC value. For example, if the
user_ldap_dn field is populated with " CN=User Name,
OU=Unit,DC=Domain,DC=Department,DC=Company ", the Security Trimmer Sync Service will extract the
domain from DC=Domain and will ignore DC=Department,DC=Company.
To configure the connector to support TCS and automatic user mapping
1. Start a SharePoint Management Shell on each server that hosts a crawl component.
Set-SPEnterpriseSearchDCTMConnectorConfig -Shared -ACLTranslation "Claims" -DisplayURLPatternForDocument
"http://<MyWebTopServer:PortOfMyWebTopServer>/webtop/component/drl?objectId={ObjectId}&format=
{Format}&RepositoryName={RepositoryName}" -DisplayURLPatternForContainer
"http://<MyWebTopServer:PortOfMyWebTopServer>/webtop/component/drl?objectId={ObjectId}&RepositoryName=
{RepositoryName}"
Set-SPEnterpriseSearchDCTMConnectorConfig -Repository -RepositoryName "<MyRepository1>" -DFSWebServiceURL
@("http://<DFSWebServices>:<30000>/services"), ("http://<DFSWebServices2>:<30000>/services")

@("http://<DFSWebServices>:<30000>/services")
Where:
<MyWebTopServer:PortOfMyWebTopServer> is the name and the port number of the DFS Web Top
Server you are using.
<MyRepository n> is the name of Documentum repository that you want to crawl.
<DFSWebServices n>:<30000> is the name and the port number of the Documentum Web Services
server that hosts the Documentum repository that you want to crawl.
3. Restart the OSearch15 service. This must be done before you create a content source for Documentum.
IMPORTANT: Do not use the Services on Server page on the SharePoint Central Administration website
to restart this service. Doing so resets the search index, which requires you to do a full crawl of all content
to rebuild the index.
Verify that the user account that is performing this procedure is an administrator for the server that hosts
the crawl component.
Open a Command Prompt window.
To stop the OSearch15 service, type this command: net stop osearch15
To start the OSearch15 service, type this command: net start osearch15
To set up the Security Trimming Sync Service
1. Open the file Microsoft.Office.Server.Search.Connector.Documentum.TrimmerSync.exe.config. This file is
stored in the folder where you have installed the Indexing Connector for Documentum connector. The
default location is
%CommonProgramFiles%\Microsoft Shared\Web Server Extensions\15\CONFIG\SearchConnectors\Documentum
2. Using the same information that you provided when you configured the Indexing Connector for
Documentum, edit the configuration file as follows.
In the Emc.Documentum section, in the ModuleInfo element, do the following:
In the host attribute, type the host name of the Documentum server.
In the port attribute, type the port number of the Documentum server.
In the Data Source: Documentum Settings section, in the Repositories element, do the following:
In the repository id attribute, type the Documentum repository id.
In the name attribute, type the name of the Documentum repository.
In the login attribute, type the Documentum login name. Use the same login name as the
Documentum content access account. This should be a user who has elevated user permissions on
the Documentum Content Server.
In the dfs attribute, type the location of the Documentum Foundation Services (DFS ) by providing
the URI for the DFS.
(Optional) If your Documentum connection requires SSL/HTTPS, you have to change the security mode.
In the Data Source: Documentum Settings section, subsection Documentum, in the
basicHttpBinding element, set the security mode attribute from None to Transport for the
following bindings:
DfsAgentService
DfsContextRegistryService
DfsDefaultService
In the Data Source: Documentum Settings section, subsection Documentum, in the
netNamedPipeBinding element, set the security mode attribute from None to Transport for the
following bindings:
localNamedPipeBinding
3. Save and close the file.
4. Copy the DFS Productivity Layer .NET assemblies to the server running the Security Trimming Sync
Service.
Locate the following DFS Productivity Layer .NET assemblies and verify that the version number is
6.7.2000.36 for all files. When extracted to the default path, these files are located in the
%local%\emc-dfs-sdk-6.7\emc-dfs-sdk-6.7\lib\dotnet directory.
Emc.Documentum.FS.DataModel.Core.dll
Emc.Documentum.FS.DataModel.Shared.dll
Emc.Documentum.FS.runtime.dll
Emc.Documentum.FS.Services.Core.dll
On the server that hosts the Security Trimming Sync Service, log on with an account that is a member of
the Administrators group on that server and deploy the DFS Productivity Layer .NET assemblies to the
global assembly cache %windir%\assembly .
NOTE
You can drag and drop the four DLLs into the global assembly cache ( %windir%\assembly ) to deploy them, but
you might have to turn off User Account Control to do this.
5. Configure authentication for the Security Trimming Sync Service and install the service.
Verify that the user account that is performing this procedure is a member of the Farm Administrators
group.
Open a Command Prompt window on each server that hosts a query processing component.
Type the following command:
Microsoft.Office.Server.Search.Connector.Documentum.TrimmerSync.exe -p
When prompted, enter the password for the account that you provided in the login attribute. Use the same
login name as the Documentum content access account. The password will now automatically be encrypted
and added to the Security Trimming Sync Service config file.
Install the Security Trimming Sync Service. Type the following command:
Microsoft.Office.Server.Search.Connector.Documentum.TrimmerSync.exe -i
6. Start the Security Trimming Sync Service.
Open Windows Server Manager.
Expand the Configuration menu and click Services.
Right-click the SharePoint Documentum Security Sync service and then click Properties. In the LogOn
tab, select This account and provide the account details and credentials for the account that runs the
SharePoint services. Click OK.
Right-click the SharePoint Documentum Security Sync service and then click Start.
Verify that the Status column changes to Started.
7. Verify that the service is running and that the security sync is completed.
Run the command Microsoft.Office.Server.Search.Connector.Documentum.TrimmerSync.exe -d to
write the Security Trimming Sync Service memory to a text file.
Verify that the Security Trimming Sync Service connects to the Documentum server. Read the file
DCTMSecuritySync.log that is located in the directory
<Microsoft Office Server path>\15.0\Data\Office Server\Applications\Search\Nodes
Verify that the membership information from the Documentum server is written to the file
DCTMSecuritySync_Dump.txt that is located in the directory
<Microsoft Office Server path>\15.0\Data\Office Server\Applications\Search\Nodes
Before you can add the pre- and post- security trimmers, you must add one simple crawl rule for Documentum.
Later, you can further specify or expand the crawl rules.
Create a simple crawl rule for Documentum
application.
Manage Service Applications.
3. On the Manage Service Applications page, click the Search service application for which you want to create
a crawl rule.
6. On the Add Crawl Rule page, specify the following information to create a crawl rule:
In Path box, type dctm://*.
In Crawl Configuration section, select Include all items in this path, and then select Crawl complex
URLs (URLs that contain a question mark - ?).
In the Specify Authentication section, select Specify a different content access account, and then
type the Documentum content access account and password in the appropriate boxes.
Make sure that the Do not allow Basic Authentication check box is cleared.
7. Click OK to add the crawl rule.
To add the Indexing Connector for Documentum pre - and post-security trimmers
1. Start a SharePoint Management Shell on each server that hosts a query processing component.
New-SPEnterpriseSearchSecurityTrimmer -SearchApplication <name of your Search service application> -typeName

"Microsoft.Office.Server.Search.Connector.Documentum.Trimmers.DctmTrimPre,
Microsoft.Office.Server.Search.Connector.Documentum.Trimmers, Version=15.0.0.0,Culture=neutral,
PublicKeyToken=48e046c834625a88, processorArchitecture=MSIL" -id 26 -RulePath dctm:\\*
New-SPEnterpriseSearchSecurityTrimmer -SearchApplication <name of your Search service application> -typeName
"Microsoft.Office.Server.Search.Connector.Documentum.Trimmers.DctmTrimPost,
Microsoft.Office.Server.Search.Connector.Documentum.Trimmers, Version=15.0.0.0,Culture=neutral,
PublicKeyToken=48e046c834625a88, processorArchitecture=MSIL" -id 17 -RulePath dctm:\\*
Where:
<name of your Search service application> is the name of the Search service application.
3. Restart the SharePoint Search Host Controller.
To start the SharePoint Search Host Controller, type this command: net start spsearchhostcontroller
4. Continue with Create a Documentum content source.
Configure the Indexing Connector for Documentum using a user

mapping table
The following procedures explain how to manually create a user mapping table that specifies how the
Documentum users are mapped to Active Directory Domain Services (AD DS ) or Active Directory service users,
and how to configure the connector to support crawling Documentum content and use the user mapping table.
The user mapping table must be in a SQL Server 2008 or a later version database.
The OSearch15 service account must have at least read permission on the user mapping table data.
To create a user mapping table
First, create a user mapping table in SQL Server 2008 or a later version. The user mapping table must have the
following format:
COLUMN NAME SQL DATATYPE DESCRIPTION
DCTMCredentialDomain nvarchar(255) NOT NULL Domain name of a Documentum

account. Populate this column when the
account comes from the local computer
or an LDAP system. The User Source
property of the Documentum account
should equal None or LDAP .
Otherwise, leave the column empty.
COLUMN NAME SQL DATATYPE DESCRIPTION
DCTMCredentialRepository nvarchar (32) NOT NULL Repository name of a Documentum

account. Populate this column when the
account comes from a Documentum
repository.
DCTMCredentialLoginName nvarchar (80) NOT NULL Login name of the Documentum

account.
NTCredential nvarchar (255) NOT NULL Windows domain user account that
searches Documentum contents in
Use the following script to create a user mapping table:
CREATE TABLE <replace with your user mapping table name>

(
DCTMCredentialDomain nvarchar (255) NOT NULL ,
DCTMCredentialRepository nvarchar (32) NOT NULL ,
DCTMCredentialLoginName nvarchar (80) NOT NULL ,
NTCredential nvarchar (255) NOT NULL ,
CONSTRAINT PK_CredentialMapping PRIMARY KEY CLUSTERED
( DCTMCredentialDomain, DCTMCredentialRepository, DCTMCredentialLogonName )
)
Alternatively, you can manually create the user mapping table using SQL Server Management Studio or an
equivalent tool. If you create the table manually, make sure that you use the same schema as defined in the script.
Next, populate the user mapping table with Documentum/Windows NT credential pairs. The table in the previous
step shows what kind of input is expected.
Example:
A Documentum repository user Dan Park has a logon that is linked to the Finance repository. Dan's Windows
domain user account is Contoso\dpark. In this case, the user mapping table entry for Dan should be:
DCTMCredentialDomain ''
DCTMCredentialRepository Finance
DCTMCredentialLogonName dpark
NTCredential Contoso\dpark
NOTE
If any cells have no value assigned, they cannot be null or empty. You must assign the following empty string value: '' . >
For each Documentum group there must be a Windows NT group in the user mapping table and they must both contain
the same user information.
Finally, grant the OSearch15 account read access to the user mapping table.
To configure the connector using a user mapping table
1. Start a SharePoint Management Shell on each server that hosts a crawl component.
Set-SPEnterpriseSearchDCTMConnectorConfig -Shared -ACLTranslation UserMappingTable -

DisplayURLPatternForContainer "http://<MyWebTopServer:PortOfMyWebTopServer>/webtop/component/drl?objectId=
{ObjectId}&RepositoryName={RepositoryName}" -DisplayURLPatternForDocument
"http://<MyWebTopServer:PortOfMyWebTopServer>/webtop/component/drl?objectId={ObjectId}&format=
{Format}&RepositoryName={RepositoryName}" -UnmappedAccount "DiscardACE" -UserMappingTableSQLServer "
<YourDatabaseServerName>" -UserMappingTableSQLInstance "<YourDatabaseInstanceName>" -UserMappingTableDBName "
<YourMappingDatabaseName>" -UserMappingTableName "<YourMappingTableName>"
@("http://<DFSWebServices>:<30000>/services", "http://<DFSWebServices2>:<30000>/services")
@("http://<DFSWebServices>:<30000>/services")
Where:
<MyWebTopServer:PortOfMyWebTopServer> is the name and the port number of the DFS Web Top
Server you are using.
<YourDatabaseServerName> is the name of the database server on which you created the user mapping
table.
<YourDatabaseInstanceName> is the name of the database instance of the database server on which you
created the user mapping table.
<YourMappingDatabaseName> is the name of the database in which you created the user mapping table.
<YourMappingTableName> is the name of the user mapping table that you created.
<MyRepository n> is the name of Documentum repository that you want to crawl.
<DFSWebServices n>:<30000> is the name and port number of the Documentum Web Services server
that hosts the Documentum repository that you want to crawl.
3. Restart the OSearch15 service. The server administrator of the server that hosts the crawl component must
restart the OSearch15 service before a content source can be created for Documentum.
IMPORTANT
Do not use the Services on Server page on the SharePoint Central Administration website to restart this service.
Doing so resets the search index, which requires you to do a full crawl of all content to rebuild the index.
Verify that the user account that is performing this procedure is an administrator for the server that hosts
To stop the OSearch15 service, type this command: net stop osearch15
To start the OSearch15 service, type this command: net start osearch15
Continue with Create a crawl rule for Documentum and then continue with Create a Documentum content source.
Create the Documentum crawled properties category

You must create a crawled properties category that will contain the Documentum crawled properties. To do so,
you use the New -SPEnterpriseSearchMetadataCategory cmdlet and specify the predefined value 34972762-
7E3F -4f4f-AE5C -5ABBA92EC530 for the cmdlet's PropSet parameter. Use the following PowerShell code to
create the crawled properties category in this way.
New-SPEnterpriseSearchMetadataCategory -Name "Documentum Connector" -SearchApplication $ssa -PropSet
"34972762-7E3F-4f4f-AE5C-5ABBA92EC530" -DiscoverNewProperties $true
Create a crawl rule for Documentum

Before a crawl, you must create at least one crawl rule to authenticate the crawler with the DFS Server. You can
create more than one crawl rule to include or exclude specific content in Documentum.
application.
Manage Service Applications.
3. On the Manage Service Applications page, click the Search service application for which you want to create
a crawl rule.
6. On the Add Crawl Rule page, specify the following information:
In the Path box, type the path to which the crawl rule will apply. You can use standard wildcard characters.
To use regular expressions instead of wildcard characters, select Use regular expression syntax for
matching this rule. For examples, see Syntax to refer to a Documentum object.
In Crawl Configuration section, select Include all items in this path, and then select Crawl complex
URLs (URLs that contain a question mark - ?).
In the Specify Authentication section, select Specify a different content access account, and then
type the Documentum content access account and password in the boxes. See Determine which
Documentum content access account to use earlier in this article.
Make sure that the Do not allow Basic Authentication check box is cleared.
7. Click OK to add the crawl rule.
NOTE
You can create multiple crawl rules for Documentum to include or exclude Documentum content.
You can use different crawl rules to specify different content access accounts for different Documentum content. For
example, you have two repositories and two content access accounts for each repository. The Documentum content
access account specified in a crawl rule will only be applied to Documentum content covered by the path in that
crawl rule. If you use the Security Trimming Sync Service, you must set up this service for each Documentum server.
Create a Documentum content source

You create a content source for Documentum content to specify which Documentum content repositories you
want to crawl.
application.
2. On the SharePointSharePoint Central Administration home page, in the Application Management
section, click Manage Service Applications.
3. Click the Search service application in which you want to create a content source.
4. On the Search Administration Page, in the Crawling section, click Content Sources.
6. On the Add Content Source page, do the following:
In the Name box, type the name for the new content source.
In the Content Source Type section, select Custom Repository.
In the Type of Repository section, select SharePoint Indexing Connector for Documentum. Use the
name that you specified when you registered the Indexing Connector for Documentum with the Search
In the Start Addresses section, type the start addresses. The start address format is the same as the path
pattern. You can type more than one start address for the content source, one per line. For examples, see
Syntax to refer to a Documentum object.
In the Crawl Schedules section, select schedules from the Full Crawl and Incremental Crawl drop-down
lists, or create schedules for each kind of crawl.
In the Content Source Priority section, assign a priority level to the content source according to your
business requirements.
Click OK.
7. On the Manage Content Sources page, right-click the content source for Documentum and click Start Full
Crawl.
The Documentum content source is configured and the system can crawl Documentum content repositories that
are specified in the content source.
SharePoint Server supports scalable architecture for performance scale-out. You can deploy more than one server
that hosts a crawl component and you can configure multiple crawlers to crawl the EMC Documentum database at
the same time.
Syntax to refer to a Documentum object

The format to refer to a Documentum object that you use for the path (when you set up a crawl rule) and the start
address (when you set up a content source) is defined in the following table:
TYPE OF DOCUMENTUM OBJECT SYNTAX FOR THE PATH OR THE START ADDRESS
Repository dctm://<clientapphostname>/<repository name>
Cabinet dctm://<clientapphostname>/<repository name>/<cabinet

name>
Folder dctm://<clientapphostname>/<repository name>/<cabinet

name>/<folder name>
TYPE OF DOCUMENTUM OBJECT SYNTAX FOR THE PATH OR THE START ADDRESS
Document dctm://<clientapphostname>/<repository name>/<cabinet

name>/<folder name>/…/<folder name>?DocSysID=
<r_object_id> (where r_object_id is the object id of that
document)
<clientapphostname> is the host name of your Documentum client application such as Webtop or DA. The
<clientapphostname> configured here must be the same as the one that is used in the content source. <repository
name> , <cabinet name> , and <folder name> are case-sensitive.
Using the SPEnterpriseSearchDCTMConnectorConfig cmdlet

Use the following Microsoft PowerShell commands to display help and examples for the Indexing Connector for
Documentum cmdlet:
Get-help Set-SPEnterpriseSearchDCTMConnectorConfig -full shows full help.
Get-help Set-SPEnterpriseSearchDCTMConnectorConfig -examples shows only examples.
The Set-SPEnterpriseSearchDCTMConnectorConfig cmdlet accepts three parameter sets. You use the Shared
parameter set to change the configuration settings that affect all the Documentum repositories that you crawl. You
use the Repository parameter set to change the configuration settings that affect only a specific repository. You use
the Remove parameter set to remove a specific repository from the connector configuration.
The following table shows which parameters are mandatory and which are optional.
ACTION MANDATORY PARAMETERS OPTIONAL PARAMETERS
Configure shared repository settings Shared DFSURL, UserMappingTableSQLServer,

UserMappingTableSQLInstance,
UserMappingTableDBName,
UserMappingTableName,
ACLTranslation, UnmappedAccount,
DisplayURLPatternForDocument,
DisplayURLPatternForContainer.
Configure settings for a specific Repository, RepositoryName DFSWebServiceURL, IndexAllVersions,

repository ACLTranslation, UnmappedAccount,
DisplayURLPatternForDocument,
DisplayURLPatternForContainer.
Remove a repository from Remove, RepositoryName

configuration
See also
Supported and unsupported Documentum object types and properties in SharePoint Server
Configure and use the Lotus Notes connector for
SharePoint Server
Before you begin

Required administrative roles
Required software
User accounts required to crawl Lotus Domino databases
The procedures in this article must be repeated on all the servers in the SharePoint Server farm that host a crawl
component.
Prerequisites
The following sections list the required administrative roles, software and user accounts.
Required administrative roles
The following administrative roles are required to prepare any server that hosts a crawl component to crawl Lotus
Notes content that is hosted by one or more Lotus Domino databases:
Administrator of the Lotus Domino server that you want to crawl.
Server administrator of the server that hosts a crawl component that you want to use to crawl Lotus Notes
content.
Service application administrator for the Search service application.
Required software
The following software is required:
Lotus C++ API Toolkit for Notes.
Lotus Notes client application, available for purchase from IBM.
Lotus Notes Domino Server, available for purchase from IBM.
The following table shows combinations of versions of the Lotus Notes Domino server and Lotus Notes client that
the Lotus Notes Connector works with.
This server version With client 6.x With client 7.x With client 8.x
Server 6.x YES NO NO
Server 7.x NO YES YES

Server 8.x NO NO YES
User accounts required to crawl Lotus Domino databases

A Domino administrator must grant a Lotus Notes user ID (which represents a Domino user) at least the Reader
permission to the Lotus Domino databases and individual documents that you want to crawl. The Domino
administrator must also add this Lotus Notes user ID and the Windows domain user account that is assigned to
the SharePoint Server Search 15 service (OSearch15) to a mappings database on the Lotus Domino server that
you want to crawl.
NOTE
Only the user account that is assigned to the OSearch15 service can be used to crawl Lotus Domino databases. You cannot
use the default content access account or a crawl rule to specify a different user account to crawl Lotus Domino databases.
The following table summarizes the user accounts that are required to crawl Lotus Domino databases.
REQUIRED ACCOUNT COMMENT EXAMPLE
Windows domain user account The user account that is assigned to the Contoso\User1, where Contoso is the
OSearch15 service must also be a domain name and User1 is the name of
member of the Administrators group the Windows domain user account.
on the server that hosts the crawl
component.
Lotus Notes user ID The Lotus Notes user ID must be User2

granted at least Reader access on the
Lotus Domino databases and on the NOTE: The name of this account and its
individual documents that you want to password do not have to match the
crawl. The Domino certificate also Windows domain user account.
contains this Lotus Notes user ID.
More information about this mappings table is provided later in this article, see Configure security mappings.
Install the Lotus Notes client application

Follow this procedure to install the Lotus Notes client application on the server that hosts the crawl component in
the server farm that you want to use to crawl a Lotus Domino database. This client application serves as a protocol
handler and is used to configure the Notes.ini file. Both are used by the crawler when crawling Lotus Domino
databases.
To install Lotus Notes
1. Verify that the user account that is performing this procedure is a member of the Administrators group on
the server that hosts the crawl component and has at least Manager permissions on the Domino server.
2. Copy the Lotus Notes client application to the server that hosts the crawl component that you want to use
to crawl Lotus Notes documents.
3. Start the Lotus Notes Installation Wizard.
4. In the Welcome to the Installation Wizard for Lotus Notes dialog box, click Next.
5. On the License Agreement page, click I accept the terms in the license agreement, and then click Next
to continue.
6. On the Customer Information page, type a user name in the User Name box and the name of the
organization in the Organization box, or accept the default settings, and then click Next.
7. On the Installation Path Selection page, specify the path for the program and data files, or accept the default
installation paths, and then click Next.
NOTE
By default, program files are stored in the <SystemDrive>:\Program Files (x86)\lotus\notes\ folder and data files are
stored in the <SystemDrive>:\Program Files (x86)\lotus\notes\data\ folder, where <SystemDrive> is the drive on
which Lotus Notes is installed.
8. On the Custom Setup page, select the program features that you want to install on the local hard disk drive,
and then click Next.
The table below shows the features and sub-features that are required by the Lotus Notes connector.
9. On the Ready to Install the Program page, if you do not want Lotus Notes to be the default email program,
clear the selection Make Notes my default email program.
10. Click Install.
The Installing Lotus Notes page shows the status of the installation.
11. On the Install Wizard Completed page, click Finish.
Features and sub-features required by the Lotus Notes connector
FEATURE SUBFEATURE
Notes Client Client Help Files
Domino Enterprise Connection Services (DECS)
Domino Designer Designer Help
Grant permissions on the data folder

Follow this procedure to grant Full Control permissions for the WSS_WPG group on the
<SystemDrive>:\Program Files (x86)\Lotus\Notes\Data folder on the server that hosts the crawl component.
To grant permissions on the data folder
2. On the server that hosts the crawl component, click Start, point to All Programs, click Accessories, and
then click Windows Explorer.
3. In Windows Explorer, go to the <SystemDrive>:\Program Files (x86)\Lotus\Notes\Data folder, where
<SystemDrive> is the drive on which Lotus Notes is installed.
4. Right-click the Data folder, and then click Sharing and Security.
5. In the Properties dialog box, on the Security tab, click Add.
6. In the Select the object names to select box, do one of the following, and then click OK:
If search is installed on an Active Directory domain controller, type domain\WSS_WPG, where domain is
the name of the domain that is associated with the domain controller.
If search is installed on a server that is not an Active Directory domain controller, type server\WSS_WPG,
where server is the NetBIOS name of the server that hosts the crawl component.
7. In the Properties dialog box, in the Permissions for WSS_WPG section, select the Allow box in the Full
control row, and then click OK.
Configure the Lotus Notes client application

Follow this procedure to configure the Lotus Notes client application. The configuration settings selected in this
procedure are written to the Notes.ini file, which the crawler uses to discover how to connect to the Lotus Domino
server.
To configure Lotus Notes
2. On the server that hosts the crawl component, click Start, point to All Programs, point to Lotus
Applications, and then click Lotus Notes.
3. On the Welcome page, click Next.
4. On the User Information page, in the Your name box, type the user name associated with the Domino
certificate.
5. Type the hierarchical name of the Domino server that you want to crawl in the Domino server box. For
example, Contoso/marketing/west.
6. Ensure that I want to connect to a Domino server is selected, and then click Next.
7. On the Notes ID File page, click Browse, and then locate where the certificate is stored. Select the
certificate, click Open, and then click Next.
8. Click Yes to copy the certificate to the specified location.
NOTE
If you are not prompted for a Domino certificate, click Previous, and ensure that you have entered the correct
information.
9. If a dialog box appears that informs you that you are not authorized to access the specified directory, click
OK to close the dialog box. This error is expected if the account that you are logged on with does not have
access to the email folder on the Domino server.
10. On the Instant Messaging Setup page, cancel the selection Setup instant messaging.
11. Click Next.
12. On the Additional Services page, click Next.
13. In the Lotus Notes message box, click OK.
The Lotus Notes Welcome screen appears.
Leave the Lotus Notes client application open. You will need it for the next procedure.
Verify access to the Lotus Domino database that you want to crawl
Follow this procedure to verify that the certificate that you installed has access to the database that you want to
crawl.
To verify access
2. In Lotus Notes, click File, point to Database, and then click Open.
3. In the Open Database dialog box, select the Lotus Domino server that you want to connect to from the
Server list.
4. In the Database list, select the database that you want to connect to, and then click Open.
The documents that are contained by the database that you selected are displayed in the Document Name
section. This means that the server that hosts the crawl component as the necessary permissions to crawl
these documents.
5. Repeat steps 1 to 3 for each additional database that you want to verify access to.
6. On the File menu, click Exit Notes.
Configure security mappings

Use the information in the following table to help you create the mappings database.
ITEM DESCRIPTION
Mappings database name Name of the Lotus Domino database that maps Lotus Notes
user IDs to Windows domain user accounts.
Lotus Notes field name Name of the field in the Lotus Domino database file that
stores Lotus Notes user IDs.
Windows user field name Name of the field in the Lotus Domino database file that
stores Windows user names.
Form name Name of the form that stores the Lotus Notes field name
and Windows user field name fields.
View name Name of the view for the form that stores the Lotus Notes
user IDs to Windows user name mappings.
NOTE: This name is case-sensitive.
Create the mappings database

Follow this procedure to create a mappings database by using Domino Designer. You only require one mappings
database for each forest of Domino servers that contain databases that you want to crawl.
To create a mappings database
the server that hosts the crawl component and has at least Manager permissions on the Domino server that
you want to crawl.
2. On the server that hosts the crawl component, open Domino Designer.
3. Click File, point to Database, and then click New.
4. In the New Database dialog box, do the following:
Select the Domino server from the Server name list.
In the Title box, type a title for the new database.
This content automatically populates the File Name box, and it is appended with the .nsf file name
extension.
If the title that you chose is more than eight characters long, the file name will be truncated.
Click OK to close the New Database dialog box.
5. Click Create, point to Design, and then click Form.
6. Click Create, and then click Field.
7. In the Field dialog box, in the Name box, type the name that you want to use for this field. This field will be
used to store the Lotus Notes user IDs.
8. Close the dialog box to save the field.
9. Click Create, and then click Field.
10. In the Field dialog box, in the Name box, type the name that you want to use for this field. This field will be
used to store the Windows domain user accounts.
11. Close the dialog box to save the field.
12. Click File, click Save, and then do the following:
Type a name in the Save Form as box.
Click OK to close the dialog box.
13. On the Create menu, point to Design, and then click View.
14. In the Create View dialog box, do the following:
In the View name box, type a name for this view.
Select Shared from the View type list.
Click OK to save the view.
15. Open the view that you created in step 14.
16. On the Objects tab, select the column that you created in step 7. In the lower right pane, select Field and
then select the field that has the same name.
17. On the Objects tab, select the column that you created in step 10. In the lower right pane, select Field and
then select the field of the same name.
18. Click File and then click Save to save the view, and then close Domino Designer.
Add user accounts to the mappings database
Follow this procedure to add user accounts to the mappings database using the Lotus Notes client. You should add
all accounts which require access to the mappings database and the Domino server.
To add user accounts to the mappings database
2. On the server that hosts the crawl component, open the Lotus Notes client application.
3. Click File, point to Database, and then click Open.
4. In the Open Database dialog box, do the following:
Select the Domino server from the Server name list.
Select the mappings database that you created earlier.
Click Open.
5. In the left pane, select the view that you created for this database.
6. Click Create, and then click the name of the form that you created earlier.
7. In the form, in the field that you created to store the Lotus Notes user IDs, type a Lotus Notes user ID that
you want to map to a Windows domain user account. For example, ContosoUser. This field is case-sensitive.
8. In the field that you created to map to the Lotus Notes user IDs, type the Windows domain user account
that you want to map to the Lotus Notes user ID that you entered in step 7. This must be in the form of
domain\user, for example, Contoso\user1.
9. Click File, and then click Save to save the document.
10. Repeat steps 6to 8 if you want to add more mappings. Otherwise, go to step 11.
11. When finished, save the form and then close the Lotus Notes client application.
Restart the server that hosts the crawl component

You must restart the server that hosts the crawl component before continuing to the next procedure.
IMPORTANT
After the server that hosts the crawl component restarts, do not open the Lotus Notes client application again. This is
because the Lotus Notes client application might lock files that could cause the following procedures and crawling Lotus
Domino databases to fail.
Register Lotus Notes with the server that hosts the crawl component
Following this procedure to register Lotus Notes with the operating system of the server that hosts the crawl
component.
To register Lotus Notes
the server that hosts the crawl component.
2. Run Notessetup.exe on the server that hosts the crawl component by using the same credentials that are
used to provision the Lotus Notes Connector.
3. On the server that hosts the crawl component, in Windows Explorer, go to the <SystemDrive>:\Program
Files\Microsoft Office Servers\15\Bin\1033 folder, where <SystemDrive> is the drive on which Microsoft
SharePoint Server is installed.
4. Double-click NotesSetup.exe.
5. On the Welcome to the Lotus Notes Index Setup Wizard page, click Next.
6. In the Register Lotus Notes for use with SharePoint Server dialog box, do the following:
In the Location of the notes.ini file box, ensure that the correct path of the Notes.ini file is specified. The
default path of this file is <SystemDrive>:\Program Files (x86)\lotus\notes\notes.ini, where <SystemDrive>
is the drive on which Lotus Notes is installed.
In the Location of the Lotus Notes install directory box, ensure that the correct path of the Lotus Notes
installation directory is specified. By default, the path of this directory is <SystemDrive>:\Program Files
(x86)\lotus\notes.
In the Password box, type the password for the user name that is associated with the Domino certificate.
In the Confirm Password box, retype the password for the user name that is associated with the Domino
certificate.
7. We recommend that you leave the Ignore Lotus Notes security while building the index box cleared.
This allows the crawl to include all Lotus Notes documents in the search index without restriction. Security
for these documents and objects is determined by the mappings table and provides security data without
excluding documents from the index.
8. Click Next.
9. On the Specify Lotus Notes Owner Field to Windows User Name Mapping page, do the following:
In the Lotus Notes server name box, type the NetBIOS name or IP address of the Domino server.
In the Lotus Notes database file name box, type the file name of the Lotus Domino database that maps
the Lotus Notes user IDs to Windows domain user accounts. Ensure that you include the .nsf file name
extension with this name, for example, Mappings.nsf.
In the View name box, type the view name of the Lotus Domino database that stores the Lotus Notes user
IDs to Windows user name mappings.
In the Lotus Notes field name column title box, type the name of the column in the Lotus Notes
database file that is used to store Lotus Notes user IDs.
In the Windows user name column title box, type the name of the column in the Lotus Notes database
file that is used to store the Windows user accounts.
10. Click Next.
11. On the Completing the Lotus Notes Index Setup Wizard page, click Finish.
Provision the Lotus Notes Connector

Follow this procedure to provision the Lotus Notes Connector with the operating system of the server that hosts
To provision Lotus Notes
the server that hosts the crawl component.
2. Open SharePoint Central Administration. In the System Settings section, click Manage services on
Server.
3. On the Services on Server page, in the Service column, find the Lotus Notes Connector service.
4. In the Action column, click Start.
5. On the Lotus Notes connector settings page, in the application pool section, select Create new
application pool, and then enter a name for the new application pool.
6. In the Configurable drop-down, select or register the same security account used for installation of the
NotesSetup.exe.
7. Click Provision.
The Lotus Notes connector is now provisioned and started.
Restart the OSearch15 service

The server administrator of the server that hosts the crawl component must restart the OSearch15 service before
a content source can be created for Lotus Domino databases.
IMPORTANT
Do not use the Services on Server page on the SharePoint Central Administration website to restart this service. Doing so
resets the search index, which requires you to do a full crawl of all content to rebuild the index.
To restart the OSearch15 service

1. Verify that the user account that is performing this procedure is an administrator for the server that hosts
2. Open a command prompt window.
3. To stop the OSearch15 service, type this command: net stop osearch15
4. To start the OSearch15 service, type this command: net start osearch15
Manage farm-level crawl settings in SharePoint
Server

You can perform the following procedures to configure certain crawl settings at the farm level:
Configure time-out values for crawler connections in SharePoint Server
Change how long the SharePoint Server search crawler will wait for a connection to a content repository or
for a response to a connection attempt.
Configure the crawler in case of SSL certificate warnings in SharePoint Server
Specify whether a SharePoint Server crawler will crawl a site if there is a problem with the site's Secure
Sockets Layer (SSL ) certificate.
Configure proxy server settings for Search in SharePoint Server
Specify a proxy server to send requests to crawl content or to query federated content repositories.
See also
Configure time-out values for crawler connections in
SharePoint Server

By default, when the crawler attempts to connect to a content repository, it waits 60 seconds for a connection or
for a response to a connection attempt. Use the procedure in this article to change these crawler time-out values.
If the crawler does not connect or get a response within the time specified, it tries to connect again. If the crawler
does not connect on the second attempt within the time specified, it does not crawl the repository during that
crawl.
To configure time-out settings for crawler connections
1. Verify that the user account that is performing this procedure is a farm administrator.
2. In Central Administration, in the Quick Launch, click General Application Settings.
3. On the General Application Settings page, in the Search section, click Farm Search Administration.
4. On the Farm Search Administration page, in the Farm -Level Search Settings section, click either of the
Time-out (seconds) setting values.
5. In the Search Time-out Setting dialog box, do the following:

In the Connection time (in seconds) text box, type the number of seconds that you want the crawler to
wait when it attempts to connect to a content repository. The default value is 60 seconds.
In the Request acknowledgement time (in seconds) text box, type the number of seconds that you want
the crawler to wait for a content repository to respond to a connection attempt. The default value is 60
seconds.
Click OK.
See also
Configure the crawler in case of SSL certificate
warnings in SharePoint Server

When a crawler requests a connection to crawl a site, the system generates a warning if there is a problem with the
site's SSL certificate. By default, the crawler does not crawl the site when this happens. For security reasons, we
strongly recommend that you do not change this default crawler behavior unless you have sufficient reason to do
so.
An SSL certificate problem can occur for reasons such as the following:
The certificate is expired.
The certificate is not signed by a trusted authority.
The name in the certificate does not match the site name.
A name mismatch could be the result of an attempt to spoof the validity of a site and trick users into
opening documents from the site or into providing passwords and other information that could allow a
hacker to access the system.
However, if you are only crawling internal sites, you might expect SSL warnings in certain cases. For example, you
might know that some site names and certificate names are mismatched for legitimate reasons, such as if the
organization changed a server name or site name, or if the organization is using a single certificate for multiple
sites. In such cases, it might be safe to change the default crawler behavior and thus ignore SSL certificate
warnings.
Use the following procedure to specify whether the crawler will crawl sites in the event of SSL certificate warnings.
The setting applies to all content sources in all Search service applications in a farm. After you change this setting,
you must re-crawl all affected sites so that the appropriate content is in the search index.
To configure the crawler for SSL certificate warnings
Group.
4. On the Farm Search Administration page, in the Farm -Level Search Settings section, click the value of the
Ignore SSL Warnings setting ( Yes or No). The default setting is No.
5. In the Search SSL Settings dialog box, do one of the following:

If you do not want the crawler to crawl a site when there is an SSL certificate warning, make sure that the
Ignore SSL certificate name warnings check box is cleared. For security reasons, the check box is cleared
by default.
If you want the crawler to crawl a site even if there is an SSL certificate warning, make sure that the Ignore
SSL certificate name warnings check box is selected.
6. Click OK.
See also
Concepts
Configure proxy server settings for Search in
SharePoint Server

A farm administrator or Search service application administrator can specify proxy server settings for sending
HTTP requests to crawl content or query federated content repositories. A proxy server is a computer that
functions as an intermediary to forward a client request to another server and return the results to the client.
Using a proxy server can help increase intranet security and can help improve response times for client search
requests.
To configure proxy server settings for crawling and federation
1. Verify that the user account that is performing this procedure is a farm administrator or a Search service
application administrator.
4. On the Farm Search Administration page, in the Farm -Level Search Settings section, in the Proxy
server for crawling and federation row, click the value.
The default value is None.
5. In the Search Proxy Setting dialog box, do one of the following:
Select Do not connect by using a proxy server if you do not want to use a proxy server for crawling or
federation.
Select Use the proxy server specified if you want to use a proxy server for crawling or federation, and
then do the following:
In the Address box, type the URL of the proxy server.
In the Port box, if the proxy server is not using the default port, type the port number that the proxy
server is using.
Select the Bypass proxy server for local (intranet) addresses check box if you do not want the
crawler to use the proxy server when crawling within the intranet.
In the Do not use proxy server for addresses beginning with box, type the appropriate
addresses. Separate the addresses by using semicolons.
Select the Use these proxy settings for access to federated sites check box if you want the
search system to use the proxy server when it queries external content repositories.
6. In the Search Proxy Setting dialog box, click OK.
See also
Best practices for crawling in SharePoint Server

Learn about best practices for crawling in SharePoint Server.
The Search system crawls content to build a search index that users can run search queries against. This article
contains suggestions as to how to manage crawls most effectively.
Use the default content access account to crawl most content

The default content access account is a domain account that you specify for the SharePoint Server Search service
to use by default for crawling. For simplicity, it is best to use this account to crawl as much as possible of the
content that is specified by your content sources. To change the default content access account, see Change the
default account for crawling in SharePoint Server.
When you cannot use the default content access account for crawling a particular URL (for example, for security
reasons), you can create a crawl rule to specify one of the following alternatives for authenticating the crawler:
A different content access account
A client certificate
Form credentials
A cookie for crawling
Anonymous access
For more information, see Manage crawl rules in SharePoint Server.
Use content sources effectively

A content source is a set of options in a Search service application that you use to specify each of the following:
One or more start addresses to crawl.
The type of content in the start addresses (such as SharePoint Server sites, file shares, or line-of-business
data). You can specify only one type of content to crawl in a content source. For example, you would use
one content source to crawl SharePoint Server sites, and a different content source to crawl file shares.
A crawl schedule and a crawl priority for full or incremental crawls that will apply to all of the content
repositories that the content source specifies.
When you create a Search service application, the search system automatically creates and configures one content
source, which is named Local SharePoint sites. This preconfigured content source is for crawling user profiles,
and for crawling all SharePoint Server sites in the web applications with which the Search service application is
associated. You can also use this content source for crawling content in other SharePoint Server farms, including
SharePoint Server 2007 farms, SharePoint Server 2010 farms, SharePoint Server 2013 farms, or other
SharePoint Server farms.
Create additional content sources when you want to do any of the following:
Crawl other types of content
Limit or increase how much content to crawl
Crawl certain content more or less frequently
Set different priorities for crawling certain content (this applies to full and incremental crawls, but not to
continuous crawls)
Crawl certain content on different schedules (this applies to full and incremental crawls, but not to
continuous crawls)
However, to keep administration as easy as possible, we recommend that you limit the number of content sources
that you create and use.
Using content sources to schedule crawls
You can edit the preconfigured content source Local SharePoint sites to specify a crawl schedule; it does not
specify a crawl schedule by default. For any content source, you can start crawls manually, but we recommend
that you schedule incremental crawls or enable continuous crawls to make sure that content is crawled regularly.
Consider using different content sources to crawl content on different schedules for the following reasons.
To accommodate server down times and periods of peak server usage.
To crawl content that is hosted on slower servers separately from content that is hosted on faster servers.
To frequently crawl content that is updated more often.
Crawling content can significantly decrease the performance of the servers that host the content. The effect
depends on whether the host servers have sufficient resources (especially CPU and RAM ) to handle the load.
Therefore, when you plan crawl schedules, consider the following best practices:
Schedule crawls for each content source during times when the servers that host the content are available
and when there is low demand on the server resources.
Stagger crawl schedules so that the load on crawl servers and host servers is distributed over time. You can
optimize crawl schedules in this manner as you become familiar with the typical crawl durations for each
content source by checking the crawl log. For more information, see Crawl log in View search diagnostics
Run full crawls only when it is necessary. For more information, see Reasons to do a full crawl in Plan
crawling and federation in SharePoint Server. For any administrative change that requires a full crawl to
take effect, such as creation of a crawl rule, perform the change shortly before the next full crawl so that an
additional full crawl is not necessary. For more information, see Manage crawl rules in SharePoint Server.
Crawl user profiles before you crawl SharePoint Server sites

By default, in the first Search service application in a farm, the preconfigured content source Local SharePoint
sites contains at least the following two start addresses:
https://webAppUrl, which is for crawling the Default Zone URL specified for the existing Web
Application(s)
sps3s://myWebAppUrl, which is for crawling user profiles
However, if you are deploying "People Search", we recommend that you create a separate content source for the
start address sps3s://myWebAppUrl and run a crawl for that content source first. The reason for doing this is that
after the crawl finishes, the search system generates a list to standardize people's names. This is so that when a
person's name has different forms in one set of search results, all results for that person are displayed in a single
group (known as a result block). For example, for the search query "Anne Weiler", all documents authored by
Anne Weiler or A. Weiler or alias AnneW can be displayed in a result block that is labeled "Documents by Anne
Weiler". Similarly, all documents authored by any of those identities can be displayed under the heading "Anne
Weiler" in the refinement panel if "Author" is one of the categories there.
To crawl user profiles and then crawl SharePoint Server sites
2. Follow the instructions in Deploy people search in SharePoint Server. As part of those instructions, you do
the following:
Create a content source that is only for crawling user profiles (the profile store). You might give that
content source a name such as People. In the new content source, in the Start Addresses section, type
sps3s:// myWebAppUrl, where myWebAppUrl is the URL of the My Site host.
Start a crawl for the People content source that you just created.
Delete the start address sps3s://myWebAppUrl from the preconfigured content source Local SharePoint
sites.
3. Wait about two hours after the crawl for the People content source finishes.
4. Start the first full crawl for the content source Local SharePoint sites.
Use continuous crawls to help ensure that search results are fresh
Enable continuous crawls is a crawl schedule option that you can select when you add or edit a content source
of type SharePoint Sites. A continuous crawl crawls content that was added, changed, or deleted since the last
crawl. A continuous crawl starts at predefined time intervals. The default interval is every 15 minutes, but you can
set continuous crawls to occur at shorter intervals by using Microsoft PowerShell. Because continuous crawls
occur so often, they help ensure search-index freshness, even for SharePoint Server content that is frequently
updated. Also, while an incremental or full crawl is delayed by multiple crawl attempts that are returning an error
for a particular item, a continuous crawl can be crawling other content and contributing to index freshness,
because a continuous crawl doesn't process or retry items that repeatedly return errors. Such errors are retried
during a "clean-up" incremental crawl, which automatically runs every four hours for content sources that have
continuous crawl enabled. Items that continue to return errors during the incremental crawl will be retried during
future incremental crawls, but will not be picked up by the continuous crawls until the errors are resolved.
A single continuous crawl includes all content sources in a Search service application for which continuous crawls
are enabled. Similarly, the continuous crawl interval applies to all content sources in the Search service
application for which continuous crawls are enabled. For more information, see Manage continuous crawls in
SharePoint Server.
Continuous crawls increase the load on the crawler and on crawl targets. Make sure that you plan and scale out
accordingly for this increased consumption of resources. For each large content source for which you enable
continuous crawls, we recommend that you configure one or more front-end web servers as dedicated targets for
crawling. For more information, see Manage crawl load (SharePoint Server 2010).
Use crawl rules to exclude irrelevant content from being crawled

Because crawling consumes resources and bandwidth, during initial deployment it might be better to crawl a
small amount of content that you know is relevant, instead of crawling a larger amount of content, some of which
might not be relevant. To limit how much content that you crawl, you can create crawl rules for the following
reasons:
To avoid crawling irrelevant content by excluding one or more URLs.
To crawl links on a URL without crawling the URL itself. This is useful for sites that do not contain relevant
content but have links to relevant content.
By default, the crawler will not follow complex URLs, which are URLs that contain a question mark followed by
additional parameters — for example, http://contoso/page.aspx?x=y. If you enable the crawler to follow complex
URLs, this can cause the crawler to gather many more URLs than is expected or appropriate. This can cause the
crawler to gather unnecessary links, fill the crawl database with redundant links, and result in an index that is
unnecessarily large.
These measures can help reduce the use of server resources and network traffic, and can increase the relevance of
search results. After the initial deployment, you can review the query and crawl logs and adjust content sources
and crawl rules to include more content if it is necessary. For more information, see Manage crawl rules in
SharePoint Server.
Crawl the default zone of SharePoint Server web applications

When you crawl the default zone of a SharePoint Server web application, the query processor automatically maps
and returns search-result URLs so that they are relative to the alternate access mapping (AAM ) zone from which
queries are performed. This makes it possible for users to readily view and open search results.
However, if you crawl a zone of a web application other than the default zone, the query processor does not map
search-result URLs so that they are relative to the AAM zone from which queries are performed. Instead, search-
result URLS will be relative to the non-default zone that was crawled. Because of this, users might not readily be
able to view or open search results.
For example, assume that you have the following AAMs for a web application named WebApp1:
DEFAULT PUBLIC URL AUTHENTICATION PROVIDER
Default https://contoso Windows authentication: NTLM
Extranet https://fabrikam Forms-based authentication
Intranet http://fabrikam Windows authentication: NTLM
Now, say that you crawl the default zone, https://contoso. When users perform queries from
https://contoso/searchresults.aspx, URLs of results from WebApp1 will all be relative to https://contoso, and
therefore will be of the form https://contoso/ path/ result.aspx.
Similarly, when queries originate from the Extranet zone—in this case, https://fabrikam/searchresults.aspx—
results from WebApp1 will all be relative to https://fabrikam, and therefore will be of the form https://fabrikam/
path/ result.aspx.
In both of the previous cases, because of the zone consistency between the query location and the search-result
URLs, users will readily be able to view and open search results, without having to change to the different security
context of a different zone.
However, now instead say that you crawl a non-default zone such as the Intranet zone, http://fabrikam. In this
case, for queries from any zone, URLs of results from WebApp1 will always be relative to the non-default zone
that was crawled. That is, a query from https://contoso/searchresults.aspx, https://fabrikam/searchresults.aspx, or
http://fabrikam/searchresults.aspx will yield search-result URLs that begin with the non-default zone that was
crawled, and therefore will be of the form http://fabrikam/ path/ result.aspx. This can cause unexpected or
problematic behavior such as the following:
When users try to open search results, they might be prompted for credentials that they don't have. For
example, forms-based authenticated users in the Extranet zone might not have Windows authentication
credentials.
The results from WebApp1 will use HTTP, but users might be searching from the Extranet zone at
https://fabrikam/searchresults.aspx. This might have security implications because the results will not use
secure sockets layer (SSL ) encryption.
Refinements might not filter correctly, because they filter on the public URL for the default zone instead of
the URL that was crawled. This is because URL -based properties in the index will be relative to the non-
default URL that was crawled.
Reduce the effect of crawling on SharePoint Server crawl targets

You can reduce the effect of crawling on SharePoint Server crawl targets (that is, SharePoint Server front-end web
servers) by doing the following:
For a small SharePoint Server environment, redirect all crawl traffic to a single SharePoint Server front-end
web server. For a large environment, redirect all crawl traffic to a specific group of front-end web servers.
This prevents the crawler from using the same resources that are being used to render and serve web
pages and content to active users.
Limit search database usage in Microsoft SQL Server to prevent the crawler from using shared SQL
Server disk and processor resources during a crawl.
For more information, see Manage crawl load (SharePoint Server 2010).
Using crawler impact rules to limit the effect of crawling
To limit crawler impact, you can also create crawler impact rules, which are available from the
Search_service_application_name: Search Administration page. A crawler impact rule specifies the rate at which
the crawler requests content from a start address or range of start addresses. Specifically, a crawler impact rule
either requests a specified number of documents at a time from a URL without waiting between requests, or it
requests one document at a time from the URL and waits a specified time between requests. Each crawler impact
rule applies to all crawl components.
For servers in your organization, you can set crawler impact rules based on known server performance and
capacity. However, this might not be possible for external sites. Therefore, you might unintentionally use too many
resources on external servers by requesting too much content or requesting content too frequently. This could
cause administrators of those external servers to limit server access so that it becomes difficult or impossible for
you to crawl those repositories. Therefore, set crawler impact rules to have as little effect on external servers as
possible while you still crawl enough content frequently enough to make sure that that the freshness of the index
meets your requirements.
Use Active Directory groups instead of individual users for permissions

The ability of a user or group to perform various activities on a site is determined by the permission level that you
assign. If you add or remove users individually for site permissions, or if you use a SharePoint Server group to
specify site permissions and you change the membership of the group, the crawler must perform a "security-only
crawl", which updates all affected items in the search index to reflect the change. Similarly, adding or updating
web application policy with different users or SharePoint Server groups will trigger a crawl of all content covered
by that policy. This increases crawl load and can reduce search-results freshness. Therefore, to specify site
permissions, it is best to use Active Directory Domain Services (AD DS ) groups, because this does not require the
crawler to update the affected items in the search index.
Add a second crawl component to provide fault tolerance

When you create a Search service application, the default search topology includes one crawl component. A crawl
component retrieves items from content repositories, downloads the items to the server that hosts the crawl
component, passes the items and associated metadata to a content processing component, and adds crawl-related
information to associated crawl databases. You can add a second crawl component to provide fault tolerance. If
one crawl component becomes unavailable, the remaining crawl component will take over all of the crawling. For
most SharePoint Server farms, a total of two crawl components is sufficient.
New -SPEnterpriseSearchCrawlComponent
Manage environment resources to improve crawl performance

As the crawler crawls content, downloads the content to the crawl server (the server that hosts the crawl
component), and feeds the content to content processing components, several factors can adversely affect
performance. To improve crawl performance, you can do the following:
TO ADDRESS THIS POTENTIAL PERFORMANCE BOTTLENECK IMPLEMENT THIS SOLUTION
Slow response time from crawled servers Provide more CPU and RAM and faster disk I/O
Low network bandwidth Install one or two one-gigabit-per-second network adapters

on each crawl server
Content processing Provide more content processing components, and more CPU
resources for each content processing component
Slow processing by the index components Add I/O resources for servers that host index components

Scale search for Internet sites in SharePoint Server
SharePoint 2013: Crawl scaling recommendations
Make sure no crawls are active before you change the search topology
We recommend that you confirm that no crawls are in progress before you initiate a change to the search
topology. Otherwise, it is possible that the topology change will not occur smoothly.
If necessary, you can manually pause or stop full or incremental crawls, and you can disable continuous crawls.
Start, pause, resume, or stop a crawl in SharePoint Server
Manage continuous crawls in SharePoint Server
NOTE
Pausing a crawl has the disadvantage that references to crawl components can remain in the MSSCrawlComponentsState
table in the search administration database. This can cause a problem if you want to remove any crawl components (say,
because you want to remove a server that hosts those components from the farm). However, when you stop a crawl,
references to crawl components in the MSSCrawlComponentsState table are deleted. Therefore, if you want to remove crawl
components, it is better to stop crawls than to pause crawls.
To confirm that no crawls are in progress, on the Search_service_application_name: Manage Content Sources
page, make sure that the value in the Status field for each content source is either Idle or Paused. (When a crawl
is completed, or when you stop a crawl, the value in the Status field for the content source will change to Idle.)
Remove crawl components from a crawl host before you remove the
host from a farm
When a server hosts a crawl component, removing the server from the farm can make it impossible for the
Search system to crawl content. Therefore, before you remove a crawl host from a farm, we strongly recommend
that you do the following:
1. Make sure that no crawls are active.
For more information, see the previous section, Make sure no crawls are active before you change the
search topology.
2. Remove or relocate crawl components that are on that host.
Remove a search component or Move a search component in Manage search components in SharePoint
Server
Remove a server from a farm in SharePoint Server 2016
SP2010: Removing/Re-joining Server to a Farm Can Break Search
Test crawl and query functionality after you change the crawl
configuration or apply updates
We recommend that you test the crawl and query functionality in the server farm after you make configuration
changes or apply updates. The following procedure is an example of an easy way to perform such a test.
To test the crawl and query functionality
2. Create a content source that you will use temporarily just for this test.
In the new content source, in the Start Addresses section, in the Type start addresses below (one per
line) box, specify a start address that contains several items that are not already in the index — for
example, several TXT files that are on a file share. For more information, see Add, edit, or delete a content
source in SharePoint Server.
3. Start a full crawl for that content source.
For more information, see Start, pause, resume, or stop a crawl in SharePoint Server. When the crawl is
complete, on the Search_service_application_name: Manage Content Sources page, the value in the Status
column for the content source will be Idle. (To update the Status column, refresh the Manage Content
Sources page by clicking Refresh.)
4. When the crawl is complete, go to the Search Center and perform search queries to find those files.
If your deployment does not already have a Search Center, see Create a Search Center site in SharePoint
Server.
5. After you finish testing, delete the temporary content source.
This removes the items specified by that content source from the search index so that they do not appear in
search results after you finish testing.
Use the crawl log and crawl-health reports to diagnose problems

The crawl log tracks information about the status of crawled content. The log includes views for content sources,
hosts, errors, databases, URLs, and history. For example, you can use this log to determine the time of the last
successful crawl for a content source, whether crawled content was successfully added to the index, whether it was
excluded because of a crawl rule, or whether crawling failed because of an error.
Crawl-health reports provide detailed information about crawl rate, crawl latency, crawl freshness, content
processing, CPU and memory load, continuous crawls, and the crawl queue.
You can use the crawl log and crawl-health reports to diagnose problems with the search experience. The
diagnostic information can help you determine whether it would be helpful to adjust elements such as content
sources, crawl rules, crawler impact rules, crawl components, and crawl databases.
For more information, see View search diagnostics in SharePoint Server.
Manage search relevance in SharePoint Server

The following articles provide information about how you manage relevance to improve classic search results in
SharePoint Server. Some settings also impact the modern search results, see Differences between the search
experiences in SharePoint Server.
CONTENT DESCRIPTION
Manage query spelling correction in SharePoint Server Learn how to include single words in or exclude single words
from query spelling corrections to help correct spelling errors
in queries in the classic search experience.
Manage query suggestions in SharePoint Server Query suggestions are phrases that you want the search
system to suggest to users as they start typing a query. This
article explains how to switch query suggestions on or off for
the classic search experience. It also explains how you can add
phrases to the automatic query suggestions, and how you can
add phrases that should not be used as query suggestions.
Create and deploy a thesaurus in SharePoint Server Learn how to create and deploy a thesaurus to expand queries
with synonyms in the classic search experience.
Configure authoritative pages in SharePoint Server Learn how to specify authoritative pages and non-
authoritative URLs and sites. Classic search uses the list of
authoritative pages to calculate the ranking of results.
Manage query rules in SharePoint Server Learn how to improve search results in the classic search
experience by creating and managing query rules.
Configure result sources for search in SharePoint Server Result sources limit searches in the classic search experience to
certain content or to a subset of search results. Learn how to
create and manage result sources.
Create and deploy custom entity extractors in SharePoint Learn to create custom entity extractors and how to use them
Server to set up custom refiners in the classic search experience.
Create one or more custom entity extraction dictionaries and
connect them to managed properties.
Manage company name extraction in SharePoint Server Learn how to include company names to be extracted from
content for search results in the classic search experience, or
how to exclude company names from being extracted.
Customize search result types in SharePoint Server Create and configure custom search result types so that users
can readily distinguish and preview different kinds of items in
a list of search results in the classic search experience.
Create a custom ranking model by using the Ranking Model If the standard ranking models don't satisfy the relevance
Tuning App requirements you have, you can create a custom ranking
model. With the Ranking Model Tuning App, you can do this
more easily than before.
CONTENT DESCRIPTION
Configure trust for search between two SharePoint Server Configure a SharePoint Server content farm that receives
farms search queries to trust the SharePoint Server farm that sends
the queries.
Manage query spelling correction in SharePoint
Server

In the classic search experience, if a user enters a word in a search query that appears to be misspelled, the search
results page displays query spelling corrections. This is also known as "Did you mean?". For example, if someone
enters a query that contains the word "ampitheater", the query spelling correction would be "amphitheater".
These query spelling suggestions are based on the closest matches in the default spelling dictionaries and the
Query Spelling Inclusions list. For terms that you enter in the Query Spelling Exclusions list, query spelling
suggestions will never be displayed. You can edit the Query Spelling Inclusions and the Query Spelling Exclusions
list, but you can't edit the default spelling dictionaries. It takes up to 10 minutes for any changes to the Query
Spelling Exclusions or the Query Spelling Inclusions list to take effect.
IMPORTANT
You can only include or exclude single words.
For more information about linguistic search features for different languages see Linguistic search features in
SharePoint Server.
Open the Term Store Management Tool

The query spelling exclusions and inclusions lists are managed in the Term Store. Use the Term Store Management
Tool to edit the lists.
To get to the Term Store Management Tool
application.
2. On the home page of the SharePoint Central Administration website, in the Application Management
section, click Manage service applications.
4. On the Search Administration Page, in the Queries and Results section, click Search Dictionaries. The
Term Store Management Tool opens.
Exclude terms from query spelling corrections

To exclude words from query spelling corrections, add terms to the Query Spelling Exclusions list.
IMPORTANT
Create a separate term for each query spelling correction exclusion. Do not create subterms for terms in the Query Spelling
Exclusions list. Term hierarchies will be ignored in this context.
To add a word to the Query Spelling Exclusions list

1. On the Site Settings: Term Store Management Tool page, click the arrow to expand the Search
Dictionaries menu.
2. Click Query Spelling Exclusions, click the arrow and then click Create Term.
3. Type the word that you want to exclude in the box that appears.
4. Click anywhere on the page to add the term to the Query Spelling Exclusions list.
Include terms in query spelling corrections

To include words in query spelling corrections, add terms to the Query Spelling Inclusions list.
IMPORTANT
Create a separate term for each query spelling correction inclusion. Do not create subterms for terms in the Query Spelling
Inclusions list. Term hierarchies will be ignored in this context.
To add a word to the Query Spelling Inclusions list

Dictionaries menu.
2. Click Query Spelling Inclusions, click the arrow and then click Create Term.
3. Type the word that you want to include in the box that appears.
4. Click anywhere on the page to add the term to the Query Spelling Inclusions list.
Edit terms
You can edit the names of terms in the Query Spelling Exclusions and Query Spelling Inclusions lists.
To edit terms
Dictionaries menu.
2. Depending on which list the term is in, click either Query Spelling Exclusions or Query Spelling
Inclusions.
3. Double-click the term that you want to edit.
4. Type the new name for the term.
5. Click anywhere on the page to save the edited term.
See also
Linguistic search features in SharePoint Server
Set-SPEnterpriseSearchQuerySpellingCorrection
Get-SPEnterpriseSearchQuerySpellingCorrection

Query suggestions help users find information quickly by showing queries that might be similar to the one they're
typing. For example, as users start to type "sales", they may be able to pick common sales-related queries from a
list below the Search Box.
The search system automatically creates suggestions for a query when users have clicked one or more of the
results for that query at least six times. The query suggestions are generated daily for each result source and for
each site collection, so the automatic query suggestions can be different for different result sources and site
collections.
When you follow the steps in this article to manually add phrases that should or shouldn't be used as query
suggestions, the query suggestions apply to all result sources and all site collections.
Add phrases that should always or never be used as query suggestions

To add phrases that you want the search system to always or never suggest to users as they start typing a query,
you have to create one or several text files that contain these phrases, and then import the files into the search
system.
You should create separate text files for the phrases that you want to always be suggested, and for the phrases that
you want to never be suggested. If you want to add query suggestions for multiple languages, you should also
create separate files per language. The language determines how the query suggestions are processed internally
in the search system, but all query suggestions are always displayed or suppressed for all languages as users
enter their queries. Add each phrase as a separate line in the text file that you create, and save the file in UTF -8
encoding.
Cau t i on
When you import a text file with phrases for query suggestions, you overwrite any existing manual query
suggestions in the search system. The automatic query suggestions are not overwritten. If you want to edit
existing manual query suggestions or add new ones, you should first export the existing query suggestions to a
text file, and then update and re-import that file.
To add phrases that should always be used as query suggestions
application.
2. Open the Query Suggestion Settings page.
On the home page of the SharePoint Central Administration website, in the Application Management
On the Manage Service Applications page, click the Search service application.
On the Search Administration Page, in the Queries and Results section, click Query Suggestions. The
Query Suggestion Settings page opens.
3. In the Language for suggestion phrases section, select the processing language for the query
suggestions that you always want to suggest.
4. In the Always suggest phrases section, click Import from text file. Browse to the file that you want to
import and click OK.
5. Click Save Settings.
NOTE
If you want to edit existing manual query suggestions or add new ones, click Export to file, update the text file and then re-
import it. To remove all manual query suggestions, upload an empty text file.
To add phrases that should never be used as query suggestions

application.
3. In the Language for suggestion phrases section, select the processing language for the query
suggestions that you never want to suggest.
4. In the Never suggest phrases section, click Import from text file. Browse to the file that you want to
import and click OK.
NOTE
If you want to edit existing manual query suggestions or add new ones, click Export to text file, update the text file and
then re-import it. To remove all manual query suggestions, upload an empty text file.
Switch query suggestions on or off

Query suggestions are turned on by default. The following steps explain how to turn query suggestions on or off.
To enable or disable query suggestions
application.
3. In the Search Suggestions section, do one of the following:
To enable query suggestions, check the Show search suggestions check box.
To disable query suggestions, clear the Show search suggestions check box.
Create and deploy a thesaurus in SharePoint Server

Use a thesaurus file to specify synonyms for a single word or multiple words that occur in queries in the classic
search experience. The query is expanded based on the entries in the thesaurus. You create and maintain the
thesaurus file in a system external to SharePoint Server before you import it into SharePoint Server to make the
synonyms available to the search system.
NOTE
You can only deploy one thesaurus per SharePoint Server farm.
Create a thesaurus
To define the entries in your thesaurus, you enter terms and their corresponding synonyms in a comma separated
(.csv) file. Optionally, you can also specify in which language the query should be written for a synonym to apply.
If you want to define more than one synonym for one key, you have to create multiple entries in the thesaurus.
Also, if you want the synonym to work both ways, for example, if you want the term "IE" to also return search
results for "Internet Explorer" and you want the term "Internet Explorer" to also return results for "IE", you have to
create two thesaurus entries.
To create your thesaurus terms, you can use alphabetical Unicode characters such as a, ø, ü or é. Your terms can
also include underscores (_), hyphens (-) and straight apostrophes ('). Your terms can't include non-alphabetical
Unicode characters, such as hashtag (#), forward slash (/), back slash () , punctuation (.) or question mark (?). You
also can't use abbreviations that include non-alphabetical Unicode characters, such as E.K.G or d\r.
The matching between the thesaurus keys and query terms is not case sensitive. When a query term matches a
thesaurus key, the query is expanded with the synonym(s) for that key and the search results will contain results
for the original query term as well as for the synonym.
To create a thesaurus
1. Create a .csv file with the columns Key, Synonym and Language. Make sure you use a comma as the column
separator. If the file contains non-ASCII characters such as diacritics, you must encode it in UTF -8. Save the file
to a location that is accessible from the server from which you will run the Microsoft PowerShell cmdlet to
deploy the thesaurus.
In the Key column, enter the term (single or multiple words) that you want to trigger a synonym for when
the term occurs in a query. Make sure there are no leading or trailing spaces around the terms.
In the Synonym column, enter the synonym (single or multiple words) that you want to add to the query if
the term specified in the Key column occurs in a query. Synonyms consisting of multiple words will be
added as phrases to the query.
In the optional Language column, enter the abbreviation for the language for which the synonym should
apply. See the table in Linguistic search features in SharePoint Server for an overview of available
languages and their code. If you leave this column empty, the query is expanded with the synonym
regardless of the query language. Make sure there are no leading or trailing spaces around the language
codes.
A thesaurus is commonly used to expand acronyms. But you can also use a thesaurus to automatically include
variations of a search term into the query for specific terminology used in your organization. An example
thesaurus file input could look like this: Key,Synonym,Language IE,Internet Explorer Internet Explorer,IE UN,United
Nations,en UN,Vereinte Nationen,de BAM,billing and account management billing and account
management,billing and accounts
Deploy a thesaurus
You create and maintain the thesaurus file in a file external to SharePoint Server before you import it into
SharePoint Server to make the synonyms available to the search system. You can't export a thesaurus from
SharePoint Server. If you want to make changes to your synonyms, you have to update the thesaurus file and then
redeploy it.
NOTE
When you redeploy a thesaurus file, the existing thesaurus will be overwritten with the information from the updated
thesaurus file.
To import a thesaurus file

application.
3. At the Windows PowerShell command prompt, type the following command:
$searchApp = Get-SPEnterpriseSearchServiceApplication
Import-SPEnterpriseSearchThesaurus -SearchApplication $searchApp -Filename <Path>
Where:
<Path> specifies the full UNC path of the .csv file (the thesaurus) to be imported.
See also
Linguistic search features in SharePoint Server
Import-SPEnterpriseSearchThesaurus
Configure authoritative pages in SharePoint Server

Static rank determines the relative importance of a page, and it is computed as the smallest number of clicks it
would take a user to navigate from an authoritative page to a document. The closer a document is to the most
authoritative page, the higher its static rank is.
An administrator provides a small set of authoritative pages. An example of an authoritative page could be the
home page of a company portal.
An administrator with specific knowledge of an area can influence the relative importance of pages by specifying
additional authoritative and non-authoritative pages. An example of non-authoritative pages could be URLs of
sites that contain outdated information that are kept for record-keeping
Specify pages as authoritative or non-authoritative

Use the following procedure to specify pages as authoritative or non-authoritative.
To specify pages as authoritative or non-authoritative
application.
4. On the Search Administration page, in the Quick Launch, click Authoritative Pages.
5. On the Specify Authoritative Pages page, in the Most authoritative pages box in the Authoritative Web
Pages section, type the URLs of pages that are the most authoritative. Separate the URLs with returns so
that there is one URL per line.
6. In the Second-level authoritative pages box, type the URLs of any pages that should be seen as second-
level.
7. In the Third-level authoritative pages box, type the URLs of any pages that should be seen as third-level.
8. In the Non-authoritative Sites section, in the Sites to demote box, type the URLs of any sites that you
want to be ranked lower than all of the other sites. Type one URL per line.
All URLs whose prefix matches the prefix of a URL in the Sites to demote box are demoted. Example:
Entering http://archive/ demotes the rank of all URLs that begin with http://archive/.
9. In the Relevance Ranking Analytics section, select the Refresh now check box to run the ranking
analytics you have defined or that you have updated.
If you clear the check box, ranking analytics run later according to a defined schedule.
10. Click OK.

Without using any custom code, a Search service application administrator, site collection administrator, or site
owner can improve classic search results by creating and managing query rules. Query rules help searches
respond to the intent of users.
In a query rule, you specify conditions and correlated actions. When a query meets the conditions in a query rule,
the search system performs the actions specified in the rule to improve the relevance of the search results, such
as by narrowing results or changing the order in which results are displayed. For example, a query rule condition
could be that a term in a query matches a particular term in a SharePoint Server term set, or that a query is
frequently performed on a particular result source in a search system, such as videos. When the query rule
condition is satisfied, a correlated action could be to show a specific item at the top of the search results.
You can configure query rules for one or more result sources, and you can specify the time period during which
the query rule is active.
NOTE
A query rule also affects the modern search experience in SharePoint Server 2019 when:
The action in the rule is to promote an individual result towards the top of search results.
The rule is defined for the default result source.
The rule is defined at the Search service application level.
Users only see such a promoted result in the modern search experience when:
They’ve searched for results across all of SharePoint.
The search results page is filtered to All result types (default view).
Creating query rules at different levels in a SharePoint Server farm

You can create a query rule for a Search service application, a site collection, or a site. The following table shows
the permissions that are required to create a query rule in each case, and where the query rule can be used.
Levels and permissions for query rules
WHEN YOU CREATE A QUERY RULE AT

THIS LEVEL YOU MUST HAVE THIS PERMISSION THE QUERY RULE CAN BE USED IN
Search service application Search service application administrator All site collections in web applications
that consume the Search service
application
Site collection Site collection administrator All sites in the site collection
Site Site owner The site
To add or edit a query rule, you must go to the Manage query rules page. Depending on the level at which you
are creating the query rule, use one of the following procedures to go to the Manage query rules page.
To go to the Manage query rules page for a Search service application
application.
applications.
3. Click the Search service application to which you want to add query rules.
4. On the Search Administration page for the Search service application, in the Quick Launch, in the Queries
and Results section, click Query Rules.
To go to the Manage query rules page for a site collection
2. On the Settings menu for the site collection, click Site Settings.
3. On the Site Settings page, in the Site Collection Administration section, click Search Query Rules.
To go to the Manage query rules page for a site
1. Verify that the user account that performs this procedure is a member of the Owners group for the site.
3. On the Site Settings page, in the Site Administration section, click Query Rules.
Create a query rule

1. Specify a result source for this query rule. Use the Select a Result Source menu, on the Manage Query
Rules page.
2. Click New Query Rule.
3. Give the query rule a name. Use the Rule name field on the Add Query Rule page.
4. If relevant, restrict this rule to queries performed on a particular result source. Click to expand the Context
section, and under Query is performed on these sourcesselect one of the following:
To apply the query rule to all result sources, select All sources.
To restrict the query rule to one or more specific result sources, select One of these sources. By default,
the result source that you specified in step 1 is selected.
5. If relevant, restrict the rule to be performed from a particular category —for example, that a query rule should
fire only when a term from your managed navigation term set is included in the query. In the Context section,
under Query is performed from these categories select one of the following:
To restrict the query rule to a particular category, click One of these categories and then add the
category. In the Import from Taxonomy dialog box, select a term that when you include it in a query will
cause the query rule to fire, and then click Save.
To remove any restrictions, click All categories.
6. If relevant, restrict the rule to be performed by a particular user segment. In the Context section, under
Query is performed by these user segments select one of the following::
To restrict the query rule to a particular user segment, click One of these user segments and then add
the user segment. Enter a title for the user segment and then click Add user segment term. In the
Import from Taxonomy dialog box, select a term that when you include it in a query will cause the query
rule to fire, and then click Save.
To remove any restrictions, click All user segments.
7. Specify when a query makes this rule fire. You can have more than one condition, and the rule will fire when
any condition is true. In the Query Conditions section do one of the following:
Select one of the conditions listed in Overview of conditions that make a query rule fire.
Add an alternate condition.
Click Remove Condition to configure this query rule to fire for every query that users type at the level at
which you are creating the rule. For example, if you are creating this rule for a site collection, click Remove
Condition if you want this rule to fire for every query that users type inside any search box in the site
collection.
8. Specify the action to take when the query rule fires. In the Actions section you can:
Promote individual results so that they appear towards the top of search results. You can add several
individual promoted results. When there is more than one promoted result, you can specify the relative
ranking. To promote, click Add Promoted Result (in SharePoint 2010 Products this was called Best Bets).
In the Add Promoted Result dialog box give the promoted result a name and enter the URL of the result
to promote. You can define that the URL is rendered as a banner instead of as a hyperlink.
Promote a group of search results, click Add Result Block. For more information, see Create and display
a result block later in this article.
Change ranked search results, click Change ranked results by changing the query. For more
information, see Change ranked search results later in this article.
9. To make the query rule active during a particular time period, click Publishing, and then specify the period.
Overview of conditions that make a query rule fire
QUERY CONDITION DESCRIPTION CONFIGURATION EXAMPLE
Query Matches Keyword Select this option if you In the Query exactly You type "picture; pic" in the
Exactly want the query rule to fire matches one of these Query contains one of
when a query exactly phrases text box, type one these phrases box. The
matches a word or phrase or more phrases separated query rule will fire when a
that you specify. by semicolons. user types "picture" or "pic"
in a search box. The rule will
not fire if a user types
"pictures" or "sunny picture."
Query Contains Action Select this option if you The action term can be one You type the word
Term want the query rule to fire of several phrases that you "download" in the Action
when a query contains a enter. Alternatively the term is one of these
term that indicates action term can be an entry phrases text box. When a
something that the user in a dictionary, where you user types "download
wants to do. The term must import the term. Contoso Electronics
be at the beginning or end datasheet" in a search box,
of the query. the user is probably not
searching for a document
that contains the words
"download," "Contoso,"
"Electronics," and
"datasheet." Instead, the
user is probably trying to
download a Contoso
Electronics datasheet. When
a user types "download
Contoso Electronics
datasheet" in a search box,
the query rule fires, and
only the words "Contoso,"
"Electronics," and
"datasheet" are passed to
the search index.
Query Matches Select this option if you From the ** Query contains A word that a user types in
Dictionary Exactly want the query rule to fire an entry in this dictionary ** a search box matches an
when the query exactly menu, select a dictionary. To entry in the pre-configured
matches a dictionary entry. specify a different dictionary, People Names dictionary.
click Import from
taxonomy, and then from
the Import from
taxonomy dialog box,
select a term from a term
set, and then click Save.
Query More Common in Select this option if you In the Query is more In the Query is more
Source want the query rule to fire if likely to be used in this likely to be used in this
the query was frequently source menu, select a result source menu, you select
issued by users on a source. Local Video Results. The
different result source that query rule will fire if a user
you specify. types the word "training" in
a search box and that word
was frequently typed in a
search box in the Videos
vertical.
Result Type Commonly Select this option if you In the Commonly clicked In the Commonly clicked
Clicked want the query rule to fire if results match result type results match result type
other users frequently menu, select a result type. box, you select SharePoint
clicked a particular result MicroBlog post. If users
type after they typed the frequently click a microblog
same query. post in search results, then
in the Actions section, you
might want to configure the
most recent microblog post
as the first promoted result,
and the next most recent
microblog post as the
second promoted result.
Advanced Query Text Select this option if you To match all phone numbers To match all phone numbers
Match want to use a regular that are in a certain format, that are in the format nnn-
expression, a phrase, or a you specify a regular nnn-nnnn, you specify the
dictionary entry that will expression in the Query regular expression "(?
cause the query rule to fire. matches this regular (\d{3}))?-?(\d{3})-(\d{4})".
expression box.
Create and display a result block

A result block is several search results that are displayed as a group. For example, for a query that contains
"Fabrikam sales report", a query rule might use a taxonomy dictionary to recognize "Fabrikam" as a customer,
and then display a result block with pertinent results about Fabrikam from your customer relationship
management (CRM ) system.
In the same manner as you can promote a specific result, you can promote a result block when a specified query
condition applies.
When you configure the query to run for a result block, you can use query variables. Query variables are
placeholders for values that you don't know when you specify the query. However, when the query is run, this
information is known and can be used when the system sends the query to the index. Examples are {User.Name},
which represents the display name of the user who typed the query, or {searchBoxQuery}, which represents the
query that a user typed in a search box. See Query variables in SharePoint Server for a list of available query
variables.
If you're not familiar with query variables, you can use the Query Builder to configure the query (see step 3 in the
following procedure).
To create a result block
1. In step 8 of the previous procedure, on the Add Query Rule page, in the Actions section, click Add
Result Block.
2. Enter the title that shall appear in the result block in the Title field in the Block Title section. Enter a title
for each language that's relevant.
3. Configure the query that gives results for the block. In the Query section, click Launch Query Builder,
and on the BASIC tab do the following:.
Select which content to search by selecting a result source from the drop-down list in the Select a query
section.
Specify your query in the Query text box. You can select pre-defined query variables from the Keyword
filter drop-down list, and then add them to the Query text box by clicking Add keyword filter.
If relevant, use property filters to query the content of managed properties that are set to queryable in the
search schema. You can select managed properties from the Property filter drop-down list. Click Add
property filter to add the filter to the query.
Test the query by clicking Test query.
4. Specify how the search results within your result block should be sorted. Sorting of search results is case
sensitive. On the SORTING tab, in the Sort by drop-down list, select a managed property, and then
select Descending or Ascending. The list only contains managed properties that are set as sortable in
the search schema. You can also sort by rank. To add more sorting levels, click Add sort level:
5. If you chose to sort by rank, you can optionally:
Select which model to use for ranking search results (this selection is optional). Use the Ranking Model
drop-down list.
Define rules for dynamically changing the ordering of results. In the Dynamic ordering section, define
when to change ranking by selecting a condition from the drop-down list and then specifying whether to
promote or demote the result. To add more rules, click Add dynamic ordering rules
6. Preview the final query that will be run by the Content Search Web Part, on the TEST tab. The preview is
based on the original query template where dynamic variables are substituted with current values. Other
changes to the query may have to be made as part of query rules. Click Show more to display additional
information.
The Query template box shows the content of the query template that is applied to the query.
The Query template variables section shows the query variables that will be applied to the query, and
the values of the variables that apply to the current page. You can type other values to test the effect they
will have on the query. Click the Test Query button to preview the search results.
7. Define which result source this result block should be applied to. Use the Search this Source drop-down
list in the Query section.
8. Define how many results ro show in the result block. Use the In the Items drop-down list, in the Query
section.
9. The result block will only display the number of search results that you specified in the previous step.
However, you can add a SHOW MORE link at the bottom of the result block that will show all search
results for the result block. To add a SHOW MORE link, expand the Settings section, select "More" link
goes to the following URL, and then type a URL. You can use query variables in this URL — for
example, http://www.<site>/search/results.aspx?k={subjectTerms} .
10. Skip the Routing section.
11. Click OK.
Change ranked search results

The ranking model calculates a ranking order of search results. You can change this ranking by promoting or
demoting items within the search results. For example, for a query that contains "download toolbox," you can
create a query rule that recognizes the word "download" as an action term, and change the ranked search results
to promote a URL of a particular download site on your intranet. You can also change the sorting order of the
search results dynamically, based on several variables such as file name extension or specific keywords. Changing
ranked search results by changing the query has the advantage that the results are security trimmed and
refinable. Moreover, the search results will not appear if the document is no longer available.
To change ranked search results by changing the query
1. From step 8 of the procedure Create a query rule, on the Add Query Rule page, in the Actions section,
click Change ranked results by changing the query. The Build Your Query dialog box appears.
2. On the BASIC tab do the following:.
Select which content to search by selecting a result source from the drop-down list in the Select a query
section.
Specify your query in the Query text box. You can select pre-defined query variables from the Keyword
filter drop-down list, and then add them to the Query text box by clicking Add keyword filter.
If relevant, use property filters to query the content of managed properties that are set to queryable in the
search schema. You can select managed properties from the Property filter drop-down list. Click Add
property filter to add the filter to the query.
Test the query by clicking Test query.
3. Specify how the search results within your result block should be sorted. Sorting of search results is case
sensitive. On the SORTING tab, in the Sort by drop-down list, select a managed property, and then
select Descending or Ascending. The list only contains managed properties that are set as sortable in
the search schema. You can also sort by rank. To add more sorting levels, click Add sort level:
4. If you chose to sort by rank, you can optionally:
Select which model to use for ranking search results (this selection is optional). Use the Ranking Model
drop-down list.
Define rules for dynamically changing the ordering of results. In the Dynamic ordering section, define
when to change ranking by selecting a condition from the drop-down list and then specifying whether to
promote or demote the result. To add more rules, click Add dynamic ordering rules
5. Preview the final query that will be run by the Content Search Web Part, on the TEST tab. The preview is
based on the original query template where dynamic variables are substituted with current values. Other
changes to the query may have to be made as part of query rules. Click Show more to display additional
information.
The Query template box shows the content of the query template that is applied to the query.
The Query template variables section shows the query variables that will be applied to the query, and
the values of the variables that apply to the current page. You can type other values to test the effect they
will have on the query. Click the Test Query button to preview the search results.
Make a query rule inactive

Query rules that are created at the Search service application level are inherited by site collections and sites that
are in web applications that consume the Search service application. Similarly, query rules that are created at the
site collection level are inherited by sites in the site collection. If you don't want a query rule to apply to a site that
inherits it, you can set the query rule as inactive for the site.
To make a query rule inactive on a site
1. Verify that the user account that performs this procedure is a member of the Owners group for the site.
2. In the site collection, in the Settings menu, click Site Settings.
3. On the Site Settings page, in the Search section, click Query Rules.
4. On the Manage Query Rules page, on the Select a Result Source menu, select the result source that
contains the query rule that you want to make inactive.
5. In the Name column, point to the query rule that you want to make inactive, click the arrow that appears,
and then click Make Inactive.
Rank query rules

When multiple query rules are active for a Search service application, a site collection, or a site, more than one
rule can fire for a query that is performed at that level. By default, the rules do not fire in a prescribed order. You
can control the order in which the rules fire by adding the query rules that you create to query groups. To do this,
you select rules to add to a group, and then you specify the order in which the rules in the group will fire if they
are triggered. You can also prevent query rules that rank lowest in a group from firing even if they are triggered.
To rank query rules for a site collection
2. In the site collection, on the Settings menu, click Site Settings.
3. On the Site Settings page, in the Site Collection Administration section, click Search Query Rules.
4. On the Manage Query Rules page, on the Select a Result Source menu, select the result source that
contains the query rules that you want to group.
5. For each query rule that you created that you want to add to a group, point to the rule and select the check
box.
NOTE
Query rules that you created for this site collection are listed in the Defined for this site collection section.
6. Click Order Selected Rules.

7. In the Order Selected Rules dialog box, do either of the following, and then click OK:
Select Move rules to new group with this name, and then type a name for the group.
Select Move rules to existing group and select a group in the drop-down list.
8. On the Manage Query Rules page, do the following:
9. To change the order in which a rule in a group will fire if it is triggered, change the numeric order of the
rule.
10. To prevent query rules that are ranked lowest in the group from firing, in the row for the group's query
rule that should fire last, in the Actions column, in the Continue/Stop drop-down list, select Stop.
See also
Concepts
Overview of search result ranking in SharePoint Server
Configure result sources for search in SharePoint
Server

Result sources limit searches to certain content or to a subset of search results. SharePoint Server provides 16
pre-defined result sources for the classic search experience. The pre-configured default result source is Local
SharePoint Results. You can specify a different result source as the default. The modern search experience uses
the default results source, so if you change the default result source for classic search, you also change it for
modern search. For more information, see Understanding result sources for search in SharePoint Server.
Create a result source

You can create a result source for a Search service application, a site collection, or a site. The following table
shows the permissions that are required to create a result source at each level, and where the result source can
be used.
Levels and permissions for result sources
WHEN YOU CREATE A RESULT SOURCE AT

THIS LEVEL YOU MUST HAVE THIS PERMISSION THE RESULT SOURCE CAN BE USED IN
Search service application Search service application All site collections in web applications
administrator that consume the Search service
application
Site collection Site collection administrator All sites in the site collection
Site Site owner The site
To create a result source

Depending on the level at which you want to create the result source, first do one of the following:
To create a result source for a Search service application:
Verify that the user account that performs this procedure is an administrator on the Search service
application.
In Central Administration, in the Application Management section, click Manage service
application.
Click the Search service application for which you want to create a result source.
On the Search Administration page for the Search service application, on the Quick Launch, in
the Queries and Results section, click Result Sources.
To create a result source for a site collection:
Verify that the user account that performs this procedure is an administrator for the site collection.
On the Settings menu for the site collection, click Site Settings.
On the Site Settings page, in the Site Collection Administration section, click Search Result
Sources.
To create a result source for a site:
Verify that the user account that performs this procedure is a member of the Owners group for the
site.
On the Settings menu for the site, click Site Settings.
On the Site Settings page, in the Search section, click Result Sources.
Next:
1. On the Manage Result Sources page, click New Result Source.
2. On the Add Result Source page, in the General Information section, do the following:
In the Name box, type a name for the result source.
In the Description box, type a description of the result source.
3. In the Protocol section, select one of the following protocols for retrieving search results:
Local SharePoint, the default protocol, provides results from the search index for this Search service
application.
Remote SharePoint provides results from the index of a search service in another farm.
IMPORTANT
To use the Remote SharePoint protocol to get search results in one SharePoint Server on-premises farm from the
index of another SharePoint Server on-premises farm, you must configure the farm that receives the queries to
trust the farm that sends the queries. For information about how to do this, see Configure trust for search
between two SharePoint Server farms.
OpenSearch provides results from a search engine that uses the OpenSearch 1.0/1.1 protocol.
Exchange provides results from Exchange Server through a SharePoint Server eDiscovery Center. Click
Use AutoDiscover to have the search system find an Exchange Server endpoint automatically, or type
the URL of the Exchange web service to retrieve results from — for example,
https://contoso.com/ews/exchange.asmx.
NOTE
The Exchange protocol only enables you to discover Exchange Server content, and only from a SharePoint Server
eDiscovery Center. For more information, see Configure communication between SharePoint Server and Exchange
Server . > The Exchange Web Services Managed API must be installed on the computer on which the search
service is running. For more information, see Optional software supported in SharePoint Server 2016 in Hardware
and software requirements for SharePoint Server 2016.
4. In the previous step, if you selected either Local SharePoint or Remote SharePoint for the protocol,
then in the Type section, select SharePoint Search Results to search the whole index, or select People
Search Results to enable query processing that is specific to people search.
5. If you selected Remote SharePoint for the protocol, then in the Remote Service URL section, type the
address of the root site collection of the remote SharePoint farm.
6. If you selected OpenSearch 1.0/1.1 for the protocol, then in the Source URL section, type the URL of
the OpenSearch source.
7. If you selected Exchange for the protocol, then in the Exchange Source URL section, type the URL of
the Exchange web service — for example, https://contoso.com/ews/exchange.asmx.
8. In the Query Transform section, do one of the following:
Leave the default query transform ( searchTerms) as is. In this case, the query will be unchanged since
the previous transform.
Type a different query transform in the text box. For more information, see Understanding query
transforms.
Use the Query Builder to configure a query transform by doing the following:
Click Launch Query Builder.
In the Build Your Query dialog box, optionally build the query by specifying filters, sorting, and
testing on the tabs as shown in the following tables.
On the BASICS tab
Keyword filter You can use keyword filters to add pre-defined query
variables to the query transform. You can select pre-defined
query variables from the drop-down list, and then add them
to the query by clicking Add keyword filter.
For an overview of query variables, see Query variables in

SharePoint Server.
Property filter You can use property filters to query the content of
managed properties that are set to queryable in the search
schema.
You can select managed properties from the Property filter

drop-down list. Click Add property filter to add the filter to
the query.
On the SORTING tab
Sort results In the Sort by menu, you can select a managed property
from the list of managed properties that are set as sortable
in the search schema, and then select Descending or
Ascending. To sort by relevance, that is, to use a ranking
model, select Rank. You can click Add sort level to specify a
property for a secondary level of sorting for search results.
Note that sorting of search results is case sensitive.
Ranking Model If you selected Rank from the Sort by list, you can select the
ranking model to use for sorting.
Dynamic ordering You can click Add dynamic ordering rule to specify
additional ranking by adding rules that change the order of
results within the result block when certain conditions are
satisfied.
On the TEST tab

Query text You can view the final query text, which is based on the
original query template, the applicable query rules, and the
variable values.
Click Show more to display the options in the following

rows of this table.
Query template You can view the query as it is defined in the BASICS tab or
in the text box in the Query transform section on the Add
Result Source page.
Query template variables You can test the query template by specifying values for the
query variables.
Finally, on the Add Result Source page, in the Credentials Information section, select the authentication type
that you want for users to connect to the result source.
Set a result source as default

You can set any result source as the default result source. Specifying a result source as default can make it easier
to edit the query in Search Web Parts. For example, when you add a Content Search Web Part to a page, the
Web Part automatically uses the default result source. For more information, see Configure Search Web Parts in
SharePoint Server.
NOTE
The modern search experience in SharePoint Server 2019 gets results from the default result source. If you change the
default result source it impacts both the classic and modern search experiences.
To set a result source as default

Perform the appropriate procedures in the following list depending on the level at which the result source was
configured.
If the result source was created at the Search service application level, do the following:
application.
applications.
3. Click the Search service application for which you want to set the result source as default.
4. On the Search Administration page, in the Queries and Results section, click Result Sources.
If the result source is at the site collection level, do the following:
1. Verify that the user account that performs this procedure is an administrator for the site collection
administrator.
2. On the Settings menu for the site collection, click Site Settings.
3. On the Site Settings page, in the Site Collection Administration section, click Search Result
Sources.
If the result source is at the site level, do the following:
1. Verify that the user account that performs this procedure is a member of the Owners group for the
site.
3. On the Site Settings page, in the Search section, click Result Sources.
On the Manage Result Sources page, point to the result source that you want to set as default, click the
arrow that appears, and then click Set as Default.
See also
Create and deploy custom entity extractors in
SharePoint Server

You create and maintain the custom entity extractor file in a system external to SharePoint Server before you
import it into SharePoint Server to make the custom entity extractor available to the search system.
To use custom entities as refiners in classic search, you first create a custom entity extraction dictionary and deploy
it. Then, you configure a managed property to use a custom entity extractor and run a full crawl. After that, you
can configure the Refinement Web Part on the search results page to use the custom entity as a refiner.
Before you begin

Before you begin this operation, you must have have in place:
A Search service application
One or more fully crawled content sources
A search results page
Create a custom entity extraction dictionary

To create a custom entity extraction dictionary
1. Determine which type of custom entity extraction dictionary you want to create: Word, Word Part, Word
exact or Word Part exact. See Overview of custom entity extractor types.
2. Create a .csv file with the columns Key and Display Form. Make sure you use a comma as the column
separator. If the file contains non-ASCII characters such as diacritics, you must encode it in UTF -8. Save the
file to a location that is accessible from the server from which you will run the Microsoft PowerShell cmdlet
to deploy the custom entity extraction dictionary.
In the Key column, enter the term (single or multiple words) that you want to include as custom entities.
You can use more than one line per key. Make sure there are no leading or trailing spaces around the terms.
(Optional) In the Display form column, enter a refiner name. If you leave this column empty, the term that
is extracted from the content will be displayed as the refiner in the same case as it occurs in the content.
Use the Display Form column to control and standardize the way in which the refiner is displayed.
For example, an organization named Contoso has a certification system with three levels: Contoso Beginner,
Contoso Professional and Contoso Expert. Contoso wants to extract these entities and wants to be able to refine
on all of them. Regardless of the case in which the word "Contoso", "beginner", "professional" or "expert" is
written, they want to display the refiner as Contoso Beginner, Contoso Professional and Contoso Expert. For
this example, the custom entity extraction dictionary file input could look like this:
Key,Display form
Contoso Beginner,Contoso Beginner
Contoso B1,Contoso Beginner
Contoso Professional,Contoso Professional
Contoso prof,Contoso Professional
Contoso Expert,Contoso Expert
Deploy a custom entity extraction dictionary

To deploy the custom entity extraction dictionary, you must import it into SharePoint Server.
To import a custom entity extraction dictionary
1. Verify that the user account that is importing the custom entity extractor dictionary is an administrator for
3. At the Windows PowerShell command prompt, type the following command:
Import-SPEnterpriseSearchCustomExtractionDictionary -SearchApplication $searchApp -Filename <Path> -
DictionaryName <Dictionary name>
Where:
<Path> specifies the full UNC path of the .csv file (the custom extraction dictionary) to be imported.
<Dictionary name> is the name of the type of the custom extraction dictionary.
Depending on which type of dictionary you are importing, enter one of the following:
- Microsoft.UserDictionaries.EntityExtraction.Custom.Word. *n* [where *n* = 1,2,3,4 or 5]
- Microsoft.UserDictionaries.EntityExtraction.Custom.ExactWord.1
- Microsoft.UserDictionaries.EntityExtraction.Custom.WordPart. *n* [where *n* = 1,2,3,4 or 5]
- Microsoft.UserDictionaries.EntityExtraction.Custom.ExactWordPart.1
Configure a managed property for custom entity extraction

The following procedure describes how to associate the custom entity extraction dictionary with an existing
managed property from which you want to extract custom entities. Typically, this is a managed property that you
expect to contain these entities, such as the managed properties Title or Body. Custom entities are extracted from
the full contents of the managed property they are associated with, even if sections in those contents are tagged
as <no index>.
To specify from which existing managed property custom entities should be extracted, you edit the existing
managed property. For more information about managing crawled and managed properties, see Manage the
search schema in SharePoint Server.
To edit a managed property for custom entity extraction
1. Verify that the user account is the administrator of the Search service application.
Schema.
5. On the Managed Properties page, find the managed property that you want to associate the custom
entity extraction dictionary with that contains the single or multiple words (or word parts). You can also
enter the name of the managed property in the Filter box.
6. Point to the managed property, click the arrow and then click Edit/Map property.
7. On the Edit Managed Property page, edit the settings under Custom entity extraction. Select the custom
entity extraction dictionary that you have imported, and then click OK.
After the next full crawl has completed, the custom entity extractor is enabled. The original managed property
content is saved unchanged in the search index. In addition, depending on the type of custom entity extractor you
have enabled, the extracted entities are copied to one or more of the following managed
properties:WordCustomRefiner1, WordCustomRefiner2, WordCustomRefiner3, WordCustomRefiner4,
WordCustomRefiner5WordExactCustomRefinerWordPartCustomRefiner1, WordPartCustomRefiner2,
WordPartCustomRefiner3. WordPartCustomRefiner4,
WordPartCustomRefiner5WordPartExactCustomRefinerThese managed properties are automatically configured
to be searchable, queryable, retrievable, sortable and refinable.
Configure a refiner in the Web Part

You can use the extracted custom entities as refiners in the search results page. The refiners based on the custom
entities are available in the Refinement Web Part.
To add a refiner based on a custom entity extractor
2. Browse to the page that contains the Refinement Web Part that you want to configure, click the Settings
menu and then click Edit Page.
3. Edit the Refinement Web Part. Click the Refinement Web Part Menu arrow, and then click Edit Web
Part.
In the Web Part tool pane, in the Properties for Search Refinement section, verify that the Choose
Refiners in this Web Part is selected.
Click Choose Refiners.
On the Refinement configuration page, from the Available refiners section, use the buttons to select one or
more managed properties containing extracted entities that you want to show as refiners from the list and
click Add. For example, if you have deployed a word extraction dictionary, choose WordCustomRefiner1.
In the Configure for section, configure how you want each refiner to appear.
4. Click OK.
Overview of custom entity extractor types

The following table shows what type of custom extraction dictionaries you can create and how the dictionary
entries are matched with content in the search index, which dictionary name you should use when you deploy the
dictionary and which managed property will contain the extracted entities..
CUSTOM ENTITY MANAGED PROPERTY

EX TRACTOR / CUSTOM DICTIONARY NAME TO THAT WILL CONTAIN
ENTITY EX TRACTOR USE IN WINDOWS THE EX TRACTED
DICTIONARY DESCRIPTION EXAMPLE POWERSHELL ENTITY
Word Extraction Case-insensitive, The entry "anchor" Microsoft.UserDiction WordCustomRefiner1

dictionary entries matches "anchor" and aries.EntityExtraction. WordCustomRefiner2
matching tokenized "Anchor," but not Custom.Word.n WordCustomRefiner3
content, maximum 5 "anchorage" [where n = 1,2,3,4 or WordCustomRefiner4
dictionaries. 5] WordCustomRefiner5
Word Part Extraction Case-insensitive, The entry "anchor" Microsoft.UserDiction WordPartCustomRefi

dictionary entries matches "anchor," aries.EntityExtraction. ner1
matching un- "Anchor" and Custom.WordPart.n WordPartCustomRefi
tokenized content, "anchorage" [where n = 1,2,3,4 or ner2
maximum 5 5] WordPartCustomRefi
dictionaries. ner3
WordPartCustomRefi
ner4
WordPartCustomRefi
ner5
Word Exact Extraction Case-sensitive, The entry "anchor" Microsoft.UserDiction WordExactCustomRefi

dictionary entries matches "anchor," but aries.EntityExtraction. ner
matching tokenized not "Anchor" or Custom.ExactWord.1
content, maximum 1 "Anchorage"
dictionary.
Word Part Exact Case-sensitive, The entry "anchor" Microsoft.UserDiction WordPartExactCusto

Extraction dictionary entries matches "anchor" and aries.EntityExtraction. mRefiner
matching un- "anchorage," but not Custom.ExactWordPa
tokenized content, "Anchor" rt.1
maximum 1
dictionary.
See also
Import-SPEnterpriseSearchCustomExtractionDictionary
Manage company name extraction in SharePoint
Server

The search system can extract company names from content. The following conditions must be met before
company names can be extracted:
The managed property setting Company name extraction must be enabled on the managed property
that you want to extract company names from. Typically, this is a managed property that you expect to
contain these entities, such as the managed properties Title or Body. Company names are extracted from
the full contents of the managed property they are associated with, even if sections in those contents are
tagged as <no index>.
The name of the company that you want to extract should either already exist in the prepopulated company
name dictionary or it should be included in the Company Inclusions list.
A full crawl must be completed.
For example, if a company name is found in the body of a document, company name extraction is enabled on
the managed property Body and a full crawl has been run, the company name is extracted and mapped to the
managed property companies. You can then use the companies managed property to create refiners based on
the extracted company name in the Refinement Web Part on the search results page.
There is a prepopulated dictionary for company name extraction which includes a large number of company
names. You can add additional company names to be extracted or prevent particular company names from being
extracted using the Company Inclusions or Company Exclusions lists.
This article explains how to maintain these lists. It does not cover how to enable a managed property to use
company extraction. For more information on how to enable company extraction on a managed property, see
Manage the search schema in SharePoint Server.
Open the Term Store Management Tool

The company name exclusion and inclusion lists are managed in the Term Store. Use the Term Store Management
Tool to edit the lists.
To get to the Term Store Management Tool
application.
4. On the Search Administration Page, in the Queries and Results section, click Search Dictionaries. The
Term Store Management Tool opens.
Exclude company names

To exclude company names from being extracted as entities from content, add the company name to the Company
Exclusions list.
To add a company name to the Company Exclusions list
Dictionaries menu.
2. Click Company Exclusions, click the arrow and then click Create Term.
3. Type the name of the company that you want to exclude in the box that appears.
4. Click anywhere on the page to add the term to the Company Exclusions list.
Include company names

To include company names to be extracted as entities from content, add the company name to the Company
Inclusions list.
To add a company name to the Company Inclusions list
Dictionaries menu.
2. Click Company Inclusions, click the arrow and then click Create Term.
3. Type the name of the company that you want to include in the box that appears.
4. Click anywhere on the page to add the term to the Company Inclusions list.
Edit terms
You can edit the names of terms in the Company Exclusions and Company Inclusions lists.
To edit terms
Dictionaries menu.
2. Depending on which list the term is in, click either Company Exclusions or Company Inclusions.
3. Double-click the term that you want to edit.
4. Type the new name for the term.
5. Click anywhere on the page to save the edited term.
Customize search result types in SharePoint Server

Create and configure custom search result types in SharePoint Server so that users can readily distinguish and
preview different kinds of items in a list of search results in the classic search experience.
A search result type is a rule that causes distinct kinds of search results to be displayed in different ways. It consists
of the following:
One or more characteristics or conditions to compare each search result against, such as the result source
or content type of the search result
A display template to use for search results that meet the conditions. The display template controls the way
in which all results that meet the conditions appear and behave on a search results page.
The search system has preconfigured result types that it uses by default. You can view them on the Manage Result
Types page. For example, a preconfigured result type named Person specifies that if a search result comes from
the result source Local People Results, then use the People Item display template to display the result. The
People Item display template shows certain user-profile information in the search result and provides links in the
hover panel for documents that the person has authored.
As a site collection administrator or site owner, you can use the default result types as starting points for creating
custom result types. For example, the pre-configured Microsoft Excel result type specifies the condition that the
file extension of the search result is XLS or XLSX. You could copy this result type and customize it so that it also
includes the condition that the value of the ContentType managed property is Sales Report. That way, users will
readily be able to identify certain Excel search results as sales reports.
You could also customize the default Excel Item display template for this purpose. A display template specifies
how to display managed properties of a search result, such as item title, file extension, path, and summary. This
helps users to distinguish results easily. The display template also controls how a document or site will appear in
the preview pane (also called the hover panel) to the right of the search result. This helps users to know whether a
search result will be useful to them before they click the result to open it. For example, the Excel Item display
template can display relevant charts, worksheets, and tables from an Excel document in the hover panel and enable
users to go directly to those sections in the document. For more information about display templates for search
result types, see:
Result types and display templates that are used to display search results in SharePoint Server
Create and configure a custom search result type
1. Go to the Manage Result Types page by doing one of the following:
If you want to create a result type for a site collection:
Ensure that you are an administrator for the site collection.
In the site collection, go to Settings > Site settings, and then in the Site Collection
Administration section, click Search Result Types.
If you want to create a result type for a site:
Ensure that you are a site owner for the site.
On the site, go to Settings > Site settings, and then in the Search section, click Result Types.
2. To create a result type, do one of the following on the Manage Result Types page:
Click New Result Type.
In the list of existing result types, click the name of a result type, such as Person, and then click Copy so that
you can modify the copy to create a new result type.
TIP
When you create a result type, we recommend that you use the copy method, so that the settings in an existing
result type can help guide you through the configuration process.
3. On the Add Result Type page, in the General Information section, in the Give it a name text box, type a
name for the new result type.
4. On the Add Result Type page, in the Conditions section, do the following:
In the Which source should results match? drop-down list, select a result source such as All Sources or
Documents.
For any given search result, this condition will be met if the search result is from the result source that you
selected from this drop-down list.
(Optional) In the What types of content should match? drop-down list, do the following:
Select a type of content, such as Microsoft Word.
NOTE
If you do not select a type of content, all results from the result source that you specified (in the Which source
should results match? section) will match this result type.
As many times as appropriate, click Add Value and select another type of content.
5. (Optional) On the Add Result Type page, expand the Show more conditions section, and then do the
following:
In the Which custom properties should match? section, the items in the Select a property drop-down
list are retrievable managed properties. Select a property that you want the search system to perform a
match on, such as Author.
In the second drop-down list, specify the operator, such as Equals any of.
In the text box, specify the value against which the search system should search for a match.
Separate multiple values with semicolons. Alternatively, as many times as appropriate, click Add Value and
type another value in the new text box that appears.
For example, if you select the Author property and you select the operator Equals any of, then if you
specify multiple values such as Kara and Silas, the condition will be "author equals Kara or Silas".
To add another property to match, click Add Property.
6. On the Add Result Type page, in the Actions section, do the following:
In the What should these results look like? drop-down list, click a display template such as Office
Document Item or PDF Item.
Display templates for search results are in the Search folder in the master page gallery for the site
collection. The Display template URL box automatically displays the URL of the display template that
corresponds to the display template that you selected.
Select the Optimize for frequent use check box if you expect this result type to appear frequently in
search results.
See also
Concepts
Result types and display templates that are used to display search results in SharePoint Server
Create a custom ranking model by using the Ranking
Model Tuning App

If the standard ranking models don't satisfy the relevance requirements you have, you can create a custom ranking
model for the classic search experience. With the Ranking Model Tuning App, you can do this more easily than
before. The app provides a user interface for copying an existing ranking model, judge the results for a set of
queries, add or remove rank features, and adjust the weight of these features. Finally, you can evaluate the
changes, and publish the new ranking model when you're satisfied with the results.
Why create a custom ranking model?

In most cases, the ranking models in SharePoint Server provide good search result ranking, and you can also
influence the ranking of search results with query rules. However, if you have a particular relevance need for
search results that the standard ranking models don't provide, you can create a custom ranking model.
Here are some typical use cases:
You have added a specific managed property that you think should influence ranking of items on your site.
Example: A food store has added a new managed property "gluten-free" and wants to include this managed
property in the ranking calculations of search results.
You want to give one or more of the managed properties in a standard ranking model more ranking weight
than what it gets by default.
Example: An accountancy company wants Excel workbooks (file type) to have higher ranking weight than what
they get when using the standard ranking model.
IMPORTANT
Creating a custom ranking model is rather complex, and you should not take this lightly. For a good result, expect to invest
time on tasks such as judging a considerable number of queries.
Learn more about ranking and ranking models:

Customizing ranking models to improve relevance in SharePoint
Get the app for SharePoint Server

IMPORTANT
For SharePoint Server 2013 we recommend that you have installed the SharePoint Server 2013 cumulative update from
March 2014.
Install the app and prepare the SharePoint farm to allow apps by using the same standard processes as for
all SharePoint Server apps: Install and manage apps for SharePoint.
To use the app, you must be a Search service application administrator.
Create a custom ranking model-main steps
Click the app icon to go to the starting page of the app.
Follow these main steps to create a custom ranking model. Expect to go back and forth between the different steps
as you fine-tune your model.
1. Step 1: Copy an existing ranking model and give it a name
2. Step 2: Add a judgment set
3. Step 3: Judge the results for the queries in the set
4. Step 4: Add rank features and tune the weight
5. Step 5: Evaluate the changes
6. Step 6: Publish the ranking model
Step 1: Copy an existing ranking model and give it a name

When you start the app, you see a list of all available ranking models. On first use, this will be the set of standard
ranking models delivered with SharePoint. These ranking models are marked with Base model, and the only
action allowed, is to copy . To create a custom ranking model, you copy an existing model and then modify the
copy. Any models created by using the app are marked with Not base model, and these you can also edit, publish,
or delete.
Most standard ranking models delivered with SharePoint have a linear stage and a neural stage. With this app, you
can only customize the linear stage of a ranking model, as a linear stage is easier to tune and customize.
We recommend that you use the Search Ranking Model with Two Linear Stages as the basis for your custom
ranking model, then it will be easier to re-tune and customize your ranking model.
1. In the list of existing ranking models, select the model you want to copy.
2. Click the arrow to the right and select Copy.
3. On the Edit ranking model page, type a name for your new ranking model.
4. Select the result source you want to test queries against.
Step 2: Add a judgment set

You can add one or more judgment sets to your ranking model. A judgment set typically consists of queries that
are popular, queries that are important for the business, or queries that the current ranking model doesn't handle
sufficiently well. On the Edit ranking model page, under Judge queries, choose Add judgment set.
1. On the Edit judgment set page, choose one or more of these options:
OPTION DESCRIPTION
OPTION DESCRIPTION
Import judged queries If you already have a set of queries and labels for documents
returned for the queries, you can import them. Choose the file
to upload, and then click Import queries.
The import file must be of type XML with the following
schema:
<QuerySet Name="testRM - JudgementSet"><Query
QueryString="query1" ><Judgements><Document
Url="docUrl1" Label="Excellent" /><Document
Url="docUrl2" Label="Good" /><Document Url="docUrl3"
Label="Fair" /><Document Url="docUrl4" Label="Bad"
/></Judgements></Query></QuerySet>
You can use four labels to indicate how desirable a result is for
a query: Excellent, Good, Fair, and Bad.
Add sampled queries If search has been active on the site, you can have the app
pick a random set of queries from the existing query logs. The
app will choose the queries that are more popular.
Specify the number of queries to sample in the box, and click
Add queries.
Add queries manually Type queries directly in the app, one query per line, and then
click Add queries.
You can add all queries this way, or you can manually add
more queries to an existing set of queries.
2. If you imported judged queries with labels, click Done to save the judgment set. If you added queries from the
query log or manually, you can start judging the queries, see step 3.
To ensure that the relevance metrics are reliable indicators for how good the ranking model is for a particular site,
make sure that:
There are sufficient queries in the judgment set. The more queries, and the more judged documents in the
top 10 for these queries, the better.
There is a representative mix from the range of queries you expect to have.
Step 3: Judge the results for the queries in the set

Now, go through all queries and evaluate the results for each one. Determine how relevant or desirable a
particular document in the index is as a search result for the specific query. The more relevant or desirable you
think a document is, the higher in the ranked list it is expected to be.
NOTE
If you imported already judged queries in the previous step, results already have a rating, and you can skip this step.
1. On the Edit judgment set page, for each query, click the query text and choose Judge results.
2. On the Evaluate query page, you see two sets of results side by side: Results with base model and
Results with current model. Before you make any changes to your new ranking model, the two result sets
will be the same.
For each result, evaluate the result and give it a rating (label) by choosing the number of stars, from one to
five. The one star option, "Broken link," can be used for documents you can't access.
After you've made the first round of changes to the ranking model, you can compare two result sets side by
side in this view. Compare the current ranking model with the base model or with the last saved version of
the new model. This way you can evaluate the effect of the different customizations you've made.
3. When you've rated the results for a query, click Next query to continue through the judgment set.
4. Click Done to save the set.
When you've gone through and evaluated the queries in the judgment set, you'll see the judgment coverage for
that set. After you've made changes to the model, you can see how much relevance has improved with the new
ranking model for the different judgment sets.
THIS COLUMN SHOWS THE FOLLOWING INFORMATION
Query text The queries in the judgment set.
Judgment coverage The percentage of document URLs in the current top ten that
have been rated.
NOTE: Relevance metrics are only reliable when the judgment
coverage is high. To increase coverage, judge more of the
results for the query.
Relevance vs. Base ranking After you've made changes to the ranking model, this figure
shows how much relevance has improved for the query with
the new ranking model compared to the base model. If the
score is 0.00%, there's no difference between the two models
for that query. If the score is negative, relevance has
decreased.
Vs. Saved model The app keeps a draft version of the ranking model while you
work on it. You can compare the current draft version to the
last saved version of the new ranking model.
This figure shows how much relevance has improved or
decreased with the current draft of the model compared to
the last saved version.
The metric of relevance used in the app is "Discounted Cumulative Gain" calculated for the top five results.
Step 4: Add rank features and tune the weight

When you copy an existing ranking model, the new ranking model contains the same rank features and weights as
in the base model. You can add more managed properties as additional rank features, remove existing features, or
tune the weight of existing features.
NOTE
You can only choose managed properties that have already been created and configured. Managing managed properties,
such as creating new ones or setting them to be searchable or sortable, is out of scope for this app.
Step 4a: Add rank features

1. On the Edit ranking model page, under Add and tune features, click Add features to customize.
2. On the Add a ranking feature to customize page, choose between these types of rank features:
RANKING FEATURE TYPE DESCRIPTION

RANKING FEATURE TYPE DESCRIPTION
Suggested feature based on judged queries The app can suggest features to add when feature vectors
have been extracted for a sufficient number of judged
documents. Suggestions will be rank features that have a
strong correlation (negative or positive) with the relevance
jugdements provided by the automated tuning. This option is
only available after you have run automated tuning on this
ranking model at least once. See more about automated
tuning later in this article.
Searchable text managed property Choose a managed property to be used in the search result
ranking calculations.
If you select that proximity of query terms in the property
value is important, you can later enter a Proximity weight for
the feature. The app uses the variants isExact=1 and
isDiscounted=1.
Sortable numeric managed property Also called static rank feature.

The managed property must be of type Integer. The app uses
the Rational transform.
Choose a managed property, and enter a default value for the
property. The default value will be used if an item doesn't have
a value explicitly set.
Sortable property with a specific value Also called bucketed static rank feature. Choose a managed
property, and enter the default value for the property.
Having value: This number is the specific bucket that is being
tuned.
Ranking feature from the base model Use this option to tune the weight of existing features.
Choose between existing rank features.
3. Click Add feature. Repeat steps to add more features to customize. The selected rank features are shown on
the Edit ranking model page.
You can also remove features from the model.
Read more about rank features and aggregation of rank features in Customizing ranking models to improve
relevance in SharePoint.
Step 4b: Tune the weights
Initially, new features have a zero weight, except existing rank features from the base model. To give rank features a
different weigth, you can use automated tuning or manual tuning.
Automated tuning:
With automated tuning, the judgments provided for your judgment set are used to automatically set the weight of
features in a way that attempts to maximize relevance. The auto-tune option is available when you have at least 10
queries with at least 10 judgments each. The more judgments you have, the more reliable the automatic tuning will
be.
On the Automated tuning tab, click the Autotune weights button.
NOTE
The autotune option includes a considerable amount of computation, and may take around 5 minutes for a judgment
set of 10 queries.
Manual tuning:
With manual tuning, you can set or change weights of individual rank features. Avoid very large values (negative
or positive).
1. On the Manual tuning tab, set or change the weight for a feature by entering or changing a value in the
Weight box.
2. Click Save weights to run evaluation on all judgment sets associated with this model.
3. Evaluate changes, see step 5.
Step 5: Evaluate the changes

The app lets you evaluate how a custom ranking model changes relevance. This is especially useful for queries that
you consider important.
IMPORTANT
When you create a custom ranking model, this influences all the queries using that ranking model. Test the effect of the
custom ranking model on many queries.
Type queries in the Sample query box below the Manual tuning list to see the results for a specific query.
You can compare results with the base model or the last saved model to the left, and results with the current
model to the right. You can also add queries to a judgment set from this page if you want to.
You can also evaluate the effect of a particular setting by running an evaluation on a judgment set. In the list
of judgment sets under Judge queries, click the arrow to the right of the set, and choose Evaluate
relevance from the menu.
NOTE
Changing the weight of a rank feature will affect the ordering of results, hopefully to provide improved relevance. As a result
of the re-ordering, new documents that are not yet judged may enter the top 10 results for a query. If this happens, the
judgment coverage value will go down for a judgment set, and you may have to provide additional judgments.
When you are done adding, removing, and tuning features, save your changes. The new custom ranking model
is shown in the list of available ranking models that you started off with. It is marked as Not base model.
Step 6: Publish the ranking model

The new ranking model is by default available for the site where you added the app. If you want to use your
custom ranking model more broadly, you must publish it.
1. In the Select ranking model list, click the arrow to the right, and choose Publish from the menu.
2. Choose one of the following:
Current site (available by default)
Current site collection
All site collections (the whole Search Service Application)
3. Click Publish.
When you publish your ranking model, you'll get a GUID that identifies the ranking model. You can use the GUID
in search, for example when configuring the Search Results Web Part, or to programmatically set the
RankingModelId property of a query.
More info about ranking and ranking models

Customizing ranking models to improve relevance in SharePoint Server
Configure trust for search between two SharePoint
Server farms

To configure an on-premises SharePoint Server content farm to return results from its search index to a separate
on-premises SharePoint Server farm, you must perform the following two main procedures:
1. In the farm that will receive the search queries, configure trust of the farm that will send the queries by doing
the following:
Configure a server-to-server trust relationship by using the Open Authorization 2.0 (OAuth 2.0) web
authorization protocol.
Enable the farm that receives the queries to return search results from all of its web applications that host
content.
2. In the farm that will send the search queries, create a result source that does each of the following:
Specifies Remote SharePoint as the protocol.
Specifies the address of any root site collection in the SharePoint Server farm that will receive the search
queries.
For more information, see Configure result sources for search in SharePoint Server.
NOTE
After you create the result source, you expose the search results that it provides by using it in a Web Part or a query-rule
action. In this way, users of the farm that is sending search queries can see results from the farm that is receiving the queries.
For more information, see Understanding result sources for search in SharePoint Server.
This article describes how to perform the first procedure in the list above: how to configure the farm that receives
search queries to trust the farm that sends the queries.
For brevity in this article, the following terms are used:
SendingFarm An on-premises SharePoint Server farm that has a search

service that sends search queries to ReceivingFarm.
ReceivingFarm An on-premises SharePoint Server content farm that has a

search index that receives search queries from SendingFarm.
In this article, it is assumed that ReceivingFarm has at least
one web application that hosts content.
In order for SendingFarm to be able to get search results from the search index in ReceivingFarm, the farms must
have the following characteristics:
Each farm is a SharePoint Server on-premises deployment.
User profiles in the two farms are synchronized. For more information, see Server-to-server authentication
and user profiles in SharePoint Server.
NOTE
Accessibility features in SharePoint 2013
Keyboard shortcuts
Touch
To configure ReceivingFarm to trust SendingFarm

1. Verify that the account that performs this procedure is a member of the following groups:
Farm Administrators group in ReceivingFarm.
Administrators group on the server on which you are running Microsoft PowerShell cmdlets.
An administrator of that server can use the Add-SPShellAdmin cmdlet to grant someone permission to
use SharePoint Server cmdlets. When you run the Add-SPShellAdmin cmdlet, you must have
membership in the securityadmin fixed server role on the SQL Server instances, and you must have
membership in the db_owner fixed database role on all databases that are to be updated. For more
information, see Add-SPShellAdmin. Contact your system administrator or SQL Server administrator to
request these memberships if you do not have them.
2. On a server in ReceivingFarm, start the SharePoint Management Shell.
In the SharePoint Server environment, on the Start menu, click All Programs, click SharePoint 2016, and
For Windows Server 2012:
In the SharePoint Server environment, on the Start page, click SharePoint Management Shell.
If SharePoint Management Shell is not on the Start page, right-click Computer, click All apps,
3. On a server in ReceivingFarm, run the following commands at a PowerShell command prompt. The commands
use the OAuth 2.0 web authorization protocol to configure a server-to-server trust, so that ReceivingFarm will
trust SendingFarm.
# Create a trusted security token issuer
$i = New-SPTrustedSecurityTokenIssuer -Name "SendingFarm" -IsTrustBroker:$false -MetadataEndpoint
"https://<SendingFarm_web_application>/_layouts/15/metadata/json/1"
# Configure trust of the token-signing certificate'
# by adding the trust used to sign oAuth tokens'
# to the list of trusted root authorities'
# in ReceivingFarm
New-SPTrustedRootAuthority -Name "SendingFarm" -MetadataEndPoint
https://<SendingFarm_web_application>/_layouts/15/metadata/json/1/rootcertificate
Where:
_https://\<SendingFarm_web_application\>_ is any SSL-enabled web application in SendingFarm
> [!IMPORTANT]
> Web applications that include server-to-server authentication endpoints for incoming server-to-server
requests, or that make outgoing server-to-server requests, should be configured to use Secure Sockets Layer
(SSL). For information about how to configure a web application to use SSL, see [Create claims-based web
applications in SharePoint Server](/previous-versions/office/sharepoint-server-2010/ee806885(v=office.14)).
For information about how to configure HTTP support for server-to-server requests, see [Configure server-to-
server authentication between SharePoint Server farms](/sharepoint/security-for-sharepoint-server/security-
for-sharepoint-server#HTTP) in [Configure server-to-server authentication in SharePoint Server]
(/sharepoint/security-for-sharepoint-server/security-for-sharepoint-server).
4. On a server in ReceivingFarm, at a PowerShell command prompt, run the following command:
# Use $realm to store the string'

# that comes after the "@" character'
# in the value of $i.NameId
$realm = $i.NameId.Split("@")
5. On a server in ReceivingFarm, at a PowerShell command prompt, run the following commands to enable all
web applications in ReceivingFarm to return search results to SendingFarm:
$s1 = Get-SPSite -Identity https://<ReceivingFarm_web_application>

$sc1 = Get-SPServiceContext -Site $s1
# Set up an authentication realm for'
# a web application that hosts content in ReceivingFarm
Set-SPAuthenticationRealm -ServiceContext $sc1 -Realm $realm[1]
# Get a reference to the application principal'
# for that web application in Farm B
$p = Get-SPAppPrincipal -Site https://<ReceivingFarm_web_application> -NameIdentifier $i.NameId
# Grant rights to the application principal'
# that SendingFarm will use'
# when it sends queries to ReceivingFarm
Set-SPAppPrincipalPermission -Site https://<ReceivingFarm_web_application> -AppPrincipal $p -Scope
SiteCollection -Right FullControl
Where:
_https://\<ReceivingFarm_web_application\>_ is an SSL-enabled web application in ReceivingFarm.
6. Repeat the previous step (step 5) for each web application in ReceivingFarm that hosts content that you want to
search.
See also
Configure server-to-server authentication in SharePoint Server
Setting Up an oAuth Trust Between Farms in SharePoint 2013
Getting a Full Result Set from a Remote SharePoint Index in SharePoint 2013
An Introduction to JavaScript Object Notation (JSON ) in JavaScript and .NET

The following articles provide information about how you manage search components in SharePoint Server.
Before you change the search topology, you must define, install and configure the required application servers
and database servers that you want to use for search.
For information about planning an initial enterprise search architecture, see Plan enterprise search architecture
in SharePoint Server 2016. To learn which approach to use to scale enterprise search architecture, see Scale
enterprise search in SharePoint Server. For information about planning an initial search architecture for cloud
hybrid search, see Plan your search architecture in SharePoint Server for cloud hybrid search.
For example farm architectures and search topologies for internet sites, see the technical diagrams Internet sites
search architectures for SharePoint Server 2013 and Search architectures for SharePoint Server 2013. You can
also find these diagrams in Technical diagrams for SharePoint Server . Scale search for Internet sites in
SharePoint Server gives guidance on scaling out search topology for Internet sites.
Articles about managing the search topology

The following articles about managing the search topology in SharePoint Server are available to view online.
Writers update articles on a continuing basis as new information becomes available and as users provide
feedback.
CONTENT DESCRIPTION
Change the default search topology in SharePoint Server Learn how to change from the default search topology with
an empty search index to a new search topology using
Windows PowerShell.
Manage search components in SharePoint Server Learn how to use Microsoft PowerShell to manage search
components in an existing search topology that has content
in the search index. Use these procedures to scale out or
scale down the search topology of the Search service
application.
Manage the index component in SharePoint Server Learn how and when to use Microsoft PowerShell to scale
out the search index by adding an index component to
create an additional index replica or index partition.
Manage a paused Search service application in SharePoint Learn why the Search service application is paused and what
Server you can do to resume it.
Change the default search topology in SharePoint
Server

This article explains how to create and activate search components in a new search topology starting from the
default search topology. The procedures and the examples in this article assume that SharePoint Server and the
Search service application are newly installed and that there is no content in the SharePoint Server search index.
You can also use the procedures and examples to manage the search topology in SharePoint Server when the
topology is part of a cloud hybrid search solution.
If there are items in the SharePoint Server search index, follow the procedures in Manage search components in
SharePoint Server and Manage the index component in SharePoint Server.
Before you begin

Before you begin, review the following prerequisites.
SharePoint Server is installed on a single server and a Search service application with a default search
topology is created. In the default search topology, all the search components are located on the server that
hosts Central Administration.
You are an administrator of the Search service application.
You have planned a target search topology. Plan enterprise search architecture in SharePoint Server 2016
gives step-by-step guidance for search in enterprises, including hardware requirements. For example farm
architectures and search topologies for Internet sites, see the technical diagram Internet sites search
architectures for SharePoint Server 2016. We recommend that you plan a target search topology based on
the expected number of items in the search index for search in enterprises.
SharePoint Server is installed on all the servers that you want to host search components on. The servers
have been added to the farm and you are an administrator on all these servers. You can create new
application servers or define application servers in an existing deployment.
Overview: changing a search topology without content in the search

index
The following list provides an overview of the tasks involved to change from the default search topology, without
any content in the SharePoint Server search index, to a new search topology.
Ensure that no crawls have been started and that the SharePoint Server search index is empty.
Start a search service instance on all the servers that you want to host search components on.
Create a new empty search topology.
Add search components to the new search topology.
Activate the new search topology.
Verify that the search topology is active.
Example: Change from the default search topology to a small
enterprise search topology
The following procedures will create and activate a small enterprise search topology on multiple servers, as
planned for in the table Target search topology. The small enterprise search topology uses virtual machines on
physical application servers. All search components in this example are set up with fault tolerance, which means
that all search components and index partitions are deployed across more than one physical machine on separate
failure domains.
You can follow the same procedures using different variables if you want to scale out to a larger enterprise search
topology or to a search topology for Internet Sites.
Target search topology
VIRTUAL MACHINE A (ON VIRTUAL MACHINE B (ON VIRTUAL MACHINE C (ON VIRTUAL MACHINE D (ON
PHYSICAL APPLICATION PHYSICAL APPLICATION PHYSICAL APPLICATION PHYSICAL APPLICATION
SERVER X) SERVER X) SERVER Y) SERVER Y)
MYSERVER1.EXAMPLE.COM MYSERVER2.EXAMPLE.COM MYSERVER3.EXAMPLE.COM MYSERVER4.EXAMPLE.COM
Admin component 1 Query processing Admin component 2 Query processing

component 1 component 2
Crawl component 1 Crawl component 2
Index component 1 (that Index component 2 (that
Content processing belongs to index partition 0) Content processing belongs to index partition 0)
Analytics processing Analytics processing

1. Ensure that no crawls have been started and that the search index is empty on the server that hosts Central
Administration.
Verify that the user account that is performing this procedure is an administrator for the Search service
application.
In Central Administration, in the Application Management section, click Manage Service
Applications.
On the Manage Service Applications page, in the list of service applications, click the Search service
application.
Verify that the search index is empty. On the Search Administration page, under System Status, verify
that Searchable items displays "0".
Cau t i on
If there are items in the SharePoint Server search index, do not continue with this procedure.
Verify that no crawls have been started. On the Search Administration page, under Crawling, click
Content Sources. On the Manage Content Sources page, verify that the Status column for any existing
content source displays Idle.
2. Start a SharePoint Management Shell on one of the servers in the farm.
3. Specify the new servers you want to add search components to, start a search service instance (ssi) on
these servers and create references to the search service instances. In this procedure we have used the
example host names "myserver< n >" for the servers as listed in the Target search topology table. At the
Windows PowerShell command prompt, type the following command(s):
$hostA = Get-SPEnterpriseSearchServiceInstance -Identity "myserver1"
$hostB = Get-SPEnterpriseSearchServiceInstance -Identity "myserver2"
$hostC = Get-SPEnterpriseSearchServiceInstance -Identity "myserver3"
$hostD = Get-SPEnterpriseSearchServiceInstance -Identity "myserver4"
Start-SPEnterpriseSearchServiceInstance -Identity $hostA
Start-SPEnterpriseSearchServiceInstance -Identity $hostB
Start-SPEnterpriseSearchServiceInstance -Identity $hostC
Start-SPEnterpriseSearchServiceInstance -Identity $hostD
4. Wait until all the search service instances are running. At the Windows PowerShell command prompt, type the
following commands until the commands return the state "Online" for each of the search service instances:
Get-SPEnterpriseSearchServiceInstance -Identity $hostA

Get-SPEnterpriseSearchServiceInstance -Identity $hostB
Get-SPEnterpriseSearchServiceInstance -Identity $hostC
Get-SPEnterpriseSearchServiceInstance -Identity $hostD
5. Create a new search topology and a reference to the new search topology. At the Windows PowerShell
command prompt, type the following command(s):
$newTopology = New-SPEnterpriseSearchTopology -SearchApplication $ssa
6. Add all the search components to the new search topology. The following Windows PowerShell commands
will create the search components of the new topology and assign them to the new servers. In this small
enterprise search topology there is one index partition, index partition 0. This is indicated with the parameter
-IndexPartition in the command New-SPEnterpriseSearchIndexComponent . The index partition has one index
replica on virtual machine B and one index replica on virtual machine D. Each index replica will contain the
exact same search index and is hosted on a different physical server to achieve fault tolerance. At the Windows
PowerShell command prompt, type the following command(s):
New-SPEnterpriseSearchAdminComponent -SearchTopology $newTopology -SearchServiceInstance $hostA

New-SPEnterpriseSearchCrawlComponent -SearchTopology $newTopology -SearchServiceInstance $hostA
New-SPEnterpriseSearchContentProcessingComponent -SearchTopology $newTopology -SearchServiceInstance $hostA
New-SPEnterpriseSearchAnalyticsProcessingComponent -SearchTopology $newTopology -SearchServiceInstance $hostA
New-SPEnterpriseSearchQueryProcessingComponent -SearchTopology $newTopology -SearchServiceInstance $hostB
New-SPEnterpriseSearchIndexComponent -SearchTopology $newTopology -SearchServiceInstance $hostB -
IndexPartition 0
New-SPEnterpriseSearchAdminComponent -SearchTopology $newTopology -SearchServiceInstance $hostC
New-SPEnterpriseSearchCrawlComponent -SearchTopology $newTopology -SearchServiceInstance $hostC
New-SPEnterpriseSearchContentProcessingComponent -SearchTopology $newTopology -SearchServiceInstance $hostC
New-SPEnterpriseSearchAnalyticsProcessingComponent -SearchTopology $newTopology -SearchServiceInstance $hostC
New-SPEnterpriseSearchQueryProcessingComponent -SearchTopology $newTopology -SearchServiceInstance $hostD
New-SPEnterpriseSearchIndexComponent -SearchTopology $newTopology -SearchServiceInstance $hostD -
IndexPartition 0
7. Activate the new search topology. At the Windows PowerShell command prompt, type the following
command:
Set-SPEnterpriseSearchTopology -Identity $newTopology
8. Verify that the new search topology is active. At the Windows PowerShell command prompt, type the
following command:
Get-SPEnterpriseSearchTopology -SearchApplication $ssa
The command returns an overview of active and inactive topologies, in this example:
TopologyId : fce8507d-61c6-4498-8038-4fd2d0a62c6e
CreationDate : 1/30/2016 2:52:00 AM
State : Inactive
ComponentCount : 6
TopologyId : b63d48b2-df5c-41be-a7f4-9abaee483611
State : Active
ComponentCount : 12
The previous topology, the default topology in this example, is listed as inactive. The new active topology
from this example will have a component count of twelve.
9. Verify that all components of the new search topology are running correctly. At the Windows PowerShell
command prompt, type the following command:
Get-SPEnterpriseSearchStatus -SearchApplication $ssa -Text
This command should return a list of all the active search components. The state of the active search
components should be displayed as **Active**.

The procedures and the examples in this article assume that SharePoint ServerSharePoint Server and the Search
service application are installed, and that there is an existing search topology and items in the SharePoint Server
search index. If SharePoint Server and the Search service application are newly installed and there are no items in
the SharePoint Server search index, follow the procedures in Change the default search topology in SharePoint
Server.
The procedures in this article apply to the following search components:
Crawl component
Search administration component
For information about procedures to manage the index component, see Manage the index component in
SharePoint Server.
Before you begin

SharePoint Server is installed and a Search service application with a search topology is created. The
Search service application is in a healthy state and is not paused for any reason.
The user account that is performing the procedures in this article is a member of the Farm
Administrators group.
You have planned a target search topology.
SharePoint Server is installed on all the servers that you want to host search components on. The servers
have been added to the farm and you are an administrator on all these servers. You can create new
application servers or define application servers in an existing deployment.
IMPORTANT
The procedures in this article use Microsoft PowerShell. You can run the Microsoft PowerShell commands on any server in
the farm. However, if you are performing multiple search topology procedures you should use the same SharePoint
Management Shell for all Microsoft PowerShell commands so that you can share Microsoft PowerShell object references
between commands.
Start a search service instance on a server

Before you add search components to a new server, you must first start a search service instance on the server.
The search service instance starts all the necessary Windows services that are used by the search service
(OSearch16 and SPSearchHostController).
To start a search service instance
group.
$<host n > = Get-SPEnterpriseSearchServiceInstance -Identity "<Server name>"

Start-SPEnterpriseSearchServiceInstance -Identity $<host n >
Where:
$ <host n> specifies the PowerShell object reference for the search service instance.
<Server name> specifies the server on which you want to add an index component. The input must be a
valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh ; a valid name of a server (for example,
myserver1 ); or an instance of a valid SearchServiceInstance object.
For example:

$hostB = Get-SPEnterpriseSearchServiceInstance -Identity "myserver2"
Start-SPEnterpriseSearchServiceInstance -Identity $hostB
You use the references _($\<host n\>)_ to specify the target server when you add search components.
4. Wait until all the search service instances are running. For each of the search service instances, at the
Microsoft PowerShell command prompt, type the following command until the command returns the status
Online:
Get-SPEnterpriseSearchServiceInstance -Identity $<host n >
For example:
Get-SPEnterpriseSearchServiceInstance -Identity $hostA

TypeName : SharePoint Server Search
Description : Index content and serve search queries
Id : 82ce8815-ecbd-4cf3-a98e-33f20bd86039
Server : SPServer Name=myserver1.example.com
Service : SearchService Name=OSearch16
Role : None
Status : Online
Retrieve the active search topology

To view the active search topology of the Search service application, you have to use Microsoft PowerShell.
To view the active search topology
group.
2. Start a SharePoint Management Shell. If you already have an open SharePoint Management Shell in
which you have created reusable Microsoft PowerShell object references, use the open shell instead.
$active = Get-SPEnterpriseSearchTopology -Active -SearchApplication $ssa
$active
The command returns information about the active topology, for example:
TopologyId : 2d7bb046-1ad4-43a9-9984-754c4551a3ec CreationDate : 1/25/2016 3:06:00 AM State : Active
ComponentCount : 6
Retrieve a list of search components

To view a list of search components in the active search topology with their properties, you have to use Microsoft
PowerShell. One of the search component properties is the search component Id. You will only need the search
component Id to remove a search component.
To view a list of all search components
group.
which you have created reusable SharePoint Management Shell object references, use the open shell
instead.
$active = Get-SPEnterpriseSearchTopology -SearchApplication $ssa -Active
Get-SPEnterpriseSearchComponent -SearchTopology $active
The command returns a list of search components in the active search topology and their properties.
Clone the active search topology

To make any changes to the search topology in a search installation that has items in the search index, you first
have to create a new topology object. You modify this new topology object, a clone of the active topology, by
adding or removing search components. After you have made the changes to the clone topology object, you
make the clone the active topology.
To clone the active topology
group.
$clone = New-SPEnterpriseSearchTopology -SearchApplication $ssa -Clone -SearchTopology $active
The command creates a clone search topology that can be referenced with _$clone_ if you continue to use the
same SharePoint Management Shell to add or remove search components and to activate the search topology.
4. (Optional) If you have to remove search components from the search topology, you have to retrieve the
search component Id. At the Microsoft PowerShell command prompt, type the following command(s):
Get-SPEnterpriseSearchComponent -SearchTopology $clone
The command returns a list of search components in the cloned search topology and their properties, including
the search component Id.
Add a search component

You cannot change the active search topology directly. This procedure assumes that you have created a clone
topology object as described in Clone the active search topology. You can use the following Microsoft PowerShell
cmdlets for each search component:
New -SPEnterpriseSearchAdminComponent
New -SPEnterpriseSearchAnalyticsProcessingComponent
New -SPEnterpriseSearchContentProcessingComponent
New -SPEnterpriseSearchCrawlComponent
New -SPEnterpriseSearchQueryProcessingComponent
NOTE
The procedure to add an index component is different. For more information, see Manage the index component in
SharePoint Server .
To add a search component

group.
New-SPEnterpriseSearch<SearchComponent> -SearchTopology $clone -SearchServiceInstance $<host n >
Where:
<SearchComponent> is the name of the search component type that you are adding.
$clone is the cloned topology that you are changing. See Clone the active search topology.
$<host n> is the PowerShell object reference to the running search service instance on the server that you
want to add the search component to. See Start a search service instance on a server .
For example, the following command adds a content processing component to the clone topology on the server
identified by the search service instance reference $hostA.
New-SPEnterpriseSearchContentProcessingComponent -SearchTopology $clone -SearchServiceInstance $hostA
4. Verify that the new search component was added to the clone topology. At the Microsoft PowerShell
command prompt, type the command:
Get-SPEnterpriseSearchComponent -SearchTopology $clone
Remove a search component

To remove a search component, you have to use Windows PowerShell. You cannot change the active search
topology directly. This procedure assumes that you have created a clone topology object as described in Clone
the active search topology.
NOTE
The procedure to remove an index component is different. For more information, see Manage the index component in
SharePoint Server.
To remove a search component

group.
3. Make sure that the current active topology is healthy and that the search component that you are about to
remove is Active. View the status of the search topology in the Search Administration page in Central
Administration or run the Windows PowerShell cmdlet Get-SPEnterpriseSearchStatus .
Remove-SPEnterpriseSearchComponent -Identity <Search component id> -SearchTopology $clone
Where:
<Search component id> is the Id of the search component that you want to remove. Use the search
component Id from the clone topology. To retrieve the search component Id, see step 4 in Clone the active
search topology.
5. When prompted, confirm that you want to remove the search component.
Move a search component
If you want to move a search component from one server to another, we recommend that you add a new search
component to the search topology before you remove the old search component.
To move a search component
1. Clone the active search topology. See Clone the active search topology.
2. Add a new search component to the server that you eventually want the search component to be hosted
on. See Add a search component.
3. Activate the search topology. This topology will have one superfluous search component. See Activate a
search topology.
4. Make sure that the current active topology is healthy. View the status of the search topology in the Search
Administration page in Central Administration or run the Windows PowerShell cmdlet
Get-SPEnterpriseSearchStatus .
5. Clone the search topology again. See Clone the active search topology.
6. Remove the superfluous search component. See Remove a search component.
7. Activate the search topology again. See Activate a search topology.
Activate a search topology

To activate a search topology, you have to use Windows PowerShell.
To activate a search topology
group.
Set-SPEnterpriseSearchTopology -Identity $clone
Where:
4. Verify that your new topology is active. At the Windows PowerShell command prompt, type the following
command(s):
Get-SPEnterpriseSearchTopology -Active -SearchApplication $ssa
The command returns an overview of active and inactive topologies, for example:
TopologyId : fce8507d-61c6-4498-8038-4fd2d0a62c6e
State : Inactive
ComponentCount : 6
TopologyId : b63d48b2-df5c-41be-a7f4-9abaee483611
State : Active
ComponentCount : 7
You will see that the component count of the active topology reflects the changes that you have made.
Manage the index component in SharePoint Server

The procedures and the examples in this article assume that SharePoint Server and the Search service
application are installed, that there is an existing search topology and that there are items in the SharePoint
Server search index. If SharePoint Server and the Search service application are newly installed and there is no
content in the SharePoint Server search index, follow the procedures outlined in Change the default search
topology in SharePoint Server to scale out the search topology.
The procedures in this article apply to the index component. For information about how to manage the analytics
processing component, the content processing component, the crawl component, the search administration
component and the query processing component, see Manage search components in SharePoint Server.
You use the index component PowerShell cmdlet (New -SPEnterpriseSearchIndexComponent) to manage both
index partitions and index replicas. Each index component in the search topology represents an index replica.
You divide the search index into discrete portions called index partitions. Each index partition is stored as a set
of files on a local disk. To scale out the search index, you add a new index partition.
To achieve fault tolerance for the SharePoint Server search index, you add an index replica of an existing index
partition to the search topology. Each index replica contains the same information.
Before you begin

SharePoint Server is installed and a Search service application with a search topology is created.
The user account that is performing the procedures in this article is a member of the Farm
Administrators group.
You have planned a target search topology and have planned on which servers that you want to host the
index partitions and the index replicas.
SharePoint Server is installed on all the servers that you want to host index components on. You can create
new application servers or define application servers in an existing deployment. The servers are added to
the farm and you are an administrator on all these servers.
Add an index replica to an existing index partition

You add an index replica to the search topology to achieve fault tolerance for an existing index partition. You place
the index replicas on separate failure domains on separate servers. When you add an index replica, you add a
new index component to the search topology and associate it with the index partition that you want to make a
replica of.
IMPORTANT
This procedure uses Microsoft PowerShell. You can run the Microsoft PowerShell commands on any server in the farm.
However, you should use the same SharePoint Management Shell for all Microsoft PowerShell commands in this procedure
so that you can share Microsoft PowerShell object references between commands.
To add an index replica
group.
3. Start a search service instance on the server that you want to create the index replica on and create a
reference to the search service instance Id. At the Microsoft PowerShell command prompt, type the
following command(s):

Where:
$<host n> specifies the PowerShell object reference for the search service instance.
<Server name> specifies the server on which you want to add an index component. The input must
be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh ; a valid name of a server (for
example, myserver1 ); or an instance of a valid SearchServiceInstance object.
For example:

4. Wait until the search service instance is running. At the Microsoft PowerShell command prompt, type the
following command until the command returns the status Online:
5. Clone the active search topology. At the Microsoft PowerShell command prompt, type the following
command(s):
6. Add a new index component and associate it with a partition. At the Windows PowerShell command
prompt, type the following command(s):
New-SPEnterpriseSearchIndexComponent -SearchTopology $clone -SearchServiceInstance <host n > -

IndexPartition <Index partition number>
Where:
$clone is the cloned topology that you are changing.
$<host n> is the PowerShell object reference to the running search service instance on the server
that you want to add the index replica to.
<Index partition number> is the number of the existing index partition that you are creating a
replica of. For example, to create an index replica of index partition 0, choose "0" as the parameter
value.
For example:
New-SPEnterpriseSearchIndexComponent -SearchTopology $clone -SearchServiceInstance $hostA -

IndexPartition 0
7. Activate the clone topology. At the Microsoft PowerShell command prompt, type the following
command(s):
8. Verify that your new topology is active and that the index component representing the new index replica is
added. At the Microsoft PowerShell command prompt, type the following command(s):
Get-SPEnterpriseSearchTopology -Active -SearchApplication $ssa
9. Monitor the distribution of the existing index to the new replica. The added index replica will have the state
Degraded until the distribution is finished. At the Microsoft PowerShell command prompt, type the
following command(s):
Repeat this command until all search components, including the new index component, output the state
Active. For a large search index, this could take several hours.
Add a new index partition

When you add a new index partition, the search index has to be repartitioned. Depending on the size of the
search index, this repartitioning can take several hours to complete.
To add an index partition and repartition the search index, you add a new index component to the search
topology and associate this index component with a new index partition number. Adding an index partition and
repartitioning the search index should be initiated as a separate process and should not be initiated while you are
making other changes to the search topology.
You must add the same number of index replicas to the new index partition as you have for your existing
partitions.
Before you add a new index partition to the search topology and start repartitioning the search index:
Back up the Search service application and the existing search index. See Back up Search service
applications in SharePoint Server.
Make sure that the current active topology is healthy. View the status of the search topology in the Search
Administration page in Central Administration or run the Microsoft PowerShell cmdlet
Get-SPEnterpriseSearchStatus .
Make sure that there is sufficient disk space available on the server where you will be adding the index
partition.
Cau t i on
The Search service application is paused during index repartitioning and cannot crawl or index content. Also,
users will not be able to run queries.
To add an index partition
group.
3. Start a search service instance on all the servers where you want to add an index replica for the new index
partition. You create a PowerShell object reference to the search service instance that is used later in the
procedure. For each server, at the Microsoft PowerShell command prompt, type the following
command(s):

Where:
<host n> specifies the PowerShell object reference for the search service instance.
<Server name> specifies the server on which you want to add an index component. The input must
be a valid GUID, in the form 12345678-90ab-cdef-1234-567890bcdefgh ; a valid name of a server (for
example, myserver1 ); or an instance of a valid SearchServiceInstance object.
For example:
$hostC = Get-SPEnterpriseSearchServiceInstance -Identity "myserver3"

Start-SPEnterpriseSearchServiceInstance -Identity $hostC
$hostD = Get-SPEnterpriseSearchServiceInstance -Identity "myserver4"
Start-SPEnterpriseSearchServiceInstance -Identity $hostD
4. Wait until the search service instances are running. For each server, at the Microsoft PowerShell command
prompt, type the following command until the command returns the status Online:
5. Clone the active search topology. At the Microsoft PowerShell command prompt, type the following
command(s):
The command creates a clone search topology that can be referenced with $clone and returns information
about the clone topology. Make a note of the topology Id of the cloned topology, in case you have to cancel
the repartitioning process.
6. Add a new index partition by adding one or more index components and associate them with the new
index partition. We recommend that you create the same number of index replicas for the new index
partition as you have for the existing partitions. For each new index component, at the Windows
PowerShell command prompt, type the following command(s):
New-SPEnterpriseSearchIndexComponent -SearchTopology $clone -SearchServiceInstance <host n > -

IndexPartition <Index partition number>
Where:
$clone is the cloned topology that you are changing.
$<host n> specifies the PowerShell object reference for the search service instance.
<Index partition number> is the number of the index partition that you are creating. By default, you
have one index partition, which is called index partition 0. If you want to create a new index
partition, enter the IndexPartition parameter value 1, followed by 2, then 3 and so forth.
For example, if you have an existing index partition 0 with index replicas on Host A and Host B, and you
want to add a new index partition with index replicas on Host C and Host D:
New-SPEnterpriseSearchIndexComponent -SearchTopology $clone -SearchServiceInstance $hostC -

IndexPartition 1
New-SPEnterpriseSearchIndexComponent -SearchTopology $clone -SearchServiceInstance $hostD -
IndexPartition 1
7. Verify that the Search service application is running. At the Microsoft PowerShell command prompt, type
the following command(s):
$ssa.IsPaused() -ne 0
If this command returns False, the Search service application is running. Continue with step 9.
If this command returns True, the Search service application is paused. Continue with step 8.
8. If the Search service application is paused, find out why and if you have to wait for any operation to
complete before you can continue with step 9. See Manage a paused Search service application in
SharePoint Server for more information.
9. Start the activation of the clone topology. This will start the activation of the topology that includes the new
index replicas associated with the new index partition. This will start the index repartitioning process.
IMPORTANT
The Search service application is paused during index repartitioning and cannot crawl or index content. Also, users
will not be able to run queries. You will not be able to access the Windows PowerShell console where the activation
command runs.
NOTE
The Search Administration page in Central Administration does not show that the Search service application has
been paused for index repartitioning. However, because all query processing components are suspended when you
pause the Search service application for repartitioning, the Search administration page will show errors for the
query processing components during this process.
At the Windows PowerShell command prompt, type the following command(s):
$ssa.PauseForIndexRepartitioning()
10. Monitor the progress of the index repartitioning process. You can only monitor the progress of the
repartitioning process on the primary index components of the existing topology. The following steps
show you how to find the primary index components.
NOTE
You will not be able to run any commands in the existing SharePoint Management Shell until the topology
activation, including the index repartitioning process, is finished. Run the following commands in a second
SharePoint Management Shell.
Start a second SharePoint Management Shell.

Find the primary index replica for each of the existing index partitions. At the Windows PowerShell
command prompt of the second SharePoint Management Shell, type the following command(s):
The command returns a list of index components and their properties. Make a note of the names of the
primary index component(s). These are the index components that have the property Primary: True.
For example, the output could look like this. In this example, IndexComponent2 is the primary index
component:
Name : IndexComponent1
State : Active
Primary : False
Partition : 0
Host : MyMachine1
Name : Cell:IndexComponent1-SPd32cdffb08a2I.0.0
State : Active
Primary : False
Partition : 0
Name : IndexComponent2
State : Active
Primary : True
Partition : 0
Host : MyMachine2
Name : Cell:IndexComponent2-SPd32cdffb08a2I.1.0
State : Active
Primary : True
Partition : 0
11. For each primary index component, monitor the index repartitioning progress. At the Windows
PowerShell command prompt of the second SharePoint Management Shell, type the following
command(s):
Get-SPEnterpriseSearchStatus -SearchApplication $ssa -Healthreport -Component <Index component name> |

? { ($_.name -match "repart") -or ( $_.name -match "splitting") } | ft -AutoSize Name, Message
Where:
<Index component name> is the name of the primary index component that you want to monitor the
progress of, for instance IndexComponent2.
Monitor the output of the command for each primary index component. The output of the command
contains progress information about the repartitioning of the index.
During the initial phase of the index repartitioning process, the output will look something like this:
Name Message
---- -------
repartition_component_state[SP...] Pending
The index partitions are split during the main phase of the index repartitioning process. During this phase,
the output will look something like this:
Name Message
---- -------
index splitting: current fusion progress[SP...] <Percentage value>
index splitting: splitting state [SP...] Index splitter running fusion, building: <Folder>
repartition_component_state [SP...] Splitting
The percentage value in the output indicates the approximate progress of the repartitioning process.
Repeat this command for all primary index components until the output of the commands no longer
returns any values. That means that the index repartitioning process has completed and that the
repartitioned index will now be replicated and distributed over the servers. This could take several hours.
12. Monitor the progress of the distribution of the index to the new index replicas. To do this, verify that your
new topology is active, and that all search components are healthy. At the Windows PowerShell command
prompt of the second SharePoint Management Shell, type the following command(s):
Get-SPEnterpriseSearchStatus -SearchApplication $ssa | ft -AutoSize Name, State, Details
During the distribution of the index to the new index replicas, the added index replicas will return the state
Degraded. The distribution is finished when all index components return the state Active in the output.
This could take several hours.
NOTE
The query processing components are suspended because you have paused the Search service application for index
repartitioning. In the output, the query processing components will be listed with the state Unknown.
13. In the SharePoint Management Shell that you used to start the topology activation process, verify that the
search topology activation command has completed.
14. (Optional) Restart the SharePoint Search Host Controller service on all the servers that hosted index
components (representing a primary index replica or any other index replica) prior to the repartitioning.
Perform this step to get a correct document count and free up memory after repartitioning the search
index. If you decide not to perform this step, it will take a few days and some indexing iterations for the
memory usage to be gradually reduced and the document count (as returned by PowerShell cmdlets and
in the Search Administration page in Central Administration) to be correct.
NOTE
To avoid query outages, ensure that at least one index component returns the state Running for each index
partition before you restart the SharePoint Search Host Controller service.
IMPORTANT
Do not use the Services on Server page on the SharePoint Server Central Administration Web site to restart this
service.
To restart the SharePoint Search Host Controller, open a command prompt window on each of the
servers that host index components for existing index partitions.
To stop the SharePoint Search Host Controller, type this command: net stop
spsearchhostcontroller
To restart the SharePoint Search Host Controller, type this command: net start
spsearchhostcontroller
15. Resume the Search service application. At the Windows PowerShell command prompt, type the following
command(s):
$ssa.ResumeAfterIndexRepartitioning()
Cancel the repartitioning process

If you have to cancel an ongoing repartitioning process, use the following procedure.
To cancel the repartitioning process
1. Start a new SharePoint Management Shell on the server where you ran the topology activation command.
2. Retrieve the activating topology Id. At the Windows PowerShell command prompt, type the following
command(s):
$activating = Get-SPEnterpriseSearchTopology -Identity <Id of the activating topology> -

SearchApplication $ssa
Where:
<Id of the activating topology> is the identity (GUID ) of the clone topology that you wrote down when
you cloned the search topology.
3. Cancel the topology activation. At the Windows PowerShell command prompt, type the following
command(s):
$activating.CancelTopologyActivation()
Remove an index component

If you have more than one active index replica for an index partition, you can remove an index replica by
performing the procedure Remove a search component in the article Manage search components in
SharePoint Server.
You cannot remove the last index replica of an index partition using this procedure. If you have to remove all
index replicas from the search topology, you must remove and re-create the Search service application and create
a completely new search topology that has the reduced number of index partitions.
Move an index component

If you want to move an index replica from one server to another, we recommend that you add a new index
component to the search topology before you remove the old index component.
To move an index component
1. Add a new index component to the server that you want to move the index replica to. Clone the search
topology, add a new index replica, wait for the index to be replicated to the new index replica and activate
the search topology. See Add an index replica to an existing index partition.
2. Wait until the new index replica is ready to serve queries. View the status of the search topology in the
Search Administration page in Central Administration or run the Windows PowerShell cmdlet
Get-SPEnterpriseSearchStatus . Before you proceed, the index replica that you have added must be Active.
3. Clone the search topology again.

4. Remove the superfluous index replica by removing the index component. See the procedure Remove a
search component in the article Manage search components in SharePoint Server.
5. Activate the search topology again.
This will ensure fault tolerance of the search index while you are moving the index replica.
Manage a paused Search service application in
SharePoint Server

Most operations that require the Search service application to be paused have to complete before the Search
service application automatically resumes.
We'll show you how you can find out if and why the Search service application is paused. There are many reasons
why the Search service application can be paused -- we'll list only the most common situations.
To manage a paused search service application
group.
3. At the Microsoft PowerShell command prompt, type the following command(s) to find out if the Search
service application is paused.
If this command returns False, the Search service application is running.

If this command returns True, the Search service application is paused. Go to step 4 to find out why, and what
action you should take.
4. At the Microsoft PowerShell command prompt, type the following command(s) until you find the reason why
the Search service application is paused.
IF THE COMMAND RETURNS TRUE, THE

SEARCH SERVICE APPLICATION IS PAUSED
COMMAND FOR THIS REASON: ACTION
($ssa.IsPaused() -band 0x01) -ne A change in the number of crawl Wait until the topology change
0 components or crawl databases is in completes.
progress.
($ssa.IsPaused() -band 0x02) -ne A backup or restore procedure is in Wait until the backup or restore
0 progress. completes. After the procedure
completes, run the command
$ssa.ForceResume(0x02) to verify.
For more information, see Restore
Search service applications in
SharePoint Server.
($ssa.IsPaused() -band 0x04) -ne A backup of the Volume Shadow Copy Wait until the backup completes. After
0 Service (VSS) is in progress. the VSS backup completes, run the
command $ssa.ForceResume(0x02)
to verify.
IF THE COMMAND RETURNS TRUE, THE
SEARCH SERVICE APPLICATION IS PAUSED
COMMAND FOR THIS REASON: ACTION
($ssa.IsPaused() -band 0x08) -ne One or more servers in the search Wait until the servers are available
0 topology that host query components again.
are offline.
($ssa.IsPaused() -band 0x20) -ne One or more crawl databases in the Wait until the operation completes.
0 search topology are being rebalanced.
($ssa.IsPaused() -band 0x40) -ne One or more link databases in the Wait until the operation completes.
0 search topology are being rebalanced.
($ssa.IsPaused() -band 0x80) -ne An administrator has manually paused If you know the reason, you can resume
0 the Search service application. the Search service application. Run the
command $ssa.resume() to resume
If you don't know the reason, find out

why someone has manually paused the
($ssa.IsPaused() -band 0x100) -ne The search index is being deleted. Wait until the search index is deleted.
0
($ssa.IsPaused() -band 0x200) -ne The search index is being repartitioned. Wait until the operation completes. For
0 more information, see Manage the
index component in SharePoint Server.
After you've waited until the operation completes, at the Microsoft PowerShell command prompt, type the
following command to make sure that the Search service application is running:
If this command returns False, the Search service application is running.

If this command returns True, the Search service application is paused. Re-run the commands from step 4 to find
out why.
Resume a paused Search service application in SharePoint Server
To resume a paused Search service application, use the following PowerShell.
$ssa = Get-SPEnterpriseSearchServiceApplication -Identity MySSA

$ssa | Resume-SPEnterpriseSearchServiceApplication
View search diagnostics in SharePoint Server

You can access and analyze several query and crawl health reports, logs and usage reports from the Search
service application in the SharePoint ServerCentral Administration to monitor the health of the search system.
Before you begin

Before you begin this operation, review the following information:
The health reports and logs only contain information after a full crawl has completed.
To view the health reports and the crawl log, you have to be an administrator of the Search service
application. Alternatively, an administrator who is a member of the Farm Administrators group can grant
user accounts Read permissions on the Search service application. A user account that has Read
permissions can only view the Search service application status page, the health reports and the crawl log.
Query health reports

SharePoint Server provides the following reports about query performance:
Trend (Query Latency Trend)
For a specified time interval, shows the query latency (in milliseconds) by percentile. For example, five
percent of all queries had lower latency than the latency indicated by the fifth percentile line in the graph.
The graph includes an overlay of query rate during the specified time interval, where query rate is the
number of queries per minute for which the query object model (OM ) returned results.
The graph also includes an overlay of the crawl rate and the partial update rate for analytics.
You can filter this report by:
Start date/time
End date/time
Client type
Result page (search results page), which only shows if verbose logging is enabled.
By default, the graph displays data for all result pages in the Search service application.
Overall (Overall Query Latency)
For a specified time interval, shows the query rate (number of queries per minute) with an overlay of query
latency in milliseconds.
Shows the query latency in each of the following areas:
Object model. This is the time it takes to communicate between the web server and the back-end.
Backend. This is the time it takes to transform the query, perform index look up, process results
(such as removing duplicates), and return results to the object model.
Start date/time
End date/time
Client Type
By default, the graph shows data for all result pages in the Search service application.
Main Flow (Default SharePoint Flow Query Latency)
For a specified time interval, shows the query latency (in milliseconds) in the main flow for query and result
processing. This indicates how fast the system processes a query and returns results to the web server. The
graph shows the query latency for:
Query rule condition matching
Query transformation
Query routing
Result mixing
Layout selection
Query logging
Other
The graph includes an overlay of query rate during the specified time interval.
Start date/time
End date/time
Client Type
Federation (Federation Query Latency)
For a specified time interval, shows the query latency in milliseconds for all result source types.
By default, the graph shows data for all result pages in the Search service application.
Start date/time
End date/time
Client type
Source type (result source type):
Best Bet Provider
Exchange Search Provider
Local People Provider
Local SharePoint Provider
OpenSearch Provider
Personal Favorites Provider
Remote People Provider
SharePoint Search Provider (Local SharePoint Search Flow Query Latency)
For a specified time interval, shows the query latency (in milliseconds) for all queries that are processed by
the local SharePoint search provider. The graph shows the query latency for:
Keyword parsing
Linguistics
Recommendations Security Trimming
Security token construction
Index lookup
Result type processing
Custom security trimming
Summary generation
Other
Start date/time
End date/time
Client type
People Search Provider (People Search Flow Query Latency)
For a specified time interval, shows the query latency (in milliseconds) for all queries that are processed by
the local people search provider. The graph shows the query latency in each of the following areas:
Keyword parsing
Linguistics
People pre-processing
Security token construction
Index lookup
Result type processing
Custom security trimming
Summary generation
Other
Start date/time
End date/time
Client type
Index Engine (Index Engine Query Latency
For a specified time interval, shows the query latency in milliseconds for each index server that you filter
on. By default, the graph shows data for all result pages in the Search service application. You can filter this
report by:
Start date/time
End date/time
Index server (a computer that hosts at least one index partition)
The graph includes an overlay of the index lookup time for the specified time interval in the past. Index
lookup time is the average amount of time during a given minute that it took the index engine to return
results. The index lookup time applies only to queries for which the index engine returned results.
To view query health reports
1. Verify that the user account that is performing this procedure is an administrator of or has Read
permissions to the Search service application.
3. On the Service Applications page, click the Search service application.
4. On the Search Administration page, in the Quick Launch, in the Diagnostics section, click Query Health
Reports.
5. On the Search Service Application: Query Latency Trend page, click the query report that you want to view.
Crawl health reports

SharePoint Server provides the following reports about crawl health:
Crawl Rate
For a specified time interval, shows a graph and a summary of the following:
Number of content items crawled per minute. This includes:
Total content items
Modified items. These are content items that were changed and re-crawled.
Not modified items. These are content items that were not changed and were not crawled.
Security items. These are content items for which the security attributes were changed.
Deleted items. These are content items that were deleted from the content source and which must
also be deleted from the index.
Average number of other crawl actions that were performed per minute. This includes:
Retries (crawl retries)
Errors (crawl errors)
Start date/time
End date/time
Content sources (for example, Local SharePoint sites)
Machine
Crawl Latency
For a specified time, shows a graph of the number of items that form the crawl load, for each of the
following:
In Crawler Queue
Waiting to submit to content processing
Submitted to content processing
Waiting to Commit (SQL )
You can filter this report by machine only.
For a specified time interval, also shows a graph and a summary of the crawl latency; the amount of time in
milliseconds that each content item is in each of the following subsystems in the feeding pipeline:
Crawler
Protocol handler (PH)
Repository
SQL Time
Start date/time
End date/time
Content source (for example, Local SharePoint sites)
Machine
Crawl Queue
For a specified time interval, shows the number of items in the following two crawl queues:
Links to process. This is the number of uncrawled URLs that are queued to be crawled.
Transactions queued. This is the number of crawled URLs that arequeued to be processed in the
crawl pipeline.
You can filter this report by start date/time and end date/time.
Crawl Freshness
For a specified time interval, shows the freshness of the content that was being indexed by the search
system. The last modified time stamp of each document is compared with the time specified in the graph.
You can view the freshness of the content as follows:
Less than 1 month ago
Less than 1 week ago
Less than 1 day ago
Less than 4 hours ago
Content Processing Activity
For a specified time interval, shows the amount of time that was spent in content processing for:
Content sources
Machines
Content processing components
Content processing activity
The graph shows the amount of time that was spent in various content processing activities, such as:
Linguistics processing
Document parsing
Document summary generation
Indexing
Start date/time
End date/time
Content source
Machine
Content processing component name
Processing activity
CPU and Memory Load
For a specified time interval, shows the percentage of CPU used, the memory use in megabytes and the
system overview for these processes:
MSSDmn
MSSearch
NodeRunner
Timer
Machine
Start date/time
End date/time
Continuous Crawl
For a specified time interval, shows the time (in milliseconds) that the processes took with an overlay of
discovery time (in minutes) for:
Time In Links Table
Time In Queue Table
Crawler Time
PH (Protocol Handler) Time
Repository Time
Content Pipeline Time
SQL Time
Content sources
Start date/time
End date/time
To view crawl health reports
4. On the Search Administration page, in the Quick Launch, in the Diagnostics section, click Crawl Health
Reports.
5. On the Search Service Application: Crawl Reports page, click the crawl health report that you want to view.
Crawl log
The crawl log tracks information about the status of crawled content. This log lets you determine whether crawled
content was successfully added to the index, whether it was excluded because of a crawl rule, or whether indexing
failed because of an error. The crawl log also contains information such as the time of the last successful crawl and
whether any crawl rules were applied. You can use the crawl log to diagnose problems with the search experience.
To view the crawl log
1. Verify that the user account that is performing this procedure is an administrator of the Search service
application, or has Read permissions to it.
4. On the Search Administration page, in the Quick Launch, in the Diagnostics section, click Crawl Log.
5. On the Crawl Log - Content Source page, click the view that you want.
Crawl log views
The following table shows the different views that you can select to see the status of crawled content.
Overview of crawl log views
VIEW DESCRIPTION
Content Source Summarizes items crawled per content source. Shows

successes, warnings, errors, top-level errors, and deleted
items. The data in this view represents the current status of
items that are already present in the index per content source.
You can also see the average time that it took to complete a
crawl of a content source for the last crawl, for the last 24
hours, for the last 7 days and for the last 30 days. You can
view the developments of the crawl duration, and see whether
a particular content source is getting smaller or larger in size.
Host Name Summarizes items crawled per host. Shows successes,

warnings, errors, deleted items, top-level errors, and the total
number of crawled items. The data in this view represents the
current status of items that are already present in the index
per host.
Crawl History Summarizes crawl transactions that were completed during a

crawl. There can be multiple crawl transactions per item in a
single crawl, so the number of transactions can be larger than
the total number of items. This view shows data for these
crawls:
Full. Crawls all items in a content source.
Incremental. Crawls items that have changed since the last

full or incremental crawl. This kind of crawl only runs if it is
scheduled.
Delete. If start addresses are removed from a content source,

a delete crawl removes items associated with the deleted start
address from the index before a full or incremental crawl runs.
This kind of crawl cannot be scheduled.
Continuous. Crawls items in a SharePoint content source on a

very frequent interval.
The Search Administration database provides the data for this

view. You can filter the results by content source.
This view also shows the crawl rate and the repository latency.
Error Breakdown Provides summaries of errors per content source or per host
name. The MSSCrawlURLReport table in the crawl database
provides the data for this view. You can filter by content
source or by host.
Note that the filter drop-down box only shows content

sources that contain errors. If there is an error on an item that
does not appear in the index, the error is not listed in this
view.
Databases Lets you view the state of the crawl databases used by this
VIEW DESCRIPTION
URL View Lets you search the crawl logs by content source, URL, or host
name, and view details of all items in the index. The
MSSCrawlURLReport table in the crawl database provides the
data for this view. You can filter the results by setting the
Status, Message, Start Time, and End Time fields.
Note that the URL View only shows the Display URL. If items
have the same Display URL (for example for a folder or views)
but different Access URLs, the same Display URL displays
several times in the URL View. You can query the Crawl
database directly to see which items have the same Display
URL.
The following table shows which additional columns are available in the Content Source, Host Name and Crawl
History views. These columns show information about crawled items.
Overview of additional columns in the Content Source, Host Name and Crawl History views
ITEM DESCRIPTION
Successes Items were successfully crawled and searchable.
Warnings Items might not have been successfully crawled and might
not be searchable.
Errors Items were not successfully crawled and might not be

searchable.
Top Level Errors Errors in top-level documents, including start addresses,

virtual servers, and content databases. Every top-level error is
counted as an error, but not all errors are counted as top-
level errors. Because the Errors column includes the count
from the Top Level Errors column, top-level-errors are not
counted again in the Host Name view.
Deletes Items that were removed from the index and are no longer
searchable.
Not Modified Items were not changed between crawls. This column only
shows in the Crawl History view.
Security Update The security settings of items were crawled because they were
changed. This column only shows in the Crawl History view.
Security Errors The security update of items caused an error. This column only
shows in the Crawl History view.
Usage reports
You can use the usage reports and the search reports provided on the View Usage Reports page to view usage
data that was collected about this site collection.
To view usage reports
4. On the Search Administration page, in the Quick Launch, in the Diagnostics section, click Usage Reports.
5. On the View Usage Reports page, click the usage or search reports view that you want view.
The following table shows the different usage reports and search reports that you can select.
Overview of usage report or search report
USAGE REPORT OR SEARCH REPORT DESCRIPTION
Number of Queries This report shows the number of search queries performed.
Use this report to identify search query volume trends and to
determine times of high and low search activity.
Top Queries by Day This report shows the most popular search queries. Use this
report to understand what types of information visitors are
seeking.
Top Queries by Month This report shows the most popular search queries. Use this
report to understand what types of information visitors are
seeking.
Abandoned Queries by Day This report shows popular search queries that received low
click-through. Use this report to identify search queries that
might create user dissatisfaction and to improve the
discoverability of content. Then, consider using query rules to
improve the query's results.
Abandoned Queries by Month This report shows popular search queries that received low
click-through. Use this report to identify search queries that
might create user dissatisfaction and to improve the
discoverability of content. Then, consider using query rules to
improve the query's results.
No Result Queries by Day This report shows popular search queries that returned no
results. Use this report to identify search queries that might
create user dissatisfaction and to improve the discoverability
of content. Then, consider using query rules to improve the
query's results.
No Result Queries by Month This report shows popular search queries that returned no
results. Use this report to identify search queries that might
create user dissatisfaction and to improve the discoverability
of content. Then, consider using query rules to improve the
query's results.
Query Rule Usage by Day This report shows how often query rules trigger, how many
dictionary terms they use, and how often users click their
promoted results. Use this report to see how useful your
query rules and promoted results are to users.
Query Rule Usage by Month This report shows how often query rules trigger, how many
dictionary terms they use, and how often users click their
promoted results. Use this report to see how useful your
query rules and promoted results are to users.
Enable search alerts in SharePoint Server

Search alerts allow end-users to receive e-mail notification when specified search query results are changed or
updated. Search alerts should be enabled when you want allow end-users to create alerts for search queries.
Search alerts may be configured on the search query page when a search query is completed and results are
displayed. Search alerts are created and configured per-user and are only configurable and viewable by the user
who creates them. Search alerts are enabled by default. Use this procedure to enable or disable search alerts.
Before you begin

Before you begin this operation, have this in place:
A Search service application
A User Profile service application
To enable or disable search alerts
application.
configure search alerts.
4. On the Search Administration page, in the System Status section, locate Search alerts status.
5. The search alerts status displays as Off Enable or On Disable.
6. By default, search alerts are turned On. Click Disable to turn off search alerts or click Enable to turn on
search alerts.
The option is now set. Search alerts are sent only if outgoing e-mail is configured. For more information, see
Configure outgoing email for a SharePoint Server farm. If you enabled search alerts, users can create search alerts
for search queries that they run. To configure search alerts for search queries, users can click the Alert Me link
that is located on the bottom of the Search Results page. The Alert Me link will appear a few minutes after search
alerts are turned on. If search alerts are turned off, this icon does not appear.
Enable query logging in SharePoint Server

SharePoint Server search collects information about user search queries and search results that users select on
their computers. SharePoint Server uses this information to improve the relevance of search results and to
improve query suggestions. Site collection administrators, tenant administrators and administrators of the Search
service application can also create reports based on this information. Query logging is enabled by default. Use this
procedure to enable or disable query logging.
To enable or disable query logging
1. Verify that the user account performing this procedure is an administrator for the Search service
application.
configure query logging.
4. On the Search Administration page, in the System Status section, locate Query logging.
5. The Query logging status displays as Off Enable or On Disable.
6. By default, query logging is turned On. Click Disable to turn off query logging or click Enable to turn on
query logging.
The option is set and no other actions are necessary. User search queries and user selected results will no longer
be logged if you clicked Disable, or will now be logged if you clicked Enable.
Export and import customized search configuration
settings in SharePoint Server

You can export and import customized search configuration settings between site collections and sites. The settings
that you export and import include all customized query rules, result sources, result types, ranking models, and site
search settings. It is also possible to export customized search configuration settings from a Search service
application and import the settings to site collections and sites, but you cannot import customized search
configuration settings to a Search service application. You can't export the default search configuration settings,
and you can't import customized search configurations from SharePoint Server to SharePoint Online, or the other
way around.
You can use the following methods to export or import customized search configuration settings:
To export or import customized search configuration settings at a site collection or site, use the Site
Settings page or CSOM.
To export customized search configuration settings from a Search service application, use CSOM.
If you want to transfer all Master Page Gallery files, use the Design Manager. If you want to transfer a whole
site, use Save site as template. If you want to export or import customized search settings programmatically, see
Exporting and importing search configuration settings in SharePoint on MSDN.
This article describes how to use the Site Settings page to export and import customized search configuration
settings for site collections, and sites.
Before you begin

Before you begin this operation, review the information in Overview of customized search configuration settings
that can be exported and imported and ensure:
That the search configuration file and the target for your import do not have settings with the same name,
except for managed properties.
That the source of your export does not include managed properties or aliases that contain the invalid
characters listed in Invalid characters causing the import to fail.
That managed property names and aliases are unique within the combination of the search configuration
file and the search configuration settings on the target site and its parent site collection.
NOTE
Keyboard shortcuts
Touch
Export customized search configuration settings from a site collection

To export customized search configuration settings from a site collection
1. Verify that the user account that is performing this procedure has Full control permission level at the site
collection.
2. In the site collection, on the Settings menu, click Site settings.
3. On the Site Settings page, in the Site Collection Administration section click Search Configuration
Export.
4. In the dialog box, click Save.
Export customized search configuration settings from a site

To export customized search configuration settings from a site
1. Verify that the user account that is performing this procedure has Full control permission level at the site.
2. On the site, on the Settings menu, click Site settings.
3. On the Site Settings page, in the Search section click Configuration Export.
4. In the dialog box, click Save.
Import customized search configuration settings to a site collection

To import customized search configuration settings to a site collection
1. Verify that the user account that is performing this procedure has Full control permission level at the site
collection.
2. In the site collection, in the Settings menu, click Site settings.
3. On the Site Settings page, in the Site Collection Administration section, click Search Configuration
Import.
4. On the Import Search Configuration page, either type the name and location of the search configuration
file to import, or click Browse and select the file name and location of the search configuration file to
import, and then click Import.
5. On the Search Config List page, verify that:
The search configuration file that you imported is in the list, and that its status is Imported Successfully.
If the file has not imported successfully, the Notes column provides details about what happened. The
Notes column also provides details, in some cases, when the file has imported successfully. For example if
the file contains a managed property that has the same name as a managed property on the target, the
Notes column indicates that this managed property already exists on the target.
The Scope column shows that the settings you imported are at the correct level, that is, at the level you
meant to import the files to. For example, if you imported your settings at the site collection level instead of
at the site level, you would see this information in the Scope column. The Scope column shows at which
level the search configuration settings were enabled. The levels are site collection (SPSite) or site (SPWeb).
Import customized search configuration settings to a site

To import customized search configuration settings to a site
1. Verify that the user account that is performing this procedure has Full control permission level at the site.
2. On the site, on the Settings menu, click Site settings.
3. On the Site Settings page, in the Search section click Configuration Import.
4. On the Import Search Configuration page, either type the name and location of the search configuration
file to import, or click Browse and select the file name and location of the search configuration file to
import, and then click Import.
5. On the Search Config List page, verify that:
The search configuration file you imported is in the list, and that its status is Imported Successfully.
If the file has not imported successfully, the Notes column provides details about what happened. The
Notes column also provides details, in some cases, when the file has imported successfully. For example if
the file contains a managed property that has the same name as a managed property on the target, the
Notes column indicates that this managed property already exists on the target.
The Scope column shows that the settings you imported are at the correct level, that is, at the level you
meant to import the files to. For example, if you imported your settings at the site collection level instead of
at the site level, you would see this information in the Scope column. The Scope column shows at which
level the search configuration settings were enabled. The levels are site collection (SPSite) or site (SPWeb).
Overview of customized search configuration settings that can be

exported and imported
When you export customized search configuration settings, SharePoint Server creates a search configuration file in
XML format. This search configuration file includes all exportable customized search configuration settings at the
Search service application, site collection, or site level from where you start the export. A search configuration file
for a site collection does not contain search configuration settings from the individual sites within the site
collection.
When you import a search configuration file, SharePoint Server creates and enables each customized search
configuration setting in the site collection or site from where you start the import.
This table shows the settings that you can export and import. For each setting, the table indicates any dependencies
on other customized search configuration settings. If the customized search configuration settings depend on a
customized search configuration setting at a different level, for example, if a site query rule depends on a result
source at site collection level, you must export and import settings at all of the relevant levels.
DEPENDENCY ON OTHER CUSTOMIZED SEARCH CONFIGURATION
CUSTOMIZED SEARCH CONFIGURATION SETTING SETTINGS
Query rules. These include result blocks, promoted results, and Result sources, result types, search schema, ranking model
user segments.
Result sources Search schema
Result types Search schema, result sources, display templates
Search schema None
Ranking model Search schema
Conditions that may cause the import to fail

If the search configuration file and the target for your import have settings with the same name, the import
of the search configuration file fails when it encounters this setting. Exceptions:
If you reimport a search configuration file, the settings that have the same name in the search
configuration file and on the target do not cause the import to fail.
Managed properties with the same name do not cause an import to fail if the individual managed
property settings are the same on the property in the search configuration file and on the target
property.
Managed properties with the same name do not cause an import to fail if the aliases and mappings
to crawled properties are different on the managed property in the search configuration file and on
the target managed property. The import adds the aliases and mappings on the managed property in
the search configuration file to the aliases and mappings on the target managed property.
If the search configuration file contains managed property names or aliases that contain invalid characters,
the import fails when it encounters that managed property name or alias.
The managed property names and aliases of a search schema must be unique for a site and its parent site
collection. This means:
If your search configuration file has a managed property that has the same name as an alias for a
managed property on your target site or the parent site collection of your target site, then the import
fails.
If your search configuration file has a managed property with an alias that has the same name as a
managed property on your target site or the parent site collection of your target site, then the import
fails.
NOTE
Customized search settings that SharePoint Server created and enabled before the import failed remain enabled.
If the import fails, remove the condition that caused the failure and reimport the search configuration file. For
example, if the Notes column states that there is already a query rule with the same name as the query rule that
you are trying to import, then you should remove that query rule either from the target or from the import file, and
then reimport the file.
Invalid characters causing the import to fail
If managed properties or aliases contain any of the listed characters, the import of the customized search schema
that contains these properties will fail.
CHARACTER NAME
space
: colon
; semicolon
, comma
( opening parenthesis
) closing parenthesis
[ opening bracket
] closing bracket
{ opening brace
} closing brace
% percent
$ dollar sign
_ underscore
+ plus sign
! exclamation point
* asterisk
= equal sign
& ampersand
? question mark
@ at sign
# number sign
\ backslash
~ tilde
< opening angle bracket
> closing angle bracket

CHARACTER NAME
| pipe
` grave accent
^ caret
' escape sequence
" escape sequence

Search center scenarios in SharePoint Server

Applies to:
The "how to" articles in this section provide step-by-step information on how you can set up and customize a
Search Center in SharePoint Server.
In this section
Set up a Search Center
Create and import a thesaurus
Create and import query suggestions
Changing the ranking of search results
Set up a Search Center in SharePoint Server

A Search Center is a portal where you can search for content on your organization's intranet. This series of articles
will present details of how to set up and manage a Search Center in SharePoint Server. But before we learn about
the details, we'll give you some background information and some planning tips and tricks.
What's a Search Center and how do I plan it?

A Search Center resembles an Internet search page like Bing: it has a starting page where you can enter queries. It
has search result pages where you can drill into and refine search results, or you can run a new query.
On the internet, you want search to be easy and fast, and to give you relevant results, and you should expect the
same when you're trying to find information on your company's intranet.
You'll easily get fast and relevant results with the standard Search Center in SharePoint Server. And if you also
have a good understanding of the content on your intranet and know how people will be searching it, you can
make your Search Center really shine.
Throughout this series, we'll use examples from a Search Center that we in the content publishing team at
Microsoft use to search for articles and other media that we have published on MSDN, TechNet and Office.com.
Because we know the content, and because we know what we want to find and how we want to search for it, we've
been able to set up the Search Center so that it suits our needs well.
This is what an empty Search Center looks like before you start to work on it:
And this is what our content publishing Search Center looks like after we set it up to meet our needs. Here, we
have searched for "relevance," just as an example.
You can see that we get results that show articles that we've published, and you can also see that we have added
refiners that are meaningful to us, such as Writer and Editor . We also added several search pages, or search
verticals, such as Art and Interop . In this series, we'll show you how you can add search verticals and refiners to
your Search Center, but before we start the practicalities, here are some considerations to help you plan your
Search Center.
What kind of content and information is located on your intranet?
When you think about your intranet, is there content that people probably want to search differently or separate
from other content?
As an example, in our content publishing Search Center we have a separate search vertical to search through the
illustrations, or "Art" files, that we use in our articles. So when we want to see whether we already have any
illustrations of a server farm, we type "server farm" as our query in the search box. On the search results page, we
can click "Art" to view only the art results for that query.
Is the content tagged with good and consistent metadata?
Setting up your Search Center is much easier if content is well organized and consistently tagged with good
metadata. It's often well worth investing time in content quality before you crawl it so that people can more easily
find what they're looking for in the Search Center.
In our content publishing Search Center, we work with SharePoint lists. Each content item that we publish, such as
an article or an art file, has its own entry on the list. We've made sure that all the entries are consistently tagged
with metadata that is important to us, for example to help us determine which product variants an article applies
to. For our articles we also have rules around the titles and short descriptions we use. We're capturing these
metadata in site columns and site column values, and we have set up our Search Center so that we can easily use
these values to refine on search results and quickly find exactly the information we're looking for.
Who works with the intranet content?
Some content can benefit from being searched separately or differently than other content. Likewise, it is useful to
think about the categories of people who search and how their interests differ. For example, if you work in Human
Resources and you search for "vacation," you're probably looking for content related to the company's rules and
regulations around holidays. If you don't work in HR and you search for "vacation," you probably want to find a
SharePoint site where you can log when you're away or use a tool to request a day off.
You can create search verticals in the Search Center to display subsets of the search results that are of particular
interest for certain groups of people, such as teams or departments. Or, you can create separate Search Centers. It
all depends on the people who use the intranet in your organization: think about what they are searching for and
how you can make it easier for them to find it.
Store most of the content in SharePoint
It's an advantage if the content in your intranet is stored in SharePoint Server, because the SharePoint content
source differs from all other types of content sources for search.
Site collection administrators have many configuration and management options for content that is stored in
SharePoint Server, such as adding new managed properties and editing existing ones. If you add a new managed
property or make certain changes to it, you have to recrawl the content. This is where it helps to have content in
SharePoint: you can reindex individual SharePoint lists and libraries without having to crawl all SharePoint content.
Also, the SharePoint content source is the only source that you can crawl continuously. When the content changes,
a continuous crawl will detect the change and you don't have to wait until the next incremental or full crawl
finishes.
A few words about how search works

Before you can show any search results in a Search Center, you have to crawl the content. After crawling, the
content and related metadata are processed and stored as managed properties in the search index. This is what it
looks like under the surface:
1. Our content is stored in SharePoint lists and libraries. We use site columns to store metadata about each
item.
2. When we crawl the content and the metadata, the information is processed and added to the search index.
3. In the search index, managed properties represent the content and metadata that we crawled.
4. The queries that we enter in our Search Center are sent to the search index, where the system tries to find
matching results.
5. Any matching results are displayed in the Search Result Web Part in the Search Center.
In this series, we'll show you how you can set up your own Search Center by using examples from our own
experience with the Search Center for content publishers. This series includes the following articles:
How to create a Search Center Site Collection and enable crawling of your content in SharePoint Server
How to configure the Search Results Web Part to use a new result source in SharePoint Server
Plan to use refiners on a search results page in SharePoint Server
How to add refiners to your search results page in SharePoint Server
How to add a custom search vertical to your search results page in SharePoint Server
TIP
A related series, How to change the way search results are displayed in SharePoint Server, enhances the example Search
Center developed in this series. In this related series, we show you how you can change the appearance of your search
results.
How to create a Search Center Site Collection and
enable crawling of your content in SharePoint Server

In this article, you'll learn:
How to create a Search Center Site Collection
How to start a full crawl in Central Administration
How to enable continuous crawls in Central Administration
How to set the continuous crawl interval
How to reindex a list
How to create a Search Center Site Collection

To create a Search Center Site Collection, go to Central Administration --> Create site collections, and then
enter details for the site collection. Here's what you have to enter:
1. Enter a title for the website.
2. Enter the website's URL.
3. Select 2013 for the experience version.
4. From the Enterprise tab, select Enterprise Search Center.
5. In the field Primary Site Collection Administration, enter the site administrator's user name.
Now that you have your Search Center Site Collection, you can move on to crawling content.
How to start a full crawl in Central Administration

Before you can start a full crawl in Central Administration, you have to specify the content source that you want to
crawl. When you run a full crawl, all content in the content source is crawled even if that content has already been
added to the search index.
In a scenario where you only have SharePoint content, you can select to crawl the Local SharePoint sites content
source.
1. Go to Central Administration --> Manage service applications --> Search Service Application -->
Content Sources.
2. On the Manage Content Sources page, pause on the Local SharePoint sites content source, and select
Start Full Crawl from the menu.
The status of the crawl is shown in the Status column.

3. Refresh this page until the value in the Status column is Idle. That means that the full crawl has finished.
4. Optionally, you can verify that your items are added to the search index by clicking Crawl Log.
In this scenario, 157,297 items appear in the search index.
How to enable continuous crawls in Central Administration

By default, content is automatically crawled every fourth hour. But, when changes are made to your content, you
probably want it to be crawled as soon as possible so that users can find it on the Search Center. Nobody wants to
start a full crawl manually every time that a change is made to their content, as this is neither efficient nor practical.
So, to avoid this overhead, you can enable a continuous crawl of the content source that contains your content.
Continuous crawls start automatically at 15-minute intervals. Any changes that were made to your content since
the previous crawl are picked up by the crawler and added to the search index.
To enable continuous crawls:
1. Go to Central Administration --> Manage service applications --> Search Service Applications -->
Content Sources.
2. On the Managed Content Sources page, click the content source for which you want to enable
continuous crawl.
In this scenario, the content source is Local SharePoint sites.
3. Select Enable Continuous Crawls.
How to set the continuous crawl interval

The default interval for continuous crawls is 15 minutes. But, you can set shorter intervals by using Microsoft
PowerShell. The following code example sets the continuous crawl interval to 1 minute.
$ssa.SetProperty("ContinuousCrawlInterval", 1)
So, by enabling continuous crawls, your search index is automatically updated with the latest changes. But, there
are some types of changes where continuous crawls are insufficient to update the search index, for example, if you
enable managed properties as refiners (we'll show you how to do this in a later article). For these changes to be
updated in the search index, you have two options:
Do a full crawl.
Do something called reindexing .
The reason there are two options is because people who work with content (let's call them content managers) are
not likely to have Search service application administration level rights. That is, they don't have access to Central
Administration where they can start a full crawl. But, content managers are likely to have Site Owner rights, and
Site Owners can do reindexing.
How to reindex a list
Here are the steps to mark a list or library for reindexing:
1. On your list or library, click the LIST or LIBRARY tab --> List Settings or Library Settings -->
Advanced Settings.
2. On the Advanced Settings page, click Reindex List or Reindex Document Library.
The list will be reindexed during the next scheduled crawl.

So, overall, content managers can be happy because their content is added to the search index at short intervals,
and Search service application administrators can be happy because they are not bothered by content managers
constantly asking them to start a crawl.
Next article in this series
How to configure the Search Results Web Part to use
a new result source in SharePoint Server

In the previous article in this series, How to create a Search Center Site Collection and enable crawling of your
content in SharePoint Server, we explained how you can create a Search Center Site Collection and enable
crawling of your content. In this article, you'll learn:
How to turn off versioning for the Pages library
Why you should consider creating a result source for your Search Center
How to create a result source
How to configure the Search Results Web Part to use a new result source
How to turn off versioning for the Pages library

If you don't want to check pages in and out when you configure the Search Results Web Part, you can turn off
versioning for the Pages library.
Here are the steps to turn off versioning for the Pages library:
1. Go to Site settings --> Site contents.
2. On the Site Contents page, click the Pages library.
3. In the Pages library, click the LIBRARY tab and then Library Settings.
4. On the Settings page, click Versioning settings.
5. On the Versioning Settings page, in the Content Approval section, for Require content approval for
submitted items, select No.
6. In the Document Version History section, for Create a version each time you edit a file in this
document library, select No versioning.
7. In the Require Check Out section, for Require documents to be checked out before they can be
edited, select No.
Why you should consider creating a result source for your Search
Center
A result source specifies where your search results can come from. For example, in our scenario, we did not want
search results to come from all sites within the SharePoint farm, but only from one specific site within the farm.
The default result source in a Search Center returns search results from the complete SharePoint Server farm. If
you want search results from the complete SharePoint Server farm, you can go to the next article in this series,
Plan to use refiners on a search results page in SharePoint Server. But, if you want search results from only a
subset within your SharePoint Server farm (in our scenario, one specific site), you should create a result source.
How to create a result source

Depending on your permission level, you create a result source on three levels:
PERMISSION LEVEL WHERE THE RESULT SOURCE WILL BE ADDED
Search service application administrator To all site collections within the farm
Site collection administrator To all sites in a site collection
Site collection owner To a single site
To save space, we'll only show you how to create a result source as a Site collection administrator.
1. Go to Site settings --> Search Result Sources.
3. On the Add Result Source page, enter a Name. Select values for Protocol and Type, and then click
Launch Query Builder. This opens a dialog box.
In our scenario, we named the result source Articles , and kept the default values for Protocol and Type.
4. In the Build Your Query dialog box, define the result source.
Remember, in our scenario we only wanted search results to come from a particular site within the farm.
Therefore, in the Query text field we added the following:
{searchTerms?} (contentclass:sts_listitem) path:http://<path>
![Search Results From a Particular Site](../media/OTCSP_QueryTextResultSource.png)
Before we move on, let's analyze what we entered:
{searchTerms?} In our result source, we wanted to include the words that users type inside the query box
when then search for something. Obviously we have no way to know what users will type. Therefore, we
added the {searchTerms?} query variable. By the way, you can tell it is a query variable because it is
enclosed in braces (for more information, see Query variables in SharePoint Server). When a user enters a
query, this query variable is replaced by the words the user has typed in the query box. The question mark
at the end of the variable means that if no words are entered in the query box, the variable should be
ignored.
(contentclass:sts_listitem) This means that only list items will be included in the result source.
path:http://<path> This is the path of the site from where we wanted search results to come from.
5. Test that the result source is working correctly by clicking the TEST tab, and then Show more.
6. In the {searchTerms} field, enter Query words to simulate a query entered by a user, and then click Test
query.
In our scenario, we entered search configuration .
Notice that 52 results were returned. (I will tell you why this is kind of cool in the next section…).
7. Click OK to close the dialog box, and then Save.
So now that we have a result source for the Search Center, we can move on to configuring the Search Results Web
Part to use the new result source.
How to configure the Search Results Web Part to use a new result
source
By default, the Search Results Web Part is used on the search results page. To configure the Search Result Web
Part, you have to navigate to the search results page. Here's what you have to do:
1. On your Search Center home page (the default URL to this page is <site>/Pages/default.aspx ), enter a
query in the search box, and press Enter.
When you press Enter, you'll be taken to the to the search results page (the default URL to this page is
<site>/Pages/results.aspx ).
In our scenario, 1,051 search results were returned.
Remember, by default you'll get search results from the complete SharePoint Server farm. The following
steps explain how to change this so only search results from your newly-created result source are returned:
2. On the search results page, click the Settings menu --> Edit Page.
3. In the Search Results Web Part, click the Web Part Menu, and then click Edit Web Part.
4. In the Web Part tool pane, click Change query. This opens a dialog box.
5. In the dialog box, from the Select a query menu, select your newly-created result source.
In our scenario, we selected the Articles (Site Collection) result source.
6. Click OK in the dialog box, click OK in the Web Part Tool pane, and then save the page. To verify that the
configuration is working, enter a query.
52 results were returned, which is the same number of items that were returned when we tested the query
in the result source configuration. Pretty cool, huh?
Now that the Search Results Web Part displays the search results we are interested in, the next task is to make it
easier for users to filter these search results by using refiners.
Plan to use refiners on a search results page in
SharePoint Server

How refiners helped plan a trip to Japan
What to look for when you identify refiners
About making a managed property refinable
About refinable managed properties
How refiners helped plan a trip to Japan

Although the term "refiners" is new to you, there is a good chance you've already used them. For example, if you
have ever bought a book online, most likely you used refiners to find the right book.
Suppose, for example, that you went online to your favorite bookstore to find a travel guide about Japan. You
typed "Japan" into the search field, and as expected, pages of search results popped up. Trawling through page
after page of results does not seem like much fun. Luckily, the site designers provided a way to narrow the search
results. On the left side of the page is a "Categories" list that contain entries such as "Cooking," "Geography,"
"History," "Travel," and so on. You click "Travel," and in an instant, the search results show only travel books that
contains the word "Japan."
But, turns out that there are many travel books out there on Japan. Therefore, you need to trim the results even
more. You were looking for a paperback version. So, still focusing on the lists at the left side of the page, you spot
a category called "Format" that contain terms like "Hardcover," "PDF," "Audio," "Digital," and "Paperback." So you
click "Paperback" and got what you've been looking for: results for travel books about Japan in paperback!
Unfortunately, the number of search results was still too large. Therefore, you continue to use the various lists on
the left side of the page until you've drilled right down to five hopeful candidates, one of which makes it over the
finish line and goes straight into your shopping cart.
Now, here's the techy part: when you were clicking "Travel" and "Paperback" you were, in fact, using refiners. In
SharePoint terms, a refiner is a managed property that is made refinable. Refiner values are the values of a
refinable managed property. So in the case of your online shopping trip, "Categories" and "Format" are refiners.
"Travel" and "Paperback" are refiner values.
The article From site column to managed property - What's up with that? explains how site columns are
"transformed" into managed properties during a crawl. For example, in our Search Center scenario, we have a site
column named "Internal Writer." For each list item, this site column contains the name of the writer of an article
(remember, each list item represents an article). To help the user quickly narrow search results to articles that are
written by a particular writer, exactly like you narrowed search results when shopping for a travel book on Japan,
you had to make the managed property that represents the "Internal Writer" site column refinable. There is, of
course, a bit more to it than that, and all the steps will be explained in later articles.
What to look for when you identify refiners

This is an easy one: to identify refiners, look for information that users will want to use to narrow their search
results.
In our Search Center scenario, we wanted to use the following refiners:
Manager
Internal Writer
Editor
Content Type
Requested Publish Date
About making a managed property refinable

The first thing that you have to do when you configure refiners is to make the managed properties that you want
to use, refinable. Depending on your permission level, you can do this from two places:
TO REFINER-ENABLE A MANAGED PROPERTY FROM REQUIRES PERMISSION LEVEL
Central Administration Search service application administrator
Site Collection Administration Site collection administrator
There's a reason why you can do this from two places. If you are working with content (let's say you're a content
manager), you're unlikely to have Search service application administration level rights, that is, you won't have
access to Central Administration. But, you are very likely to have Site collection administrator permissions.
The previous article of this series ( How to configure the Search Results Web Part to use a new result source)
explained how content managers can easily add content to the search index without having to pester Search
service application administrators. So now that everyone's happy, we don't want to jeopardize this happiness by
making content managers dependent on a Search service application administrator to enable refiners.
This article only describes the procedure as it can be performed by a Site collection administrator (content
manager). For information on how Search service application administrators can make a managed property
refinable, see Enable automatically created managed properties as refiners in SharePoint Central Administration.
About refinable managed properties

The previous section stated "The first thing that you must do when you configure refiners is to make the managed
properties that you want to use, refinable." Well, turns out that Site collection administrators (content managers)
can't do this because they don't have the required permission level. But, they do have the permission level to map
a crawled property to a refinable managed property.
Confused? Let's take a closer look.
Search service application administrators, who have access to Central Administration, can configure many things
directly on a managed property. For example, the following screen shot shows how they can change the property
named InternalWriterOWSUSER to be refinable by selecting either Yes - active, or Yes - latent from the
Refinable menu.
If we look at the same property from the perspective of a Site collection administrator, who is configuring the
property on the site collection level, not only is the property name grayed out, but the Refinable choice menu is
locked (it might not be easy to see on the screen shot, but the field is locked).
Luckily, there are many "empty" managed properties that are enabled as refiners by default. In this context,
"empty" means that a crawled property is not mapped to it. This means that Site collection administrators can
map a crawled property to one of these refiner-enabled managed properties without having to depend on a
Search service application administrator.
The table below provides an overview of the managed properties that are enabled as refiners by default.
MANAGED PROPERTY NAME DATA TYPE FOR MAPPING DISPLAY FORMAT FOR REFINER VALUES
RefinableDate00 - RefinableDate19 Values contain dates Intervals
RefinableDecimal00 - Values contain numbers with maximum Intervals

RefinableDecimal09 three decimals
RefinableDouble00 - Values contain numbers with more Intervals

RefinableDouble09 than three decimals
RefinableInt00 - RefinableInt49 Values are whole numbers Intervals
RefinableString00 - RefinableString99 Values are strings. This includes values List

that use the data type Text, Person or
Group, Managed Metadata, Choice,
and Yes/No
In our Search Center scenario, we had already identified the refiners that we wanted to use. For each of these
refiners, we defined which refinable managed property we would use:
REFINER TO USE REFINABLE MANAGED PROPERTY
Manager RefinableString01
Internal Writer RefinableString02
Editor RefinableString03
Content Type RefinableString04
Requested Publish Date RefinableDate01
So now that we have a plan for which refiners to use, the next task is to do the actual refiner configuration.
How to add refiners to your search results page in SharePoint Server
How to add refiners to your search results page in
SharePoint Server

The previous article in this series, Plan to use refiners on a search results page in SharePoint Server, showed how
to identify and plan to use refiners on your site. In this article, you'll learn:
How to map a crawled property to a refinable managed property
How to initiate a reindexing of a list or library
How to configure the Refinement Web Part to use custom refiners
How to add counts to refiner values
How to map a crawled property to a refinable managed property

In our Search Center scenario, we knew we wanted to use the following refinable managed properties:
REFINER TO USE REFINABLE MANAGED PROPERTY
Manager RefinableString01
Internal Writer RefinableString02
Editor RefinableString03
Content Type RefinableString04
Requested Publish Date RefinableDate01
The procedure for mapping a crawled property to a refinable managed property is the same for all refiners. The
following example procedure explains how we mapped the crawled property that represents Internal Writer to the
RefinableString01 refinable managed property.
1. On your Search Center, on the Site Settings page, select Search Schema.
2. In the Managed property field, type the name of the refinable managed property to which you want to
map a crawled property, and then click the arrow button.
In our scenario, we typed RefinableString01 .
3. From the Property Name field, select Edit/Map Property.
4. On the Edit Managed Property page, click Add a Mapping.
5. In the Crawled property selection dialog box, use the Search for crawled property name field to
search for the crawled property that you want to map to this refinable managed property.
In our scenario, we knew we wanted to use the site column called Internal Writer . Crawled properties don't
contain spaces. Therefore, we entered InternalWriter .
Two crawled properties were found: ows_q_USER_Internal_Writer and ows_Internal_Writer .
If you have questions here, your confusion is understandable. This part is somewhat tricky. There are
actually two crawled properties, which might seem strange, considering that we have only one Internal
Writer site column. So which crawled property should we choose to map to the refinable managed
property?
Let's take a closer look at what's going on. The difference between the two crawled properties is the prefix.
One has an ows_q_USER_ prefix, and the other has ows_ .
IMPORTANT
When mapping a crawled property to a refinable managed property, select the crawled property with the ows_
prefix.
If you want more information about the naming convention for crawled and managed properties, see From
site column to managed property - What's up with that?.
6. Select the crawled property with the ows_ prefix, and then click OK.
In our scenario, we selected ows_Internal_Writer .
On the Edit Managed Property page, notice that the crawled property is added to the Mappings to
crawled property field.
7. In the Alias field, enter a name for the refiner.

In our scenario, we entered InternalWriter .
It's important to understand that the alias that you enter here is not the refiner name that will be shown on
your search results page. This alias is meant to make your life a bit easier when you're configuring refiners
in the Refinement Web Part (see procedure below ). Remember, you can't change the name of the
refinable managed property. Therefore, when you do the configuration, you'll have to deal with many
refinable managed properties that have similar names, RefinableString01 , RefinableString02 and so on So,
the alias is a good reminder of which value that you mapped to the property.
8. To finish the mapping, click OK.
The following screen shots show the final result after repeating the steps from the procedure above for the
remaining four refiners.
How to initiate a reindexing of a list or library

When you've mapped all the refinable managed properties that you want to use, you have to do a reindexing of
your list or library. For information on how to do that, see How to create a Search Center Site Collection and
enable crawling of your content in SharePoint Server.
How to configure the Refinement Web Part to use custom refiners

By default, the Refinement Web Part is included on the search results page. In the previous blog post I showed
you how to configure the Search Results Web Part to use a new result source. The two refiners Author and
Modified date were also displayed.
To display custom refiners, here's what you should do:
2. In the Refinement Web Part, click the Web Part Menu, and then click Edit Web Part.
3. In the Web Part tool pane, click Choose Refiners.
4. In the Selected refiners section, select the refiners that you don't want to display on your search results
page, and then click Remove.
In our scenario, we removed all the default refiners.
5. In the Available refiners section, scroll down and select a refinable managed property.
In our scenario, we selected RefinableString1. This is the refinable managed property that is mapped to the
crawled property ows_Internal_Writer . Notice that sample values are shown (a good sign that we're on the
right path), together with the alias InternalWriter .
6. Click Add.
This moves the RefinableString01 property over to the Selected refiners section. When a refiner is moved
over to the Selected refiners section, additional configuration options are shown. They will be explained in
steps 10 and 11.
7. Repeat steps 5 and 6 to add all the refiners you want to use on your search results page.
In our scenario, we added the five refinable managed properties that we configured in the previous section.
8. To preview the refiners, click Preview Refiners.
9. To change the display order of refiners, select the refiner you want to move, and then click the Move up or
Move down button.
In our scenario, we selected RefinableString04 (notice the Alias name), and selected Move up until it was
the first property in the Selected refiners section.
10. To enable users to select multiple refiner values, from the Display template menu, select Multi-value
Refinement Item.
We clicked Preview refiners again, and verified that the ContentType refiner (RefinableString04) was
displayed first, and that it had check boxes that would enable users to select multiple refiner values.
We repeated this step for the refiners RefinableString01 , RefinableString02 , and RefinableString03 .
The RefinableDate01 refiner represents Requested publish date . By default, the refiner values are shown in
a list, which makes it difficult for users to see the date range.
To display the refiner values in a more user-friendly way, in the Refinement configuration dialog box,
from the Display template menu, we selected Slider with bar graph. In the Dates section, we selected
Last day, week, month, six months and year.
When we now previewed our refiners, the values for the Requested Publish Date refiner ( RefinableDate01 )
were perfectly displayed as a graph.
But, there was more thing that we needed to improve: the refiner display names. RefinableString01 ,
RefinableString02 , and so on do not make much sense to users.
11. To change the refiner display name, in the Display name field, enter the name that you want to be
displayed for each refiner.
In our scenario, for the RefinableString04 refiner, we entered Content Type .
Repeat this step for all your refinable managed properties.
12. To save the configurations, click OK in the Refinement configuration dialog box, and then OK in the Web
Part tool pane.
13. Save the page.
In our scenario, the five refiners were now correctly displayed on the search results page.
But, there was one small detail that would make the refiners even better. Right now users couldn't see numeric
details for the refiner values. For example, we could see names of writers that had written articles that had to do
with search configuration . However, we couldn't see how many articles they had written.
To see this information, we needed to add counts to the refiner values.
How to add counts to refiner values

To add counts to refiner values, you'll have to edit a display template. When you work with display templates, you'll
make life a lot easier for yourself if you map your network drive. By doing this, you'll be able to work with display
templates from Windows Explorer. Stage 6: Upload and apply a new master page to a publishing site in
SharePoint Server explains how to map your network drive.
1. In your mapped network drive, go to Display Templates --> Filters.
2. To add counts to refiners where it's only possible to select one refiner value at a time, open the HTML file
Filter_Default. To add counts to refiners where it's possible to select multiple refiner values, open the
HTML file Filter_MultiValue.
3. Change the value for ShowCounts to true.
4. Save the file.

To verify that refiner counts are displayed, enter a query in your search center.
In our scenario, we again entered search configuration . We could now see that the writer "Bella Engen" was
the writer of five articles on the subject that had something to do with search configuration. Nice!
How to add a custom search vertical to your search results page in SharePoint Server
How to add a custom search vertical to your search
results page in SharePoint Server

In the previous article in this series, How to add refiners to your search results page in SharePoint Server, we
showed you how to add and configure refiners for your classic search results page. In this article you'll learn:
Using a search vertical in an everyday situation
About search verticals in SharePoint Server
Result sources - why setting limits is a good thing
How to create a custom search vertical
What you can do after you have successfully set up a Search Center
Using a search vertical in an everyday situation

You may not have heard the term "search vertical" before, but it's likely you have used them several times. Let's
take a closer look at what we mean by the term "search vertical."
Suppose you enjoy skiing, so you often search for ski-related content. When you enter the word "ski" in a search
engine, you get many search results.
You are delighted to see there is much information out there about skiing, but in this case, you are just looking for
great ski pictures. This is where search verticals can be used.
On the same search results page, you click IMAGES, and in an instant your screen is filled with images of people
in colorful clothing, racing down white slopes while bathing in sunshine from a clear blue sky. Wow!
When you click IMAGES, you are using a search vertical. Bing has five search verticals: WEB, Images, VIDEOS
Maps, and NEWS.
A search vertical filters search results so only a certain type of search results are displayed. When we clicked the
IMAGES search vertical, the search results were filtered so only images were displayed.
About search verticals in SharePoint Server

In SharePoint Server, search verticals are displayed in the Search Navigation Web Part. There are four default
search verticals: Everything, People, Conversations, and Videos.
When users click one of these search verticals, it will in fact move to a new page. For example, the default search
results page, the Everything search vertical, uses the results.aspx page.
When a user clicks on the People search vertical, they navigate to the peopleresults.aspx page.
The following are the default pages that are used for the four search verticals:
SEARCH VERTICAL USE THIS PAGE
Everything results
People peopleresults
Conversations conversationresults
Videos videoresults
To view these pages, from the Site settings menu, select Site contents --> Pages.
The default vertical pages all use these Web Parts:

1. Refinement Web Part
2. Search Box Web Part
3. Search Navigation Web Part
4. Search Results Web Part
The difference between these pages is how the Search Results Web Part is configured. To be specific: the Web
Parts are configured to use different result sources .
Result sources - why setting limits is a good thing

As explained in an earlier article, a result source specifies the source from which your search results can come. For
example, suppose that your search index is the cube as shown in the following diagram, where you have four
result sources:
Result source 1: search results can come from the complete cube.
Result source 2: search results can come only from the Bs.
Result source 3: search results can come only from the Cs.
Result source 4: search results can come only from the Ds.
So, by limiting from where search results can come from, you can make it easier for your users to find what they're
looking for.
In our internal search center scenario, all search results are list items that represent a type of media file, for
example an article, an image or a video. We wanted to create three custom search verticals for three specific types
of media files:
Art: list items that represent images
Video: list items that represent videos
Interop: list items that represent interoperable articles (interoperable articles are a specific type of article we
produce)
But, before we could begin to create these search verticals, we had to create one result source for each custom
search vertical. We showed you how to create a result source in How to create a result source.
This is how we defined the Art result source .
Remember, {searchTerms?}(contentclass:sts_listitem) path:http://<path> was the query text of the Article result
source that we created earlier. To this, we added AND ContentType:Art
In our lists, we use the site column Content Type to specify the different media files. For example, all images have
the value Art for Content Type .
So, by adding AND ContentType:Art to the query text, only list items that have the value Art for Content Type will
be returned in search results.
Here are the three new result sources we created.
Now that we had three new result sources, we could move on to creating the custom search verticals.
How to create a custom search vertical

When you create a custom search vertical, the first thing that you must do is to create a page the search vertical
will use. Here are the steps to create a new page:
1. From the Site Settings menu, select Site contents.
2. Select Pages.
3. In the Pages library, select the FILES tab --> New Document --> Page.
4. On the Create Page page, enter a Title and a URL Name.

In our scenario, we entered Art and art .
5. Click Create.
Your new page is displayed in your Pages library.
Now that you have a page for your custom search vertical, you can begin to create the actual search
vertical. Here's what you should do:
6. On the Site Settings page, click Search Settings.
7. On the Search Settings page, in the Configure Search Navigation section, click Add Link.
8. In the Navigation Link dialog box, in the Title field, enter the search vertical title. This text will appear as
the "tab" name on your search results page.
In our scenario, we entered Art .
9. In the URL field, select Browse and select a page for your search vertical.
In our scenario, we selected the art page we just created.
10. Click OK to close the Navigation Link dialog Box.

11. On the Search Settings page, in the Configure Search Navigation section, select the search verticals
that you don't want to display, and then click Delete.
In our scenario, we deleted the People, Conversations, and Videos verticals so that we were only left with
the Everything and the Art search vertical.
12. Click OK to save all changes.

13. In your Search Center, enter a query. On your search results page, your newly created search vertical is
displayed.
On our search results page, the Art vertical was displayed.
14. On your search results page, click on your newly created search vertical, and verify that the URL is the same
as you specified in step 4.
In our scenario, we clicked Art , and verified that the URL was <site>/articles/Pages/art.aspx . We also
noticed that 13 search results were displayed.
15. On your new search vertical page, select to edit the page, and then to edit the Search Results Web Part.
16. In the Web Part tool page, click Change query. This opens a dialog box.
17. In the Build Your Query dialog box, from the Select a query menu, select the result source that you
created for this search vertical (what we did in the previous section).
In our scenario, we selected Art result source (Site Collection) .
18. Click OK and save the page.

On your new search vertical page, enter a query to verify that the correct search results are displayed.
In our scenario, we entered united airlines again, and noticed that only 11 search results were displayed.
Remember, before we changed the result source in the Search Result Web Part, 13 results were displayed.
So our new vertical was working. Nice!
In our scenario, we added two more search verticals, Video and Interop . And with that, we had completed
the Search Center set up.
What you can do after you have successfully set up a Search Center
When you have successfully set up a Search Center, the first thing that you should do is congratulate yourself on a
job well done! Nice job!
But, the job usually doesn't end here. To make the Search Center even more user-friendly, you can change the way
search results are displayed, for example to display information that is specific to your company or business. You
can read about how to do that in series How to change the way search results are displayed in SharePoint Server.

SharePoint Server and SharePoint Online include many default search features that help users find what they're
looking for. But you might want your search results to look a certain way, for example, display information that's
specific to your company or business.
This series will explain how to customize the way search results are displayed in the classic search experience. To
help explain these display concepts, we'll use examples from an internal list of Microsoft publications, a frequently-
used tool among Microsoft content publishing professionals.
As you know, Microsoft publishes thousands of articles across TechNet, MSDN and Office.com. To help in the
publishing process, we use several SharePoint lists. Each item in a list represents an article or a media file. To
quickly find information about a list item, we've set up a Search Center that searches across all of the lists.
This series will show how to change the way search results are displayed from this…
to this:
In this series, we'll cover:
Understanding how search results are displayed in SharePoint Server
Understanding how item display templates and hit highlighting work in SharePoint Server
How to create a new result type in SharePoint Server
How to display values from custom managed properties in search results - option 1 in SharePoint Server
How to display values from custom managed properties in the hover panel in SharePoint Server
How to add a custom action to the hover panel in SharePoint Server
How to change the text that is displayed in the Search Box Web Part in SharePoint Server
How to change the order in which search results are displayed in SharePoint Server
How search works in a few words

In case you're not familiar with how search works, here's a high level representation that might be useful for this
series.
1. Content is stored in lists and libraries. Site columns are used to store values, or in other words information,
about each item in a list or library.
2. When lists and libraries are crawled, site columns and the site column values are added to the search index.
3. In the search index, site columns are "transformed" into managed properties. Site column values are
"transformed" into managed property values.
4. On a search page, a user enters a query in a Search Box Web Part. The query is sent to the search index.
5. Search results are sent from the search index to a search results page, and displayed in a Search Results
Web Part. The Search Results Web Part uses display templates that specify which managed property values
should be displayed.
Here's how to understand this high level representation in the context of Microsoft's internal Search Center.
1. A Microsoft writer creates a list item for an article she'll be writing. Site columns, such as Title , Content
Summary , and Technical Subject , are used to store values, or in other words, information, about the article.
2. The list is marked for continuous crawl. This means the list will be crawled at a set interval, for example,
every minute.
You can see the crawl schedule in List Settings --> Catalog Setting.
3. From Site Settings --> Search Schema you can search for managed properties.
In this scenario, there's a managed property named ContentSummaryOWSMTXT , and another one named
owstaxIdTechnicalSubject . They represent the site columns Content Summary and Technical Subject . For
more information about the "transformation" of site columns into managed properties, see From site
column to managed property - What's up with that?.
4. On a search page, a user enters a query, for example customize search results .
5. On a search results page, search results are displayed in a Search Results Web Part. The Web Part uses
display templates that specify that the values from the managed properties ContentSummaryOWSMTXT
and owstaxIdTechnicalSubject should be displayed in the search results (the display templates also specify
many other things, but for now, let's just concentrate on the values of these two managed properties). The
second search result is the list item created in step 1. We can see that the values from the managed
properties ContentSummaryOWSMTXT and owstaxIdTechnicalSubject are displayed in the search result.
You can also see details such as a small icon next to each search result on the page. These icons represent the site
to which the article is published, such as Office.com and TechNet. The search result also contains the words
"Technical Subject" in front of the value search . Later in this series, you'll learn how to add the icons and the
words. But first, let's explore more details about how search results are displayed.
Understanding how search results are displayed in SharePoint Server
See also
Concepts
Understanding how classic search results are
displayed in SharePoint Server

How search results are displayed by default
About controlling how search results are displayed
About result types
About the connections between a result type and display templates
About display templates that are used by all result types
About display template settings in the Search Results Web Part
How classic search results are displayed by default

When you search for something in a Search Center, your results are displayed differently. For example, in the
following screen shot, notice how the icons for Word, PDF, and Excel are displayed for each of the search results.
By hovering over the first search result, more information about the result is displayed.
By hovering over the fourth result, the information that is displayed differs from what you saw when you hovered
over the first result.
What's going on here, and what's making the search results display so differently? That is the subject of this
article.
About controlling how classic search results are displayed

Search results are displayed in a Search Results Web Part. The following screen shot shows how SharePoint
uses two display templates to control how information about search results is displayed:
1. The item display template controls how the information in the body of the Search Results Web Part is
displayed.
2. The hover panel display template controls how the information in the hover panel is displayed.
There are 90 default search display templates available. This might seem like a lot, and the reasons there are so
many will be explained later. For now, to see all the default search display templates, go to Site settings -->
Master pages and page layouts. In the Master Page Gallery, click Display Templates --> Search.
In this folder, there is an HTML file and a JavaScript file for each display template.
To view or edit a display template, use the HTML file. SharePoint automatically transforms the HTML file into an
associated JavaScript file when you upload it. Because the two files are associated, any changes that you make to
the HTML file will automatically update the associated JavaScript file.
Details about how display templates work will be provided later in this series. For now, let's move on to result
types.
About result types for classic search

If a user can see information about search results directly on the search results page, this will save them the
trouble of having to click and open each item to see what it's about. If you look back at How search results are
displayed by default, you can easily see that the first two results are PowerPoint presentations, and the third result
is a Word document.
To display search results differently, search results have to be sorted into different result types. A result type
distinguishes one search result from another. For example, if a search result is found in a Microsoft Word
document, that search result belongs to the Microsoft Word result type. If a search result is found in a PDF file,
that search result belongs to the PDF result type.
There are 31 default result types. To see them, go to Site Settings --> Result Types.
For an overview of the default result types, see Result types and display templates that are used to display search
results in SharePoint Server. You don't have to worry about how default search results are specified. It happens
"inside" in SharePoint Server.
It is not possible to edit any of the default result types. But, you can copy them, and add additional configurations.
This will be explained later in this series, but first, it's important to understand how result types and display
templates are connected.
About the connections between a result type and display templates

for classic search
The mechanics of these connections are not very straight forward and easy to understand, but let's take a look in
a step-by-step manner.
1. Each result type contains a reference to an item display template, for example, Item_PowerPoint .
2. Each item display template contains a reference to a hover panel display template, for example,
Item_PowerPoint_HoverPanel .
Let's start with the first connection. To see the connection between a result type and an item display
template, go to Site Settings --> Result Types. Select to view a result type, for example Microsoft
PowerPoint.
On the Result Type page, in the Display template URL section, there's a URL that points to a file that is
named Item_PowerPoint.js.
This URL is a reference to an item display template. This means that all search results that belong to the
Microsoft PowerPoint result type will be displayed by using the Item_PowerPoint.js display template.
If you look in the Master Page Gallery, you'll see the Item_PowerPoint.js file and the associated
Item_PowerPoint.html file.
Now for the second connection: to see the connection between an item display template and a hover panel
display template, open Item_PowerPoint.html. You'll see a reference to a hover panel display template, in
this case, Item_PowerPoint_HoverPanel.js.
In the Master Page Gallery, you'll find the Item_PowerPoint_HoverPanel.js file and the associated
Item_PowerPoint_HoverPanel.html file.
So now you know why there are so many search display templates. It's because four display templates are
connected to each result type.
For an overview of the connection between the default result types, item display templates, and hover
panel display templates, see Result types and display templates that are used to display search results in
SharePoint Server.
That was straight forward, however, we're not completely through yet. In addition to the display templates
that are connected to a result type, there are display templates that are used by all result types.
About display templates that are used by all result types for classic
search
To recap:
1. Each result type contains a reference to an item display template.
2. Each item display template contains a reference to a hover panel display template.
and then we have to add:
3. Each item display template contains a reference to a common item display template.
4. Each hover panel display template contains references to three common hover panel display templates.
These common display templates are located in the same Master Page Gallery folder as the display
templates that are specific to individual result types.
Each item display template points to the common item display template. The following screen shot shows
how the item display template that was used for the Microsoft Excel result type points to the common
display template Item_CommonItem_Body .
Each hover panel display template points to three common hover panel display templates. The following
screen shot shows how the hover display template that is used for the Microsoft Excel result type points
to the three common hover panel display templates.
If all these references are a bit confusing, don't worry. Upcoming articles in this series will use examples
that will make it easier to understand. At this point, it's important to know how result types are used to
categorize different types of search results, and how result types are connected to different display
templates.
About display template settings in the Search Results Web Part

Now for the easiest part of the puzzle: how does the Search Results Web Part know how to display search
results based on the different result types?
On the search results page, click to edit the Search Results Web Part. In the Web Part Tool Pane, expand
Display Templates.
You'll see that the radio button Use result types to display items is selected by default. This means that search
results will be displayed based on the result type that they belong to. That's it!
So now you know about the mechanics of how search results are displayed. The next article in this series, we'll
goes into detail about the item display template, and also explains the magic of hit highlighting.
Understanding how item display templates and hit highlighting work in SharePoint Server
Understanding how item display templates and hit
highlighting work in the classic search experience in
SharePoint Server

How to map your network drive
Why it's important to know about managed property names
About important elements in the item display template
About hit highlighting
How hit highlighting works - it is magic!
How to map your network drive

When working with display templates, you'll make life a lot easier for yourself if you map your network drive. By
doing this, you'll be able to work with display templates from Windows Explorer. For instructions, see How to map
your network drive.
Why it's important to know about managed property names

The How search works in a few words section of the introductory topic in this series explained how site columns
and site column values are "transformed" into managed properties and managed property values during a crawl.
It is important that you learn to find the name of the managed property that represents a site column, because to
add new information to your search results, you'll have to add the managed property name to an item display
template. If you are uncertain how managed properties are named, see From site column to managed property -
What's up with that?.
Confusing? Well, don't despair. We'll show you the steps of how to find and add a managed property name to an
item display template later in this series.
About important elements in the item display template

The article Understanding how search results are displayed in SharePoint Server explained that SharePoint Server
includes many item display templates. Although these display templates are not 100% identical, they all contain
certain elements that control how search results are displayed.
Let's dive in and open an item display template, for example: Item_Excel.
NOTE
Because we have mapped a network drive, we can open the file in our favorite HTML editor, for example, Notepad++.
About the <title> tag
The top of the display template has a <title> tag. The text in this tag is what will be shown when you do
configurations in the SharePoint UI, for example, when you configure a result type.
The following screen shot shows how the text from the <title> tag in the item display template, Excel Item, is
shown in the configuration of the Microsoft Excel result type.
About the ManagedPropertyMapping element

After the <title> tag, there's a set of elements in a <mso:CustomDocumentProperties> tag, the most
important of which is <mso:ManagedPropertyMapping>.
The ManagedPropertyMapping element contains the managed properties that can be used to display the
search results. The following syntax is used to store these properties in the item display template:
'<Display template reference name>':<Managed property name>'
The following screen shot shows the default ManagedPropertyMapping element for the Excel Item display
template.
Notice that the display template reference name is the same as the managed property name, for example
'Title':'Title' or 'FileType':'FileType' . Even though this might seem a bit confusing at first, having identical
names will make it easier to maintain the file.
By default, the managed properties that are included in this element vary slightly for the different item display
templates. But, there are two managed properties that are included in all display templates:
HitHighlightedProperties and HitHilightedSummary . We'll explore these two properties in the "How hit
highlighting works - it is magic!" section of this topic.
About the <body> tag
Inside the <body> tag, there is a <div> tag with an ID. By default, the ID for this <div> tag matches the name of
the file. In our case, this is Item_Excel.
Any HTML or code that the display template should use to display search results is included inside this <div> tag.
In this <div> tag there are one or more blocks that begin with . JavaScript code is used
inside these blocks, and HTML outside the blocks. You can also use these blocks to control the HTML with
conditional statements. We'll show you how you can do this in a later article.
About the hover panel display template variable
We have to consider one variable that's used inside this block: var hoverUrl. In Understanding how search results
are displayed in SharePoint Server, we covered how each item display template contains a reference to a hover
panel display template. The variable var hoverUrl contains this reference.
The following screen shot shows how var hoverUrl points to the Item_Excel_HoverPanel hover panel display
template.
About the icon that shows in search results
I also want to mention the value ctx.CurrentItem.csr_Icon. This value points to the icon that should be displayed
next to each search result, for example the Excel icon.
The following screen shot shows how the value ctx.CurrentItem.csr_Icon points to an icon.
Later in this series, we'll look at how you can change this value so that it points to a custom icon.
About the reference to the common item display template
Toward the end of the <div>, a very important line of code is included: #=ctx.RenderBody (ctx )=#. In
Understanding how search results are displayed in SharePoint Server, we looked at how this is a reference to the
item display template that's used by all result types.
The following screen shot shows how #=ctx.RenderBody (ctx )=# is used in the Item_Excel display template.
About hit highlighting
Even if you have never heard of hit highlighting before, you've seen the feature in action, even though you might
not have given it much thought.
The hit highlighting feature takes the words a user has entered in a search box and displays them in bold in the
search results. That way, users can easily scan search results to see the context in which their query words are
found. For example, the following screen shot shows that "result type" was entered in the search box. In the search
results, "result" and "type" are displayed in bold.
How hit highlighting works - it is magic!

By default, hit highlighting is enabled for certain managed properties. To see these managed properties, on a
search results page, edit the Search Results Web Part. In the Web Part Tool Pane expand the Display Templates
section. The properties that are enabled for hit highlighting are listed in the Hit-highlighted properties (JSON )
section.
There is a bit more to it than that, but for now it's important that you know where these managed properties are
listed.
Let's go back to our "result type" search and take a closer look at the first search result, which. was returned
because the values in the Title and Project/File Name columns contained the words we were looking for.
As was previously explained in the "About the ManagedPropertyMapping element" section of this topic, the
ManagedPropertyMapping element in the item display template contains the managed properties that can be
used to display search results. Based on this, you can understand why "About configuring result types " is
displayed. It is because "About configuring result types" is the value of Title in the list item, and Title is one of the
managed properties found in the ManagedPropertyMapping element in the display template. The words "result
type" are displayed in bold (hit highlighted) because Title is one of the hit highlighted listed in the Search Results
Web Part.
But why is "CSH_Configure_ result_types… "displayed in the search results? In the list item we can see that this is
the value for Project/File Name, but the managed property for that site column is not included in the
ManagedPropertyMapping element in display template. Neither is it listed as one of the hit highlighted
properties in the Search Results Web Part. So why is this value displayed?
About the "magical summary" property
If you guessed hit highlighting, you are correct. In addition to the default properties that you saw in the Hit-
highlighted properties (JSON ) section of the Search Results Web Part, there is a property that contains a
summary for each item. This is almost like a magical property, because it stores a summary of each item in the
search index. This summary is created under the SharePoint hood, so you don't have to worry about that. What's
important is that when I searched for "result type," a match was found in both the Title and this "magical
summary" property.
If you are now thinking, hang on! I understand that the value for Title is displayed because Title is one of the
managed properties found in the in the ManagedPropertyMapping element display template. But I don't see
any "magical summary" property in the ManagedPropertyMapping element of the display template. So how
can the value be displayed?
Well, that is where the two properties HitHighlightedProperties and HitHilightedSummary are useful. The diagram
below does not represent how SharePoint actually handles these properties. However you can think about it in the
following way:
1. The managed properties that are listed in the Hit-highlighted properties (JSON ) section of the Search
Results Web Part and the "magical summary" property are passed to the HitHighlightedProperties
property.
2. All values of the HitHighlightedProperties property are passed to the HitHighlightedSummary property.
3. A truncated version of the values in HitHighlightedSummary is displayed in the Search Results Web Part.
If you look closely at the search results, you'll notice that many search results are displayed with three dots at the
end.
These dots indicate that these are values from the HitHighlightedSummary property.
If you only want to display a minimum amount of information for each search result, you can rely on the hit
highlighting magic and probably be OK with the default way search results are displayed. But, if you want custom
information to be displayed for each search result, you'll have to do some customization.
In the next article you'll learn the first step in customizing search results: creating a new result type.
How to create a new result type for classic search in
SharePoint Server

About the Search Center example in this series
How to copy a default item display template
How to create a result type
About the Search Center example in this series

To help explain how we can customize the appearance of the displayed results, we'll use examples from a tool that
is used daily among content publishers: an internal list of Microsoft publications.
As you know, Microsoft publishes thousands of articles across TechNet, MSDN, and Office.com. To help in the
publishing process, we use several SharePoint lists. Each item in a list represents an article or a media file. To make
it easy to find information about a particular list item, we created a Search Center that searches across these lists.
In our first version of the Search Center, all the search results were displayed identically. This was because by
default, all list items belonged to the same SharePoint List Item result type. We wanted to change this so that just
by glancing at the search results, we could differentiate between an article published on TechNet and an article
published on MSDN. We also wanted to add important information about each search result that would be visible
without having to select and open it.
Before we did anything in SharePoint Server, we sat down for a planning session. The first task was to decide how
we wanted to categorize our search results. We came up with the following categories:
CATEGORY DEFINITION
TechNet content Articles that are published on the TechNet platform
MSDN content Articles that are published on the MSDN platform
Office.com content Articles that are published on the Office.com platform
Images content Images that are used in publications
Video content Videos that are used in publications
Download content Downloadable content
After we had defined the categories, we needed to distinguish the categories from one another. Items in our list
contain a site column named Distribution Channel . This site column contains the value of the platform to which an
article is published, for example TechNet Library .
We decided that we would use values from the Distribution Channel site column to distinguish the categories from
one another.
With these decisions in hand, we set out to create new result types for each category. The procedure for creating a
new result type is identical for all categories. So, to save space, we'll only look at how TechNet content result type
was created.
How to copy a default item display template

Before you create a new result type, you should create a new item display template that your new result type will
use. To avoid having to create a new item display template from scratch, you can copy an existing one. Try to copy
an item display template that is as close as possible to the type of content that you have. Here's what you should
do:
1. Copy a default item display template.
In our scenario, we wanted to customize search results for SharePoint list items. From the reference table in
About result types we can determined that the default item display template that is used by the SharePoint
List Item result type is the file that is named Item_Default . Because we have already How to map your
network drive, we could easily copy the Item_Default file in Windows Explorer.
By refreshing Windows Explorer, we saw that SharePoint Server had automatically created an associated
JavaScript file.
2. Rename your newly created item display template.

In our scenario, we renamed it TechNet content . Again, we refreshed Windows Explorer to verify that the
JavaScript file was updated accordingly.
3. Open the new display template and change the <title> tag. Remember, the text in this tag is what will be
shown when you do configurations in the SharePoint Server UI.
In our scenario, we changed the
4. Save the new item display template.
Now that we have created a new item display template, we could move on to creating a new result type.
How to create a result type

Depending on your permission level, you create a result type on two levels:
PERMISSION LEVEL WHERE THE RESULT TYPE WILL BE ADDED
Site collection administrator To all sites in a site collection
To save space, we'll only look at how to create a result type as a Site collection administrator.
1. Go to Site settings --> Search Result Types.
Instead of creating a new result type from scratch, we can make life a bit easier by copying an existing result
type and changing it to fit our new result type. If we do this, we must be sure to copy a result type that
closely resembles the new result type we want to create.
2. On the Manage Result Types page, from the result type menu field, select Copy.
In our scenario, we wanted to customize search results for SharePoint list items. Therefore, we copied the
SharePoint List Item result type.
3. On the Add Result Type page, here are the steps to follow:
In the Give it a name field, enter a name for the new result type.
In our scenario, we entered TechNet content .
From the Which source should results match menu, select the result source that we have used to
configure the query in our Search Result Web Part.
In the What types of content should match? You can skip this rule to match all content menu, all the
default result type are listed.
In our scenario, we chose Select a value.
Click Show more conditions.
This opens a menu where we can specify the result type based on managed property values.
In our scenario, all list items contain a site column called Distribution Channel . As we saw at the beginning,
this site column contains the publication platform value, for example TechNet Library . We used values from
this site column to specify which list items should belong to our new result type.
From the Which custom properties should match menu, we selected DistributionChannelOWSCHCS .
DistributionChannelOWSCHCS is the managed property that represents the Distribution Channel site
column. In the fields below, we entered all the values that should specify the new TechNet content result
type.
From the What should these results look like menu, select the display template that should be used by
this result type.
In our scenario, we selected the newly-created TechNet content display template.
Click Save.
The newly-created result type is now listed on the Managed Result Types page.
In our scenario, we could see that the TechNet content result type was created.
So now that we have a new result type, the next task is to change the display template that is associated
with this result type. There is more than one way to do this. Therefore in the next two articles of this series,
we'll explain two different options.
How to display values from custom managed
properties in classic search results - option 1 in
SharePoint Server

How to display a custom icon
How to find a managed property name
How to change an item display template to show values from custom managed properties - option 1
About click tracking and automatically improved relevancy
How to display a custom icon

In Understanding how search results are displayed in SharePoint Server we explained how the icons Word, PDF,
and Excel are displayed for classic search results. In our Search Center scenario, we wanted to add the following
custom icon next to all search results that belong to the newly created TechNet content result type:
TN
To display a custom icon for classic search results, here's what you should do:
1. Add the custom icon to a SharePoint Server library.
In our Search Center scenario, we added the custom icon to the Images library.
2. Open the item display template that is referenced from the result type for which you want to display a
custom icon.
In our Search Center scenario, we also removed the if statement: if (ctx.CurrentItem.IsContainer ) .
3. On a search page, enter a query that will trigger the new result type.
4. In our Search Center scenario, we entered "result type." Search results that are TechNet publications now
have a custom icon next to them. Great!
So users of our Search Center could now easily distinguish the search results that were published on TechNet.
But, we also wanted to add information from custom site columns so that users could see important information
about each search result without having to click it.
In Understanding how search results are displayed in SharePoint Server we explained that site columns are
"transformed" into managed properties during crawl. We also explained that only managed properties that are
listed in an item display template can be displayed in search results. So, to display custom information in your
search results, you must have to add managed properties to an item display template. Hence, the next thing that
you should do is find the managed property name that corresponds to the custom site column that you want to
use.
How to find a managed property name
Before you start to search for a managed property name, it's important that you know a bit about the naming
convention for managed properties. For more information about this, see About the naming convention for
automatically created crawled and managed properties.
Depending on your permission level, you can search for managed properties from three places:
PERMISSION LEVEL SEARCH FROM THIS LOCATION
Search service application administrator Central Administration --> Managed Service Application -->
Search Service Application --> Search Schema
Site collection administrator Site Settings --> Search Schema (in the Site Collection
Administration section)
Site collection owner Site Settings --> Schema (in the Search section)
Here's what you should do:

1. Go to Site settings --> Search Schema.
2. On the Managed Properties page, in the Managed property field, type the name of the site column that
you want to find the managed property name of. Remember that managed property names don't contain
spaces. Therefore, if your site column name contains a space, leave it out.
In our Search Center scenario, we wanted to find the managed property name for the site column Content
Summary . We entered ContentSummary in the Managed property field, and clicked the green arrow
icon.
One search result was returned: ContentSummaryOWSMTXT .
Because the Content Summary site column is of type Multiple lines of text , we knew this was the
managed property name we wanted to use.
3. Repeat the steps of this procedure to find the names of all of the managed properties that you want to
display in your search results.
Now that you have found the names of the managed properties that you want to show in your search results, the
next step is to change the item display template.
How to change an item display template to show values from custom

managed properties - option 1
In Understanding how search results are displayed in SharePoint Server we mentioned that there are several
ways to change an item display template to show values from custom managed properties. The option explained
in this section is very simple. We'll cover the second option in the next article of this series. It doesn't include any
if statements, and hit highlighting is not applied.
Here's what you should do:
1. Open the item display template that belongs to the result type for which you want to customize search
results.
In our Search Center scenario, this was TechNet content .
2. In the item display template, in the ManagedPropertyMapping tag, use the following syntax to add the
custom managed properties that you want to display:
'<Current item property name>':<Managed property name>'

In our Search Center scenario, we wanted the values from the managed properties ContentSummaryOWSMTXT
and owstaxIdTechnicalSubject to be displayed in the search result. To make the file easier to maintain, we named
the current item properties the same as the managed properties.
![Add MPs](../media/OTCSP_AddMPs.png)
3. Inside the second <div> tag in the <body>, use the following syntax to add code that will display the value of
the custom managed property:
_#= ctx.CurrentItem.<Current item property name> =#
In our Search Center scenario, we added the following to the item display template:
<div>_#= ctx.CurrentItem. ContentSummaryOWSMTXT =#_</div>

<div>_#= ctx.CurrentItem. owstaxIdTechnicalSubject =#></div>
![Display Two New MPs](../media/OTCSP_DisplayTwoNewMPs.png)
4. Save the item display template.
NOTE
You don't have to do this step if you are using SharePoint Online. Go to Site settings --> Search Result Types.
Notice that a Property Sync alert is displayed.
This alert is displayed because we added managed properties to an item display template (what we did in
step 2). To update the result types with the newly added managed properties, click Update.
IMPORTANT
If you don't do this update, the newly added managed properties won't display in your search results.
After we made this change, when users entered a query in our Search Center, both the value of
ContentSummaryOWSMTXT and the value for owstaxIdTechnicalSubject were displayed in the search
results.
Even though two custom properties were now displayed in the search results, the result wasn't completely
right. For example, we wanted to display the two custom properties between the title and the link, and not
below the link as was currently the case.
To better understand why the search results were displayed the way that they were, let's take a closer look at the
customized item display template:
1. points to the location of my custom icon. This variable is used by the

ctx.CurrentItem.csr_Icon
Item_CommonItem_Body display template.
2. _#=ctx.RenderBody(ctx)=#_calls the Item_CommonItem_Body display template. (Remember
Understanding how item display templates and hit highlighting work in SharePoint Server. The
Item_CommonItem_Body display template displays the custom icon, title, and the link to the item.)
3. _#= ctx.CurrentItem.ContentSummaryOWSMTXT =#_ and _#= ctx.CurrentItem.owstaxIdTechnicalSubject =#_
display the values of the two managed properties, ContentSummaryOWSMTXT and
owstaxIdTechnicalSubject .
To display the custom properties between the title and the link, you could take the Item_CommonItem_Body
display template out of play by deleting the reference _#=ctx.RenderBody(ctx)=#_ from your custom display
template. You could then add the properties in the order that you want them to display, for example as follows:
The search result would then look like this:
By working a bit more on the styling, you could have a good enough result. But, by deleting the reference to
_#=ctx.RenderBody(ctx)=#_ ,the Item_CommonItem_Body display template is no longer used to display results.
The Item_CommonItem_Body display template contains some functionality that will automatically improve the
relevancy of your classic search results. So, before you delete the _#=ctx.RenderBody(ctx)=#_ reference, you
should consider whether automatically improved relevancy is something that the users of your search site would
benefit from.
About click tracking and automatically improved relevancy

The Item_CommonItem_Body display template contains an onlick method that tracks the click behavior of users.
This tracking influences the relevancy of classic search results. For example, a search result that is often clicked by
users will automatically be displayed higher up in the search results.
IMPORTANT
If you want your classic search results to receive automatically improved relevancy based on the click behavior of users, do
not delete the reference to _#=ctx.RenderBody(ctx)=#_ from the item display template.
In the next article, we'll explain how you can keep this reference, display custom properties between the title and
link in the classic search results, and also apply hit highlighting to your custom properties.
properties in classic search results - option 2 in
SharePoint Server

In How to display values from custom managed properties in search results - option 1 in SharePoint Server we
showed a simple method to add a custom icon and values from two custom managed properties to your classic
search results. In this topic, we'll look at a somewhat fuller method for changing the way classic search results are
displayed that includes if statements and hit highlighting. In this article, you'll learn:
Strategy for killing three birds with one stone - search results version
How to display values from custom managed properties with hit highlighting, and get automatically
improved relevancy
Strategy for killing three birds with one stone - search results version
First, let's state what we want to achieve:
Display values from two custom managed properties.
Apply hit highlighting to the two custom managed properties.
Get automatically improved relevancy for our classic search results.
Before we look at details about how to achieve these goals, let's look at the strategy we want to follow. If this gets a
bit complex, please try to hang in there. Hopefully it'll be clear by the end.
First, remember how we can think about hit highlighting:
1. The managed properties that are listed in the Hit-highlighted properties (JSON ) section of the Search
Results Web Part and the "magical summary" property are passed to the HitHighlightedProperties
property.
2. All values of the HitHighlightedProperties property are passed to the HitHighlightedSummary property.
3. A truncated version of the values in HitHighlightedSummary is displayed in the Search Results Web Part
with three dots at the end.
Also remember that each item display template contains a reference to the Item_CommonItem_Body display
template, and that this template contains an onlick method that will result in automatically improved relevance
based on the end-user's click behavior.
So our strategy is this: create variables in the item display template that will be passed on and rendered by the
Item_CommonItem_Body display template.
Specifically, that means that we have to do the following:
Add the custom managed properties that we want to display in our classic search results to the Hit-
highlighted properties in the Search Results Web Part.
Add the custom managed properties to an item display template.
In the item display template, create a variable that will be used by the property HitHighlightedSummary to
display our two custom managed properties with hit highlighting.
In the item display template, leave the reference _#=ctx.RenderBody(ctx)=#_ so that the
Item_ComonItem_Body display template will render the search result. This makes sure that we get
automatically improved relevancy.
OK, now let's take it step-by-step, with examples of how we did this for our Search Center scenario.
How to display values from custom managed properties with hit

highlighting, and get automatically improved relevancy
First, you have to find the managed property names that correspond to the custom site columns that you want to
use. We looked at how to do this in How to display values from custom managed properties in search results -
option 1 in SharePoint Server.
Next, you have to do some configuration on the Search Results Web Part. Here are the steps:
1. On the Search results page, choose the Settings menu, and then choose Edit Page.
2. In the Search Results Web Part, choose Web Part Menu --> Edit Web Part.
3. In the Web Part tool pane, choose to expand the Display Templates section, and then select Use a single
template to display items. This will allow you to change the Hit-highlighted properties (JSON ) field.
4. In the Hit-highlighted properties (JSON ) field, use the following format to add the custom managed
properties that you want to add hit highlighting to:
"<Managed property name>"
In our Search Center scenario, we wanted to apply hit highlighting to the ContentSummaryOWSMTXT and
the owstaxIdTechnicalSubject managed properties.
5. Select Apply to save the changes. This will close the Display Templates section.
6. Select Display Templates to reopen the section, and select Use result types to display items.
7. Click OK and save the page.
Next, you have to add the custom managed properties to an item display template. Here's what you should
do:
8. Open the item display template that belongs to the result type for which you want to customize search
results.
In our Search Center scenario, this was TechNet content .
9. In the item display template, in the ManagedPropertyMapping tag, use the following syntax to add the
custom managed properties that you want to display:
In our Search Center scenario, we wanted the values from the managed properties ContentSummaryOWSMTXT
and owstaxIdTechnicalSubject to be displayed in the search result. To make the file easier to maintain, we named
the current item properties the same as the managed properties.
Next, you have to create variables in the item display template that will be used and rendered by the
Item_Common_Item_Body display template. Here's what you should do:
10. Because you have no guarantee that the values of your custom properties will contain any of the entered
query words, that is, hit highlighting won't be used, you have to create variables that guarantee that that the
value of your custom properties will be displayed regardless of hit highlighting.
The following screen shots show how we created two such variables for our custom properties
ContentSummaryOWSMTXT and owstaxIdTechnicalSubject .
11. In addition, we added a similar variable for the Title property. If you don't add this, the search results won't
be rendered.
12. The last step that you have to do in the item display template is to create a variable that will override the
HitHighlightedSummary property used to display the values.
13. Save the item display template.
NOTE
You don't have to do this step if you are using SharePoint Online. Go to Site settings --> Search Result Types.
Notice that a Property Sync alert is displayed.
This alert is displayed because we added managed properties to an item display template (what we did in
step 9). To update the result types with the newly added managed properties, choose Update.
IMPORTANT
If you don't do this update, the newly added managed properties won't display in your search results.
After we made these changes, when users entered a query in the Search Center, the search result included:
1. A custom icon
2. The value of Title with hit highlighting
3. The value of ContentSummaryOWSMTXT with hit highlighting
4. The value of owstaxIdTechnicalSubject (The query words did not match the property value, but because of
the variable that we created in step 10, the value is displayed.)
5. A link to the item in the list
We wanted to make one little change to how the value for owstaxIdTechnicalSubject was displayed. We wanted to
give users a bit more context as to what this value represents. Therefore, we decided to add the text "Technical
Subject:" before the value. Also, because this value is not always present for all list items, we decided it should only
display when a value was present.
To do this, we made a change to the variable that overrides the HitHighlightedSummary property:
Notice that we added a slightly different color to the text "Technical Subject:". With this addition, the final search
result is displayed as follows:
In How to create a new result type in SharePoint Server, we had decided we wanted 6 different result types. After
creating the TechNet content result type and display template, it was very easy to copy this work over to the other
5 result types.
And here's the result:
So now that we have changed the way classic search results are displayed, the next step is to change the values
that are displayed in the hover panel.
How to display values from custom managed properties in the hover panel in SharePoint Server
properties in the hover panel in SharePoint Server

In How to display values from custom managed properties in search results - option 2 in SharePoint Server we
showed you how to display values from custom managed properties with hit highlighting, and get automatically
improved relevancy based on end-user click behavior. In this article, you'll learn:
How to decide which hover panel display template to modify
How to copy an existing hover panel display template
How to change a hover panel display template to show values from custom managed properties
How to decide which hover panel display template to modify

Before we do anything, let's first refresh our memories on how the different display templates are connected:
1. Each result type contains a reference to an item display template.

2. Each item display template contains a reference to a hover panel display template.
3. Each item display template contains a reference to the common item display template.
4. Each referenced hover panel display template contains references to three common hover panel display
templates.
By default, the rendering of the hover panel is performed by the three common hover panel display templates. The
illustration below shows how the common hover panel display templates were used to render the default hover
panel in our Search Center scenario.
To make life as easy as possible when you are adding custom properties to your hover panel, you should leave
these three common hover panel display templates as they are, and instead concentrate on the result type specific
hover panel display template (highlighted in the illustration below ). That's what we did in our Search Center
scenario, and it's what we'll demonstrate in this article.
This may seem confusing now, but we'll show you all the the steps that are required in the next two sections. So
let's get started!
How to copy an existing hover panel display template

Remember when we created the custom item display template TechNet content , we started by copying the item
display template named Item_Default (see How to create a new result type in SharePoint Server for more
information). The Item_Default display template contains a reference to the Item_Default_HoverPanel hover panel
display template. Because we copied the Item_Default display template, our TechNet content display template also
contains a reference to the Item_Default_HoverPanel .
We wanted to use the Item_Default_HoverPanel hover panel display template as a basis when we added custom
properties to our hover panel. Therefore, in our mapped network drive, we copied the Item_Default_HoverPanel
display template
and gave it a new name: TechNet_Content_HoverPanel .
We only had to rename the HTML file, because the name of the associated JavaScript file was automatically
updated.
In the TechNet content display template, we changed the reference in var hoverUrl so that it pointed to the newly
copied and renamed TechNet_Content_HoverPanel display template.
How to change a hover panel display template to show values from

custom managed properties
In our Search Center scenario, the default hover panel contained almost no additional information about the
search result.
We wanted to add the values from the following four site columns to the hover panel:
GUID/UUID
Internal Writer
Status
Submission Contact
The following screen shot shows how these values are maintained for one item in our internal list.
When adding custom properties to a hover panel, we have to add them to the item display template
(highlighted in the illustration below ).
Again, because this is not really intuitive: When adding custom properties to a hover panel, we have to add them
to the item display template .
To display custom properties in the hover panel, here's what you should do:
1. Find the managed property names of the site columns that you want to use. How to display values from
custom managed properties in search results - option 1 in SharePoint Server showed how to do this.
2. Open the item display template that contains the reference to the hover panel display template that you
want to customize. In the item display template, in the ManagedPropertyMapping tag, use the following
syntax to add the custom managed properties that you want to display:
In our Search Center scenario, we added four managed properties to the TechNet content item display template.
![Added MPs](../media/OTCSP_AddedMPs.png)
3. NOTE
You do not have to do this step if you are using SharePoint Online.
Go to Site settings --> Search Result Types. Notice that a Property Sync alert is displayed.
This alert is displayed because we have added new managed properties to an item display template (we did
this in step 2). To update the result types with the newly added managed properties, choose Update.
IMPORTANT
If you don't do the update, the newly added managed properties won't display in your hover panel.
4. Open the hover panel display template that you want to change, and use HTML to add the custom
properties that you want to display.
In our Search Center scenario, we opened the TechNet_Content_HoverPanel . The following screen shot
shows how we added our four custom properties.
5. Save the file.

By doing a new search and hovering over a search result, we saw that the four custom properties were now
displayed. Nice!
But, we are not completely through yet. The values for Internal Writer and Submission Contact were displayed
differently. The screen shot might not show it clearly, but hopefully you can see that the value for Internal Writer
was displayed well, but the value for Submission Contact was very long and contained an ugly GUID.
Both these values come from a site column of type Person or Group. The difference is that in the site column
settings, Internal Writer is configured to show Name, whereas Submission Contact is configured to show Name
(with presence).
To make Submission Contact display correctly, we copied the HP.GetAuthorsHtml method that is used by the
Item_CommonHoverPanel_Body display template to display authors.
And now the hover panel was starting to look really good.
But to make the hover panel even more helpful, we wanted to add an action to the bottom of the hover panel. will
show how to do this this.
How to add a custom action to the hover panel in SharePoint Server
How to add a custom action to the hover panel in
SharePoint Server

In How to display values from custom managed properties in the hover panel in SharePoint Server, we showed
you how to display values from custom managed properties in the hover panel. In this article you'll learn:
What is a hover panel action?
How to add an action to the hover panel
What is a hover panel action?

Before we look at how to add a custom action to a hover panel, let's make sure we know what an action is.
At the bottom of the hover panel there are some links that are called actions . When we choose one of these,
something will occur. For example, in our Search Center scenario, when we choose "SEND"
an email message with a link to the list item will open.
To enable our visitors to do something with the search results, without having to leave the search results page, we
can add a custom action.
In our Search Center scenario, we wanted to add a custom action that opens the published article. For example, for
the search result "Customize search result types in SharePoint Server", we wanted to add an action that opens this
link:<need fwlink? /SharePoint/search/customize-search-result-types>
How to add an action to the hover panel

In our lists, when an article is published, the URL to the published article is added to the list item. The screen shot
below shows how the URL to the article "Customize search result types in SharePoint Server" is maintained in the
site column "Content Release URL".
Because this URL is maintained in the list, we can add a custom action to the hover panel that will open the link.
How to display values from custom managed properties in the hover panel in SharePoint Server showed how the
hover panel actions are rendered by the Item_Common_HoverPanel_Actions display template. So, to add a
custom action, you have to edit this file.
But, similar to what we did when we added a custom property to the hover panel, you have to add the managed
property that you want to use in your custom action to the item display template.
Confused? Well, this is not easy. It takes a while to understand how things were connected. Let's go through it
step-by-step.
Here are the steps to add a custom action to the hover panel:
1. Find the managed property name of the site column that you want to use. How to display values from
custom managed properties in classic search results - option 1 in SharePoint Server showed how to do this.
2. In your mapped network drive, open an item display template. In the item display template, in the
ManagedPropertyMapping tag, use the following syntax to add the custom managed property:
In our Search Center scenario, we added the custom property we wanted to use to the TechNet content display
template.
3. NOTE
You don't have do this step if you are using SharePoint Online.
Go to Site settings --> Search Result Types. Notice that a Property Sync alert is displayed.
This alert is displayed because we have added a new managed property to an item display template (what
we did in step 2). To update the result types with the newly added managed properties, choose Update.
IMPORTANT
If you don't do the update, the newly added managed properties won't display in your hover panel.
4. Open the Item_Common_HoverPanel_Actions display template. See how the default actions are created,
and use JavaScript and HTML to add your custom action.
In our Search Center scenario, we looked at how the OPEN action ( #= editHmtl =# ) is created. Based on
that, we created a new action: #= viewHtml =#. The following screen shot shows what we did.
By doing a new search and hovering over a search result, we saw that our new custom action was displayed.
Nice!
So now that you know how to change the way your classic search results are displayed, there is one more thing we
should look at, and that is how you can change the text that is displayed in the Search Box Web Part.
How to change the text that is displayed in the Search Box Web Part in SharePoint Server
How to change the text that is displayed in the
Search Box Web Part in SharePoint Server

This article will be short and sweet, so let's get right to it.
How to change the text that is displayed in the Search Box Web Part
The following screen shot shows the default text that is displayed in the Search Box Web Part.
Here are the steps to change this text:

1. In your mapped network drive, go to Display Templates --> Search, and open the file Control_SearchBox
. For details about mapping your network drive, see Stage 6: Upload and apply a new master page to a
publishing site in SharePoint Server.
2. Replace the value for the promt variable with the text you want to display. Enclose the text in quotation
marks.
The following screen shot shows how we changed this in our Search Center scenario.
3. Save the file.

In the Search Center, you can now see the new text.
So that's it for this series. If you plan to change how search results are displayed in your Search Center, we hope
you'll find the information in this series helpful.
How to change the order in which classic search
results are displayed in SharePoint Server

In the series How to change the way search results are displayed in SharePoint Server we explained how to
customize the way search results are displayed by adding custom icons and properties.
When it comes to displaying search results, design and content are indeed very important. However, there is one
thing that often trumps them both: the order in which search results are displayed.
Think of your own behavior when looking at search results. How often do you click to view the second page of
search results? Often, the answer is "rarely."
So, when displaying search results, it is important that the results that your users are looking for are displayed as
high up in the search results list as possible. This article, an addendum to the How to change the way search results
are displayed in SharePoint Server series, explains how to use a query rule to change the order in which classic
search results are displayed. To demonstrate how query rules work, we'll use an example from an internal
Microsoft Search Center.
What was the problem again?
When using query rules: define before you assign
How to create a query rule that will change the order in which classic search results are displayed
How do I know that the query rule's been applied?
Think two times before you apply a query rule
What was the problem again?

As you know, Microsoft publishes thousands of articles across TechNet, MSDN, and Office.com. To help in the
publishing process, we use several SharePoint lists. Each item in a list represents an article or a media file. To make
it easy to find information about a particular list item, we created a Search Center that searches across these lists.
The following screen shot shows the default order in which search results were displayed in our Search Center.
Notice that search results for articles and images were displayed in a mixed order.
When users search for something in this Search Center, they are usually looking for information about an article.
So, to make it easier for users to find information about articles, we wanted to change the order of the search
results so that images would be displayed at the bottom. To do this, we had to create a query rule.
When using query rules: define before you assign

A query rule is largely what the name implies: a rule that can be applied to queries. But before you start to assign
rules to your queries, you should define what you want the query rule to do.
Basically, you have to define two things: a condition and an action. Simply put, this comes down to defining the
following:
"when X (condition), do Y (action)".
In our Search Center scenario, we knew the action part: Display list items that represent images at the bottom of
the search results list .
In our lists, we use the site column Content Type to differentiate between the type of articles or media types a list
item represents. For example, all images have the value "Art" for Content Type .
Based on this, we were able to define the condition part so that my final definition was:
When list items are of Content Type "Art", display these at the end of the search results list.
So, with the definition in place, we could begin to create the query rule that would make this happen.
How to create a query rule that will change the order in which search
results are displayed
Depending on your permission level, you can create a query rule on three levels:
PERMISSION LEVEL WHERE THE QUERY RULE WILL BE APPLIED
Search service application administrator To all site collections within the farm
Site collection administrator To all sites inside a site collection
To save space, we'll only show you how to create a query rule as a Site collection administrator.
1. Go to Site Settings --> Search Query Rules.
2. On the Manage Query Rules page, from the Select a Result Source menu, select the result source to
which the query rule should be applied.
3. Select New Query Rule.

4. On the Add Query Rule page, in the Rule name field, enter a name for the query rule.
In our Search Center scenario, we named the query rule Demote Art .
5. In the Query Conditions section, specify the conditions that will trigger the query rule.
In our Search Center scenario, we wanted the query rule to be triggered every time that a user entered a
query. In other words, we didn't want the query rule to be triggered by a specific condition. Therefore, we
selected Remove Condition.
6. In the Actions section, specify what you want the query rule to do when it is triggered.
In our Search Center scenario, we selected Change ranked results by changing the query. This opened
a dialog box where we could define what we wanted the query rule to do.
7. We wanted to change the order of search result. Therefore, in the Build Your Query dialog box, we selected
the SORTING tab.
From the Sort by menu, we selected Rank.
From the Dynamic ordering section, we selected Add dynamic ordering rule.
From the Change ranking when menu, we selected Manual condition.

Remember, we wanted list items of Content Type Art to be displayed at the end of the search results list. So,
in the Manual condition field, we entered ContentType:Art , and selected Demote to bottom.
Now, before we move on, let's analyze what we entered:

ContentType is the managed property that represents the site column Content Type. How to display
values from custom managed properties in search results - option 1 in SharePoint Server explains
how to find managed property names.
The colon : means "contains".
Art is the managed property value.
Demote to bottom is the action that should be taken.
Put it together, and it matches the definition we specified: When list items are of Content Type "Art", display
these at the end of the search results list .
8. Select OK, and then Save.
Your newly created query rule will be listed on the Manage Query Rules page.
In our Search Center scenario, we could see that the Demote Art query rule was created.
When we now entered a search in the Search Center, we could see that articles were displayed at the top of the
search results list, and images were displayed at the bottom. Nice!
How do I know that the query rule's been applied?
In our Search Center scenario, we could easily verify that the query rule we created was being applied. But, if you
are uncertain about whether your query rule is being applied, the Search Results Web Part can give you an
answer.
Here are the steps to verify that a query rule is being applied:
1. On your search results page, select to edit the Search Results Web Part.
2. In the Web Part tool pane, select Change query.
3. In the Build Your Query dialog box, select the TEST tab, and then Show more.
4. In the {searchboxquery} field enter a query that you know should cause the query rule to be triggered,
and then select Test query.
In our Search Center scenario, we could verify that our query rule was working by looking at the following:
1. In the field Applied query rules, the name of our query rule, Demote art, was shown.
2. In the Query text section, XRANK was applied to ContentType:Art .
Think two times before you apply a query rule

Even though this was a fairly simple query rule, we saw that the effect was very noticeable. So a word of warning:
even though query rules are great for changing the order in which classic search results are displayed, you should
think carefully before you apply too many of them. The effects can be very large, and the more complex query
rules that you have, the more performance resources each query will require.
But, if they are used with caution, you can make the users of your Search Center very happy customers.
Create and import a thesaurus in SharePoint Server

Why synonyms matter when you search
How to create a thesaurus
How to import a thesaurus
Why synonyms matter when you search

People are different. Not only do we look and dress differently, but when we communicate, we use different words
to describe the same thing. The same applies to how we search for information. In a search engine, one person
might enter "flower image," whereas another might enter "flower picture" or "flower photo." Even though we used
different phrases, we were searching for the same information.
And then there are acronyms. Acronyms are especially popular in organizations, but when we search for
information, this can be challenging. For example, if we want to see the Monthly Sales Report, we'll most likely
search for it by using the terms Monthly Sales Report . But, the people who create this report might use the
acronym MSR . So, when we search for Monthly Sales Report , no search results are returned.
In the classic search experience of SharePoint Server we can easily create and upload a thesaurus that contains
synonyms for search phrases and acronyms. In this article, we'll use a simple example to show how to do this.
Suppose you have two documents in a library:
A Word document titled "Coffee"
A PowerPoint document titled "Cup of Joe"
When you search for coffee , the Word document is returned.
When you search for cup of joe , the PowerPoint document is returned.
For both documents to be returned when you search for either coffee or cup of joe , we can create a thesaurus.
How to create a thesaurus

1. Open a text editor, for example Notepad.
2. In the text editor, enter the columns of our thesaurus: Key , Synonym , and Language .
3. Use commas to separate the words.
4. On a new line in the text editor, enter a term or a phrase, a synonym for that term or phrase and a two letter
language code. Use commas to separate the phrases, for example Coffee,Cup of Joe,en .
This means that when users search for "Coffee", search results for both "Coffee" and "Cup of Joe" will be
returned.
5. Repeat step 3, but switch the order of Key and Synonym .
This means that when users search for "Cup of Joe," search results for both "Cup of Joe" and "Coffee" will
be returned.
6. Save the file as .csv with UTF-8 encoding.
Now that we've created our thesaurus, the next task is to import it to SharePoint Server.
How to import a thesaurus

NOTE
To import a thesaurus, you must be a Search service application administrator.
1. On the server where SharePoint Server is installed, open a SharePoint Management Shell.
2. At the command prompt, enter the following command:
Import-SPEnterpriseSearchThesaurus -SearchApplication $searchApp -Filename <Path>
where <Path> is the UNC path of the thesaurus file.
That's it!
IMPORTANT
When you import a thesaurus, the existing thesaurus will be overwritten. If you want to add new phrases to our thesaurus,
you should add them to the thesaurus file we have already imported. You can't export a thesaurus file. Therefore, you should
maintain our thesaurus file in an external system, for example on a file share.
To verify that you thesaurus is working the way that you want it to, search for phrases from the thesaurus. In this
example scenario, two files were returned for both "coffee" and "cup of joe."
See also
Concepts
Create and deploy a thesaurus in SharePoint Server
Create and import query suggestions for the classic
search experience in SharePoint Server

An easy way to help users search for information in SharePoint Server is to create query suggestions . Query
suggestions are words that appear under the search box as users type a query.
SharePoint Server automatically creates a query suggestion when users have clicked a search result for a query at
least six times. For example, if users have entered the query word "coffee" and then clicked on a search result six
times, then "coffee" automatically becomes a query suggestion. We can also create query spelling suggestions
manually. In this article, we'll use a simple example to show how to do this.
How to create a query suggestions file
How to import a query suggestions file to SharePoint Server
How to verify that your query suggestions are working
How to create a query suggestions file

1. Open a text editor, for example Notepad.
2. Enter the query spelling suggestions that you want to add. Add one word or phrase per line.
3. Save the file as a .txt file and encoding UTF-8.
Now that you have a query suggestions file, the next task is to import it to SharePoint Server.
How to import a query suggestions file to SharePoint Online
1. From the Office 365 Admin menu, select SharePoint.
2. On the SharePoint admin center, select search.
3. On the search administration page, select Query Suggestion Settings.
4. In the Language for suggestions phrases section, select the language of your query suggestions. In the
Always suggest phrases section, select Import from text file.
5. In the Text file that has phrases section, select Choose File, and import your query suggestions file.
6. Select OK, and then Save Settings.
IMPORTANT
When you import query suggestions, existing query suggestions are overwritten. If you haven't previously imported any
query suggestions, you have nothing to worry about. Automatically created query suggestions will not be overwritten when
you import new ones. But, if you want to import additional query suggestions, you should export the existing query
suggestions file, update it, and then reimport it.

1. Go to Central Administration --> Manage service applications --> Search Service Application -->
Query Suggestions.
2. On the Query Suggestion Settings page, in the Always suggest phases section, select Import from
text file.
3. On the Import phrases for query suggestions page, select Browse, and import your query suggestions
file.
4. Select OK, and then Save Settings.
IMPORTANT
When you import query suggestions, existing query suggestions are overwritten. If you haven't previously imported any
query suggestions, you have nothing to worry about. Automatically created query suggestions won't be overwritten when
you import new ones. But, if you want to import additional query suggestions, you should export the existing query
suggestions file, update it, and then reimport it.
How to verify that your query suggestions are working

IMPORTANT
After you have uploaded your query suggestions file, it might take some hours before your query suggestions are displayed.
To verify that your query suggestions are working correctly, in a search box, type two letters of a phrase from your
query suggestions file. The query suggestions appear under the search box.
See also
Concepts
Other Resources
Customize query suggestions in SharePoint search
Changing the ranking of classic search results in
SharePoint Server

Audience: SharePoint Server and SharePoint Online search administrators.
Before you start:
To change the ranking of classic search results, you need:
A basic understanding of search in SharePoint
Knowledge and understanding of the content that is returned in search results, to judge how relevant a
search result for a given query is
A running Search service application and Enterprise Search Center
Content in the search index
Why is search result ranking important?

Whether you're working with an Enterprise Search Center on premises, with SharePoint Online, or with a cross-
site publishing solution, your search results will be ranked. In most cases, this default search result ranking should
be just fine.
But, sometimes, you may want to influence the ranking of search results to make results even more relevant to
your end-users. We recently published a set of articles that explain how you can change the ranking of search
results and that will help you understand how search result ranking works in SharePoint Server. (See references
later in this article.)
How are search results ranked?

Search results are ranked using a ranking model. A ranking model calculates the position of a search result in the
result set. There are several ranking models in SharePoint that automatically do this for you. So, usually, you don't
have to care about which ranking model is used for a query, or what it does exactly.
Using query rules to change search result ranking

If you are not satisfied with the search result ranking that SharePoint provides, we recommend that you add query
rules to optimize search result ranking for your search scenarios.
The good thing about query rules is that they are available to a large range of search administrators. You can add
query rules to the Search service application as a search administrator on premises, or as a tenant administrator in
SharePoint Online. You can also add and reuse query rules as a site collection administrator or site owner, both on
premises and online.
For each query rule, you can influence the way that you sort, rank and display search results. Each query rule
consists of a query rule condition and a query rule action. Whenever a query matches a query rule condition, the
query rule action that you specify in the query rule is triggered. After you have entered a condition, you can specify
to:
Add promoted results that always appear above the ranked search results.
Add a result block that shows particular search results as a group, and promote that block.
Change the order of the search results:
Sort by one or several managed properties.
When you sort results in this manner, you override the ranking model.
Apply dynamic ranking.
You can promote or demote results, based on a query condition that you specify.
Influence the ranking of search results with query rules provides more details. In most cases, you can use query
rules to adjust ranking. However, to avoid increased query latency be careful not to add too complex or too many
query rules.
Using custom ranking models: if query rules don't work

If it turns out that you can't use query rules to achieve your goals, you can consider creating and deploying a
custom ranking model. For example, you can create a custom ranking model to include custom managed
properties in the search result ranking calculations.
Since creating and tuning a custom ranking model is complex and can have a very large effect on your search
results, we recommend that you do not take this lightly. You can only create and deploy a custom ranking model on
premises.
When you create a custom ranking model, you copy an existing SharePoint Server ranking model and edit that
copy. Then, you should validate how good the custom ranking model is by running many queries and comparing
the results that you get with the new ranking model to the results that you got with the previous ranking model.
Once you're done creating and validating, you deploy your custom ranking model and tell the search system that it
should use the new ranking model to rank all or some of your search results.
As with any ranking model that is included with SharePoint Server, a custom ranking model calculates the position
of a search result in the result set. A search result is considered relevant if it receives a high rank score. A high rank
score is a specific numeric score that's calculated by the search engine that uses a ranking model. A ranking model
is a list of one or more rank stages that contain a set of rank features. The ranking model defines how the search
engine calculates the relevance rank using various factors, which are represented in the ranking model as rank
features.
There are several ranking models available in SharePoint Server. For more details, see Overview of search result
ranking in SharePoint Server. Most search results are ranked using the Default Search Model. Read Customizing
ranking models to improve relevance in SharePoint 2013 on MSDN to learn more about the most important
ranking features in the Default Search Model. This article also explains how to deploy a custom ranking model.
We hope that the articles give you an overview of how search result ranking works and how you can change it.
Hybrid for SharePoint Server

With SharePoint Server hybrid, productivity services in SharePoint Online can be integrated with on-premises
SharePoint Server to provide unified functionality and access to data. For enterprises that want to gradually move
their existing on-premises SharePoint Server services to the cloud, SharePoint Server hybrid provides a staged
migration path by extending high-impact SharePoint Server workloads to SharePoint Online.
A SharePoint Server hybrid environment enables trusted communications between SharePoint Online and
SharePoint Server. When you have established this trust framework, you can configure integrated functionality
between services and features such as Search, Follow, and user profiles.
To get started exploring hybrid, see the following articles:
Extranet for Partners with Office 365
For detailed hybrid configuration information, see SharePoint Server 2016 hybrid configuration roadmaps.
Explore SharePoint Server hybrid

Discover how a SharePoint hybrid environment using SharePoint Server and SharePoint Online can integrate
functionality and access between the services and features of both environments.
Offload your users' personal storage to SharePoint Online with hybrid OneDrive for Business. Maximize the reach
of Search to get search results from both SharePoint Server and SharePoint Online. Extend access to Microsoft
Business Connectivity Services data and applications to the cloud. The following articles describe the currently
supported SharePoint hybrid options and configurations and will help you decide which hybrid solution you
should use to meet your business goals.
When you're done exploring, plan your hybrid deployment.
CONTENT DESCRIPTION
The building blocks of Office 365 hybrid This chalk talk video covers the major components of Office
365 hybrid. If you're considering a hybrid solution, watch this
video to learn more about how all the pieces fit together.
Minimum public update levels for SharePoint hybrid features Learn which SharePoint Server updates are required to enable
the various hybrid features.
SharePoint hybrid sites and search Learn about the available hybrid features related to sites and
search that can help create a cohesive user experience
between SharePoint Server and SharePoint Online.
Learn about cloud hybrid search for SharePoint Learn about cloud hybrid search, its advantages, and what
search experiences are available for your users.
Learn about hybrid federated search for SharePoint Learn about the different scenarios available for hybrid
federated search and what search experiences they enable for
your users.
Hybrid picker in the SharePoint Online admin center Learn about the hybrid picker configuration wizard and which
hybrid scenarios it enables.
See also
Concepts
The building blocks of Office 365 hybrid

This chalk talk video covers the major pieces of Office 365 hybrid deployments. This includes identity
management, and a look at SharePoint, Exchange, and Skype for Business hybrid.
If you're considering deploying an Office 365 hybrid solution, watch this video to learn more about how all the
pieces fit together.
Video: The building blocks of SharePoint hybrid
Minimum public update levels for SharePoint hybrid
features

SharePoint Server offers a variety of hybrid scenarios to help connect you on-premises SharePoint environment to
Office 365. Since these features have been released over time, they may require a minimum Public Update (PU ) in
order to work. This article is a reference for which updates are required for each hybrid feature.
Keep in mind that these are minimum updates. Later PUs are fine, and we always recommend that you keep your
farm updated with the latest Public Update.
Links to all the available Public Updates can be found at SharePoint Updates.
NOTE
Hybrid extranet B2B collaboration sites have no on-premises components and thus have no PU requirements.

The following table shows the minimum PU requirements for hybrid features in SharePoint Server 2019.
HYBRID FEATURE MINIMUM PU
Hybrid self-service site creation RTM
Cloud hybrid search RTM
Extensible hybrid app launcher RTM
Hybrid federated search RTM
Hybrid OneDrive for Business RTM
Hybrid profiles RTM
Hybrid site following RTM
Hybrid taxonomy RTM
Hybrid content types RTM

Hybrid self-service site creation November 2017
Cloud hybrid search RTM
Extensible hybrid app launcher RTM
Hybrid auditing November 2016
Hybrid federated search RTM
Hybrid OneDrive for Business RTM
Hybrid profiles RTM
Hybrid site following RTM
Hybrid taxonomy November 2016
Hybrid content types June 2017

Hybrid self-service site creation March 2017
Cloud hybrid search January 2016
Extensible hybrid app launcher July 2016
Hybrid federated search (results in SharePoint Server) RTM
Hybrid federated search (results in SharePoint Online) May 2014
Hybrid OneDrive for Business September 2015
Hybrid profiles September 2015
Hybrid site following July 2016
Hybrid taxonomy November 2016
Hybrid content types June 2017

Hybrid OneDrive for Business February 2015


A hybrid environment can help your company get started in the cloud, taking a first step to explore the cloud
functionality at own your own pace. It also enables enterprise users to be connected from almost anywhere to the
resources and content they need.
When you add Office 365 to an environment where you're already using SharePoint Server, by default there's no
integration between the two. With SharePoint hybrid features, you can tie the two environments together in a
variety of ways to make a more seamless user experience.
With SharePoint hybrid features, you can consolidate search results between SharePoint Server and Office 365,
consolidate user profiles in Office 365, and offload your users' personal storage to the cloud. Except as noted, the
hybrid features discussed in this article are available for both SharePoint Server 2013 and SharePoint Server
2016.
Hybrid sites and search at a glance

This table gives a quick overview of hybrid integration between SharePoint Server and Office 365.
NON-HYBRID HYBRID
OneDrive for Business OneDrive for Business is available in OneDrive links are provided in
Office 365 but there is no link to it from SharePoint Server which direct users to
SharePoint Server. If you've deployed OneDrive for Business in Office 365.
MySites, users may have a second (See Plan hybrid OneDrive for Business
OneDrive for Business in SharePoint for detailed information.)
Server.
Site following The followed sites list in Office 365 Followed sites from both locations are
tracks followed SharePoint Online sites. consolidated in the SharePoint Online
If you've deployed MySites, a second followed sites list. SharePoint Server
followed sites list in SharePoint Server links to the followed sites list redirect
tracks followed SharePoint Server sites. users to the SharePoint Online followed
sites list.
(See Hybrid site following for detailed
information.)
Document following If you've deployed MySites, the Hybrid document following is not
followed documents list in SharePoint available. If you use hybrid OneDrive
Server tracks followed SharePoint for Business, the SharePoint Server
Server documents. followed documents list will be hidden
from users. (Note that if you configure
hybrid search and you have Delve, you
can favorite SharePoint Server
documents.)
NON-HYBRID HYBRID
Profiles Users have separate profiles in Profiles exist in both locations, but
SharePoint Server and in Office 365. SharePoint Server links to users' profiles
redirect profiles in Office 365.
(See Plan hybrid profiles for detailed
information.)
Extensible app launcher Users see a different app launcher in There are still separate app launchers,
Office 365 and in SharePoint Server. but the SharePoint Server app launcher
includes several tiles from Office 365.
(See The extensible hybrid app launcher
for detailed information.)
Hybrid self-service site creation Users see separate self-service site Users going to the default SharePoint
creation experiences in SharePoint Server site creation page are redirected
Server and SharePoint Online, as to the SharePoint Online Group
configured by the administrator. Creation page, allowing them to create
sites in SharePoint Online.
(See Hybrid self-service site creation for
detailed information.)
Search Separate search indexes and search Search results between the two
centers for SharePoint Server and Office locations are combined in one of two
365. Users must search from ways. Cloud hybrid search crawls on-
SharePoint Server to find items stored premises content and indexes it in the
there and they must search form Office search index in Office 365. Users can
365 to find items stored there. search the Office 365 index from either
location. Hybrid federated search
combines search results from each
search index in a single search center.
(See Hybrid search in SharePoint for
detailed information.)
What is redirection?
Many of the SharePoint hybrid features make use of a technique called redirection. With redirection, when users
attempt to access a service in SharePoint Server using site navigation, they are automatically redirected to the
equivalent service in Office 365.
For example, in a non-hybrid environment, when a user clicks OneDrive on a SharePoint Server site, they are
taken to their SharePoint Server OneDrive for Business location. With hybrid OneDrive for Business, when a user
clicks OneDrive, they are taken to OneDrive for Business in Office 365.
Hybrid OneDrive for Business, hybrid site following, and hybrid profiles all use redirection to send users from on-
premises SharePoint Server to the equivalent service in Office 365. The on-premises SharePoint Server services
continue to function in the background and are accessible by users if they've bookmarked the URL.
When redirection is used, existing data in SharePoint Server is not automatically migrated to the equivalent Office
365 service. Documents in OneDrive for Business and user profile information have to be manually migrated for
each user, and SharePoint Server followed sites will have to be re-followed.
Hybrid sites features and OneDrive for Business

Several hybrid features are bundled together to help ease deployment. The two feature bundles are:
Hybrid OneDrive for Business
Hybrid sites features
(Note that the hybrid search options are independent of these two bundles and are configured separately.)
The following table shows which hybrid features are included with each option.
HYBRID ONEDRIVE FOR BUSINESS HYBRID SITES FEATURES
OneDrive for Business X X
Site following X
Profiles X X
Extensible app launcher* X
*In SharePoint Server 2016, the extensible app launcher is part of hybrid sites features. In SharePoint Server
2013, it requires the July 2016 PU and is enabled separately from hybrid sites features by using Windows
PowerShell.
Configuring SharePoint hybrid

To get started configuring hybrid features for your environment, choose a feature below:

Hybrid search lets your users search for files and documents across SharePoint Server and Office 365 at the same
time. Depending on how you set up hybrid search, you can have only on-premises users search for content stored
in Office 365, only online users search for content stored in SharePoint Server, or both user groups search for
content stored in the other environment.
There are two variants of hybrid search:
Cloud hybrid search
Hybrid federated search
What is cloud hybrid search?

With the cloud hybrid search solution for SharePoint, you index all your crawled content, including on-premises
content, in your search index in Office 365. When users enter a query in a search center, they get search results
from the Office 365 search index, and thus get results both from on-premises and Office 365 content.
What is hybrid federated search?

With the hybrid federated search solution for SharePoint, you federate results from your search index in
SharePoint Server 2013 and your search index in Office 365. When users enter a query in a search center, they get
search results from the Office 365 search index and from the SharePoint Server 2013 search index, and thus get
results both from on-premises and Office 365 content.
Cloud hybrid search or hybrid federated search - what's the difference
for your users?
With cloud hybrid search, search results come from one search index. A search center in for example SharePoint
Online in Office 365 displays and ranks results in one single result block. SharePoint Online calculates search
relevance ranking and refiners for all your results, regardless of whether the results come from on-premises or
Office 365 content.
With hybrid federated search, search results come from two indexes. A search center in for example SharePoint
Online in Office 365 displays and ranks results in two result blocks. SharePoint Online displays and ranks search
results from Office 365 content, but uses the ranking from SharePoint Server 2013 for search results from on-
premises content and displays these search results in the order that they arrive.
Should you choose cloud hybrid search or hybrid federated search?

We recommend that you choose cloud hybrid search for these benefits:
Your users get unified search results, search relevance ranking, and refiners even if your organization has a
hybrid deployment with content both on-premises and in Office 365.
Your users automatically get the newest SharePoint Online search experience without your organization
having to update your existing SharePoint servers.
Your users can use cloud capabilities such as Office Delve also for your on-premises content.
You no longer have to worry about the size of your search index, because your search index is in Office 365.
This means that the footprint of your SharePoint Server 2013 search farm is smaller, and your total cost of
ownership for search is lower.
You don't need to upgrade any of your existing installations of SharePoint to have enterprise search in the
cloud because SharePoint Server 2013 supports crawling of existing SharePoint Server 2007, SharePoint
Server 2010 and SharePoint Server 2013 content farms.
You no longer have to migrate your search index to a newer version of SharePoint because this happens
automatically for you in Office 365.
If you have some on-premises content that's highly sensitive and shouldn't be indexed outside your on-premises
network, then we recommend using a combination of cloud hybrid search and hybrid federated search.
See also
Concepts
Plan hybrid federated search for SharePoint Server
Other Resources

With the cloud hybrid search solution for SharePoint, you index all your crawled content, including on-premises
content, in your search index in Office 365. When users query your search index in Office 365, they get search
results from both on-premises and Office 365 content.
A search center displays and ranks results from the Office 365 search index in one result block and calculates
search relevance ranking and refiners for all your results, regardless of whether the results come from on-
premises or Office 365 content.
It's the metadata for the content that's indexed, and this metadata is encrypted when it's transferred to the search
index in Office 365, so the on-premises content remains secure. If you've synchronized Active Directory (AD )
between your on-premises network (Windows Server Active Directory) and your Office 365 tenant (Windows
Azure Active Directory), Office 365 alters the document permissions that refer to on-premises users, so they refer
to the corresponding Office 365 users. Users only see search results for content they have access to.
Learn more:
What are the benefits
Which search experiences can you offer with cloud hybrid search?
Where do you manage cloud hybrid search?
How does cloud hybrid search work?
What are the benefits?

Your users get unified search results, search relevance ranking, and refiners even if your organization has
content both on-premises and in Office 365.
This means that the footprint of your SharePoint Server search farm is smaller, and your total cost of
ownership for search is lower.
SharePoint Server 2013 supports crawling of existing SharePoint Server 2007 and SharePoint Server 2010
content farms.
SharePoint Server 2016 supports crawling of existing SharePoint Server 2007, SharePoint Server 2010,
and SharePoint Server 2013 content farms.
You no longer have to migrate your search index to a newer version of SharePoint Server because this
happens automatically for you in Office 365.
Which search experiences can you offer with cloud hybrid search?
When you've set up cloud hybrid search and a full crawl of the on-premises content has completed, the search
center in Office 365 automatically shows hybrid results from your Office 365 index.
Other searches
Search verticals - Search verticals narrow search results to a specific set of content, for example to show only
videos. If you currently use a search vertical in a search center in SharePoint Server, you have to recreate it in your
search center in SharePoint Online in Office 365.
Site search - Your existing search in document libraries in SharePoint Server stops returning results when you
move your search index to Office 365. Search is fastest when users use search centers that are in the same
environment as the search index, so searching from an Office 365 search center gives a better experience. If your
users need results from the Office 365 search index in on-premises SharePoint sites, such as in existing Team Sites
in SharePoint Server 2010 or SharePoint Server 2013, you can set up search in SharePoint Server to show hybrid
results from your Office 365 index. Because SharePoint Online in Office 365 processes your queries, your users
have to use the query syntax that SharePoint Online supports. Learn more in Show results from Office 365 in on-
premises SharePoint with cloud hybrid search.
eDiscovery search - You might have to set up eDiscovery separately in SharePoint Server and in SharePoint
Online in Office 365.
Cross-site publishing search - Cross-site publishing isn't available with cloud hybrid search.
Display options for search results
Previews - When a user hovers over a search result that comes from Office 365, information about the content as
well as a preview of the content is displayed. Information about the content from search results that come from
on-premises is displayed automatically, but you have to set up display of previews for this content.
Custom security trimming - Custom security trimming isn't available with cloud hybrid search because
SharePoint Online in Office 365 doesn't support custom security trimming.
Search features that work differently with cloud hybrid search
Best bets - Best bets is a SharePoint Server 2010 feature. Use query rules in SharePoint Online in Office 365
instead.
Custom search scopes - Custom search scopes is a SharePoint Server 2010 feature. Use result sources in
SharePoint Online in Office 365 instead.
Promotion/demotion of search results - Promotion/demotion of search results is a SharePoint Server 2010
feature. Use result sources in SharePoint Online in Office 365 instead.
Removal of on-premises search results - In Central Administration in SharePoint Server you can select a
Search service application and use the option "Index reset" to remove all content from the search index. This
option does not work for cloud hybrid search because there is no direct communication between the cloud Search
service application in SharePoint Server 2013 or SharePoint Server 2016 and the search index in Office 365. If
you only want to remove some on-premises metadata from the Office 365 search index, remove that on-premises
content source, or create a crawl rule that doesn't crawl the URL of a file. If you need to remove all metadata from
on-premises content from the search index in Office 365, open a ticket with Microsoft Support.
Usage reports - Usage reports are based on information about the crawled content and user actions on the
SharePoint site. The cloud Search service application in SharePoint Server 2013 or SharePoint Server 2016
doesn't communicate with the usage analytics in SharePoint Online, so usage reports in SharePoint Online don't
contain information about user actions on sites in SharePoint Server 2013 or SharePoint Server 2016.
Search features that aren't available with cloud hybrid search
Multi-tenancy on a SharePoint Server 2013 or SharePointServer 2016 farm - One SharePoint Server 2013
or SharePoint Server 2016 farm can only attach to one tenant in SharePoint Online in Office 365, therefore
SharePoint Online can't preserve the tenant isolation in a multi-tenant SharePoint Server 2013 or SharePoint
Server 2016 farm.
Custom entity extraction - Custom entity extraction isn't available with cloud hybrid search because SharePoint
Online in Office 365 doesn't support custom entity extraction.
Content enrichment web service - The content enrichment web service call-out is not available with cloud
hybrid search because SharePoint Online in Office 365 doesn't support custom enrichment web service.
Thesaurus - Thesauruses aren't available with cloud hybrid search because SharePoint Online in Office 365
doesn't support thesauruses.
Where do you manage cloud hybrid search?

You set up crawling of on-premises content in Central Administration in the SharePoint Server 2013 or
SharePoint Server 2016 farm.
You manage all other settings in search administration in SharePoint Online in Office 365.
Crawling on-premises content
With cloud hybrid search, the crawler can crawl the same content sources and use the same search connectors as
in earlier SharePoint Server versions. This lets you crawl and push content from your SharePoint Server 2007,
SharePoint Server 2010, SharePoint Server 2013 and SharePoint Server 2016 farms into the Office 365 search
index. But, you can't index content that requires custom security trimming, because SharePoint Online in Office
365 doesn't support adding custom security trimmers.
The crawler can crawl the same default file types as in earlier SharePoint Server versions. If you need to crawl
other file types on-premises, you just add custom iFilters to the SharePoint Server 2013 or SharePoint Server
2016 farm. From the SharePoint Server 2013or SharePoint Server 2016 farm you can also change which file
types the crawler crawls and includes in the search index in Office 365.
The search schema in SharePoint Online in Office 365
You manage the search schema in SharePoint Online, see Manage the Search Center in SharePoint Online.
The default mappings between crawled and managed properties in the search schema in Office 365 also apply to
the on-premises content. As long as you don't remove your existing, standard SSA, you can still set up a search
schema in SharePoint Server, but this search schema won't apply to your on-premises content that the cloud SSA
crawls.
In the user interface for managing the search schema in SharePoint Online, you can't see the difference between
the origin of properties such as categories, crawled properties, and automatically created managed properties.
For content that's stored in Office 365, you can customize the search schema at the tenant and the site collection
level. For content that's stored on-premises, you can only customize the search schema at the tenant level. In the
search index, metadata for content that's stored on-premises has the managed property ** IsExternalContent **
set to true.
How search results are displayed
Search results are security trimmed based on the user's Office 365 identity. Ranking does not differentiate
between on-premises and Office 365 content, and the refiners in the search center show both Office 365 and on-
premises content. But, there are a few differences:
Opening a link from a search result. To open a link from a search result that comes from on-premises
content, users have to either be connected to the on-premises intranet via a Virtual Private Network (VPN )
connection or be logged on to where the content is stored. Alternatively, you enable users to open such
links by installing a reverse proxy device for SharePoint Server 2013 or SharePoint Server 2016.
Previews. When a user hovers over a search result that comes from Office 365, information about the
content as well as a preview of the content is displayed. Information about the content from search results
that come from on-premises is displayed automatically, but you have to set up the ability to display
previews for this content.
How does cloud hybrid search work?

The key element is the cloud Search service application (SSA ). You set up a SharePoint farm running
SharePoint Server 2013 or SharePoint Server 2016 and create the cloud SSA on this farm. We only support one
cloud SSA per SharePoint Server farm.
Here's how it works:
On-premises content (1) is crawled by the crawler in the cloud SSA (2) and pushed to the search index in
Office 365 (3).
Users enter a query (4) in the SharePoint Online Search Center, the query is sent to the search index in
Office 365 (3), and results are returned to the SharePoint Online Search Center (4).
If necessary, you can set up site search in SharePoint Server 2013 or SharePoint Server 2016 to get search
results from your search index in Office 365. Users enter a query in an on-premises site search box (5) and
the query is sent via the server with the cloud SSA (2) to the search index in Office 365 (3). Results are
returned via the server with the cloud SSA (2) to the on-premises site search box (5).
See also
Concepts
Other Resources

With the hybrid federated search solution, you use both your index in SharePoint Server and your index in Office
365 Both SharePoint Server and SharePoint Online Search services can query the search index in the other
environment and return federated results. When users search from a Search Center, the search results come from
both your search index in SharePoint Server and your search index in Office 365.
The Search Centers display results from the environments in two separate result blocks. Each Search Center
displays and ranks search results from its own environment and uses ranking from the other environment for the
other environment's search results. Let's use the Search Center in SharePoint Online in Office 365 as an example.
This Search Center displays and ranks search results from the search index in Office 365, but for search results
from the search index in SharePoint Server this Search Center uses the ranking from SharePoint Server and
displays these search results in the order that they arrive.
If you've synchronized Active Directory (AD ) between your on-premises network (Windows Server Active
Directory) and your Office 365 tenant (Windows Azure Active Directory), Office 365 alters the document
permissions that refer to on-premises users, so they refer to the corresponding Office 365 users, and the other
way around. Users only see search results for content they have access to.
What are the scenarios for hybrid federated search?

Hybrid federated search results in SharePoint Server
Show search results from SharePoint Online in a Search Center in SharePoint Server. This is the simplest scenario
to set up because an outbound connection doesn't require a reverse proxy device.
Hybrid federated search results in SharePoint Online
Show search results from SharePoint Server in a Search Center in SharePoint Online. This scenario requires a
reverse proxy device, see Display hybrid federated search results in SharePoint Online.
Hybrid federated search from both SharePoint Server and SharePoint Online
Show search results from both environments in Search Centers both in SharePoint Online and SharePoint Server.
This scenario requires a reverse proxy device, see Display hybrid federated search results in SharePoint Server
and Display hybrid federated search results in SharePoint Online.
Should you set up hybrid federated search in the SharePoint Server

farm, or in SharePoint Online?
For your users, it's usually most convenient if you set up hybrid federated search in the environment where
most of them are working. That way, users don't have to go to the remote environment to search for
content.
But for performance reasons, it's usually best to set up hybrid federated search in the environment where
most of the content is stored. If most of the search results are from the local deployment, the overall query
latency is likely to be less (all other things being equal) than if many results are from the remote
deployment. Also, in general, when a user clicks a search result for local content, the response time to open
that content will be faster than it would be to open content that is stored remotely. This is especially true for
large files.
You can set up hybrid federated search in both SharePoint Server and SharePoint Online if there about as
many users working in both environments, or if there is about as much content in both environments, or if
most users are working in one environment while most of the content is in the other environment.
IMPORTANT
If you have some on-premises content that's highly sensitive and shouldn't be indexed outside your on-premises network
due to regulatory or legal or geopolitical constraints, there are several approaches to achieve this such as using crawler
exclusion rules or a separate Search service application for that content.
Where do you manage hybrid federated search?

Because hybrid federated search is based on federating results from the two environments, you manage search
separately in each environment, just as you'd do without hybrid federated search set up.
How does hybrid federated search work?

The key element of hybrid federated search is the result source. You need two results sources, one provides results
from the local search index and one from the remote search index. For example, if you want to get search results
from SharePoint Online in a Search Center in SharePoint Server, you create a result source in SharePoint Server
that specifies SharePoint Online as the provider of remote search results. Learn about result sources and
federation in Plan crawling and federation in SharePoint Server and in Understanding result sources for search in
SharePoint Server. Configure hybrid federated search from SharePoint Server to SharePoint Online - roadmap.
See also
Concepts
Configure hybrid federated search from SharePoint Server to SharePoint Online - roadmap
Configure hybrid federated search from SharePoint Online to SharePoint Server - roadmap
Other Resources
What is the Hybrid Picker?

Hybrid Picker is a wizard that can be downloaded to your SharePoint Server from Office 365. The wizard helps
automate certain configuration steps needed to connect your on-premises SharePoint Server environment with
SharePoint Online in Office 365. The Hybrid Picker wizard is your assistant, designed to do some of the work for
you.
Use the Hybrid Picker wizard to redirect OneDrive for Business to SharePoint Online, leverage hybrid site features
or app launcher, and add some extra integration between on-premises SharePoint Server and an extranet site
made in Office 365. Hybrid Picker also creates a Server-to-Server (S2S )/OAuth connection for your SharePoint
Hybrid features.
Using the Hybrid Picker

First, you need to make sure you meet the prerequisites in your SharePoint Server on-premises farm, then you
can run the Hybrid Picker wizard.
Prerequisites to run the Picker
The Picker requires the .NET Framework 4.6.2 in order to run.
The following are the account requirements to run the Hybrid Picker. You must be:
A member of the Farm Administrators group
A service application administrator (Full Control) for the User Profile Service
An Office 365 Global Administrator
Logged into Office 365 and SharePoint Server from a server in your SharePoint Server farm
Able to launch the Hybrid Picker as a Farm Administrator with elevated permissions
The account that you use must not use multi-factor authentication.
IMPORTANT
The Hybrid Picker wizard must be launched from an on-premises server with SharePoint Server 2013 or SharePoint Server
2016 installed. Launch it in the environment you want to use for your SharePoint hybrid.
SharePoint hybrid features offered in the Hybrid Picker

Use the Hybrid Picker to either configure, or assist with the configuration of, hybrids that connect Office 365 and
your on-premises SharePoint environment.
The Hybrid picker helps with or completes the setup of these hybrid features:
Hybrid OneDrive - Choosing this option will redirect on-premises My Sites/OneDrive for Business sites
to SharePoint Online OneDrive for Business in Office 365. Once the wizard completes, any click of the
OneDrive link from on-premises will redirect to OneDrive for Business in the cloud. Your redirection will be
complete and users can begin to migrate any files to their online OneDrive. This option also sets up hybrid
user profiles. When users click to view a profile, they will be redirected to the profile in Office 365.
Hybrid Sites Features - Choosing this option sets up hybrid sites features, a suite of site integration
features, as well as OneDrive for Business redirection. Clicking this option configures hybrid OneDrive for
Business and hybrid user profiles, hybrid site following, and the hybrid app launcher.
Hybrid App Launcher - This hybrid feature further integrates Office 365 with your on-premises
SharePoint server farm by placing tiles like Office 365 Delve and Video (as well as custom Office 365 tiles
you may have) on the on-premises SharePoint Server App Launcher. This option also sets up hybrid
OneDrive for Business with user profile redirection, and sites features.
Business-to-business (B2B ) extranet sites - Choosing this option will install extra features you can
integrate with an extranet site you create in Office 365. With Office 365 extranet, partners can connect
directly to a members-only site in Office 365 without access to the corporate on-premises environment or
any other Office 365 site. Choosing this option sets up OneDrive for Business and user profile redirection,
sites features, and hybrid app launcher.
**Hybrid auditing (SharePoint Server 2016 only) ** - This feature lets on-premises SharePoint Server 2016
administrators upload on-premises user activity logs to the Office 365Compliance Center. Administrators
will be able to view user activities via Audit Log search from the Office 365 Compliance Center. No
additional hybrid features will be set up with this option.
Hybrid Taxonomy - This feature allows a centralized taxonomy that's readable and writable in the Office
365 Cloud, to be used as a read-only copy on-premises. This feature includes Hybrid Content type (June
2017 PU required) which will replicate the published content types in Office 365 to on-premises. Choosing
this option sets up OneDrive for Business and user profile redirection, sites features, and hybrid app
launcher.
**Hybrid self-service site creation ** - This feature redirects the default self-service site creation page in
SharePoint Server 2013 (/_layouts/15/scsignup.aspx) or SharePoint Server 2016
(/_layouts/16/scsignup.aspx) to the SharePoint Online Group Creation page. This setting can be configured
independently for each web application in your farm. It helps your users create their sites in SharePoint
Online instead of SharePoint Server.
Cloud hybrid search - Choosing this option creates a cloud Search service application in SharePoint
Server and connects the cloud Search service application to your Office 365 tenant. This is one of the steps
needed to set up cloud hybrid search, you must do the rest of the steps yourself (see the roadmap). This
option doesn't include set-up of other hybrid features..
TIP
If the Hybrid Picker is run a second time with an enabled feature unchecked, this will not cause the feature to be uninstalled.
Any additional selections will be installed and previously installed features will remain.
For all options, the hybrid picker configures a server-to-server trust between your SharePoint Server farm and
Office 365.
Note that the hybrid picker does not uninstall features. If you run the hybrid picker and deselect a feature that you
previously installed, it will remain installed.
To get started configuring hybrid features for your environment, choose from the following:
Hybrid Picker Prerequisite Checking

While running the Hybrid Picker, the wizard will check basic SharePoint farm settings that would otherwise block
setup of essential hybrid building-blocks (such as OAuth/S2S Trust). This is why you should launch the Hybrid
Picker from a server that will be part of your SharePoint hybrid. Some of the settings that are detected and
checked while the configuration is run, include whether the:
SharePoint Server farm exists
Account is a farm administrator
SharePoint farm is a version that can function in a hybrid configuration
AppMangementServiceInstance is online
AppMangementServiceApplication is online
AppMangementServiceApplicationProxy is online
UserProfileApplicationProxy is online
The SPO365LinkSettings cmdlet (used to set the MySiteHostURL ) is accessible on the server
The results of this testing can be viewed as a report if any prerequisite isn't met. If all prerequisites are met you
will see green check-marks beside all the prerequisites, and will be able to continue your hybrid configuration.
Authentication realm update

As part of hybrid configuration, the hybrid picker updates the on-premises farm's authentication realm to match
the Office 365 tenant context ID. After the authentication realm is changed, existing SharePoint add-ins fail to
authenticate. The hybrid picker will attempt to fix this issue automatically. If the hybrid picker is not able to fix this
issue or if you choose to fix it manually, follow the steps in Fix the HTTP 401 error with provider-hosted add-ins
and issues with workflow and cross farm trust scenarios in SharePoint.
See also
Other Resources
You receive the error "Value cannot be null. Parameter name: My site URL or team site URL from Discovery
Service is null or empty" when you use the SharePoint Hybrid Picker

After you have determined which hybrid solution is right for you, follow the associated planning article below to
guide you through the planning and organization process.
CONTENT DESCRIPTION
Plan hybrid SharePoint taxonomy and hybrid content types Learn about how hybrid taxonomy and content types give
you a single taxonomy and set of content types that you can
share between SharePoint Server and SharePoint Online.
Plan hybrid OneDrive for Business Use this article to plan for using OneDrive for Business in
SharePoint Online for your users' personal storage.
Plan cloud hybrid search for SharePoint Learn how to plan for cloud hybrid search.
Plan hybrid profiles Learn about hybrid profiles and your options for tying in
external profile information.
The extensible hybrid app launcher Learn how the hybrid extensible app launcher can bring Office
365 tiles to SharePoint Server.
Hybrid site following Learn how hybrid site following give you a single followed
sites list for SharePoint Server and SharePoint Online.
Plan server-to-server authentication Use this article to plan for server-to-server authentication,
which is required for all hybrid scenarios except hybrid
OneDrive for Business.
Plan hybrid federated search for SharePoint Server Learn how to plan for hybrid federated search in SharePoint
Server.
Plan connectivity from Office 365 to SharePoint Server Learn how to plan for connectivity from SharePoint Online to
SharePoint Server through a reverse proxy device.
Plan hybrid SharePoint taxonomy and hybrid
content types

SharePoint hybrid taxonomy enables you to have a single taxonomy that spans SharePoint Server and
SharePoint Online. This gives you a single, consistent taxonomy no matter where your sites are located.
You can choose which term groups are shared between SharePoint Server and SharePoint Online and which are
on-premises only or online only.
The shared taxonomy is mastered inSharePoint Online and a read-only copy is kept updated in SharePoint
Server. Shared terms, term sets, and groups are available in both locations.
IMPORTANT
Farm Administrators can modify Term Groups on-premises. These changes will not replicate to SharePoint Online. It is
important that Farm Administrators be notified to not make changes on-premises.
You also have the option of installing hybrid content types. This feature propagates updates to your SharePoint
Online content types to your SharePoint Server site collections.
Prerequisites
Hybrid SharePoint taxonomy and hybrid content types are available in SharePoint Server 2013 and SharePoint
Server 2016 with the following SharePoint updates:
Hybrid taxonomy requires the November 2016 public update or later.
Hybrid content types requires the June 2017 public update or later.
Configuration of both features uses the Hybrid Picker in the SharePoint Online admin center, which also has a
number of prerequisites. Be sure to read Hybrid picker in the SharePoint Online admin center as you plan your
hybrid SharePoint taxonomy rollout.
The functionality and configuration procedures are the same for both versions of SharePoint Server.
As with all hybrid scenarios, hybrid SharePoint taxonomy and hybrid content types both rely on your user
accounts being synchronized between SharePoint Server and SharePoint Online, though users whose accounts
are not synchronized can still use the replicated and local term sets on-premises.
How hybrid SharePoint taxonomy works

Hybrid SharePoint taxonomy works by replicating changes that you make to your taxonomy in SharePoint
Online to your term store in SharePoint Server. Replication is done at the term group level. Groups that are
replicated via hybrid SharePoint taxonomy are set to read-only in SharePoint Server and can only be updated in
SharePoint Online. (A term store administrator can still update the SharePoint Server groups, but such updates
will be overwritten during the next replication.)
You choose the groups that you want to share across SharePoint Server and SharePoint Online. System and
special groups (the System, Search, SearchDirectories, and People groups) cannot be replicated, but any other
groups that you create can be. (Be sure you're not reusing terms between groups that you replicate and groups
that you don't replicate.)
The Taxonomy Groups Replication SharePoint Server timer job polls SharePoint Online for taxonomy changes
on a daily basis and replicates them to the SharePoint Server taxonomy store. This timer job performs a daily
update of changes and a weekly full replication. You can reschedule the timer job to meet your needs or run it
manually when you want to force an update.
On-premises taxonomy
If you already have a taxonomy in SharePoint Server, you can copy it to SharePoint Online by using PowerShell.
This allows you to create your master taxonomy from your existing SharePoint Server and SharePoint Online
taxonomies, while maintaining the IDs of the terms, term sets, and term groups in those taxonomies.
We recommend that you copy your taxonomy to SharePoint Online before you set up hybrid SharePoint
taxonomy. You can do so at a later time, but you'll have to rerun the Hybrid Picker configuration wizard in order
to turn on replication for those groups.
Local term sets
You can continue to work with local term sets in both locations. They remain local and are not affected by hybrid
SharePoint taxonomy. These local site-specific terms cannot be replicated.
How hybrid content types work

If you already have content types in SharePoint Server, you can copy them to SharePoint Online by using
PowerShell. This allows you to create your master content types list from your existing SharePoint Server and
SharePoint Online content types. You control which content types are shared across SharePoint Online and
SharePoint Server.
We recommend that you copy your content types to SharePoint Online before you set up hybrid content types.
Get set up
To get started configuring hybrid SharePoint taxonomy and hybrid content types, be sure you've reviewed the
prerequisites for the Hybrid Picker, and then read Configure hybrid SharePoint taxonomy and hybrid content
types.
See also
Other Resources
TechNet Forums - Hybrid Taxonomy

In SharePoint Server, you can redirect users to OneDrive for Business in Office 365 when they choose OneDrive
in the navigation bar (SharePoint Server 2010 and SharePoint Server 2013) or in the app launcher (SharePoint
Server 2016). This is known as hybrid OneDrive for Business.
With this feature, you can continue to use your on-premises SharePoint farm while providing your users with an
easy way to store, share, and collaborate in the cloud with OneDrive for Business in Office 365. This best-of-
both-worlds approach lets you keep your key business information in your own environment while allowing
users the flexibility to access their documents from anywhere.
How it works
With hybrid OneDrive for Business your users can:
Store personal files they are working on in the cloud, and access these files even when they aren't signed
in to your corporate network.
Access these files on devices such as iPhones, Windows Phones, tablets, and so on.
Share and collaborate on documents with others in your organization or with external users by using
guest links.
As an IT pro, you can:
Provide cloud storage for your users.
Add storage for your users in the cloud in 25-100 gigabytes (GB ) increments, as needed.
Continue to provide SharePoint features as usual in your on-premises farm.
Things to keep in mind
To avoid user confusion, keep the following in mind when you turn on hybrid OneDrive for Business:
When you turn on this feature, your users will be directed to OneDrive for Business in Office 365 when
they click OneDrive in SharePoint Server. Be sure to plan to migrate your users' content from their old
SharePoint Server OneDrive for Business to the new one in Office 365.
Because there's no direct link between OneDrive for Business in SharePoint Server and OneDrive for
Business in Office 365, users' Shared with me lists in Office 365 won't display documents that have been
shared with them from on-premises SharePoint Server.
Getting started
In SharePoint Server 2013 and SharePoint Server 2016, hybrid OneDrive for Business is available as part of
several hybrid option bundles. See Hybrid sites features and OneDrive for Business for details.
Hybrid OneDrive for Business is also available with SharePoint Server 2010. See Configure hybrid OneDrive for
Business in SharePoint Server 2010 for details.

Setting up cloud hybrid search for SharePoint requires careful planning. This article helps you design a highly
reliable, secure and scalable cloud hybrid search solution.
What search experiences do your users need?

When you've set up cloud hybrid search and a full crawl of the on-premises content has completed, the Search
Center in Office 365 automatically displays hybrid results from your Office 365 index.
Do your users need other types of search?
Search verticals - Search verticals narrow search results to a specific set of content, for example to show only
videos. If you currently use a search vertical in a Search Center in SharePoint Server, you have to recreate it in
your Search Center in SharePoint Online in Office 365.
Site search - Your existing search in document libraries in SharePoint Server stops returning results when you
move your search index to Office 365. Search is fastest when users use Search Centers that are in the same
environment as the search index, so searching from an Office 365 Search Center gives a better experience. If your
users need results from the Office 365 search index in on-premises SharePoint sites, such as in existing Team Sites
in SharePoint Server 2010, you can set up search from SharePoint Server 2013 or SharePoint Server 2016. Plan a
remote result source in SharePoint Server 2013 or SharePoint Server 2016 that gets results from the Office 365
search index and plan use of query federation. Because SharePoint Online in Office 365 processes your queries,
your users have to use the query syntax that SharePoint Online supports. Learn more in Show results from Office
365 in on-premises SharePoint with cloud hybrid search.
eDiscovery - You might have to set up eDiscovery separately in SharePoint Server and in SharePoint Online in
Office 365.
Cross-site publishing - Cross-site publishing isn't available with cloud hybrid search.
How do you want to display search results?
Previews - When a user hovers over a search result that comes from Office 365, information about the content as
well as a preview of the content is displayed. Information about the content from search results that come from
on-premises is displayed automatically, but you have to set up display of previews for this content. Plan an Office
Web Apps Server farm and configure SharePoint Server 2013 to use Office Web Apps Server. Learn how in Show
results from Office 365 in on-premises SharePoint with cloud hybrid search.
Custom security trimming - SharePoint Online in Office 365 doesn't support custom security trimming.
Which search features do you need?
Some of the search features you might be familiar with from SharePoint Server work differently with cloud hybrid
search. Plan to inform your users about the differences.
Best bets - Best bets is a SharePoint Server 2010 feature. Use query rules in SharePoint Online in Office 365
instead.
Custom search scopes - Custom search scopes is a SharePoint Server 2010 feature. Use result sources in
SharePoint Online in Office 365 instead.
Promotion/demotion of search results - Promotion/demotion of search results is a SharePoint Server 2010
feature. Use result sources in SharePoint Online in Office 365 instead.
Removal of on-premises search results - In Central Administration in SharePoint Server you can select a
Search service application and use the option "Index reset" to remove all items from the search index. Don't use
this option for a cloud Search service application, the option deletes the crawl history from the crawl databases,
but doesn't remove on-premises items from the Office 365 index because there is no direct communication
between the cloud Search service application in SharePoint Server and the search index in Office 365. These on-
premises items become orphans in the Office 365 index. If you want to remove all on-premises metadata from the
Office 365 search index, remove all the on-premises content sources. Any on-premises items left in the Office 365
search index after the process has completed, are orphan items.
Some of the search features you might be familiar with from SharePoint Server aren't available with cloud hybrid
search. Plan to inform your users.
Multi-tenancy on SharePoint Server 2013 or SharePoint Server 2016 farm - A SharePoint Server 2013
orSharePoint Server 2016 farm can only attach to one tenant in SharePoint Online in Office 365, therefore
SharePoint Online can't preserve the tenant isolation of a multi-tenant SharePoint Server 2013 or SharePoint
Server 2016 farm.
Custom entity extraction - Custom entity extraction isn't available with cloud hybrid search because SharePoint
Online in Office 365 doesn't support custom entity extraction.
Content enrichment web service - The content enrichment web service call-out is not available with cloud
hybrid search because SharePoint Online in Office 365 doesn't support custom entity extraction.
Thesaurus - Thesauruses aren't available with cloud hybrid search because SharePoint Online in Office 365
doesn't support thesauruses.
Plan your search architecture in SharePoint Server for cloud hybrid

search
When you set up cloud hybrid search, one of the steps is to create a cloud Search service application (cloud SSA)
on your SharePoint Server 2013 orSharePoint Server 2016 search farm. When you create this cloud SSA, a
default search architecture is created for you on the server running the cloud SSA. Each search farm can have only
one cloud SSA, but can have multiple SSAs in combination with the cloud SSA.
A search architecture for cloud hybrid search consists of search components and databases that form a topology,
and servers that host that topology. You need to plan the number of crawl components for your topology, which
servers to host the search components and databases on, and the hardware required for each server.
Before you get going, you should read Learn about the search topology for cloud hybrid search to familiarize
yourself with the search components in a search architecture for cloud hybrid search.
Step 1: How much on-premises content can I index in Office 365?
For each 1 TB of pooled storage space your tenant has in SharePoint Online, you can index 1 million items of on-
premises content in the search index in Office 365. You can purchase more space to increase your quota, until it
reaches the threshold of 20 million items. If you need to index more than 20 million items of on-premises content,
contact Microsoft Support to increase this threshold.
Step 2: What size cloud search architecture do I need?
For cloud hybrid search we recommend using the default search architecture that you get when you create a cloud
SSA:
The grey components are inactive in cloud hybrid search, but they still need to be placed on servers as shown.
Read about inactive components in Learn about the search topology for cloud hybrid search.
Just as for on-premises only enterprise search, you can scale your search architecture. The main difference is that
for cloud hybrid search it's only relevant to scale the crawl component. If you need to tune crawling, follow the
guidance for crawling in Redesign enterprise search topology for specific performance requirements in SharePoint
2016 (the guidance for crawling also applies to cloud hybrid search). Note that if you crawl on-premises content at
a high rate, the system might throttle feeding to the Office 365 search index to protect the Office 365 tenancy. If
your search architecture has up to two crawl components, this should result in a sufficient and acceptable crawl
rate.
Step 3: What hardware requirements should I be aware of for cloud search architecture?
Choose to run servers physically or virtually for cloud hybrid search
We recommend a search architecture that uses virtual machines, but you can also use physical machines. Learn
more in Choose to run servers physically or virtually .
Choose hardware resources for the host servers for cloud hybrid search
needs:
SERVER ON HOST STORAGE RAM PROCESSOR 1
Application server A 100 GB 16 GB 1.8 GHz 4x CPU cores
Database server B 100 GB 16 GB 1.8 GHz 4x CPU cores
In addition to the above:
Make sure that each host server has enough disk space for the base installation of the Windows Server
operating system and for the SharePoint Server program files. The host server also needs free hard disk
space for diagnostics such as logging, debugging, and creating memory dumps, for daily operations, and
for the page file. Normally, 80 GB of disk space is enough for the Windows Server operating system and
for the SharePoint Server program files.
Add storage for the SQL log space for each database server. If you don't set the database server to back up
the databases often, the SQL log space uses lots of storage. For more information about how to plan SQL
databases, see Storage and SQL Server capacity planning and configuration (SharePoint Server).
Plan storage performance for cloud hybrid search
The way you decide to distribute data from the search components and from the operating system across your
storage, has an impact on search performance. It's a good idea to:
Split the Windows Server operating system files, the SharePoint Server program files, and diagnostics logs
Store the search component data on a separate storage volume or partition with high performance.
TIP
component on the host that needs to store data, stores it in this location. To change this location later, you have to reinstall
SharePoint Server on that host.
Make sure that the storage you have is fast enough to handle the traffic from the search components and
databases. The crawl database is the only component in the search architecture for cloud hybrid search with IOPS
requirements. The crawl database requires medium to high IOPS, and the typical load on a I/O subsystem is 10
IOPS per 1 document per second (DPS ) crawl rate.
Learn about the search topology for cloud hybrid search
The search topology of the cloud SSA consists of the same types of search components and databases as the
search topology of a standard SSA in SharePoint Server 2013 or SharePoint Server 2016. But there are some
differences.
Unused search components and databases in cloud hybrid search - In cloud hybrid search, it's Office 365
that processes the content, stores the index, and processes analytics. The cloud SSA doesn't use its own content
processing component, index component, analytics processing component, links database, or analytics database.
These components and databases are idle.
Interaction between search components and databases in cloud hybrid search - Search components and
databases interact differently in the search topology of the cloud SSA compared to the search topology of a
standard SSA:
1. The crawl component gets content from your on-premises farm and sends this content to the search index
in Office 365. It uses connectors to interact with the content sources, and uses the crawl database to store
both temporary and historical information about the items it crawls, just like a regular crawl component.
2. The search administration component runs system processes that are essential to search, just as for a
standard SSA.
3. We recommend running all searches from Office 365, as cloud hybrid search is optimized for this. But, you
can set up site search in SharePoint Server to get search results from your search index in Office 365. If you
set up search in an on-premises site collection to query your Office 365 index, this query processing
component passes queries from the search box to the Office 365 index, and results from the Office 365
index to the search box.
Decide how to manage crawling of your on-premises content

You can influence crawl performance and search freshness by how you manage crawls, such as by using content
sources effectively, scheduling crawls, and crawl rules. The guidance for managing crawling for on-premises only
search also applies to cloud hybrid search, see Best practices for crawling in SharePoint Server.
Decide how to synchronize Active Directories

When your on-premises content is crawled, parsed and encrypted, the access control lists (ACLs) for each item are
crawled too. The Office 365 search index stores the ACLs together with the item, so the system needs to be able to
recognize an on-premises user as the same person in Office 365. When you've set up Active Directory
synchronization between your on-premises network (Windows Server Active Directory) and your Office 365
tenant (Windows Azure Active Directory), the system maps and translates the ACLs to the right users, and the
users get security trimmed search results from the Office 365 index.
There are two methods to synchronize Active Directories:
Directory synchronization with password synchronization
Directory synchronization with single sign-on (SSO )
If you choose the SSO option, you can also configure password synchronization if you want to as a backup for
SSO, but you must configure at least one of the two (password synchronization or SSO ). Learn more and how to
configure the two methods in Office 365 integration with on-premises environments.
Why can't users get hybrid results with cloud hybrid search when they're members of the Domain Users security
group?
Some organizations assign access rights to their on-premises content by using one of the default security groups
in Windows Server Active Directory (AD ), for example the Domain Users security group.
The Azure Active Directory Connect synchronization tool by default excludes some objects from synchronization.
Security groups that have the attribute IsCriticalSecurityObject=true is one set of objects that the tool excludes,
and Domain Users is an example of such a security group. Therefore, the access rights for the members of
Domain Users aren't available in Azure Active Directory (AAD ). Even if users have access to on-premises content,
they don't get search results when they search for that content.
Instead, assign access rights by using a group that doesn't have IsCriticalSecurityObject=true, for example the
Everyone group, the Authenticated Users group, or a custom group. For a list of the conditions for excluding
objects and more information about unexpected synchronization results, see One or more objects don't sync when
using the Azure Active Directory Sync tool.
Does your organization have on-premises content that's sensitive?

Some organizations have on-premises content that's considered sensitive because of regulatory, legal, or
geopolitical constraints. In some cases, it's prohibited to add metadata from sensitive on-premises content to the
Office 365 search index. In other cases, metadata from sensitive on-premises content can be added to the Office
365 search index, but only a limited number of users are allowed to open search results from the sensitive content.
Here are two examples of how you could set up hybrid search to comply with these constraints:
When metadata from sensitive, on-premises content is allowed in the Office 365 index
Set up and cloud hybrid search and carefully plan access rights to the sensitive content so only the right users get
access to the sensitive content when they select a search result.
When metadata from sensitive, on-premises content isn't allowed in the Office 365 index
Set up cloud hybrid search in combination with hybrid federated search.
Plan content sources for the cloud Search service application (cloud SSA) in SharePoint Server that cover
all on-premises content except the sensitive content. The metadata for the crawled content is added the
search index in Office 365.
Plan enterprise search in SharePoint Server to crawl the sensitive, on-premises content, see Plan search in
SharePoint Server. Plan content sources for the SSA that cover the sensitive content. The metadata from
the crawled, sensitive content is added to the search index in SharePoint Server.
If your users need results from the Office 365 search index in on-premises SharePoint sites, plan hybrid
federated search from SharePoint Server to display search results from the search index in SharePoint
Server and from the search index in Office 365, see Plan hybrid federated search for SharePoint Server.
Plan to validate cloud hybrid search before exposing it to your users

After you've created and set up the cloud SSA and completed a full crawl, your Office 365 Search Center shows
both on-premises and online search results. We recommend that you validate and tune the new search experience
in a separate Search Center, while keeping the original search experience unchanged.
Plan for a custom result source that limits your Search Centers in Office 365 to only show Office 365 content. The
following illustration shows an environment where you can validate and tune how your hybrid search results are
shown:
1. On-premises content. During crawl, metadata from this content is added to the Office 365 search index.
2. Office 365 content. During crawl, metadata from this content is added to the Office 365 search index.
3. Default (or existing) Office 365 Search Center. You create a custom result source for this Search Center,
which limits search results to show only Office 365 content. .
4. New Office 365 Search Center, where you validate and tune how hybrid search results are shown. This
Search Center uses the default result source and shows search results from both on-premises and Office
365 content. You set up access so only testers and administrators have access to this site.
NOTE
Although you can keep the original search experience unchanged while tuning, you can't keep the original Office Delve
experience unchanged. When metadata from on-premises content is in the Office 365 search index, Delve will display this
content.
Related Topics

When you have both SharePoint Server and Office 365, by default users have a different profile in each location.
This can lead to a confusing profile experience for your users. With hybrid profiles, user have a single profile in
Office 365 where they can maintain all of their profile information.
If Office Delve is part of your Office 365 tenant, user profiles will be integrated with Delve and users can discover
information and documents and see what their teammates are working on. If you've deployed cloud hybrid
search, users can also find on-premises documents through Delve.
Profile redirection in SharePoint hybrid deployments

Hybrid profiles redirects hybrid users to their profiles in Office 365. This ensures that hybrid users have a single
place for their profile information. Hybrid profiles is available with both SharePoint Server 2013 and SharePoint
Server 2016.
Profile redirection works as follows:
Profiles for all hybrid users are in Office 365. Clicking a hybrid user's profile in SharePoint Server redirects
you to their profile in Office 365 (even if you're not a hybrid user yourself).
If you choose to use a SharePoint audience when you configure hybrid sites features, non-hybrid users
(those not in the audience) retain their SharePoint Server profiles, and they also have profiles in Office 365
if they are licensed Office 365 users.
Moving custom profile properties to Office 365

Many enterprises have business requirements to replicate custom attributes to the SharePoint Online user profile
service. Some user attributes are synchronized from Active Directory Domain Services to Azure Active Directory.
You can select which attributes are replicated from Active Directory Directory Services to Azure Active Directory.
However, a standard set of attributes are replicated from Azure Active Directory to the SharePoint Online user
profile store in Office 365. This set of attributes cannot be customized like it can in SharePoint Server.
Where in SharePoint Server you might use Business Connectivity Services or Microsoft Identity Manager to
import custom profile properties that are not located in Active Directory Directory Services, SharePoint Online
does not support these solutions. For custom properties in SharePoint Online, a user profile bulk update API is
available.
The bulk update process works like this:
1. You compile the needed profile data from SharePoint Server, your line-of-business system, or any other
external system, into a JSON formatted file.
2. The tool uploads the JSON file to Office 365 and queues an import process.
3. A timer job running in SharePoint Online checks for queued import requests and performs the import
operation based on the API calls and information in the provided file.
For more information about the bulk update API, see Introducing Bulk UPA Custom Profile Properties Update
API for SharePoint Online.
Working with Delve in SharePoint hybrid deployments
If Delve is part of your Office 365 tenant, user profiles will be integrated with Delve, otherwise you'll have
standard Office 365 profiles. If you haven't used Delve before, you'll want to learn more about it and how to
administer it. Delve user profiles contain the same properties as SharePoint Online profiles and can be imported
in the same manner, as described above in Moving custom profile properties to Office 365.
Setting up hybrid profiles

Hybrid profiles is part of several hybrid feature bundles for SharePoint Server. For details, see Hybrid sites
features and OneDrive for Business.
See also
Other Resources
About user profiles in SharePoint Online

The extensible hybrid app launcher helps users to have a more seamless experience when navigating between
SharePoint Server and Office 365.
What does it do?

The extensible hybrid app launcher is designed to help you get to your Office 365 apps and services from
SharePoint Server. Once you enable this feature, you'll see the Office 365 Delve and Video apps, along with your
custom Office 365 tiles, appear in your SharePoint Server app launcher.
How do I customize tiles in my app launcher?

Custom tiles that you've pinned to your Office 365 app launcher will also appear in your SharePoint Server app
launcher.
If you want to change what you see in your SharePoint Server app launcher, make the change in the Office 365
app launcher, and the changes will be reflected in the SharePoint Server app launcher within a day or so.
(You can also customize your SharePoint Server 2016 app launcher separately.)
How can I enable this feature?

In SharePoint Server 2016, this feature is enabled as part of Hybrid Sites Features. See Hybrid sites features and
OneDrive for Business for details.
In SharePoint Server 2013, this feature is enabled using Windows PowerShell. It requires the July 2016 PU for
SharePoint Server 2013. See the hybrid sites features roadmap for details.

When a user follows a site, a link to that site is added to the user's Followed Sites list. If you're using both
SharePoint Server and SharePoint Online, your users will have different followed lists for sites in each location.
With SharePoint hybrid, you can consolidate the information from both locations into the SharePoint Online list
in Office 365.
How hybrid site following works

When you enable hybrid site following:
The Sites link in a SharePoint Server site is redirected to Office 365 (SharePoint Server 2013).
The Sites tile in the app launcher is redirected to Office 365 (SharePoint Server 2016).
When a user follows a site in SharePoint Server, it is added to the followed list in both SharePoint Server
and Office 365.
While the SharePoint Server followed list continues to be updated, users are directed to the followed list in Office
365, which contains followed sites from both locations.
The SharePoint newsfeed functionality is unaffected. Users will continue to have separate newsfeeds in
SharePoint Server and Office 365, and each will show activities for sites and documents for SharePoint Server
and Office 365, respectively. Also, follow documents functionality remains unaffected, and follow people
functionality remains in SharePoint Server only.
Note that existing followed sites lists in SharePoint Server are not migrated to Office 365 when you turn this
feature on (though any sites in the Office 365 list will remain there). Users will have to follow their SharePoint
Server sites again once the feature is turned on.
Setting up hybrid site following

Hybrid site following is part of Hybrid Sites Features, and is available on both SharePoint Server 2013 and
SharePoint Server 2016. See Hybrid sites features and OneDrive for Business for information about the other
features included with Hybrid Sites Features.

Server-to-server authentication enables your SharePoint Server farm to consume content and resources from
your Office 365 tenant. For example, search can be configured to allow federated users to see both SharePoint
Server and SharePoint Online search results in a SharePoint Server search portal.
The major thing that you need to plan for when configuring server-to-server authentication between SharePoint
Server and Office 365 is your web application configuration.
Plan your web application configuration for hybrid server-to-server

authentication
This section helps you plan how to configure your SharePoint Server web application to support hybrid
functionality.
Outbound requests to SharePoint Online can be made from any web application in the on-premises SharePoint
farm that uses Integrated Windows authentication using NTLM, as shown in the following image.
If your existing web application is not configured to use Integrated Windows authentication using NTLM, you
must either create a web application or extend your existing web application and configure it to use Integrated
Windows authentication using NTLM.
If you have to create a new web application to configure for hybrid functionality, you have two choices:
Extend an existing web application to connect to an existing content database. This creates a new
website in Internet Information Services (IIS ) with a unique URL and authentication configuration. The
extended web application can be used to access the same site collections and content as the original web
application by using the new URL.
This is the best choice if you want users to go to an enterprise search portal in an existing site collection to
use hybrid search.
Create a new web application and a new content database. This creates a new web application that
has a new, empty content database in which you can create a new site collection with an enterprise search
portal.
This is the best choice if you want users to go to an enterprise search portal in a new site collection to use
hybrid search.
Integrated Windows authentication using NTLM is required to allow the SharePoint Authentication service to pass
user claims to SharePoint Online using OAuth.

A SharePoint hybrid environment enables you to provide hybrid solutions that integrate functionality and data
access between services and features of SharePoint Online in Office 365 and SharePoint Server. With SharePoint
hybrid federated search, user searches from a Search Center display hybrid results—that is, results from both the
SharePoint Server 2013 and SharePoint Online search indexes.
Options for displaying hybrid federated search solutions

You can set up SharePoint hybrid federated search so that it works in either or both of the following two ways:
User searches from the SharePoint Server Search Center display hybrid results. This is called outbound
hybrid search. For information about how to set up outbound hybrid search, see Display hybrid federated
search results in SharePoint Server
User searches from the SharePoint Online Search Center display hybrid results. This is called inbound
hybrid search. For information about how to set up inbound hybrid search, see Display hybrid federated
search results in SharePoint Online
You can set up either search option first, and then optionally also set up the other one at any time.
Watch a video about some of the main concepts behind hybrid SharePoint Search. (Length: 9 minutes
20 seconds)
Choosing an option for displaying hybrid federated search

How do you decide whether to set up hybrid federated search in the SharePoint Server farm (outbound hybrid
search), or in SharePoint Online (inbound hybrid search), or both? That can depend in part on which deployment
users are working in, what content they will need, and where that content is stored.
Outbound hybrid search is generally simplest hybrid federated search solution to configure, primarily because it
doesn't require configuration of a reverse proxy device. It is also generally the safest hybrid federated search
solution because, unlike inbound hybrid search, it doesn't involve receiving unsolicited calls from the Internet.
For the convenience of users, it can be beneficial to set up hybrid federated search in the deployment where most
users are working. That way, users don't have to go to the remote deployment to search for content.
For performance reasons, it can be beneficial to set up hybrid federated search in the deployment where most of
the content is stored. If most of the search results are from the local deployment, the overall query latency is likely
to be less (all other things being equal) than if many results are from the remote deployment. Also, in general,
when a user clicks a search result for local content, the response time to open that content will be faster than it
would be to open content that is stored remotely. This is especially true for large files.
It can be reasonable to set up hybrid federated search in both deployments under any of the following
circumstances:
Many users are working in one deployment and many other users are working in the other deployment.
Much of the content is in one deployment and much is in the other deployment.
Most users are working in one deployment and most of the content is in the other deployment.
IMPORTANT
If there is content in SharePoint Server that you don't want users of SharePoint Online to be able to view due to regulatory
or legal or geopolitical constraints, then you should not set up any hybrid federated search in SharePoint Online that could
return results that include that SharePoint Server content. For more information, see Delete items from the search index or
from search results in SharePoint Server.
Prerequisites for hybrid federated search

This section covers the phases of the hybrid deployment process that you have to complete before you perform
each of the possible SharePoint hybrid federated search configurations.
In this section:
Prerequisites for outbound hybrid search
Prerequisites for inbound hybrid search
Prerequisites for outbound hybrid search
Before you can configure SharePoint Server to display hybrid federated search results, you have to complete all
the steps in the Configure hybrid federated search from SharePoint Server to SharePoint Online - roadmap. You
must also do the following:
Perform at least one crawl in the SharePoint Server deployment, so that there is content in the SharePoint
Server search index. (The SharePoint Online content must also be crawled, but you don't have to attend to
that because SharePoint Online crawls its content automatically.) For more information, see Manage
crawling in SharePoint Server.
Create an enterprise Search Center in the SharePoint Server deployment by using the Enterprise Search
Center template to create a new site collection. For more information, see Create a Search Center site in
SharePoint Server.
Prerequisites for inbound hybrid search
Before you can configure SharePoint Online to display hybrid federated search results, you have to complete all
the steps in the Configure hybrid federated search from SharePoint Online to SharePoint Server - roadmap.
In addition, you have to perform at least one crawl in the SharePoint Server deployment, so that there is content
in the SharePoint Server search index. (The SharePoint Online content must also be crawled, but you don't have
to attend to that because SharePoint Online crawls its content automatically.) For more information, see Manage
crawling in SharePoint Server.
Planning considerations for hybrid federated search

In this section:
Benchmark local search performance before you deploy hybrid federated search
Plan where to create the result source and query rule
Plan where to display the result block from the remote deployment
Consider providing hybrid federated search results only for certain searches
Train users how to get around in the SharePoint hybrid environment
Benchmark local search performance before you deploy hybrid federated search
Before you deploy hybrid federated search, we strongly recommend that you test local search in whichever
deployments you plan to deploy hybrid federated search, such as in SharePoint Online or in SharePoint Server. At
that time, troubleshoot any issues that arise that are related to local search, until you have local search working
smoothly. That way, if search-related issues arise after you deploy hybrid federated search, you might have a
better idea whether those issues might be attributable to hybrid federated search.
For example, in hybrid federated search, search results from the two deployments are displayed synchronously,
which means that no results are displayed until results from both deployments are available. For this reason, if
there is significant query latency, it is not likely to be immediately evident whether getting results from one
deployment or the other is causing the lag. Therefore, before you deploy hybrid federated search, test local search
performance to determine benchmarks for query latency. You can do this by running tests that simulate the user
query load. Then try the same tests after you deploy hybrid federated search. If there is an increase in query
latency after you deploy hybrid federated search, it might be due to a delay in getting search results from the
remote deployment. The remote deployment might be slow to respond, or there might be network-related delays
caused by factors such as low network bandwidth or geographical distance between the two deployments.
Plan where to create the result source and query rule
When you configure either outbound or inbound hybrid search, there are two main steps. You perform these
steps in the deployment in which you want users to be able to get hybrid federated search results. The first step is
to create a result source, which specifies where to get remote search results from. For example, if you are
configuring outbound search, you create a result source in the SharePoint Server farm that specifies SharePoint
Online as the remote provider to get search results from. In the second step, you create a query rule. When the
query rule fires, it causes search results from content in the remote deployment to be displayed in a separate
group, called a result block, on a search results page in the local deployment.
You can create the result source and query rule at the Search service application level in SharePoint Server (or at
the tenant level in SharePoint Online), or at the site collection level, or the site level. If you create the result source
at the Search service application level, the result source will be available to any query rule that is created at the
same level, and also to any query rule that is created for a site collection or site that is in a web application that
consumes the Search service application. Also, if you create the result source and query rule at the Search service
application level, then they might be easier to keep track of, and they can generally be recovered in the case of a
disaster recovery scenario. However, the advantage of creating the result source and query rule at the site
collection level or the site level is that the administrative work of maintaining the result source and query rule is
performed at that level, so that the Search service application administrator doesn't have to attend to it.
Plan where to display the result block from the remote deployment
In the query rule that you create for hybrid federated search, you can configure the result block from the remote
deployment to be shown at the top of the first page of search results (above all of the results from the local
deployment), or to be ranked by relevance compared to the results from the local deployment. For testing and
troubleshooting, it's best to show the result block at the top of the first page of search results so that you can
readily see it. This makes it easy to verify that results from the remote deployment are being displayed in the
result block, and to verify that clicking a result does not result in an error in displaying the target of the search
result. When you're done testing and troubleshooting, you can edit the query rule so that the result block is
ranked by relevance compared to results from the local deployment. This setting that ranks the result block by
relevance compared to local search results is typically more useful for users.
Consider providing hybrid federated search results only for certain searches
The easiest way to configure hybrid federated search is to create a query rule in the local deployment that fires
and gets results from the remote deployment for any query text. As an alternative that will avoid delays in getting
search results from the remote deployment, you can construct one or more query rules that will fire and get
search results from the remote deployment only for certain searches, such as searches for which you know that
there is relevant content in the remote deployment. For example, if there is content in the remote deployment
about using a particular in-house software tool, you can specify conditions in a query rule so that the rule will fire
only if a search query contains the name of the tool. When you create a query rule, you can also narrow its scope
by specifying that the rule is only to be performed from certain categories (based on terms for topic categories in
the term store of a Managed Metadata service application), or by specifying that the rule is only to be performed
by users in certain user segments (based on terms that describe users in the term store of a Managed Metadata
service application).
Train users how to get around in the SharePoint hybrid environment
With hybrid federated search, the target of a search result might be a document or site in the remote deployment.
After a user clicks such a search result, it might be difficult for the user to know how to get back to the
deployment they were working in before or where to go to perform another search. Users can click the Back
button in the browser to return to the place they were working in before. However, it can also be helpful to share
URLs with users to let them know how to get to sites and Search Centers that they will need to use in the
SharePoint hybrid environment.
See also
Concepts
Configure hybrid federated search from SharePoint Server to SharePoint Online - roadmap
Configure hybrid federated search from SharePoint Online to SharePoint Server - roadmap
Plan connectivity from Office 365 to SharePoint
Server

This article is designed to help you plan and prepare to configure inbound connectivity from Office 365 for
enterprises to SharePoint Server through a reverse proxy device. This is required for the following hybrid
environments:
Inbound hybrid search (displaying search results from SharePoint Server in Office 365)
Hybrid Business Connectivity Services
In this article, we give you the information that you need to know, such as prerequisites, and a worksheet to
collect necessary information before you begin the configuration process.
This topic will help you do the following:
Understand the prerequisites and requirements for inbound connectivity
Plan your web application architecture
Plan SSL certificates
Record key decisions and information
Gather and record worksheet and build log information

Worksheet. During the planning process, you have to collect information and files. It is important to use the
SharePoint hybrid worksheet to track planning and deployment information for reference and to share with other
members of your deployment team. We can't stress enough the importance of using this worksheet to organize
your information before you begin the configuration process.
Create a build log. As in any complex implementation project, a detailed record of every design decision, server
configuration, procedure, command output, and error is a very important reference for troubleshooting, support,
and awareness. We highly recommend that you thoroughly document your deployment process.
Cau t i on
For security reasons, store the worksheet and the build log in a security-enhanced place, such as a secured file
share or SharePoint document library, and grant permissions only to administrators who are involved in the
deployment process and must know this information.
Collect and record URL and host name information

In this section, you record information about URLs and host names in your environment. You will use this
information during the deployment process.
Record your company's public DNS domain name (such as adventureworks.com).
Record the URL of the public-facing endpoint of the reverse proxy device that you'll use for SharePoint
hybrid. This is the External URL. If this endpoint doesn't exist yet, you'll have to decide what this URL will
be.
Record the IP address of the external endpoint of the reverse proxy device.
Ensure that an A record (also known as a host record) exists in the public DNS forward lookup zone for
your public domain that maps the External URL to the IP address of the Internet-facing endpoint on the
reverse proxy device. If you don't yet have this A record, create it now.
Ensure that an A record exists in the intranet DNS forward lookup zone that maps the host name of your
SharePoint Server farm to its IP address. If you don't yet have this A record, create it now.
IMPORTANT
If you configure internal URLs to access a web application during the deployment process, make sure that you also
create A records for those URLs in the intranet DNS forward lookup zone, and record them on the worksheet.
Record the following information in Table 3 of the SharePoint

Hybrid worksheet:
The domain name of the public-facing corporate DNS domain
in the Public Internet Domain name row.
The URL of the public-facing endpoint of the reverse proxy
device in the External URL row.
The IP address of the external endpoint of the reverse proxy
device in the IP Address of the external endpoint row.
Plan your web application architecture

This section helps you plan the architecture of the SharePoint Server web applications that you will use in your
hybrid environment.
Inbound connectivity requires a secure communication channel between the on-premises SharePoint Server
farm and SharePoint Online. Data is exchanged between a site collection in SharePoint Online and an on-
premises web application over this communication channel.
SharePoint Online sends requests to a reverse proxy server that relays the requests to a specific web application
in the on-premises SharePoint Server farm that is configured for SharePoint hybrid. We refer to this as the
primary web application.
TIP
Regardless of how many hybrid solutions that you plan to configure, you typically will use only one primary web
application. You don't have to create extra primary web applications for each additional hybrid solution.
Both the primary web application and a single site collection within the primary web application must be
configured to accept inbound connections from SharePoint Online.
The SharePoint administrator associates the services and connection objects that are needed to support the
hybrid solutions that are being deployed with the primary web application. Outbound connections can be made
from any on-premises SharePoint Server web application by using the feature-specific configurations.
A SharePoint Server web application is composed of an Internet Information Services (IIS ) website that acts as a
logical unit for the site collections that you create. Each web application is represented by a different IIS website
that has a unique or shared application pool, that has a unique public URL, and that can also be configured to use
up to five internal URLs using Alternate Access Mapping (AAM ). A given web application is associated with a
single content database and is configured to use a specific authentication method to connect to the database.
Multiple web applications can be configured to use different authentication methods, and optionally AAMs, to
provide access to a single content database.
A web application's public URL is always used as the root URL in all links to sites and content accessed through
the web application. Consider a web application with the public URL https://spexternal.adventureworks.com
that has an internal URL https://sharepoint configured in AAM. When you browse to the internal URL
https://sharepoint, SharePoint Server returns the website with the URL https://spexternal.adventureworks.com,
and all links within the site will have URLs based on that path.
Alternate access mapping (AAM ) is needed only when you are configuring inbound connectivity using a path-
based site collection with a public URL that is different than the external URL. AAM lets you associate the
external URL with the internal URL of a SharePoint site inside your organization. This enables SharePoint Server
to route requests for internal URLs configured in AAM to the corresponding primary web application.
For more information about claims-based web applications, see Create claims-based web applications in
SharePoint Server.
For more information about how to extend a web application, see Extend claims-based web applications in
SharePoint.
For more information about site collections, see Overview of sites and site collections in SharePoint Server.
Choose a site collection strategy
Before you decide to use an existing web application or create a new one, you must understand the configuration
requirements that the web application and site collection must meet to support hybrid functionality. Use the
information in this section to determine your strategy for creating a new web application and site collection or to
determine whether a site collection in an existing web application can be used in your hybrid environment.
The following figure shows the decision flow for determining your site collection strategy.
Requirements for hybrid web applications
Web applications used for hybrid functionality must meet all these requirements:
The public URL of the web application must be identical to the External URL.
The OAuth protocol provides user authorization in SharePoint hybrid solutions. The Host request header
in all SharePoint Online communications to SharePoint on-premises contains the URL to which the
request was originally sent. To authenticate inbound requests from SharePoint Online, the on-premises
SharePoint Authentication service must be able to match this URL in all traffic from SharePoint Online to
the public URL of the primary web application. This is the External URL. One advantage of using a host-
named site collection for SharePoint hybrid environments is that you can configure a host-named site
collection to use the same URL as the External URL. This eliminates the need to configure Alternate
Access Mapping.
The web application must be configured to use Integrated Windows authentication using
NTLM.
Integrated Windows authentication using NTLM is required for web applications that are deployed in
scenarios that support server-to-server authentication and app authentication. For more information, see
Plan for server-to-server authentication in SharePoint Server.
Requirements for specific site collection configurations

Site collections used for hybrid functionality must meet all these requirements, and must also either exist in or be
created in a web application that meets the web application requirements:
Host-named site collections
The web application must support host-named site collections.
To create a host-named site collection, the web application must be created to enable them. You
cannot enable this functionality after the web application has been created.
For more information about how to create a host-named site collection, see Host-named site
collection architecture and deployment in SharePoint Server.
NOTE
Although this is a web application requirement, it is listed here because it applies only to environments that
have host-named site collections.
Your on-premises DNS server has to be configured with split DNS. You need to create a forward
lookup zone for the Public Internet domain that you used for your public URL and an A (host)
record in the forward lookup zone that has the IP address of the SharePoint Server server and the
host name of your External URL.
IMPORTANT
The reverse proxy device must be able to resolve host names in this forward lookup zone to relay inbound
requests to the SharePoint Server farm.
Path-based site collections
If the public URL is identical to the External URL:
Your on-premises DNS server must be configured with split DNS. You need to create a forward
lookup zone for the Public Internet domain you used for your public URL and an A record in the
forward lookup zone that has the IP address of the SharePoint Server server and the host name of
your External URL.
IMPORTANT
The reverse proxy device must be able to resolve host names in this forward lookup zone to relay inbound
requests to the SharePoint Server farm.
This is an easy way to configure a web application for a SharePoint hybrid. The goal is to match the
Public URL field of the new web application to the URL of the public-facing endpoint on the
reverse proxy, which is also known as the External URL.
If the public URL is different from the External URL:
You need to configure an alternate access mapping (AAM ) to relay inbound requests from
SharePoint Online.
Extend the primary web application and use the External URL as the Public URL. Then create an
Internal URL (via Add Internal URLs) in the same security zone as the extended web application
to use as a bridging URL. You will also configure the reverse proxy device to relay inbound requests
from SharePoint Online to this bridging URL.
Remember, alternate access mapping (AAM ) is needed only when you are configuring inbound
connectivity using a path-based site collection with a public URL that is different than the external
URL.
NOTE
Remember that the External URL is the URL of the Internet-facing endpoint of the reverse proxy device.
Record your site collection strategy choice on the worksheet

in the Site collection strategy row of Table 2.
Choose an existing web application or create a new one

You can either use an existing web application or create one to use as the primary web application.
If you prefer to manage the web application used for hybrid functionality independently or if your existing web
application does not meet the requirements that are listed in the Choose a site collection strategy section, you
should create a new web application.
Record your decision in the New or existing web

application row of Table 2.
Plan to use an existing web application

If you decide to use an existing web application as the primary web application, gather the URL of the primary
web application and the URL of the top level site collection and list it on the worksheet.
Record the following information on the worksheet:

Depending on your site collection strategy, record the URL of
the primary web application in the Primary web
application URL row of Table 5a, 5b, or 5c.
If you are using an existing host-named site collection, record
the URL of the top-level site collection in the Host-named
site collection URL row in Table 5a.
Plan to create a new web application
If you decide to create a new web application, we will direct you on how to do this when you are configuring the
hybrid topology.
Plan SSL certificates

SSL certificates establish server identity and provide certificate authentication for several different services and
connections in a SharePoint hybrid environment. You need to have two SSL certificates: a Secure Channel SSL
certificate and an STS certificate.
For more information on how SSL certificates are used in SharePoint hybrid environments, see SharePoint 2013
Hybrid Topology: Certificate and Authentication Model.
NOTE
If you choose to help secure your on-premises SharePoint farm with SSL, you will also need an SSL certificate for the
primary web application. There are no hybrid-specific considerations for this certificate, so you can follow the general best
practices for configuring SharePoint Server with SSL.
NOTE
"Secure Channel" is not a class of certificate; we use the term as a way to differentiate this particular certificate from other
SSL certificates used in the environment.
About Secure Channel SSL certificates

A Secure Channel SSL certificate provides authentication and encryption for the secure communication channel
between the reverse proxy device and Office 365, acting as both a server and a client certificate. It also verifies
the identity of the reverse proxy endpoint that's used to publish the on-premises SharePoint Server site
collection.
This certificate must be either a wildcard or a SAN certificate and be issued by a public root certification
authority. The subject field of this certificate must contain the host name of the external endpoint of the reverse
proxy server or a wildcard URL that covers all host names in the namespace. It must use at least 2048-bit
encryption.
IMPORTANT
Wildcard certificates can secure only a single level of a DNS namespace. For example, if your external URL is
https://spexternal.public.adventureworks.com, the subject of your wildcard certificate must be
*.public.adventureworks.com, not *.adventureworks.com.
In scenarios where SharePoint Online is configured to request information from SharePoint Server, an SSL
certificate is required to do the following:
Encrypt traffic over the security channel.
Enable the reverse proxy device to authenticate inbound connections using Certificate Authentication.
Allow SharePoint Online to identify and trust the external endpoint.
During deployment, you'll install the SSL certificate both on the reverse proxy device and in a SharePoint Online
Secure Store target application. You will configure this when you configure the hybrid environment
infrastructure.
Get a Secure Channel SSL certificate
Get a Secure Channel SSL wildcard or SAN (Subject Alternative Name) certificate for your on-premises public
domain from a well-known certificate authority, such as DigiCert, VeriSign, Thawte, or GeoTrust.
NOTE
This certificate must support multiple names and must be at least 2048 bits. > The Subject or Subject Name field of the
certificate must contain a wildcard entry of the domain name in the External URL. For example, if your external URL is
https://spexternal.public.adventureworks.com, the subject of your wildcard certificate should be
*.public.adventureworks.com. > Certificates typically expire at one-year intervals. So it's important to plan in advance for
certificate renewals to avoid service interruptions. SharePoint Administrators should schedule a reminder for certificate
replacement that gives you enough lead-in time to prevent a work stoppage.
About STS certificates

The STS certificate of the on-premises SharePoint farm requires a default certificate to validate incoming tokens.
In a SharePoint hybrid environment, Azure Active Directory acts as a trusted token signing service and uses the
STS certificate as the signing certificate. If you choose to use a certificate other than the default STS certificate
(for example, a certificate from a public certificate authority), replace the default certificate before you begin the
hybrid configuration process.
Record the accounts needed for configuration and testing

A SharePoint hybrid environment setup requires several user accounts in both your on-premises Active
Directory and the Office 365 directory (Azure Active Directory that is surfaced in the Office 365 directory). These
accounts have different permissions and group or role memberships. Some of the accounts are used to deploy
and configure software, and some are needed to test specific functionality to help guarantee that security and
authentication systems are working as expected.
Go to Accounts needed for hybrid configuration and testing for a complete explanation of the required
user accounts, including notes about roles and identity providers.
Record the required account information in the worksheet as instructed.
Return to this planning article after you complete this step.
Next steps
At this point, you should have completed filling out the required worksheet for inbound connectivity and be
ready to start the configuration process. Your next step is to choose a configuration roadmap.

By now, you've reviewed the planning information for your hybrid solution. It's time to get started with the
installation and configuration tasks for your chosen solution.
First, take a look at the hardware and software requirements for SharePoint hybrid, and the accounts that you'll
need to complete the configuration steps.
Roadmaps
The configuration steps for each hybrid solution are presented in roadmaps which show the exact sequence of
steps needed to configure your solution.
Choose a roadmap and configure your solution.
hybrid

This article describes the prerequisites that are required to deploy a SharePoint hybrid solution between
SharePoint Server and SharePoint Online in Office 365 for enterprises.

An operational, on-premises Active Directory Directory Services (AD DS ) domain.
An operational SharePoint Server farm. Services must be running on the local farm - farms with federated
services are not supported. For more information about setting up a farm, see Install SharePoint Server.
A properly configured Office 365 tenant that is provisioned with SharePoint Online with one of the
following subscription plans: E1 supports Display hybrid federated search results in SharePoint Server only,
E3, or E4.
Certificate requirements
The default STS certificate in the SharePoint farm is used by the hybrid picker to establish the token signing trust
when configuring hybrid workloads. Using the inbuilt STS certificate is the recommended approach when
configuring hybrid workloads. If however, you intend to use a publicly signed certificate instead of the inbuilt STS
one then you must replace the inbuilt certificate with your own following the provided guidance.
For more information, see Replace the STS certificate.
Inbound connectivity requirements

The following hybrid solutions require inbound connectivity from Office 365 to SharePoint Server:
Inbound hybrid search (displaying search results from SharePoint Server in Office 365)
Hybrid Business Connectivity Services
Hybrid Duet Enterprise Online for Microsoft SharePoint and SAP
For each of these hybrid solutions, the requirements in the following sections apply.
Additional hardware requirements
Inbound connectivity requires the following:
A reverse proxy device. The reverse proxy device provides a secure endpoint for inbound traffic using SSL
encryption and client certificate authentication.
An Internet domain (such as https://adventureworks.com) and the permission to create or edit DNS records
for that domain.
NOTE
This public domain must be registered by using a domain registrar, such as GoDaddy.com, and must be the same
domain that the URL of the external endpoint of the reverse proxy device is associated with.
Certificate requirements
This section describes the certificates you'll need to configure a inbound connectivity from Office 365 to
SharePoint Server.
About the Secure Channel SSL certificate
This certificate provides authentication and encryption between the reverse proxy device and Office 365. It must
be either a wildcard or a SAN certificate and be issued by a public root certification authority. For more
information, see About Secure Channel SSL certificates and Get a Secure Channel SSL certificate.
About the on-premises SharePoint SSL certificate
If you'll configure your primary web application to use SSL (which is the web application on the on-premises
SharePoint farm that's configured for hybrid), you'll have to bind an SSL certificate to the primary web application.
If this web application already exists and is configured for SSL, you're ready to go. Otherwise you have to either
obtain or create one for this purpose. For production environments, this certificate should be issued by a public
certification authority (CA). For test and development environments, it can be a self-signed certificate.
For more information, see Plan SSL certificates.
Supported reverse proxy devices
The following table lists the currently supported reverse proxy devices for SharePoint Server hybrid deployments.
This list will be updated as new devices are tested for supportability.
SUPPORTED REVERSE PROXY DEVICES CONFIGURATION ARTICLE MORE INFORMATION
Windows Server 2012 R2 with Web Configure Web Application Proxy for a Web Application Proxy (WA-P) is a
Application Proxy (WA-P) hybrid environment Remote Access service in Windows
Server 2012 R2 that publishes web
applications that users can interact with
from many devices.
> [!IMPORTANT]> To use Web
Application Proxy as a reverse proxy
device in a hybrid SharePoint Server
environment, you must also deploy AD
FS in Windows Server 2012 R2. Earlier
versions of Windows don't support
Web Application Proxy
Forefront Threat Management Gateway Configure Forefront TMG for a hybrid Forefront TMG 2010 is a
(TMG) 2010 environment comprehensive, secure, web gateway
solution that provides secure reverse
proxy functionality.
Note that Forefront TMG 2010 is no
longer sold by Microsoft but will be
supported through 4/14/2020. For
more information, see Microsoft
Support Lifecycle information for
Forefront TMG 2010.
F5 BIG-IP Enabling SharePoint 2013 Hybrid This is external content that's managed
Search with the BIG-IP by F5 Networks.
General reverse proxy requirements

In a hybrid SharePoint Server scenario, the reverse proxy must be able to:
Support client certificate authentication with a wildcard or SAN SSL certificate.
Support pass-through authentication for OAuth 2.0, including unlimited OAuth bearer token transactions.
Accept unsolicited inbound traffic on TCP port 443 (HTTPS ).
TIP
No ports other than TCP 443 have to be opened on the external reverse proxy endpoint to support hybrid
connectivity.
Bind a wildcard or SAN SSL certificate to a published endpoint.

Relay traffic to an on-premises SharePoint Server farm or load balancer without rewriting any packet
headers.
For an overview of reverse proxy devices in a SharePoint hybrid topology, see Configure a reverse proxy device
for SharePoint Server hybrid.
Accounts needed for hybrid configuration and
testing

When you configure a SharePoint Server hybrid environment, you need several user accounts in both your on-
premises Active Directory and Office 365. These accounts also need different permissions and group or role
memberships. Some of these accounts are used to deploy and configure software, and some are used to test
specific functionality to help ensure that security and authentication systems are working as expected.
In a hybrid environment, some or all user accounts in Active Directory are synchronized with Azure AD directory
services. We refer to these accounts as federated users. SharePoint Server and SharePoint Online are configured
with a server-to-server (S2S ) trust relationship, and service applications can be configured to enable federated
users to access content and resources from both farms using a single identity. Because user accounts and
credentials are synchronized between SharePoint Server and SharePoint Online, list and library content security
can be applied in both farms using the same set of users and groups.
NOTE
This table does not include service accounts, which may have specific requirements for service applications and features in
certain SharePoint Server hybrid solutions. For more information about the requirements for each supported solution, see
the solution configuration articles at Configure a hybrid solution for SharePoint Server.
Table: Accounts needed for SharePoint hybrid configuration and testing
ACCOUNT IDENTITY PROVIDER ROLE
Global Administrator Office 365 and Azure Active Directory Use an Office 365 work account that
has been assigned to the Global
Administrator role for Office 365
configuration tasks such as configuring
SharePoint Online features, running
Azure AD and SharePoint Online
PowerShell commands, and testing
SharePoint Online.
AD Domain Administrator On-premises AD Use an AD account in the Domain

Admins group to configure and test
AD, ADFS, DNS, and certificates and to
do other tasks that require elevation.
ACCOUNT IDENTITY PROVIDER ROLE
SharePoint Farm Administrator On-premises AD Use an AD account in the Farm

Administrators SharePoint group for
SharePoint Server configuration tasks
such as running PowerShell commands
in the SharePoint Management Shell to
configure S2S trusts, create and
configure web applications and site
collections, deploy and configure SQL
Server databases, and troubleshoot
SharePoint Server.
This account must also have additional
privileges to use the SharePoint
Management Shell:
Membership in the securityadmin
fixed server role on the SQL Server
instance.
Membership in the db_owner fixed
database role on all databases that are
to be updated.
Membership in the Administrators
group on the server on which you are
running the PowerShell cmdlets.
Federated Users On-premises AD Use AD accounts that have been

synchronized with Office 365 to test
access to specific resources in both
SharePoint Server and SharePoint
Online.
These accounts, or groups of which
they are members, must have
permissions to SharePoint Server site
collections and resources in both
environments and have the appropriate
product licenses assigned in the Office
365 subscription. They also must be set
to use the alternative domain UPN
suffix that you specify for federated
users during the planning process.
You can configure multiple federated
accounts with different permissions or
group memberships to test for
appropriate security trimming and
access to site resources.
SharePoint Server hybrid configuration roadmaps

These roadmaps guide you through the steps you need to follow to set up the hybrid features of your choice. Be
sure to follow each step in the roadmap. (If you follow more than one roadmap, there's no need to repeat the
steps that are the same. )
Choose the hybrid feature that you want to set up:
CONTENT DESCRIPTION
Configure hybrid OneDrive for Business - roadmap With hybrid OneDrive for Business, users will be redirected
to OneDrive for Business in Office 365 when they click the
OneDrive link in SharePoint Server.
Configure hybrid sites features - roadmap With hybrid sites features, you can integrate parts of your
site navigation between SharePoint Server and Office 365 for
enterprises.
Configure cloud hybrid search - roadmap With cloud hybrid search, you have a single search index in
Office 365 for enterprises with content from SharePoint
Server and SharePoint Online.
Configure hybrid federated search from SharePoint Server to With outbound hybrid search, users will be able to see
SharePoint Online - roadmap search results from Office 365 for enterprises when they
perform a search in SharePoint Server.
Configure hybrid federated search from SharePoint Online With inbound hybrid search, users will be able to see search
to SharePoint Server - roadmap results from SharePoint Server when they perform a search
in Office 365 for enterprises.
Configure hybrid Business Connectivity Services - roadmap With hybrid Business Connectivity Services (BCS), you can
leverage your existing BCS solutions to allow connections to
your SharePoint Server data sources from SharePoint Online.
See also
Concepts

This article provides the roadmap for configuring OneDrive for Business hybrid, which allows your users to use
OneDrive for Business in Office 365 with SharePoint Server.
Follow these steps in the order shown. If you already completed a step when you did a different roadmap, skip
that step and go to the next.
STEP DESCRIPTION
1. Configure Office 365 for SharePoint hybrid Configure your Office 365 tenant for a hybrid environment,
including registering your domain, configuring UPN suffixes,
and synchronizing your user accounts.
2. Set up SharePoint services for hybrid environments Configure the needed SharePoint services for hybrid search,
including User Profiles, MySites, and the Application
Management service.
3. (SharePoint Server 2013 only)Install Service Pack 1 Be sure you've installed at least Service Pack 1 on your
for SharePoint Server 2013 SharePoint Server 2013 farm or the OneDrive for Business
redirect option will not be available.
4. Redirect OneDrive for Business users to Office 365 Configure hybrid OneDrive for Business in the SharePoint
5. Quick test Check to make sure OneDrive for Business is being redirected
to Office 365:
Log in to a SharePoint Server as a regular user. (Be sure you're
a member of the correct audience if you used audiences.)
Click OneDrive in the app launcher.
The URL in the browser address bar should change from that
of your on-premises farm, to the personal site URL of
SharePoint Online.
See also
Concepts

This article provides a roadmap for configuring hybrid sites features. Follow these steps in the order shown. If you
already completed a step when you followed a different roadmap, skip that step, and go to the next one.
STEP DESCRIPTION
1. Configure Office 365 for SharePoint hybrid Configure your Office 365 for enterprises tenant for a hybrid
environment, including registering your domain, configuring
UPN suffixes, and synchronizing your user accounts.
Management service.
3. (SharePoint Server 2013 only) Install the September Install the September 2015 PU or higher for SharePoint
PU for SharePoint Server 2013 Server 2013. (We recommend installing the latest PU.)
3. Run Hybrid Picker Configure hybrid sites features by running the Hybrid Picker
in Office 365.
4. Quick test Check to make sure hybrid sites features are working:
Log in to a SharePoint Server as a regular user. (Be sure you're
a member of the correct audience if you used audiences.)
Click the Follow link at the top of the page.
You should see a small pop-up under Follow letting you
know that you're following the site. Click this pop-up and
notice that it navigates to your personal site, and the list of
sites you're following in SharePoint Online.

The app launcher is included as part of SharePoint Server 2016. If you want to add it to SharePoint Server 2013,
open the SharePoint 2013 Management Shell and run the following cmdlet:.
install-SPFeature SuiteNav
For each site collection where you want to use the feature, run the following cmdlet:
Enable-SPFeature suitenav -url <SiteCollectionURL>
Video demonstration
This video shows a walkthrough of configuring sites features.
Video: Configure hybrid sites features
See also
Concepts

Learn how to configure cloud hybrid search for SharePoint Server by setting up a cloud Search service
application in your SharePoint Server environment and connecting it to your search index in Office 365.
This article describes how you set up cloud hybrid search in an environment with SharePoint Server and
SharePoint Online for Office 365 for enterprises. With the cloud hybrid search solution, you add crawled
metadata from all your content, including on-premises content, to your search index in Office 365. When users
search in Office 365, they get search results from both on-premises and from Office 365 content.
NOTE
If you are an Office 365 Dedicated customer, setting up cloud hybrid search requires engagement of SharePoint Service
Engineering staff. Contact your Microsoft Service Delivery Manager for assistance. If you aren't sure what type of customer
you are, you can safely disregard this note.
Before you start

To complete the configuration steps you'll need these items:
The hardware and software that's needed in a SharePoint Server hybrid environment.
An on-premises server or virtual machine for cloud hybrid search that has:
Minimum 100 GB storage, 16 GB RAM, and four 1.8 GHz CPUs.
SharePoint Server installed.
Is a member of a Windows Server Active Directory domain.
(SharePoint Server 2013 only) You must have at least Service Pack 1 and the January 2016 public update
installed.
The accounts that are needed in a SharePoint Server hybrid environment, a search account for cloud
hybrid search in SharePoint Server, and a managed account for default content access in SharePoint
Server. Ensure that the account for default content access has at least read access to the content to crawl.
Your company's or organization's SharePoint Online portal URL, such as
https://<yourtenantname>.sharepoint.com
The search architecture plan you made for cloud hybrid search.
If you'll use the Hybrid picker in the SharePoint Online admin center wizard to help you configure, ensure
that the application farm that hosts the SharePoint Server Central Administration website has .NET 4.6.3
installed.
If you'll use the CreateCloudSSA.ps1 and Onboard-CloudHybridSearch.ps1 Microsoft PowerShell
scripts to help you configure, find them in the Microsoft Download Center. You'll also need the Microsoft
Online Services Sign-In Assistant for IT Professionals RTW and the Azure Active Directory Module for
Windows PowerShell.
Follow these steps:
If you already completed step 1 when you configured a different hybrid solution, skip that step and go to the next.
Step Description
and synchronizing your on-premises user accounts with
Office 365.
2. Create a cloud Search service application in Run the Hybrid Picker wizard on the application farm that
SharePoint Server hosts the SharePoint ServerCentral Administration website.
Alternatively, run the CreateCloudSSA.ps1 PowerShellscript
3. Connect your cloud Search service application to If you used the Hybrid Picker wizard to create a cloud Search
your Office 365 tenant service application, skip this step. The Hybrid Picker
automatically connected your environments.
Otherwise, run the Onboard-CloudHybridSearch.ps1
PowerShell script to onboard your cloud SSA and Office 365
tenant to cloud hybrid search. The script sets up the cloud
SSA to interact with the Office 365 tenant and also sets up
server-to-server authentication.
4. Set up search architecture in SharePoint Server for This step is optional. If you planned a search architecture
cloud hybrid search that's different from the default one, set up the planned
search architecture.
5. Create a content source for cloud hybrid search to We recommend adding a small file share first, you can add
crawl more on-premises content later.
6. Set up a separate Search Center in Office 365 to Keep the existing search experience unchanged by setting up
validate hybrid search results a separate Search Center in Office 365 so you can validate
and tune the new search experience there.
7. Start a full crawl of on-premises content for cloud When the crawl completes, your on-premises content shows
hybrid search up in the search results in your validation Search Center in
Office 365 and in Office Delve.
8. Verify that cloud hybrid search works Go to your Search Center in SharePoint Online in Office 365
and enter this query: "IsExternalContent:true". The results you
get should show content from the on-premises content
source that you've crawled.
9. Tune cloud hybrid search Set up and tune the search experiences you've planned for
your users.
10. Remove the validation Search Center and expose all Set your Search Center and any site search in Office 365 to
users to hybrid search results. use the default result source and set up the default result
source with the search experiences that you've tuned. Your
on-premises content shows up in the search results in your
Search Center in Office 365, site search in Office 365, and in
Office Delve.
Create a cloud Search service application in SharePoint Server

The cloud SSA lets you crawl and add metadata from on-premises content to the search index in Office 365. Each
search farm can have only one cloud SSA, but can have multiple SSAs in combination with the cloud SSA. You
can't convert an existing SSA to a cloud SSA.
NOTE
If your organization restricts computers from connecting to the internet, you need to allow access to the endpoints
(FQDNs) that cloud hybrid search uses. Include the endpoints in your outbound allow lists. The endpoints are listed in the
SharePoint Online section of the article Office 365 URLs and IP address ranges and are marked for use with Hybrid Search.
Use the Hybrid Picker to connect your SharePoint Server and Office 365 environments and create the cloud
On the application server that hosts the SharePoint ServerCentral Administration website:
1. Log on to the console as a farm administrator.
2. Connect to Office 365 as a global administrator.
3. Navigate to https://go.microsoft.com/fwlink/?linkid=867176 to download, install, and start the Hybrid
Picker wizard.
4. Follow the prompts in the Hybrid Picker and select the hybrid search feature.
The Hybrid Picker lets you choose between a cloud SSA with the default search architecture on the application
server that hosts the SharePoint Server Central Administration website, or a cloud SSA with a search architecture
on two application servers (supports high availability)
The Hybrid Picker saves you time because it also connects the cloud SSA to your Office 365 tenant (step 3).
Alternative methods for creating a cloud Search service application
You can also create the cloud SSA as follows:
You can download the CreateCloudSSA.ps1 Powershell script from the Microsoft Download Center and
run it. The script lets you choose between a cloud SSA with the default search architecture on the
application server that hosts the SharePoint Server Central Administration website, or a cloud SSA with a
search architecture on two application servers (supports high availability).
You can use the SharePoint Central Administration website, just like you would for an SSA. With this
method you get a cloud SSA and the default search architecture installed on the application server that
hosts the SharePoint Server Central Administration website.
To create a cloud SSA by running the CreateCloudSSA.ps1 PowerShell script, follow the instructions below.
NOTE
When you installed SharePoint Server, the user account from which you ran the installation was granted the appropriate
permissions to run Windows PowerShell cmdlets.
On the application server that hosts the SharePoint ServerCentral Administration website , follow these steps:
1. Make sure you're using the same user account as when you installed SharePoint Server. This account is
granted the appropriate permissions to run Window Powershell cmdlets.
2. Start the Windows Powershell console with administrator privileges: Click Start, type PowerShell, and
then right-click Windows PowerShell and select Run as administrator.
3. Run the CreateCloudSSA.ps1 PowerShell script.
4. When prompted, type:
The host name of the search server in SharePoint Server.
If you've planned highly available search, the host name of the second search server.
The Search service account in this format: domain\username.
A name of your choice for the cloud SSA.
The name of the database server in SharePoint Server
5. Verify that you see the message that the cloud SSA was successfully created.
Can I make my own Windows PowerShell script for creating a cloud SSA?
If you want to make your own PowerShell script for creating a cloud SSA, first study the CreateCloudSSA.ps1
PowerShell script we've provided. Notice that the difference between creating a cloud SSA and an SSA is the
value of the property CloudIndex. You set CloudIndex: true when you create a cloud SSA (you can't change
this value later). When CloudIndex is true, crawled metadata is not added to the on-premises search index.
However, this doesn't mean that the metadata is added to the Office 365 search index, you have to onboard the
cloud SSA to cloud hybrid search for that to happen (see Connect your cloud Search service application to your
Office 365 tenant). Ensure that your PowerShell script:
Tests that the Search service account is a managed account, and makes it a managed account if it isn't.
Includes -CloudIndex $true as an argument when it uses the New -SPEnterpriseSearchServiceApplication
PowerShell cmdlet.
Connect your cloud Search service application to your Office 365

tenant
NOTE
If you used the Hybrid Picker to create a cloud Search service application, then you can skip this step.
This section guides you how to onboard your cloud SSA and Office 365 tenant to cloud hybrid search and covers:
Connecting your cloud SSA and your Office 365 tenant - When your cloud SSA and your Office 365
tenant are correctly connected, the cloud hybrid search solution is ready to add crawled metadata from on-
premises content to the search index in Office 365. When you've onboarded your cloud SSA, check to see
that your cloud SSA has the value 1 for the property IsHybrid. You check by running this PowerShell
command: $ssa.GetProperty("CloudIndex").
Configuring server-to-server authentication - Server-to-server authentication allows servers to access
and request resources from one another on behalf of users.
On the application server that hosts the SharePoint ServerCentral Administration website, follow these steps:
1. Ensure that the date and time of the server is synchronized with the other servers in the SharePoint Server
farm.
2. Download and install the Microsoft Online Services Sign-In Assistant for IT Professionals RTW from the
Microsoft Download Center.
3. Download and install the latest version of the Azure Active Directory Module for Windows PowerShell
from the PowerShell Gallery.
4. Download the OnBoard-CloudHybridSearch.ps1 PowerShell script from the Microsoft Download Center.
5. If your environment is Office 365 Business, Office 365 Enterprise, Office 365 Education, Office 365
operated by 21Vianet, Office 365 Germany, or Office 365 US Government Defense, open an elevated
PowerShell prompt, and run the OnBoard-CloudHybridSearch.ps1 PowerShell script as follows:
Import-Module MSOnline
.\OnBoard-CloudHybridSearch.ps1 -PortalUrl <SPOTenantPortalUrl> -CloudSsaId <CloudSSANameCreatd>
**SPOTenantPortalUrl** is the URL of your company's or organization's SharePoint Online portal, and **
CloudSsaID ** is the name of the cloud SSA that you created earlier.
6. If your environment is Office 365 US Government Communication, open an elevated PowerShell prompt, and
run the OnBoard-CloudHybridSearch.ps1 PowerShell script as follows:
Import-Module MSOnline
.\OnBoard-CloudHybridSearch.ps1 -PortalUrl <SPOTenantPortalUrl> -CloudSsaId <CloudSSANameCreatd> -

IsPortalForUSGovernment $true
**SPOTenantPortalUrl** is the URL of your company's or organization's SharePoint Online portal, and **
CloudSsaID ** is the name of the cloud SSA that you created earlier.
7. When prompted, type the global admin credentials for your Office 365 tenant.
Set up search architecture in SharePoint Server for cloud hybrid search

If you planned to use the default search architecture that you get when creating a cloud SSA, you can skip this
step.
Otherwise, ensure that you have prepared the servers you need for your planned search architecture for cloud
hybrid search, and follow the guidance for setting up your planned search architecture. This guidance is
applicable also for cloud hybrid search.
Create a content source for cloud hybrid search to crawl

We recommend that you start with a small on-premises content source, for example a small file share, to test. You
can add more on-premises content sources later.
1. Verify that the user account that is performing this procedure is an administrator for the cloud SSA.
2. On the home page of Central Administration, in the Application Management section, click Manage
3. On the Manage Service Applications page, click the cloud SSA.
4. On the Search Administration Page, in the Crawling section, click ** Content Sources **.
6. On the Add Content Source page, in the Name section, in the Name box, type a name for the new content
source.
7. In the Content Source Type section, select the type of content that you want to crawl.
8. In the Start Addresses section, in the Type start addresses below (one per line) box, type the URLs
from which the crawler should begin crawling.
10. In the Crawl Schedules section, to specify a schedule for full crawls, select a defined schedule from the
Full Crawl list. A full crawl crawls all content that is specified by the content source, regardless of whether
the content has changed. To define a full crawl schedule, click Create schedule.
11. To specify a schedule for incremental crawls, select a defined schedule from the Incremental Crawl list.
An incremental crawl crawls content that is specified by the content source that has changed since the last
crawl. To define a schedule, click Create schedule. You can change a defined schedule by clicking Edit
schedule.
12. To set the priority of this content source, in the Content Source Priority section, on the Priority list,
select Normal or High.
13. Click OK.
Set up a separate Search Center in Office 365 to validate hybrid search

results
After you've set up cloud hybrid search and completed a full crawl of your on-premises content, your existing
Search Center in Office 365 as well as Office Delve will automatically show both on-premises and online search
results. Before you start the full crawl, we recommend that you create a new, separate Search Center. Set it up to
show the mixed on-premises and online search results. This way you can validate and tune the new search
experience in the separate Search Center, while you keep the existing Search Center unchanged.
Follow these steps to set up a separate Search Center in Office 365:
1. Create a result source that retrieves search results from the search index of this tenant, but limits search
results to Office 365 content by using a Query Transform. Change the default query transform to "{?
{searchTerms} NOT IsExternalContent:true}". This works because content that has the managed property
IsExternalContent set to true (see About the IsExternalContent managed property ) in the SharePoint
Online search schema, is on-premises content.
2. Modify the Search Results Web Part in your Office 365 Search Center to use the result source that you just
created. Your users get the original search experience in this Search Center.
3. Create a second Office 365 Search Center that uses the default result source. This Search Center has
hybrid search results when you've run a full crawl. Validate and tune your new search experience in this
Search Center.
4. Set up access so only testers and administrators have access to the second Office 365 Search Center.
Here's an example of a validation environment:
1. On-premises content. During crawl, content is added to the Office 365 index.
2. Office 365 content. During crawl, content is added to the Office 365 index.
3. Default (or existing) Office 365 Search Center. This Search Center uses the custom result source that limits
search results to only Office 365 content.
4. Second Office 365 Search Center, where you validate and tune how hybrid search results are shown. This
Search Center uses the default result source and shows search results from both on-premises and Office
365 content.
About the IsExternalContent managed property
An important part in this environment is the custom result source you use in the default or existing Office 365
Search Center. This result source keeps the search experience unchanged while you validate and tune how hybrid
search results are displayed. An important piece in this custom result source is the IsExternalContent managed
property in the SharePoint Online search schema. Before you set up cloud hybrid search, this managed property
is empty. But, after you've set up cloud hybrid search and crawled your on-premises content, this property is set
to true for all on-premises content. You can therefore limit search results to show only Office 365 content with
NOT IsExternalContent:true .
Start a full crawl of on-premises content for cloud hybrid search

Start a full crawl of the content source. See Start, pause, resume, or stop a crawl in SharePoint Server 2013 or
follow these steps:
1. Verify that the user account that is performing this procedure is an administrator for the Cloud Search
3. On the Manage Service Applications page, click the cloud Search service application.
source that you want to crawl, click the arrow and then click Start Full Crawl. The value in the Status
column changes to Crawling Full for the selected content source.
Verify that cloud hybrid search works
After the full crawl completes, verify that your on-premises content shows up in the search results in your
validation Search Center in Office 365.
1. Log in to Office 365 with your work or school account. Make sure that:
You have access to the validation Search Center.
You have access to the content in the content source that you have crawled. If you performed step 1 of this
roadmap, you should have access.
Your organization hasn't assigned user access rights to the on-premises content by using one of the default
security groups in Windows Server Active Directory (AD ), for example the Domain Users security group,
see Plan cloud hybrid search for SharePoint.
2. Search for IsExternalContent:1 in the validation Search Center. The results you get should show content
from the on-premises content source that you've crawled.
3. Verify that your on-premises content shows up in the search results.
Tune cloud hybrid search

After you've set up cloud hybrid search and verified that you get search results from on-premises content in your
validation Search Center in Office 365, set up the search experiences that you planned.
You might find this guidance useful:
With cloud hybrid search you manage the search schema in SharePoint Online in Office 365, just as you
would in an Office 365 environment. Learn how in Manage the Search Center in SharePoint Online.
You manage how search results are displayed from the search schema in SharePoint Online, see Manage
the Search Center in SharePoint Online. If you've set up site search in SharePoint Server to get search
results the Office 365, you also manage how these results are displayed from the search schema in
SharePoint Online.
Enable previews of on-premises search results in cloud hybrid search .
Show results from Office 365 in on-premises SharePoint with cloud hybrid search .
To publish your SharePoint Server site and make it accessible for your users, follow the best practices in
Plan for Internet, intranet, and extranet publishing sites in SharePoint Server
To open a link from a search result that comes from on-premises content, users have to either be
connected to the on-premises intranet via a Virtual Private Network (VPN ) connection or be logged on to
where the content is stored. Alternatively, you enable users to open such links by installing a reverse proxy
device for SharePoint Server.
After setting up and validating the planned search experiences, you might want to clear your search index in
Office 365 for metadata from the on-premises content you've used during this work. This works differently from
what you might be familiar with from SharePoint Server.
In the SharePoint Central Administration website you can use the option "Index reset" for an SSA to remove all
content from the search index. This option does not work for cloud hybrid search because there is no direct
communication between the cloud SSA in SharePoint Server and the search index in Office 365. If you only want
to remove some on-premises metadata, remove that on-premises content source, or create a crawl rule that
doesn't crawl the URL of a file. If you need to remove all metadata from on-premises content from the search
index in Office 365, open a ticket with Microsoft Support.
Proxy Considerations
If the SharePoint farm is behind a forward proxy (that is, traffic destined for the Internet must be sent through a
proxy server), it may be necessary to configure additional proxy settings. Follow the steps outlined in Configure
proxy server settings for Search in SharePoint Server.
In addition, it may be necessary to configure the to support the proxy. This file resides at
machine.config
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config . More information on configuring the
appropriate element can be found at Network Settings Schema.
Related Topics
Cloud hybrid search service (CSSA)-FAQ
Quite frequently, we receive questions regarding Cloud hybrid search service application, Hybrid and its
supportability around various use cases. The goal of this post is to collate and have a home for these questions for
ease of reference.
What are the current supported Hybrid features in SharePoint?
Hybrid is not limited to search/Cloud hybrid search service application (CloudSSA) anymore. Below is a
consolidated list of Hybrid features along with Microsoft Official reference to configure the same.
1. Hybrid OneDrive for Business
2. Hybrid Sites Features
3. Hybrid App Launcher
4. Hybrid Extranet Business-to-Business sites
5. Hybrid Auditing (Works only in SharePoint 2016)
6. Hybrid Taxonomy and Content Types
7. Hybrid self-service site creation (Hybrid self-service site creation is available in SharePoint Server 2013 with
the March 2017 PU. November 2017 CU adds this to 2016)
8. Hybrid Search [Query federation]
9. Cloud Hybrid search(CloudSSA)
10. Business connectivity services
Is there an automated wizard that can help configure Hybrid in my environment?
Yes, you can leverage the Hybrid picker in SharePoint Online admin center for hybrid configurations. This wizard
automates certain configuration steps required to connect on-premises SharePoint Server environment with
SharePoint Online in Office 365. You can read more about the Hybrid picker here.
Can I leverage SharePoint Hybrid picker to perform a clean -up of Hybrid environment or deactivate the
Hybrid features that was activated by picker?
The picker automates certain configuration steps to configure Hybrid between On-premises SharePoint Server
with SharePoint Online. This is not designed to undo the changes once the wizard completes. Example, Hybrid
Picker creates a Server-to-Server (S2S )/OAuth trust between the SharePoint Online and SharePoint On-premises
farm. Once this is configured, re-running the wizard does not clean up the trust. You can refer to the official
guidance here that mentions the Server-to-Server trust: "Note that the hybrid picker does not uninstall features. If
you run the hybrid picker and deselect a feature that you previously installed, it will remain installed."
I plan to configure cloud hybrid search with high availability (HA ) topologies. Is there a script available to
configure the same?
If you plan to configure cloud hybrid search with HA topologies in either SharePoint 2013/2016, you can configure
it with hybrid picker. Hybrid picker has automated certain configuration steps needed to connect your on-premises
SharePoint Server environment with SharePoint Online in Office 365 for cloud hybrid search. (Learn more)
What is hybrid federated search and how is it different from cloud hybrid search?
Hybrid federated search and Cloud hybrid search are the two Hybrid experiences that a search administrator can
choose while configuring hybrid search with Office365.
With hybrid federated search solution for SharePoint, the results are federated from your search index in
SharePoint Server 2013/2016 as well as index in Office 365. SharePoint on-premise crawls on-premises content
and SharePoint Online crawls SharePoint Online corpus. Post hybrid configurations, when authenticated users
submit a query in a search center, a real time query would be fired against both indexes and authorized users will
get search results from the Office 365 search index as well as from the SharePoint On-premises 2013/2016 search
index. However, the results are separate and distinct from one another often displayed in separate search verticals
or result blocks.
Cloud hybrid search service application for SharePoint 2013/2016 is a crawl-based solution. All crawled content,
including on-premises content, is processed by Office365 search engine and resides in search index in Office 365.
When authenticated users submits a query in SharePoint Online search center, they get search results from Office
365 search index, thus see items both from on-premises and Office 365 content. If you want to get the same
experience in on-premises SharePoint 2013/2016 search center, you need to configure a remote result source in
the on-premises farm to fetch results from Office365 index.
What are the supported topologies in Hybrid federated search?
There are three topology types for Hybrid federated search.
Hybrid infrastructure setup (server to server (S2S ) authentication) is a must for any of the below scenarios to work.
Outbound: In an outbound scenario, a remote result source will only be configured in the on-premise SharePoint
2013/2016 farm. Outbound can be defined as the ability to only query from the on-premise farm to SharePoint
Online search(SPO ) farm. Results will be displayed in the on-premise search center in separate search verticals
(one for SPO results, another for SharePoint on premise). If outbound is configured, then querying from
SharePoint Online (SPO ) search center will not return any search results from the on-premises SharePoint
2013/2016 farm.
Inbound: In an inbound scenario, a remote result source will only be configured in the SharePoint Online (SPO )
search center. Inbound can be defined as the ability to query only from SPO farm to on-premise farm. Results will
be displayed in the SPO search center in separate search verticals (one for SPO results, another for SharePoint on
premise). There are additional certificate and reverse proxy requirements in addition to the outbound
configurations mentioned above. The blog here outlines the requirement.
Two way: A combination of the above two (outbound and inbound) is a two way hybrid federated search. Two way
is typically the desired state of hybrid federated search deployment in an organization, where result sources are
created in both SharePoint Online as well as SharePoint 2013/2016 farm. When queried from either of the search
centers, users see a set of search verticals with results from SharePoint Online and another from on-premise
SharePoint 2013/2016 farm.
What are the some of the tested and documented reverse proxies for Hybrid?
In Hybrid federated search, the reverse proxy must be able to:
Support client certificate authentication with a wildcard or SAN certificate.
Support pass-through authentication for OAuth 2.0.
Relay traffic to an on-premises SharePoint Server 2013 or 2016 farm or load balancer without rewriting any
packet headers.
As described in this article, below is a list of tested reverse proxy solution.
SUPPORTED REVERSE PROXY DEVICES CONFIGURATION ARTICLE
Windows Server 2012 R2 with Web Application Proxy (WA-P) Configure Web Application Proxy for a hybrid environment
Forefront Threat Management Gateway (TMG) 2010 Configure Forefront TMG for a hybrid environment
F5 BIG-IP Enabling SharePoint 2013 Hybrid Search with the BIG-IP
Citrix NetScaler Citrix NetScaler and Microsoft SharePoint 2013 Hybrid

Deployment Guide
When should I deploy cloud hybrid search or hybrid federated search? Are there any recommendations ?
The recommendation is to choose Cloud hybrid search for these benefits as per TechNet guidelines.
Your users get unified search results, search relevance ranking, and refiners even if your organization has a
hybrid deployment with content both on-premises and in Office 365.
Your users can use cloud capabilities such as Office Delve also for your on-premises content.
This means that the footprint of your SharePoint Server 2013/2016 search farm is smaller, and your total
cost of ownership for search is lower.
You don't need to upgrade any of your existing installations of SharePoint to have enterprise search in the
cloud because SharePoint Server 2013/2016 supports crawling of existing SharePoint Server 2007,
SharePoint Server 2010, and SharePoint Server 2013 content farms.
You no longer have to migrate your search farm to a newer version of SharePoint because this happens
automatically in Office 365.
If you have some on-premises content that's highly sensitive and shouldn't be indexed outside your on-premises
network, then hybrid federated search may be the way to go. Note: Authenticated user queries will be routed in
real time to two separate indices (SharePoint Online index and SharePoint on-premise) and results will be
displayed in separate search verticals.
Can Hybrid Search results be displayed in a SharePoint 2010 search center?
Out of box, there is no way to configure Server to Server authentication in a SharePoint 2010 environment. Cloud
hybrid search service application can only be installed in SharePoint 2013/2016 environment. The
recommendation is ideally to upgrade the SharePoint 2010 farm to SharePoint 2013 and or SharePoint 2016
following the upgrade guidelines. However, if there is a business requirement to remain on SharePoint 2010, then
there is a workaround through which you will be able to display results. You need to publish search service
application from SharePoint 2013 and consume from SharePoint 2010 farm. Whichever hybrid search model you
deploy (cloud hybrid search service application or federated hybrid search), consuming the same from SharePoint
2010 farm will show authenticated users search results from Office365. Note: The search center site in SharePoint
2010 must be Enterprise search center.
What are supported topologies while publishing/consuming Cloud hybrid search service application?
Publishing/consuming of Cloud search service application follows the exact same support matrix as any other
service application within SharePoint. The following table lists the supported options:
PUBLISHED CLOUDSSA VERSION CAN BE CONSUMED BY
SharePoint Server 2016 SharePoint Server 2016
What is user rehydration and why does it play a key role in hybrid setup with Office365?
Server-to-server authentication (S2S ) allows servers (ex. SharePoint 2013/2016) to access and request resources
from one another on behalf of users. This is a key requirement for Hybrid search to work. For example, in a Cloud
hybrid search service farm when a user queries for an item in a SharePoint 2013 search center, the query needs to
be routed to SharePoint Online farm (as the index is in SPO farm). The user identity needs to be re-hydrated and
then an ACL match has to happen, and only after that a set of results that the user has permission to would be
returned in search results. To do so, it's a must that the following tasks can be accomplished:
Resolve the request to a specific SharePoint user.
Determine the set of role claims that are associated with the user, a process known as rehydrating the user's
identity.
When a request is made to obtain a resource from another server (ex. SharePoint 2013/2016), the claims from the
incoming security token is leveraged to resolve it to a specific SharePoint user. By default, SharePoint Server 2013
uses the built-in User Profile service application to resolve the identity. A match of the set of claims is done against
some user attributes for locating the corresponding user profile. The match is performed against one of the
following attributes:
Windows Security Identifier (SID )
Simple Mail Transfer Protocol (SMTP ) address
User principal name (UPN )
Session Initiation Protocol (SIP ) address
Therefore, it's recommended that at least one of these user attributes must be current in user profiles both in
SharePoint On-premises as well as in SharePoint Online.
What is the List of attributes that are synced by the Azure Active Directory Sync tool
The article here has the list of attributes that are synchronized out of the box by the Azure Active Directory Sync
tool.
Search service application in my On premises SharePoint 2013/2016 farm is partitioned. Can I configure
hybrid query federation?
Office 365 doesn't support incoming Hybrid Search queries when the on-premises Search Service Application
Proxy is deployed in partitioned mode. Outbound search fails when the Search Service Application or the proxy is
partitioned. This is because the search query passes a partitionID (tenantID ) to the search query processor, which
fails because this is a GUID and therefore unique. The unique partitionID will not be found in the O365 search
index and so no search query can be scoped to that ID. Security trimming will not allow results from one ID to be
passed to another ID. Search admins need to fix/rebuild their Service Application to be fully supported. This KB
article describes the errors and some workarounds.
What content sources can you crawl using Cloud hybrid search service application?
All SharePoint 2013/SharePoint 2016 content sources are supported.
My SharePoint topology consists of multiple SharePoint farms (i.e., Content farm, Service Farm ). What is
the preferred farm to configure Cloud hybrid search service application?
In a content/service SharePoint scenario, assuming Search is in the service farm, CloudSSA should ideally be
configured in the service farm. For implementation details, refer to this link. https://technet.microsoft.com/en-
us/library/ff621100(v=office.16).aspx
Is ADFS/Single-sign -on mandatory to configure server-to-server authentication or Cloud hybrid search
service application?
ADFS/Single-sign is not a mandatory pre-requisite to configure server-to-server authentication or Cloud hybrid
search service application. Below is an overview of features that need to be configured between Office 365 and
SharePoint Server 2016 /2013 to configure a hybrid environment.
1. Sign up for Office 365.
2. Register your domain with Office 365.
3. Synchronize accounts with Office 365.
4. Assign licenses to your users.
5. Create cloud hybrid search service application.
6. Onboard cloud hybrid search service application.
Can I connect multiple Cloud hybrid search service applications (CloudSSA ) to the same Office365 tenant?
Companies have SharePoint Farms across different geographical locations. Having CloudSSA across geographical
locations and connecting them to the same Office365 tenant is supported. CloudSSA provides the ability to crawl
and parse on-premises content, and process and index it in single Office 365 tenant that these CloudSSA farms are
connected to.
However, it is important to note that each CloudSSA farm must only crawl unique content (i.e., crawling the same
source content from multiple CloudSSA farms connected to the same Office365 tenant is not supported).
Pro Tip: The name of the content source in SharePoint on-premises is included in the managed property
"ContentSource". If you name the content sources in your different farms uniquely, you can identify the content
source by name in queries. If you use the default "Local SharePoint Sites," you will have to find another way to
segregate your content.
Is it supported to run multiple Cloud hybrid search service applications on the same farm? Or is it supported
to host a farm that has both regular search service application as well as Cloud hybrid search service
application sharing farm hardware?
Separate farms should be used to host individual Cloud search service applications (CSSA) to avoid resource
consumption and possible unexpected behaviors. However, it is a supported configuration to operate two search
service applications (SSA) on the same farm if only one of the SSAs is a Cloud hybrid search service application.
You also need to ensure that the servers in the farm only host components from one SSA. If the Cloud hybrid
search service application and the regular search service application components do not share hardware between
any components, only then it's supported that machines in the farm can be used to host both SSAs.
What are the supported topologies for document collaboration using Exchange Server 2016, Office Online
Server (OOS ), and SharePoint Server?
The following are documented and supported topologies:
Exchange On-Premises + SharePoint On-Premises
Exchange On-Premises + SharePoint Online
Exchange Online + SharePoint Online.
Can we deploy Cloud hybrid search service application in an environment that has multiple forests?
Cloud hybrid search service application works in an environment that has multiple forests. You need to ensure that
the accounts across these forests are synched to Office365. Azure AD Connect sync should take care of this
situation. When you have multiple forests, all forests must be reachable by a single Azure AD Connect sync server.
You don't have to join the server to a domain. If necessary, to reach all forests, you can place the server in a
perimeter network. The articles below discuss this configuration.
Topologies for Azure AD Connect
Implement-support-for-multiple-forests
When Cloud hybrid search service application crawls On Premises content, do crawled properties from
SharePoint on -premises propagate to SharePoint Online?
Following the crawl of content via Cloud hybrid search service application, crawled properties from SharePoint
2013/2016 on-premises propagate to SharePoint online search schema. The crawled properties in on-premises
should be a part of default propset. You also need to ensure that you are looking up the crawl properties in
SharePoint Online search schema using the correct account. (By 'correct account', I mean an account in on-
premises Active directory having rights in SharePoint On Premises as well synched to Office365 Azure AD in your
tenant.) For example, if you can look up using the content access account of your On premises Cloud hybrid search
service application farm, you should definitely see the Crawl Properties in SharePoint Online search schema.
Can Cloud hybrid search service application be onboarded in a farm that has already been configured for
provider hosted apps?
This question primarily revolves around the following use cases:
You have a SharePoint 2013 or SharePoint 2016 farm where you plan to implement provider-hosted add-
ins and/or associate with workflow manager.
You have a SharePoint 2013 or SharePoint 2016 farm that already has provider-hosted add-ins and/or
leverages workflow manager.
Hybrid features/Cloud search service application (CSSA) can be implemented on same SharePoint farm as
mentioned above. When you try to establish a S2S trust via the CSSA onboarding script or Hybrid picker, the
authentication realm of the on premises Farm is updated to match the Office 365 tenant context id. Within the
script, we set it using Set-SPAuthenticationRealm. Once the authentication realm is changed, existing SharePoint
Add-ins fail to authenticate; users will get a HTTP 401 when they are redirected to the add-ins. You can read more
about the problem as well and fix in our post here. Note: If you configure Hybrid using Hybrid picker from
SharePoint tenant admin, then the wizard takes care of the fix.
What are the out-of-box Cloud hybrid search service application crawl limits? Also, can I request additional
index quota for my tenant?
The maximum number of on-premises items crawled by Cloud hybrid search service that can be indexed in Office
365 is 20 million. For each 1 TB of storage space a tenant has in Office 365, one can index 1 million items of on-
premises content in tenant's search index. Once the limit on how many items can indexed is reached, the on-
premises farm hosting Cloud search service application will start seeing errors while crawling new items. Below is
a snippet of the error from ULS logs from a SharePoint 2016 farm:
mssearch.exe (0x5304 ) 0x97D0 SharePoint Server Search Crawler:Azure Plugin a9sz7 Verbose
AzureServiceProxy::SubmitDocuments: submit returned : Forbidden, docid : 4653596 DocIDString : sts4s://
SharePoint Server Search Crawler:Azure Plugin ayg2m High AzureServiceProxy::SubmitDocuments: submit failed
for the document: HTTP status: Forbidden
If Cloud search service application is hosted in a SharePoint 2013 environment, the uls tag tracking the error
would be amnz2 and amoeu.
You need to request an increase in the available quota to fix the issue. To increase the maximum items that can be
indexed beyond 20 million, you need to contact Microsoft Support (see here).
My Office365 tenant is configured for Hybrid. Can I query for only on -premises items that have been
crawled using Cloud hybrid search service application?
The Hybrid Cloud SSA exposes a new managed property IsExternalContent. When crawling on premises
content, this property is automatically populated with the value 1. You can leverage the managed property
"IsExternalContent" and search for the value 1 for content that is crawled on-premises. The querystring for this
example is constructed as follows
http://<searchcenter url>/Pages/results.aspx?k=IsExternalContent:1
You can test for the online content only by stipulating NOT IsExternalContent:1 as follows:
http://<searchcentre url>/Pages/results.aspx?k=(NOT IsExternalContent:1)
What would be the People crawl experience if you are crawling On -premise profile store using Cloud hybrid
search service application?
By default, all people in the SharePoint Online SPO User Profile application will be indexed by the SharePoint
online search service. If you additionally crawl people using the on-premises cloud search service application, you
will generate an additional set of people content items in the Office 365 Search index. Since these would have two
different DocID's, both will be returned in search results when queried for a person - one will have url pointing to
users mysite in SPO and another pointing to SharePoint On-premises. This will be confusing to end users as
searching for a person will return multiple results per person.
There are two ways to approach this problem today:
Make O365 User Profile service the primary source of user information and let Office 365 Search take care
of the indexing and presentation. With this approach, you do not need to crawl people on-premises.
Crawl the on-premises people profile store in addition to O365 crawling the tenant profile store. This will
result in the described scenario of duplicate search results for each person; however, you can use query
transformation to decide which results you want to display, even providing the ability for end users to
choose between the different result sources at query time.
To utilise the on-premises profile store as the primary people search source, you should follow these steps:
1. Create a new result source or copy the existing people results source.
2. Edit the new result source and modify the Query Transformation box to include the Managed Property
IsExternalContent as follows:
{?{searchTerms} ContentClass=urn:content-class:SPSPeople IsExternalcontent:1}
3. Create a new search results page and configure the Core Search Results web part to consume this new
search result source.
4. Complete the implementation by adding the new page to the search navigation settings. This will add the
new page as a search vertical within the search center.
To utilise the Office 365 profile store as the primary people search source, you should follow the same steps but
using a slightly different query transformation at step two, as follows:
{?{searchTerms} ContentClass=urn:content-class:SPSPeople NOT IsExternalcontent:1}
Note: The difference in the two transform is the insertion of NOT before the managed property to force the
exclusion of External content i.e Non O365 People Results.
I only see preview of Office documents in search results if the content resides in SharePoint Online. Office
documents that reside in SharePoint On -premises do not show previews. Is this expected?
To enable previews for on-premises content, you need to set up an on-premises Office Web Apps Server and
configure SharePoint Server 2013 to use it (or Office Online Server for SharePoint 2016). The guidelines are
documented here. The behavior is a little different with site/webpage previews (aspx). When searching from
SharePoint Online, you will see previews of aspx pages for the pages in SharePoint Online farm and not for the
aspx pages from SharePoint On-Premises. Currently, the site and web page hover templates check that the result
item has the same host name as the current host. This is by design.
Can Perfmon be leveraged to look at crawl statistics for Cloud hybrid search service application? If yes, what
are the Perfmon counters?
There are Preform counters that have been introduced for Cloud hybrid search service application. To get a list of
all counters, you can run the following command in powershell:
((Get-Counter -ListSet "Search Gatherer Azure Plugin - SharePointServerSearch").counter
What is the recommended number of crawl databases for Cloud hybrid search service application?
Use one crawl database for each 20 million items in the content corpus. You can refer to this article for further
details.
I am using Cloud hybrid search service application (CSSA ) to crawl content. In my CSSA, I see all 6
components of the search topology. Which ones are hosted locally? For example, is there a local index?
No!! Cloud hybrid search service application is a crawler. The crawl component gets content from your on-
premises farm and sends this content to the search index in Office 365. It uses connectors to interact with the
content sources and uses the crawl database to store both temporary and historical information about the items it
crawls, just like a regular crawl component.
What is pushed by Cloud hybrid search service application to Office365 SPO endpoint during a crawl?
Cloud hybrid search service application identifies the document that has changed in SharePoint. Crawler picks up
the document and parses it, extracting a structured view of the content and removing unnecessary markup.
Crawler sends the encrypted content to the Indexing API associated with the SharePoint Online content farm.
Encrypted batch submission happens, which consists of ACLs, keywords, metadata, destination tenant info, etc. The
following types of operations can be submitted from the crawler:
1. Insert: Creates or overwrites a document's content and access control list.
2. Security update: Overwrites an existing document's access control list.
3. Delete: Deletes all content for a document.
From cloud hybrid search service application farm's ULS logs, you can track the submission of items including the
crawled properties. To do so, you need to enable VerboseEx for [SharePoint Server Search] "Crawler:Azure Plugin"
categories.
What size Cloud hybrid search service architecture do I need?
Search architecture for Cloud hybrid search service application consists of search components and databases.
Ideally, you need to plan the number of crawl components for your topology, which servers to host the
components and databases on, and the hardware required for each server. When you set up a Cloud hybrid search
service application, all components of the search service application are set up and need to be online.
The grey components as shown in this TechNet article are inactive in cloud hybrid search, but they still need to be
placed on servers as recommended in the article.
APPLICATION SERVER DATABASE SERVER
Admin Admin database
Crawl. Crawl database
Content processing component. Link database
Analytics Analytics database
Index
Query Processing component
Deploying additional crawlers will provide high availability for the crawler function. Adding query processors will
also provide high availability when the on-premises farm is configured to send search queries to Office 365.
Content processing is performed in the Office 365 service, so there is no requirement for additional content
processors on-premises. Regardless of the number of items crawled by the Cloud Search Service Application, there
is no requirement for additional index components. The index is stored in the Office 365 search farms, which saves
a significant amount of on-premises capacity and capital outlay for large corpora. You must scale the on-premises
crawl databases to match the number of items crawled because the Cloud Search Service Application must
maintain an up-to-date crawl log of the items crawled. Scaling-out employs the same processes as a regular Search
Service Application; follow the steps at
https://technet.microsoft.com/library/jj862356(v=office.15).aspx#Topology_ExampleDefaultSmall. If you need to
tune crawling, follow the recommendation in Redesign enterprise search topology for specific performance
requirements in SharePoint 2016. The same guidelines apply for Cloud hybrid search service application.
What are the Highly Available (HA ) and Disaster Recovery (DR ) recommendations for Cloud hybrid search
service application?
It is recommended that for HA, at least two servers are configured in the same SharePoint on-premises farm and
each machine hosts all the search roles. Additional servers can be used, but if at least two of each component are
present, the CloudSSA can be considered Highly Available.
For disaster recovery, a second Cloud hybrid search service application can be built in the Disaster Recovery farm.
You need to ensure that Cloud hybrid search service application must not crawl the same content as the primary
farm unless a failover is initiated. In the event of failover, the Disaster Recovery farm can immediately serve search
results from the same Office 365 search index.
Can users query for items secured with SAML claims if crawled by a Cloud search service application?
Items secured with SAML claims when crawled using Cloud Search Service application will not show up in search
results. This does not work as those identities cannot be interpreted during the ACL mapping process in the Cloud
search service application. As of today, we do not have a way to map an on premises SAML identity to an Office
365 user, which is a core requirement for ACL mapping to work. This is by design. For such supportability
questions, a request can be submitted at https://sharepoint.uservoice.com for evaluation.
On premises environment Cloud search service application crawls site collection secured with NT
Authority\Authenticated users. How does this translate to ACL mapping in SharePoint Online?
The SIDs/SID claims in incoming ACLs are translated in SPO when a cloud hybrid search service application is
used to crawl on-premises content. User security identifiers (SID ) are mapped to passport unique ID (PUID ).
Similarly, group SIDs are mapped to Object IDs. NT AUTHORITY\Authenticated Users and Everyone (the built-in
SIDSs S -1-5-11 and S -1-1-0) are translated to "Everyone except external users" in SPO (i.e., all users in tenant
except the external ones that have been invited to share by email). Cloud search service application only support
Windows identity that has been synced to AAD. If customer is not using Windows identity and wants to Crawl
using Cloud SSA, a workaround can be to add Everyone claim to the source content to ensure that users are able
to search for that Content.
Result Type Rules are configured at the site collection. Where do I configure Result Type Rules and Display
Templates when using Cloud hybrid search?
The awesome blog post from our friend MVP Matthew McDermott highlights what to configure & where. Also,
thank you Matt for providing some of your valuable comments for this post.
Can I view Popularity trend reports in SPO for content crawled with Cloud search service application?
Popularity trends works based out of analytics. Usage Analytics reporting isn't operational under a Cloud search
service application as of today. Usage analysis uses view events created on the farm where the actual content
resides. When you configure CloudSSA to crawl content from an on-premises SharePoint farm, the view events
are not passed on to the SharePoint Online search farm. The analysis processing happens on SharePoint Online
search farm so it will not see the view events and thus will not have the possibility to update the usage reports.
Cloud hybrid search service application is crawling a SharePoint farm that has http:// prefix in the default
zone, extranet zone is https://. Query from SharePoint Online ends up showing http in the search result is
this expected behavior?
Yes, this is expected. Users will see http:// prefix in the search results. As my friend Brian explains it very nicely here
, SharePoint 2013, URL -related managed properties including Path, ParentURL and SPSiteUrl all store values
relative to the URL that was crawled. The crawler simply passes what it can gather to the Search Content Services
in the cloud. SPO search has no knowledge of the AAMs on your on-prem farm and so is unable to correctly set
the mappings you would expect to see. Thus, it's recommended to crawl the Default zone for a SharePoint 2013
Web Application.
Cloud search service application is crawling my On -Premises content. Can I remove on -premises items from
SPO?
The "urls to remove" option within SharePoint admin center (https://<tenantname>-
admin.sharepoint.com/_layouts/15/searchadmin/searchresultremoval.aspx) cannot be leveraged to remove items
from SharePoint Online index. If you want to remove specific urls, your option is to use the crawl log in the on-
premises Cloud search service application server to remove the same.
Can I run Cloud hybrid search Onboarding script when multifactor authentication (MFA )is enabled in my
tenant?
Yes, you need to ensure you have the latest version of Azure AD PowerShell. You can download it from here.
What are the firewall ports and protocols requirement to configure Cloud hybrid search service application?
The articles below outline the complete infrastructure firewall requirement for end to end connectivity with
Office365. The first blog below talks about Cloud search service application specific ports and protocols.
Ports and Protocols requirement for the Hybrid Cloud Search Service Application
Office 365 URLs and IP address ranges
Hybrid Identity Required Ports and Protocols
All Outbound requests in my network are filtered or get routed via proxy server. Is there any specific
requirement Cloud hybrid search service application to work?
You need to ensure that account running the search service (msssearch, noderunner accounts) (for crawl and
Query federation scenarios to work) in the Cloud Search Service Application farm have unrestricted outbound
internet access. If not, set system level proxy settings for these search service accounts. You can follow the steps
documented in our post here.
Cloud search service application always communicates with endpoints using port 443. Assuming there are
multiple SharePoint servers in a farm that hosts Cloud search service application components, all SharePoint
servers need to communicate to the following sites
1. *.sharepoint.com
2. https://accounts.accesscontrol.windows.net
3. https://login.windows.net/common/oauth2/authorize
4. https://sts.windows.net/*
5. https://login.microsoftonline.com
If there are dedicated Search servers in the farm topology they should be able to communicate to the following
sites as well.
1. https://provisioningapi.microsoftonline.com
2. *.search.production.us.trafficmanager.net
3. *.search.production.emea.trafficmanager.net
4. *.search.production.apac.trafficmanager.net
Where can I download Cloud hybrid search service application onboarding script?
The latest version of Windows PowerShell scripts to configure cloud hybrid search for SharePoint can be
downloaded here.
Is Cloud hybrid search service application onboarding supported for Government community cloud (GCC ) &
Office 365 operated by 21Vianet.
Yes, you can refer to our post for details.
Is it possible to perform an index reset and cleanup just the content that has been crawled via Cloud hybrid
search service application?
Yes, you can follow the steps outlined in this blog article.
Is there a forum where I can discuss and ask questions regarding issues with Cloud hybrid search?
Yes, you can submit your questions regarding Cloud search service application at the TechNet forum.
Hybrid references on TechNet
Below are some links to Hybrid articles at TechNet
Minimum public update levels for SharePoint hybrid features
Plan hybrid SharePoint taxonomy and hybrid content types
Are there any eBook available to configure SharePoint Hybrid capabilities?
Yes , you can download the eBook on Configuring Microsoft SharePoint Hybrid Capabilities (ISBN
9781509302437) from this link.
Configure hybrid federated search from SharePoint
Server to SharePoint Online - roadmap

This article provides the roadmap for configuring hybrid search from SharePoint Server to SharePoint Online in
Office 365 for enterprises, which allows your users to use see search results from Office 365 when searching
from SharePoint Server.
STEP DESCRIPTION
Management service.
3. Configure server-to-server authentication from Configure server-to-server authentication between

SharePoint Server to SharePoint Online SharePoint Server and Office 365. If you've already configured
hybrid sites features, then server-to-server authentication
has already been configured and you can skip this step.
4. Display hybrid federated search results in SharePoint Configure your search service application to display search
Server results from Office 365.
See also
Concepts
Configure hybrid federated search from SharePoint
Online to SharePoint Server - roadmap

This article provides the roadmap for configuring hybrid search from SharePoint Online in Office 365 for
enterprises to SharePoint Server, which allows your users to use see search results from SharePoint Server when
searching from Office 365.
STEP DESCRIPTION
Management service.
3. Configure server-to-server authentication from Configure server-to-server authentication between

SharePoint Server to SharePoint Online SharePoint Server and Office 365.
4. Synchronize user profiles Run SharePoint user profile synchronization to update the
SharePoint User Profile Store with the new account UPNs that
you added when you configured Office 365. For information
about how to run profile sync, see Manage user profile
synchronization in SharePoint Server.
5. Configure inbound connectivity Configure authentication from Office 365 to SharePoint

Server.
6. Configure a reverse proxy device for SharePoint Configure a reverse proxy device for your on-premises
Server hybrid environment.
7. Display hybrid federated search results in SharePoint Configure your search service application to display search
Online results from SharePoint Server in Office 365.
See also
Concepts
Configure hybrid Business Connectivity Services -
roadmap

This article provides the roadmap for configuring hybrid Microsoft Business Connectivity Services between
SharePoint Online in Office 365 for enterprises and SharePoint Server.
Follow these steps in the order shown. If you already completed a step when you did a different roadmap, skip that
step and go to the next.
STEP DESCRIPTION
Management service.
3. Configure server-to-server authentication from Configure server-to-server authentication between SharePoint

SharePoint Server to SharePoint Online Server and Office 365.
4. Synchronize user profiles Run SharePoint user profile synchronization to update the
SharePoint User Profile Store with the new account UPNs that
you added when you configured Office 365. For information
about how to run profile sync, see Manage user profile
synchronization in SharePoint Server.
5. Configure inbound connectivity Configure authentication from Office 365 to SharePoint

Server.
6. Configure a reverse proxy device for SharePoint Configure a reverse proxy device for your on-premises
Server hybrid environment.
7. Deploy a Business Connectivity Services hybrid Deploy the Business Connectivity Services solution.
solution in SharePoint
See also
Concepts
Configure the hybrid infrastructure

The articles in this section describe how to configure the underlying infrastructure that you need to create a hybrid
environment with SharePoint Server and Office 365 for enterprises. Be sure to follow a SharePoint hybrid
roadmap when following the procedures in these articles.

**This article is part of a roadmap of procedures for configuring SharePoint hybrid solutions. Be sure you're
following a roadmap when you do the procedures in this article. **

You have to set up some basic integration between Office 365 for enterprises and SharePoint Server before you
can configure a hybrid environment. Do the following steps as described in this article:
1. Sign up for Office 365.
2. Register your domain with Office 365.
3. Assign UPN domain suffixes.
4. Synchronize accounts with Office 365.
5. Assign licenses to your users.
You might have already done some of these steps. If so, there's no need to repeat them. But be sure you do each
of the steps in the order shown above before you configure a hybrid environment.
1. Sign up for Office 365

You need an Office 365 subscription in order to set up a hybrid environment with SharePoint Server. If you're
planning to configure hybrid OneDrive for Business, be sure to subscribe to a plan that includes OneDrive for
Business. All other hybrid SharePoint hybrid scenarios require an Enterprise plan that includes SharePoint
Online.
2. Register your domain with Office 365

When you sign up for Office 365, you're given an initial domain name that looks like contoso.onmicrosoft.com.
However, in order to configure a hybrid environment with SharePoint Server, you must register a public domain
that you own (such as contoso.com) in Office 365. For detailed information on how to do this, see Work with
domain names in Office 365.
3. Assign a UPN domain suffix

You have to create a UPN domain suffix in your on-premises Active Directory domain that matches the public
domain—for example, contoso.com. Then, you have to assign the UPN domain suffix to each user account that
you want to synchronize or federate.
The following procedures show how to manually do these tasks. If you have many users whom you want to
federate, we recommend that you put all federated user accounts into an organizational unit (OU ), and then
create a script that will change the UPN domain suffix for each user account in that OU. For supported guidance
on DirSync filtering, see Configure filtering for directory synchronization. For information about how to create a
script for this, see How Can I Assign a New UPN to All My Users.
To create the UPN suffix in your on-premises DNS
1. On the Active Directory server, open Active Directory Domains and Trusts.
2. In the left pane, right-click the top-level node, and then click Properties.
3. In the UPN suffixes dialog box, enter the domain suffix in the Alternative UPN suffixes box that you
want for hybrid, and then click Add > OK.
For more information, see Add user principal name suffixes (https://go.microsoft.com/fwlink/?LinkId=392430).
To manually assign a UPN domain suffix to users
1. In Active Directory Users and Computers, in the left pane, click the Users node.
2. In the Name column, right-click the user account that you want to federate, and then click Properties.
3. In the Properties dialog box, click the Account tab.
4. Select the UPN domain suffix that you added in the previous procedure from the drop-down list, as shown
in the following picture.
5. Repeat steps 2 through 4 for each additional user account that you want to federate.
4. Synchronize user accounts with Office 365

In order to configure a hybrid environment, you must synchronize your on-premises Active Directory Domain
Services user accounts with Office 365 by configuring one of the following:
Directory synchronization with password synchronization
Directory synchronization with single sign-on (SSO )
If you choose the SSO option, you can also configure password synchronization if you want to as a backup for
SSO, but you must configure at least one of the two (password synchronization or SSO ).
For detailed information on how to configure these options, see Office 365 integration with on-premises
environments.
5. Assign licenses to your users

Your users must each have a license in Office 365 in order to be able to use hybrid features. Once your accounts
are synchronized, assign licenses to your users.
Set up SharePoint services for hybrid environments

Set up SharePoint services for hybrid

SharePoint Server services such as My Sites, User Profiles, and Managed Metadata can be challenging to deploy
and can require a lot of planning. If you plan to make use of these services in depth, we highly recommend that
you follow the detailed planning information for My Sites, User Profiles, and Managed Metadata.
However, SharePoint Server hybrid scenarios, such as hybrid Search require several services to be running in
SharePoint Server, but they do not require them to be extensively configured. In this article, we're going to look at
the easy path to getting these services running on your farm for use in a hybrid configuration. You can do more
extensive configuration of these services later if you want to use more of the available features.
Note that if you're using SharePoint Server 2013, you need to turn on some services manually. (We call this out in
the appropriate procedures later in the article.) If you're using SharePoint Server 2016, these services are handled
automatically by MinRole.
Services for hybrid deployments in SharePoint Server

SharePoint Server hybrid configurations all require the following services to be running on your farm:
User Profile Service application
My Sites
If you're setting up OneDrive for Business, these are the only services you need. If you're setting up a hybrid
Search or hybrid sites features, there are some additional requirements that we'll cover in the next section.
If you've already configured these services, there's no need to add additional instances of them for hybrid, but be
sure to see Configure hybrid specific settings for important configuration information for the User Profile Service
for SharePoint and BCS hybrid deployments.
Let's look at how to set up each.
To turn on the Managed Metadata Web Service (SharePoint Server 2013 only)
1. In Central Administration, under System Settings, click Manage services on server.
2. On the server drop-down list, choose Change Server.
3. Choose the server where you want to run the Managed Metadata Web Service.
4. In the Service list, click Start for the Managed Metadata Web Service.
You need to create a Managed Metadata service application.
2. Click New, and then click Managed Metadata Service.
4. In the Database Name box, type a name for the database.
5. Under Application Pool, choose SharePoint Web Services Default from the Use existing
application pool list.
6. Click OK.
That's all the configuration that you need to do for the Managed Metadata service if you're configuring a hybrid
scenario. If you want to make further use of the Managed Metadata service, see Plan for managed metadata in
SharePoint Server.
**My Sites **
The first thing we need to do is to create a web application for the My Sites site. We recommend that My Sites be
in a separate web application, although the web application can be in an application pool that is shared with other
collaboration sites, or it can be in a separate application pool but in a shared IIS website.
The default settings for this web application will work fine for a hybrid environment, or you can customize any
that you need to for your organization.
To create a web application
1. In Central Administration, in the Application Management section, click Manage web applications.
2. On the ribbon, click New.
3. On the Create New Web Application page, in the Authentication section, select the authentication
mode that will be used for this web application.
4. 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 website on which to install your new web application.
Click Create a new IIS web site, and then type the name of the website in the Name box.
You can also provide the port number, host header, or path for the new IIS website.
5. In the Security Configuration section, select an authentication provider, whether to allow anonymous
access, and whether to use Secure Sockets Layer (SSL ).
If you want to use an existing application pool, click Use existing application pool, and then select the
application pool from the drop-down menu.
If you want to create a new application pool, click Create a new application pool, type the name of the
application pool, and either select the account that the application pool will run under or create a new
managed account for the application pool to run under.
7. In the Database Name and Authentication section, select the database server, database name, and
authentication method for your new web application.
the name of a specific failover database server that you want to associate with a content database.
available to the web application.
12. When the Application Created page appears, click OK.
Next, we need to create the site collection that will host users' My Sites.
To create a My Site Host site collection
1. On Central Administration, in the Application Management section, click Create site collections.
2. On the Create Site Collection page, in the Web Application section, select the web application that you
just created for My Sites.
4. In the Web Site Address section, select the path of the URL for the My Site host. In most cases, you can
use the root directory (/).
5. In the Template Selection section, click the Enterprise tab, and then select My Site Host.
6. In the Primary Site Collection Administrator section, type the user name (in the form <DOMAIN>\
<user name>) for the user who will be the site collection administrator.
template in the Select a quota template list.
9. Click OK.
The Top-Level Site Successfully Created page will appear when the My Site Host site collection is created.
Although you can click the link to browse to the root of the site collection, doing this results in an error because
the user profile cannot be loaded. This behavior is to be expected; user profiles are not imported at this point.
User Profile Service
If you're running SharePoint Server 2013, then you need to turn on the User Profile Service on at least one server
in your farm.
To turn on the User Profile Service (SharePoint Server 2013 only)
2. On the Server drop-down list, choose Change Server.
3. Choose the server where you want to run the User Profile Service.
4. In the Service list, click Start for the User Profile Service.
NOTE
Do not turn on the User Profile Synchronization Service. We'll do that later after we've configured the User Profile
Next, let's create a User Profile service application.
To create a User Profile service application
2. Click New, and then click User Profile Service Application.
5. In the My Site Host URL box, type the URL of the My Site Host that you created.
6. Optionally change other settings to meet the needs of your organization. The default settings work fine for
hybrid environments.
7. Click OK.
If you're using SharePoint Server 2013, the next step is to turn on the User Profile Synchronization Service. Be
sure that you turn it on on the server that you specified as the Profile Synchronization Instance when you created
the service application.
To turn on the User Profile Synchronization Service (SharePoint Server 2013 only)
3. Choose the server that you specified as the Profile Synchronization Instance.
4. In the Service list, click Start for the User Profile Synchronization Service.
5. Type the credentials for the account shown, and click OK.
NOTE
This service can take several minutes or longer to start. Refresh the page occasionally until you see a status of
Started.
Next, we'll configure the App Management Service.

** App Management Service **
If you're using SharePoint Server 2013, you need to turn on the App Management Service on at least one server
in your farm.
To turn on the App Management Service (SharePoint Server 2013 only)
3. Choose the server where you want to run the Managed Metadata Web Service.
4. In the Service list, click Start for the App Management Service.
You need to create an App Management service application.
To create a App Management service application
2. Click New, and then click App Management Service.
3. Type a name for the service application in the Service Application Name box.
5. Click OK.
Configure hybrid specific settings
Hybrid uses the Microsoft SharePoint Foundation Subscription Settings Service which is turned off by default in
SharePoint Server. Use the following procedure to turn it on.
To turn on the Microsoft SharePoint Foundation Subscription Settings Service
1. In Central Administration, under System Settings, click Manage services in this farm.
2. For the Microsoft SharePoint Foundation Subscription Settings Service, click Enable Auto
Provision
You must also have a Subscription Settings service application and proxy. These must be created by using
Microsoft PowerShell. Use the example script provided at New -SPSubscriptionSettingsServiceApplication.
** Active Directory Domain Services synchronization connection **
For hybrid, we need a synchronization connection with Active Directory Domain Services for the User Profile
service. If you haven't already configured one, use the following procedure to do so.
To configure a synchronization connection
2. Click the User Profile service application.
3. Click Configure Synchronization Connections.
4. Click Create New Connection.
5. Type a name for the connection in the Connection Name box.
6. In the Forest name box, type the name of your domain, for example, contoso.com.
7. Type the user name and password of your domain administrator.
8. Click Populate Containers.
9. Expand the domain node, and select the check box for the object where your users are located.
10. Click OK.
Next, we'll verify some user properties in the User Profile Service.
The Work email user property needs to contain the email address that you configured for each user in Active
Directory Directory Services. Also, the User Principal Name property must be mapped to the
userPrincipalName attribute. Use the following procedure to verify both of these mappings.
To verify user profile properties
3. Click Manage User Properties.
4. In the Property Name column, confirm that User Principal Name is mapped to userPrincipalName in
the Mapped Attribute column.
5. In the Property Name column, confirm that Work email is mapped to mail in the Mapped Attribute
column.
If either of these properties is not mapped as described, you need to update the mapping.
Synchronize user profiles
After you verify the user property mappings, we need to synchronize the UPN domain suffix and email address
that we configured in Active Directory Domain Services. To do this, you have to start a profile synchronization.
To start profile synchronization manually
1. On the SharePoint Central Administration website, in the Application Management section, click
3. On the Manage Profile Service page, in the Synchronization section, click Start Profile
Synchronization.
4. On the Start Profile Synchronization page, select Start Incremental Synchronization to synchronize
the profiles that you have updated.
5. Click OK.
NOTE
Refresh the Manage Profile Service page to view the profile synchronization status.
That's all the configuration that you need to do for the App Management Service. Next, move on to the next step
in your roadmap.
Configure server-to-server authentication from
SharePoint Server to SharePoint Online

NOTE
We recommend using the SharePoint Hybrid Picker to establish the Server-to-Server authentication between SharePoint
Server and SharePoint Online. If you are unable to use the Hybrid Picker for any reason, follow the steps in this article to
enable server-to-server authentication.

This article provides guidance for the SharePoint hybrid environment deployment process, which integrates
SharePoint Server and SharePoint Online.
TIP
For the most reliable outcome, complete the procedures in the order they are shown in this article.
Verify web application settings

In SharePoint hybrid, federated users can send requests to SharePoint Online from any SharePoint Server web
application that's configured to use Integrated Windows authentication with NTLM.
For example, you have to make sure that the on-premises search center site(s) that you want to use in your
solution are configured to use Integrated Windows authentication with NTLM. If they're not, you have to either
reconfigure the web application to use Windows authentication with NTLM or use a search center site on a web
application that meets this requirement. You also have to make sure that the users who expect search results to be
returned from SharePoint Online are federated users.
To verify that a web application meets the requirement
1. Confirm that the user account that will do this procedure is a member of the Farm Administrators
SharePoint group.
2. In Central Administration, click Application Management > Manage web applications.
3. In the Name column, select the web application that you want to verify, and then on the ribbon, click
Authentication Providers.
4. In the Authentication Providers dialog box, in the Zone column, click the zone the search center site is
associated with.
5. In the Edit Authentication dialog box, verify that Integrated Windows authentication and NTLM are
selected as shown in the following picture.
Configure OAuth over HTTP (if it is required)
By default, OAuth in SharePoint Server requires HTTPS. If you configured your primary web application to use
HTTP instead of SSL, you have to enable OAuth over HTTP on every web server in your SharePoint Server
farm.
NOTE
If you configured your primary web application to use SSL, this step is not required.
To enable OAuth over HTTP, run the following commands as a farm administrator account from the SharePoint
2016 Management Shell command prompt on each web server in your SharePoint Server farm.
$serviceConfig = Get-SPSecurityTokenServiceConfig
$serviceConfig.AllowOAuthOverHttp = $true
$serviceConfig.Update()
If you have enabled OAuth over HTTP for testing but want to reconfigure your environment to use SSL, you can
disable OAuth over HTTP by running the following commands as a farm administrator account from the
SharePoint 2016 Management Shell command prompt on each web server in your SharePoint Server farm.
$serviceConfig = Get-SPSecurityTokenServiceConfig
$serviceConfig.AllowOAuthOverHttp = $false
$serviceConfig.Update()
Configure server-to-server authentication between on-premises

SharePoint Server and SharePoint Online
This section will help you set up server-to-server authentication among:
SharePoint Server
SharePoint Online
Azure Active Directory
When you set up server-to-server authentication for hybrid environments, you create a trust relationship
between your on-premises SharePoint farm and your SharePoint Online tenant, which uses Azure Active
Directory as a trusted token signing service. By adding the required PowerShell modules and snap-ins, this
process can occur in a single PowerShell window on an on-premises SharePoint web server.
TIP
You'll want to keep a record of your steps, the PowerShell cmdlets you run, and any errors that you might encounter. You
should capture all the contents of the PowerShell buffer when you have finished and before you close the window. This will
give you a history of the steps that you took, which will be helpful if you have to troubleshoot or explain the process to
others. This can also be useful to refresh your memory if the setup happens in stages.
Here's a high-level view of the procedures you have to complete in this section:
1. Configure the Security Token Service (STS ) in SharePoint Server:
Create a new STS certificate.
Replace the default STS certificate on each server in your SharePoint Server farm.
2. Install online service management tools on a web server in your SharePoint Server farm.
3. Configure server-to-server authentication:
Set variables you'll be using in later steps.
Upload the new on-premises STS certificate to SharePoint Online.
Add a Service Principal Name (SPN ) to Azure.
Register the SharePoint Online application principal object ID with on-premises SharePoint Server.
Configure a common authentication realm between your on-premises SharePoint Server farm and
SharePoint Online.
Configure an Azure Active Directory application proxy on-premises.
Install online service management tools and configure the Windows PowerShell window
To continue, you need to install these tools on an on-premises SharePoint Server web server:
The Microsoft Online Services Sign-In Assistant
The Azure Active Directory Module for Windows PowerShell
The SharePoint Online Management Shell
This is most easily accomplished on a web server in your SharePoint farm because it's easier to load the
Microsoft.SharePoint.PowerShell snap-in on the web servers than on servers that don't have SharePoint Server
installed.
Authentication to SharePoint Server, SharePoint Online, and Azure Active Directory requires different user
accounts. For information about how to determine which account to use, see Accounts needed for hybrid
configuration and testing.
NOTE
To make it easier to complete the steps in this section, we'll open a PowerShell Command Prompt window on a SharePoint
Server web server and add the modules and snap-ins that let you connect to SharePoint Server, SharePoint Online, and
Azure Active Directory. (We'll give you detailed steps on how to do this later in this article.) We'll then keep this window
open to use for all the remaining PowerShell steps in this article.
To install the online service management tools and configure the PowerShell window:
1. Install the online service management tools:
2. Install the Microsoft Online Services Sign-In Assistant:
Microsoft Online Services Sign-In Assistant for IT Professionals BETA (64 bit version)
(https://go.microsoft.com/fwlink/?LinkId=391943)
For additional information, see Microsoft Online Services Sign-In Assistant for IT Professionals RTW
(https://go.microsoft.com/fwlink/?LinkId=392322).
3. Install the latest version of the Azure Active Directory Module for Windows PowerShell
4. Install the SharePoint Online Management Shell:
SharePoint Online Management Shell (64 bit version) (https://go.microsoft.com/fwlink/?LinkId=392323)
For additional information, see Introduction to the SharePoint Online management shell
5. Open a PowerShell window.
6. To help ensure that you don't fill the buffer and lose any of your command history, increase the buffer size
of the PowerShell window:
7. Click the upper-left corner of the PowerShell window, and then click Properties.
8. In the PowerShell Properties window, click the Layout tab.
9. Under Screen Buffer Size, set the Height field to 9999, and then click OK.
10. This step loads the modules you downloaded so you can use them in your PowerShell session. Copy the
following commands into your PowerShell session, and press Enter.
Add-PSSnapin Microsoft.SharePoint.PowerShell
Import-Module Microsoft.PowerShell.Utility
Import-Module MSOnline -force
Import-Module MSOnlineExt -force
Import-Module Microsoft.Online.SharePoint.PowerShell -force
If you need to run any of the configuration steps again later, remember to run these commands again to load
the required modules and snap-ins in PowerShell.
5. Configure remoting in Microsoft PowerShell:

From the PowerShell command prompt, type the following commands.
enable-psremoting
new-pssession
For more information, see [about_Remote_Requirements](https://go.microsoft.com/fwlink/?LinkId=392326)

6. To log on to your SharePoint Online tenant, from the PowerShell command prompt, type the following
commands.
$cred=Get-Credential
Connect-MsolService -Credential $cred
You are prompted to log on. You need to log on using an Office 365 global administrator account.
Leave the PowerShell window open until you've completed all the steps in this article. You need it for a
variety of procedures in the following sections.
Configure server-to -server (S2S ) authentication

Now that you installed the tools to enable you to remotely administer Azure Active Directory and SharePoint
Online, you're ready to set up server-to-server authentication.
About the variables you'll create
This section describes the variables you will set in the procedure that follows. These variables contain important
information used in many of the remaining configuration steps.
Variable Comments
$spcn The root domain name of your public domain. This value
should not be in the form of a URL; it should be the domain
name only, with no protocol.
An example is adventureworks.com.
$spsite The internal URL of your on-premises primary web

application, such as http://sharepoint or
https://sharepoint.adventureworks.com. This value is a full
URL using the proper protocol (either http: // or https:// ).
This is the internal URL of the web application that you are
using for hybrid functionality.
An example is http://sharepoint or
https://sharepoint.adventureworks.com.
$site The object of your on-premises primary web application. The

command that populates this variable gets the object of the
site you specified in the $spsite variable.
This variable is automatically populated.
$spoappid The SharePoint Online application principal ID is always

00000003-0000-0ff1-ce00-000000000000. This generic
value identifies SharePoint Online objects in an Office 365
tenant.
$spocontextID The context ID (ObjectID) of your SharePoint Online tenant.

This value is a unique GUID that identifies your SharePoint
Online tenant.
This value is automatically detected when you run the
command to set the variable.
$metadataEndpoint The URL that is used by your Azure Active Directory proxy to
connect to your Azure Active Directory tenancy.
You don't need to input a value for this variable.
Step 1: Set variables
Now that you identified the variables that you need to set, use these instructions to set them. Pre-populating the
most commonly used variables should help you do the remaining steps faster. These variables remain populated
as long as you don't close the PowerShell session. Be careful to provide accurate information wherever you see
angle brackets (< >), and always remove the angle brackets before you run the command. Don't alter the code
outside of the angle brackets.
NOTE
If you have to do any of these configuration steps again later, you should begin by running the following PowerShell
commands in this step to repopulate the important variables.
Copy the following variable declarations and paste them into a text editor like Notepad. Set the input values
specific to your organization. From the PowerShell command prompt you configured with the online service
management tools, run the commands.
$spcn="*.<public_root_domain_name>.com"
$spsite=Get-Spsite <principal_web_application_URL>
$site=Get-Spsite $spsite
$spoappid="00000003-0000-0ff1-ce00-000000000000"
$spocontextID = (Get-MsolCompanyInformation).ObjectID
$metadataEndpoint = "https://accounts.accesscontrol.windows.net/" + $spocontextID + "/metadata/json/1"
After you populate these variables, you can view their values by entering the variable name in the PowerShell
window. For example, entering $metadataEndpoint returns a value similar to the following:
https://accounts.accesscontrol.windows.net/00fceb75-246c-4ac4-a0ad-7124xxxxxxxx/metadata/json/1
Step 2: Upload the STS certificate to SharePoint Online
In this step, you upload the STS certificate for your SharePoint Server farm to your SharePoint Online tenant,
which enables SharePoint Server and SharePoint Online to connect to and consume each other's service
applications.
The commands in this step add the new on-premises STS certificate (public key only) to the SharePoint Online
principal object of your Office 365 tenancy.
$stsCert=(Get-SPSecurityTokenServiceConfig).LocalLoginProvider.SigningCertificate
$binCert = $stsCert.GetRawCertData()
$credValue = [System.Convert]::ToBase64String($binCert);
New-MsolServicePrincipalCredential -AppPrincipalId $spoappid -Type asymmetric -Usage Verify -Value $credValue
Step 3: Add an SPN for your public domain name to Azure Active Directory
In this step, you add a service principal name (SPN ) to your Azure Active Directory tenant. The SPN is comprised
of the SharePoint Online principal object and your company's public DNS namespace.
Just like SPNs function in Active Directory, creating this SPN registers an object in Azure Active Directory that is
used to support mutual authentication between SharePoint Server and your SharePoint Online tenant. The basic
syntax for the SPN is:
<service type>/<instance name>
where:
<service type> is the SharePoint Online principal object, which is the same for all SharePoint Online
tenants.
<instance name> is the URL of your company's public DNS domain namespace, which is always expressed
as a wildcard, even if the Secure Channel SSL Certificate is a SAN certificate.
Here's an example:
00000003-0000-0ff1-ce00-000000000000/*.<public domain name>.com
If the common name in your certificate is sharepoint.adventureworks.com, the syntax of the SPN will look like
this:
00000003-0000-0ff1-ce00-000000000000/*.adventureworks.com
Using a wildcard value lets SharePoint Online validate connections with any host in that domain. This is useful if
you ever need to change the host name of the external endpoint (if your topology includes one) or if you want to
change your SharePoint Server web application, in the future.
To add the SPN to Azure Active Directory, enter the following commands in the Azure Active Directory Module
for Windows PowerShell command prompt.
$msp = Get-MsolServicePrincipal -AppPrincipalId $spoappid

$spns = $msp.ServicePrincipalNames
$spns.Add("$spoappid/$spcn")
Set-MsolServicePrincipal -AppPrincipalId $spoappid -ServicePrincipalNames $spns
To validate that the SPN was set, enter the following commands in the Azure Active Directory Module for
Windows PowerShell command prompt.
$msp = Get-MsolServicePrincipal -AppPrincipalId $spoappid

$spns = $msp.ServicePrincipalNames
$spns
You should see a current list of SPNs for SharePoint Online in your Office 365 tenancy, and one of the SPNs
should include your public root domain name, prefaced by the SharePoint Online application principal ID. This
registration is a wildcard registration and should look like the following example:
00000003-0000-0ff1-ce00-000000000000/*..com
This should be the only SPN in the list that includes your public root domain name.
Step 4: Register the SharePoint Online application principal object ID with SharePoint Server
This step registers the SharePoint Online application principal object ID with the on-premises SharePoint
Application Management Service, which allows SharePoint Server to authenticate to SharePoint Online using
OAuth.
$spoappprincipalID = (Get-MsolServicePrincipal -ServicePrincipalName $spoappid).ObjectID

$sponameidentifier = "$spoappprincipalID@$spocontextID"
$appPrincipal = Register-SPAppPrincipal -site $site.rootweb -nameIdentifier $sponameidentifier -displayName
"SharePoint Online"
To validate this step, from the PowerShell command prompt, type the $appPrincipal variable:
$appPrincipal | fl
The expected output is a description of the registered application principal with the name SharePoint Online,
which should look something like this.
Step 5: Set the SharePoint authentication realm
This step sets the authentication realm of your SharePoint Server farm to the context ID of the organization's
Office 365 tenancy.
From the PowerShell command prompt, type the following command.
Set-SPAuthenticationRealm -realm $spocontextID
To validate this step, from the PowerShell command prompt, type the following commands.
$spocontextID
Get-SPAuthenticationRealm
The output of each of these commands is the GUID that represents the context ID of the SharePoint Online
tenancy. These GUIDs should be identical.
IMPORTANT
If you have configured farm setup scripts that specify the farm authentication realm value, you should update the setup
scripts with this new value before you run them again. > For more information about the requirements for realm values in
farm setup scripts, see Plan for server-to-server authentication in SharePoint Server. Because you have now configured this
SharePoint farm to participate in the hybrid configuration, the SharePoint farm authentication realm value must always
match the tenant context identifier. If you change this value, the farm will no longer participate in hybrid functionality.
Step 6: Configure an on-premises proxy for Azure Active Directory
In this step, you create an Azure Active Directory proxy service in the SharePoint Server farm. This enables Azure
Active Directory as a trusted token issuer that SharePoint Server will use to sign and authenticate claims tokens
from SharePoint Online.
New-SPAzureAccessControlServiceApplicationProxy -Name "ACS" -MetadataServiceEndpointUri $metadataEndpoint -

DefaultProxyGroup
New-SPTrustedSecurityTokenIssuer -MetadataEndpoint $metadataEndpoint -IsTrustBroker:$true -Name "ACS"
To validate the New-SPAzureAccessControlServiceApplicationProxy command:

1. Browse the SharePoint 2016 Central Administration website, and click Security > General Security >
Manage trust.
2. Make sure you have an entry with a name that begins with ACS and the type Trusted Service Consumer.
To validate this step, from the PowerShell command prompt, type the following command.
Get-SPTrustedSecurityTokenIssuer
The output that's expected is a description of the farm's trusted token issuer, where the value of the
RegisteredIssuerName property is the following:
00000001-0000-0000-c000-000000000000@where <context ID> is the context ID of your SharePoint Online
tenancy, which is the value in the $spocontextID variable.
Validation and next steps

After finishing the tasks in this topic and its validation steps, you should check your SSO and Directory
Synchronization setup.
So that you have a history of the steps you've taken, you should capture the entire contents of the PowerShell
buffer into a file. This will be crucial if you need to reference your configuration history to troubleshoot, or for any
other reasons. This will also help you pick up where you left off if the configuration spans multiple days or
involves multiple people.
After you have completed and validated the configuration tasks in this topic, continue with your configuration
roadmap.
See also
Run Hybrid Picker

following a roadmap when you do the procedure in this article. **
Hybrid Picker is located in Office 365 for enterprises, and you can use it to help you configure certain hybrid
scenarios between Office 365 and SharePoint Server.
NOTE
If you're using a pop-up blocker with your browser, be sure to turn it off before running the hybrid picker.
To run Hybrid Picker

1. Log on to the console of a SharePoint Server farm server as a farm administrator.
2. From the farm server, connect to Office 365 as a global administrator.
3. Navigate to https://go.microsoft.com/fwlink/?linkid=867176
4. Follow the prompts in Hybrid Picker to configure your hybrid features.
Configure connectivity from Office 365 to SharePoint
Server

This article contains guidance the SharePoint hybrid environment deployment process, which integrates
SharePoint Server and SharePoint Online.
Before you begin

**Accessibility note:**SharePoint Server supports the accessibility features of common browsers to help you
administer deployments and access sites. For more information, see Accessibility for SharePoint 2013.
If you haven't already done this, read Plan connectivity from Office 365 to SharePoint Server before you start to
configure anything.This is important because the planning article helps you make important decisions and record
them on the SharePoint hybrid deployment worksheet, referred to in the rest of this article as the worksheet. This
in turn informs which procedures in this article to use and which you can skip over.
If you've read the planning article, you should have already done the following:
Decided which site collection strategy you'll configure for hybrid.
Decided whether to use an existing web application or create one for hybrid.
These decisions are recorded in Table 2 of the worksheet. If

not, go back and read Plan connectivity from Office 365 to
SharePoint Server and make these decisions before you go
any further.
Worksheet tips
Things will go a lot easier if all of the applicable information is entered on the SharePoint hybrid worksheet before
you start to configure anything. At a minimum, you need to know the following things to use this article.
Table: Decisions that should already be recorded on the SharePoint hybrid worksheet
DECISION LOCATION ON THE WORKSHEET
Will you use an existing web application for hybrid or create New or existing web application row of Table 2
one?
What site collection strategy will you use? Site collection strategy row of Table 2
What's the External URL? External URL row of Table 3
What's the IP address of the Internet-facing endpoint on the IP address of the external endpoint row of Table 3
reverse proxy device that the external URL is associated with?
Verify that these decisions are entered on the worksheet before you continue.
Configuration phases
In order to configure the environment infrastructure, you'll need both SharePoint Server interfaces, such as the
SharePoint Central Administration website, and the Administration pages in SharePoint Online. To prevent you
from having to switch between these interfaces more than necessary, we've organized the configuration steps into
the following phases:
Prepare your public domain
Create and configure a target application for the SSL certificate in SharePoint Online
Please complete each configuration step in the order shown in this article.
IMPORTANT
It is recommended that you thoroughly document your deployment strategy and that you maintain detailed work logs
during the hybrid environment configuration process. In any complex implementation project, a detailed record of every
design decision, server configuration, procedure, and output is a very important reference for troubleshooting, support, and
awareness.
Prepare your public domain

In order for Office 365 to send requests to the external endpoint of your reverse proxy device, you need to have
the following things:
A public domain registered with a domain registrar, such as GoDaddy.com, that the URL of the external
endpoint of the reverse proxy device is associated with.
An A record in your public domain's DNS zone that's associated with the published SharePoint site (which
is the External URL, such as spexternal.adventureworks.com). This enables Office 365 to send requests to
the external endpoint on the reverse proxy device that's configured for hybrid. This A record maps the
External URL to the IP address of the Internet-facing endpoint of the reverse proxy device. For more
information, see Plan connectivity from Office 365 to SharePoint Server.
If you don't yet have a public domain that you want to use for this purpose (such as adventureworks.com), get one
now, and then create this A record. If you already took care of this during the planning phase, the name of your
public domain and the IP address that you need to create this A Record are recorded in Table 3 of the worksheet.
You have to complete the steps in the Add your domain to Office 365 article to add the host name of your public
domain to Office 365.

This section tells you how to configure the SharePoint Server farm for use in an inbound hybrid solution. We've
organized the steps for this section into the following phases. For the most reliable outcome, complete the
procedures in the order shown.
Configure a site collection strategy
Assign a UPN domain suffix
Synchronize user profiles
Configure OAuth over HTTP (if it's required)
NOTE
The procedures in this section assume that you have an existing SharePoint Server farm that you intend to use for hybrid
functionality.
Configure a site collection strategy

In a hybrid environment, data is exchanged between the root site collection in SharePoint Online and a specific
web application in the on-premises SharePoint farm that's configured for hybrid. We call this the primary web
application. This web application is the focal point on which your site collection strategy is configured.
During the planning phase, you should have decided whether you'll use an existing web application or create one
and which site collection strategy you'll configure. If so, your decisions are listed in the Site collection strategy
row of Table 2 of the worksheet. If you haven't decided yet, review the Plan connectivity from Office 365 to
SharePoint Server article and make these decisions before you go any further.
Choose one of the following site collection strategies to configure:
Configure a site collection strategy by using a host-named site collection
Configure a site collection strategy by using a path-based web application without AAM
Configure a site collection strategy by using a path-based web application with AAM
Configure a site collection strategy by using a host-named site collection
If you want to configure a site collection strategy by using a host-named site collection for the SharePoint hybrid
environment, complete these steps in the order shown:
1. Ensure that the web application and root site collection exist.
2. Ensure that an SSL binding exists on the primary web application.
3. Create the host-named site collection.
4. Configure split DNS.
5. Create an A record in the on-premises DNS.
For more information about site collection strategy decisions, see the Choose a site collection strategy section of
Plan connectivity from Office 365 to SharePoint Server.
Ensure that the primary web application and root site collection exist
The host-named site collection that you'll create a bit later has to be created in a web application that's configured
to use the following:
Integrated Windows Authentication with NTLM
https protocol (Secure Sockets Layer)
You also need a path-based site collection to use as the root site collection in this web application.
If you identified a web application that you want to use during

planning, it should be listed in the Primary web application
URL row of Table 5a of the worksheet.
If the web application and root site collection don't exist, you'll have to create them. You can do this by using either
Central Administration or the SharePoint 2016 Management Shell. If they already exist, go to Ensure that an SSL
binding exists on the primary web application.
Here's an example for how to create a web application by using SharePoint 2016 Management Shell.
New-SPWebApplication -Name 'Adventureworks Web app' -SecureSocketsLayer -port 443 -ApplicationPool

AdventureworksAppPool -ApplicationPoolAccount (Get-SPManagedAccount 'adventureworks\abarr') -
AuthenticationProvider (New-SPAuthenticationProvider -UseWindowsIntegratedAuthentication)
Where:
The name of the web application is Adventureworks Web app.
The port number of the web application is 443.
Record the port number that you chose in the Port number
of the web application row of Table 5a of the worksheet.
The new web application uses a web application pool named AdventureworksAppPool.
The web application runs as the managed account adventureworks\abarr.
The web application is created by using Windows Integrated Authentication with NTLM.
Here's an example for how to create the root site collection by using the SharePoint 2016 Management
Shell.
New-SPSite 'https://sharepoint' -Name 'Portal' -Description 'Adventureworks Root site collection' -OwnerAlias
'adventureworks\abarr' -language 1033 -Template 'STS#0'
Where:
The host name of the SharePoint farm is "sharepoint".
The primary administrator is adventureworks\abarr.
The site template uses the English language (1033).
The template (STS#0) is the Team Site template.
For more information about how to create a web application and root site collection for a host-named site
collection, see Create claims-based web applications in SharePoint Server and Host-named site collection
architecture and deployment in SharePoint Server.
Ensure that an SSL binding exists on the primary web application
Because this web application is configured to use SSL, you have to ensure that an SSL certificate is bound to the
primary web application. For production environments, this certificate should be issued by a public certification
authority (CA). For test and development environments, this can be a self-signed certificate. We call this the on-
premises SharePoint SSL certificate.
TIP
This is typically a separate certificate from the one that you'll later install on the reverse proxy device. For more information
about these certificates, see the Plan SSL certificates section of Plan connectivity from Office 365 to SharePoint Server.
After the certificate is bound to the web application, you'll be able to see this host name in the Issued To field in
the Server Certificates dialog box in Internet Information Services (IIS ). For more information, see How to Set
Up SSL on IIS 7.0.
Create the host-named site collection
After the web application and root site collection are in place, the next step is to create a host-named site collection
within the primary web application. The public URL of this site collection must be identical to the external endpoint
URL.
NOTE
Host-named site collections must be created by using the SharePoint 2016 Management Shell. You can't use Central
Administration for creating this type of site collection.
Here's an example of how to create a host-named site collection by using the SharePoint 2016
Management Shell.
New-SPSite 'https://spexternal.adventureworks.com' -HostHeaderWebApplication 'https://sharepoint' -Name

'https://spexternal.adventureworks.com' -Description 'Site collection for hybrid' -OwnerAlias
'adventureworks\abarr' -language 1033 -Template 'STS#0'
Where:
https://spexternal.adventureworks.com is the URL of the host-named site collection. This URL must be
identical to the External URL.
https://sharepoint is the web application that the site collection is created in.
For more information, see Host-named site collection architecture and deployment in SharePoint Server.
Configure split DNS
You have to configure split DNS. This is a common configuration that's used to help ensure that on-premises client
computers resolve a server name to internal IP addresses, even though public DNS resolution resolves the same
service name to a completely different public IP address. This enables users to be redirected to an endpoint that
uses standard SharePoint security-enhanced mechanisms for authentication, but queries from Office 365 can be
directed through a reverse proxy configured to use certificate authentication.
For more information about how to use split DNS in a hybrid topology, see Architecture Design Recommendation
for SharePoint 2013 Hybrid Search Features. For information about how to configure a split DNS, see A faulty
split-brain DNS configuration can prevent a seamless SSO sign-in experience.
Create an A record in the on-premises DNS
The reverse proxy device must be able to resolve the internal URL of the host-named site collection. You can do
this by creating an A record in the desired on-premises DNS namespace. This doesn't have to be in the same
namespace as the reverse proxy device. However, the reverse proxy device must be able to resolve this namespace.
This A record maps the host name of the External URL to the IP address of the on-premises SharePoint farm.
Here's an example of an A record where the External URL is https://spexternal.adventureworks.com, and the IP
address of the network load balancer for the SharePoint farm is 10.0.0.13.
The External URL is recorded in the External URL row of Table
3 of the worksheet.
You have finished configuring the site collection strategy by using a host-named site collection for hybrid. Now,
skip ahead to Assign a UPN domain suffix.
Configure a site collection strategy by using a path-based web application without AAM
If you want to configure a site collection strategy by using a path-based web application without the need to create
an Alternate Access Mapping (AAM ) for the SharePoint hybrid environment, complete these steps in the order
shown:
1. Ensure that the web application exists.
2. Ensure that an SSL binding exists on the primary web application.
3. Configure split DNS.
4. Create an A record in the on-premises DNS.
NOTE
When you configure a site collection strategy without AAM, the public URL of the primary web application must be identical
to the External URL.
For more information, see the Choose a site collection strategy section of Plan connectivity from Office 365 to
SharePoint Server.
Ensure that the primary web application exists
You can use an existing web application as the primary web application, or you can create one. You should have
made this decision during planning and recorded it in the New or existing web application row of Table 2 of
the worksheet. If you haven't made this decision yet, refer to Plan connectivity from Office 365 to SharePoint
Server and decide before you go any further. Remember that when you configure a site collection strategy without
AAM, the public URL of the primary web application must be identical to the External URL.
If during planning, you decided which existing web application to use as the primary web application, its URL
should be recorded in the Primary web application URL row of Table 5b of the worksheet. If so, skip ahead to
Ensure that an SSL binding exists on the primary web application. Otherwise, to create a web application to use as
the primary web application, use the procedures in Create claims-based web applications in SharePoint Server.
In general, you should use the default settings. However, the following configuration settings are required.
Required configuration settings
LOCATION DESCRIPTION
In the IIS Web Site section, in the Port box Type the port number that you want this web application to
use—for example, 443.
In the Security Configuration section Ensure that Allow Anonymous is set to No.
In the Security Configuration section Ensure that Use Secure Sockets Layer (SSL) is set to Yes.
You'll have to bind an SSL certificate to the web application,
which we discuss more in the next section.
In the Claims Authentication Types section Select the Enable Windows Authentication check box, select
the Integrated Windows authentication check box, and in
the drop-down menu, select NTLM.
In the Public URL section, in the URL box Type the External URL—for example,
https://spexternal.adventureworks.com.
By default, SharePoint appends the port number to the
default URL that it recommends for this field. When you
replace that URL with the external URL, don't append the port
number.
To make things easier for yourself in later procedures, we recommend that you do the following.
Get the URL from the Public URL section of the Create New
Web Application page in Central Administration, and record
it in the Primary web application URL row of Table 5b of
the worksheet.
Ensure that an SSL binding exists on the primary web application
You have to ensure that an SSL certificate is bound to the primary web application. For production environments,
this certificate should be issued by a public certification authority (CA). For test and development environments,
this can be a self-signed certificate. We call this the on-premises SharePoint SSL certificate.
TIP
This is typically a separate certificate from the one that you'll later install on the reverse proxy device, but you can use the
Secure Channel SSL certificate for this if you want to. For more information about these certificates, see the Plan SSL
certificates section of Plan connectivity from Office 365 to SharePoint Server.
The host name of the web application must be in the Subject field of the SSL certificate. After the certificate is
bound to the web application, you can see this host name in the Issued To field in the Server Certificates dialog
box in Internet Information Services (IIS ). For more information, see How to Set Up SSL on IIS 7.0.
Configure split DNS
You have to configure split DNS. This is a common configuration that's used to help ensure that on-premises client
computers resolve a server name to internal IP addresses, even though public DNS resolution resolves the same
service name to a completely different public IP address. This enables users to be redirected to an endpoint that
uses standard SharePoint security-enhanced mechanisms for authentication, but queries from Office 365 can be
directed through a reverse proxy that's configured to use certificate authentication.
For more information about how to use split DNS in a hybrid topology, see Architecture Design Recommendation
for SharePoint 2013 Hybrid Search Features. For information about how to configure a split DNS, see A faulty
split-brain DNS configuration can prevent a seamless SSO sign-in experience.
Create an A record in the on-premises DNS
The reverse proxy device must be able to resolve the internal URL of the host-named site collection. You can do
this by creating an A record in the desired on-premises DNS namespace. This doesn't have to be in the same
namespace as the reverse proxy device. However, the reverse proxy device must be able to resolve this namespace.
This A record maps the host name of the External URL to the IP address of the on-premises SharePoint farm.
Here's an example of an A record where the External URL is https://spexternal.adventureworks.com and the IP
address of the network load balancer for the SharePoint farm is 10.0.0.13.
The External URL is recorded in the External URL row of Table

3 of the worksheet.
You have finished configuring the site collection strategy by using a path-based site collection without AAM for
hybrid. Now, skip ahead to Assign a UPN domain suffix.
Configure a site collection strategy by using a path-based web application with AAM
If you want to use a path-based web application with Alternate Access Mapping (AAM ) for your site collection
strategy, complete these steps in the order shown:
1. Ensure that the primary web application exists.
2. Extend the primary web application, and configure AAM.
3. Ensure that an SSL binding exists on the primary web application (if it is needed).
4. Configure AAM.
5. Create a CNAME record.
If you've already configured a different name mapping type, go to Assign a UPN domain suffix.
The following video demonstrates how a site collection strategy works with a path-based web application with
AAM.
Video: Understanding URLs and host names
Ensure that the primary web application exists

You can use an existing web application as the primary web application, or you can create one. If you haven't made
this decision yet, refer to Plan connectivity from Office 365 to SharePoint Server and decide before you go any
further.
If during planning, you decided which existing web application to use as the primary web application, its URL
should be recorded in the Primary web application URL row of Table 5c of the worksheet. If so, skip ahead to
Extend the primary web application. Otherwise, to create a web application to use as the primary web application,
use the procedures in Create claims-based web applications in SharePoint Server. The SharePoint hybrid
configuration is not affected by the initial configuration of this web application when you configure this site
collection strategy. This is because you'll apply the settings that you need for hybrid when you extend the web
application a bit later. So you can use any settings that you want when you create a web application.
To make things easier for yourself in later procedures, we

recommend that you record this information when you create
the web application:
Get the URL from the Public URL section of the Create New
Web Application page in Central Administration, and record
it in the Primary web application URL row of Table 5c of
the worksheet.
Extend the primary web application
This section explains how to extend your web application. Extending the web application creates a new IIS website
that you'll assign the External URL to as the public URL.
When you've completed the procedures in this section, you'll have two IIS websites. Both are connected to the
same content database. The original IIS website will be unchanged and can continue to be accessed by internal
users. The extended web application will use a different zone, such as the Internet zone, and will be configured to
use the External URL as the public URL. This extended web application is used only for servicing SharePoint
hybrid requests.
IMPORTANT
Ensure that you perform these procedures on the specific web applications that you intend to use as the primary web
application for SharePoint hybrid solutions. The URL of this web application that you have to extend is recorded in the
Primary web application URL row of Table 5c of the worksheet.
To extend the web application, use the procedures in Extend claims-based web applications in SharePoint. In
general, you should use the default settings. But, the following configuration settings are required.
Required configuration settings
In the IIS Web Site section, in the Port box Ensure that the value is set to the appropriate port number
for one of the following:
If you decide to extend the primary web application for
unencrypted HTTP connections, use port 80 or the HTTP
port specified by the network administrator who configures
the reverse proxy device. All inbound service connections from
the reverse proxy device to the web application's site collection
have to use HTTP.
If you decide to configure the primary web application for
encrypted HTTPS connections, use port 443 or the SSL port
specified by the network administrator who configures the
reverse proxy device. All inbound service connections from the
reverse proxy device to the web application's site collection
have to use HTTPS.
In the Security Configuration section Ensure that Allow Anonymous is set to No.
In the Security Configuration section Choose the appropriate value for Use Secure Sockets Layer
(SSL). If you choose No, the web application will use
unencrypted HTTP. If you choose Yes, the web application
will use encrypted HTTPS, and you must bind an SSL
certificate to the extended web application. We discuss this
certificate more in the next section.
In the Claims Authentication Types section Select the Enable Windows Authentication check box, select
the Integrated Windows authentication check box, and in
the drop-down menu, select NTLM.
In the Public URL section, in the URL box Type the External URL—for example,
https://spexternal.adventureworks.com.
Note that by default, SharePoint appends the port number to
the default URL that it recommends for this field. When you
replace that URL with the external URL, don't append the port
number.
In the Public URL section, in the Zone list Select the zone that you want to assign to this extended web
application. We recommend that you set the Zone value to
Internet if it's available.
Ensure that an SSL binding exists on the primary web application (if it's needed)
If you configured the extended web application to use SSL, you'll have to ensure that an SSL certificate is bound to
the web application that you extended in the previous section. Otherwise, if you configured the extended web
application for HTTP (unencrypted), skip ahead to Configure AAM.
For production environments, this certificate should be issued either by a public or an enterprise certification
authority (CA). For test and development environments, this can be a self-signed certificate. We call this the on-
premises SharePoint SSL certificate.
IMPORTANT
This certificate must have the bridging host name of the URL in the Subject field. For example, if the bridging URL is
https://bridge, the Subject field of the certificate must contain bridge. Therefore, this certificate can't be created by using
IIS. But you can use a certificate creation tool such as MakeCert.exe to create it. After the certificate is bound to the web
application, you can see this host name in the Issued To field in the Server Certificates dialog box in Internet Information
Services (IIS).
TIP
This is typically a separate certificate from the one that you'll later install on the reverse proxy device. For more information
about these certificates, see the Plan SSL certificates section of Plan connectivity from Office 365 to SharePoint Server.
For more information about how to set up SSL, see A guide to https and Secure Sockets Layer in SharePoint
2013.
Configure AAM
To enable SharePoint Server to dynamically translate links in requests by using the External URL, follow these
steps.
To configure AAM
1. In Central Administration, in the Quick Launch, click Application Management.
2. In the Web Applications section, click Configure alternate access mappings.
3. On the Alternate Access Mappings page, click Add Internal URLs.
4. In the Alternate Access Mapping Collection section, click the down arrow, and then click Change
Alternate Access Mapping Collection. In the dialog box that is displayed, select the primary web
application that you're configuring for hybrid.
The URL of this web application is recorded in the Primary

web application URL row of Table 5c of the worksheet.
5. In the Add Internal URL section, in the URL protocol, host and port box, type the URL you want to use as
the bridging URL. This URL must have the same protocol as the extended web application, either http or https.
For example, if you configured the extended web application by using https, the URL will resemble
https://bridge.
The protocol that you used is recorded in the Protocol of the

extended web application row of Table 5c of the worksheet.
Record this URL in the Bridging URL row of Table 5c of the
worksheet.
6. In the Zone drop-down menu, select the same zone that you used when you extended the web application.
This zone is recorded in the Zone of the extended web

application row of Table 5c of the worksheet
7. Click Save.
The URL that you specified in step 5 appears in the Internal URL column of the Alternate Access
Mappings page.
Create a CNAME record
You need to create a CNAME record in the on-premises DNS. This record maps the host name of the Bridging
URL to the fully qualified domain name of the on-premises SharePoint farm. The Bridging URL is the one that you
assigned to the AAM in the previous section. The reverse proxy device must be able to query DNS to resolve the
alias to the IP address of the on-premises SharePoint farm.
Here's an example CNAME record where the host name is Bridge, based on the bridging URL, https://bridge.
To verify that the alias name you chose for your CNAME record is resolving to the SharePoint Server farm, do the
following verification step.
Verification step
1. Log on to the reverse proxy device as administrator and open a Windows command prompt.
2. Ping the alias name in the CNAME record. For example, if the alias name is Bridge, then type the following
and press Enter.
ping bridge
The command prompt should return the IP address of the SharePoint farm that's specified in the CNAME record.
If not, verify that the fully qualified domain name of the SharePoint farm is correctly specified in the CNAME
record and then repeat these verification steps.
> [!NOTE]
> If the `ping` command is blocked on the network, try using either the `tracert -4` or the `pathping -4`
command instead.
Create and configure a target application for the SSL certificate in

SharePoint Online
In this section, you create and configure a Secure Store target application in SharePoint Online. This target
application is used to store the Secure Channel SSL certificate and enable it so that it can be used by SharePoint
Online services when users request data from the on-premises SharePoint farm. We refer to this target application
as the Secure Channel Target Application.
To follow these steps, you need the information recorded in

Table 4a of the worksheet.
NOTE
You can use either a certificate that contains a private key, such as a Private Information Exchange (.pfx) file or you can use
an Internet Security Certificate File (.cer). If you use a .pfx file, you must provide a password for the private key later in this
procedure.
When you configure SharePoint hybrid solutions in Phase 4: Configure a hybrid solution, you'll provide the name
of the target application that you created so that SharePoint Online Search and Business Connectivity Services can
get the Secure Channel SSL certificate that's needed to authenticate with the reverse proxy device.
To create a target application to store the Secure Channel SSL certificate
1. Verify that you're logged on to Office 365 as a global administrator.
2. In the SharePoint Online Administration Center, in the navigation pane, choose secure store.
3. On the Edit tab, choose New.
4. In the Target Application Settings section, do the following:
5. In the Target Application ID box, type the name (which will be the ID ) that you want to use for the target
application—for example, we recommend that you name it SecureChannelTargetApplication. Do not
use spaces in this name.
NOTE
You create the ID in this step—you do not receive the ID from elsewhere. This ID is a unique target application name
that cannot be changed.
Record this name in the Target Application ID row of Table 6

of the worksheet.
2. In the Display Name box, type the name that you want to use as the display name for the new target
application. For example, Secure Channel Target App.
Record this name in the Target Application Display Name

row of Table 6 of the worksheet.
3. In the Contact E -mail box, type the name of the primary contact for this target application.
4. In the Credential Fields section, do the following:
5. In the Field Name column, in the first row, delete any existing text that is in the box, and then type
Certificate.
6. In the Field Type column, in the first row, in the drop-down list, select Certificate.
7. In the Field Name column, in the second row, delete any existing text that is in the box, and then type
Certificate Password.
NOTE
You must follow this step only if you are importing the certificate from a certificate that contains a private key, such
as a Private Information Exchange (.pfx) file.
8. In the Field Type column, in the second row, in the drop-down list, select Certificate Password.
The credentials section should resemble the following illustration.
9. In the Target Application Administrators section, in the box, type the names of users who will have
access to manage the settings of this target application. Make sure to add any users who will test the hybrid
configuration so that they can make changes, if it's needed.
10. In the Members section, in the box, type the names of the Azure AD users and groups that you want to
enable to use hybrid solutions.
The Office 365 global administrator can create Azure AD groups. These are domain groups, not SharePoint
groups.
A list of these users, or the group they were added to, is listed
in the Federated Users row of Table 1 of the worksheet.
8. Click OK.
9. Select the check box next to the ID of the target application that you created—for example,
SecureChannelTargetApp.
This name is listed in the Target Application Display Name

row of Table 6 of the worksheet.
10. On the Edit tab, in the Credentials group, click Set.

11. In the set credentials for secure store target application dialog box, do the following:
12. Next to the Certificate field, click Browse.
13. Browse to the location of the Secure Channel SSL certificate, select the certificate, and then click Open.
The name and location of this certificate is recorded in the

Secure Channel SSL Certificate location and filename row
of Table 4b of the worksheet.
3. If the certificate you're using contains a private key, such as a Private Information Exchange (.pfx) file, then in
the Certificate Password field, type the password of the certificate. Otherwise, go to step 12.
The password is recorded in the Secure Channel SSL
Certificate password row of Table 4b of the worksheet.
4. In the Confirm Certificate Password field, retype the password of the certificate.
5. Click OK.
For more information, see Configure the Secure Store Service in SharePoint Server.

After you complete the configuration tasks in this topic, you should validate the following items:
Verify that your public Internet domain name can be resolved in DNS.
Verify that you can connect to the primary web application by using both the internal and external URLs.
Verify that you can successfully access an on-premises site collection within the primary web application
from the Internet by using the external URL of your reverse proxy endpoint. The computer that you use for
this validation step must have the Secure Channel SSL certificate installed in the Personal certificate store
of the computer account.
After you have completed and validated the configuration tasks in this topic, return to your configuration roadmap.
Configure a reverse proxy device for SharePoint
Server hybrid

This topic provides an overview of the role of reverse proxy devices in a SharePoint Server hybrid deployment
and links to device-specific configuration guidance.
The role of a reverse proxy in a SharePoint Server hybrid deployment

SharePoint Server and SharePoint Online can be configured in a hybrid configuration to securely combine search
results and external data from Microsoft Business Connectivity Services. Reverse proxy devices play a role in the
secure configuration of a hybrid SharePoint Server deployment when inbound traffic from SharePoint Online
needs to be relayed to your on-premises SharePoint Server farm. For example, if a federated user uses a
SharePoint Online search portal that is configured to return hybrid search results, a reverse proxy device
intercepts and pre-authenticates the request for on-premises SharePoint Server content and then relays it to
SharePoint Server. The reverse proxy device in a hybrid topology provides a secure endpoint for inbound traffic
using SSL encryption and client certificate authentication.
How inbound connectivity works
The following diagrams show how a reverse proxy device is used for inbound connectivity.
With an inbound search solution, only the SharePoint Online site has search results from both locations.
Inbound connectivity
In the example below, a federated user on the Internet uses the SharePoint Online search portal to search for
content in both SharePoint Online and her company's on-premises SharePoint Server server.
A federated user on the Internet searches for content that's located on her company's on-premises
server.
The following list describes the steps shown in the preceding picture.
1. From the Internet, a federated user browses to her SharePoint Online site.
2. SharePoint Online queries the search index in SharePoint Online and also sends the search query to the
external URL of the on-premises SharePoint farm which resolves to the external endpoint of the reverse
proxy device.
3. The reverse proxy device pre-authenticates the request using the Secure Channel SSL certificate and
relays the request to the URL of the primary web application.
4. The SharePoint farm service account queries the on-premises search index and security trims the search
results in the context of the user who sent the search request.
5. Security trimmed search results are returned to SharePoint Online and displayed on the search results
page. This result set includes search results from the SharePoint Online search index and search results
from the search index of the SharePoint Server farm.
NOTE
Inbound connectivity enables access to content and resources in your on-premises SharePoint Server farm from the
internet only if the user has an active, secure connection to the intranet network over VPN or DirectAccess or if the
SharePoint Server farm is configured in an extranet topology.
For a more detailed description of this process, that shows how certificates are used and authentication and
authorization work in this topology, see Poster: SharePoint 2013 Hybrid Topology: Certificate, Authentication, and
Authorization flow.
General reverse proxy requirements
In a hybrid SharePoint Server scenario, the reverse proxy must be able to:
Support client certificate authentication with a wildcard or SAN SSL certificate.
Support pass-through authentication for OAuth 2.0, including unlimited OAuth bearer token transactions.
TIP
No ports other than TCP 443 need to be opened on the external reverse proxy endpoint to support hybrid
connectivity.

Relay traffic to an on-premises SharePoint Server farm or load balancer without rewriting any packet
headers.
Supported reverse proxy devices

The table below lists the currently supported reverse proxy devices for SharePoint Server hybrid deployments.
This list will be updated as new devices are tested for supportability. Follow the steps in the configuration article
for the reverse proxy device that you want to use. When you've completed configuring the reverse proxy device,
return to your roadmap.
SUPPORTED REVERSE PROXY DEVICES CONFIGURATION ARTICLE ADDITIONAL INFORMATION
Azure Application Proxy Enable remote access to SharePoint Azure Application Proxy is an Azure
with Azure AD Application Proxy service that allows remote access to
services within your network without
opening firewall ports from the Internet
to your service.
Windows Server 2012 R2 with Web Configure Web Application Proxy for a Web Application Proxy (WA-P) is a
Application Proxy (WA-P) hybrid environment Remote Access service in Windows
Server 2012 R2 that publishes web
applications that users can interact with
from many devices.
> [!IMPORTANT]> To use Web
Application Proxy as a reverse proxy
device in a hybrid SharePoint Server
environment, you must also deploy AD
FS in Windows Server 2012 R2.
Forefront Threat Management Configure Forefront TMG for a hybrid Forefront TMG 2010 is a
Gateway (TMG) 2010 environment comprehensive, secure, web gateway
solution that provides secure reverse
proxy functionality.
> [!NOTE]> Forefront TMG 2010 is no
longer sold by Microsoft but will be
supported through 4/14/2020. For
more information, see Microsoft
Support Lifecycle information for TMG
2010.
SUPPORTED REVERSE PROXY DEVICES CONFIGURATION ARTICLE ADDITIONAL INFORMATION
F5 BIG-IP Enabling SharePoint 2013 Hybrid External content managed by F5

Search with the BIG-IP Networks.
Citrix NetScaler Citrix NetScaler and Microsoft External content managed by Citrix.
SharePoint 2013 Hybrid Deployment
Guide
See also
Concepts
Configure Web Application Proxy for a hybrid
environment

This article describes Web Application Proxy and helps you set it up to use as a reverse proxy for a hybrid
SharePoint Server environment.
Before you begin

Accessibility note: SharePoint Server supports the accessibility features of common browsers to help you
administer deployments and access sites. For more information, see Accessibility for SharePoint 2013.
About Web Application Proxy in a hybrid environment

Web Application Proxy is a Remote Access service in Windows Server 2012 R2 that publishes web applications
that users can interact with from many devices. It also includes proxy functionality for Active Directory Federation
Services (AD FS ). This helps system administrators provide secure access to an AD FS server. By using Web
Application Proxy, system administrators choose how users authenticate themselves to a web application and can
determine who is authorized to use one.
In hybrid SharePoint Server environments in which SharePoint Online requests data from SharePoint Server, you
can use Windows Server 2012 R2 with Web Application Proxy as a reverse proxy device to securely relay requests
from the Internet to your on-premises SharePoint Server farm.
IMPORTANT
To use Web Application Proxy as a reverse proxy device in a hybrid SharePoint Server environment, you must also deploy AD
FS in Windows Server 2012 R2.
NOTE
To install and configure the Web Application Proxy feature, you must be a local administrator on the computer where
Windows Server 2012 R2 is installed. The Windows Server 2012 R2 server running the Web Application Proxy feature can be
a member of a domain or a workgroup.
Step 1: Install AD FS and the Web Application Proxy feature

For information about installing AD FS in Windows Server 2012 R2, see Active Directory Federation Services
Overview.
For information about installing the Web Application Proxy feature in Windows Server 2012 R2, see Install Server
Roles and Features on a Server Core Server.
Step 2: Configure the Web Application Proxy

This section describes how to configure the Web Application Proxy feature after it is installed:
1. Web Application Proxy matches the thumbprint against the secure channel certificate, which must be
imported and installed in the local computer's Personal certificate store on the Web Application Proxy
server.
2. Configure Web Application Proxy with a published application that can accept inbound requests from your
SharePoint Online tenant.
Import the Secure Channel SSL certificate
You must import the Secure Channel SSL certificate into the Personal store of the local computer account and
then set permissions on the certificate's private key to allow the service account of the Web Application Proxy
Service (appproxysvc) Full Control.
NOTE
The default service account of the Web Application Proxy Service is the local computer Network Service.
The location of the Secure Channel SSL certificate is

recorded in Row 1 (Secure Channel SSL Certificate location
and Filename) of Table 4b: Secure Channel SSL Certificate.
If the certificate contains a private key, you will need to
provide the certificate password, which is recorded in Row 4
(Secure Channel SSL Certificate password) of Table 4b:
Secure Channel SSL Certificate.
For information about how to import an SSL certificate, see Import a Certificate.
Configure the published application
NOTE
The steps in this section can be performed only by using Windows PowerShell.
To configure a published application to accept and relay requests from your SharePoint Online tenant, type the
following Microsoft PowerShell command.
Add-WebApplicationProxyApplication -ExternalPreauthentication ClientCertificate -ExternalUrl <external URL> -

BackendServerUrl <bridging URL> -name <friendly name of the published application> -
ExternalCertificateThumbprint <certificate thumbprint> -ClientCertificatePreauthenticationThumbprint
<certificate thumbprint> -DisableTranslateUrlInRequestHeaders:$False -
DisableTranslateUrlInResponseHeaders:$False
Where:
<externalUrl> is the external URL for the web application. This is the public URL to which SharePoint Online
will send inbound requests for SharePoint Server content and resources.
The external URL is recorded in Row 3 (External URL) of Table

3: Public Domain Info in the SharePoint Hybrid worksheet.
<bridging URL> is the internal URL you configured for the primary web application in your on-premises
SharePoint Server farm. This is the URL to which Web Application Proxy will relay inbound requests from
SharePoint Online.
The bridging URL is recorded in one the following locations in
the SharePoint Hybrid worksheet:
If your primary web application is configured with a host-
named site collection , use the value in Row 1 (Primary web
application URL) of Table 5a: Primary web application
(host-named site collection).
If your primary web application is configured with a path-
based site collection , use the value in Row 1 (Primary web
application URL) of Table 5b: Primary web application
(path-based site collection without AAM).
based site collection with AAM , use the value in Row 5
(Primary web application URL) of Table 5c: Primary web
application (path-based site collection with AAM).
<friendly name of the published application> is a name you choose to identify the published application in
Web Application Proxy.
<certificate thumbprint> is the certificate thumbprint, as a string with no spaces, of the certificate to use for
the address specified by the ExternalUrl parameter. This value should be entered twice, once for the
ExternalCertificateThumbprint parameter and again for the ClientCertificatePreauthenticationThumbprint
parameter.
This is the thumbprint of the Secure Channel SSL

certificate. The location of this certificate file is recorded in
Row 1 (Secure Channel SSL Certificate location and Filename)
of Table 4b: Secure Channel SSL Certificate.
For additional information about the Add-WebApplicationProxyApplication cmdlet, see Add-

WebApplicationProxyApplication.
Validate the published application

To validate the published application, use the Get-WebApplicationProxyApplication cmdlet. Type the following
Microsoft PowerShell command.
Get-WebApplicationProxyApplication |fl
The output should resemble the content in the following table.
ADFSRelyingPartyID :<populated at run time>
ADFSRelyingPartyName :<relying party name>
BackendServerAuthenticationMode :ADFS
BackendServerAuthenticationSPN : None
BackendServerCertificateValidation : None
BackendServerUrl : https://<bridging URL>/
ClientCertificateAuthenticationBindingMode : None
ClientCertificatePreauthenticationThumbprint : : <certificate thumbprint>
DisableTranslateUrlInRequestHeaders : False
DisableTranslateUrlInResponseHeaders : False
ExternalCertificateThumbprint : <certificate thumbprint>
ExternalPreauthentication : PassThrough
ExternalUrl : https://<external URL>/
ID : 91CFE805-44FB-A8A6-41E9-6197448BEA72
InactiveTransactionsTimeoutSec : 300
Name : <friendly name of the published application>
UseOAuthAuthentication : False
PSComputerName :
Troubleshooting
Web Application Proxy logs events and errors to the Application and Remote Access Windows Server event logs.
Logging plays an important role in troubleshooting issues with connectivity and authentication between
SharePoint Server and SharePoint Online. Identifying the component that is causing a connection failure can be
challenging, and reverse proxy logs are the first place you should look for clues. Troubleshooting can involve
comparing log events from Web Application Proxy event logs, SharePoint Server ULS logs, Windows Server event
logs, and Internet Information Services (IIS ) logs on multiple servers.
For more information on troubleshooting techniques and tools for SharePoint Server hybrid environments, see
Troubleshooting hybrid environments.
See also
Concepts
Configure Forefront TMG for a hybrid environment

This article tells you how to set up Forefront Threat Management Gateway (TMG ) 2010 for use as a reverse proxy
for a hybrid SharePoint Server environment.
For complete information about Forefront Threat Management Gateway (TMG ) 2010, see Forefront Threat
Management Gateway (TMG ) 2010.
Before you begin

Before you begin, there are a few things you need to know:
TMG has to be deployed in an edge configuration, with at least one network adapter connected to the
Internet and configured for the external network in TMG and at least one network adapter connected to the
intranet network and configured for the internal network in TMG.
The TMG server has to be a domain member in the Active Directory domain forest that contains your
Active Directory Federation Services (AD FS ) 2.0 server. The TMG server has to be joined to this domain to
use SSL client certificate authentication, which is used for authenticating inbound connections from
SharePoint Online.
[!SECURITY NOTE ] As a general best practice for edge deployments, you normally install Forefront
TMG in a separate forest (rather than in the internal forest of your corporate network), with a one-way
trust to the corporate forest. However, you can configure client certificate authentication only for users
in the domain to which the TMG server is joined, so this practice cannot be followed for hybrid
environments. > For more information on TMG network topology considerations, see Workgroup and
domain considerations.
Deploying TMG 2010 for use in a SharePoint Server hybrid environment in a back-to-back configuration is
theoretically possible but has not been tested and may not work.
TMG 2010 includes both diagnostic logging and a real-time logging interface. Logging plays an important
role in troubleshooting issues with connectivity and authentication between SharePoint Server and
SharePoint Online. Identifying the component that is causing a connection failure can be challenging, and
TMG logs are the first place you should look for clues. Troubleshooting can involve comparing log events
from TMG logs, SharePoint Server ULS logs, Windows Server event logs, and Internet Information
Services (IIS ) logs on multiple servers.
For more information on how to configure and use logging in TMG 2010, see Using diagnostic logging.
For more information on general TMG 2010 troubleshooting, see Forefront TMG Troubleshooting.
For more information on troubleshooting techniques and tools for SharePoint Server hybrid environments, see
Troubleshooting hybrid environments.
Install TMG 2010

If you have not already installed TMG 2010 and configured it for your network, use this section to install TMG
2010 and prepare the TMG system.
Install TMG 2010
1. Install Forefront TMG 2010 if it is not already installed. For more information on installing TMG 2010, see
Forefront TMG Deployment.
2. Install all the available service packs and updates for TMG 2010. For more information, see Installing
Forefront TMG Service Packs.
3. Join the TMG server computer to the on-premises Active Directory domain if it is not already a domain
member.
For more information on deploying TMG 2010 in a domain environment, see Workgroup and domain
considerations.
Import the Secure Channel SSL certificate

You must import the Secure Channel SSL certificate into both the Personal store of the local computer account
and the Personal store of the Microsoft Forefront TMG Firewall service account (fwsvc).
The location of the Secure Channel SSL certificate is

recorded in Row 1 (Secure Channel SSL Certificate location
and Filename) of Table 4b: Secure Channel SSL Certificate.
If the certificate contains a private key, you will need to
provide the certificate password, which is recorded in Row 4
(Secure Channel SSL Certificate password) of Table 4b:
Secure Channel SSL Certificate.
Import the certificate

1. Copy the certificate file from the location specified in the worksheet to a folder on the local hard disk.
2. On the reverse proxy server, open MMC and add the Certificate Management snap-in for both the local
computer account and the local fwsrv service account.
NOTE
After TMG 2010 has been installed, the friendly name of the fwsrv service is the Microsoft Forefront TMG Firewall
service.
3. Import the Secure Channel SSL certificate to the Personal certificate store of the computer account.
4. Import the Secure Channel SSL certificate to the Personal certificate store of the fwsrv service account.
For more information about how to import an SSL certificate, see Import a Certificate.
Configure TMG 2010

In this section, you configure a web listener and a publishing rule that will receive inbound requests from
SharePoint Online and relay them to the primary web application of your SharePoint Server farm. The web
listener and publishing rule work together to define the connection rules and to pre-authenticate and relay the
requests. You configure the web listener to authenticate inbound connections using the Secure Channel certificate
you installed in the last procedure.
For more information on configuring publishing rules in TMG, see Configuring Web publishing.
For more information on SSL bridging in TMG 2010, see About SSL bridging and publishing.
Use the following procedure to create the publishing rule and web listener.
Create the publishing rule and web listener
1. In the Forefront TMG Management Console, in the left navigation pane, right-click Firewall Policy, and
then click New.
2. Select SharePoint Site Publishing Rule.
3. In the New SharePoint Publishing Rule Wizard, in the Name text box, type the name of the publishing
rule (for example, "Hybrid Publishing Rule"). Click Next.
4. Select Publish a single Web site or load balancer, and then click Next.
5. To use HTTP for the connection between TMG and your SharePoint Server farm, select Use non-secured
connection to connect the published Web server or server farm, and then click Next.
To use HTTPS for the connection between TMG and your SharePoint Server farm, select Use SSL to
connect the published Web server or server farm, and then click Next.
NOTE
If you use SSL, ensure that you have a valid certificate installed on the primary web application.
6. In the Internal Publishing Details dialog box, in the Internal site name text box, type the internal DNS
name of the bridging URL , and then click Next. This is the URL that the TMG server will use to relay
requests to the primary web application.
NOTE
Do not type the protocol (http:// or https://).
The Bridging URL is recorded in one the following locations in

the SharePoint Hybrid worksheet:
If your primary web application is configured with a host-
named site collection , use the value in Row 1 (Primary web
application URL) of Table 5a: Primary web application
(host-named site collection).
based site collection , use the value in Row 1 (Primary web
application URL) of Table 5b: Primary web application
(path-based site collection without AAM).
based site collection with AAM , use the value in Row 5
(Primary web application URL) of Table 5c: Primary web
application (path-based site collection with AAM).
7. In the Use a computer name or IP address to connect to the published server box, optionally type the
IP address or the fully qualified domain name (FQDN ) of the primary web application or network load
balancer, and then click Next.
NOTE
If TMG can resolve the primary web application using the host name you provided in the previous step, you do not
have to perform this step.
8. In the Public Name Details dialog box, accept the default setting on the Accept requests for menu. In
the Public name text box, type the host name of your External URL (for example,
"sharepoint.adventureworks.com"), and then click Next. This is the host name in the external URL that
SharePoint Online will use to connect with your SharePoint Server farm.
NOTE
Do not type the protocol (http:// or https://).
The External URL is recorded in Row 3 (External URL) of Table

3: Public Domain Info in the SharePoint Hybrid worksheet.
9. In the Select a Web Listener dialog box, select New.

10. In the New Web Listener Wizard dialog box, in the Web listener name text box, type a name for the web
listener, and then click Next.
11. In the Client Connection Security dialog box, select Require SSL secured connections with clients, and
then click Next.
12. In the Web Listener IP Addresses dialog box, select External <All IP addresses>, and then click Next.
If you want to restrict the listener to listen only on a specific external IP address, click the Select IP
Addresses button, and then in the External Network Listener IP Selection dialog box, select Specified
IP addresses on the Forefront TMG computer in the selected network. Click Add to specify an IP
address, and then click OK.
13. In the Listener SSL Certificates dialog box, select Use a single certificate for this Web Listener, and
click the Select Certificate button. In the Select Certificate dialog box, select the Secure Channel SSL
certificate you imported to the TMG computer, click Select, and then click Next.
14. In the Authentication Settings dialog box, select SSL Client Certificate Authentication, and then click
Next. This setting enforces client certificate credentials for inbound connections using the Secure Channel
certificate.
15. Click Next to bypass Forefront TMG single sign-on settings.
16. Review the New Listener summary page, and click Finish. This returns you to the Publishing Rule Wizard
in which your newly created web listener is automatically selected.
17. In the Select Web Listener dialog box, in the Web Listener drop-down menu, make sure the correct web
listener is selected, and click Next.
18. In the Authentication Delegation dialog box, select No delegation, but client may authenticate
directly from the drop-down menu, and then click Next.
19. In the Alternate Access Mapping Configuration dialog box, select SharePoint AAM is already
configured on the SharePoint server, and then click Next.
20. In the User Sets dialog box, select the All Authenticated Users entry, and click Remove. Then click Add,
and in the Add Users dialog box, select All Users, and then click Add. Click Close to close the Add Users
dialog box, and then click Next.
21. In the Completing the New SharePoint Publishing Rule Wizard dialog box, confirm your settings, and
then click Finish.
There are several settings that you must now verify or change in the publishing rule you just created.
Finalize the publishing rule configuration
1. In the Forefront TMG Management Console, in the left navigation pane, select Firewall Policy, and in the
Firewall Policy Rules list, right-click the publishing rule you just created, and click Configure HTTP.
2. In the Configure HTTP policy for rule dialog box, on the General tab, under URL Protection, confirm
that both Verify normalization and Block high bit characters are unchecked, and then click OK.
3. Right-click the publishing rule you just created again, and click Properties.
4. In the <rule name> Properties dialog box, on the To tab, uncheck the Forward the original host header
instead of the actual one box. Under Proxy requests to published site, ensure that Requests appear
to come from the original client is selected.
5. On the Link Translation tab, ensure that the Apply link translation to this rule check box is set correctly:
If the internal URL of your primary web application and the external URL are identical, uncheck the Apply
link translation to this rule check box.
If the internal URL of your primary web application and the external URL are different, check the Apply
link translation to this rule check box.
6. On the Bridging tab, under Web server, ensure that the correct Redirect requests to <HTTP port or
SSL port> check box is checked and that the port in the text box corresponds to the port your internal site
is configured to use.
7. Click OK to save your changes to the publishing rule.
8. In the Forefront TMG Management Console, on the top bar, click Apply to apply your changes to TMG. It
might take one or two minutes for TMG to process your changes.
9. To validate your configuration, right-click the new publishing rule from the Firewall Policy Rules list, and
click Properties.
10. In the <rule name> Properties dialog box, click the Test Rule button. TMG runs a series of tests to check
for connectivity to the SharePoint site and displays the results of the tests in a list. Click each configuration
test for a description of the test and its results. Fix any errors that appear.
See also
Concepts
Other Resources
Configuring Web publishing
Forefront Threat Management Gateway (TMG ) 2010
Configure a hybrid solution for SharePoint Server
Configuring and deploying one or more SharePoint hybrid solutions takes place in the final phase of the
SharePoint hybrid environment deployment process and is the ultimate reason for configuring a SharePoint
hybrid environment.
Be sure you're following a roadmap when you read the articles in this section.

This article is part of a roadmap of procedures for configuring SharePoint hybrid solutions. Be sure
you're following a roadmap when you do the procedures in this article.
You can redirect users to OneDrive for Business in Office 365 when they click OneDrive or Sites on the
navigation bar or the app launcher. In this article are the steps you need to configure your on-premises
environment to connect with OneDrive for Business in Office 365. You can find an overview of the process in Plan
for hybrid OneDrive for Business.
Video demonstration
This video shows a walkthrough of configuring hybrid OneDrive for Business.
Video: Configure hybrid OneDrive for Business
NOTE
The SharePoint Migration Tool demonstrated in the video is currently in preview. It is only supported for SharePoint Server
2013. [Download the SharePoint Migration Tool]((http://spmtreleasescus.blob.core.windows.net/install/default.htm).
Configure user permissions

To use OneDrive for Business in Office 365, your users must have Create Personal Site and Follow People and
Edit Profile permissions. Both are controlled by the user permissions in the User Profile service application.
group.
2. In your on-premises SharePoint Server environment, go to Central Administration > Manage Service
Applications.
3. Click the User Profile Service Application.
4. On the Manage Profile Service page, under People, click Manage User Permissions.
5. In the Permissions for User Profile Service Application dialog box, click All Authenticated Users (or
a specific audience that you intend to use as a pilot group of users).
6. Verify that the Create Personal Site and Follow People and Edit Profile permission check boxes are
selected.

To configure hybrid OneDrive for Business, you must be both a SharePoint Server farm administrator and an
Office 365 global administrator. Perform these steps on a server in your SharePoint Server farm.
To configure hybrid OneDrive for Business
1. In the SharePoint Online admin center, in the left navigation, click configure hybrid.
2. Click Go to Hybrid Picker Download Page.
3. On the SharePoint Hybrid Picker page, click click here.
4. Accept the security prompts to install and run the wizard.
5. On the SharePoint Hybrid Picker page, click Next.
6. On the Credentials page, verify your on-premises credentials and enter your global administrator
credentials. Click Validate credentials, and then click Next.
7. On the Checking prerequisites page, click Next.
8. On the Select the features you want to use in your hybrid environment page, select the Hybrid
OneDrive check box and deselect any other check boxes. Click Next.
9. When the configuration completes, click Next.
10. Add a rating and comments if desired, and then click Close.
Create an audience (if necessary)

If you want to redirect only a specific set of your users from your on-premises environment to OneDrive for
Business in Office 365, you need to use an audience to identify that set of users. If you have an audience set up
already that contains just those users, you can use that. Otherwise, you need to create an audience in SharePoint
Server. See Create an audience for SharePoint Server for information about how to create an audience for
SharePoint. You can also use Microsoft PowerShell cmdlets to create an audience.
To configure a OneDrive for Business redirection audience
1. On the Central Administration website, choose Office 365 > Configure hybrid OneDrive and Sites
features.
2. Choose Use a specific audience and type the audience name for the audience that contains your Office
365 users.
3. Click OK.
Verify that then OneDrive for Business links work as expected

It can take up to a minute for the changes to be updated in the User Profile service application for your on-
premises farm. Because the link may be stored in the user's browser cache, we recommend you wait 24 hours and
then verify the links are working.
To check that the links are working as expected, have one of the users in the audience that is using the Office 365
option for OneDrive for Business sign in to your on-premises environment. From the user's personal site, have the
user choose OneDrive from the navigation bar or app launcher.
If the user is redirected to Office 365 for OneDrive for Business, everything is working as expected.
If users want to browse to their OneDrive for Business directory directly, they can go to https:// <yourtenant
name>.onedrive.com in the browser. For example, https://contoso.onedrive.com will take users of Contoso
tenancy to their OneDrive for Business document library. This is a simple way to bookmark the link for users of
OneDrive for Business. Note that rich clients might not recognize this short URL.
(Optional) Create a search vertical

You can set up a search vertical so that you can search content stored in OneDrive for Business. The specific steps
to set up the search vertical are in the article Set up Search of OneDrive for Business in Office 365 from
SharePoint Server.
(Optional) Customize the Office 365 navigation experience (SharePoint

Server 2013)
Now that your users are set up to be redirected to Office 365, you can customize what they see on the navigation
bar there. By default, the navigation bar contains the following links: SkyDrive, Yammer or Newsfeed, and Sites. If
you intend for your users to use only OneDrive for Business, you can remove the other links. If you want to allow
your users to interact with Yammer or the SharePoint Newsfeed features or to create team sites in Office 365, you
can leave those links on the navigation bar.
NOTE
Turn on the appropriate navigation bar links for the set of SharePoint Online service features that you have purchased. For
example, if you have OneDrive for Business with Office on the web, then you would turn on only the OneDrive for Business
link, and not the Sites or Newsfeed links. OneDrive for Business with Office on the web does not include the Sites and
Newsfeed features and users would see Access Denied messages if they clicked the links. You can, however, still choose to
turn on Yammer as your social network and then turn on the Yammer/Newsfeed navigation link.
To customize the navigation bar

1. Log on to Office 365 with a tenant administrator account.
2. On the Admin tab, choose SharePoint.
3. Choose Settings on the left.
4. In the Top Navigation Bar User Experience section, specify the links to show or hide on the navigation
bar.
5. Choose OK to save the settings and update the navigation bar.
See also
Other Resources
Plan for hybrid OneDrive for Business
Show results from Office 365 in on-premises
SharePoint with cloud hybrid search

Learn how to show results from the Office 365 search index when searching from SharePoint Server sites with
cloud hybrid search.
After you've set up cloud hybrid search, your users get search results from both on-premises and Office 365
content when they use the search center in Office 365. However, your existing search in document libraries in
SharePoint Server, such as Team Sites, stops returning results when you've set up cloud hybrid search. If your
users need to search from Team Sites, you can set up search from SharePoint Server Team Sites to show results
from the search index in Office 365. You use the cloud Search service application to achieve this. Note that
searching from a Search Center in Office 365 will be faster than searching from a document library in SharePoint
Server because the search index and the search center are in the same environment.
Here's an overview of the cloud hybrid search solution. The light grey lines represent what you're setting up by
following the steps in this article.
Follow these steps:

1. Verify that cloud hybrid search works.
2. In the cloud search farm, create a result source that defines how to get search results from the search index
in Office 365.
3. In the cloud search farm, set that result source as the default result source for the cloud Search service
application.
4. If your existing on-premises document libraries are in SharePoint Server 2010 and/or SharePoint Server
2013, set up query federation by publishing the cloud Search service application (cloud SSA) so that
SharePoint Server 2010 and/or SharePoint Server 2013 can consume the cloud SSA.
Create a result source that defines how to get search results from the
search index in Office 365
1. Verify that the user account that you use to perform this procedure is an administrator for the cloud SSA.
2. In the cloud search farm, in Central Administration, in the Application Management section, click
3. Click the cloud SSA to which you want to add a result source.
4. On the Search Administration page for the cloud SSA, in the Quick Launch, click Result Sources.
6. On the Add Result Source page, do the following:
7. In the General Information section, in the Name text box, type a name for the new result source—for
example, Office 365 search index .
8. (Optional) In the General Information section, in the Description text box, type a description of the new
result source.
This description will appear as a tooltip when the pointer rests on the result source on certain configuration
pages.
9. In the Protocol section, select Remote SharePoint.
10. In the Remote Service URL section, type the address of the root site collection in SharePoint Online that
you want to get search results from, such as https://adventure-works.sharepoint.com.
11. In the Type section, select SharePoint Search Results.
12. In the Query Transform section, keep the default setting.
13. In the Credentials Information section, select Default Authentication.
14. Click OK to save the new result source.
Set the result source as the default result source for the cloud Search
service application
1. Verify that the user account that performs this procedure is an administrator for the cloud SSA.
2. In the cloud search farm, in Central Administration, in the Application Management section, click
3. Click the cloud SSA for which you want to set the result source as default.
4. On the Search Administration page, in the Queries and Results section, click Result Sources.
5. On the Manage Result Sources page, point to the result source that you want to set as default, click the
arrow that appears, and then click Set as Default.
Set up query federation

To set up query federation you have to publish the cloud SSA so that it can be consumed by SharePoint Server
2010 or SharePoint Server 2013. For an overview of this approach, see Share service applications across farms in
SharePoint Server and select the SharePoint Server version of the article for your consuming environment.
In each of the following steps, when you refer to the SharePoint Server documentation, use the appropriate
names and parameters for your cloud search farm and your cloud SSA.
1. Publish and share the cloud SSA, see Publish service applications in SharePoint Server.
2. Consume the cloud SSA.
Consuming a published SSA requires exchanging trust certificates between the consuming and the
publishing SharePoint on-premises farm. See Exchange trust certificates between farms in SharePoint
Server, and select the relevant SharePoint Server version of the article for your consuming environment.
3. Grant permission to connect to the cloud SSA.
Grant permission to the consuming SharePoint Server 2010 or SharePoint Server 2013 farm to be able to
connect the published cloud SSA. See Set permissions to published service applications in SharePoint
2013.
4. Connect to the cloud SSA.
Once the trust and permissions have been set between the farms, you can configure SharePoint Server
2010 or SharePoint Server 2013 to connect to the cloud SSA on your cloud search farm. See Connect to
service applications on remote farms in SharePoint 2013.
5. Configure web applications to associate with the cloud SSA.
In SharePoint Server 2010 or SharePoint Server 2013, configure the web applications to associate with the
new cloud SSA connection. See Add or remove service application connections from a web application in
SharePoint 2013.
Related Topics
Configure cloud hybrid search for SharePoint
Enable previews of on-premises search results in
cloud hybrid search

Learn how to enable display of previews of on-premises search results in a Search Center in Office 365 for cloud
hybrid search.
In cloud hybrid search, when users search in Office 365, they get search results from both on-premises and Office
365 content. When a user hovers over a search result that comes from Office 365, information about the content
as well as a preview of the content is displayed. Information about the content from search results that come from
SharePoint Server is displayed automatically, but display of previews is not automatic. You can enable such display
of previews for content from SharePoint Server 2013 and SharePoint Server 2016, but not for content from
SharePoint Server 2010. Users can click search results that come from SharePoint Server 2010, SharePoint Server
2013, and SharePoint Server 2016 to access the content.
To enable previews for on-premises content in SharePoint Server you need to set up an on-premises Office Online
Server and configure SharePoint Server to use it.
What is Office Online Server?

Office Online Server is an Office server product that lets users access their documents online using a web browser.
For SharePoint Server content farms, it's the stand-alone Office Online Server that delivers the browser-based
versions of Word, PowerPoint, Excel, and OneNote.
1. In an Office 365 Search Center, a user hovers over a search result for a Word document that's stored on a
SharePoint Server on-premises content farm.
2. The request to show a preview of the document goes to the Office Online Server. You have to ensure that
the Office Online Server is accessible from where the user is. For example, if you want to support users that
are outside the corporate network, you can make the Office Online Server accessible through a reverse
proxy.
3. The Office Online Server gets the document from the content farm and renders the document in the user's
web browser.
Turn on previews for on-premises content in SharePoint Server

Follow these procedures:
1. Deploy Office Online Server
2. Configure Office Online Server for SharePoint Server
3. Optional: Make the Office Online Server accessible outside the corporate network. You can configure your
corporate firewall to allow access from the public Internet to your Office Online Server. To do this, set the
public DNS to match the ExternalUrl value in your Office Online Server farm. This value can be set when
creating a farm using New-OfficeWebAppsFarm -ExternalUrl <value> or
Set-OfficeWebAppsFarm -ExternalUrl <value> . You must use SSL when allowing Internet access to your
Office Online Server.
Deploy the Office Online Server farm
Office Online Server needs to be on a separate server than SharePoint Server. Here are the steps for deploying the
Office Online Server farm:
1. Plan how to use the Office Web Apps Server.
2. Deploy Office Web Apps Server, here's an overview of the steps:
Prepare each server in the Office Online Server farm to run Office Online Server. This includes installing
prerequisite software of Office Online Server, installing Office Online Server and related updates, and
installing language packs for Office Online Server.
Deploy the Office Online Server farm. If you're deploying for test purposes, deploy a single server Office
Online Server farm that uses HTTP. If you're deploying for production, deploy a single server Office Online
Server farm that uses HTTPS.
Configure SharePoint Server to use the Office Online Server
1. Plan how you want to use Office Web Apps with SharePoint 2013.
2. Configure SharePoint 2013 to use Office Web Apps Server. Here's an overview of the steps:
Create a binding between SharePoint Server and the Office Online Server so traffic from the Office Online
Server can enter SharePoint Server.
Office Online Server uses zones to determine which URL (internal or external) and which protocol (HTTP or
HTTPS ) to use when it communicates with SharePoint Server. By default, SharePoint Server uses the
internal-https zone. If you've deployed Office Online Server for test purposes, set SharePoint Server to use
the internal-http zone and set SharePoint Server to allow authentication over HTTP. If you've deployed
Office Online Server for production, set SharePoint Server to use the internal-https zone.
Verify that Office Online Server is working.
See also
Other Resources
Configure cloud hybrid search for SharePoint
Display hybrid federated search results in SharePoint
Server

This article describes how to configure a SharePoint hybrid environment so that searches from the SharePoint
Server enterprise Search Center display hybrid results—that is, results from both search indexes (SharePoint
Server and SharePoint Online). This configuration is called outbound hybrid search.
The search results from SharePoint Online will appear with the search results from SharePoint Server, but in a
separate group called a result block. You can configure the block of results from SharePoint Online to be shown
above all the results from SharePoint Server, or to be ranked by relevance compared to the SharePoint Server
results.
To display hybrid search results in the SharePoint Server enterprise Search Center, in the SharePoint Server
deployment you perform the following procedures, which are described in detail this article:
Step 1: Create a result source that defines how to get search results from SharePoint Online
Step 2: Create a query rule to turn on hybrid search results in SharePoint Server 2013
Step 3: Try a search from the SharePoint Server 2013 Search Center
Step 1: Create a result source that defines how to get search results
from SharePoint Online
In this procedure, you create a result source in the SharePoint Server deployment. This result source is a definition
that specifies SharePoint Online as a provider to get search results from. This definition specifies each of the
following:
The SharePoint Online URL to get search results from
The protocol for getting those results
The method for authenticating against SharePoint Online
Result sources can be created at the Search service application level, the site collection level, or the site level. In
this procedure, you create the result source at the Search service application level. This will make the result source
available to any query rule that is created at the same level, and also to any query rule that is created for a site
collection or site that is in a web application that consumes the Search service application.
For more information about result sources, see the following resources:
Understanding result sources for search in SharePoint Server
To create the result source
1. Verify that the user account that you use to perform this procedure is an administrator for the Search
2. In the SharePoint Server deployment, in Central Administration, in the Application Management
3. Click the Search service application to which you want to add a result source.
4. On the Search Administration page for the Search service application, in the Quick Launch, click Result
Sources.
6. On the Add Result Source page, do the following:
In the General Information section, in the Name text box, type a name for the new result source—for
example, Get results from SharePoint Online.
(Optional) In the General Information section, in the Description text box, type a description of the new
result source.
pages.
In the Protocol section, select Remote SharePoint.
In the Remote Service URL section, type the address of the root site collection in SharePoint Online that
you want to get search results from, such as https://adventure-works.sharepoint.com.
In the Type section, select SharePoint Search Results.
In the Query Transform section, you can use the query transform to narrow the search results to a
specified subset—for example, a subset that is from a particular SharePoint site collection or site. However,
if you are not familiar with query transforms in SharePoint Server, we recommend that you keep the
default query transform here. The default transform is {searchTerms}, which is a query variable that stands
for the query that the user typed, as it was changed by the most recent query transform. If you are familiar
with query transforms, either keep the default query transform or type a different query transform in the
text box. You can also click Launch Query Builder if you want to use Query Builder to help you configure
a different query transform. For more information about see Plan to transform queries and order results in
SharePoint Server and Query variables in SharePoint Server.
In the Credentials Information section, select Default Authentication.
Click Save to save the new result source.
Step 2: Create a query rule to turn on hybrid search results in

In this procedure, you create a query rule in the SharePoint Server deployment. This query rule uses the result
source that you created in the previous procedure in this article. When the query rule fires, it causes search results
from the SharePoint Online search index to be displayed in a result block on a search results page in the
SharePoint Server deployment. The results from the SharePoint Online search index are displayed along with
results from the SharePoint Server search index.
Query rules can be created at the Search service application level, the site collection level, or the site level. In this
procedure, you create the query rule at the Search service application level. Because you create the rule at this
level, the rule can apply to queries that users submit in sites or site collections that consume the Search service
application.
For more information about query rules, see Plan to transform queries and order results in SharePoint Server and
2. In the SharePoint Server deployment, in Central Administration, in the Application Management
3. Click the Search service application in which you created a result source in the previous procedure in this
article (Step 1: Create a result source that defines how to get search results from SharePoint Online).
4. On the Search_service_application_name: Search Administration page, in the Quick Launch, click Query
rules.
5. On the Search_service_application_name: Manage Query Rules page, do the following:
Under the text For what context do you want to configure rules?, in the Select a Result Source
drop-down list, select a result source for which you want this query rule to be applicable.
For testing, we recommend that you select the Local SharePoint Results result source here. If you
do so, then by default the query rule will be applicable when a user performs a query in the
Everything search vertical in the enterprise Search Center, because that vertical uses the Local
SharePoint Results result source by default.
After you select a result source from the drop-down list, all existing query rules that apply to that
result source appear on the page. (On the Search_service_application_name: Add Query Rule page,
in the Context section, you will be able to add or remove result sources for which you want the rule
to be applicable.)
(Optional) Under the text For what context do you want to configure rules?, in the User
Segments drop-down list, select a user segment for which you want this query rule to be applicable.
User segments are based on terms that describe users in the term store of a Managed Metadata
service application. (On the Add Query Rule page, in the Context section, you will be able to add or
remove user segments for which you want the rule to be applicable.)
(Optional) Under the text For what context do you want to configure rules?, in the Topic
Categories drop-down list, select a topic category for which you want this query rule to be
applicable. Topic categories are based on terms for categories in the term store of a Managed
Metadata service application. (On the Add Query Rule page, in the Context section, you will be able
to add or remove categories for which you want the rule to be applicable.)
Click New Query Rule.
6. On the Search_service_application_name: Add Query Rule page, do the following:
In the General Information section, in the Rule Name text box, type a name for the new query
rule—for example, Show results from SharePoint Online.
If the Context section is collapsed, click the arrow next to Context to expand it.
In the Context section, under Query is performed on these sources, select All sources if you
want this query rule to be applicable for queries that users submit against any result source, or select
One of these sources, and then optionally click Add Source to add other result sources for which
you want the query rule to be applicable.
(Optional) Under Query is performed from these categories, specify the topic categories (based
on terms for topic categories in the term store of a Managed Metadata service application) to
perform the query from.
(Optional) Under Query is performed by these user segments, specify user segments (based on
terms that describe users in the term store of a Managed Metadata service application) to which you
want the query rule to apply.
In the Query Conditions section, specify conditions to control when the rule will fire, or click
Remove Condition if you want the rule to fire for any query text. For testing, we recommend that
you click Remove Condition so that the rule will fire for any query text.
In the Actions section, under Result Blocks, click Add Result Block.
(Optional) In the Block Title section, in the Title text box, change the title to the text that you want
to display above the result block on the search results page, such as Results for "{subjectTerms}"
from SharePoint Online.
In the Que ry section, enter the query you want to run. Either type it in the Configure Query text
box, or launch the Query Builder to get help configuring the query. If you are not familiar with
transforming queries in SharePoint Server, we recommend that you keep the default query here,
namely {subjectTerms}. For more information see Plan to transform queries and order results in
SharePoint Server and Query variables in SharePoint Server.
In the Query section, in the Search this Source drop-down list, select the name of the result source
that you created in the previous procedure in this article ( Step 1: Create a result source that defines
how to get search results from SharePoint Online)—for example, Get results from SharePoint
Online.
In the Query section, in the Items drop-down list, select the number of search results from
SharePoint Online that you want to show in this result block on the search results page.
For example, select 3 to display three results from SharePoint Online in this result block.
If you want to display a Show More link at the bottom of the result block, expand the Settings
section and select More link goes to the following URL, and type the URL for the link to a page
that displays more results from the SharePoint Online search index.
For example, to specify the main search results page as the page that displays more results, typically
you can type a URL of the following form (followed by "?k={subjectTerms}" to signify the user's
search query): http:// domain_name.com/sites/ Search_Center_name/pages/results.aspx?k=
{subjectTerms}.
When end users click Show More, they will see more results for the result block.
Specify the placement of the block of results from SharePoint Online relative to the results from
SharePoint Server.
Select This block is always shown above core results to display the result block at or near the
top of the first page of search results. In this case, core results are the results from the SharePoint
Server search index. This option is useful for testing, or when most of the relevant content is
located in the remote search index in the hybrid environment. If you select this option for more
than one result block, you can configure the order in which the result blocks are displayed by
ranking the associated query rules.
Select This block is ranked within core results (may not show) to display the result block
such that it is ranked by relevance compared to the core results, in which case the result block
might not appear on the first page of search results.
This is the default setting and is typically the more appropriate choice in a production
environment. As with individual results, the rank of the result block might be different when users
perform the same query later. For example, if users click search results in the result block, the
result block will be ranked higher in the search results over time. Otherwise, the result block will
be ranked lower over time.
(Optional) Specify a different URL for the group display template in the Group Display Template
URL text box.
(Optional) Specify an item display template in the Item Display Template text box,
Skip the Routing section.
Click OK to add the result block.
7. (Optional) Specify when the query rule shall be active. In the Publishing section, use the Start Date, End
Date, Review Date, and Contact fields. The start date and end date specify when the query rule will be
active.
If you specify a start date without an end date, the rule will always be active after the start date.
If you specify an end date without a start date, the rule will always be active until the end date.
If you do not specify a start date or an end date, the rule will always be active.
8. Activate the query rule by selecting Is Active in the Publishing section. When a query rule is active, it fires
whenever the query conditions are met.
9. Click Save.
After a few moments, when federated users submit queries from the SharePoint Server Search Center against a
result source that you specified in step 6c of this procedure, they will see results from both search indexes, as
shown in the following screen shot. In the screen shot, a block of three search results from SharePoint Online
appears above the search results from SharePoint Server.
NOTE
A federated user is a user whose on-premises Active Directory Domain Services (AD DS) domain account is synchronized
between SharePoint Server and SharePoint Online, and who accesses resources in both environments by authenticating with
the federation identity provider, such as Active Directory Federation Services (AD FS) 2.0.
Step 3: Try a search from the SharePoint Server 2013 Search Center
To validate your configuration for displaying search results from both SharePoint Server and SharePoint Online in
the SharePoint Server Search Center, you can log on to SharePoint Server as a federated user and try some
searches from the enterprise Search Center. Use the following procedure to validate your configuration in this
way.
IMPORTANT
If you are using single sign-on (SSO) authentication, it is important to test hybrid Search functionality by using federated
user accounts. Native Office 365 user accounts and Active Directory Domain Services (AD DS) accounts that are not
federated are not recognized by both directory services. Therefore, they cannot authenticate using SSO and cannot be
granted permissions to resources in both deployments. For more information, see Accounts needed for hybrid configuration
and testing.
1. Log on to the SharePoint Server deployment as a federated user who has been activated in SharePoint
Online and who has permissions to view the root site collection in SharePoint Online.
2. Browse to the enterprise Search Center in the SharePoint Server deployment.
3. In the enterprise Search Center, do the following:
Click a search vertical that uses a result source that you specified in step 6c of the second procedure
in this article (Step 2: Create a query rule to turn on hybrid search results in SharePoint Server
2013).
In the search box, type a test query, such as the name of your company.
Make sure that the test query should yield search results from the SharePoint Server search index
and the SharePoint Online search index.
Click the search icon, or press Enter.
4. On the search results page, you should see results from the SharePoint Server search index and a result
block of results from the SharePoint Online search index.
5. If you do not see results from both search indexes, do the following:
Verify that the search system in SharePoint Server has crawled the local content. For information
about how to view the crawl log, see Crawl log in View search diagnostics in SharePoint Server
Verify that you have configured the hybrid SharePoint environment as described in first SharePoint
Server 2016 hybrid configuration roadmaps and then Configure server-to-server authentication
from SharePoint Server to SharePoint Online.
Verify that you have configured Search features and functionality as described in this article.
Correct any errors or omissions, and try a search again.
6. If you still do not see search results from both search indexes, check the SharePoint Unified Logging
Service (ULS ) logs, also called the SharePoint trace logs.
For more information, see Overview of Unified Logging System (ULS ) Logging.
See also
Concepts
Display hybrid federated search results in SharePoint Online
Display hybrid federated search results in SharePoint
Online

This article describes how to configure a hybrid SharePoint environment so that searches from the SharePoint
Online enterprise Search Center display hybrid results—that is, results from both search indexes (SharePoint
Online and SharePoint Server). This configuration is called inbound hybrid search.
The search results from SharePoint Server will appear with the search results from SharePoint Server, but in a
separate group called a result block. You can configure the block of results from SharePoint Server to be shown
above all the results from SharePoint Online, or to be ranked by relevance compared to the SharePoint Online
results.
To display hybrid search results in the SharePoint Online Search Center, in SharePoint Online you perform the
following procedures, which are described in detail in this article:
Step 1: Create a result source that defines how to get search results from the SharePoint Server 2013
deployment
Step 2: Create a query rule to turn on hybrid search results in SharePoint Online
Step 3: Test your configuration for displaying search results from SharePoint Server 2013 in SharePoint
Online
Step 4: Try a search from the SharePoint Online Search Center
Step 1: Create a result source that defines how to get search results
from the SharePoint Server 2013 deployment
In this procedure, you create a result source in SharePoint Online. This result source is a definition that specifies
SharePoint Server as a provider to get search results from. This definition specifies each of the following:
The protocol for getting search results from the SharePoint Server deployment.
The URL of the reverse proxy device. The reverse proxy device forwards search queries from SharePoint
Online to the SharePoint Server deployment.
The ID of the target application that stores the Secure Store SSL certificate.
Result sources can be created at the SharePoint Admin Center level, the site collection level, or the site level. In
this procedure, you create the result source at the SharePoint Admin Center level. This makes the result source
available to any query rule that is created at the same level, and also to any query rule that is created for a site
collection or site.
For more information about result sources, see Understanding result sources and Manage result sources.
1. Verify that the user account that you use to perform this procedure is a global administrator for the Office
365 subscription that you want to configure.
2. In the SharePoint Online Admin Center, in the Quick Launch, click search.
3. On the search administration page, click Manage Result Sources.
4. Click New Result Source.
5. On the page where you can create a new result source, do the following:
In the General Information section, in the Name text box, type a name for the new result source—
for example, Get results from SharePoint Server 2013.
(Optional) In the General Information section, in the Description text box, type a description of the
new result source. This description will appear as a tooltip when the pointer rests on the result
source on certain configuration pages.
In the Protocol section, select Remote SharePoint.
In the Remote Service URL section, type the address of the external endpoint of the reverse proxy
device, such as https://spexternal.adventureworks.com. The reverse proxy device routes queries that
are submitted in SharePoint Online to the SharePoint Server deployment. For more information,
see Configure a reverse proxy device for SharePoint Server hybrid. The external endpoint of the
reverse proxy device is its Internet-facing endpoint. The address of that external endpoint is called
the external URL. Get the value of the external URL from the External URL row in Table 3 of the
SharePoint hybrid worksheet that you have been maintaining, and type it in the Remote Service
URL text box.
In the Type section, select SharePoint Search Results.
In the Query Transform section you can enter a query transform to narrow the search results to a
specified subset—for example, a subset that is from a particular SharePoint site collection or site.
However, if you are not familiar with query transforms in SharePoint Server or SharePoint Online,
we recommend that you keep the default query transform that's in the text box. The default
transform is {searchTerms}, which is a query variable that stands for the query that the user typed,
as it was changed by the most recent query transform. If you are familiar with query transforms you
can change the default query transform by either typing a different query transform in the text box
or launching the Query Builder to help you configure a query transform. For more information, see
Plan to transform queries and order results in SharePoint Server and Query variables in SharePoint
Server.
If you are connecting to your organization's intranet through a reverse proxy, in the Credentials
Information section, select SSO Id and then in the Reverse proxy certificate (Secure Store Id)
text box, type the name of the target application—for example, SecureChannelTargetApp—which
stores the Windows certificate that will be used to authenticate to the reverse proxy device. Get the
name of the target application from the Target Application ID row in Table 6 of the SharePoint
hybrid worksheet that you have been maintaining, and enter it in the Reverse proxy certificate
(Secure Store Id) text box.
Click OK to save the new result source.
Step 2: Create a query rule to turn on hybrid search results in

SharePoint Online
In this procedure, you create a query rule in SharePoint Online that uses the result source that you created in the
previous procedure in this article. When the query rule fires, it causes search results from content in the
SharePoint Server search index to be displayed in a result block on a search results page in SharePoint Online.
Query rules can be created at the SharePoint Admin Center level, the site collection level, or the site level. In this
procedure, you create a query rule at the SharePoint Admin Center level. Because you create the rule at this level,
the rule can apply to any queries that users submit in this instance of SharePoint Online.
For more information about query rules, see Plan to transform queries and order results in SharePoint Server
and Manage query rules in SharePoint Server
1. Verify that the user account that you use to perform this procedure is a global administrator for the Office
365 subscription that you want to configure.
2. In the SharePoint Online Admin Center, in the Quick Launch, click search.
3. On the search administration page, click Manage Query Rules.
4. On the Manage Query Rules page, do the following:
Under the text For what context do you want to configure rules?, in the Select a Result
Source drop-down list, select a result source for which you want this query rule to be applicable.
For testing, we recommend that you select the Local SharePoint Results result source here. If you
do so, then by default the query rule will be applicable when a user performs a query in the
Everything search vertical in the enterprise Search Center, because that vertical uses the Local
SharePoint Results result source by default. After you select a result source from the drop-down
list, all existing query rules that apply to that result source appear on the page. (On the
Search_service_application_name: Add Query Rule page, in the Context section, you will be able to
add or remove result sources for which you want the rule to be applicable.)
(Optional) Under the text For what context do you want to configure rules?, in the User
Segments drop-down list, select a user segment for which you want this query rule to be
applicable. User segments are based on terms that describe users in the term store of a Managed
to add or remove user segments for which you want the rule to be applicable.)
(Optional) Under the text For what context do you want to configure rules?, in the Topic
Categories drop-down list, select a topic category for which you want this query rule to be
applicable. Topic categories are based on terms for categories in the term store of a Managed
to add or remove categories for which you want the rule to be applicable.)
Click New Query Rule.
5. On the Add Query Rule page, do the following:
In the General Information section, in the Rule Name text box, type a name for the new query
rule—for example, Show results from SharePoint Server.
If the Context section is collapsed, click the arrow next to Context to expand it.
In the Context section, under Query is performed on these sources, select All sources if you
want this query rule to be applicable for queries that users submit against any result source, or
select One of these sources, and then optionally click Add Source to add other result sources for
which you want the query rule to be applicable.
NOTE
The result source that you selected on the Search_service_application_name: Add Query Rule page (for
example, Local SharePoint Results—see step 5a of this procedure) will be shown under One of these
sources. > When you select One of these sources, this query rule will be applicable only when a user
submits a query against one of the result sources in this list. Therefore, make sure that the result source
appears for which you want this query rule to be applicable—for example, Local SharePoint Results.
(Optional) Under Query is performed from these categories, specify the topic categories (based
on terms for topic categories in the term store of a Managed Metadata service application) to
perform the query from.
(Optional) Under Query is performed by these user segments, specify user segments (based on
terms that describe users in the term store of a Managed Metadata service application) to which you
want the query rule to apply.
In the Query Conditions section, specify conditions to control when the rule will fire, or click
Remove Condition if you want the rule to fire for any query text. For testing, we recommend that
you click Remove Condition so that the rule will fire for any query text.
In the Actions section, under Result Blocks, click Add Result Block.
(Optional) In the Block Title section, in the Title text box, change the title to the text that you want
to display above the result block on the search results page, such as Results for "{subjectTerms}"
from SharePoint Server.
In the Query section, you can enter the query you want to run. If you are not familiar with query
transforms in SharePoint Server or SharePoint Online, we recommend that you keep the default
query transform that's in the text box. The default transform is {searchTerms}. If you are familiar
with query transforms you can change the default query transform by either typing a different
query transform in the text box or launching the Query Builder to help you configure a query
transform. For more information, see Plan to transform queries and order results in SharePoint
Server and Query variables in SharePoint Server.
In the Query section, in the Search this Source drop-down list, select the name of the result source
that you created in the previous procedure in this article ( Step 1: Create a result source that defines
how to get search results from SharePoint Online)—for example, Get results from SharePoint
Server.
In the Query section, in the Items drop-down list, select the number of search results from
SharePoint Server that you want to show in this result block on the search results page. For
example, select 3 to display three results from SharePoint Server in this result block.
If you want to display a Show More link at the bottom of the result block, expand the Settings
section and select More link goes to the following URL, and type the URL for the link to a page
that displays more results from the SharePoint Server search index. For example, to specify the main
search results page as the page that displays more results, typically you can type a URL of the
following form (followed by "?k={subjectTerms}" to signify the user's search query): http://
Tenant_Name.sharepoint.com/sites/ Search_Center_Name/pages/results.aspx?k={subjectTerms}.
When end users click Show More, they will see more results for the result block.
Specify the placement of the block of results from SharePoint Server relative to the results from
SharePoint Online. Select This block is always shown above core results to display the result
block at or near the top of the first page of search results. In this case, core results are the results
from the SharePoint Online search index. This option is useful for testing, or when most of the
relevant content is located in the remote search index in the hybrid environment. If you select this
option for more than one result block, you can configure the order in which the result blocks are
displayed by ranking the associated query rules. Select This block is ranked within core results
(may not show) to display the result block such that it is ranked by relevance compared to the core
results, in which case the result block might not appear on the first page of search results. This is the
default setting and is typically the more appropriate choice in a production environment. As with
individual results, the rank of the result block might be different when users perform the same
query later. For example, if users click search results in the result block, the result block will be
ranked higher in the search results over time. Otherwise, the result block will be ranked lower over
time.
(Optional) Specify a different URL for the group display template in the Group Display Template
URL text box.
(Optional) Specify an item display template in the Item Display Template text box,
Skip the Routing section.
Click OK to add the result block.
6. (Optional) Specify when the query rule shall be active. In the Publishing section, use the Start Date, End
Date, Review Date, and Contact fields. The start date and end date specify when the query rule will be
active. If you specify a start date without an end date, the rule will always be active after the start date. If
you specify an end date without a start date, the rule will always be active until the end date. If you do not
specify a start date or an end date, the rule will always be active.
7. Activate the query rule by selecting Is Active in the Publishing section. When a query rule is active, it
fires whenever the query conditions are met.
8. Click Save.
After a few moments, when federated users submit queries from the SharePoint Online Search Center against a
result source that you specified in step 5 of this procedure, they will see results from both search indexes, as
shown in the following screen shot. In the screen shot, a block of two search results from SharePoint Server
appears above the search results from SharePoint Online.
NOTE
A federated user is a user whose on-premises Active Directory Domain Services (AD DS) domain account is synchronized
between SharePoint Server and SharePoint Online, and who accesses resources in both environments by authenticating
with the federation identity provider, such as Active Directory Federation Services (AD FS) 2.0.
Step 3: Test your configuration for displaying search results from

SharePoint Server 2013 in SharePoint Online
Use the following procedure to validate your configuration for viewing search results from the SharePoint Server
deployment in SharePoint Online.
IMPORTANT
If you are using single sign-on (SSO) authentication, it is important to test the hybrid Search functionality by using
federated user accounts. Native Office 365 user accounts and AD accounts that are not federated are not recognized by
both directory services. Therefore, they cannot authenticate using SSO and cannot be granted permissions to resources in
both environments. For more information, see Accounts needed for hybrid configuration and testing.
1. Verify that the user account that you use to perform this procedure is a federated user who has been
activated in SharePoint Online, and who has permissions to view the root site collection there.
2. On the SharePoint Admin Center page, click search.
3. On the search administration page, click Manage Query Rules.
4. On the page for managing query rules, do the following:
In the Select a Result Source drop-down list, click the result source that you selected in step 4a of Step
2 in this article ( Step 2: Create a query rule to turn on hybrid search results in SharePoint Online )—for
example, Local SharePoint Results.
A list of query rules that are applicable to that result source appears.
In the list of query rules, click the query rule that you created according to step 2 in this article ( Step 2:
Create a query rule to turn on hybrid search results in SharePoint Online)—for example, Show results
from SharePoint Server 2013.
5. On the page for editing the query rule, in the Actions section, in the Result Blocks subsection, next to the
name of the query rule that will show results from the SharePoint Server search index (for example, Show
results from SharePoint Server 2013), click edit.
6. In the edit result block dialog box, in the Query section, click Launch Query Builder.
7. In the build your query dialog box, on the BASICS tab, do the following:
In the Select a query section, select the result source that you created according to Step 1 in this
article ( Step 1: Create a result source that defines how to get search results from the SharePoint
Server 2013 deployment)—for example, Get results from SharePoint Server.
In the Query text section, delete the default text, which is {subjectTerms}, and then type a test
query (such as the name of your company) that should yield search results from the SharePoint
Server search index.
8. Click Test query.
In the Search Result Preview pane, if your search configuration is valid and there are relevant results in
SharePoint Server, the SharePoint Online search system will display search results from SharePoint
Server. If there are problems with your configuration, the search system can display troubleshooting
information.
9. Click OK.
Step 4: Try a search from the SharePoint Online Search Center

To validate your configuration for displaying search results from both SharePoint Server and SharePoint Online
in the SharePoint Online Search Center, you can log on to SharePoint Online as a federated user and try some
searches from the enterprise Search Center. Use the following procedure to validate your configuration in this
way.
1. Log on to SharePoint Online as a federated user who has been activated in SharePoint Online, and who
has permissions to view the root site collection there.
2. Go to the enterprise Search Center in SharePoint Online.
Typically, the enterprise Search Center in SharePoint Online is at https://<
domain>.sharepoint.com/search—for example, https://adventureworks.sharepoint.com/search.
In the search box, type a test query, such as the name of your company.
Make sure that the test query should yield search results from the SharePoint Server search index and the
SharePoint Online search index.
Click the search icon, or press Enter.
Click a search vertical that uses a result source that you specified in step 5c of the second procedure
in this article (Step 2: Create a query rule to turn on hybrid search results in SharePoint Online ),
such as Local SharePoint Results. That is, click a search vertical that you specified on the Add
Query Rule page, in the Context section, under Query is performed on these sources.
4. On the search results page, you should see results from the SharePoint Online search index and a result
block from the SharePoint Server search index.
NOTE
To view the target of a search result that is from content in the SharePoint Server farm, a user must have at least
Read permission for the root site collection in the primary web application. (In a SharePoint hybrid environment, the
primary web application is in the SharePoint Server farm and is used to receive all connections from Office 365. For
more information about the primary web application, see Plan connectivity from Office 365 to SharePoint Server.)
5. If you do not see results from both search indexes on the search results page, do the following:
Verify that the search system in SharePoint Server has crawled the local content.
Verify that you have configured Search features and functionality as described in this article.
Correct any errors or omissions, and try a search again.
6. If you still do not see search results from both search indexes, check the SharePoint Unified Logging
Service (ULS ) logs, also called the SharePoint trace logs.
See also
Concepts
Configure hybrid SharePoint taxonomy and hybrid
content types

In this article, we look at how to configure hybrid SharePoint taxonomy and hybrid content types.
Hybrid SharePoint taxonomy allows you to have a shared taxonomy between SharePoint Server and SharePoint
Online. Hybrid content types allows you to have a shared set of content types between SharePoint Server and
SharePoint Online.
Be sure to read Plan hybrid SharePoint taxonomy and hybrid content types before you follow the procedures in
this article.
This feature is available in SharePoint Server 2013 and SharePoint Server 2016 with the following SharePoint
updates:
Hybrid taxonomy requires the November 2016 public update or later.
Hybrid content types requires the June 2017 public update or later.
The functionality and configuration procedures are the same for both versions of SharePoint Server.
Video demonstration
This video shows a walkthrough of configuring hybrid taxonomy and hybrid content types.
Video: Configure hybrid taxonomy and content types
Migrate your taxonomy from SharePoint Server

If you have an existing taxonomy in SharePoint Server, the best practice is to copy any term groups you want to be
part of the shared taxonomy to SharePoint Online before you configure hybrid SharePoint taxonomy. You can
migrate additional taxonomy groups from SharePoint Server to SharePoint Online to add to the shared taxonomy
later, but if you do you may need to run the configuration wizard again to include them in the shared taxonomy.
The migration process copies taxonomy groups from SharePoint Server to SharePoint Online. This is done by
using the Copy-SPTaxonomyGroups PowerShell cmdlet.
Active Directory groups
While the copy process preserves most user information associated with term sets - such as owner and
stakeholders - note, that the copy process does not work with Active Directory groups. If you use Active Directory
groups in your term sets, there are two options for copying your taxonomy groups:
You can replace the Active Directory groups with individual users within your taxonomy groups. The
individual users will be copied when you copy your taxonomy groups.
You can copy your taxonomy groups with the Active Directory groups in place. You will see a PowerShell
warning and the Active Directory group assignments will be lost if you proceed. You can then assign an
Office 365 group in place of the Active Directory group after you've copied the taxonomy groups.
Copying taxonomy groups
Copying taxonomy groups is done using the Copy-SPTaxonomyGroups PowerShell cmdlet. You need the
following information to run the cmdlet:
The name of your managed metadata service application in SharePoint Server.
The URL of the SharePoint Server site where your taxonomy store is located.
The URL of the SharePoint Online site where your term store is located
(http://<TenantName>.sharepoint.com).
Taxonomy groups in SharePoint Server to be copied to SharePoint Online.
Your Office 365 global administrator credentials.
NOTE
If you receive an HTTP 400 error when attempting to use the Copy-SPTaxonomyGroups cmdlet with correct credentials,
switch to a cloud-based global administrator instead of an Active Directory synchronized account.
A list of the taxonomy groups that you want to copy.

Run the cmdlet as a farm administrator from one of the servers in your SharePoint farm.
Use the following syntax to copy your taxonomy groups:
$credential = Get-Credential
Copy-SPTaxonomyGroups -LocalTermStoreName "<ManagedMetadataServiceApplication>" -LocalSiteUrl "

<OnPremisesSiteURL>" -RemoteSiteUrl "SharePointOnlineSiteURL" -GroupNames "Group1","Group2" -Credential
$credential
For example:
Copy-SPTaxonomyGroups -LocalTermStoreName "Managed Metadata Service" -LocalSiteUrl "https://sharepoint" -

RemoteSiteUrl "https://contoso.sharepoint.com" -GroupNames "Engineering","Marketing" -Credential $credential
Note that you can also simply run Copy-SPTaxonomyGroups and you will be prompted for the needed
parameters.
Copying content types
If you're planning to use hybrid content types, you can copy your SharePoint Server content types to SharePoint
Online by using the Copy-SPContentTypes cmdlet. For example:
Copy-SPContentTypes -LocalSiteUrl http://localsite/ -LocalTermStoreName "managed metadata service application

proxy" -RemoteSiteUrl https://contoso.sharepoint.com/ -ContentTypeNames @("ContentTypeA", "ContentTypeB") -
Credential $credential
The content types will be copied into https://contoso.sharepoint.com/sites/contentTypeHub. If this site does not
exist, it will be created for you and the Site Collection Feature Content Type Syndication Hub will be enabled. The
site URL is hard coded and cannot be changed.
Configure hybrid SharePoint taxonomy

Configuration of hybrid SharePoint taxonomy is done using the Hybrid Picker in the SharePoint Online admin
center. The Hybrid Picker has a number of prerequisites. Be sure to read Hybrid picker in the SharePoint Online
admin center before you follow the procedures in this section.
We also recommend that you back up your term store before you proceed.
Make the timer service account a term store admin
For taxonomy replication to work properly, the account that runs the SharePoint Timer Service must be a term
store administrator in SharePoint Server. (To find this account, check the Log On As account for the SharePoint
Timer Service on your server.) Use the following procedure to add this account as a term store administrator.
To add a term store admin
2. Click the link for the Managed Metadata service application.
3. Add the timer service account to the Term Store Administrators box, and then click Save.
Configure hybrid SharePoint taxonomy using the Hybrid Picker
The next step is to configure hybrid SharePoint taxonomy by running the Hybrid Picker in the SharePoint Online
admin center.
To configure hybrid SharePoint taxonomy
1. Log on to a server in your SharePoint Server farm as the farm administrator.
2. From your SharePoint Server computer, open a web browser and log on to Office 365 as a global
administrator.
3. In the SharePoint Online Admin Center, click configure hybrid.
4. On the hybrid picker page, click Hybrid Picker.
5. Follow the wizard and choose Hybrid Taxonomy when prompted.
6. Provide the following information when prompted:
The URL of your SharePoint Server root site. (For example, https://sharepoint.)
The name of your SharePoint Server managed metadata service application. (For example, Managed
Metadata Service.)
The names of the taxonomy groups that you want to replicate. (For example, Engineering;Marketing.)
Note, if you don't specify groups, then all groups except system and special groups are configured for
replication.
Once you've configured hybrid SharePoint taxonomy, the taxonomy replication timer job will poll SharePoint
Online on a daily basis for changes to the taxonomy.
Running the taxonomy replication timer job

Hybrid SharePoint taxonomy uses a timer job called Taxonomy Groups Replication to copy taxonomy information
from SharePoint Online to SharePoint Server. The SharePoint Online APP Identity is used to authenticate to
Office 365. By default, this timer job replicates taxonomy on a daily basis.
Like other timer jobs in SharePoint, you can configure the Taxonomy Groups Replication job to run on a different
schedule, or you can run it manually, by searcing for it in the timer job list in Central Administration.
Stopping replication of taxonomy groups

If at any time you want to stop taxonomy replication between SharePoint Online and SharePoint Server, you can
do so by using PowerShell.
The Stop-SPTaxonomyReplication cmdlet will stop taxonomy replication. For example:
Stop-SPTaxonomyReplication -Credential $credential
The Stop-SPContentTypeReplication cmdlet will stop content type replication:
Stop-SPContentTypeReplication
If you wish to reenable taxonomy replication again, you must run the Hybrid Picker again.
If you simply want to reconfigure which taxonomy groups you are replicating, there's no need to stop replication.
You can just run the hybrid picker again and specify the new taxonomy groups that you want to replicate.
See also
Other Resources
TechNet Forums - Hybrid Taxonomy

Hybrid self-service site creation redirects the default self-service site creation page in SharePoint Server
(/_layouts/15/scsignup.aspx) or (/_layouts/16/scsignup.aspx) to the SharePoint Online Group Creation page. By
configuring this feature, you can help your users to create their sites in SharePoint Online instead of SharePoint
Server.
Hybrid self-service site creation respects your hybrid audience settings. If you use a hybrid audience, members of
the hybrid audience will be redirected to SharePoint Online for self-service site creation, while on-premises only
users will continue to be directed to self-service site creation in SharePoint Server.
This setting can be configured independently for each web application in your farm.
Hybrid self-service site creation is available in SharePoint Server 2013 with the March 2017 PU.
Hybrid self-service site creation is available in SharePoint 2016 with November 2017 PU.
Configure hybrid self-service site creation using the Hybrid Picker

Configuring hybrid self-service site creation is done by using the hybrid picker in the SharePoint Online admin
center.
NOTE
If you've previously configured other hybrid features with the hybrid picker, you can go directly to the SharePoint Central
Administration website to manage hybrid self-service site creation. In this case, the hybrid connection has been made and
there's no need to run the hybrid picker again.
To configure hybrid self-service site creation

1. Log on to a server in your SharePoint Server farm as the farm administrator.
2. From your SharePoint Server computer, open a web browser and log on to Office 365 as a global
administrator.
3. In the SharePoint Online Admin Center, click configure hybrid.
4. On the hybrid picker page, click Hybrid Picker.
5. Follow the wizard and choose Hybrid self-service site creation when prompted.
6. When prompted, choose the web application with which you want to use hybrid self-service site creation.
When the hybrid picker wizard completes, hybrid self-service site creation will be enabled for the web application
that you selected.
Manage hybrid self-service site creation

Once you have configured hybrid self-service site creation, you can manage it in the SharePoint Central
To manage hybrid self-service site creation
1. In Central Administration, click Application Management.
2. On the Application Management page, under Site Collections, click Configure self-service site
creation.
3. In the Web Application section, select the web application where you want to manage hybrid self-service
site creation, and then select or clear the Create Site Collections in SharePoint Online check box.
NOTE
While hybrid users of this web application will be redirected to SharePoint Online for self-service site creation, the
other settings on this page continue to apply to any on-premises only users.
4. Click OK.
Set up Search of OneDrive for Business in Office 365
from SharePoint Server

After you install Service Pack 1 for SharePoint Server, when your users click OneDrive or Sites on the navigation
bar, you can redirect them to OneDrive for Business in Office 365 for professionals and small businesses. To learn
how to do this, see Plan hybrid OneDrive for Business.
This article describes how you can then set up an option in the SharePoint Server enterprise Search Center to
return only search results from OneDrive for Business that is in Office 365. This option, called a search vertical, will
provide an easy way for a user of on-premises SharePoint Server to search only the following items in OneDrive
for Business in Office 365 for a match to the user's search query:
Items that the user has stored in OneDrive for Business in Office 365
Items in OneDrive for Business in Office 365 that are shared with the user
Items in OneDrive for Business in Office 365 that are shared with everyone
How users will access the OneDrive for Business search vertical
A search vertical filters search results so that only a certain subset of all relevant results is displayed. SharePoint
Server provides four preconfigured search verticals: Everything, People, Conversations, and Videos. You can
see the links for these search verticals in the Search Navigation Web Part, which is below the search box on a
search-results page, as shown in the following screen capture.
When a user enters a search query in the search box and then clicks one of the search-vertical links, the Search
system returns search results that correspond to that search vertical only. For example, if the user enters Azure in
the search box and then selects the Videos search-vertical link, the Search system will return only search results
that are videos related to Azure.
In this article, in the SharePoint Server deployment, you will create a search vertical for OneDrive for Business in
Office 365. You will then add a link in the enterprise Search Center for the new search vertical. The link in the
enterprise Search Center will look something like this, depending on what you name it.
After that, when users of on-premises SharePoint Server type queries in the search box in the enterprise Search
Center and they click the OneDrive for Business search-vertical link that you created, they will get search results
only from OneDrive for Business that is in Office 365.
Setting up Search of OneDrive for Business by creating a OneDrive

search vertical
To create a search vertical in your SharePoint Server deployment that will enable users to search only for items
that are in OneDrive for Business in Office 365, you perform the following procedures, which are described in
detail in this article:.
That is, in your SharePoint Server deployment, you do the following:

Step 1: Create a result source that specifies OneDrive for Business in Office 365 as the content repository to
get search results from
Step 2: Create a search-results page for the OneDrive for Business search vertical
Step 3: Configure the Search Results Web Part to display results from OneDrive for Business that is in
Office 365
Step 4: Create a link in the Search Center for the OneDrive for Business search vertical
Step 5: Test your configuration for using the OneDrive search vertical to display search results from
OneDrive for Business that is in Office 365
Before you begin

Before you perform the procedures in this article, make sure that you do each of the following:
Complete the procedures in Configure hybrid OneDrive for Business.
Configure a hybrid SharePoint environment according to the instructions in the following two articles, and
in the following order:
1. Configure hybrid federated search from SharePoint Server to SharePoint Online - roadmap
2. Configure server-to-server authentication from SharePoint Server to SharePoint Online
For additional information about synchronizing users and passwords, see Ways to synchronize users and
passwords in Configure hybrid OneDrive for Business.
Create an enterprise Search Center in your SharePoint Server deployment if one does not already exist. For
more information, see Create a Search Center site in SharePoint Server.
Step 1: Create a result source that specifies OneDrive for Business in

Office 365 as the content repository to get search results from
In this procedure, you create a result source in the SharePoint Server deployment. This result source is a definition
that specifies the URL and path in Office 365 to get search results from, the protocol for getting those results, and
several other related settings.
A result source can be created at the Search service application level, the site collection level, or the site level. In
this procedure, you create the result source at the Search service application level. This makes the result source
available to any query rule that is created at the Search service application level in that Search service application
and to any query rule that is created for a site collection or site that is in a web application that consumes the
To create the result source
2. In the SharePoint Server deployment, in Central Administration, in the Application Management section,
3. Click the Search service application to which you want to add a result source.
4. On the Search_service_application_name:Search Administration page for the Search service application, in
the Quick Launch, click Result Sources.
5. On the Search_service_application_name:Manage Result Sources page, click New Result Source.
6. On the Search_service_application_name:Add Result Source page, do the following:
7. In the Name box, type a name for the new result source—for example, Results from OneDrive in Office
365.
8. (Optional) In the Description box, type a description of the new result source.
pages.
9. In the Protocol section, select Remote SharePoint.
10. In the Remote Service URL section, type the address of the root site collection in SharePoint Online that
you want to get search results from.
The address of the root site collection in SharePoint Online is typically of the form https://
tenant_name.sharepoint.com, where tenant_name is the name of the Office 365 tenant.
11. In the Type section, select SharePoint Search Results.
12. In the Query Transform section, after {searchTerms}, type a space and then type the following:
path:https:// tenant_name-my.sharepoint.com/personal
In general, you can use a query transform to narrow search results to a specified subset. In this case, you
use a query transform to specify the Path property, which narrows search results to documents that are in
OneDrive for Business in Office 365. For more information about query transforms, see the following
resources:
Transforming queries in result sources in Plan to transform queries and order results in SharePoint Server
7. In the Credentials Information section, select Default Authentication.
Your settings on the Search_service_application_name:Add Result Source page then look something like
this:
8. Click OK to save the new result source.
Step 2: Create a search-results page for the OneDrive for Business

search vertical
Each search vertical can have its own search-results page on which results for that vertical are displayed. In the
following procedure, you create the search-results page that will display results for the OneDrive for Business
search vertical.
To create the search-results page for the OneDrive for Business search vertical
1. Verify that the user account that you use to perform this procedure is a site collection administrator or site
owner for the enterprise Search Center.
2. In the SharePoint Server deployment, browse to the enterprise Search Center.
The URL of the enterprise Search Center is typically of the form http:// host_name/sites/
Search_Center_name.
3. Go to Settings > Site Contents > Pages.
This Pages page contains a list of all of the search-results pages for the enterprise Search Center.
4. From the Pages page, add a new search-results page by doing the following:
5. On the ribbon, click the Files tab.
6. Click New Document, and then click Page.
7. On the Create Page page, do the following:

8. In the Title box, enter a title for the new search-results page, such as OneDriveResults.
9. (Optional) In the Description box, enter a description for the new page.
10. In the URL box, enter the portion of the URL that you want to use to identify the page, such as
OneDriveResults.
11. In the Page Layout section, ensure that (Welcome Page) Search Results is selected.
This specifies how the new search-results page will be displayed.
Your settings on the Create Page page then look something like this:
12. Click Create.

13. On the page that contains a list of all of the search-results pages for the enterprise Search Center, do the
following:
14. Select the icon next to the name of the search-results page (such as OneDriveResults) that you just
created.
This selects that row in the list of search-results pages.
15. On the Files tab, in the Open & Check Out section, select Check In.
16. In the Check in dialog box, do the following:
17. In the Version field, select 1.0 Major Version (publish).
18. In the Retain Check Out field, select No.
19. (Optional) In the Comments field, enter comments as appropriate for your configuration.
20. Click OK.
This checks in and publishes the page.
Step 3: Configure the Search Results Web Part to display results from
OneDrive for Business that is in Office 365
In this procedure, you configure the Search Results Web Part on the search-results page that you created in the
previous procedure in this article (Step 2). You configure the Search Results Web Part to display search results
from OneDrive for Business that is in Office 365.
To configure the Search Results Web Part to display search results from OneDrive for Business that is in
Office 365
owner for the enterprise Search Center.
2. Go to the page that has a list of all of the search-results pages for the enterprise Search Center.
You accessed this page in the previous procedure in this article (Step 2). To reach it again, browse to the
enterprise Search Center, and then go to Settings > Site Contents > Pages. The URL of the page might
resemble http:// host_name/sites/ Search_Center_name/Pages/Forms/AllItems.aspx.
3. Click the name of the search-results page (such as OneDriveResults) that you created, checked in, and
published in the previous procedure in this article (Step 2).
Clicking the name of the search-results page will take you to that page.
NOTE
On the search-results page, you might see the message Sorry, something went wrong, or the message Nothing
here matches your search. These are default messages that can be displayed on the search-results page when a
user search fails. These messages do not apply to the configuration that you are currently doing.
4. Go to Settings > Edit page.

5. On the ribbon, click the PAGE tab.
6. On the PAGE tab, in the Search Results Web Part, move the pointer to the right until you see the down
arrow, and then click the arrow.
The Search Results Web Part menu appears.
7. On the Search Results Web Part menu, choose Edit Web Part.
The Search Results Web Part tool pane then appears at the top right of the page that you are editing.
8. In the Search Results Web Part tool pane, click Change query.
9. In the Build Your Query dialog box, do the following:

10. In the Select a query section, on the drop-down menu, select the result source that you created in the first
procedure of this article, such as Results from OneDrive in Office 365.
This causes search results from OneDrive for Business in Office 365 to appear in the Search Results Web
Part on the OneDriveResults search-results page.
11. Skip the other sections in the dialog box, and then click OK.
12. On the PAGE tab, in the Edit group, click Check In.
13. In the Check In dialog box, do the following:
14. (Optional) Type comments as appropriate for your configuration.
15. Click Continue.
16. Do either of the following to publish the page:
Click Publish this draft.
Do the following:
1. On the Publish tab, click Publish.
2. In the Publish dialog box, optionally type comments as appropriate for your configuration, and then click
Continue.
Step 4: Create a link in the Search Center for the OneDrive for Business
search vertical
In this procedure, you create the link in the SharePoint Server enterprise Search Center that users will click to get
results from OneDrive for Business that is in Office 365. After you create the link, it appears in the Search
Navigation Web Part, under the search box next to the links for the other search verticals, such as Everything and
People. The links in the Search Navigation Web Part then look something like this, depending on your particular
configuration:
To create the link for the OneDrive for Business search vertical
owner for the enterprise Search Center in the SharePoint Server deployment.
The URL of the enterprise Search Center is typically of the form http:// host_name/sites/
Search_Center_name.
3. Go to Settings > Site Settings.
5. On the Search Settings page, do the following:

6. (Optional) In the Enter a Search Center URL section, in the Search Center URL box, type the URL of the
enterprise Search Center.
If you type a URL in this box, after a user performs a search from a search box on another site, the Search
system displays a link that the user can click to try the search again from the enterprise Search Center.
7. In the Which search results page should queries be sent to? section, select Use the same results page
as my parent.
8. In the Configure Search Navigation section, select Add Link.
10. In the Title box, type the text (such as MyOneDrive) that you want to use for the search-vertical link in the
enterprise Search Center that will take users to the search-results page that you created in the second
procedure (Step 2) in this article.
11. In the URL box, do one of the following:
Type the relative path to the search-results page that you created in the previous procedure, such as /sites/
Search_Center_name/Pages/onedriveresults.aspx.
Click Browse.
In the list of search-results pages, click the name of the search-results page for the new search vertical, and
then click Insert.
3. Select the Open link in new window check box if you want the search-results page for OneDrive for
Business to open in a new window when users click the link for that search vertical.
4. (Optional) In the Description box, type a description for the new link.
5. (Optional) In the Audience box, type the name of a global audience, a SharePoint group, a distribution
group, or a security group to which access to the new search-results page will be limited.
All Site users is the default value if you do not type anything in the Audience box. The value All site users
allows access to all users who can access the Search Center site. For more information, see "To grant access
to the SharePoint Search Center" in Create a Search Center site in SharePoint Server.
6. If you typed a value in the Audience box, then next to that box, click the Check Names icon to make sure
that SharePoint Server recognizes the audience that you typed.
7. Click OK.
8. In the Configure Search Navigation section, click the name of the new link, such as MyOneDrive, and
then click Move Up or Move Down as appropriate to position the new link where you want it to appear in
the group of search-vertical links.
9. Click OK.
Step 5: Test your configuration for using the OneDrive search vertical
to display search results from OneDrive for Business that is in Office
365
Federated users should now be able to use the new MyOneDrive search vertical to get results from OneDrive for
Business that is in Office 365. Searches that federated users perform in the new search vertical should return the
following items from OneDrive for Business that is in Office 365 that match the search query:
Items that the user has stored in OneDrive for Business in Office 365
Items in OneDrive for Business in Office 365 that are shared with the user
Items in OneDrive for Business in Office 365 that are shared with everyone
A federated user is one who has an account in the on-premises Active Directory Domain Services (AD DS )
Domain Users group that has been synchronized with Azure Active Directory by using the Azure Active Directory
Sync tool (DirSync). The account has group memberships and permissions for resources in the SharePoint Server
deployment and in Office 365, and can access resources in both environments by authenticating with the
federation identity provider, such as Active Directory Federation Services (AD FS ) 2.0.
To validate your configuration for displaying search results from OneDrive for Business that is in Office 365, you
can log on to SharePoint Server as a federated user and try some searches from the OneDrive for Business search
vertical in the enterprise Search Center. Use the following procedure to validate your configuration in this way.
To test your configuration for displaying search results from OneDrive for Business that is in Office 365
1. Log on to the SharePoint Server deployment as a federated user who has been activated in Office 365, and
who has permission to view the root site collection in SharePoint Online in Office 365.
The URL of the enterprise Search Center might resemble http:// host_name/sites/ Search_Center_name.
4. In the search box, type a test search query, such as the name of your company.
Make sure that it's a query that should yield some search results from OneDrive for Business that is in
Office 365.
5. Press Enter or click the search icon, and then wait for initial search results to be displayed.
6. After the initial search results are displayed, click the link for the search vertical for OneDrive for Business
that you created earlier in this article.
7. On the search-results page, confirm that you see results from OneDrive for Business that is in Office 365.
8. If you do not see results from OneDrive for Business in Office 365 on the search-results page, do the
following:
9. Verify each of the following:
10. You configured the hybrid SharePoint environment as described in the following articles, and in the
following order:
11. Configure hybrid federated search from SharePoint Server to SharePoint Online - roadmap
12. Configure server-to-server authentication from SharePoint Server to SharePoint Online
13. You completed the procedures described in Configure hybrid OneDrive for Business.
14. You completed the previous procedures described in this article.
15. Correct any errors or omissions, and try a search again.
16. If you still do not see search results from OneDrive for Business that is in Office 365, check the SharePoint
Unified Logging Service (ULS ) logs, also called SharePoint trace logs.
Deploy a Business Connectivity Services hybrid
solution in SharePoint

The Microsoft Business Connectivity Services (BCS ) hybrid deployment scenario allows you to securely publish
on-premises data to an external list or app for SharePoint in SharePoint Online. From there, users can view and
edit the data, depending on the permissions that they have.
In this scenario, you will learn how to:
Configure your on-premises environment so that you can securely publish confidential business data to
your SharePoint Online tenancy.
Create and configure an OData service endpoint and an external content type with Visual Studio 2012.
Prepare your SharePoint Online tenancy to host an app for SharePoint or an external list, which makes the
external data available to your extranet users.
Create a connection settings object that tells Business Connectivity Services in SharePoint Online how to
connect to the on-premises OData service endpoint.
Deploy an app for SharePoint or external list to SharePoint Online.
Validate and troubleshoot the BCS hybrid scenario.
What these procedures help you deploy

BCS is a centralized infrastructure in SharePoint Server, Office 2016, and SharePoint Online that enables you to
integrate data that is not in SharePoint products or Office 2016 into SharePoint Server. BCS implementations take
many forms. This includes this hybrid form that uses SharePoint Online and SharePoint Server on-premises.
These procedures show how to install and configure BCS to integrate data from an on-premises OData service
endpoint into SharePoint Online. For this scenario, we use the AdventureWorks sample SQL database and create
an OData service head for the database. The solution looks as shown in the following diagram.
Figure: Hybrid BCS solution
1. An information worker logs on to SharePoint Online by using their federated account and opens an app for
SharePoint or external list that needs data from an on-premises OData data source.
2. The external list creates a request for the data and sends it to Business Connectivity Services. Business
Connectivity Services looks at the connection settings object to see how to connect to the data source and
which credentials to use.
3. Business Connectivity Services retrieves two sets of credentials:
4. The Secure Channel certificate from Secure Store in SharePoint Online. This is used for SharePoint Online
authentication to the reverse proxy.
5. An OAuth token from the Azure AD Service. This is used for user authentication to the SharePoint Server
farm. You gain access to the Azure AD service with your SharePoint Online subscription. It is a security
token service that manages security tokens for users of SharePoint Online.
6. Business Connectivity Services sends an HTTPS request to the published endpoint for the data source. The
request includes the client certificate from Secure Store, the OAuth token, and a request for the data. The
reverse proxy authenticates the request by using the client certificate and forwards it to the on-premises
SharePoint Server farm. For more information about publishing SharePoint to the Internet, see SharePoint
publishing solution guide in the Forefront Technical Library.
7. The on-premises farm retrieves the user's cloud identity from the OAuth token (for example,
user123@contoso.com), and through the Client Side Object Model (CSOM ) code, maps it to the on-
premises identity (for example, contoso\user123). The on-premises credentials are mapped to credentials
that have access to the external data via a Secure Store target application.
8. The on-premises Business Connectivity Services forwards the request to the OData Service endpoint. The
OData Service authenticates the request (via IIS ) and returns the data, which is passed back through the
chain to the external list for the user to work with.
Video: Watch a demonstration of the BCS hybrid scenario
How to use these procedures

The steps to completely deploy this scenario are presented in smaller procedures. Each procedure is numbered
indicating its position in the overall sequence. At the beginning and end of each procedure, links direct you to the
previous and following steps. The following list contains links to all of the procedures, in the required order, for
your reference. Be aware that this list includes the steps to deploy an external list and an app for SharePoint. You
can deploy one or the other or both, depending on your needs. You should skip the steps for whichever
configuration you don't want to deploy. You must follow them in sequence to build out the scenario. You can also
use these procedures individually for your own unique scenarios. When you assemble individual procedures to
build out your own scenarios, it is important that you test the complete set of procedures, in order, in a lab setting
before you try them in production.
Roadmap of the procedures

To configure the BCS hybrid solution:
1. Follow the procedures in Prepare your environment for the Business Connectivity Services hybrid scenario
to configure the underlying settings and services needed.
2. If you want to use an external list, follow the procedures in Deploy the Business Connectivity Services
hybrid scenario as an external list.
3. Follow the procedures in Validate the Business Connectivity Services hybrid scenario to validate your setup.
See also
Concepts
Other Resources
Introducing OData: Data Access for the Web, the cloud, mobile devices, and more
Prepare your environment for the Business
Connectivity Services hybrid scenario

This example of the Microsoft Business Connectivity Services (BCS ) hybrid scenario shows you how to use
standard Windows domain security to control access to the on-premises OData service endpoint. You configure
one domain account with which to access the OData service endpoint, and one global security group for your
federated user accounts. Then, you map the group to the account by using a Secure Store Service target
application.
To prepare on-premises security for the BCS hybrid scenario

1. Identify all the user accounts in your on-premises domain that need to use the BCS hybrid solution and
make sure that they are federated accounts. You will add these accounts to a domain global security group
later in this procedure.
2. In your on-premises domain, create a service account that will access the OData service endpoint. These
procedures use an account named ODataAccount.
3. In your on-premises domain, create a global security group. These procedures use a group named
ODataGroup.
4. Add the accounts that you identified in step 1 to the ODataGroup group.
Create and configure a Secure Store target application

In this procedure, you link the ODataGroup to the ODataAccount by using a Secure Store target application.
This way, users in the ODataGroup access the OData service endpoint through only one account, the
ODataAccount.
In this procedure, you create and configure the on-premises Secure Store target application named ODataApp for
the BCS hybrid scenario. (You can choose a different name if you want.)
To create a target application
2. Click the Secure Store service application.
3. In the Manage Target Applications group, click New.
4. In the Target Application ID box, type a text string. For example, ODataApp.
5. In the Display Name box, type a name for the target application. For example, ODataApp.
6. In the Contact Email box, type a contact e-mail.
7. In the Target Application Type drop-down list, select Group. This indicates the mapping of many user
credentials or a security group to one credential. In this case, the Target Application Page URL is not
needed and automatically selects None. Click Next.
8. On the Create New Secure Store Target Application page, for both Field Name and Field Type, accept
the default values of Windows User Name and Windows Password. Click Next.
9. In the Target Application Administrators field, add the Farm Administrators account and an account that
has farm administrator rights. In the Members field, add the domain security group you are using to
control access to the BCS hybrid scenario solution; for example, ODataGroup.
10. Click OK.
Next, we need to add the credentials that we'll be using.
To set credentials for a target application
1. In the target application list, point at the target application that you just created, click the arrow that appears,
and then, in the menu, click Set credentials.
If the target application is of type Group, type the credentials for the external data source. Depending on the
information that is required by the external data source, the fields for setting credentials will vary.
If the target application is of type Individual, type the user name of the individual who will be mapped to
this set of credentials on the external data source, and type the credentials for the external data source.
Depending on the information that is required by the external data source, the fields for setting credentials
will vary.
2. In the Windows User Name box, type the account name for the account that will have access to the OData
service endpoint in domain\username format; for example, Adventureworks\ODataAccount.
3. Type and confirm the password for that account, and then click OK.
Create and configure the OData service endpoint

The BCS hybrid scenario supports connecting only to an OData source. If your external data already has an OData
service endpoint, then you can skip the creating an OData service endpoint portions of this procedure. You will still
need to configure permissions on the service endpoint for the ODataAccount. For the purposes of these
procedures, we use the SQL ServerAdventureworks sample database and the AdventureWorks 2012 LT sample
data as the data source and create an OData service endpoint to make the data available to the BCS hybrid
solution. You use Visual Studio 2012 to create and configure the OData service.
To create and configure the OData service endpoint, perform the procedures in How to: Create an OData data
service that sends notifications to BCS in SharePoint 2013 in the MSDN Library. You will need the
ODataAccount account to secure the service endpoint in Internet Information Services (IIS ) 7.0.
Prepare the SharePoint Online site and App Catalog

The BCS hybrid scenario publishes on-premises data to select users of SharePoint Online. You can present the
data either through a SharePoint Online external list or through an app for SharePoint. In either case, you must
identify or create a site in SharePoint Online through which the data will be offered. If you choose to use an app
for SharePoint, you must also have a SharePoint OnlineApp Catalog configured.
To prepare the SharePoint Online site and App Catalog
1. Identify or create a site in SharePoint Online for your external list or app for SharePoint. Ensure that all the
federated users who will be using the BCS hybrid solution are added to the Members group for access to
the site. (The easiest way to do this is to add your ODataGroup as a Member.)
2. If you're going to be using a app for SharePoint, you must enable the App Catalog.
NOTE
This scenario shows you how to directly deploy your app for SharePoint into the site you have prepared. It is also
possible to deploy your app for SharePoint into the App Catalog.
Set permissions on the BDC Metadata Store in SharePoint Online

The Business Data Connectivity service (BDC ) Metadata Store holds external content types, external systems, and
BDC model definitions for the BDC Service Application. In this procedure, you configure administrative
permissions on the Metadata Store and everything that it will contain. Later in this scenario, if you are using the
manual import of the external content type method, you will be using the BDC Metadata Store. This external
content type will be available across SharePoint Online. If you will only be using the automated deployment of an
app for SharePoint, then you will not use the BDC Metadata Store, and the external content type is scoped to the
app only.
To set permissions on the BDC Metadata Store in SharePoint Online
1. Open the SharePoint Online Administration Center by using an administrative account.
2. On the Quick Launch, click BCS, then click Manage BDC Models and External Content Types.
3. Click Set Metadata Store Permissions, and add All Authenticated Users with at least Execute
permissions. This will allow all users who authenticate to your SharePoint Online tenancy to use the
external content types stored in the Metadata Store.
4. Select the Propagate permissions to all BCS Models, External Systems and External Content Types
in the BDC Metadata Store. Doing so will overwrite existing permissions check box.
5. Click OK.
Validate external access to reverse proxy published URL

At this point in deploying the BCS hybrid scenario, you should confirm that you can access your on-premises
SharePoint Server farm that has been configured to receive hybrid calls from SharePoint Online. This site was
already configured in the SharePoint Server 2016 hybrid configuration roadmaps procedures. Its URL is the one
you published through your reverse proxy.
Before you begin this procedure, make sure you have the following:
The external URL, for example, if your on-premises farm web application was configured with an alternate
access mapping of "hybridexternal.sharepoint.com" and you published out
"https://hybridexternal.sharepoint.com" through the reverse proxy, you will use
"https://hybridexternal.sharepoint.com" for this procedure.
A computer to browse from that is in the extranet. For example, use a computer that is not on your
corporate network and is not a member of your corporate domain.
The Secure Channel certificate that is stored in the SharePoint OnlineSecure Store Service target
application. This target application was configured in the SharePoint Server 2016 hybrid configuration
roadmaps procedures. In the example it was named SecureChannelTargetApp. You will need the
password for the certificate as well.
The credentials of a federated account.
To confirm access to external URL
1. Copy the certificate to your extranet computer, and then click the certificate. You will be prompted for the
certificate password. This adds the certificate to your personal certificate store.
2. Open a web browser and browse to the externally published URL of your on-premises farm. You should be
prompted for credentials. If not, check your browser settings and make sure that your logged on credentials
are not being automatically passed.
3. Provide the credentials of the federated user. This log on must succeed and you should see the published
site. If this does not work, contact the administrators who set up your hybrid infrastructure. Do not proceed
any further with the BCS hybrid scenario until this issue is resolved.
Create and configure the connection settings object

Unlike BCS in SharePoint Server, BCS in SharePoint Online requires that you configure a connection settings
object, which contains additional information to establish the connection to the external system and the OData
source.
Before you begin this procedure, make sure you have the following:
The URL or published service endpoint of the on-premises OData service that you configured.
The ID of the Secure Store target application that you configured.
The Internet-facing URL that Office 365 uses to connect to the service address and that was published by
the reverse proxy. This is the address that you used to browse to the external service in the last procedure,
with the addition of /_vti_bin/client.svc.
The ID of the Secure Store target application for the Secure Channel certificate in Office 365.
To configure the connection settings object for the BCS hybrid scenario
1. Open the SharePoint Online Administration Center by using an administrator account, and on the Quick
Launch, click bcs.
2. Click Manage connections to on-premises services.
3. Click Add.
4. Give the connection settings object a name.
IMPORTANT
Keep track of this name; you will use it when you create the external content type in the next procedure.
5. In the Service Address box, type the URL of the OData service endpoint that you created.
6. For this scenario, select the Use credentials stored in Sharepoint on-premises as the authentication
option, and then type the name of target application ID that holds the group to account mapping. In this
scenario, it is ODataApp that you created.
7. In the Authentication Mode drop-down list, select Impersonate Window's Identity.
8. In the Internet-facing URL box, type the external URL with the /_vti_bin/client.svc extension. For example
https://hybridexternal.sharepoint.com/_vti_bin/client.svc.
9. In the Secure Store Target Application ID box, type the ID of the target application that holds the Secure
Channel certificate. For example SecureChannelTargetApp.
10. Click Create.
Create and configure the external content type
In every BCS solution, the external content type defines the external data to SharePoint Server. It includes
descriptions of how the data is structured, how it is secured, the specific portions of the external data that you want
to interact with, and the permitted operations. When an external list or app for SharePoint or business data Web
Part makes a request for external data, the Business Data Connectivity service refers to the external content type
for the list or app or Web Part to understand how to communicate with the external data source.
In the BCS hybrid scenario, only OData sources are supported and the preferred way to make an external content
type for an OData source is to use Visual Studio 2012. Visual Studio 2012 simplifies the external content type
creation process by directly connecting to the OData source, reading it, and building the external content type XML
for you. Once created, you have to make some minor changes to the XML, such as inserting which connection
settings object to use and removing some of the boilerplate code, before you can deploy it to SharePoint Online
for use in the BCS hybrid scenario.
Before you begin, make sure you have the following:
Visual Studio 2012 installed on a computer that on your corporate network.
The OData service endpoint URL
Microsoft Office Tools for Visual Studio 2012
Once you have all of that, complete the steps in How to: Create an external content type from an OData source in
SharePoint 2013 in the MSDN Library.
When you are done creating the external content type, deploy the hybrid scenario to an external list.
See also
Concepts
Deploy a Business Connectivity Services hybrid solution in SharePoint
Overview of Business Connectivity Services security tasks in SharePoint Server
Deploy the Business Connectivity Services hybrid
scenario as an external list

The procedures in this article show you how to integrate external data by using an external list. Make sure you've
already prepared your environment for the Business Connectivity Services hybrid scenario before you follow the
procedures in this article.
Manually extract an external content type to a BDCM file

The external content type that you configured must be manually extracted and saved as a file with a .bcdm
extension. This is done by using Visual Studio 2012. Follow the procedure in How to: Convert an App-Scoped
External Content Type to Tenant-Scoped in the MSDN Library.
You'll need the .bcdm file for the next procedure.
Import the BDCM file into the SharePoint Online BDC Metadata Store
When you import the BDC Model file into SharePoint Online, you must be logged in to the SharePoint Online
administrator site as a federated account (an account imported to Office 365 from On-Premise using Directory
Sync). This federated account should also be given Global Administrator rights in Office 365. When importing the
BDC Model to configure Hybrid BCS, certain calls are made to SharePoint Server that will require you use a
federated user account. Be aware the account must also have a populated user profile in SharePoint Server.
To import a BDCM file into the SharePoint Online BDC Metadata Store
1. Log on to your SharePoint Online tenancy by using an administrative account, and then open the
SharePoint Online Administration Center.
2. In the Quick Launch, click bcs.
3. Under business connectivity services, click Manage BDC Models and External Content Types.
4. On the Edit tab, click Import.
5. Click Browse, and then browse to the .bdcm file that you exported.
6. Leave the default selections for File Type and Advanced Settings, and then click Import. During the
import, BCS validates the XML in the model, queries the connection settings object, and connects to the on-
premises OData source.
When you import a BDCM model into the BDC metadata service, you are creating an external content type. This
external content type is available for tenant-wide use.
Create an external list for the BCS hybrid scenario

The next step is to create the external list.
To create an external list for the BCS hybrid scenario
1. Open the site that you prepared by using an account that has site owner permissions and is a federated
account.
2. On the Quick Launch, click Site Contents, and then click add an app.
3. Click External List, and then provide a name for the list.
4. Click the Select External Content Type link next to the External Content Type box.
5. Select the external content type that you created, click OK, and then click Create.
6. Open the external list and confirm that your external data is displayed.
Once the list is created, validate the scenario.
See also
Concepts
Validate the Business Connectivity Services hybrid
scenario

Now that you have created an external list or deployed an app for SharePoint in SharePoint Online, you need to
test the security you put in place. Every account that will be accessing and manipulating the external data must
have three properties:
It must have user or greater permissions to the SharePoint Online site and the external list or app for
SharePoint.
It must be a federated account.
It must be a member of the on-premises global security group that you are using to control access to the
OData service endpoint. For example, it must be a member of ODataGroup.
In this procedure, you will open the SharePoint Online site and the external list or app for SharePoint with four
different accounts.
To validate security on the BCS hybrid

1. Identify or create one account for each of the account types listed in the following table.
ACCOUNT EXPECTED OUTCOME TROUBLESHOOTING STEP
Account A External data displayed and editable. If the external data does not display or
Has site/list/app permissions. you cannot edit it, check the site
Is federated. permissions, your federation setup, and
Is a member of the on-premises global the membership of your on-premises
security group ( ODataGroup). global security group; for example, the
ODataGroup.
Account B External data does not display. If the external data does display and
Does not have site/list/app permissions. you can edit it, check the site/list/app
Is federated. permissions.
Is a member of the on-premises global
security group ( ODataGroup).
Account C External data does not display. If the external data does display and
Has site/list/app permissions. you can edit it, check your federation
Is not federated (is an Office 365 setup and membership of your on-
account only). premises global security group ( Odata
Cannot be added to the on-premises Group).
global security group ( ODataGroup).
ACCOUNT EXPECTED OUTCOME TROUBLESHOOTING STEP
Account D External data does not display. If the external data does display and
Has site/list/app permissions. you can edit it, check the membership
Is federated. of your on-premises global security
Is not a member of your on-premises group ( ODataGroup) and the
global security group ( ODataGroup). permissions that you set on the OData
service endpoint that you configure in
Deploy a Business Connectivity Services
hybrid solution in SharePoint
2. Open (by using In-Private browsing if possible) the SharePoint Online site that contains the external list or
app for SharePoint by using each of the accounts in turn. Be sure to completely log out and close your
browser in between tests.
3. If you don't see the expected outcome, refer to the troubleshooting step in the previous table, fix the issue,
and repeat all four tests until you achieve the expected outcome.
If you see the error message:
ResourceBudgetExceeded, sending throttled status code.
Exception=Microsoft.SharePoint.SPResourceBudgetExceededException: ResourceBudgetExceeded at
Microsoft.SharePoint.SPResourceTally.Check(Int32 value) at
Microsoft.SharePoint.SPAggregateResourceTally.Check(SPResourceKind kind, Int32 value) at
Microsoft.SharePoint.Client.SPClientServiceHost.OnBeginRequest()
You can either remove the throttling:
$webapp = Get-SPWebApplication -Identity http://<URL of your on-premises farm>

$rule =
$webapp.AppResourceTrackingSettings.Rules.Get([Microsoft.SharePoint.SPResourceKind]::ClientServiceRequestDurat
ion)
$rule.Remove()
Or change the throttling value:
$webapp = Get-SPWebApplication -Identity http://<URL of your on-premises farm>

$webapp.
AppResourceTrackingSettings.Rules.Add([Microsoft.SharePoint.SPResourceKind]::ClientServiceRequestDuration,
150000, 150000)
$webapp.AppResourceTrackingSettings.WindowCount = 10
$webapp.AppResourceTrackingSettings.WindowSize = [System.TimeSpan]::FromSeconds(30)
$webapp.Update()
where the 150000 means 150 seconds.
See also
Concepts
Governance SharePoint Server

Read these articles to learn about planning the different aspects of governance in SharePoint.
CONTENT DESCRIPTION
What is governance in SharePoint? Learn about governance as an essential part of a successful

SharePoint deployment and the various components of an
organizational governance plan
IT governance in SharePoint Learn about key factors in governing a SharePoint service and
what to include in a service-level agreement.
Application management and governance in SharePoint Learn how to govern applications for SharePoint by creating a
customization policy and understanding the app model,
branding, and life-cycle management.
Information management and governance in SharePoint Learn how to plan effective information architecture to ensure
that your SharePoint solution meets your business needs.
Plan for managed metadata in SharePoint Server Learn about managed metadata, term sets, and taxonomy in
SharePoint.
How to use the Managed Solutions Gallery Learn how to use the Managed Solutions Gallery for code-
based sandbox solutions in SharePoint Server 2016,
eDiscovery and in-place holds in SharePoint Server Learn about eDiscovery across SharePoint Server 2016 and
Exchange Server 2016, or SharePoint Server 2013 and
Exchange Server 2013, and the eDiscovery Center, eDiscovery
cases, in-place holds, and exports.
Records management in SharePoint Server Learn about records management and the records
management planning process in SharePoint Server.
Document management in SharePoint Server Learn about the elements of a document management
solution and the document management planning process in
SharePoint Server.
Workflow in SharePoint Server Learn about how to use Workflows in SharePoint to model
and automate business processes.
What is governance in SharePoint?

Governance is the set of policies, roles, responsibilities, and processes that control how an organization's business
divisions and IT teams work together to achieve its goals. Every organization has unique needs and goals that
influence its approach to governance. Larger organizations will probably require more—and more detailed—
governance than smaller organizations. A good governance plan can:
Streamline the deployment of products and technologies, such as SharePoint.
Help keep your organization's system secure and compliant.
Help ensure the best return on your investment in technology.
NOTE
The What is governance? poster gives a summary of this content. Download the PDF version or Visio version.
Governance team
Your governance policies should support your organization's goals and be kept up-to-date as your organization's
needs change. We recommend that you create a team from various disciplines across your organization to develop
and maintain these policies. Include people from as many of the following roles as possible:
ROLE RESPONSIBILITY
Executive stakeholders Key executives should define the overall goals of the
governance committee and periodically evaluate the success
of the implemented practices and policies.
Financial stakeholders Financial officers should make sure that governance rules and
processes help increase the return on your organization's
investment in SharePoint.
Business division leaders Business leaders represent the teams that do the primary
work of the enterprise and drive the architectural and
functional requirements of the deployment. They work with
information architects to structure the information
architecture and taxonomy standards. Business leaders also
work with IT leaders to create service-level agreements and
other support policies.
IT managers IT managers help develop their service offerings and

determine how to achieve their IT responsibilities (for example,
improving security and maintaining reliability) while
supporting the features required by the business teams.
Software development leaders Software development leaders help determine which

customization tools are approved, how to verify code security,
and ensure code-related best practices.
ROLE RESPONSIBILITY
Technical specialists Technical specialists design, build, and run IT services and
solutions.
Trainers Instructional experts should develop a training plan for your

organization.
Influential information workers The members of your organization who do the day-to-day
work should help ensure that the services and information
architecture meet their needs.
Information architects or taxonomists Members of these groups design information systems and
taxonomies. Based on their analysis of the information needs
of the audience, they develop plans that support
organizational objectives and define site architecture and
navigation.
Compliance officers Governance includes making sure that an organization meets

its regulatory and legal requirements and manages its
corporate knowledge. If your organization has roles that are
responsible for compliance or legal oversight, include
representatives from those disciplines in your governance
team.
Your organization might not have all of these roles, or it might use a different name for some of these roles.
Governance and training

Great training, good resources, and effective search are keys to user adoption. We recommend you provide the
employees of your organization with the following:
PROVIDE WHY?
Training for the products and services Training and education about SharePoint in your governance
plan helps drive adoption and reduce support costs.
Education about your governance policies Training your user community appropriately increases
compliance with your policies, increases satisfaction with your
services, and reduces support costs.
Content to support your services and policies Having good quality resources and information available helps
your users find the answers when they have questions about
a service, process, or policy.
A good search infrastructure Having a good search infrastructure helps your users find
what they need when they need it.
Best practices for governance plans

An effective governance plan anticipates the needs and goals of your organization's business divisions and IT
teams. Because every enterprise is unique, we recommend that you tailor a governance plan to your environment
by using the following steps.
1. Determine initial principles and goals. The governance committee should develop a governance vision,
policies, and standards that can be measured to track compliance and to quantify the benefit to your
organization. For example, your plan should identify service delivery requirements for both technical and
business aspects of your SharePoint deployment.
2. Classify your business information. Organize your information according to an existing taxonomy, or
create a custom taxonomy that includes all the information that supports your business solution. After your
information is organized, design an information architecture to manage it. Then, determine the most
appropriate IT services to support it.
3. Develop an education strategy. The human element is, after the governance plan, the most important
ingredient in the success or failure of a SharePoint deployment. A comprehensive training plan should show
how to use SharePoint according to the standards and practices that you are implementing and explain why
those standards and practices are important. Your plan should cover the kinds of training required for
specific user groups and describe appropriate training tools. For example, your IT department might
maintain a frequently asked questions (FAQ ) page about its SharePoint service offerings, or your business
division might provide online training that shows how to set up and use a new document management
process.
4. Develop an ongoing plan. Successful governance is ongoing. The governance committee should meet
regularly to review new requirements in the governance plan, reevaluate and adjust governance principles,
and resolve conflicts among business divisions for IT resources. The committee should provide regular
reports to its executive sponsors to promote accountability and to help enforce compliance across your
organization. Although this process seems complicated, its goals are to increase the return on your
investment in SharePoint, take full advantage of the usefulness of your SharePoint solution, and improve
the productivity of your organization.
See also
Concepts
Information management and governance in SharePoint
Application management and governance in SharePoint
Other Resources
Governance planning in SharePoint
What is governance poster (Visio format)
What is governance poster (PDF format)

How will you control the services that you offer? What will you provide with each service? What will you include in
service-level agreements for each service? And how do you prevent proliferation of unmanaged servers? These
questions should be answered as part of your IT governance plan.
We recommend that you develop a good governance plan when you create an IT service to support SharePoint. A
good governance plan ensures that the service meets the business needs of your organization securely and cost-
effectively. When you add to the service, a good governance plan helps you do so seamlessly. A good governance
plan to run a successful IT service should include:
A Governance team defines the initial offerings of the service and its ongoing policies, and meets regularly
to evaluate success.
The policies you develop are communicated to your organization and are enforced.
Users are encouraged to use the service and not create their own solutions. Installations are tracked and
rogue installations are blocked.
What is a SharePoint service?

A SharePoint service is an IT service that offers hosted sites based on SharePoint. The benefits of a SharePoint
service include backup and recovery, content storage, support for customizations, security, and service levels
based on speed and availability as show in the following illustration.
Elements of a successful service

As you plan and implement your SharePoint service, consider the following elements that can contribute to the
success of the governing effort:
Form and use a governing group. Your IT service for SharePoint should be governed by a group that
includes executive stakeholders, business division leaders, influential information workers, IT managers, and
IT technical specialists, among others. The goal of the governing group should be to oversee the service. In
this capacity, the governing group defines the initial offerings of the service, defines the service's ongoing
policies, and meets regularly to evaluate success.
Communicate the policies. The governance policies that you develop must be publicized to your
organization. Maintain a website that describes the service.
Encourage use of the service. Discourage or block users from deploying their own servers. Instead,
encourage them to use the service. Isolated servers may not be configured according to IT security policy
and the organization's regulatory requirements. Furthermore, users who deploy their own servers may not
properly back up their servers or keep servers up-to date with software patches and updates. Finally,
content on servers that are not governed by the service may not be detected by the organization's indexing
service, which may create isolated pockets of content.
What to govern in a SharePoint service

Determine limits and policies for the areas shown in the following table.
Areas that should have limits or policies in a governance plan
AREA RECOMMENDATION
Security, infrastructure, and web application policies How is the system and infrastructure maintained and who has
access at what levels? What's the maximum upload size you
want to allow? Are you controlling the use of fine-grained
permissions?
Data protection (backup and recovery) Vary the level of data protection that you offer based on
service levels. Plan how often you back up the farms and how
quickly you can guarantee the data is restored.
Site policies Use site policies to help control site proliferation. A site policy
defines the life cycle of a site by specifying when the site will
be closed and when it will be deleted. When you close or
delete a site, any subsites are also closed or deleted. If an
Exchange mailbox is associated with a site, the mailbox is
deleted from Exchange Server 2013 when the site is deleted.
Quotas Quota templates define how much data can be stored in a site
collection and the maximum size of uploaded files. Associate
different quota templates with site collections at different
service levels.
Asset classification Classify sites and content by value and impact of the content
to the organization (such as high, medium, or low business
value/impact). That classification then controls other
requirements, such as encryption for high business impact
information.
Impact = Exposure
If this leaks, will it hurt my business?
Value = Availability
If this isn't available, can my business run?
Service-level agreements
Your organization should create appropriate service-level agreements for each service you provide. A good
service-level agreement should include:
The approval process, including the length of time and approvals necessary to create a site.
Costs for users or departments.
Operations-level agreement, which specifies which teams perform which operations and how frequently.
Policies around problem resolution through a support team.
Negotiated performance targets for first load of a site, subsequent loads, and performance at remote
locations.
Recovery, load balancing, and failover strategies.
Customization policies.
Storage limits for content and sites.
How to handle inactive or stale sites.
Multilingual support.
Deployment governance
In addition to governing services that you offer, you also need to govern installations of SharePoint in your
environment.
Track installations An Active Directory Domain Services (AD DS ) marker named Service Connection
Point identifies the SharePoint servers in an organization. Set this marker for each domain in your
organization if you want to track installations in all domains. See Track or block SharePoint Server 2010
installations.
Block installations You can block installations of SharePoint Server 2016 to prevent users from installing
it to unauthorized servers that you don't want to support. Use a Group Policy in Active Directory Domain
Services (AD DS ) to set a registry key on all servers to block installations. This registry key existed by
default in SharePoint Server 2010, but is not included in SharePoint Server 2016. You can create it yourself
in the registry if you want to block installations. See Track or block SharePoint Server 2010 installations.
Keep current with software updates Keep your servers current. Test and install recommended software
updates. See the Updates Resource Center for SharePoint Server 2016.
Site collection upgrades Site collections can now be upgraded independently from the content databases.
Determine who, when, and how to upgrade site collections when a new version or an update is available.
See Plan for site collection upgrades in SharePoint 2013.
Application management and governance in
SharePoint

How will you manage the applications that are developed for your environment? What customization do you allow
in your applications, and what are your processes for managing those applications?
For effective and manageable applications, your organization should consider the following:
Customization policy SharePoint Server 2016 includes customizable features and capabilities that span
multiple product areas, such as business intelligence, forms, workflow, and content management.
Customization can introduce risks to the stability, maintenance, and security of the environment. To support
customization while controlling its scope, you should develop a customization policy.
Life-cycle management Follow best practices to manage applications and keep your environments in sync.
Branding If you are designing an information architecture and a set of sites to use across an organization,
consider including branding in your governance plan. A formal set of branding policies helps ensure that
sites consistently use enterprise imagery, fonts, themes, and other design elements.
Solutions or apps for SharePoint? Decide whether a solution or an app for SharePoint would be the best
choice for specific customizations.
Customization policy
Determine the types of customizations you want to allow and how to manage them. Your customization policy
should include:
Service-level descriptions What are the parameters for supporting and managing customizations in your
environments? See Service-level agreements.
Guidelines for updating customizations How do you manage changes to customizations, and how do
you roll out those changes to your environments? Consider ways to manage source code, such as a source
control system and standards for documenting the code.
Processes for analyzing How do you understand whether a particular customization is working well in
your environment, or how do you decide which ones to create, change, or retire?
Approved tools for customization Consider development standards, such as coding best practices and
the tools that you will to use across your organization. For example, you should decide whether to allow the
use of SharePoint Designer 2013 and Design Manager, and specify which site elements can be customized
and by whom.
Process for piloting and testing customizations How do you test and deploy customizations? How
many people should be in a pilot testing group? What are your standards for testing and validating
customizations?
Who is responsible for ongoing support Who will be responsible for supporting customizations in your
environments—individual teams or a central group?
Guidelines for packaging and deploying customizations Do you have individual packages for each, or
do you include several in a feature or solution? Which customizations should be apps for SharePoint
instead of solutions? How do you ensure that customizations in one environment do not affect the rest of
your SharePoint implementation?
Specific policies regarding each potential type of customization What types of customizations do
you allow?
For more information about kinds of customizations and their potential risks, see the Customizations table
later in this article. For more information about processes for managing customizations, see the white paper
SharePoint Products and Technologies customization policy. Most of this content still applies to SharePoint
Server 2016.
Policies around using the App Catalog and SharePoint Store Which apps for SharePoint do you want
to make available to your organization? Can users purchase apps directly? See Solutions or apps for
SharePoint? later in this article for more information.
The highly customizable design of SharePoint products enables you to provide the look, behavior, or functionality
that meets your business needs. Customizations can introduce risk to your environment, whether that risk is to the
environment's performance, availability, or supportability. Conversely, a "no customizations" policy severely
restricts your organization's ability to take advantage of the SharePoint platform.
All customizations are not the same. You must decide carefully which kinds of customizations to allow in your
environment. You must ensure the customizations support the performance, availability, and supportability you
want for your environment. Your governance policy should balance a level of acceptable risk against the business
needs for your organization.
What is considered a customization? All of the following are considered kinds of customizations in SharePoint
products:
Configuration Using the SharePoint user interface to configure SharePoint products.
Branding Changing logos, styles, colors, master pages and page layouts, and so on to create a custom look
for your SharePoint sites. See more about Branding.
Custom code Using developer tools to add or change functionality in SharePoint products or to interact
with other applications. Risk can vary depending on kind of functionality and level of trust (full trust
solutions should be rarely used; consider apps for SharePoint first).
TIP
Sandboxed solutions are deprecated in this release, so they are not the best option for custom code in the long term
Some customizations have very little risk or impact on your environment. Others have the potential for much
higher risk and impact. The following table provides examples of different kinds of customizations, the risk level
associated with that kind of customization, and potential issues that you might face if you allow that kind of
customization.
Customizations
TYPES OF CUSTOMIZATIONS AND

RISK LEVEL EXAMPLES CONSIDERATIONS OR IMPACT
Unsupported/High Unsupported customizations such as Will not be supported through

direct changes to the database schema Microsoft Customer Support.
or modifying files on the file system. Will be unable to upgrade.
Do not use.
TYPES OF CUSTOMIZATIONS AND
RISK LEVEL EXAMPLES CONSIDERATIONS OR IMPACT
Moderate to high Creating applications that interact with Potential for service outage or
or redirect actions in key pipelines, such performance issues.
as events, claims, and so on. Might require rework at upgrade
Moderate to low Using a custom Web Part outside a Short or long-term performance issues
sandbox environment, creating custom or page errors.
actions such as adding a menu item, or Might require rework at upgrade.
creating a custom site provisioning
process.
Low Using solutions in a sandbox Short-term performance issues; you can

environment. avoid some performance issues by
using resource throttling and quotas.
Very low to no risk Using apps for SharePoint or using Minor configuration or page errors that
functionality within the product or would have to be addressed. Apps can
configurations, such as associating a be uninstalled or updated.
workflow with a list or using an instance
of a built in Web Part.
NOTE
For more information about customizations and upgrade, see Create a plan for current customizations during upgrade to
SharePoint 2013.
Also, when you think through the customizations to allow in your environment, consider carefully whether a
particular customization is necessary. If it recreates functionality that is already available in the product (such as
creating a Web Part that does the same thing as the Content Editor Web Part or the Content by Query Web Part),
then that might be unnecessary work. Consider first whether the standard functionality can do what you want, or
check the SharePoint Store to see if there is an app for SharePoint available that does what you need.
Life-cycle management
Follow these best practices to manage applications based on SharePoint Server 2016 throughout their life cycle:
Use separate development, preproduction, and production environments, and keep these environments as
synchronized as possible so that you can accurately test your customizations.
Test all customizations before releasing the first time and after any updates have been made before you
release them to your production environment.
Use source code control and solution and feature versioning to track changes to code.
Branding
Consistent branding with a corporate style guide makes for more cohesive-looking sites and easier development.
Store approved themes in the theme gallery for consistency so that users will know when they visit the site that
they are in the right place.
SharePoint Server 2016 includes a new feature to use for branding, Design Manager. By using Design Manager,
you can create a visual design for your website with whatever web design tool or HTML editor you prefer and then
upload that design into SharePoint. Design Manager is the central hub and interface where you manage all aspects
of a custom design.
Solutions or apps for SharePoint?
SharePoint Server 2016 has a new development model based on apps for SharePoint. Apps for SharePoint are
self-contained pieces of functionality that extend the capabilities of a SharePoint website. An app may include
SharePoint features such as lists, workflows, and site pages, but it can also use a remote web application and
remote data in SharePoint. An app has few or no dependencies on any other software on the device or platform
where it is installed, other than what is built into the platform. Apps have no custom code that runs on the
SharePoint servers.
The guidance for whether to use apps for SharePoint or SharePoint solutions is to:
Design apps for end users
Apps for SharePoint:
Are easy for users (tenant administrators and site owners) to discover and install.
Use safe SharePoint extensions.
Provide the flexibility to develop future upgrades.
Can integrate with cloud-based resources.
Are available for both SharePoint Online and on-premises SharePoint sites.
Use farm solutions for administrators
SharePoint solutions:
Can access the server-side object-model APIs that are needed to extend SharePoint management,
configuration, and security
Can extend Central Administration, Microsoft PowerShell cmdlets, timer jobs, custom backups, and
so on.
Are installed by administrators.
Can have farm, web application, or site-collection scope.
For more information about the new development model, Apps for SharePoint compared with SharePoint
solutions, and Deciding between apps for SharePoint and SharePoint solutions.
Set a policy for using apps for SharePoint in your organization. Can users purchase and download apps? How do
you make your organization's apps available? How do you tell if they're being used?
SharePoint Store Determine whether users can purchase or download apps from the SharePoint Store.
App Catalog Make specific apps for SharePoint available to your users by adding them to the App
Catalog.
App requests Configure app requests to control which apps are purchased and how many licenses are
available.
Monitor apps Monitor specific apps in SharePoint Server 2016 to check for errors and to track usage.
Information management and governance in
SharePoint

How will you govern the information in your organization, such as documents, lists, websites, and webpages? How
do you maximize the information's usability and manageability? Who has access to what information? How are
you making information available internally and externally, and to whom?
What is information architecture?

Information architecture determines how the information in that site or solution—its webpages, documents, lists,
and data—is organized and presented to the site's users. Information architecture is often recorded as a
hierarchical list of content, search keywords, data types, and other concepts.
Assess your organization's information architecture to make it as efficient as possible: A comprehensive
assessment of your organization's information architecture can help you identify efficiencies, such as the following:
Use metadata to make it easier to search for and compare related data or content.
Manage versions and records to ensure that you can tell which is the authoritative version of a document.
Catalog and store information properly so decision-makers can find and rely on the right data.
Design navigation and present information so that users can find important sites and information.
Integrate your information architecture with your environment's search strategy, so your users can find the
right information. Information architecture includes the wireframe and site map, search and navigation,
managed metadata tags, and content types.
Define a publishing strategy: distribute authoring tasks and use cross-site publishing to control the design
of the site and display of the content.
Good information architecture supports the following goals:
Manageable Can the IT team effectively implement and manage the information?
Meets requirements Does the information architecture meet regulatory requirements, privacy needs, and
security goals?
Increases business effectiveness Does the architecture add to your organization's effectiveness?
Questions to ask when you design a site or solution:
QUESTION MORE INFORMATION
How will data be presented? Plan for business intelligence in SharePoint 2013
How will site users navigate? Overview of site navigation in SharePoint Server
How will search be configured and optimized? Overview of search architecture in SharePoint Server
How can you organize content so that searches return useful Best practices for organizing content for search in SharePoint
results? Server
What types of content will live on sites? Plan content types and workflows in SharePoint 2013 and
Plan for Internet, intranet, and extranet publishing sites in
SharePoint Server
How will content be tagged and how will metadata be Plan for managed metadata in SharePoint Server
managed?
Does any of the content on the sites have unique security Permissions planning for sites and content in SharePoint
needs? Server
What is the authoritative source for terms? Plan terms and term sets in SharePoint Server 2013
How will information be targeted at specific audiences? Audience and content targeting planning (SharePoint Server
2010)
Do you need to have language-specific or product-specific Variations overview in SharePoint Server

versions of your sites?
Who will write content for the site and what method will you Overview of publishing to Internet, intranet, and extranet sites
use to publish it? in SharePoint Server
Information access
Be sure to consider access to content when you design your solution and sites. This overlaps with IT governance as
you consider your entire environment. Ask these questions:
Information management: permissions and audiences
How do I structure permission in a site? Overview of site permissions in SharePoint 2013
How do I target content to a specific audience? Audience and content targeting planning (SharePoint Server
2010)
Should I use Information Rights Management (IRM) to protect Plan Information Rights Management (SharePoint Server
content? 2010)
IT governance: access
How do I make this content available to external users? SharePoint Server design samples: Corporate portal and
extranet sites
How do I make sure that only people who need access have Security and permissions (SharePoint 2013)
it?
Information management tools

Govern your information by using tools for information management, including:
TOOL MORE INFORMATION
Use workflows and approvals for Document Centers and site Plan content types and workflows in SharePoint 2013
pages—wherever official documentation is stored.
Use approval for published websites to control pages. Plan for Internet, intranet, and extranet publishing sites in
SharePoint Server and Plan content types and workflows in
SharePoint 2013
Use version history and version control to maintain a history Plan document versioning, content approval, and check-out
and master document. controls in SharePoint 2013
Manage libraries by using the Content Organizer. Configure the Content Organizer to route documents
Use site policies to manage site collection life cycles. Overview of site policies in SharePoint Server
Use Information Rights Management and auditing to secure Apply Information Rights Management to a list or library and
and audit important corporate assets and any sites that Configure audit settings for a site collection
contain sensitive information.
Determine the rules or policies that you need for the following types of items: pages, lists, documents, records, rich
assets, blogs and wikis, feeds, anonymous comments, anonymous access, terms and term sets, and external data
(Business Connectivity Services).
As a good information management practice, consider the balance among the following factors:
Availability Content needs to be available when users need it and where they can get to it.
Access Consider who has access to the content. If it should be secure, is it?
Redundancy Shared copies reduce redundancy and provide one version of a document.
Consider your priorities for different content by thinking through questions like these:
Which of these factors is the highest priority for each type of content?
Is availability more important than access?
Is access more important than redundancy?
What would make it so difficult for users that they would be tempted to use a different solution?
What trade-offs are possible or desirable?
Resources for planning information architecture

The following table presents resources that are available to help information architects plan the information
architecture of your SharePoint solution.
Information architecture resources
TO PLAN … SEE …
The structure of sites and subsites Plan sites and site collections in SharePoint Server
Document libraries Plan document libraries in SharePoint 2013

TO PLAN … SEE …
Navigation Overview of managed navigation in SharePoint Server

Metadata Plan managed metadata (OLD)
Search Plan search in SharePoint Server
Content expiration Plan for information management policy in SharePoint Server
Publishing and managing pages Plan for Internet, intranet, and extranet publishing sites in
SharePoint Server
Templates Site Types: WebTemplates and Site Definitions
Content approval Plan document versioning, content approval, and check-out

controls in SharePoint 2013
Plan content approval and scheduling
Information management policies Plan for information management policy in SharePoint Server
Social computing Plan for My Sites in SharePoint Server

Plan for OneDrive for Business in SharePoint Server
Plan for managed metadata in SharePoint Server

With managed metadata in SharePoint Server, you can create a unified taxonomy of terms that you can use
throughout your SharePoint farm. In this article, we walk through the configuration decisions that you need to
make before you configure the managed metadata service application in SharePoint Server.
Before you configure managed metadata, it's important to understand what managed metadata is and how it
works in SharePoint. Before you read this article, be sure to read Introduction to managed metadata.
Overview of the managed metadata service in SharePoint Server

In SharePoint Server, managed metadata is implemented through a service application and the Managed
Metadata Web Service which runs on the Application and Front-end server roles. You can create multiple
managed metadata service applications if you need separate term sets for specialized use. Each service
application has its own database containing the term set, terms, keywords, and so on.
Connections between the managed metadata service application and your web applications are handled by
managed metadata connections. Using these connections, you can map different managed metadata service
applications to different web applications if needed, and configure features around keyword and term set
creation policy.
If you have multiple SharePoint Server farms and you want to share a managed metadata term store between
them, you can publish the service application in one farm and the others can connect to it. (This requires a trust
relationship between the farms.)
The managed metadata service application also provides publishing functionality for content type hubs, which
are site collections where you can create standard content types and share them among other site collections.
Let's look at the decisions you need to make in these areas before you configure managed metadata.
Isolating managed metadata term sets

Within a term store, you can create a variety of different term sets. These term sets can be organized in groups.
Groups offer some security isolation by allowing you to specify who can manage or contribute to them.
However, users in general can access and use the terms themselves. If you want to restrict a term set to a specific
group of users, there are two options.
First, you can allow users to create term sets that are local to a site collection. These term sets are not available in
other site collections. (We talk more about this option in the next section.)
Second, you can provide even greater isolation for a term set by housing it in a separate managed metadata
service application. This gives you a completely separate term store in a separate database which you can restrict
to a particular set of users.
If you have sensitive areas such as legal or human resources where you want a term store with limited access,
consider this second approach. Users of this term store can also be granted access to your main term store.
Decision
Before you configure managed metadata in SharePoint, decide if you need more than one managed metadata
service application for separate term stores. (You can add additional service applications in the future if needed.)
Using local term sets
Beyond the global term sets that are available across all of your site collections, you can create term sets that are
local to a site collection. When users create a managed metadata column for a SharePoint list, they have the
option of creating a new term set rather than using global term sets.
This can be useful if you want to use managed metadata in ways that don't apply to the entire organization, such
as metadata for a particular project or event.
By using local term sets, different teams and business groups can create their own managed metadata without
needing to request formal updates to a global term set, and you can keep the global term sets focused on core
areas of your business.
If you don't want to allow users to create their own term sets that are local to site collections, you can disable this
feature when you configure the managed metadata connection.
Decision
Before you configure managed metadata in SharePoint, decide if you want to allow local term sets to be created.
(You can have different setting for each service application that you create.)
Managed metadata keywords and folksonomy

When you use a managed metadata column in a SharePoint list, users who fill out that column have to use one
of the available values defined in the term store that the column is connected to. This is one of the primary
advantages of managed metadata - you're certain the value was chosen from a predefined list.
However, SharePoint managed metadata also supports tagging functionality where users can tag SharePoint
items such as documents with keywords that they create that aren't in the existing term store. These keywords
accumulate in a list in the term store, and you can manage them by consolidating them and adding them to
existing or new term sets as needed. This allows a folksonomy approach where users can create new keywords
as needed without having to go through a formal process to update a particular term set.
If you want to take a more formal approach to managed metadata, you can disable this feature when you
configure the managed metadata connection. In this case, users will have to pick from the existing terms in the
term store and add those values to specific fields that you create for that purpose.
Decision
Before you configure managed metadata in SharePoint, decide if you want to allow tagging of SharePoint items
with keywords that are not in the term store.
Publishing managed metadata content types

In addition to sharing managed metadata, you can also use the managed metadata service to share content
types. By specifying a site collection as the content type hub when you configure the managed metadata service
application, you can share all content types in the site collection's content type gallery, making them available to
other site collections.
Decision
Before you configure managed metadata in SharePoint, decide if you want to create a content type hub. (You can
also add one later.)
See also
For the SharePoint Online version of this article, see Introduction to managed metadata.
Configure the Managed Metadata service

In this article we cover how to configure a Managed Metadata service application in SharePoint Server. Be sure
you've planned your configuration before you follow the procedures below.
To configure a Managed Metadata service application, you perform the following steps:
1. Register a managed account in SharePoint Server to run the Managed Metadata service application pool.
2. Start the Managed Metadata Web Service (SharePoint Server 2013 only).
3. Create a Managed Metadata service application.
4. Configure the Managed Metadata service connection
Start the Managed Metadata Web Service (SharePoint Server 2013

only)
If you are using SharePoint Server 2013, you must start the Managed Metadata Web Service on at least one
server in your farm. (This service is started automatically in SharePoint Server 2016.)
To start the Managed Metadata Web Service
1. On the SharePoint Central Administration Web site home page, click Manage services on server.
2. Click Server and then select the server where you want to start the Managed Metadata Web Service.
3. In the Service list, click Start for the Managed Metadata Web Service.
Configure a Managed Metadata service application in SharePoint

Server
To run the application pool, you must have a standard domain account. No specific permissions are required for
this account. Once the account has been created in Active Directory, follow these steps to register it with
SharePoint Server.
To register a managed account
1. On the SharePoint Central Administration Web site home page, in the left navigation, click Security.
2. On the Security page, in the General Security section, click Configure managed accounts.
3. On the Managed Accounts page, click Register Managed Account.
4. In the User name box, type the name of the account.
5. In the Password box, type the password for the account.
6. If you want SharePoint Server to handle changing the password for the account, select the Enable
automatic password change box and specify the password change parameters that you want to use.
7. Click OK.
Once you have configured the registered account, you must create a Managed Metadata service application. Use
the following procedure to create the service application.
2. On the Manage Service Applications page, click New, and then click Managed Metadata Service.
3. In the Name box, type a name for the service application (for example, Managed Metadata Service).
4. In the Database Server box, type the instance of SQL Server where you want to create the Managed
Metadata database.
5. In the Database Name box, type the name that you want to use for the Managed Metadata database.
6. In the Failover Database Server box, type the name of your failover database server if you're using one.
7. Select the Create new application pool option and type a name for the application pool in the text box.
8. Select the Configurable option, and, from the drop-down list, select the account for which you created the
managed account earlier.
9. If you're configuring a Content Type Hub, type the URL for that site collection in the Content Type Hub
box.
10. Click OK.
The Managed Metadata service application has now been configured. The next step is to configure the settings for
the Managed Metadata service connection.
Configure the Managed Metadata service connection

Each managed metadata service application has an associated managed metadata service connection. Using the
service connection, you can configure the following four options:
This service application is the default storage location for Keywords - Determines if this service
application is used as the default location for enterprise keywords.
If you are using more than one Managed Metadata service application, only select this option for one
service application per web application.
If you do not want to use the enterprise keywords functionality, make sure this check box is not selected for
any of your Managed Metadata service connections.
This service application is the default storage location for column specific term sets - Determines if
this service application is used to store custom term sets that are created at the site collection level.
If you are using more than one Managed Metadata service application, only select this option for one
service application per web application.
If you do not want to allow custom term sets, make sure this check box is not selected for any of your
Managed Metadata service connections.
Consumes content types from the content type gallery at http://<site> - Determines if this service
application makes the content types that are that are defined in the specified content type gallery available
to users of sites in this web application. This option is available only if the service has a hub defined to share
content types.
using the content type - Determines if change in content types are published to sub-sites and lists that
use the content type.
Use the following procedure to set these options:
To configure a managed metadata service connection
2. Find the managed metadata service connection for the service application that you want to configure. (Look
for Managed Metadata Service Connection in the Type column.)
3. Highlight that row, and then click Properties.
4. Select the check boxes for the options that you want to enable, and then click OK.
How to use the Managed Solutions Gallery

Learn how to use the Managed Solutions Gallery for code-based sandbox solutions in SharePoint Server 2013,
If you want to govern the activation of code-based sandbox solutions, you can utilize the Managed Solutions
Gallery. This gallery is a specialized site collection and document library that identifies trusted code-based sandbox
solutions within a SharePoint web application. Administrators with permission to upload solutions to the Managed
Solutions Gallery can use this tool to determine which effectively approve the solutions they want to allow to
activate within the web application.
After an administrator uploads a solution to the Managed Solutions Gallery, site collection administrators can add
and activate the solution using existing processes. Code-based sandbox solutions that are not in the Managed
Solutions Gallery can't be activated by site collection administrators within the web application.
IMPORTANT
When an InfoPath form that contains custom code is published in a web application with a Managed Solutions Gallery, the
form no longer renders in a browser. It also creates a category of sandbox solution that cannot be approved using the
Managed Solutions Gallery, so publishing fails and the form can no longer be rendered by InfoPath Forms Services. For
additional information, see InfoPath Forms Containing Code Fail to Activate when using the Managed Solutions Gallery.
Overview
The Managed Solutions Gallery is a new feature in the September Public Update for code-based sandbox
solutions which can be downloaded from here, SharePoint Updates https://go.microsoft.com/fwlink/?
LinkID=827479
NOTE
The September Public Update includes the English-language version of the Managed Solutions Gallery. A future Public
Update will include the Multi-language versions of the Managed Solutions Gallery.
NOTE
To initially setup and configure the Managed Solutions Gallery is only available by using the following Microsoft PowerShell
cmdlets: New-SPUserSolutionAllowList, Enable-SPUserSolutionAllowList. To use these cmdlets you must use elevated
administrator privileges, by using RunAs Administrator. > Once the gallery is configured, it is treated as a document library
(that is, SPList) and can be managed by using the user interface.
Before you can use the Managed Solutions Gallery, you must create a site collection on the Master Gallery, and
then enable the functionality of the Managed Solutions Gallery.
Create and enable the Managed Solutions Gallery
1. Verify that you meet all of the following minimum requirements:
You must have membership in the securityadmin fixed server role on the SQL Server instance
You must have membership in the db_owner fixed database role on all databases that are to be updated.
You must be a member of the Administrators group on the server on which you are running the Microsoft
PowerShell cmdlet.
cmdlets.
3. At the PowerShell command prompt, type the following command to create the site collection in the
Managed Solutions Gallery.
# Creates a site collection and the Managed Solutions Gallery

$managedSolutionsGallerySite = New-SPSite -Url "http://localhost/sites/allowlist" -Template "STS#0" -Name "
Managed Solutions Gallery site collection" -OwnerAlias "contoso\admin" -OwnerEmail "admin@contoso.com"
$managedSolutionsGallery = New-SPUserSolutionAllowList -Site $managedSolutionsGallerySite -ListTitle "Managed

Solutions Gallery"
4. At the PowerShell command prompt, type the following command to enable the functionality of the Managed
Solutions Gallery.
# Enables the Managed Solutions Gallery functionality

Enable-SPUserSolutionAllowList
If you want to disable the functionality of the Managed Solutions Gallery, you can run the **Disable-
SPUserSolutionAllowList** cmdlet.
Transform your sandbox solutions to the SharePoint add-in model

We encourage customers that are considering moving away from the sandbox solution to the new SharePoint add-
in model to review the considerations outlined here, Sandbox solution transformation guidance - InfoPath
SharePoint Add-ins are self-contained extensions of SharePoint websites that you create, and that run without
custom code on the SharePoint server. To learn more about Add-ins see, SharePoint Add-ins
See also
Other Resources
Disable-SPUserSolutionAllowList
Get-SPUserSolutionAllowList
Searching and using keywords in the eDiscovery
Center

Keywords help you narrow down the specific content that you produce through export for an eDiscovery case. By
creating focused searches, you increase the likelihood that content is applicable to a case, and reduce the amount
of content that you need to manage.
Your organization may create an eDiscovery case if it receives a request for potential evidence to support litigation,
an audit, or an investigation.
Filters and Queries

After you create a case, you add Discovery Sets to it. Discovery Sets contain the content sources - such as
SharePoint subsites - that are may be relevant to a case. Filters help you narrow down the source, such as by
keywords, a range of start and end dates, domains, or by author or sender.
Once you have identified potential sources, queries help further refine the content that you want to export to
review or to provide to counsel and/or the requesting party. You can construct your filter by using keywords, date
ranges, author/recipients, domains, and proximity searches.
NOTE
In order for content to be discovered, it must be crawled by search. For more information about the default file types that
are crawled, see the article Default crawled file name extensions and parsed file types in SharePoint Server 2013.
Operators and Proximity in Keywords

Special operators, such as Boolean and proximity operators, can be used to create relationships between multiple
keywords. The operators must be written in all uppercase letters. If you need to use multiple operators, you can
group them with parenthesis to determine the order in which they are applied.
For example, you might be looking for content with the term executive, but you don't want to find the term when it
appears in the title of a frequent report in your organization called the Executive Summary. When you use the
phrase executive NOT summary, you can narrow down the number of items returned from 300 to 188, since you
are eliminating any documents that contain the word Summary.
NOTE
When two words are specified with no operator, an implied AND exists. For example: wooly worm is the same as wooly AND
worm .
USE TO EXAMPLE
AND Find content that contains all of the risk AND value AND VAR finds
words or phrases it separates. content that contains all three words.
USE TO EXAMPLE
OR Find content that contains either of the risk OR VAR finds all the content that
words or phrases it separates. contains either word.
NOT Exclude content that contains the term Executive NOT Summary finds all the
within a phrase. content that contains the phrase
Executive, unless the content also
contains the term Summary.
( ) Group words or phrases to show the (Risk AND management) OR (VAR OR

order in which they are applied. Value-at-risk)
NEAR(n) Finds words that are near each other, Mid NEAR(5) Office finds Mid and
where n equals the number of words Back Office and Mid-Office and Mid,
apart. If no number is specified, the Back, and Front Office.
default distance is 8 words.
Using Wildcards
Wildcards can help you expand your keywords to include terms that contain part of a keyword or terms that have
alternative spellings.
USE TO EXAMPLE
* at the end of word Find terms that contain the root word risk* finds risk, risks, risked, risking, and
and any additional letters. risky
Basic rules for using keywords in filters and queries

A content filter or query can include words, quoted phrases, and terms that use keywords and properties.
Separate terms with spaces.
Commonly used words such as the , it , and by , and single-digit numbers, are ignored.
When you enclose a phrase in quotation marks, your search returns content within the chosen scope that
contains the exact phrase that you typed. If there is any variance between the phrase in quotations and the
actual content, the content will not be found.
Operators (for example, Boolean operators) - such as OR and AND — should be written as all uppercase.
If a property of SharePoint content is not listed in the Specify Property dropdown menu, you can search
for it with keywords. Enclose a property value in quotation marks to find an exact match, or leave the value
unquoted to find partial matches that begin with the letters typed. For example, if you look for
filename:"Budget" (with quotation marks), your search will return a file named "Budget.xlsx." A search for
filename:budget (without quotation marks) will also return the files "Budget_Current.xlsx" and
"Budget_Next.xlsx."
> [!NOTE]
A query must include a term to find. Queries that consist only of terms to exclude will produce an error
message.
Examples for applying rules
KEYWORDS EXAMPLE RESULTS
Executive Briefing Any content that contains both Executive and Briefing,
anywhere in the document, page, message, or metadata.
"Executive Briefing" Any content that contains the exact phrase "Executive
Briefing" anywhere in the document, page, or message.
"Executive Briefing" AND "Executive Summary" Any content that contains the exact phrases "Executive
Briefing" and "Executive Summary" anywhere in the document,
page, message, or metadata.
filename:budget Any file with budget in its filename, such as 2014 budget
projections.docx, 2015 budget priorities.pptx, 2014 budget
planning.xlsx, 2014 budget review.xlsx, and so on
filename:2014 budget filetype:xlsx Excel worksheets that contain the phrase 2014 budget, such
as "2014 budget planning.xlsx" and "2014 budget review.xlsx"
Query Scope
A query can apply to all the content in a case, to specific eDiscovery Sets, or a specific content source (such as Web
content or a fileshare) within an eDiscovery Set. Narrowing the scope may help you identify the right content,
especially if the case is large, and the search returns in other sources or eDiscovery Sets aren't relevant.
IMPORTANT
When the Select sources options is selected, any filters that may have been added as part of the Discovery set are not
included.
To set the scope of a query, click Modify Query Scope, and then select All case content, Select eDiscovery
Sets, or Select sources.
The All case content option includes all content from the list of sources, with any eDiscovery Set filters applied.
You can also include additional content locations when setting query scope.
Viewing and troubleshooting queries

After you run a query, you can view the SharePoint results by relevance to the query, or by the oldest or newest
date. You can see a preview of the document by hovering over its title.
To narrow down which items are exported, you can further refine the results by file extension and by property,
such as Author or Title.
In the query dialog box, click the Advanced Query Options link. You can see your underlying query syntax for
SharePoint, the content sources included in your query, any filters for your query, and any refinements.
Find more information about eDiscovery

For more information about eDiscovery cases, see the following articles:
Scenario: eDiscovery in SharePoint Server 2013 and Exchange Server 2013
Default crawled file name extensions and parsed file types in SharePoint Server 2013
Overview of crawled and managed properties in SharePoint Server 2013
Export content and create reports in the eDiscovery
Center

You export content from a case when you are ready to deliver it to an authority or want to work on it with another
legal program. You can also create reports to identify the contents of and any search indexing issues with the
export. The export includes a load file based on the Electronic Discovery Reference Model standard.
Before you export content, the case should already have content sources, such as Web sites, and queries. Also, the
computer you use to export content has to meet the following system requirements:
32- or 64-bit version of Windows 7 and later versions
Microsoft .NET Framework 4.5
One of the following supported browsers:
Internet Explorer 10 and later versions
Mozilla Firefox or Google Chrome, with the ClickOnce add-in installed
When you first export content or create a report, the eDiscovery Download Manager is installed, which exports the
SharePoint content and reports to the your local computer. When downloading an eDiscovery export, users must
log into SharePoint with the same account that they are logged into on their client machine. If you receive a
warning asking whether or not to run the Download Manager, accept the warning and continue.
Export eDiscovery content

1. If your case is not already open, in an eDiscovery Center, click Cases, and then click the case in which you
want to export content.
2. In the Search and Export section, under Queries, click the name of the query you want to export. On the
query page, you can see the size and contents to be included in the export.
3. At the bottom of the query page, click Export.
4. Type a name for the export. By default, the export is named the same as the query it's based on, but you can
change the name.
5. On the page that appears, in the Options section, select any of the following:
6. To include versions of documents - if your organization tracks versions - select the Include versions for
SharePoint documents checkbox.
7. To include items that are encrypted or have an unrecognizable format, select the Include items that are
encrypted or have an unrecognized format check box.
8. Click OK.
9. Click Download Results.
10. If you are exporting content for the first time on a computer, you will be prompted to install the Discovery
Download Manager. Click Yes.
11. When you are finished exporting, click Close.
Create reports about exported content

Reports identify the SharePoint content, its location, and other information, as well as any errors, such as content
not exported as a result of search indexing issues. The reports are created in comma separated values format,
which can be opened in Excel or imported into many types of programs.
In Microsoft Excel, you can examine the contents further by sorting and filtering the columns. For example, you
could view only PowerPoint slides or sort by Web address or author.
want to export content.
2. In the Search and Export section, under Queries, click the name of the query you want to export.
3. At the bottom of the query page, click Export.
4. On the page that appears, in the Options section, select any of the following. The settings won't affect the
report itself, but the report will show how the settings would affect your query:
5. To include versions of documents - if your organization tracks versions - select the Include versions for
SharePoint documents checkbox. If your exported content contains many libraries that track versions, and
many of your authors use versioning, this could significantly increase the file size of the export.
6. To include items that are encrypted or have an unrecognizable format, select the Include items that are
encrypted or have an unrecognized format check box.
7. On the page that appears, click OK.
8. Click Download Report.
9. If you are exporting content for the first time on a computer, you will be prompted to install the Discovery
Download Manager. Click Yes.
10. When you are finished exporting the report, click Close.
The following reports (Excel CSV files) are downloaded to your computer in a folder named Reports.
Export Errors This report lists any errors that occurred during the export process.
SharePoint Index Errors
SharePoint Results Contains a list of every SharePoint items returned as a search result. This report
contains information such as the document type, the document author, the document URL, the URL and
name of the site where the document is located, and the date when the document was last modified.
NOTE
If you don't select the Include items that are encrypted or have an unrecognized format option when you
export search results or just download the reports, the index error reports are downloaded but they don't have any
entries. This doesn't mean there aren't any indexing errors. It just means that unindexed items weren't included in the
request to download the reports.

Default crawled file name extensions and parsed file types in SharePoint Server 2013
Overview of crawled and managed properties in SharePoint Server 2013

Once you have defined your sources, and placed them on hold if necessary, you can run queries to narrow down
and extract exactly the content you need for a particular case.
Efficient queries can make it much easier for you and other people involved in the case to manage the content,
because it reduces the overall volume and helps ensure that the content that you deliver is more likely to be
relevant.
Before creating queries, you should add content sources to your case. Find more information about working with
content sources in the article Add content to a case and place sources on hold in the eDiscovery Center.
NOTE
A query can contain a maximum of 100 SharePoint sources, and 500 keywords.
By default, a query searches across all content sources, you can choose which discovery sets or sources a query
searches if you don't need to search them all, which can make your queries run faster. You can also refine your
queries in other ways. For more information, see Searching and using keywords in the eDiscovery Center.
1. If your case is not already open, in an eDiscovery Center, click Cases, and then open the case you want to
create queries for. The case should already have content sources, such as Web sites.
2. In the Search and Export section, under Queries, click New Item.
3. Type a descriptive name for your query.
4. In the Query box, type the keywords you want to use to narrow down your query. Find tips for writing
queries in the See Also section.
5. To narrow down content by a date range, enter the Start Date and End Date.
NOTE
If you type the dates in the Start Date and End Date boxes, use the format mm/ dd / yyyy ; for example, you would use
03/01/2013 to specify March 1, 2013. Use the mm/ dd / yyyy format even if the regional settings on the local computer are
configured with a different format, such as dd /mm/ yyyy . Alternatively, select the start and end dates using the date picker.
1. To limit results to the author of a document or list item, or to a specific sender of e-mail messages, type the
names or e-mail addresses in the Author/Sender box.
2. If you have multiple sources and Discovery Sets, but don't need to search them all, click Modify Query
Scope. Then, specify the discovery sets or content sources you want.
3. To narrow down your query by specific types of content, click the SharePoint tabs, and then select the
checkboxes for the type of content you want. For example, you can select only only PowerPoint slides for
SharePoint.
4. To analyze or further refine your query, click Advanced Query Options., and do one or more of the
following.
To examine the syntax and structure of your query, view the SharePoint Query sections, and the table of
sources that shows filters, queries, and refiners,
5. When you are ready to run your query, click Search. The results are ranked based on relevance, such as how
frequently a search term appears.
NOTE
Once you add queries or content sources to an eDiscovery case, changing the regional settings for the site is not supported.
Add more content sources while creating a query

1. On the Query:New Item page, in the Sources section, click Modify Query Scope.
2. In the dialog box that appears, click All case content,
3. Click Add location for SharePoint content.
4. Specify the person's Web site you want to add.
5. Click OK.
NOTE
If you update a query and rerun it, only the first page of the new results will be refreshed. If you are viewing multiple pages
of query results, and you are not viewing the first page, the page will not be refreshed with the new results.

Add content to a case and place sources on hold in
the eDiscovery Center

Content that is part of an eDiscovery case - such as potential evidence for litigation, audits and investigations -can
be managed in an eDiscovery Set. Each case can have multiple eDiscovery Sets. You can also filter the source
content you include, such as by author or sender, by a date range, or by search keywords.
When a content source is part of a case, you can place it on hold so that a copy is preserved. This includes
SharePoint sites, documents, or pages . In SharePoint Server, you can also hold content on searchable file shares.
When items are placed on hold, people can continue to work on them without disruption. Content that is being
managed by policies will not expire when it is placed on hold.
After you have defined content sources, you can run queries and export the content to provide to authorities. The
exported content includes a load file based on the Electronic Discovery Reference Model standard.
NOTE
Once you add content sources or queries to an eDiscovery case, changing the regional settings for the site is not supported.
Create an eDiscovery Set to manage content sources

This procedure creates an eDiscovery Set and adds content sources to it. To also place content on hold, follow the
next procedure, Place content sources on hold.
NOTE
To include sources in a case, they must first be indexed by the SharePoint search service. For more information, see the
person that manages the sites and mailboxes you want to include.
1. If your case is not already open, in an eDiscovery Center, click Cases, and then click the case that you want
to add content sources to.
2. Under eDiscovery Sets, click New Item.
3. Type a name for the eDiscovery Set, such as Executive Correspondence.
4. Next to Sources, click Add & Manage Sources.
5. Under Locations, type the URL for the content you want to use as the source. In SharePoint Server, you
can also type a file share address. Any content you include must be indexed by search.
6. Click Save.
7. In the box under Filter, type any keywords you want to use to narrow down the source.
10. Click the Apply Filter button.
11. To verify that you've selected the right content, click Preview Results.
12. Click Save.
NOTE
You can add and remove content sources after you create an eDiscovery Set. To see a list of content sources in an
eDiscovery Set, click Sources.
Place content sources on hold

NOTE
To include sources in a case, they must first be indexed by the SharePoint search service. For more information, see the
person that manages the sites and mailboxes you want to include.
want to place on hold.
2. Under eDiscovery Sets, click New Item.
5. Under Locations, type the URL for the content you want to use as the source. In SharePoint Server, you
can also type a file share address. Any content you include must be indexed by search.
6. Click Save.
9. To limit results to the author of a document or list item, or to a specific sender of e-mail messages, types the
11. Click Enable In-Place hold.
13. Click Save.
NOTE
After you've placed content on hold, if you want to see a list of content sources for a case, click Sources.
Remove a hold from content sources

want to remove a hold.
2. Click eDiscovery Sets.
3. Under Sources, click the name of the source whose hold you want to remove.
4. Click Disable In-Place Hold.
Remove an eDiscovery Set from a case

want to remove an eDiscovery Set.
2. Click to the left of the eDiscovery Set to select it, so that a check mark appears besides its name.
3. Click the three dots … to display the Open Menu.
4. Click Delete Item.
5. When prompted whether to send the item to the Recycle Bin, click OK.
Learn more about holds

These types of content can be placed on hold as part of a case:
Documents
Lists (including blogs and wiki content)
Pages (including pages that host blogs and wikis)
In SharePoint Server, content on file shares that have been crawled by search.
When you place a hold on the content sources in an eDiscovery set, the hold status for each source is
displayed in the In-Place Hold Status column in the list of content sources. The following list describes
each hold status value.
On hold Indicates that the entire content source is on hold. This value is displayed when the box
under Filter is left blank, and In-Place Hold is enabled for the sources in the eDiscovery set. The
result is that all content in the specified source is placed on hold.
On hold with filter Indicates that items that meet the search criteria that's specified in the box
under Filter in the content source is on hold, and In-Place Hold is enabled for the sources in the
eDiscovery set. The result is that content that meets the search criteria in the specified source is
placed on hold.
Not on hold Indicates that the content source is not on hold.
Cannot hold Indicates that the content source can't be put on hold.
Failed Indicates that the request to place the content source on hold failed.
Processing Indicates that the hold request is in progress. This status is displayed after you click
Enable In-Place Hold and then click Save in an eDiscovery set. After a few moments, refresh the
eDiscovery set page and this value is replaced with one of the previous values.
When a hold is placed on a SharePoint site, you can't remove an app from the site.
When a hold is placed on a SharePoint site, a preservation hold library is created, if one doesn't already
exist. Users can still work with the content, but a copy of the content as it was at the time that you initiated
the hold is preserved as users change the content. Regular users with typical permissions can't see the
preservation hold library. Only users with Web application- level permissions, or users who have been
granted specific permissions, can view the preservation hold library.
If a user attempts to change or delete content in a site that is on hold, SharePoint first checks whether the
content was changed since the hold was applied. If this is the first modification since the hold was applied,
SharePoint copies the content to the preservation hold library, and then allows the user to change or delete
the original content.
A user will receive an error if they try to delete a library, list, or site collection that's on hold. Users will also
receive an error if they try to delete a folder that contains a file that's on hold. If users want to delete a
folder that contains one or more files that are on hold, they have to delete those files before they can delete
the folder.
To store all versions of content in a site, you have to enable document versioning for the document libraries
in the site. If a document is deleted from a site that's on hold and document versioning is enabled, all
versions of the deleted document will be preserved. If document versioning isn't enabled, the version of
content that is current at the time that the hold was applied is the only version that is preserved. If the
content is changed multiple times after the hold is applied, intermediate versions of the content are not
preserved, so that storage space is used more efficiently. Most content in a site typically does not change,
and content that is not changed is not copied to the preservation hold library.
If you remove a hold from a site, all files in the preservation hold library will be deleted (moved to the first-
stage Recycle Bin) within 7 seven days of removing the hold. That's because a timer job for the
preservation hold library runs once every 7 days and identifies items to delete. Files will be deleted the next
time the timer job runs after the hold is removed from the site.


Electronic discovery, or eDiscovery, is the process of identifying and delivering electronic information that can be
used as evidence. The eDiscovery Center, is a type of site collection that serves as a portal for managing
eDiscovery cases. From this central location you can discover content in the SharePoint farm, in Exchange Servers
2013, 2016, and 2019, on file shares, and in other SharePoint farms. You can apply a hold to SharePoint and
Exchange content that you discover. The hold ensures that a copy of the content is preserved, while still allowing
users to work with their content. When you have identified the specific items that you will have to deliver, you can
export them in an industry-standard format.
Managing an eDiscovery case

When you receive a new request for eDiscovery, you create an eDiscovery case in the eDiscovery Center. An
eDiscovery case is a collaboration site that you can use to organize information related to the eDiscovery request.
From within an eDiscovery case, you can search for content, apply a hold to content, export content, and view the
status of holds and exports that are associated with the case.
The two primary components of an eDiscovery case are eDiscovery sets and queries. Use an eDiscovery set to
find content and apply a hold. Use a query to find content and export it.
eDiscovery process flow
To find and preserve content, create an eDiscovery set. Each eDiscovery set contains the following:
Sources, which are locations to be searched. Exchange mailboxes, SharePoint sites, and file shares can all be
sources.
A filter, which defines what you are searching for. A filter can include search terms, a date range, and an
author's name.
An option to apply an in-place hold to the sources that contain content that matches the filter.
To find and export content, create a query. Each query contains the following:
Query filters, which define what you are searching for. Query filters resemble a filter in an eDiscovery set,
and can include search terms, a date range, and an author's name. However, query filters in a query can
also use stemming.
Sources to be searched. Exchange mailboxes, SharePoint sites, file shares, and eDiscovery sets can all be
sources in a query.
When you run a query, you can see statistics about the items that were found, you can preview the results, and
you can filter the results by message type (for Exchange results) or by file type (for SharePoint results). When you
are finished, you can export the results of the query.
The content that you export by using a query is formatted according to the Electronic Data Reference Model
(EDRM ) specification so that it can be imported into a review tool. An export can include the following:
Documents: Documents are exported from file shares. Documents and their versions can be exported from
SharePoint Server.
Lists: If a list item is included in the query results, the whole list is exported as a comma-separated values
(.csv) file.
Pages: SharePoint pages, such as wiki pages or blogs, are exported as MIME HTML (.mht) files.
Exchange objects: Items in an Exchange Server mailbox, such as tasks, calendar entries, contacts, email
messages and attachments are exported as a .pst file. If Skype for Business conversations are archived in
Exchange, those can be discovered and exported, too.
Crawl log errors.
An XML manifest that provides an overview of the exported information.
How eDiscovery works in SharePoint products

The Search service application is a key component of the search system in SharePoint Server. You can associate
an eDiscovery Center with a Search service application. Any content that's indexed by the Search service
application can be discovered from the eDiscovery Center. If you configure the Search service application to crawl
file shares, you can use the eDiscovery Center to discover content on the file shares. If you configure the Search
service application to crawl other websites - for example, a team site that was created by using SharePoint Server
2010 - you can use the eDiscovery Center to discover content on the websites. For SharePoint Server farms, you
can also put the content on hold. If you add Exchange Server to the Search service application as a result source,
you can discover content within Exchange mailboxes from the eDiscovery Center and put the mailboxes on hold. If
you archive content from Skype for Business in Exchange, you can also discover Skype for Business content.
If your environment includes two isolated Search service applications - for example, SharePoint Online and
SharePoint Server on-premises - you need to have two eDiscovery Centers to discover content across the farms.
A separate eDiscovery Center for each isolated Search service application.
As the Search system crawls content, it creates a search index. The search index stores data that's used to provide
the results for search queries. The search index also stores information about the permissions that are required to
access each piece of content. When a user performs a search, the search system uses the search index to identify
the appropriate search results. Before displaying the results, the Search service application performs security
trimming, by which the system compares the user's permissions to the permissions that are required to access
content that search results link to, and then "trims" the results to show only those results that the user has
permissions to view.
In-place holds
SharePoint Server 2013 introduced the concept of an in-place hold. When you apply an in-place hold to a site,
content in the site remains in its original location. Users can still work with the content, but a copy of the content
as it was at the time that you initiated the hold is preserved. Additionally, if an in-place hold is applied to a site, any
new content that's created or added to the site after it was put on hold will be discoverable, and will be preserved
if it's deleted. Also, users don't have to know that their content is on hold.
IMPORTANT
If SharePoint Server runs on a server that uses Alternate Access Mapping (AAM), host-named site collections, or SSL
termination format, then users will not be able to edit web pages in a site that has an in-place hold applied. To allow users to
edit pages in sites that are on hold, you need to disable loopback checking as described in Method 2 of KB article 896861.
An in-place hold is applied at the level of a site. When a hold is placed on a SharePoint site, a preservation hold
library is created, if one doesn't already exist. The preservation hold library is only visible to site collection
administrators so most users can't view it. The search crawler also has special permissions to crawl content in the
preservation hold library.
NOTE
There is one case in which a user can view the preservation hold library. Users who are granted permissions at the web
application level can view all content in all site collections within the web application.
If a user attempts to modify or delete content in a site that's on hold, SharePoint first checks whether the content
has been modified since the hold was applied. If this is the first modification since the hold was applied,
SharePoint copies the content to the preservation hold library, and then allows the user to modify or delete the
original content. Note that any content in the site can be copied to the preservation hold library, even if the
content doesn't match the filter of the eDiscovery set that initiated the hold.
A user receives an error if they try to delete a library, list, or site collection that's on hold. Users also receive an
error if they try to delete a folder that contains a file that's on hold. If users want to delete a folder that contains
one or more files that are on hold, they have to delete those files before they can delete the folder.
The Hold Processing and Reporting timer job generates reports about items on hold and removed item from hold
libraries that are pending release. The timer job runs daily and processes eDiscovery in SharePoint Server.
Consider the following when planning for in-place holds:
To store all versions of content in a site, you have to enable document versioning for the document libraries
in the site. For more information about versioning, see Enable and configure versioning for a list or library.
If a document is deleted from a site that's on hold and document versioning is enabled, all versions of the
deleted document will be preserved.
As previously mentioned, if a site is put on hold, any new content that's created or added to the site after it
was put on hold will be preserved if it's deleted.
If document versioning isn't enabled and an item is placed on hold multiple times, SharePoint preserves
the version that's current at the time each hold is placed. For example, if version 27 of an item is the most
recent when the site is placed on hold the first time, and version 51 is the most recent when the site is
placed on hold the second time, versions 27 and 51 are preserved.
Storage space is used efficiently when an in-place hold is implemented. Most content in a site does not
change, and content that's not changed is not copied to the preservation hold library.
Integration with Exchange

You can manage the discovery process for Exchange Servers 2013, 2016, and 2019 from a SharePoint eDiscovery
Center. You can do the following:
Add Exchange mailboxes as sources to either an eDiscovery set or a query.
Preview content that's discovered in an Exchange mailbox.
Apply a hold to an Exchange mailbox.
Export content that's discovered in an Exchange mailbox.
To discover content in Exchange mailboxes, you must first configure a trust relationship between SharePoint and
Exchange. You must also grant specific Exchange permissions to the users of the eDiscovery Center. For more
information about these tasks, see Configure eDiscovery in SharePoint Server.
Plan for eDiscovery in SharePoint Server

There are several factors to consider before you implement eDiscovery. First, determine how many eDiscovery
Centers you need and where to put the eDiscovery Centers. Then identify the locations that contain content that
can be discovered. Finally, consider the permissions that you have to grant to eDiscovery users. The decisions that
you make when you plan for eDiscovery might affect other systems that your organization uses, such as Exchange
Servers 2019, 2016, or 2013. Accordingly, you might have to coordinate with the people who manage those
systems when you create and implement your plan.
To implement your plan, follow the instructions in the article Configure eDiscovery in SharePoint Server. The
decisions that you make during planning determine which tasks to do.
Before you read this article, you should understand the concepts that are presented in the article eDiscovery and
in-place holds in SharePoint Server.
Decide how many eDiscovery Centers

The following factors affect the number of eDiscovery Centers that you have to create:
How many Search service applications you have.
What content each Search service application crawls.
If you have only one Search service application, or if there is a single Search service application that crawls all of
the sites that contain discoverable content, you can have a single eDiscovery Center. If different Search service
applications crawl subsets of the discoverable content, you have to have multiple eDiscovery Centers. Associate
eDiscovery Centers with Search service applications so that all discoverable content is crawled by a Search service
application that is associated with an eDiscovery Center.
The following figure presents three examples of farm topologies and illustrates how many eDiscovery Centers are
required for each example.
How many Search service applications you have influences how many eDiscovery Centers you have.
A Search service application in an on-premises SharePoint farm cannot crawl content in SharePoint Online. If you
have discoverable content in SharePoint Online, you will also have to create an eDiscovery Center in SharePoint
Online.
Record how many eDiscovery Centers you will have.
An eDiscovery Center must be in a web application that supports claims authentication. For each eDiscovery
Center, record the farm that will contain the eDiscovery Center and the Search service application with which to
associate the eDiscovery Center.
Identify discoverable content

After you have determined how many eDiscovery Centers you will have and where the eDiscovery Centers will be,
identify the content that each Search service application will crawl.
To be discoverable, content on file shares, in SharePoint sites, or on other web sites must be crawled by a Search
service application that is associated with an eDiscovery Center.
NOTE
A file on a file share whose file name is longer than 259 characters cannot be discovered.
List all the locations that contain content that must be discoverable. If you have more than one eDiscovery Center,
indicate which Search service application will crawl each content source.
If you want to manage the discovery of Exchange Servers 2019, 2016, or 2013 content from a SharePoint Server
eDiscovery Center, you must configure a Search service application to include Exchange Server 2019, 2016, or
2013 as a result source. If you want to manage the discovery of Skype for Business Server 2015 content from a
SharePoint Server eDiscovery Center, you must configure Skype for Business Server 2015 to archive content to
either Exchange Server 2019, 2016 or 2013.
NOTE
SharePoint Server 2019 with Exchange 2019, enables Outlook on the web users to link to and share documents that are
stored in OneDrive for Business instead of attaching files to messages. Users in SharePOint Server 2019 can collaborate on
files the same way as in Office 365. You'll need to run Office Online Server in your environment to do this. For more
information, see the Document collaboration section in What's new in Exchange Server.
NOTE
To manage discovery of Exchange content through SharePoint Server 2013, you must be using Exchange Server 2013. To
manage discovery of Lync content through SharePoint, you must be using both Lync Server 2013 and Exchange Server 2013.
Determine how to manage permissions

People who perform eDiscovery must be able to view all content that is potentially discoverable. We recommend
that you create a security group for eDiscovery users, and add the appropriate users to the security group. Then
you can grant permissions to the security group, instead of to individual users. Choose a name for the security
group, and record this name and also record which users will be members of the security group.
Within SharePoint Server, eDiscovery users must be able to view all content. This includes content that is in the
preservation hold library. (For more information about the preservation hold library, see eDiscovery and in-place
holds in SharePoint Server. There are two ways to achieve this:
1. Grant eDiscovery users access to all content in a web application by using web application user policy.
2. Add eDiscovery users as site collection administrators for every site collection that contains discoverable
content.
We recommend that you grant permissions at the web application level, if that is possible in your environment.
NOTE
Because SharePoint Online is a hosted service, administrators cannot access web applications directly. Therefore, in SharePoint
Online you must explicitly add eDiscovery users as site collection administrators on each site collection that contains
discoverable content.
Decide whether you will grant permissions by web application or by site collection. If you will grant permissions at
the web application level, identify which web applications you will have to grant access to eDiscovery users. (It is
likely that this will be all web applications.) If you will grant permissions at the site collection level, identify which
site collections eDiscovery users will need access to and record your decisions.
Generally, when you export content for eDiscovery, you will also want to export a list of things that could not be
indexed. The search crawl log contains this information. Therefore, eDiscovery users also have to have access to the
search crawl log.
See also
Concepts
Search and place a hold on public folders using In-Place eDicovery

This article identifies the steps that are required to configure eDiscovery in SharePoint Server. When you
complete the steps that are listed in this article, users will be able to create and work with eDiscovery cases.
Before you configure eDiscovery, you should understand the concepts that are presented in the article eDiscovery
and in-place holds in SharePoint Server.
You must perform the following tasks to configure eDiscovery:
Configure communication between SharePoint Server and Exchange Server 2016.
Configure Search to crawl all discoverable content.
Grant permissions.
Create an eDiscovery Center.
Configure communication between SharePoint Server and Exchange

If you will use a SharePoint eDiscovery Center to discover content in Exchange Server, you must configure
SharePoint Server and Exchange Server to interact.
IMPORTANT
To discover content in Exchange Server from a SharePoint eDiscovery Center, you must be running Exchange Server
versions 2019, 2016, or 2013.
Perform the following steps:

1. Ensure that the Exchange Web Service managed API is installed on every front-end server that is running
SharePoint Server.
2. Configure a trust relationship between SharePoint Server and Exchange Server. For information about the
trust relationship, see Plan for server-to-server authentication in SharePoint Server.
3. If you want content from Skype for Business Server to be discoverable, configure the server to archive to
Exchange Server 2016. For information about how to configure Skype for Business Server 2015 archiving,
see Configure Skype for Business Server 2015 to use Exchange Server archiving.
4. If you want SharePoint Server 2019 users to link to and share documents that are stored in OneDrive for
Business instead of attaching file to Outlook messages, see the Document collaboration section in What's
new in Exchange Server.
5. Perform the eDiscovery configuration steps for Exchange. For information about how to configure
Exchange Server 2013 for eDiscovery, see Integration with SharePoint.
Configure Search to crawl all discoverable content

Content is only discoverable if it is crawled and indexed by the Search service application that is associated with
the web application that the eDiscovery Center is in. You should have identified this Search service application
when you planned for eDiscovery. To configure the Search service application to crawl the appropriate content,
follow these steps:
1. If content in Exchange Server 2013 must be discoverable, add Exchange Server 2013 as a result source.
For information about how to configure a result source, see Configure result sources for search in
SharePoint Server.
2. Ensure that all websites that contain discoverable content are being crawled. For information about how to
configure a location to be crawled, see Add, edit, or delete a content source in SharePoint Server.
3. Ensure that all file shares that contain discoverable content are being crawled.
Grant permissions
We recommend that you create a security group to contain all users of the eDiscovery Center. After you create
the security group, grant the security group permissions to access all discoverable content.
1. If you will grant permissions at the web application level, create a user policy that gives the security group
full read permissions for each web application that contains discoverable content. For information about
how to create a policy for a web application, see Manage permission policies for a web application in
SharePoint Server.
NOTE
When you change permissions at the web application level, Search re-crawls all of the content in the web
application.
2. If you will grant permissions at the site collection level, make the security group a site collection
administrator for each site collection that contains discoverable content. For information about how to add
a site collection administrator, see Add, change, or remove a site collection administrator.
IMPORTANT
A site collection administrator must add the security group as an additional site collection administrator by using
the Site Settings menu. You cannot use Central Administration to make a security group a site collection
administrator
3. Ensure that the security group has permissions to access all file shares and other websites that contain
discoverable content.
4. If you will use a SharePoint eDiscovery Center to discover content in Exchange Server, grant the security
group permissions to access Exchange Server mailboxes. For information about how to grant permissions
in Exchange, see Integration with SharePoint.
5. Grant the security group permissions to view the crawl log. For information about how to grant
permissions to access the crawl log, see Set-SPEnterpriseSearchCrawlLogReadPermission.
Create an eDiscovery center

An eDiscovery Center is a site collection from which users can create and manage eDiscovery cases. To create an
eDiscovery Center, follow the procedure in the article Create a site collection in SharePoint Server, and choose
the eDiscovery Center site collection type from the Enterprise tab. Be aware that an eDiscovery Center must be
in a web application that supports claims authentication.
See also
Concepts
Search and place a hold on public folders using In-Place eDicovery
Assign eDiscovery permissions in Exchange Server

Electronic Discovery, or eDiscovery, is the discovery of content in electronic format for litigation or investigation.
This typically requires identifying content spread across laptops, email servers, file servers, and many other
sources.
The eDiscovery Center is a SharePoint site collection used to perform electronic discovery actions. In an
eDiscovery Center, you can create cases, which are SharePoint sites that allow you to identify, hold, search, and
export content from SharePoint sites, and searchable file shares.
NOTE
Once you add content sources or queries to an eDiscovery case, changing the regional settings for the site is not supported.
> In order for content to be discovered, it must be crawled by search. For more information about the default file types that
are crawled, see the article Default crawled file name extensions and parsed file types in SharePoint Server 2013.
Planning and creating cases

If you anticipate managing multiple cases in your eDiscovery Center, consider whether you want to define
consistent processes for people in your organization to follow.
Naming conventions for cases - Could matter if you anticipate a larger number of cases, or different types or
classifications of cases, for different departments,
Additional data to describe cases
Defining and communicating permissions for managing cases.
Guidelines on creating queries
Standard procedures for communicating when content is placed on hold
Standard procedure for retaining and closing cases
Example lifecycle of an eDiscovery case
Create the site to manage a case
Add sources
Place sources on hold
Create queries
Export case content
Close case
Create a case
1. In an eDiscovery Center, click Create new case.
2. Type a title and description for your case.
3. In the Web Site Address box, type the last part of the URL you want for the case, such as
ContosovsFabrikam.
4. Under Select a template, make sure that eDiscovery Case is selected.
5. Under User Permissions, select whether or not to keep the same permissions as the parent site or use
unique permissions. If specific people will need access to this case, but not to other cases, you should choose
Use unique permissions.
Add sources and place them on hold

1. In the eDiscovery Center, open the case that you want to add a source to.
2. Click eDiscovery Sets.
5. Under Locations, type the URL or file share address for the content you want to use as the source. Any
content you include must be indexed by search.
6. Click Save.
11. Click Enable In-Place hold.
13. Click Save.
For more information, see Add content to a case and place sources on hold in the eDiscovery Center.
Run queries and export content

Once you have defined your sources, and placed them on hold if necessary, you can run queries to narrow down
and extract exactly the content you need for a particular case. SharePoint has some tools that can help you refine
your queries.
You export content from a case when you are ready to deliver it to an authority or want to work on it with another
legal program. The content is exported in a format that is compatible with the Electronic Discovery Reference
Model standard.
Close cases
When you close a case, in-place holds will be released for all of its sources, and you will no longer be able to put
sources on hold for this case.
1. Click Settings , and then click Case Closure.
2. Click Close this case.
Default crawled file name extensions and parsed file types in SharePoint Server
Overview of crawled and managed properties in SharePoint Server
Records management in SharePoint Server

A record is a document or other electronic or physical entity in an organization that serves as evidence of an
activity or transaction performed by the organization and that requires retention for some time period. Records
management is the process by which an organization:
Determines what kinds of information should be considered records.
Determines how active documents that will become records should be handled while they are being used,
and determines how they should be collected after they are declared to be records.
Determines in what manner and for how long each record type should be retained to meet legal, business,
or regulatory requirements.
Researches and implements technological solutions and business processes to help ensure that the
organization complies with its records management obligations in a cost-effective and non-intrusive way.
Performs records-related tasks such as disposing of expired records or locating and protecting records that
are related to external events such as lawsuits.
Determining which documents and other physical or electronic items in your organization are records is the
responsibility of corporate compliance officers, records managers, and lawyers. By carefully categorizing all
enterprise content in your organization, these people can help you ensure that documents are retained for the
appropriate period of time. A well-designed records management system helps protect an organization legally,
helps the organization demonstrate compliance with regulatory obligations, and increases organizational
efficiency by promoting the disposition of out-of-date items that are not records.
A records management system includes the following elements:
A content analysis that describes and categorizes content in the enterprise that can become records, that
provides source locations, and that describes how the content will move to the records management
application.
A file plan that indicates, for each kind of record in the enterprise, where they should be retained as
records, the policies that apply to them, how long they must be retained, how they should be disposed of,
and who is responsible for managing them.
A compliance requirements document that defines the rules that the organization's IT systems must
follow to ensure compliance and the methods that are used to ensure the participation of enterprise team
members.
A method for collecting records that are no longer active from all record sources, such as
collaboration servers, file servers, and email systems.
A method for auditing records while they are active.
A method for capturing records' metadata and audit histories and for maintaining them.
A process for holding records (suspending their disposition) when events such as litigations occur.
A system for monitoring and reporting on the handling of records to ensure that employees are
filing, accessing, and managing them according to defined policies and processes.
SharePoint Server includes features that can help organizations implement integrated records management
systems and processes.
Overview of records management planning

This topic describes the planning steps that you should take to help make sure that the records management
system that you implement based on SharePoint Server will achieve your organization's records management
goals. The following is a preview of the records management planning process:
1. Identify records management roles Successful records management requires specialized roles, such as the
following:
Records managers and compliance officers to categorize the records in the organization and to run the
records management process.
IT personnel to implement the systems that efficiently support records management.
Content managers to find where organizational information is kept and to make sure that that their teams
follow records management practices.
2. Analyze organizational content Before creating a file plan, records managers and content managers
survey document usage in the organization to determine which documents and other items can become
records.
3. Develop a file plan After you have analyzed your organizational content and determined retention
schedules, fill in the rest of the file plan. File plans differ from organization to organization, but generally
they describe the kinds of items the enterprise acknowledges to be records, indicate where they are stored,
describe their retention periods, and provide other information, such as who is responsible for managing
them and which broader category of records they belong to.
4. Develop retention schedules For each record type, determine when it is no longer active (being used),
how long it should be retained after that, and how it should ultimately be disposed of.
5. Evaluate and improve document management practices Make sure that required policies are being
applied in document repositories. For example, make sure that that content is being appropriately audited
so that suitable audits are retained together with records.
6. Design the records management solution Determine whether to create a records archive, to manage
records in place, or to use a combination of the two approaches. Based on your file plan, design the record
archive, or determine how to use existing sites to contain records. Define content types, libraries, policies,
and, when it is required, metadata that determines the location to route a document to.
7. Plan how content becomes records If you are using SharePoint Server for both active document
management and records management, you can create custom workflows to move documents to a records
archive. If you are using either SharePoint Server or an external document management system, you can
plan and develop interfaces that move content from those systems to the records archive, or that declare a
document to be a record but do not move the document. You also create a training plan to teach users how
to create and work with records.
8. Plan email integration Determine whether you will manage email records within SharePoint Server , or
whether you will manage email records within the email application itself.
9. Plan compliance for social content If your organization uses social media such as blogs, wikis, or My
Sites, determine how this content will become records.
10. Plan compliance reporting and documentation To verify that your organization is performing its
required records management practices, and to communicate these practices, you should document your
records management plans and processes. If your enterprise becomes engaged in records-related litigation,
you might have to produce these records management guidelines, implementation plans, and metrics on
effectiveness.
Create a file plan to manage records in SharePoint
Server

The file plan is the primary records management planning document in SharePoint Server. Although file plans can
differ across organizations, they typically:
Describe the kinds of items the organization acknowledges to be records.
Describe what broader category of records the items belong to.
Indicate where records are stored.
Describe retention periods for records.
Delineate who is responsible for managing the various kinds of records.
This article describes the contents of a file plan and summarizes how to create a file plan for your organization. The
article also directs you to a worksheet in which you can record the file plan.
Identify kinds of records

Determining which active documents in your organization might be declarable as records requires the
collaboration of records managers, lawyers, compliance officers, and content managers. Note that, even if your
enterprise is not in a highly regulated industry, there are general laws that might obligate your enterprise to keep
records. Along with general business laws, you must evaluate legal requirements that are specific to your
enterprise.
It is beyond the scope of this article to provide more than general information about how to determine what is a
record in your organization. Most likely, your enterprise is already doing some form of records management and
has filled most of the records management roles that you need, and you might already have a taxonomy of records.
Generally, to determine what are records in your organization:
1. Understand your enterprise's legal obligations and business needs.
2. In a collaborative effort across the divisions of your organization, analyze how active documents are used.
3. Develop a list of the kinds of documents that should become records. For example, you might determine
that the following should be retained as records:
Contracts to rent corporate space.
Documents related to employees' benefits.
Documents related to product research and development.
4. Categorize the records. Records in the same category often have the same retention periods and might require
similar treatment in other ways.
Record the information that you collected. Record the kind of record, the category that records of this kind belong
to, and a brief description of the kind of record.
The following is a sample worksheet:
KIND OF RECORD RECORD CATEGORY DESCRIPTION
Benefit plans, insurance plans, pension Employee Benefit Descriptions Descriptions of all employee benefit
plans plans.
Payroll timesheets, supplementary Payroll Records Summaries of hours worked, overtime,

payroll information and salary paid.
Vendor invoices Invoices Records of goods or services purchased

from vendors.
Product surveys, questionnaires, Training Materials Provides internal or external training.

training manuals, training videos
Shipping forms, shipping reports Shipping Records Documents the shipment of materials.
Press releases, newspaper articles Press Releases Public relations information about
products and services.
Emergency contact sheets, medical plan Personnel Records Records of individuals' employment
enrollment forms, resumes, benefits histories and related personnel actions.
status reports
Complete the file plan

After you determine which documents should be retained as records and after you create a set of record categories,
complete your file plan by providing additional information about each kind of record. Indicate the following:
How long each kind of record should be retained.
How records should be disposed of when the retention period expires.
Who is the primary records manager for records of this kind.
What kind of media are records of this kind stored in.
The following is a completed sample file plan:
RECORD
RECORDS DESCRIPTION MEDIA CATEGORY RETENTION DISPOSITION CONTACT
401k plans Description of Web pages Employee X years None Kathi Flood
employee Benefit Plans
benefit plan.
Insurance Description of Print Employee X years None Reshma Patel

plans employee Benefit Plans
insurance
plan.
Pension plans Description of Print Employee X years None Reshma Patel

employee Benefit Plans
pension plan.
RECORD
Payroll Summaries of Electronic Payroll X years Destroy Reshma Patel

timesheets hours worked, documents Records
overtime, and
salaries paid.
Supplementar Summaries of Electronic Payroll X years Destroy Reshma Patel

y payroll sick time, documents Records
information vacation time,
and other
non-salary
payroll items.
Vendor Records of Print Invoices X years Destroy Eric Lang

invoices goods or
services
purchased
from vendors.
Product Customer Web pages Survey X years Archive Molly

surveys satisfaction Materials Dempsey
survey.
Questionnaire Questionnaire Print Survey X years Archive Molly

s to determine Materials Dempsey
customer
demographics.
Training Hard-copy Print Training X years Destroy Molly

manuals training Materials Dempsey
content.
Training Video training Video Training X years Destroy Molly

videos content. Materials Dempsey
Shipping Configuration Print Shipping X years Destroy Eric Lang

forms of materials Materials
shipments
Shipping Documentatio Electronic Shipping X years Destroy Eric Lang

reports n of the spreadsheets Materials
shipment of
materials.
Press releases Releases Electronic Public X years Archive Molly

about documents Relations Dempsey
products and Information
services.
Newspaper News about Print Public X years Archive Molly

articles products and Relations Dempsey
services. Information
Emergency Employee Electronic Personnel X years Destroy Reshma Patel

contact sheets information. documents Records
RECORD
Medical plan Employees' Electronic Personnel X years Destroy Reshma Patel

enrollment sign-up forms documents Records
forms for health
plans.
Resumes Resumes Mixed Personnel X years Destroy Reshma Patel

received. Records
NOTE
The example earlier in this section is a sample. It is not a recommendation of any particular file plan settings. To reinforce that
this is an example and not a recommendation of any records management policy, no retention periods are supplied.
Plan ways to convert active documents to records in
SharePoint Server

After you develop a file plan and design your records management solution in SharePoint Server, plan how active
documents in your organization - electronic and hard copy - will become records. This article reviews techniques
that you can use to declare active documents to be records and suggests one way to plan how items in your file
plan will become records.
Techniques for converting active documents to records in SharePoint

Server
You can use the following techniques convert active documents to records:
Manually declaring a document to be a record.
Defining a policy that declares a document to be a record or sends a document to a Records Center site at a
specified time.
Creating a workflow that sends a document to a Records Center site.
Using a custom solution that is based on the SharePoint object model.
Creating records manually
If in-place records management is enabled for a document library, users can explicitly declare a document in the
library to be a record by editing the document's compliance details. When the site collection administrator enables
in-place records management, the site collection administrator specifies who should be able to declare and un-
declare records, and whether users should be able to edit or delete documents after they become records.
If a connection to a Records Center site was created, users can manually send documents to the Records Center
site by using the Send to command. When a farm administrator configures a connection to the Records Center
site, this command becomes available on all active documents. Depending on how the connection is configured,
documents can be either copied to the Records Center site, moved to the Records Center site, or moved to the
Records Center site with a link to the document maintained.
Although manually sending records to the Records Center site is not a practical large-scale solution, you can use it
to supplement other methods of creating records.
Defining a policy
A retention policy specifies actions to take on documents at certain points in time. Policy actions occur
automatically. Users do not have to start the action.
Two policy actions relate specifically to managing records: transferring a document to another location, and
declaring a document to be a record. If a connection to a Records Center site exists, you can create a policy that
sends documents to a Records Center site. The policy also specifies whether to copy the document to the Records
Center site, move it, or move it and leave a link in the document library. If in-place records management is enabled
for the site, you can create a policy that declares a document to be a record. You can also use the SharePoint object
model to create a custom action.
A retention policy can have multiple stages. For example, you could create a retention policy that deletes all earlier
versions of a document one year after the document was last changed, and transfers the document to a Records
Center site five years after the document was last changed.
If in-place records management is enabled for a site, the site can contain both active documents and records. In this
case, you can specify different retention policies for active documents and records. For example, you could create a
policy that declares an active document to be a record two years after the document was created, and create a
second policy that deletes a record seven years after it was declared to be a record.
Creating a workflow
When you use SharePoint Designer to create a workflow, you can add an action to send an item to a repository. By
using this action, you can create workflows that send documents to a Records Center site. You can also include
other actions in the workflow. For example, you could create a workflow that sends an email message to a
document's author requesting approval, and then sends the document to a Records Center site. You could combine
policies and workflows by creating a retention policy that runs the new workflow one year after a document is
created.
You can also use the SharePoint object model to create a custom workflow that copies files to the Records Center
site. A workflow that sends files to the Records Center site can be integrated into your document management
system as part of a workflow that guides a document through its life cycle. For document types that have a
predictable life cycle, such as expense reports, you could implement a workflow that guides the document through
its various stages and, as a final step, sends a copy of the document to the Records Center site. The workflow could
be triggered by creating a new document.
Using a custom solution
You can develop custom solutions that use objects in the
Microsoft.Office.RecordsManagement.OfficialFileWSProxy namespace to send content from other data
sources to the Records Center site. For more information about how to implement custom solutions using the
SharePoint Server object model, see the SharePoint Server Software Development Kit
(https://go.microsoft.com/fwlink/p/?LinkId=259788).
Completing your plan

After you develop the file plan and review the methods for moving content into the Records Center site, complete
your file plan by determining how to send each kind of record to the Records Center site. The things to consider
Is compliance enforced or voluntary?
Can you depend on the cooperation of users in your organization to comply with records management
processes? In general, avoid manual processes. However, where they are needed, create suitable training
and monitoring to make sure that team compliance.
Will content be stored on SharePoint Server document management servers?
Are you maintaining physical content? Managing active physical content, such as hard copy or CD -ROM,
and sending it to a records vault for retention (together with tracking the record in a Records Center site)
requires unique planning not described in this topic. For example, if no electronic version of a paper
document exists, you might have to track the item by using a list that has associated policies and workflows.
The following table shows how some records in a sample file plan will move to a Records Center site:
DOCUMENTS DESCRIPTION MEDIA SOURCE LOCATION BECOMES A RECORD...
Benefit plan Description of Web pages SharePoint Server Using a custom

employee benefit document library workflow associated
plan. with expiration policy
DOCUMENTS DESCRIPTION MEDIA SOURCE LOCATION BECOMES A RECORD...
Insurance plan Description of Print Physical document By sending it to a

employee insurance associated with list physical vault and
plan. item in SharePoint creating a list item in
Server the Records Center
site to track (using a
barcode)
Payroll timesheets Summaries of hours Electronic documents Payroll records server Using a custom
worked, overtime, not based on program
and salaries paid. SharePoint Server
Product development Specifications of Electronic documents SharePoint Server Using custom

files products and document library workflow associated
associated with expiration policy
documents. and manually by
using Send to
command
Use a SharePoint Server records archive or manage
records in place

In SharePoint Server you can manage records in an archive, or you can manage records in the same document
repository as active documents. By using the SharePoint Server in-place approach, when you declare that a
document has become a record, the record remains in place, but SharePoint Server now manages it as a record.
For example, a document might get a different retention policy when it is declared to be a record, or users might be
unable to edit it.
A hybrid approach is also possible. For example, you could keep records in place with active documents for two
years, and then move records to a records archive when a project is completed.
As you think about whether to manage records in a separate Records Center site or in the same collaboration site
in which the documents were created, consider the following questions:
Is the governance of the collaboration site appropriate for managing records? Is your industry subject to
regulatory requirements that mandate records be separated from active documents? Should the
administrator of a collaboration site be trusted to manage a site that contains records? You might want to
store records in a site that uses more restricted access than the collaboration site, or in a site that is backed
up on a different schedule.
How long will the collaboration site be in use? If records will have to be kept for longer than the project is
ongoing, selecting an in-place records management strategy means that you will have to maintain the
collaboration site even after it is no longer used.
Will the project members need frequent access to the documents after the documents have become
records? If you use an in-place approach, project members can access documents in the same manner
regardless of whether the documents are active or are records.
Are records managers in your organization responsible for only records, or are they responsible for all
information, regardless of whether it is active or a record? If records managers are responsible only for
official records, having a separate Records Center site might be easier for them.
The following table describes differences between what you can do with records in a record center and with
records that are managed in-place in a collaboration site. The differences are presented from the point of view of
both records managers and employees collaborating on a project team.
Differences between a records archive and in-place records
FACTOR RECORDS ARCHIVE IN-PLACE RECORDS
Managing record retention The content organizer automatically There may be different policies for
puts new records in the correct folder in records and active documents based on
the archive's file plan, based on the current content type or location.
metadata.
Restrict which users can view records Yes. The archive specifies the No. Permissions do not change when a
permissions for the record. document becomes a record. However,
you can restrict which users can edit
and delete records.
Ease of locating records (for records Easier. All records are in one location. Harder. Records are spread across
managers) multiple collaboration sites.
Maintain all document versions as The user must explicitly send each Automatic, assuming versioning is
records version of a document to the archive. turned on.
Ease of locating information (for team Harder, although a link to the Easier.
collaborators) document can be added to the
collaboration site when the document
becomes a record.
Clutter of collaboration site Collaboration site contains only active Collaboration site contains active and
documents. inactive documents (records), although
you can create views to display only
records.
Ability to audit records Yes. Dependent on audit policy of the

collaboration site.
Administrative security A records manager can manage the Collaboration site administrators have
records archive. permission to manage records and
active documents.
The following table describes differences between the two records management approaches that might affect how
you manage IT resources.
Resource differences between a records archive and in-place records
Number of sites to manage More sites. That is,, there is a separate Fewer sites.
archive in addition to collaboration sites.
Scalability Relieves database size pressure on Maximum site collection size reached
collaboration sites. sooner.
Ease of administration Separate site or farm for records. No additional site provisioning work
beyond what is already needed for the
sites that have active documents.
Storage Can store records on different storage Active documents and records stored
medium. together.
See also
Other Resources
Introduction to Records Management and Compliance
Document management in SharePoint Server

This article contains a high-level description of the various elements of a document management solution that is
based on SharePoint Server.
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 2013 includes features that implement all these aspects of document management.
SharePoint Server includes the same features and also adds the following:
What policies to apply to documents so that document-related actions are audited, documents are retained
or disposed of appropriately, and content that is important to the organization is protected.
How to handle documents as corporate records, which must be retained according to legal requirements
and corporate guidelines.
To make sure 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 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
that they work on and how they use them. .
3. Plan the organization of documents You can organize documents in site collections, sites, and libraries.
SharePoint Server 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 additionally organize content into folders and subfolders.
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.
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.
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 Server includes workflows for common team tasks such as reviewing and approving
documents. SharePoint Server also supports creating and installing custom workflows.
7. Plan content governance You can plan the appropriate degree of control that is 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.
8. Plan policies For each content type, plan information management policies to make sure that documents
are audited, retained, and otherwise handled according to your organization's institutional and legal
requirements. SharePoint Server includes policies that implement auditing, document retention, and bar
codes (to make sure that printed content can be correlated with corresponding electronic versions).
NOTE
Policies are not available in SharePoint Foundation 2013.
Identify users and analyze document usage in
SharePoint Server

The first step to plan your document management solution is to identify users and analyze how documents are
used. This article contains guidance to identify users and analyze document usage for your solution that is based
on SharePoint Server.
Identify users
To identify the stakeholders and participants in your document management solution, you can use a survey to
collect 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 websites used for hosting documents?
Who sets guidelines and policies for managing documents?
Who manages records in your organization?
Who deploys and maintains the servers on which documents are stored?
Identifying content stakeholders can help you make sure 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 must have to implement your solution.
Which information management policies to apply to the sites.
NOTE
Information management policies are not available in SharePoint Foundation 2013.
The information to collect includes the following:

Document type, such as equity research note, employee performance review, internal memo, or product
specification.
The purpose of each document type, such as "gives customers recommendations about equities together
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" — instead of 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.
Table: Example with research information
TYPE PURPOSE AUTHOR USER ROLE FORMAT OTHER ROLES LOCATION
Equity Gives Financial Customer DOCX (for Reviewer Authoring site

research note premium analyst authoring); (technical); Testing site
customers of PDF (for reviewer
a financial publishing) (legal);
service approver;
guidance on copy editor;
whether to site
buy or sell administrator
one or more
stocks
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.
Table: Example with employee information

Employee Evaluates the Information Managers; .DOCX Reviewer Client

performance performance worker; human (human computer
review of an manager resources resources); E-mail server
employee — specialists reviewer (as
including self- (legal); attachment)
evaluation approver Corporate
and (upper web server
manager's manager); Corporate
evaluation records records center
manager
Analysis Two authors and multiple reviewers require one or more workflows. The document is handled by many
people, then is located in a corporate web server (presumably highly secured) and is managed in place or moved
to a records center. The sensitive nature of this content requires Information Rights Management (IRM ) on the
desktops and servers, in addition to corporate policies and best practices (such as auditing) that protect the
employee's privacy and the enterprise's legal standing.
NOTE
The Records Center is not available in SharePoint Foundation 2013.
Worksheets
Use the following worksheets to record the information discussed in this article:
Document management participants worksheet (https://go.microsoft.com/fwlink/p/?LinkId=165871)
Analyze document usage worksheet (https://go.microsoft.com/fwlink/p/?LinkId=165873)
Plan document libraries in SharePoint Server

This article describes how to plan document libraries in your SharePoint Server document management solution.
Document libraries are collections of files on SharePoint Server 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 Office Open 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 Overview of
document management in SharePoint 2013 .
NOTE
The publishing feature, Document Center, Records Center, and Published Links web service are not available in SharePoint
Foundation 2013. All other content in this topic applies to SharePoint Server 2016, SharePoint Server 2013 and SharePoint
Foundation 2013 unless otherwise noted.
Determine library type

When you identify which document libraries best match your organization's needs, you might also determine that
that you want 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 Server 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.
Table: How document libraries are used
LIBRARY PURPOSE
Library in a team site Collaboration; easy sharing of content among peers; content
control, such as versioning; SharePoint Server 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.
Library in a Document Center site (SharePoint Server 2016 A large-scale library useful as an enterprise knowledge base or
and SharePoint Server 2013 only.) historical archive; includes features to help users navigate,
search, and manage lots of documents in a deep hierarchy by
using a set of specialized Web Parts.
LIBRARY PURPOSE
Library in a Records Center (SharePoint Server 2016 and Specialized records management; each library corresponds to
SharePoint Server 2013 only.) a record type, such as contract, that the organization must
retain for legal compliance purposes; libraries retain
documents, metadata, and associated audits and are meant to
be read-only.
Library in an Internet site (HTML) (SharePoint Server 2016 and Content in web pages to incorporate into an Internet or
SharePoint Server 2013 only.) intranet website; SharePoint Server supports editing web
pages directly and manages the underlying document libraries
for each page automatically.
Library in an Internet site (hybrid) (SharePoint Server 2016 Content available for downloading from a website; you can
and SharePoint Server 2013 only.) present content from document libraries on an Internet site.
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 in SharePoint Server 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.
Table: Document usage analysis
DOCUMENTS PURPOSE AUTHOR USERS FORMAT
Engagement ideas Develop new Project leader Sales manager; .docx

and requests customer project leader
engagements
Proposals Describe a proposed Project leader Project managers; .docx

customer project team
engagement members; customers
Contracts Commit to a Lawyer Project leader; project .docx

consulting manager; sales
engagement manager; customers
DOCUMENTS PURPOSE AUTHOR USERS FORMAT
Research results and Generate documents Project leader; project Editors; technical .docx and other types
project deliverable related to the contributor; reviewers
drafts customer consultant
engagement
Deliverable Generate final Project leader Customers .pdf

documents deliverables, probably
converted from .docx
format
Best practices and Capture Project contributor; All team members Various types
case study documents organizational consultant;
knowledge knowledge manager
Corporate records - Retain some content, All Corporate records All

(SharePoint Server such as contracts, as managers; corporate
2013 only.) corporate records lawyers
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. (SharePoint Server 2016 and
SharePoint Server 2013 only.)
All members of the enterprise need access to a Document Center site for viewing best practices and case
study documents. (SharePoint Server 2016 and SharePoint Server 2013 only.)
Corporate records managers and lawyers need access to an enterprise Records Center to maintain
corporate records. (SharePoint Server 2016 and SharePoint Server 2013 only.)
The following figure shows how these libraries might be distributed. The sites are hosted in three site collections:
an Internet site collection for customer access, an extranet site collection for remote authoring by team members,
and an intranet site collection for secure maintenance of the records management site. (SharePoint Server 2016
and SharePoint Server 2013 only.)
Figure: How document libraries might be distributed
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 Server 2013 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 Plan content types and workflows in
SharePoint 2013.
Authors can copy a document to a library in any site in which they have authoring permissions. The
relationship between the source and the destination document is maintained so that the copy can be
refreshed as needed.
Web pages and whole websites can be staged and published from one site to another, either manually or
automatically based on a schedule. (SharePoint Server 2016 andSharePoint Server 2013 only.)
Content can be sent to the records management site by using the SharePoint Server user interface, by using
a workflow, or by using a custom solution that is based on the SharePoint Server object model. (SharePoint
Server 2016 and SharePoint Server 2013 only.)
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.
Returning to the example, the following figure shows how to apply some of these content flow techniques. Note
that the Staged Internet site has been added to the Authoring portal site. (SharePoint Server 2016 and SharePoint
Server 2013 only.)
Figure: How to apply content flow techniques
By using publishing features, an author can publish web pages to the Internet site. (SharePoint Server 2016
and SharePoint Server 2013 only.)
By using the Copy command, an author can copy documents to the Document Center site.
By using a custom workflow, an author can copy documents to document libraries on the Internet site.
By using the Send To command, an author can send contracts to the enterprise records repository.
(SharePoint Server 2016 and SharePoint Server 2013 only.)
Promoting document libraries from Office client applications

IMPORTANT
This section only applies to SharePoint Server 2016 and SharePoint Server 2013.
You can customize the Office Open dialog box and the Save dialog box to encourage organization members to use
document libraries as storage locations. By adding sites to the My Places bar next to the Open dialog box and the
Save dialog box, you can provide single-click access to the locations where users should store their documents.
This makes it possible for team members to interact with the document libraries when they use Save from Office
client applications, instead of having to go directly to the server to upload their documents.
To promote using sites in the Open dialog box and the Save dialog box, you can publish them by using a web
service. This service provides a list of sites targeted to specific users based on their roles or the sites that they are
members of. An Office client application can automatically discover this web service through the user's My Sites.
Other server products can also implement this web service and provide the location of the service to the Office
client application. After the web service is configured, Office adds an entry to the My Places bar and populates it
with the locations that are defined by the web service. For more information about the Published Links web
service, see Published Links web service in the MSDN Library.
Or, administrators can set registry keys to add specific sites to the My Places bar in the Office Open dialog box and
the Save dialog box. Registry keys are deployed by using Group Policy and an Active Directory directory service
template that is provided in the Office 2013 Resource Kit.
You can limit the locations that organization members can save content to by using the Office Save dialog box. For
example, you can restrict the ability to save files to desktops and force users to save content in a document library.
In Office, you can control where users can browse to save their documents. This guides users to save in approved
locations. Note that this does not guarantee that users will not save files to their local computers or other
unapproved locations. There are many ways to move files onto a computer, and motivated people can work around
most restrictions. However, by limiting access to these locations through the Office Save dialog box, you can
significantly reduce the number of team members who use these unapproved locations.
To restrict the locations available in the Office Save dialog box, use Group Policy to set the appropriate registry
keys to enable this setting and define the approved local, network, or server locations. When this setting is enabled,
any location not defined in this manner — including standard links to the Desktop and My Network Places folders
— will be removed from the My Places bar.
The list of approved locations can be limited to one or more Office applications. For example, an administrator can
restrict save locations in Access while allowing other Office applications to save anywhere.
Plan content types and workflows in SharePoint
Server

This article describes content types and workflows and provides guidance about how to plan to integrate them into
your SharePoint Server document management solution. A content type is a reusable collection of metadata
(columns), workflow, behavior, and other settings for a category of items or documents in a SharePoint Server 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 Server.
Before you use the Content type and workflow planning (https://go.microsoft.com/fwlink/p/?LinkID=165878)
worksheet included with this article to plan your content types and workflows, ensure that you have read Identify
users and analyze document usage in SharePoint Server 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.
Metadata to associate with items of its type.
Workflows that can be started from items of its type.
Information management policies to associate with 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, policies, and templates directly with a list or library. However, doing this can
limit these associations to the list or library and is not reusable across your solution. In SharePoint Server 2013, 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. In SharePoint Server, you can also create a
custom content type inside a content type hub that is defined in a managed metadata service instance. When it is
created in a content type hub, the content type will be available to other site collections that are part of web
applications associated with that managed metadata service instance.
NOTE
The Managed Metadata service and the content type hub are not available in SharePoint Foundation 2013.
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 Server, 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.
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 user-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 make sure 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 Office
In the Microsoft Office system, when a user edits a document from a SharePoint Server 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 Server makes it easy to customize the property form for a content type. When you configure a content
type, you can start InfoPath, 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 would use if no custom form
were defined. You can then customize and deploy the form as you would any other InfoPath 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 Word 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 the metadata from the parent content type at the site collection
level. Additional metadata can then be added at a lower level, such as a single 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 Server 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.
Document sets is a feature in SharePoint Server that lets you use Office to manage deliverables that span multiple
documents. Document sets are special kinds of folders that are used to manage a single deliverable, or work
product, which can include multiple documents in multiple locations. You create document sets by using extensible
templates that are provided with SharePoint Server. You can also customize Document Set templates to represent
the work products that are relevant to your organization. Document sets also include version control, which lets
you capture the status of the complete document set at various points in its life cycle. For more information about
document sets, see Plan document sets in SharePoint Server 2013.
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 (https://go.microsoft.com/fwlink/p/?LinkId=165873) 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.
NOTE
Supported core content types do not include PDF files.
For information about changing the core content types, download the white paper "Guidance for editing pre-
defined content types and site columns" (https://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.
Plan workflows
Workflows implement business processes on documents, web pages, forms, and list items in SharePoint Server.
They can be associated with libraries, lists, or content types.
In document management, use workflows to route documents from person to person so that they can each
complete their document management tasks, such as reviewing documents, approving their publication, or
managing their disposition. Also, use custom workflows to move documents from one site or library to another.
For example, you can design a workflow to copy a document from one site to another when the document is
scheduled to be archived.
SharePoint Server includes the Three-state workflow, which you can use to manage business processes that track
the status of an item through three states or phases. SharePoint Server also includes the following workflows that
address 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.
Associate a workflow with a content type when you want to make that workflow available when 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 make sure 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.
Table: Workflows for a contract content type
CONTRACT PROCESS CONTRACT WORKFLOW
Review drafts. Collect feedback

CONTRACT PROCESS CONTRACT WORKFLOW
Get approval from the manager and legal counsel. Approval
Resolve open issues. Issue tracking
Get signatures. Collect signatures

Plan document sets in SharePoint Server 2013

This article describes Documents Sets and provides guidance on how you can integrate them with your SharePoint
Server document management solution.
About Document Sets

Document Sets are a feature in SharePoint Server that enables an organization to manage a single deliverable, or
work product, which can include multiple documents or files. A Document Set is a special kind of folder that
combines unique Document Set attributes, the attributes and behavior of folders and documents, and provides a
user interface (UI), metadata, and object model elements to help manage all aspects of the work product.
For teams and users in many organizations, a set of documents, or a work product, is needed to better manage a
project or deliverable. For example, a legal team might need to collect, create, and manage various documents,
photos, and audio files that are related to a particular case. Or, a sales team might need to compile documents from
various sources to create and manage a request for proposal (RFP ) for a potential client. Documents Sets provide
those teams and users with the ability to manage those sets of documents as a single collection, deliverable, or
work product. Document Set owners can then create a custom Welcome Page that can display the items included
and important information about the work product.
In SharePoint Server, organizations that want to create and manage Document Sets consistently can configure a
Document Set content type for each work product they typically create. A Document Set content type can then
define approved content types, attributes, default items, columns, workflows, and policies. Additional customized
Document Set content types can then be created from the parent content type, each inheriting properties and
settings from the parent Document Set content type. After the content type is added to a library, users can then
create a Document Set that inherits the attributes of the Document Set content type by using the New command.
A Document Set content type provides additional settings that enable you to specify allowed content types, default
content, shared columns, Welcome Page columns, and default Welcome Page view.
For more information about content types, see Plan content types and workflows in SharePoint 2013.
For more information about how to create and manage Document Sets in SharePoint Server 2013, see Create and
configure a new document set content type in SharePoint Server 2013 Help.
Administering Document Sets

Document Sets in SharePoint Server share many of the same attributes and properties as folders. However there
are some important considerations you should be aware of when planning a Document Set solution.
There is no limit on the number of documents that can exist in a Document Set. However, display load times
may be limited by the list view threshold which by default is set at 5,000 items. Folders are allowed in
document sets, but metadata navigation cannot be used in a Document Set. Therefore, it is important to
consider the possibility of exceeding list view thresholds and navigation design concerns when you
determine how many items should exist in a Document Set. In addition, when you use the Send to feature
with a Document Set, the sum for all documents in a Document Set cannot be larger than 50MB. For a
collection or work product with a very large number of items, a folder structure in a document library may
be a better solution.
There is no limit on the number of Document Sets that can exist in a document library. However, the
number of Document Sets that can appear in lists will be limited by the list view threshold.
When using shared metadata, if there are more than 10 items that are using shared metadata in a
Document Set, metadata updates will be run by a timer job every 15 minutes. For example, if you have 10
documents in the top level of the library, and a single document in a Document Set with shared metadata,
the time job will not run. But if you add another Document Set with 9 more documents, the timer job will
run.
When using Document Set routing, Document Sets that are sent to a content organizer will remain in the
drop-off library and be moved to the appropriate location by the content organizer processing timer job,
which by default runs daily.
To use Document Sets in a site collection, the Document Sets feature must be enabled.
To enable Document Sets feature for a site collection
1. On the Site Settings page, under Site Collection Administration, click Site collection features.
2. On the Features page, for Document Sets, click Activate.
After the Document Sets feature is enabled, you can create Document Set content types.
Plan for information management policy in
SharePoint Server

An information management policy is a set of rules for a type of content. Each rule in a policy is a policy feature.
For example, an information management policy feature could specify how long a type of content should be
retained, or it could provide document auditing. Information management policies enable you to control who can
access your organizational information, what they can do with it, and how long the information should be retained.
Information management policies and policy features

NOTE
In this article, the term policy refers to information management policy unless otherwise specified.
Policies can be implemented to help an organization comply with legally mandated requirements, such as the
need to retain records. For example, a Human Resources policy, used in an organization to ensure that employee
records are handled in compliance with legally recommended guidelines, could include the following policy
features:
Auditing, to record the editing and viewing history of each employee-related document.
Retention, to ensure that work-in-progress content is not kept for an unnecessarily long time.
Print restrictions, to ensure that sensitive employee-related documents are printed only on secure printers.
Note that this is an example of a custom policy feature that must be implemented by using the SharePoint
Server object model or obtained from a third-party software vendor.
Policy features are implemented as programs that run on SharePoint Server. They can be enabled and configured
by a server administrator and, when they are enabled, they can be used by site administrators to define policies.
SharePoint Server includes policy features to help you manage your content. By using the SharePoint Server
object model, you can design and install custom policy features that meet unique enterprise needs.
When your organization uses Office client applications together with SharePoint Server, policies are enforced
both on the server and in the client applications. This is done transparently; policy features that apply to a
document are described in a policy statement that is associated with the document, and policy-aware applications
prevent users from doing tasks that violate the document's policy.
To implement a policy, associate it with content types, libraries, or lists in sites.
You can associate a policy with a library, list, or content type in the following ways:
Associate policy features with a Site Collection policy and then associate that policy with a
content type or with a list or library. The top-level site of a site collection includes a Site Collection
Policies gallery where administrators of the top-level site can create new policies. After creating a Site
Collection policy, you can export it so that administrators of other site collections can import it into their
Site Collection Policies galleries. This lets you standardize policies across your organization.
When a Site Collection policy is associated with a content type and that content type is associated with a list
or library, the owner of the list or library cannot modify the Site Collection policy in the list or library. This
ensures that policies that are assigned to a content type are enforced at each level of the site hierarchy.
Associate a set of policy features directly with a content type, and then add that content type to
one or more lists or libraries. To ensure that a policy that is created by using this method will be used in
the whole site collection, associate it with a content type in the Site Content Type gallery of the top-level
site collection. Then every item of that content type in the site collection, and every item of a content type
that inherits from the original content type, will have the policy. When you use this method of associating a
policy with a content type, it is harder to reuse the policy in other site collections, because policies created
by using this method cannot be exported.
NOTE
To more tightly control which policies are being used in a site collection, site collection administrators can disable the
ability to set policy features directly on a content type. When setting policy features on a content type is restricted,
content type designers can only associate policies from the Site Collection Policies gallery with content types.
Associate a set of policy features directly with a list or library. You can only use this method if the list
or library does not support multiple content types. This method of creating a policy is only useful for a
narrowly defined policy that applies to a single list or library.
NOTE
To more tightly control which policies are being used in a site collection, site collection administrators can disable the
ability to set policy features directly on a library. When setting policy features on a library is restricted, content type
designers can only associate policies from the Site Collection Policies gallery with libraries.
Information management policy integration with Office system

applications
SharePoint Server information management policies are exposed in Office client applications. When you
configure an information management policy on the server, you can write a policy statement that informs
information workers about the policies that are enforced on documents. For example, the policy statement might
indicate that a document will be deleted after a certain time or that it contains sensitive information that should
not be communicated outside the company. The statement might even provide a contact name if the information
worker needs more information about the policy.
Custom policy features can be integrated in Office client applications. However, you must implement policy-
specific behaviors that you want to be available from Office client applications, and you must give users a way to
install these behaviors on their client computers via mechanisms such as add-ins to make them available from
Office client applications. For example, if you implement a custom policy feature that restricts the printers that can
be used to print a content type, you must provide a custom add-in for Microsoft Office client applications to
enforce the restriction from these applications.
Policy features available in SharePoint Server

This section describes the policy features that are included in SharePoint Server.
Retention The Retention policy feature lets you define retention stages, with an action that happens at the
end of each stage. For example, you could define a two-stage retention policy on all documents in a specific
library that deletes all previous versions of the document one year after the document is created, and
declares the document to be a record five years after the document is created.
The actions that can occur at the end of a stage include the following:
Moving the item to the Recycle Bin
Permanently deleting the item
Transferring the item to another location
Starting a workflow
Skipping to the next stage
Declaring the item to be a record
Deleting all previous drafts of the item
Deleting all previous versions of the item
Auditing The Auditing policy feature logs events and operations that are performed on documents and list
items. You can configure Auditing to log events such as the following:
Editing a document or item
Viewing a document or item
Checking a document in or out
Changing the permissions for a document or item
Deleting a document or item
Labeling The Labeling policy feature specifies a label to associate with a type of document or list item.
Labels are searchable text areas that SharePoint Server generates based on properties and formatting that
you specify. For example, in a law firm, a document related to a legal matter could include a label that
contains the clients' names, the case number, and the attorney assigned to the matter. Labels are especially
useful in printed versions of documents as a way to display document properties in printed copy. Along
with using labels for documents, you can associate a label with a list item and include that label in views of
the list.
NOTE
The label policy feature has been deprecated and should not be used in SharePoint Server 2013 or SharePoint Server
2016.
Barcode The Barcode policy feature enables you to track physical copies of a document by creating a
unique identifier value for a document and inserting a bar code image of that value in the document. By
default, bar codes are compliant with the common Code 39 standard (ANSI/AIM BC1-1995, Code 39), and
you can plug in other bar code providers by using the policies object model.
Plan document policies

When you plan your solution's policies, first determine organization-wide policy needs, and then design Site
Collection policies to meet those needs and distribute those policies for inclusion in the Site Collection Policy
galleries of all relevant site collections. This might require planning custom policy features. Note that, if your policy
requires custom policy features and resources, those features and resources must be installed and enabled on all
server farms on which your solution is used.
A typical example of an organization-wide policy is one that is designed to promote best practices in auditing and
retaining product specifications across the divisions of an organization. A single Site Collection policy is designed
to be applied to all product specifications so that they are consistently audited and retained. After the Site
Collection policy is designed and tested, it is exported and then imported to Site Collection Policy galleries of
other site collections in which product specifications are stored. It is then associated with all product specification
content types in the various site collections to impose the policy on all product specifications.
Plan document versioning, content approval, and
check-out controls in SharePointServer

This article describes how to plan to use versioning, content approval, and check-out in SharePoint Server to
control document versions throughout their life cycle.
About versioning, content approval, and check-outs

SharePoint Server 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 governance 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
governance settings. This makes sure that new libraries will reflect your content governance decisions.
For more information about versioning, see Enable and configure versioning for a list or library.
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
Server has three versioning options:
No versioning Specifies that no earlier versions of documents are saved. When versioning is not being
used, earlier 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 retained by using a simple
versioning scheme (such as 1, 2, 3). To control the effect on storage space, you can specify how many earlier
versions to keep, counting back from the current version.
In major versioning, every time that 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
When you create a new version of a document, the incremental changes are stored in SQL Server, rather than a completely
new copy of the document. This provides the most efficient storage and helps reduce overall storage requirements.
Plan content approval

Use content approval to formalize and control 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.
A document draft awaiting content approval is in the Pending status. 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 status
becomes Pending. SharePoint Server keeps the earlier version of the document so that users who have read
permissions can still view it. After the pending changes are approved, the new version of the document is
made available for viewing by users who have read permissions and the earlier 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 status 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 status 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 status 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 status 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 status as version 0.1 or the author can immediately request
approval. In this case, the document's status becomes Pending.
Plan check-out and check-in

You can require users to 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 users to check in and check out documents to edit them, you can use features in Office
client applications that support these actions. Users can check out documents, undo check-outs, and check in
documents from Office client applications.
When a document is checked out, it is locked for exclusive editing by the user. When the user saves edits to this file,
the changes are uploaded and saved to the server. The changes are private to the user and not visible to others.
When the user is ready to check in the document, the latest changes are made visible to others and published.
From Office 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.
Overview of co-authoring in SharePoint Server

Audience: IT Professionals
Use the co-authoring feature in SharePoint Server to enable multiple users to work on a document, at any time,
without interfering with each other's changes. Co-authoring removes barriers to server-based document
collaboration and helps organizations to reduce the overhead associated with traditional document sharing
through attachments. This functionality requires no additional server setup and is the default state for documents
stored in SharePoint Server. Co-authoring functionality is managed by using the same tools and technologies that
are already used to manage SharePoint, helping to minimize the impact on administrators.
Office provides co-authoring functionality for Word, PowerPoint, OneNote, and Visio. If you have SharePoint
Server configured to use Office Web Apps Server, users can also co-author documents in Word, PowerPoint, Excel,
and OneNote Web Apps.
IMPORTANT
This article is for IT Professionals managing SharePoint Server. > Are you looking for help with co-authoring? You may
be looking for Document collaboration and co-authoring, which will help you understand and use the co-authoring and
versioning and applies to SharePoint Online.
Co-authoring functionality in SharePoint Server

In traditional collaboration, documents are shared via email attachments. Tracking versions and edits from
multiple authors is difficult and time-consuming for users. Email 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 to store documents for collaboration has reduced these problems by providing consistent
access to up-to-date versions of documents, the ability to track earlier 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 can't 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.
Co-authoring in SharePoint Server 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 work 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 the other's work.
Several authors work 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 provides 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 of co-authoring in SharePoint
Server
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,
PowerPoint, OneNote, Visio or one of the Office Web Apps, he or she merely opens it from SharePoint Server, as
usual. If another user already has the document open, both users can edit the document at the same time. One
exception to this is that users can co-author in Excel Web App only if everyone uses the Excel Web App to access
the workbook. If anyone uses Excel (the client application) to access the workbook, co-authoring in Excel Web App
will be disabled for that workbook while it is open in the client application.
When a user saves a Word, PowerPoint, or Word document, other current users are notified that there are new
edits. Those users can refresh their views immediately to see the changes or continue their work and refresh later
to see the latest edits. PowerPoint Web App, and Excel Web App auto-save so that users can view any changes
automatically. The authors can see one another's work, and everyone knows who is working on the document.
SharePoint Server versioning and tracking tools protect the document so that authors can roll back unwanted
changes. When Skype for Business is available, users can see the online status of fellow co-authors and start
instant messaging conversations without leaving the document.
In OneNote and OneNote Web App, 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 so that
everybody has a complete set of notes. Edits made by multiple users on the same page appear automatically,
which enables 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 client application does not support co-authoring workbooks in SharePoint Server. The Excel client
application uses the Shared Workbook feature to support non-real-time co-authoring workbooks that are stored
locally or on network (UNC ) paths. Co-authoring workbooks in SharePoint is supported by using the Excel Web
App.
Important planning considerations for co-authoring in SharePoint

Server
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 is designed to be easy to set up and requires minimal effort to manage.
But, 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 guarantee that 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. For more information, see Overview of site permissions in SharePoint Server.
Versioning -SharePoint Server versioning keeps track of changes to documents while they are being
edited, and even stores earlier versions for reference. By default, this feature is turned off in SharePoint
Server. SharePoint Server supports two kinds of versioning, major and minor. It is best that minor
versioning remain off for document libraries that are used for co-authoring in OneNote, because it 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. For more information, see
How does versioning work in a list or library?.
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. For
more information, see Enable and configure versioning for a list or library
Versioning period - The versioning period determines how often SharePoint Server will create a 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 affect 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 in SharePoint Server.
Check out - When a user checks out a document for editing, the document is locked for editing by that
user. This prevents co-authoring. Do not enable the Require Check Out feature in document libraries in
which co-authoring will be used. By default, Require Check Out is not enabled in SharePoint Server. Users
should not check out documents manually when co-authoring is being used. For more information, see Set
up a library to require check-out of files.
Planning considerations for co-authoring in OneNote notebooks

Unlike Word and PowerPoint, OneNote stores version information within the file itself. For this reason,
administrators should follow these recommended practices when storing OneNote notebooks in a SharePoint
Server document library:
Do not enable minor versioning. By default, minor versioning is not enabled in SharePoint Server.
Major versioning is enabled in SharePoint Server by default. Set a reasonable maximum number of
versions to store.
Performance and scalability considerations for co-authoring in

SharePoint Server
SharePoint Server and Office applications minimize the performance and scalability impact that is 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 earlier versions of SharePoint.
Office clients are configured to reduce server impact by reducing the frequency of synchronization actions that are
related to co-authoring when the server is under heavy load, or when a user is not actively editing the document.
This helps reduce overall performance impact.
See also
Plan document versioning, content approval, and check-out controls in SharePointServer
Configure versioning for co-authoring in SharePoint
2013

Document library versioning is the method by which successive iterations of a document are numbered and saved.
By default, versioning is disabled in SharePoint Server 2013 document libraries . We recommend that you enable
this feature for document libraries in which users plan to co-author documents or presentations.
Before you configure versioning for co-authoring, review Overview of co-authoring in SharePoint Server.
Configure versioning for co-authoring in SharePoint Server 2013

SharePoint versioning helps protect documents and prevent data loss by allowing authors to roll back to a
previous document version when the current version contains unwanted changes.
Do not enable minor versioning in document libraries that contain OneNote notebooks. 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. To
limit server storage usage, you can limit the number of retained versions. If you enable major versioning in a
document library that contains OneNote notebooks, we recommend that you specify the maximum number of
versions so you can use disk space more efficiently.
To enable versioning
1. Browse to the document library that you want to configure.
2. In the toolbar, on the LIBRARY tab, in the Settings group, choose Library Settings.
3. In General Settings, choose Versioning settings.
4. In Document Version History, select Create major versions.
5. 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 in SharePoint Server 2013

When a document is checked out of a document library, the document is locked. This makes it unavailable for co-
authoring. Therefore, the Require Check Out setting should not be enabled in document libraries that are used
for co-authoring. By default, for SharePoint Server 2013 document libraries, this setting is not enabled.
To disable Require Check Out
1. Browse to the document library that you want to configure.
2. In the toolbar, on the LIBRARY tab, in the Settings group, choose Library Settings.
3. In General Settings, choose Versioning settings.
4. In Require Check Out, select No (default).
See also
Concepts
Configure the co-authoring versioning period in SharePoint Server
Configure the co-authoring versioning period in
SharePoint Server

The CoauthoringVersionPeriod property specifies, in minutes, how often SharePoint stores a version of a
document that is being edited. This article describes how to use Microsoft PowerShell to configure the
CoauthoringVersionPeriod property. For more information about document library versioning, see Configure
versioning for co-authoring in SharePoint 2013.
Configure the co-authoring versioning period in SharePoint Server

2013
When versioning is turned on, SharePoint Server 2013 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.
You can configure the CoauthoringVersionPeriod property by using the Microsoft PowerShell. If the value is set to
0, SharePoint Server 2013 captures 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 Server 2013 creates one version for the whole editing session.
This latter behavior matches the behavior of files that are not co-authored and files that were created in earlier
versions of SharePoint Server 2013 or SharePoint Foundation.
To configure the co-authoring versioning period by using Windows PowerShell (save as script and run
script)
2013 cmdlets.
NOTE
2. Paste the following code into a text editor, such as Notepad:
$siteurl ="<ServerName>"
$mysite=new-object Microsoft.SharePoint.SPSite($siteurl)
$mysite.WebApplication.WebService.CoauthoringVersionPeriod = <Time>
$mysite.WebApplication.WebService.Update()
3. Specify the following parameters:

Parameters to configure the co-authoring versioning period
PARAMETER VALUE
ServerName Server name
Time Number in minutes
4. Save the file and add the .ps1 extension, such as SuggestedNameOfFile.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. Start the SharePoint 2013 Management Shell as Administrator.

6. Change to the directory to which you saved the file.
./SuggestedFileName.ps1
See also
Concepts
Configure versioning for co-authoring in SharePoint 2013
Configure the maximum number of co-authoring
authors in SharePoint Server

The CoauthoringMaxAuthors property lets you specify the maximum number of users who can co-author a Word
document or PowerPoint presentation at the same time in SharePoint Server 2013. This article describes how to
configure the CoauthoringMaxAuthors property by using Microsoft PowerShell.
Configure the maximum number of co-authoring authors for

SharePoint 2013
You can limit the number of users who can co-author a document at the same time by setting the
CoauthoringMaxAuthors property. This property only applies to Word 2010, Word 2013, Word Web App,
PowerPoint 2010, PowerPoint 2013 and PowerPoint Web App documents. There is no upper limit to the number of
users who can co-author OneNote notebooks.
To configure the maximum number of co-authoring users for Word documents and PowerPoint
presentations by using Windows PowerShell (save as script and run script)
2013 cmdlets.
NOTE
$siteurl = "<ServerName>"
$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.
NOTE

7. At the PowerShell command prompt, type the following command: ./SuggestedFileName.ps1
See also
Concepts
Disable co-authoring in SharePoint Server

Co-authoring in SharePoint Server makes it possible for multiple users to work on a document, at any time,
without interfering with each other's changes. Although we have engineered co-authoring to be scalable and
efficient, some organizations that have hardware limitations may want to turn off co-authoring to minimize any
additional effects on server performance.
This article describes how to disable co-authoring functionality in SharePoint Server by using Group Policy or by
using PowerShell.
Disable co-authoring in SharePoint Server

There are three ways to disable co-authoring:
You can use Group Policy to disable co-authoring functionality on the client-side. For more information, see
Group Policy overview for Office 2013.
You can use Microsoft PowerShell to set the DisableCoauthoring server property. This disables the co-
authoring property for Word and PowerPoint documents on the server. This property applies to documents
or presentations that are authored in Word 2010, Word 2013, Word Online, PowerPoint 2010, PowerPoint
2013 and PowerPoint Web App.
You can enable the Require Check Out setting in a document library. This disables co-authoring in the
document library. For more information, see Configure Require Check Out in SharePoint Server 2013.
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. Start 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. Choose (right-click) the Group Policy Object where your co-authoring settings are configured, and then
choose Edit.
4. For Word 2013, expand User Configuration, Administrative Templates, Microsoft Word 2013,
Collaboration Settings, Co-authoring, and then open (double-click) Prevent Co-authoring.
For PowerPoint 2013, expand User Configuration, Administrative Templates, Microsoft PowerPoint
2013, Collaboration Settings, Co-authoring, and then choose Prevent Co-authoring.
5. In the Prevent Co-authoring Properties dialog box, select Enabled, and then choose OK.
To disable co-authoring for Word documents and PowerPoint presentations at the web service level by
using Windows PowerShell (save as script and run script)
cmdlets.
NOTE
$siteurl = "<servername>"
$mysite.WebApplication.WebService.DisableCoauthoring = $true;
$mysite.WebApplication.WebService.Update();
3. Specify the following parameter:
PARAMETER VALUE
servername Server name
NOTE

To disable co-authoring for Word documents and PowerPoint presentations at the web application level
by using Windows PowerShell (save as script and run script)
cmdlets.
NOTE
$siteurl = "<servername>"
$mysite.WebApplication.DisableCoauthoring = $true;
$mysite.WebApplication.Update();
3. Specify the following parameter:
PARAMETER VALUE
servername Server name
NOTE

See also
Workflow in SharePoint Server

Workflows in SharePoint allow you to model and automate business processes. These business processes can
range from simple to complex. But most importantly, workflow lets users focus on doing the work -- rather than
managing the workflow.
Workflows help people to collaborate on documents and to manage project tasks by implementing business
processes on documents and items in a SharePoint site. Workflows help organizations adhere to consistent
business processes, and improve organizational efficiency and productivity.
SharePoint 2013 Workflow and Microsoft Flow

SharePoint Server 2019 supports a variety of workflow technologies to meet the needs of our customers. These
workflow technologies are described below.
The SharePoint 2013 Workflow platform is the recommended workflow technology for SharePoint Server
2019. These workflows integrate with Microsoft Workflow Manager and will provide a stable and reliable
workflow experience for SharePoint Server 2019.
Microsoft Flow is the new cloud-based platform to automate actions across a variety of applications and
services. Thanks to hybrid technology, you can also integrate Microsoft Flow into your SharePoint Server
environments using the On-Premises Data Gateway. Each related user must be assigned a PowerApps Plan 1
license to use Flow with SharePoint Server, which is not included as part of the SharePoint Server license. In
addition, Microsoft Flow is currently optimized for non-interactive workflows with SharePoint Server. If you
require interactive workflows, we recommend exploring the SharePoint 2013 Workflow platform instead.
The SharePoint 2010 Workflow platform is also supported in SharePoint Server 2019 for backward
compatibility. This allows SharePoint Sever 2019 to run legacy workflows from previous versions of SharePoint
Server. Although SharePoint 2010 workflows are still supported, we don’t recommend building new workflows
using this technology. Instead, we recommend exploring either SharePoint 2013 workflows or Microsoft Flow.

SharePoint Server can use the workflow service built on the Windows Workflow Foundation. This service is called
Workflow Manager and it is designed to play a central role in the enterprise. Processes are central to any
organization and workflow is the orchestrator of processes. Workflow Manager integration was introduced with
SharePoint Server 2013. SharePoint Server 2016 builds stability and reliability into this already proven workflow
platform. The Workflow Manager platform continues to be called the SharePoint 2013 Workflow platform and the
traditional workflow platform continues to be called the SharePoint 2010 Workflow platform.
Workflow development tools

There are several tools that come together to provide a rich workflow development experience. These include the
following:
Visual Studio 2015
A supported web browser such as Edge, Firefox, or Chrome
The primary development tool for a SharePoint Server workflow is called SharePoint Designer 2013. SharePoint
Designer 2013 provides a rich set of features specifically designed for workflow development against both the
SharePoint 2010 Workflow platform and the SharePoint 2013 Workflow platform. You work with SharePoint
Designer 2013 by opening it on your local computer and then connecting it to a SharePoint Server site.
TIP
SharePoint Designer 2013 can connect to any SharePoint Server site as long as you have permissions to that site and can
access it over a network. For example, you might have SharePoint Designer 2013 installed on a computer in your home office
and SharePoint Server might be installed on a server at your corporate data center. As long as you can connect to your site,
you can use SharePoint Designer 2013 to develop workflows for it.
Visual Studio 2015

Visual Studio 2015 is used in many types of Microsoft development. You can use Visual Studio 2015 to develop
workflows similar to SharePoint Designer 2013. However it can also be used to develop custom actions and tasks
such as a workflow action that interacts with a custom application.
SharePoint Server ships with a rich assortment of actions and tasks. If you need a very specific action, you can use
Visual Studio 2015 to develop it. The custom action can then be used in SharePoint Designer 2013 by a workflow
developer.
Web browser
A web browser, such as Edge, Firefox, or Chrome, is what you use to interact with SharePoint Server sites. For
example, you can create lists and libraries, associate a workflow with a list and library, add items to a list or library,
start a workflow on an item, and check the status of a workflow.
Install and configure workflow for SharePoint Server

This article contains the information and procedures required to configure workflow in SharePoint Server.
IMPORTANT
The steps in this article apply to SharePoint Server. The SharePoint 2013 Workflow platform is not supported in SharePoint
Foundation 2013.
NOTE
You can watch a video series that walks through the process of installing and configuring the SharePoint 2013 Workflow
platform. To view the videos, see Video series: Install and configure Workflow in SharePoint Server 2013
Overview
A new option exists when you build a workflow for SharePoint Server. This option is called Platform Type. The
figure shows the Platform Type option when you are creating a new workflow by using SharePoint Designer
2013.
Figure: SharePoint Server includes three workflow platform options.
The only platform available when you first install SharePoint Server is the SharePoint 2010 Workflow platform.
The SharePoint 2013 Workflow platform and the Project Server platform require additional steps. The three
workflow platforms are outlined in the following table.
Workflow Platform types available in SharePoint Server
PLATFORM TYPE PLATFORM FRAMEWORK REQUIREMENTS

PLATFORM TYPE PLATFORM FRAMEWORK REQUIREMENTS
SharePoint 2010 Workflow Windows Workflow Foundation 3 Installs automatically with SharePoint
Server.
SharePoint 2013 Workflow Windows Workflow Foundation 4 Requires SharePoint Server and
Workflow Manager.
SharePoint 2013 Workflow - Project Windows Workflow Foundation 4 Requires SharePoint Server, Workflow
Server Manager, and Project Server.
NOTE
Workflow Manager must be downloaded and installed separately from SharePoint Server. It does not install automatically
when you install SharePoint Server.
Install Workflow Manager

Workflow Manager may be installed on the same servers as SharePoint or on separate, dedicated servers.
Workflow Manager can be deployed with the Web PI tool. For more information on Web PI, see Using the
Microsoft Web Platform Installer.
Install and configure SharePoint Server

You must install and configure SharePoint Server. To do so, see Install and deploy SharePoint 2013.
NOTE
The SharePoint 2010 Workflow platform installs automatically when you install SharePoint Server. The SharePoint 2013
Workflow platform requires Workflow Manager and must be installed separately and then configured to work with your
SharePoint Server farm. > To function correctly SharePoint 2013 Workflows require to have App Management Service and
Site Subscription Service provisioned. It is not required to setup a wildcard certificate and DNS registration but both instances
need to be running.
Configure Workflow Manager to work with the SharePoint Server farm

You must consider the following two key factors before configuring Workflow Manager to work with SharePoint
Server.
Is Workflow Manager installed on a server that is part of the SharePoint farm?
Will communication between Workflow Manager and SharePoint Server use HTTP or HTTPS ?
These factors translate into four scenarios. Each scenario configures a SharePoint Server farm to communicate and
function with the Workflow Manager farm. Follow the scenario that matches your circumstance.
1: Workflow Manager is installed on a server that is part of 2: Workflow Manager is installed on a server that is part of
the SharePoint Server farm. Communication takes place by the SharePoint Server farm. Communication takes place by
using HTTP. using HTTPS.
3: Workflow Manager is installed on a server that is NOT part 4: Workflow Manager is installed on a server that is NOT part
of the SharePoint Server farm. Communication takes place by of the SharePoint Server farm. Communication takes place by
using HTTP. using HTTPS.
NOTE
For security reasons, we recommend HTTPS for a production environment.
TIP
For information about least-privilege configuration, see Least Privilege Configuration for Workflow Manager with SharePoint
Server 2013.
To configure Workflow Manager on a server that is part of the SharePoint Server farm and on which
communication takes place by using HTTP
1. Log on to the computer in the SharePoint Server farm where Workflow Manager was installed.
2. Open the SharePoint Management Shell as an administrator. This is accomplished by right-clicking the
SharePoint Management Shell and choosing Run as administrator.
3. Run the Register-SPWorkflowService cmdlet.
Example:
Register-SPWorkflowService -SPSite "http://myserver/mysitecollection" -WorkflowHostUri

"http://workflow.example.com:12291" -AllowOAuthHttp
4. Log on to each server in the SharePoint Server farm.

Each server in the SharePoint Server farm must have the Workflow Manager Client installed.
NOTE
When you install Workflow Manager on a server it automatically installs the Workflow Manager Client on that server.
You will still need to install the Workflow Manager Client on any additional servers. For example, if you have a farm
that contains five servers and you install Workflow Manager on one of those servers you will still need to install the
Workflow Manager Client on the four additional servers.
5. Install the Workflow Manager Client on each server in the SharePoint farm.
Download and install the Workflow Manager Client here: http://go.microsoft.com/fwlink/p/?LinkID=268376
To configure Workflow Manager on a server that is part of the SharePoint Server farm and on which
communication takes place by using HTTPS
1. Determine if you need to install Workflow Manager certificates in SharePoint.
Under some circumstances, you have to obtain and install Workflow Manager certificates. If your installation
requires that you obtain and install these certificates, you must complete that step before continuing. To
learn whether you need to install certificates, and for instructions, see Install Workflow Manager certificates
2. Log into the computer in the SharePoint Server farm where Workflow Manager was installed.
SharePoint Management Shell and choosing Run as administrator.
Example:
Register-SPWorkflowService -SPSite "https://myserver/mysitecollection" -WorkflowHostUri

"https://workflow.example.com:12290"

Each server in the SharePoint Server farm must have the Workflow Manager Client installed.
NOTE
When you install Workflow Manager on a server it automatically installs the Workflow Manager Client on that server.
You will still have to install the Workflow Manager Client on any additional servers. For example, if you have a farm
that contains five servers and you install Workflow Manager on one of those servers you will still need to install the
Workflow Manager Client on the four additional servers.
To configure Workflow Manager on a server that is NOT part of the SharePoint Server farm and on
which communication takes place by using HTTP
Before you can run the workflow pairing cmdlet, you must install Workflow Manager Client on each of the
SharePoint 2013 Management Shell command and choosing Run as administrator.
4. Run the Register-SPWorkflowService cmdlet. The cmdlet should be run only once and can be run from
any of the servers in the SharePoint farm.
Example:
Register-SPWorkflowService -SPSite "http://myserver/mysitecollection" -WorkflowHostUri

"http://workflow.example.com:12291" -AllowOAuthHttp
IMPORTANT
You must install the Workflow Manager Client on each server in the SharePoint farm before you run the pairing cmdlet.
To configure Workflow Manager on a server that is NOT part of the SharePoint Server farm and on
which communication takes place by using HTTPS
1. Determine whether you need to install Workflow Manager certificates in SharePoint 2013.
Under some circumstances, you have to obtain and install Workflow Manager certificates. If your installation
requires that you obtain and install these certificates, you must complete that step before continuing. To
learn whether you need to install certificates, and for instructions, see Install Workflow Manager certificates
Before you can run the workflow pairing cmdlet, you must install Workflow Manager Client on each of the
SharePoint Management Shell command and choosing Run as administrator.
Example:
Register-SPWorkflowService -SPSite "https://myserver/mysitecollection" -WorkflowHostUri

"https://workflow.example.com:12290"
IMPORTANT
You must install the Workflow Manager Client on each server in the SharePoint farm before you run the pairing cmdlet.
Validate the installation

Use these steps to validate that you have successfully installed and configured the required components.
To validate the installation
1. Add a user to your SharePoint site, and grant the user Site Designer permissions.
2. Install SharePoint Designer 2013 and create a workflow based on the SharePoint 2013 Workflow platform.
For more information, see Creating a workflow by using SharePoint Designer 2013 and the SharePoint
2013 Workflow platform.
3. Run this workflow from the SharePoint user interface.
Troubleshooting
For security reasons, the Setup account cannot be used to create a workflow based on the SharePoint 2013
Workflow platform. If you try to create a workflow based on the SharePoint 2013 Workflow platform by using
SharePoint Designer 2013, you receive a warning that the list of workflow actions do not exist, and the workflow is
not created.
The user who deploys and runs a workflow must be added to the User Profile service. Check the User Profile
service application page in Central Administration to confirm that the user you are using to validate workflow
installation is in the User Profile service.
You can determine which ports SharePoint Server and Workflow Manager are using for both HTTP and HTTPS by
using IIS Manager as shown in the figure.
Figure: Use IIS Manager to view the ports used by Workflow Manager
Workflow Manager communicates by using TCP/IP or Named Pipes. Make sure that the appropriate
communication protocol is enabled on the SQL Server instance that hosts the Workflow Manager databases.
The SQL Browser Service must be running on the SQL Server instance that hosts the Workflow Manager
databases.
The System Account cannot be used to develop a workflow.
To troubleshoot SharePoint Server, see Troubleshooting SharePoint Server.
Install Workflow Manager certificates in SharePoint
Server

Secure Socket Layer (SSL ) is an encrypted communication protocol which uses encryption certificates. Workflow
Manager and SharePoint Server can communicate in a secure manor using SSL. This article describes the steps
required to setup and configure SSL certificates.
Configuration steps
The following sections provide instructions for configuring SSL communication with Workflow Manager and
SharePoint Server.
Enable SSL
Enable Secure Sockets Layer (SSL ) in IIS Manager. For guidance on completing the configuration, see the
following:
Configuring SSL in IIS Manager
How to Set Up SSL on IIS 7
Install Workflow Manager certificates in SharePoint
Under some circumstances, you must obtain and install Workflow Manager "issuer" certificates on SharePoint
Server. Here are the circumstances where you must install Workflow Manager certificates:
1. If SSL is enabled either on SharePoint Server (which is not the default) or on Workflow Manager (which is
the default), AND
2. If SharePoint Server and Workflow Manager do not share a Certificate Authority, AND
3. If Workflow Manager is configured to generate self-signed certificates (which is the default).
NOTE
Product trial, workflow development, and troubleshooting are easier if SSL is not enabled. However, communication between
SharePoint Server and Workflow Manager is not encrypted if SSL is not enabled. For this reason, SSL should be enabled for
production configurations.
To obtain and export certificates from the Workflow Manager server

1. On a computer that has Workflow Manager installed, choose IIS Manager, Sites. Right-click Workflow
Management Site, and then choose Edit Bindings.
2. Choose the https port, and then choose Edit. Choose the View button in the SSL Certificate section.
3. To export the issuer certificate, do the following:
4. In the Certificate window, choose the Certification path tab.
5. Select root certification path and choose View.
6. On the Details tab, choose Export Certificate, and take the default options in the export wizard.
7. Give the exported certificate file a friendly name.
To install certificates on SharePoint Server
1. Copy the issuer certificate to your SharePoint Server computer.
2. Add the certificates to the Windows Certificate store.
3. For each certificate, do the following:
4. Double-click the file to open and view the certificate.
5. On the certificate, choose the Install Certificate button to start the installation wizard.
6. In the wizard, choose Place all certificates in the following store, and then choose Trusted Root
Certification Authorities.
7. Add the certificates to SharePoint Server by going to the SharePoint Management shell and running the
New-SPTrustedRootAuthority cmdlet. Do this for each certificate file.
Video series: Install and configure Workflow in

This six-part video series walks through the installation and configuration of the SharePoint 2013 Workflow
Platform where communication between the SharePoint farm and the Workflow farm is using Secure Sockets
Layer (SSL ). These videos show the process in SharePoint Server 2013. The process is the same in SharePoint
Server 2016.
Episode 1: Installation overview

This video provides an overview of the installation and configuration process for Workflow in SharePoint Server
2013. (time: 1:15)
This video provides an overview of the installation and configuration process for Workflow in
Episode 2: Pre-install steps

This video provides a walkthrough of the pre-install steps that must be completed before installing and configuring
Workflow in SharePoint Server 2013. (time: 5:12)
This video provides a walkthrough of the pre-install steps that must be completed before installing and
configuring Workflow in SharePoint Server 2013.
Episode 3: Install and configure Workflow Manager

This video provides a walkthrough of the installation and configuration of Workflow Manager. (time: 10:15)
This video provides a walkthrough of the installation and configuration of Workflow Manager.
Episode 4: Install and configure Workflow Manager Client

This video provides a walkthrough of the installation of the Workflow Manager Client in the SharePoint farm.
(time: 3:40)
This video provides a walkthrough of the installation of the Workflow Manager Client in the SharePoint
farm.
Episode 5: Configure the SharePoint farm with the workflow farm

This video provides a walkthrough on how to pair the SharePoint farm with the Workflow farm in order to enable
the SharePoint 2013 Workflow Platform. (time: 3:00)
This video provides a walkthrough on how to pair the SharePoint farm with the Workflow farm in order
to enable the SharePoint 2013 Workflow Platform.
Episode 6: Test workflow

This video provides a walkthrough of testing the SharePoint 2013 Workflow Platform by using SharePoint
Designer 2013 once it has been installed. (time: 7:43)
This video provides a walkthrough of testing the SharePoint 2013 Workflow Platform using SharePoint
Designer 2013 once it has been installed.
See also
Concepts
Run cmdlets after software updates are installed

It is important that any Cumulative Updates (CU ) for SharePoint Server and Workflow Manager are installed in a
coordinated fashion. After an update has been performed, several Microsoft PowerShell cmdlets must be run in
order to maintain the connection between the SharePoint Server farm and the Workflow Manager farm.
Run the following PowerShell cmdlets as an administrator from the SharePoint Administration Shell after the
updates have been installed for SharePoint Server, Workflow Manager, and Workflow Manager Client.
IMPORTANT
The latest update level must be installed on SharePoint Server, Workflow Manager, and Workflow Manager Client before you
run the update cmdlets.
$credential = [System.Net.CredentialCache]::DefaultNetworkCredentials
$svcAddress = $proxy.GetWorkflowServiceAddress($site)
Copy-SPActivitiesToWorkflowService -WorkflowServiceAddress $svcAddress -Credential $credential -Force $true
NOTE
Because workflow supports environments with multiple Site Subscriptions, the $site Site Collection address determines the
proper configuration location for workflow settings.
Troubleshooting steps for workflow updates

Make sure all components are on the latest patch level. This includes SharePoint Server, Workflow
Manager, and Workflow Manager Client.
Verify the $proxy connection settings using the following commands:
$proxy.GetWorkflowServiceAddress($site)
Inspect any errors displayed in the SharePoint Designer user interface or any errors shown in the
SharePoint Workflow Status user interface.
Administration of SharePoint Server
Articles about operations and maintenance in SharePoint Server

CONTENT DESCRIPTION
Manage databases in SharePoint Server Learn how to manage the databases that are associated with
SharePoint Server.
Web applications management in SharePoint Server Learn how to manage web applications in a SharePoint Server
farm.
Configure server-to-server authentication between publishing Learn how to configure server-to-server authentication when
and consuming farms sharing service applications across SharePoint farms.
Configure log shipping in SharePoint Server Learn how to implement log shipping for SharePoint Server in
a disaster-recovery scenario.
Description of MinRole and associated services in SharePoint Learn about the MinRole feature in SharePoint Server 2016
Server 2016 and the services that are associated with each server role.
Managing a MinRole Server Farm in SharePoint Server 2016 Learn how to manage your MinRole farm deployment in
Role conversion using MinRole in SharePoint Server 2016 Learn about how to convert your server roles in a SharePoint
farm deployment using MinRole to help you select the right
server role when provisioning SharePoint Server 2016.
Administer search in SharePoint Server Learn how to manage the search schema and the search
topology in SharePoint Server.
Administer the User Profile service in SharePoint Server Learn how to administer the User Profile service in SharePoint
Server 2016.
Related operations and maintenance articles for SharePoint Server

Microsoft PowerShell Reference for SharePoint
System Center Operations Manager knowledge articles for SharePoint Server
Downloadable resources about operations and maintenance in

SharePoint Server
Download the System Center Management Pack for SharePoint Server.
See also
Concepts
System Center Operations Manager knowledge articles for SharePoint Server
Other Resources
About SharePoint
Server Management

Use the following articles to manage your SharePoint Server environment.
ARTICLE DESCRIPTION
Global deployment of multiple farms (SharePoint 2013) Learn about supported architectures for SharePoint 2013 in
WAN environments, strategies for optimizing performance
over WAN connections, and recommendations for service
applications.
SQL Server and storage (SharePoint Server) Learn how to plan for SQL Server and storage configuration
for SharePoint Server 2016 and SharePoint Server 2013.
Overview of backup and recovery in SharePoint Server Learn about how to prepare to back up and restore and
complete specific operations for SharePoint Server 2016 and
SharePoint 2013.
High availability and disaster recovery concepts in SharePoint Create a well-designed high availability plan and a disaster
Server recovery plan that meets business goals and objectives for
SharePoint Server 2016 and SharePoint 2013.
Configure SQL Server AlwaysOn Availability Groups for Learn how to create and configure a SQL Server Always On
SharePoint Server Availability Group for a SharePoint Server 2016 and
SharePoint 2013 farm.
Performance planning in SharePoint Server 2013 Learn about the concepts and planning considerations for
managing the capacity of a SharePoint Server environment.
Managing a MinRole Server Farm in SharePoint Server 2016 Learn how to manage your MinRole farm deployment in
Remove a server from a farm in SharePoint Server 2016 Learn how to remove a web server, application server, or
database server from a SharePoint 2013 farm.
Remove a server from a farm in SharePoint 2013 Learn how to remove a web server, application server, or
database server from a SharePoint 2013 farm.
Uninstall SharePoint 2013 Learn how to uninstall SharePoint Server 2013 and SharePoint
Foundation 2013.
Uninstall SharePoint Server 2016 Learn how to uninstall SharePoint Server 2016.
Custom Tiles in SharePoint Server 2016 This article describes Custom Tiles which is one of the new
features in the November 2016 Public Update for SharePoint
Server 2016 (Feature Pack 1).
Configure server-to-server authentication between publishing Learn how to configure server-to-server authentication when
and consuming farms you share service applications across SharePoint Server
publishing and consuming farms.
ARTICLE DESCRIPTION
Turn on automated document translation in SharePoint Server Learn how to turn on the Machine Translation Service in
SharePoint Server to let site owners automatically translate
documents.
Manage the Distributed Cache service in SharePoint Server Learn how to configure and manage the Distributed Cache
service in SharePoint Server.
Configure Request Manager in SharePoint Server
Overview
Request Manager is functionality in SharePoint Server that enables administrators to manage incoming requests
and determine how SharePoint Server routes these requests.
Request Manager uses configured rules to perform the following tasks when it encounters requests:
Deny potentially harmful requests from entering a SharePoint farm.
Route good requests to an available server.
Manually optimize performance.
Information that administrators or an automated process provide to Request Manager determine the effectiveness
of routed requests.
The following table describes possible scenarios and resolutions that Request Manager can address.
AREA SCENARIO RESOLUTION
Reliability and performance Routing new requests to web front end Request Manager can route to front-
with low performance can increase end web servers that have better
latency and cause timeouts. performance, keeping low performance
front-end web servers available.
Requests from users and bots have Prioritize requests by throttling requests
equal priority. from bots to instead serve requests
from end-users).
Manageability, accountability, and SharePoint Server fails or generally Request Manager can send all requests
capacity planning responds slowly, but it’s difficult to of a specific type, for example, Search,
identify the cause of a failure or User Profiles, or Office Online, to specific
slowdown. computers. When a computer is failing
or slow, Request Manager can locate
the problem.
All front-end web servers must be able Request Manager can send multiple or
to handle the requests because they single requests to front-end web
could be sent to any front-end web servers that are designated to handle
server. them.
Scaling limits Hardware scaling limited by load Request Manager can perform
balancer application routing and scale out as
needed so that a load balancer can
quickly balance loads at the network
level.
Setup and Deployment

Request Manager's task is to decide two things: a SharePoint farm will accept a request, and if the answer is "yes",
to which front-end web server SharePoint Server will send it. The three major functional components of Request
Manager are Request Routing, Request Throttling and Prioritizing, and Request Load Balancing. These components
determine how to handle requests. Request Manager manages all requests on a per-web-application basis.
Because Request Manager is part of the SharePoint Server Internet Information Services (IIS ) module, it only
affects requests that IIS hosts.
When a new request is received, Request Manager is the first code that runs in a SharePoint farm. Although
Request Manager is installed during setup of SharePoint Server on a front-end web server, the Request
Management service is not enabled. You can use the Start-SPServiceInstance and Stop-SPServiceInstance cmdlets
to start and stop the Request Management service instance respectively or the Manage services on server page on
the the SharePoint Central Administration website. You can use the RoutingEnabled or ThrottlingEnabled
parameters of the Set-SPRequestManagementSettings Microsoft PowerShell cmdlet to change properties of
Request Manager.
NOTE: There is no user interface to configure properties of Request Manager. The Windows PowerShell cmdlet is
the only way to perform this task.
Request Manager has two supported deployment modes: Dedicated and Integrated.
Dedicated mode
A set of front-end web servers is dedicated to managing requests exclusively. The front-end web servers that are
dedicated to Request Manager are in their own farm that is located between the hardware load balancers (HLBs)
and the SharePoint farm. The HLBs send all requests to the Request Manager front-end web servers. Request
Manager that runs on these front-end web servers decides to which SharePoint front-end web servers it will send
the requests and then routes the requests. Depending on the routing and throttling rules, Request Manager might
ignore some requests without sending them to another server. The SharePoint front-end web servers do their
normal tasks in processing requests and then send responses back through the front-end web servers that run
Request Manager and to the clients.
Note that all farms are set up as SharePoint farms. All front-end web servers are SharePoint front-end web
servers, each of which can do the same work as any other. The difference between the farms is that the Request
Manager front-end web servers have Request Manager enabled.
Dedicated mode is good for larger-scale deployments when physical computers are readily available. The ability to
create a separate farm for Request manager provides two benefits: Request Manager and SharePoint processes do
not compete for resources and you can scale out one without having to also scale out the other. This allows you to
have more control over the performance of each role.
Request Manager and SharePoint processes do not compete for resources.
You can scale out each farm separately, which provides more control over the performance of each farm.
Integrated mode
In an integrated mode deployment, all SharePoint front-end web servers run Request Manager. Hardware load
balancers send requests to all front-end web servers. When a front-end web server receives a request, Request
Manager decides how to handle it: .
Allow it to be processed locally.
Route it to a different front-end web server.
Deny the request. Integrated mode is good for small-scale deployments when many physical computers are not
readily available. This mode lets Request Manager and the rest of SharePoint Server to run on all computers.
This mode is common for on-premises deployments.
Configuration
Request Manager has two configurable parts: General settings and Decision information. General settings are
parameters that make Request Manager ready to use, such as enabling or disabling Request Routing and Request
Throttling and Prioritizing. Decision information is all of the information that is used during the routing and
throttling processes, such as routing and throttling rules.
NOTE: You configure Request Manager on a farm and functionality occurs at a web application level in SharePoint
Server 2013 and the web application role in SharePoint Servers 2016 and 2019.
General settings
By default, request routing and request throttling and prioritizing are enabled. You use the Set-
SPRequestManagementSettings cmdlet to change the properties of request routing, request throttling and
prioritizing, and select a routing weight scheme.
The table describes the configuration situation and Windows PowerShell syntax to use.
SITUATION MICROSOFT POWERSHELL EXAMPLE
Enable routing and throttling for all web |Get-SPWebApplication | Set-

applications SPRequestManagementSettings –
RoutingEnabled $true –
ThrottlingEnabled $true
Enable routing with static weighting for Get-SPWebApplication | Get-

all web applications SPRequestManagementSettings |
Set-SPRequestManagementSettings –
RoutingEnabled $true –
ThrottlingEnabled $false –
RoutingWeightScheme Static
In some situations, multiple front-end web servers will be suitable destinations for a particular request. In this case,
by default, SharePoint Server selects one server randomly and uniformly. One routing weight scheme is static-
weighted routing. In this scheme, static weights are associated with front-end web servers so that Request
Manager always favors a higher static weight during the selection process. This scheme is useful to give added
weight to more powerful front-end web servers and produce less strain on less powerful ones. Each front-end web
server will have a static weight associated with it. The values of the weights are any integer value, where 1 is the
default. A value less than 1 represents lower weight, and greater than 1 represents higher weight.
Another weighting scheme is health-weighted. In health-weighted routing, front-end web servers that have health
scores closer to zero will be favored, and fewer requests will be sent to front-end web servers that have a higher
health score values. The health weights run from 0 to 10, where 0 is the healthiest and therefore will get the most
requests. By default, all front-end web servers are set to healthy, and therefore, will have equal weights.
SharePoint's health score based monitoring system assigns weight to server and send a health score value as a
header in the response to a request. Request Manager uses same health score and stores it in local memory.
Decision information
Decision information applies to routing targets, routing rules, and throttling rules.
Routing targets
Request routing determines the routing targets that are available when a routing pool is selected for a request. The
scope of routing targets is currently for front-end web servers only, but Request Manager’s design does not
exclude routing to application servers, too. A list of front-end web servers in a farm is automatically maintained by
using the configuration database. An administrator who wants to change that list, typically in dedicated mode, has
to use the appropriate routing cmdlets to get, add, set, and remove routing targets.
The following table describes the various routing target tasks and the associated Windows PowerShell syntax to
use.
TASK MICROSOFT POWERSHELL EXAMPLE
Return a list of routing targets for all Get-SPWebApplication | Get-

available web applications SPRequestManagementSettings |
Get-SPRoutingMachineInfo –
Availability Available
Add a new routing target for a specified $web=Get-SPWebApplication -

web application. Identity <URL of web application>
$rm=Get-
SPRequestManagementSettings -
Identity $web
Add-SPRoutingMachineInfo –
RequestManagementSettings $rm -
Name <MachineName> -Availability
Available
Edit an existing routing target’s $web=Get-SPWebApplication -

availability and static weight for a Identity <URL of web application>
specified web application.
$rm=Get-
Identity $web
$m=Get-SPRoutingMachineInfo -
Name <MachineName>
Set-SPRoutingMachineInfo -
Identity $m -Availability
Unavailable
Remove a routing target from a $web=Get-SPWebApplication -

specified web application. Identity <URL of web application>
$rm=Get-
Identity $web
$m=Get-SPRoutingMachineInfo -
Name <MachineName>
Remove-SPRoutingMachineInfo -
Identity $M
NOTE: You cannot remove front-end web servers that are in the farm. Instead, you can use the Availability
parameter of the Set-SPRoutingMachineInfo cmdlet to make them unavailable.
Routing and throttling rules
Request routing and request throttling and prioritizing are decision algorithms that use rules to prescribe many
actions. The rules determine how Request Manager handles requests.
Rules are separated into two categories, routing rules and throttling rules, which are used in request routing and
request throttling and prioritizing, respectively. Routing rules match criteria and route to a machine pool. Throttling
rules match criteria and throttle based on known health score of a computer.
Request Routing
Request processing is all operations that occur sequentially from the time that Request Manager receives a new
request to the time that Request Manager sends a response to the client.
Request processing is divided into the components:
request routing
incoming request handler
request throttling and prioritizing
request load balancing
Incoming request handler
The role of the incoming request handler is to determine whether Request Manager should process a request. If
request throttling and prioritizing is disabled and the Request Manager queue is empty, Request Manager directs
the request to SharePoint Server that is running on the current front-end web server. If request throttling and
prioritizing is enabled, request throttling and prioritizing determines whether the request should be allowed or
denied on the current front-end web server . The processes steps of the incoming request handler are as follows:
1. Request is determined if it should be throttled or routed
2. For routed requests, load balance algorithm is run
3. Request routed to load balancer endpoint
Request routing and Request throttling and prioritizing only run if it is enabled and is routed once per farm.
Request load balancer only runs if a request has been determined as routable. The outgoing request handler only
runs if the request has to be sent to a different front-end web server. The role of the outgoing request handler is to
send the request to the selected front-end web server, wait for a response, and send the response back to the
source.
Request routing
The role of request routing is to select a front-end web server to route a request. By using no routing rules that are
defined, the routing scheme is as easy as randomly selecting an available front-end web server.
The algorithm of request routing is defined by two parts: request-rule matching and front-end web server
selection.
Request rule matching
Every rule has one or more match criteria, which consist of three things: match property, match type, and match
value.
The following table describes the different types of match properties and match types:
MATCH PROPERTY MATCH TYPE
Hostname ReqEx
URL Equals
Port number Starts with
MIME type Ends with
For example, an administrator would use the following match criteria to match http://contoso requests: Match
Property=URL; Match value= http://contoso; Match type=RegEx.
Front-end web server selection
The front-end web server selection uses all routing rules, whether they match or do not match a given request.
Rules that match have machine pools, a request sends load balanced to any machine in any matching rule’s
machine pool. If a request does not match any request, it sends load balanced to any available routing target.
NOTE: For SharePoint Servers 2016 and 2019, the front-end role type is used.
Request routing and prioritizing
For routing requests that use the health-based monitoring system, the role of request routing and prioritizing is to
reduce the routing pool to computers that have a good health score to process requests. If request routing is
enabled, the routing pool is whichever front-end web server is selected. If request routing is disabled, the routing
pool only contains the current front-end web server.
Request routing and prioritizing can be divided into two parts: request-rule matching and front-end web server
filtering. Request-rule matching happens exactly like in request routing. Front-end web server filtering uses the
health threshold parameter from the throttling rules in combination with front-end web server health data to
determine whether the front-end web servers in the selected routing pool can process the given request.
The front-end web server filtering process follows these steps:
1. The routing pool is either the current front-end web server or one or more front-end web servers that request
routing selects.
2. All matching rules are checked to find the smallest health threshold value.
3. Remove front-end web servers in the routing pool that have health scores greater than or equal to the smallest
health threshold value.
For example, request routing is disabled and the current front-end web server has a health score of 7 and a rule
“Block OneNote” without a health threshold (that is, health threshold = 0) is created.
The routing pool is the current front-end web server that has a health threshold equal to zero (0). So, the smallest
threshold that the front-end web server can serve is zero. Because the current front-end web server has health
score of 7, Request Manager denies and removes the request.
Request load balancing
The role of request load balancing is to select a single target to which to send the request. Request load balancing
uses the routing weight schemes to select the target. All routing targets begin with a weight of 1. If static weighting
is enabled, request load balancing uses the static weights set of each routing target to adjust the weights and the
value can be valid integer number. If health weighting is enabled,request load balancing uses health information to
add weight to healthier targets and remove weight from less healthy targets.
Monitoring and maintenance

Monitoring and logging are keys to managing requests from Request Manager.
The rules that matched.
The rules that did not match.
The final decision of the request.
Decisions might include useful information such as the following.
Was the request denied?
Which front-end web server was selected and from which routing pool.
Did the request succeed or fail and why?
How long did each part, routing, throttling, and waiting for front-end web server to respond, take?
An administrator can use this information to adjust the routing and throttling rule sets to optimize the system and
correct problems. To help you monitor and evaluate your farm's performance, you can create a performance
monitor log file and add the following SharePoint Foundation Request Manager Performance counters:
COUNTER NAME DESCRIPTION
Connections Current The total number of

connections that are
currently open by Request
Manager.
Connections Reused / Sec The number of connections

per second that are reused
when the same client
connection makes another
request without closing the
connection.
Routed Requests / Sec The number of routed

requests per second. The
instance determines the
application pool and server
for which this counter tracks.
Throttled Requests / Sec The number of throttled

Failed Requests / Sec Ends with
MIME type The number of failed

Average Processing Time Ends with
MIME type The time to process the

request that is, the time to
evaluate all the rules and
determine a routing target.
Last Ping Latency The last ping latency (that is,

Request Manager's PING
feature) and the instance
determine which application
pool and machine target.
Connection Endpoints The total number of

Current endpoints that are
connected for all active
connections.
Routed Requests Current The number of unfinished

routed requests. The
instance determines which
application pool and
machine target.
Along with creating a performance monitor log file, the verbose logging level can be enabled by using the
following Microsoft PowerShell syntax:
Set-SPLogLevel “Request Management” –TraceSeverity Verbose
Global deployment of multiple farms (SharePoint
2013)

global deployment of multiple SharePoint 2013 farms.
Downloadable resources about global deployments of SharePoint

Server 2013
Download the following content for information about global deployments of SharePoint Server 2013.
CONTENT DESCRIPTION
SharePoint 2013 WAN testing with This PowerPoint presentation is a

Visual Studio 2012 walkthrough walkthrough that shows how to build a
web test and load test for WAN testing
that uses Visual Studio 2013.
Articles about global deployments of SharePoint Server 2013

The following articles about global deployments of SharePoint Server 2013 are available to view online. Writers
update articles on a continuing basis as new information becomes available and as users provide feedback.
** ** CONTENT DESCRIPTION
Global architectures for SharePoint Learn about supported architectures for

Server SharePoint Server 2013 in WAN
environments, strategies for optimizing
performance over WAN connections,
and recommendations for service
applications.
Testing WAN connections for Learn about WAN performance

SharePoint 2013 architectures improvements, test results, and WAN
test tools and scenarios.
Global architectures for SharePoint Server

SharePoint Server is optimized to perform well over wide-area network (WAN ) connections. For most customers, a
centralized environment is the recommended architecture for serving a world-wide user base. Customers who
have sites that are not well connected might benefit from deploying one or more regional farms. This article
describes supported architectures, strategies to optimize SharePoint Server for WAN connections, and
recommendations for service applications.
Key concepts
This article uses the following terms:
Central site—The location that hosts most of the company data and employee computers. A centralized
SharePoint Server environment can consist of a single farm or multiple farms located in the same
datacenter.
Regional site—A location that hosts a subset of corporate data and employee computers that are connected
by using a combination of local-area network (LAN ) and WAN links.
Distributed environment—An environment in which employees and company data are dispersed across the
globe.
In-country farm — A farm that is deployed inside a political boundary to satisfy government regulations.
Evaluate your WAN connections

The most important factor that drives architectures for WAN environments is the performance of SharePoint
Server across the WAN connections. Before you consider architecture options for your WAN environment, first
evaluate the performance that users will experience for the most common actions they will perform. This can be
done by using systematic benchmark testing across multiple WAN connections, or with simple user testing against
a test environment. You can also create an evaluation site in Office 365 within the same region as the main
company location, and test the user experience from multiple geographic locations.
If your organization currently deploys more than one farm geographically by using an earlier version of the
product, you might be able to succeed with either a single, central-farm environment or with fewer farms. Do not
assume that your organization will require the same number of farms as you deployed with an earlier version.
Optimize a central farm or central datacenter deployment

The first and best option to serve a world-wide user base is to deploy SharePoint Server to a central environment.
Due to the performance improvements in SharePoint Server global customers who are well connected with WAN
connections can expect to succeed with a centralized deployment of SharePoint Server. For enterprise-scale
customers, this might include more than one farm that is deployed to a single datacenter. Most customers can
deploy a single farm to meet the needs of an organization (for example, United Airlines). Organizations can also
use Office 365 as a central environment to serve a world-wide user base.
If you deploy SharePoint Server on premises, several strategies can help optimize a centralized environment across
WAN connections.
Optimize web pages for faster downloads
The default pages in SharePoint Server are optimized for performance. If you customize pages or add many
images or other types of content, make sure that you optimize these pages so they perform well over WAN
connections.
Windows Server features
Several features in Windows Server can improve performance for users who connect to a central environment
through a regional site or branch office.
BranchCache-- BranchCache, a feature of the Windows 7, Windows Server 2008 R2, and Windows Server
2012 operating systems, caches content from file and web servers on a WAN on computers at a local
branch office. In a geographically distributed SharePoint Server environment, BranchCache can optimize
WAN performance by caching large files that users download from SharePoint Server.
Quality of Service (QoS )— Windows 2000 introduced QoS features that Windows Server 2012 has
enhanced. QoS enables you to meet the service requirements of a workload or an application by measuring
network bandwidth, detecting changing network conditions (such as congestion or availability of
bandwidth), and prioritizing - or throttling - network traffic. For example, you can use QoS to prioritize
traffic for latency-sensitive applications and to control the effect of latency-insensitive traffic (such as bulk
data transfers). You can use QoS to prioritize requests for applications that are critical for users. In addition,
you can deprioritize applications or processes that adversely affect performance, such as backup processes
or large downloads. For more information about QoS features in Windows Server 2012, see Quality of
Service (QoS ) Overview.
WAN accelerators
WAN accelerators benefit intranet deployments. Some global companies position WAN accelerators across the
highest latency connections to improve performance at these sites to an acceptable range. These solutions typically
optimize traffic at several levels.
WAN acceleration solutions compress network-level packets and optimize the underlying protocol to reduce
the raw traffic.
WAN accelerators optimize content by comparing content blocks against a history of recently sent blocks,
which enables only differences to be sent instead of all the content.
Application-aware devices optimize the application-level protocol which reduces the application chatter.
Different solutions use different combinations of optimization techniques and algorithms.
WAN accelerators work in pairs. One device is in the data center next to the servers that are running SharePoint
Server, and another device is in the branch office or on a client device outside an office. Vendors claim 90% or
more reduction in response time for second and successive requests over high-latency networks.
Many WAN accelerator devices are available. Each device optimizes WAN traffic in different ways. Because
SharePoint Server also optimizes and compresses data, it is important to test the performance of SharePoint
Server both with and without WAN acceleration devices. In some cases, the compression of multiple technologies
(SharePoint Server, IIS, and a WAN accelerator) might adversely affect performance compared to the benefit
achieved.
Optimize the network
Many customers can make a centralized environment work by working with bandwidth providers to optimize the
network connections between users and a central site. Also, some telecommunications companies provide more
efficient routing patterns, especially in emerging markets. Compared to the complexity of managing SharePoint
farms and content at multiple locations, it might be more practical to optimize the WAN connections instead.
Client tools for WAN environments

Several client tools can greatly improve the user experience over WAN connections without deploying multiple
farms across the globe. You can also use these tools in environments that have multiple farms that are deployed
geographically.
Office Online Server
Office Online Server is an Office server product that delivers browser-based versions of Word, PowerPoint, Excel,
and OneNote. Office Online Server greatly improves performance in WAN environments because users don't
upload or download files. A single Office Online Server farm can support users who access Office files through
SharePoint Server 2016, Skype for Business Server 2015, and Exchange Server 2013. Office Online Server works
well in environments that have high-latency connections, or low bandwidth connections, or both. It might not work
well in environments that have intermittent connections.
A Office Online Server farm is typically located in the same datacenter as the SharePoint Server 2016 farm,
although this is not a requirement. Locating a Office Online Server farm in a remote datacenter where SharePoint
sites are not located will not improve performance. For more information, see Office Web Apps Server overview.
OneDrive for Business
OneDrive for Business lets users sync their My Site library or other SharePoint libraries on team sites to their
computers. They can then work with files in these libraries directly in Windows Explorer. Users can access these
files even when they are offline. Updates to files sync with SharePoint when a user is online.
OneDrive for Business works well in environments that have intermittent connections or in environments that
have high latency or low bandwidth connections. It is not intended to be used by many users who are editing the
same file offline at the same time. For more information see Sync your OneDrive or other SharePoint libraries to
your computer with OneDrive for Business.
NOTE
At this time, the OneDrive for Business next generation sync client is not available in SharePoint Server.
Design a central site with multiple farms

Some enterprises might choose to deploy more than one farm at a central site to meet scale and capacity
requirements. However, if the architecture includes more than one content farm, social features may be limited. To
optimize a multi-farm environment the following design principles apply:
The User Profile Service application must reside in the same datacenter as the content that it supports.
One My Site farm is recommended. Social features are limited across multiple My Site farms. For example,
users will see social activities in their My Site newsfeed from that farm alone. Multiple My Site farms also
require multiple User Profile service applications which increase complexity.
For social features to work across content farms, you must create a My Site Host on each content farm in
the datacenter. In this design, the My Site Host on the designated My Site farm, where the User Profile
Service application exists, is the primary My Site Host. The other My Site Hosts support site feeds on team
sites that are located in the content farms.
SharePoint Server supports stretched farm architectures in which servers are located in different
datacenters. For a stretched farm to work, there must be less than 1 millisecond latency between the
computer that is running SQL Server and the front-end web servers in one direction, and at least 1 gigabit
per second bandwidth.
Search farms can reside in a different datacenter. The Search service application works well over WAN
connections. If you have to spread farms across datacenters, a dedicated search farm does not have to be
located in the same datacenter as other types of SharePoint farms.
The following illustration represents a multi-farm architecture designed for a global manufacturing company that
is fictionally named Fabrikam and has more than 300,000 users.
Share service applications across farms connected by WAN links

You can share some service applications across farms. Most of these can be shared across farms separated by
WAN links. The following table summarizes the support for sharing service applications across WAN links. The
Search service application requires greater consideration and recommendation for this service are provided after
the table.
Cross-farm services support for WAN environments
SERVICE APPLICATION SUPPORTED OVER WAN CONNECTIONS? NOTES
Search Yes Content can be crawled over WAN

connections. Or, you can configure
search to retrieve results from remote
result sources (indexes at remote farms).
Managed Metadata Yes User entry fields that the Managed

Metadata service application provides
might not be available if a WAN
connection is not online (such as an
intermittent satellite link).
Business Data Connectivity Yes After the data model is cached on the
web server of the remote farm (the
farm that consumes the Business Data
Connectivity service from a central
farm), the remote farm connects directly
to the data source over the WAN to
query the data (instead of reconnecting
to the farm that is hosting the Business
Data Connectivity service). Therefore,
the remote farm requires permission to
access the data source. Also,
performance between the remote farm
and the data source depends on the
performance of the WAN connection.
User Profile Not supported Using the User Profile service

application across WAN links is not
supported. This service requires direct
database access.
Secure Store Service Yes Although the Secure Store Service

works across WAN links, we do not
recommend this use because it might
adversely affect the performance of
other services over a WAN link.
Machine Translation Service Yes
Search
You can share the Search service application across WAN connections. However, if a WAN connection is robust
enough to support crawling content over the WAN, the connection is likely robust enough to support user actions
over the WAN to a central farm. Instead of sharing the Search service application over WAN connections, we
recommend that you take advantage of WAN performance improvements by eliminating the regional farm and
having users use a central farm environment instead.
The following WAN conditions may be reasons for creating regional farms:
Highest latency connections
Intermittent connections
Unreliable connections caused by network congestion
Inefficient routing patterns
Packet loss
We do not recommend sharing the Search service application across these types of WAN connections. Instead, we
recommend that you configure Search on the regional farm and use Remote SharePoint result sources to bring
together search results from the regional farm(s) and the central farm.
In-country farms represent a different challenge. If the purpose of an in-country farm is to prevent documents and
files from residing in locations outside a political boundary, we do not recommend crawling content over the WAN.
A search index contains at least fragments of the crawled content. Furthermore, a temporary copy of each
document is downloaded to the search farm for processing. Therefore, a central farm that crawls an in-country
farm includes a copy of the data in that in-country farm. If this is against company policy, we recommend that you
use Remote SharePoint result sources instead. With this configuration, search results can include content from an
in-country farm and content continues to reside only on the local farm, unless a user downloads a copy to their
local computer.
The one scenario in which crawling content over WAN connections is allowed is with a hybrid deployment in which
an on-premises SharePoint Server farm is used to crawl content in an Office 365 Dedicated farm (O365-D ) and
provide search services to that farm. With the Office 365 Dedicated subscription plan each customer environment
is placed on a dedicated server farm. Crawling the Office 365 dedicated farm provides a single relevancy-ranked
set of results for the two environments. The dedicated Office 365 environment differs from the multi-tenant Office
365 environment. For hybrid environments that include the Office 365 multi-tenant environment, crawling the
multi-tenant environment is not possible and the recommendation is to provide centralized search by using remote
result sources.
Despite the recommendations, sharing the Search service application over WAN connections is supported and can
be implemented in the following ways:
A regional farm can consume the Search service application from a central farm and use it to crawl content
locally. You have to set up a cross-farm service sharing relationship and complete additional configuration.
In this case, the search components on the central farm crawl content on the regional farm. Communication
that is necessary to crawl content occurs over the WAN connection. This configuration is not recommended.
Instead, deploy and configure the Search service application directly on the regional farm.
A Search service application at a central farm can crawl content at a regional farm. This configuration does
not require you to set up cross-farm service sharing. Instead, crawl rules are added at the central farm to
crawl content at a remote farm. However, this configuration crawls content over the WAN connection, which
is not ideal.
The following table summarizes the differences between crawling over the WAN and using remote result sources
to include content in search results.
Options for including global content in search results
CONFIGURE A RESULT SOURCE FOR

CRAWL OVER THE WAN REMOTE FARMS
CONFIGURE A RESULT SOURCE FOR
CRAWL OVER THE WAN REMOTE FARMS
Description Content at regional sites is crawled from Search is configured to return results
the central site over the WAN. from one or more remote farms (result
source), in addition to the local farm.
In this scenario, remote farms are
crawled locally. You configure search at
the central farm to include results from
the remote indexes.
You can also configure the remote
farms to include results from the central
farm and other regional farms. This
allows users to search from the local
farm.
User experience Users are presented with a single list of Results are presented in in a single list.
results. However, the results are grouped in
blocks by result source. You can
configure the number of results within
each group.
Advantages Search results are contained in a single WAN crawling is not used.
search-ranked list. Search results are potentially fresher,
Search is managed centrally. based on the crawl schedule.
If you also configure remote farms to
include result sources for other farms,
enterprise-wide search is available from
remote farms in addition to the central
farm.
Disadvantages Crawling over the WAN takes time and Users see multiple groupings of results.
uses bandwidth. Search results are not ranked across the
Search results might not be as fresh as organization.
if the content were crawled locally. Search must be managed at multiple
Enterprise-wide search is available only locations.
from the central farm.
Testing WAN connections for SharePoint 2013
architectures

SharePoint Server 2013 is optimized to perform well over WAN connections. This article describes performance
improvements and methods for testing WAN connections to help you determine if you need to deploy more than
one farm geographically. It also includes example test results from companies that participated in the prerelease
program.
Key concepts
Bandwidth — The data transfer capacity, or speed of transmission, of a digital communications system as
measured in bits-per-second (bps).
Latency — The time that is required for a request to travel from one point on a network to another point.
Network congestion - The condition of a network when the current load approaches or exceeds the available
resources and bandwidth that are designed to handle that load at a particular location in the network. Packet
loss and delays are associated with congestion.
WAN performance improvements

SharePoint Server 2013 responds to incoming requests 50% faster the previous version. It utilizes available
bandwidth between the server and the client almost 40% more efficiently than the previous version. These
performance gains were quantified in Microsoft's environment with the busiest SharePoint farms in the world.
A Microsoft Office 365 environment demands higher levels of performance over WAN connections because many
customers are geographically distributed. As a result, Office 365 was extensively tested under WAN conditions.
Testing scenarios included latencies up to 300 milliseconds, which is much higher than latencies between the North
America and Asia.
To achieve up to 40% improvement in the use of available bandwidth (compared to the previous version),
optimizations were targeted to various layers of the network stack:
IIS compression and image compression are more effective on the server side.
Servers respond to http and https requests much faster.
Low -level TCP/IP optimizations result in better use of the communication ports that are open between the
client and the server. The ports ramp up quicker and are used more efficiently.
Users benefit not only from the performance gains but also from additional features that improve the experience:
Active download management and script on demand — these optimizations prioritize resources and
JavaScript to download the content that is most meaningful to users first.
Smooth page transitions with animations provide a rich, interactive browser experience.
Minimal download strategy — As users browse SharePoint content, only changes to a page are downloaded
and sent to the client.
WAN product-team test results
The following diagrams detail the effect of WAN performance optimizations on one of the most popular pages in
SharePoint — Teamsite. The diagrams show network traces of Teamsite for both SharePoint 2010 and SharePoint
Server 2013 with the following network conditions:
Approximately 300 ms latency roundtrip
1 mpbs bandwidth connection between the server and clients
These conditions represent higher latencies and lower bandwidths than are typical for global WAN connections.
However, some customers who have extremely remote sites find themselves within this range (for example,
mining, oil and gas, and global construction companies). 1 mpbs bandwidth connection is lower than a typical
mobile phone connection.
The following diagram demonstrates that SharePoint Server 2013 makes better use of available communication
ports.
In the two network traces, the horizontal rows represent the ports that are open. The colored blocks represent
content that is traveling over the wire, such as the images, JavaScript, and HTML. In the SharePoint 2010 network
trace, the white spaces between the colored blocks represent idle time in which the client or server is waiting for
something to happen before completing the next action. In the SharePoint Server 2013 network trace, the network
pipe is filled almost 100%. Communication between the client and server is ongoing until the transaction is
complete. There is very little or no idle time between actions. These improvements are provided by the
optimizations described earlier in this article (minimal download strategy, active download management, and script
on demand).
The following diagram calls attention to the improvement in bandwidth utilization. The blue graphs in both
network traces represent the bandwidth utilization. The use of available bandwidth is more efficient in SharePoint
Server 2013.
This following diagram of the network traces shows that the content that users interact with on the page (the
document library, prompts, navigational elements, etc.) are downloaded a full second faster in SharePoint Server
2013 compared to SharePoint 2010. Users can interact with the site much sooner.
Compared to SharePoint 2010, WAN optimizations in SharePoint Server 2013 achieve the following
improvements for this network scenario:
Downloads 65% fewer bytes for images because of better use of image compression.
Downloads 20% more bytes for the JavaScript which provides quicker and improved functionality in the
browser.
Downloads 15% fewer bytes total.
Simple WAN unit testing

The simplest method to test performance over WAN connections is to have a user at a remote location connect to a
SharePoint site and perform several user actions. For example, you can host an online meeting, talk the user
through the actions, and count the number of seconds for actions to be completed. Or, you can connect to a
computer remotely and perform the tasks.
For example, during the early adoption phase of SharePoint Server 2013, Microsoft worked with Teck to evaluate
WAN performance between the mining company's two datacenters in Santiago, Chile, and Calgary, Canada.
Mahmood Jaffer, IT Specialist and SharePoint Architect, created a remote connection from his Canadian office to
the datacenter in Santiago, Chile. From a computer in Santiago, he connected to a server running SharePoint
Server 2013 in the Calgary datacenter and uploaded several files. He also connected to a server running
SharePoint 2010 in Calgary and uploaded files that have the same characteristics. The following table records the
results.
Teck unit test — File upload from Santiago to Calgary (140ms latency) with Riverbed device
FILE SIZE AND TYPE SHAREPOINT 2010 SHAREPOINT 2013
1 mg pdf 5 seconds <1 second
10 mg .zip 25 seconds 12 seconds
An important consideration for this user test is the use of a WAN accelerator device between the two locations.
Teck uses a Riverbed device to accelerate traffic. WAN accelerators look for patterns within packets of data and
potentially only send packets that are unique, replacing duplicate packets with content that is cached on the other
end. For Teck to obtain accurate results, it was important to use files that have different content for each test,
instead of just renaming files.
To repeat this unit test, the Microsoft SharePoint writing team had colleagues in the Beijing office connect to
SharePoint sites in the Redmond office. In this scenario, two writers repeated the test multiple times throughout
the day and produced a range of results. Files with different content were used each time to avoid potential caching
issues, although a WAN accelerator device is not used between the two locations. The following table records the
results.
Microsoft writing team unit test — File upload from Beijing to Redmond (144ms latency)
FILE SIZE AND TYPE SHAREPOINT 2010 SHAREPOINT 2013
1 mg pdf 8-9 seconds 7-8 seconds
10 mg .zip 53-140 seconds 49-63 seconds
Several observations result from a comparison of these two sets of results:

Testing multiple times throughout a day or week will produce a range of results.
The range of results for SharePoint Server 2013 is narrower than the range of results for SharePoint 2010.
The result is in a more predictable experience with SharePoint.
Network environment characteristics can affect results more than latency. Both tests were conducted over
WAN connections with similar latencies. However, the results are slower for the WAN connection from
Beijing to Redmond. Network environment characteristics include routing patterns, network congestion,
packet loss, and other factors. Some global regions and international telecommunications companies are
less optimized for WAN traffic.
Simple unit testing can provide meaningful data. In these two cases, the real-world experience is unlikely to
be duplicated by plugging numbers for bandwidth and latency into a WAN simulation device.
Here are recommendations if you conduct your own simple unit testing:
Use different files that have different content to avoid optimization of WAN accelerator devices on second
upload.
Test multiples times throughout a day or week to capture results for different network loads.
Be aware that a file upload in SharePoint Server 2013 might be slower than in SharePoint 2010 due to the
new Efficient File I/O features. Efficient File I/O is a storage method in which a file is split into pieces that are
stored and updated separately, and streamed together when a user requests the file. As a result, the
performance of the first upload might be slower. Subsequent downloads and uploads of the file will be faster
as only the pieces that change are updated. However, you might see slower performance for SharePoint
Server 2013 when you test the versions side-by-side in or near the same location as the servers. The results
of the two unit tests described in this article demonstrate that the WAN optimizations in SharePoint Server
2013 more than offset the performance overhead of the Efficient File I/O feature for high latency
connections.
WAN test tools and scenarios for systematic testing

Before you begin any type of systematic load testing across a WAN environment make, sure that you understand
the nature of your network. You should have data about bandwidth, latency, network congestion, packet loss and
types of devices between users and the SharePoint front-end web server. This data is not always easy to obtain.
However tools, such as System Center Operations Manager, can make it easier.
After you understand the network environment, you'll know whether you must address items before you test over
the WAN. For initial testing, minimize network congestion and packet loss. Also remove or disable network
optimization devices. This will leave you with bandwidth and latency as the two primary factors that will impact
your end-users from a network perspective.
Test tools
After you address WAN constraints, you can start to use a combination of tools to testing WAN efficiency.
Prescriptive tools, such as Visual Studio 2012 Update 1, provide repeatable unit and load testing capabilities. Non-
prescriptive tools, such as Microsoft Network Monitor (Netmon) with Visual Round Trip Analyzer, provide end-
user oriented monitoring. Both types of tools can be useful because they each provide a different approach to
WAN testing and data collection. The combined results can provide a complete view of the impact of WAN
connections on user performance.
The following chart lists the strengths of both tools.
VISUAL STUDIO 2012 UPDATE 1 NETWORK MONITOR WITH VISUAL ROUND TRIP ANALYZER
Repeatable unit and load test capabilities End-user oriented monitoring (true end-user experience
Data capture across servers and load test agents capture)
Plug-ins to test SharePoint loads Network packet and port analysis
Export to Excel with Pivot capability Low barrier to entry (free and easy setup)
Real and simulated bandwidth and latency capability Real bandwidth, latency, congestion, packet loss and
optimization is reflected
Test scenarios
Create test scenarios that reflect the types of actions users will perform as part of their jobs. Common scenarios
Browse a team site
Fill out a form
Upload a document
Download a document
View a document in Office Web Apps Server
Edit a document in Office Online Server
Add a newsfeed post
Add a social tag
The goal is to have a well-rounded set of unit tests which capture actions that end-users perform in a SharePoint
environment and expose any potential latency-sensitive transactions.
Finally, make sure that you conduct rounds of tests at various times throughout the day to capture differences in
network utilization patterns. For example, 09:00 on Monday morning may have a very different network and
performance pattern compared to 23:00 on Friday. Also, be aware of events in other geographical regions, such as
a natural disaster that results in region-wide power outages, that might impact WAN routing or performance. A
comprehensive set of tests spread across different time intervals will provide insight and set expectations about
what your end-users will experience when they use SharePoint Server 2013 across the WAN.
Example WAN test using Visual Studio 2013
For an example test case, see SharePoint 2013 SharePoint 2013 WAN testing with Visual Studio 2012
walkthrough. This 3 megabyte Visio slide deck shows how to build a web test and load test for WAN testing that
uses Visual Studio 2013.
Example test results
Fabrikam is a fictional company that represents a large, world-wide manufacturing company that participated in
the SharePoint Server 2013 prerelease program. Fabrikam used Visual Studio to script a load test made up of
many unit tests and then ran the load test from multiple geographic locations.
In this first set of results, two users in the Fabrikam Shanghai, China, office ran the load test against the servers
running SharePoint Server 2013 in the Texas, USA datacenter. Latency is around 190 ms. The upload, download,
and Office Online Server tests were conducted with a 1 mb file.
Fabrikam — WAN performance across the feature set for Shanghai to Texas
The test results show that performance is good, especially for the social tasks.
The next set of results shows performance for the same load test across a larger set of geographic locations where
Fabrikam employees work. The SharePoint servers are located in Texas, USA.
Fabrikam — Results across the feature set for differentlocations
Even though there are varying degrees of latency, performance is good for users across the globe. The Fabrikam
test results provide an example of systematic WAN testing that uses a load test made up of many SharePoint tasks
that are important to the company.
Fabrikam is an example of a world-wide company that succeeds with a central datacenter model, instead of
deploying SharePoint Server 2013 to multiple regions across the world. If you plans include a move from a central
datacenter model to multiple SharePoint sites in different geographical regions, make sure that you conduct WAN
testing to see whether it is really necessary.
See also
Concepts
Global architectures for SharePoint 2013
SQL Server and storage (SharePoint Server)

The following articles provide information about SQL Server and storage configuration for SharePoint Server.
** CONTENT** DESCRIPTION
Overview of SQL Server in SharePoint Server 2016 and 2019 Describes the relationship between SharePoint Servers 2016
environments and 2019, the supported versions of SQL Server and how you
can interact with the databases.
Overview of SQL Server in a SharePoint Server 2013 Describes the relationship between SharePoint Server 2013
environment and supported versions of SQL Server and how you can
interact with the databases.
Deploy Azure SQL Managed Instance with SharePoint Server Describes how to deploy Azure SQL Managed Instance with
2016 and 2019 SharePoint Servers 2016 and 2019 that are hosted in
Microsoft Azure.
Storage and SQL Server capacity planning and configuration Describes a process for planning storage and SQL Server
(SharePoint Server) capacity for a SharePoint Server deployment.
Overview of SQL Server in SharePoint Server 2016
and 2019 environments

The minimum requirements for a database server in SharePoint Servers 2016 and 2019 are as follows:
64-bit edition of Microsoft SQL Server 2014 with Service Pack 1 (SP1)
NOTE
SQL Server Express is not supported with SharePoint Servers 2016 and 2019.
SQL Server 2017 on Linux is not supported with SharePoint Servers 2016 and 2019.
Depending on the installed version, you can use specific features of SQL Server, such as reporting and business
intelligence (BI with SharePoint Server 2016. For more information, see Hardware and software requirements for
SharePoint Server 2016 supports the following:
SQL Server 2016 Reporting Services (SSRS )
SQL Server 2016 Analysis Services (SSAS )
SharePoint Server 2019 supports the following:
SQL Server 2016 Reporting Services (SSRS )
SQL Server 2016 Analysis Services (SSAS )
NOTE
SQL Server Reporting Services integration with SharePoint Server 2019 is no longer supported. For more information, see
Reporting Services Report Server (SharePoint Mode) and Supported combinations of SharePoint and Reporting Services
server.
You can use the Report Viewer web part that has much of the same functionality as integrated mode. for more
information, see Add the Report Viewer web part to a web page and Report Viewer web part on a SharePoint site
- Reporting Services
NOTE
If you want to use Microsoft SQL Server Power Pivot for SharePoint or Microsoft Power View for SharePoint for BI solutions
you must install the Power Pivot or Power View add-ins for SQL Server 2016 RTM. The SQL Server 2014 (SP1) Power Pivot
for SharePoint and Power View for SharePoint BI solutions do not work with SharePoint Server 2016.
SharePoint Servers 2016 and 2019 and the SQL Server database
engine
The SharePoint Server 2016 application is built on the SQL Server database engine. Most content and settings in
SQL Server 2014 (SP1), SQL Server 2016, and SQL Server 2017 RTM are stored in relational databases. The
following table shows the databases that SharePoint Servers 2016 and 2019 use.
DATABASE TYPE DESCRIPTION
Configuration The Configuration database and Central Administration

content database are called configuration databases. They
contain data about farm settings such as the databases that
are 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
Data for apps for SharePoint
Data and objects for Project Server 2016
User names and permissions
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 Databases for service applications store the data that service
applications use.
For a full list of all of the databases that support SharePoint Servers 2016 and 2019, see Database types and
descriptions in SharePoint Server. The Quick reference guide: SharePoint Servers 2016 and 2019 Databases,
is available to download as either a PDF or Visio file.
Working with the SQL Server databases that support SharePoint

The databases that support SharePoint Server 2016 are either created automatically with the SharePoint Products
Configuration Wizard or manually by database administrators when they configure SharePoint Server.
Microsoft does not support directly querying or modifying the databases that support SharePoint Servers 2016
and 2019. In SharePoint Servers 2016 and 2019 the Usage and Health Data Collection database does support
schema modifications.
SharePoint Server 2019 does not support multi-tenancy so service application databases in partitioned mode
can’t be attached. Additionally, service applications databases in partitioned mode can’t be created from Central
Administration.
The SQL Server databases that support SharePoint Server 2016 are subject to sizing limitations and to
configuration recommendations that are not standard for SQL Server. For more information, see Storage and
SQL Server capacity planning and configuration (SharePoint Server).
SharePoint Server 2016 and SQL Server 2014 with Service Pack 1 (SP1)
SQL Server 2014 (SP1) provides greater performance, availability, and manageability with SharePoint Server
2016 than SQL Server 2014. While you can't use SQL Server Power Pivot for SharePoint or Power View for
SharePoint with SQL Server 2014 (SP1), you can use some business intelligence solutions with SharePoint Server
2016. For example, you can install Office Online Server to use Excel Online.
For more information, see Features Supported by the Editions of SQL Server 2014. For detailed information
about Office Online Server, see Configure Office Online Server for SharePoint Server 2016.
High Availability Solutions
We recommend AlwaysOn Availability Groups and AlwaysOn Failover Cluster Instances for high availability in
SQL Server 2014 Reporting Services (SP1). Other high availability solutions are database mirroring, and log
shipping. Both AlwaysOn Availability Groups and Failover Cluster Instances solutions require and use Windows
Server Failover Clustering (WSFC ).
NOTE
We recommend that you use AlwaysOn Availability Groups instead of database mirroring for your high availability solution
with SQL Server 2014 (SP1), SQL Server 2016, and SQL Server 2017 RTM for SharePoint Servers 2016 and 2019. For more
information, see Overview of SQL Server High-Availability Solutions.
For more information, see AlwaysOn Availability Groups (SQL Server), and Prerequisites, Restrictions, and
Recommendations for AlwaysOn Availability Groups (SQL Server).For information about high availability for SQL
Server Reporting Services, see High Availability (Reporting Services).
Log Shipping
SQL Server Log shipping provides a disaster recovery solution for single primary databases and multiple
secondary databases where each are located on separate instances of SQL Server. Log shipping backs up the
transaction log on the production server, copies the log to the backup or secondary instances, and is then available
to restore the log backup. You can then configure alerts to notify you when the production server fails. Then you
can fail over from the production server to the backup servers so if the production server fails one of the backup
or secondary servers can be brought online to act as the production server. For more information, see About Log
Shipping (SQL Server).
Reporting Services SharePoint mode
When you setup Reporting Services with SharePoint Server 2016 you create a report server. The report server is
the central component of Reporting Services. This component contains two processing engines and a set of unique
extensions that handle authentication, data processing, rendering, and delivery operations.
For more information, see Supported Combinations of SharePoint and Reporting Services Server and Add-in
(SQL Server 2016). The following levels of integration are provided when you run a report server in integrated
mode with SharePoint Server 2016.
Shared storage
Shared security
Same site access for all business documents such as reports, report models, and shared data sources
When Reporting Services runs in SharePoint integrated mode, both the SharePoint content and report server
databases store content and metadata. The following table shows the report server data that each database stores.
NAME OF DATABASE REPORT SERVER DATA
SharePoint content Primary storage for the following data:

Published reports
Report models
Shared data sources
Resources
Properties
Permissions
SharePoint configuration All report server configuration settings that you make in
Central Administration including:
Report server URL
Report server Reporting Services account information
Information about the authentication provider that is used on
the server
Site-level settings that limit or enable report history and
logging
Report server Internal copies of report content and metadata, which are also
stored in the SharePoint content database, and the following
report data:
Schedules
Subscriptions
Snapshots for report history or report execution
Report server Temp Temporary data, including the following:

Session data
Temporary snapshots created for subscription processing,
interactive reporting, or report caching as a performance
improvement
SharePoint mode in SQL Server 2016 is a SharePoint shared service that you configure in either the SharePoint
Central Administration website or by using Reporting Services SharePoint mode, Microsoft PowerShell cmdlets.
SharePoint mode supports SharePoint Server 2016 backup and restore for SQL Server Reporting Services service
application and Unified Logging Service (ULS ) trace logs. SharePoint mode also supports claims-based
authentication.
SharePoint mode requires that a report server component of Reporting Services must run within a SharePoint
Server farm. This means that a SharePoint application server must exist with the Reporting Services shared
service installed and at least one Reporting Services service application.
For more information, see Reporting Services Report Server (SharePoint Mode), Reporting Services Report
Server, and PowerShell cmdlets for Reporting Services SharePoint Mode.
SQL Server 2016
SQL Server 2016 provides business intelligence solutions for SharePoint Server 2016. The SharePoint mode of
SQL Server 2016 provides features for SQL Server Analysis Services and SQL Server Reporting Services. For
more information, see Features Supported by the Editions of SQL Server 2016.
When you install SQL Server 2016 Analysis Services (SSAS ) and SQL Server 2016 Reporting Services (SSRS ) in
a SharePoint Server 2016 farm the following business intelligence solutions are available:
SQL Server 2016 Power Pivot
SQL Server 2016 Power View
Reporting Services interactive report designer that runs on Power Pivot or Analysis Services tabular data
models
The following SharePoint Server 2016 business intelligence features are available when you upgrade to SQL
Server 2016 RTM:
Power Pivot Gallery
Workbooks as a Data Source
Power View reports
Power View Subscriptions
Report Alerting
For more information, see Supported Combinations of SharePoint and Reporting Services Server and Add-in
(SQL Server 2016) and Install SQL Server 2016 Business Intelligence Features.
Power Pivot for SharePoint
SQL Server 2016 RTM is required to deploy Power Pivot for SharePoint 2016. Power Pivot for SharePoint 2016 is
an add-in that is available in the SQL Server 2016 RTM Feature Pack. SQL Server 2016 Analysis Services must be
run in SharePoint mode. This provides a server that hosts Power Pivot data in a SharePoint farm. For more
information, see Install Analysis Services in Power Pivot Mode. The server that hosts Power Pivot for SharePoint
2016 can be outside a SharePoint Server 2016 farm.
SQL Server 2016 Analysis Services provides three modes for analysis, Multidimensional, Tabular, and Power Pivot
for SharePoint. Note that each server mode is independent of the others, and each supports a type of analytical
database that only runs in that modality. For more information about SQL Server 2016 Analysis Services, see
Analysis Services.
To configure Power Pivot for SharePoint you can use the Power Pivot for SharePoint 2013 Configuration tool, the
SharePoint Central Administration website, or Microsoft PowerShell cmdlets. The following table lists each
method and describes the process:
POWER PIVOT FOR SHAREPOINT CONFIGURATION METHOD DESCRIPTION
Power Pivot for SharePoint 2016 Configuration Tool Evaluates an existing installation and determines what needs
to be configured in the SharePoint farm and Power Pivot for
SharePoint and then configures everything required.
SharePoint Server 2016 Central Administration Central Administration provides the SQL Server Power Pivot
Service Application that you create to access the Power Pivot
Management Dashboard for your BI farm.
Microsoft PowerShell cmdlets Provides cmdlets that you can use to build PowerShell script
files (.ps1) and automate the configuration process for Power
Pivot for SharePoint.
Power View for SharePoint
Power View is a feature included with Microsoft SQL Server 2016 Reporting Services Add-in for Microsoft
SharePoint. Install SQL Server 2016 Reporting Services Add-in for SharePoint, and then configure the servers for
integration. When you deploy Power View for SharePoint you can create and interact with views of data from data
models that are based on Power Pivot workbooks that are published in a Power Pivot Gallery, or tabular models
that are deployed to SSAS. You can also create and view reports from SSRS on SharePoint document libraries. All
Power View reports provide multiple views that feature tiles, slicers, chart filters, and visualizations. For more
information, see What's New in Reporting Services (SSRS ).
See also
Other Resources
Supported Combinations of SharePoint and Reporting Services Server and Add-in (SQL Server 2016)
What's New in SQL Server 2016
Deprecated and Discontinued SQL Server Features in SQL Server 2016
What's New (Analysis Services)
Analysis Services
Features Supported by the Editions of SQL Server 2014
Deprecated Database Engine Features in SQL Server 2014
Deploy Azure SQL Managed Instance with

SharePoint Servers 2016 and 2019 now support Azure SQL Managed Instance (MI). SQL MI is a deployment
option of Azure SQL Database and is compatible with the current version of SQL Server (on-premises), Enterprise
Edition Database Engine.
IMPORTANT
SharePoint Server farms must be hosted in Microsoft Azure to support Azure SQL Managed Instance. The SharePoint Server
farm and the managed instance must be hosted in the same Azure region. SharePoint Server farms don't support managed
instances when hosted in customer datacenters.
Deploying a managed instance with SharePoint Server lets you move your SQL Server on-premises application to
the cloud with little or no application and database changes. The following procedure shows how to deploy an
Azure SQL Database Managed Instance with SharePoint Servers 2016 and 2019.
Environment
1. Create a resource group with a vNet and then create two subnets. You can use the SQL Managed Instance
Virtual Network Environment template to create an Azure Virtual Network with two subnets.
2. Create subnet 1 (Default) and then create two VMs. First, set up VM 1 as an Active Directory Directory
Services domain controller and configure your domain. For more information, see Step-By-Step: Setting up
Active Directory in Windows Server 2016.
3. Install SharePoint Server 2016 or SharePoint Server 2019 in VM 2:
Run PrerequitsiteInstaller.exe
Run Setup.exe
Install the May 2019 sts core patch for SharePoint Server 2016, KB 4464549 or SharePoint Server
2019, KB 4464556
Install the April 2019 wssloc MUI/language pack patch for SharePoint Server 2016, KB 4461507 or
for SharePoint Server 2019, KB 4462221
NOTE
You can join other VMs to Active Directory in subnet 1.
4. Create an Azure SQL Managed Instance in subnet 2, within this resource group (ManagedInstance).
IMPORTANT
No other resources can reside in subnet 2 except for SQL MI.
5. Create the SharePoint farm, hosting the databases on SQL MI with SQL authentication. Open the
SharePoint Management Shell and run the following Windows PowerShell commands:
$FarmCredential = Get-Credential -Message "Provide the user name and password for the SharePoint
farm service account."
$DBCredential = Get-Credential -Message "Provide the user name and password for the Azure SQL
Managed Instance database login."
$FarmPassphrase = Read-Host -AsSecureString -Prompt "Provide the SharePoint farm passphrase"
New-SPConfigurationDatabase -DatabaseServer <DBServer> -DatabaseName <ConfigDB> -FarmCredentials

$FarmCredential -DatabaseCredentials $DBCredential -Passphrase $FarmPassphrase -LocalServerRole
<ServerRole>
Where:
<DBServer> is the name you gave the Azure SQL Managed Instance in step 4.
<ConfigDB> is the name of the SharePoint configuration database to be created.
<ServerRole> is the SharePoint MinRole server role for this server in the SharePoint farm.
6. Run the SharePoint Products Configuration Wizard to complete the configuration. Next open Central
Administration to complete the Farm Configuration Wizard.
NOTE
Access Services isn't supported with Azure SQL Managed Instances.
See also
Other Resources
Azure SQL Database managed instance
SQL Server instance migration to Azure SQL Database managed instance
Quickstart: Create an Azure SQL Database managed instance
Quickstart: Configure Azure VM to connect to an Azure SQL Database Managed Instance
Quickstart: Restore a database to a Managed Instance
Overview of SQL Server in a SharePoint Server 2013
environment

SharePoint Server 2013 supports several versions of SQL Server. Depending on the installed version, you can use
specific features of SQL Server, such as reporting and business intelligence (BI).
NOTE
SharePoint Foundation 2013 does not support BI features, which require SharePoint Server 2013.
The minimum requirements for a database server in SharePoint Server 2013 are SQL Server 2008 R2 with
Service Pack 1 (SP1) or SQL Server 2012, or SQL Server 2014 64-bit versions. Note that to use the business
intelligence (BI) tools in SharePoint Server 2013 you must install SQL Server 2012 with Service Pack 1 (SP1) or
SQL Server 2014, 64-bit version. For more information, see Hardware and software requirements for SharePoint
Server 2016.
SharePoint Server 2013 and the SQL Server database engine

The SharePoint Server 2013 application is built on the SQL Server database engine. Most content and settings in
SQL Server 2008 R2 with Service Pack 1 (SP1), SQL Server 2012, and SQL Server 2014 are stored in relational
databases. The following table shows the databases that SharePoint Server 2013 uses.
DATABASE TYPE DESCRIPTION
Configuration The Configuration database and Central Administration

content database are called configuration databases. They
contain data about farm settings such as the databases that
are 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
Data for apps for SharePoint
User names and permissions
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 Databases for service applications store the data that service
applications use.
For a full list of all of the databases that support SharePoint Server, see Database types and descriptions in
SharePoint Server. For a graphical representation of the databases that support SharePoint Server 2013, see
Databases that support SharePoint 20113.
Working with the SQL Server databases that support SharePoint Server
2013
The databases that support SharePoint Server 2013 are either created automatically with the SharePoint Products
Configuration Wizard or by database administrators when they manually configure SharePoint Server 2013.
Microsoft does not support directly querying or modifying the databases that support SharePoint Server. In
SharePoint Server the Usage and Health Data Collection database does support schema modifications.
The SQL Server databases that support SharePoint Server 2013 are subject to sizing limitations and to
configuration recommendations that are not standard for SQL Server. For more information, see Storage and SQL
Server capacity planning and configuration (SharePoint Server).
SQL Server 2008 R2 with Service Pack 1 (SP1)

SQL Server 2008 R2 introduced Power Pivot for SharePoint and Power Pivot for Excel 2010 for SharePoint
business intelligence capability through integration with SharePoint Server 2010. Both SQL Server Analysis
Services and SQL Server Reporting Services can run in the same SharePoint Server farm. SQL Server 2008 R2
with Service Pack 1 (SP1) introduced various new features and fixed many SQL Server 2008 R2 issues. For more
information, see "1.0 What's New in Service Pack 1" in Microsoft SQL Server 2008 R2 SP1 Release Notes.
SQL Server Reporting Services in SharePoint Integrated Mode
SQL Server 2008 R2 Reporting Services supports two types of SharePoint integration. Full integration relies on
the SharePoint integrated mode. Partial integration relies on two Web Parts, Report Explorer and Report Viewer,
which you must install on a SharePoint site and point to a remote report server instance. For more information,
see Overview of Reporting Services and SharePoint Technology Integration and Planning for SharePoint
Integration.
NOTE
Reporting Services supports SharePoint integrated mode using SharePoint Server 2013 only.
When you setup Reporting Services with SharePoint Server 2013 you create a report server. The report server is
the central component of Reporting Services. This component contains two processing engines and a set of unique
extensions that handle authentication, data processing, rendering, and delivery operations.
NOTE
When you configure a report server to run with SharePoint Server 2013 in integrated mode you must install the SQL Server
2012 Reporting Services add-in or later on a SharePoint front-end web server. > SQL Server 2008 R2 is the minimum version
and is not supported when you use SQL Server 2012 Reporting Services or SQL Server 2014 Reporting Services.
For more information, see Supported Combinations of SharePoint and Reporting Services Components. The
following levels of integration are provided when you run a report server in integrated mode with SharePoint
Server 2013.
Shared storage
Shared security
Same site access for all business documents such as reports, report models, and shared data sources
When Reporting Services runs in SharePoint integrated mode, both the SharePoint content and report server
databases store content and metadata. The following table shows the report server data that each database stores.
NAME OF DATABASE REPORT SERVER DATA
SharePoint content Primary storage for the following data:

Published reports
Report models
Shared data sources
Resources
Properties
Permissions
SharePoint configuration All report server configuration settings that you make in
Central Administration including:
Report server URL
Report server Reporting Services account information
Information about the authentication provider that is used on
the server
Site-level settings that limit or enable report history and
logging
Report server Internal copies of report content and metadata, which are also
stored in the SharePoint content database, and the following
report data:
Schedules
Subscriptions
Snapshots for report history or report execution
Report server Temp Temporary data, including the following:

Session data
Temporary snapshots created for subscription processing,
interactive reporting, or report caching as a performance
improvement
Reporting Services data alerts are available to inform recipients of changes in report data.
For more information, see Storing and Synchronizing Report Server Content With SharePoint Databases
SQL Server 2012 and SQL Server 2014

SQL Server 2012 with SP1 and SQL Server 2014 provide business intelligence solutions for SharePoint Server
2013. The SharePoint mode of SQL Server 2012 provides features for SQL Server Analysis Services and SQL
Server Reporting Services. In addition, the SharePoint mode provides SQL Server BI features in SharePoint Server
2013. For more information, see Features Supported by the Editions of SQL Server 2012 and Features Supported
by the Editions of SQL Server 2014.
NOTE
SharePoint Foundation 2013 does not support SQL Server BI features.
High Availability Solutions

We recommend AlwaysOn Availability Groups for high availability in SQL Server 2012 Reporting Services and
SQL Server 2014 Reporting Services. Other high availability solutions are AlwaysOn Failover Cluster Instances,
database mirroring, and log shipping. Both AlwaysOn Availability Groups and Failover Cluster Instances solutions
require and use Windows Server Failover Clustering (WSFC ).
NOTE
We recommend that you use AlwaysOn Availability Groups instead of database mirroring for your high availability solution
with SQL Server 2012 or SQL Server 2014 and SharePoint Server 2013. For more information, see Overview of SQL Server
High-Availability Solutions.
For more information, see AlwaysOn Availability Groups (SQL Server), and Prerequisites, Restrictions, and
Recommendations for AlwaysOn Availability Groups (SQL Server).
Reporting Services SharePoint mode
SharePoint mode in SQL Server 2012 Reporting Services and SQL Server 2014 Reporting Services is a
SharePoint Server 2013 shared service that you configure in either the SharePoint Central Administration website
or by using Reporting Services SharePoint mode Microsoft PowerShell cmdlets. For more information, see
PowerShell cmdlets (Reporting Services SharePoint Mode). SharePoint mode supports SharePoint Server 2013
backup and restore for SQL Server Reporting Services service application and Unified Logging Service (ULS )
trace logs. SharePoint mode also supports claims-based authentication. For more information, see the "SharePoint
Mode" section of What's New (Reporting Services). For more information about the SharePoint Microsoft
PowerShell cmdlets for ULS, see Logging and events cmdlets in SharePoint 2013.
SharePoint mode requires that a report server component of Reporting Services must run within a SharePoint
Server farm. This means that a SharePoint application server must exist with the Reporting Services shared service
installed and at least one Reporting Services service application.
For more information, see Reporting Services Report Server (SSRS ) and Reporting Services Report Server
(SharePoint Mode).
Business intelligence features
NOTE
SharePoint Foundation 2013 does not support BI features, which require SharePoint Server 2013.
When you install SQL Server 2012 Analysis Services (SSAS ) and SQL Server 2012 Reporting Services (SSRS ) in
a SharePoint Server 2013 farm the following business intelligence features are enabled:
SQL Server 2012 Power Pivot for SharePoint 2013
Power View for SharePoint 2013
Reporting Services interactive report designer that runs on Power Pivot or Analysis Services tabular data
models
The xVelocity in-memory analytics engine in SQL Server 2012 supports both self-service BI and corporate BI. For
more information, see xVelocity in SQL Server 2012.
For more information, see Guidance for Using SQL Server BI Features in a SharePoint Farm, Install SQL Server BI
Features with SharePoint 2013 (SQL Server 2012 SP1), and Install SQL Server BI Features with SharePoint
(PowerPivot and Reporting Services).
Power Pivot for SharePoint 2013
SQL Server 2012 with SP1 is required to deploy Power Pivot for SharePoint 2013. Power Pivot for SharePoint
2013 is a SharePoint Server service application that becomes available when Analysis Services runs in SharePoint
mode. This provides a server that hosts Power Pivot data in a SharePoint farm. SQL Server 2012 Analysis Services
provides three modes for analysis, Multidimensional, Tabular, and Power Pivot for SharePoint. Note that each
server mode is independent of the others, and each supports a type of analytical database that only runs in that
modality. For more information about SQL Server 2012 Analysis Services (SSAS ), see Analysis Services. For more
information about SQL Server 2014 Analysis Services, see Analysis Services. The server that hosts Power Pivot
for SharePoint 2013 can be outside a SharePoint Server 2013 farm.
To configure Power Pivot for SharePoint you can use the SharePoint Central Administration website, the Power
Pivot for SharePoint 2013 Configuration tool, or Microsoft PowerShell cmdlets. The following table lists each
method and describes the process:
POWER PIVOT FOR SHAREPOINT CONFIGURATION METHOD DESCRIPTION
SharePoint Server 2013 Central Administration Provides all available options to configure the Power Pivot for
SharePoint service application.
Power Pivot for SharePoint 2013 Configuration Tool Evaluates an existing installation and determines what needs
to be configured in the SharePoint farm and Power Pivot for
SharePoint and then configures everything required.
Microsoft PowerShell cmdlets Provides cmdlets that you can use to build PowerShell script
files (.ps1) and automate the configuration process for Power
Pivot for SharePoint.
The Power Pivot for SharePoint 2013 add-in enables PowerPivot Gallery, Schedule Data Refresh, and the
PowerPivot Management Dashboard in Central Administration. For more information, see PowerPivot for
SharePoint (SSAS ).
See also
Other Resources
Supported Combinations of SharePoint and Reporting Services Components
What's New (Analysis Services)
Features Supported by the Editions of SQL Server 2014
Deprecated Database Engine Features in SQL Server 2014
Storage and SQL Server capacity planning and
configuration (SharePoint Server)

The capacity planning information that we provide contains guidelines to help you plan and configure the
storage and SQL Server database tier in a SharePoint Server environment. This information is based on
testing performed at Microsoft on live properties. However, your results may vary based on the equipment
you use and the features and functionality that you implement for your sites.
Although tests were not run on SQL Server 2014 (SP1), SQL Server 2016 , or SQL Server 2017 RTM you can
use these test results as a guide to help you plan for and configure the storage and SQL Server database tier
in SharePoint Server 2019, 2016, and 2019 environments. For training about how to configure and tune SQL
Server 2012, see SQL Server 2012 for SharePoint Server 2013. Note that the test results are the same as in
SharePoint 2013.
Because SharePoint Server often runs in environments in which databases are managed by separate SQL
Server database administrators, this document is intended for joint use by SharePoint Server farm
implementers and SQL Server database administrators. It assumes significant understanding of both
SharePoint Server and SQL Server.
This article assumes that you are familiar with the concepts that are presented in Capacity management and
sizing for SharePoint Server 2013.
Design and configuration process for SharePoint Servers 2016 and

2019 storage and database tier
We recommend that you break the storage and database tier design process into the following steps. These
sections provide detailed information about each design step, including storage requirements and best
practices:
1. Gather storage and SQL Server space and I/O requirements
2. Choose SQL Server version and edition
3. Design storage architecture based on capacity and I/O requirements
4. Estimate memory requirements
5. Understand network topology requirements
6. Configure SQL Server
7. Validate and monitor storage and SQL Server performance
Gather storage and SQL Server space and I/O requirements

Several SharePoint Server architectural factors influence storage design. The key factors are: the amount of
content, enabled features, deployed service applications, number of farms, and availability requirements.
Before you start to plan storage, you should understand the databases that SharePoint Server can use.
In this section:
Databases used by SharePoint Server
Understand SQL Server and IOPS
Estimate core storage and IOPS needs
Estimate service application storage needs and IOPS
Determine availability needs
Databases used by SharePoint Server
The databases that are installed with SharePoint Servers 2016 and 2019 depend on the service applications
that are used in the environment. All SharePoint Server environments rely on the SQL Server system
databases. This section provides a summary of the databases installed with SharePoint Servers 2016 and
2019. For detailed database information, see Database types and descriptions in SharePoint Server.
Some SharePoint Server, SQL Server Database Engine, and SQL Server Reporting Services (SSRS )
databases have specific location recommendations or requirements. For information about these database
locations, see Database types and descriptions in SharePoint Server. The Quick reference guide:
SharePoint Servers 2016 and 2019 Databases, is available to download as either a PDF or Visio file.
The following databases are the SharePoint Server system databases and are installed automatically.
Configuration
Central Administration content
Content (one or more)
The following list shows the SharePoint Server service applications that have databases:
App Management Service
Apps for SharePoint
Business Data Connectivity
Managed Metadata
PerformancePoint Services
Project Server (SharePoint Server 2013 only)
Search Service
Search Administration
Analytics Reporting
Crawl
Link
SharePoint Translation Service
SQL Server Power Pivot Service
State Service
Subscription Settings Service
Usage and Health data collection
User Profile Service
Profile
Social Tagging
Synchronization
The following list shows the SharePoint Foundation 2013 databases:
Configuration
Central Administration content
Content (one or more)
Search service application:
Analytics Reporting (one or more)
Crawl (one or more)
Link (one or more)
Subscription Settings Service Application (if enabled through Windows PowerShell)
Usage and Health Data Collection Service
Word Conversion Service
If you are integrating further with SQL Server, your environment may also include additional databases, as in
the following scenario. SQL Server Power Pivot for SharePoint can be used in a SharePoint Server 2016
environment only if you use SQL Server 2016 RTM Enterprise Edition and SQL Server 2016 SQL Server
Analysis Services (SSAS ). If in use, you must also plan to support the Power Pivot application database, and
the additional load on the system. For more information, download the new Deploying SQL Server 2016
PowerPivot and Power View in SharePoint 2016 white paper. For details about configuring and deploying
business intelligence in a multiple server SharePoint Server 2016 farm, download Deploying SQL Server
2016 PowerPivot and Power View in a Multi-Tier SharePoint 2016 Farm.
The SQL Server 2016 Reporting Services (SSRS ) add-in can be used with any SharePoint Server 2016
environment. If you are using the add-in, plan to support the two SQL Server Reporting Services databases
and the additional load that is required for SQL Server Reporting Services.
SQL Server 2012 Power Pivot for SharePoint 2013 can be used in a SharePoint 2013 environment that
includes SQL Server 2008 R2 Enterprise Edition and SQL Server Analysis Services. If in use, you must
also plan to support the Power Pivot application database, and the additional load on the system. For
more information, see Plan a PowerPivot deployment in a SharePoint farm and the SQL Server PRO
article Understanding PowerPivot and Power View in Microsoft Excel 2013.
The SQL Server 2008 R2 Reporting Services (SSRS ) plug-in can be used with any SharePoint 2013
environment. If you are using the plug-in, plan to support the two SQL Server 2008 R2 Reporting
Services databases and the additional load that is required for SQL Server 2008 R2 Reporting Services.
NOTE
SQL Server Reporting Services integration with SharePoint Server 2019 is no longer supported. For more information,
see Reporting Services Report Server (SharePoint Mode) and Supported combinations of SharePoint and Reporting
Services server.
Understand SQL Server and IOPS

On any server that hosts a SQL Server instance, it is very important that the server achieve the fastest
response possible from the I/O subsystem.
More and faster disks or arrays provide sufficient I/O operations per second (IOPS ) while maintaining low
latency and queuing on all disks.
You cannot add other types of resources, such as CPU or memory, to compensate for slow response from the
I/O subsystem. However, it can influence and cause issues throughout the farm. Plan for minimal latency
before deployment, and monitor your existing systems.
Before you deploy a new farm, we recommend that you benchmark the I/O subsystem by using the Diskspd
Utility . Note that this tool works on all Windows Server versions with all versions of SQL Server. For more
information, see Diskspd Utility: A Robust Storage Testing Tool.
Stress testing also provides valuable information for SQL Server. For information, see Storage Benchmarking
with DiskSpd.
For detailed information about how to analyze IOPS requirements from a SQL Server perspective, see
Analyzing I/O Characteristics and Sizing Storage Systems for SQL Server Database Applications.
Estimate core storage and IOPS needs
Configuration and content storage and IOPS are the base layer that you must plan for in every SharePoint
Server deployment.
Configuration storage and IOPS
Storage requirements for the Configuration database and the Central Administration content database are not
large. We recommend that you allocate 2 GB for the Configuration database and 1 GB for the Central
Administration content database. Over time, the Configuration database may grow beyond 1 GB. It does not
grow quickly — it grows by approximately 40 MB for each 50,000 site collections.
Transaction logs for the Configuration database can be large. Therefore, we recommend that you change the
recovery model for the database from full to simple.
NOTE
If you want to use SQL Server database mirroring to provide availability for the Configuration database, you must use
the full recovery model.
IOPS requirements for the Configuration database and Central Administration content database are minimal.
Content storage and IOPS
Estimating the storage and IOPS required for content databases is not a precise activity. In testing and
explaining the following information, we intend to help you derive estimates to use to determine the initial size
of your deployment. However, when your environment is running, we expect that you'll revisit your capacity
needs based on the data from your live environment.
For more information about our overall capacity planning methodology, see Capacity management and sizing
for SharePoint Server 2013.
Formula to estimate content database storage
The following process describes how to approximately estimate the storage required for content databases,
without considering log files:
1. Use the following formula to estimate the size of your content databases:
Database size = ((D × V ) × S ) + (10 KB × (L + ( V × D )))
NOTE
The value, 10 KB, in the formula is a constant that approximately estimates the amount of metadata required by
SharePoint Server. If your system requires significant use of metadata, you may want to increase this constant.
2. Calculate the expected number of documents. This value is known as D in the formula.
How you calculate the number of documents will be determined by the features that you are using. For
example, for My Sites or collaboration sites, we recommend that you calculate the expected number of
documents per user and multiply by the number of users. For records management or content
publishing sites, you may calculate the number of documents that are managed and generated by a
process.
If you are migrating from a current system, it may be easier to extrapolate your current growth rate and
usage. If you are creating a new system, review your existing file shares or other repositories and
estimate based on that usage rate.
3. Estimate the average size of the documents that you'll be storing. This value is known as S in the
formula. It may be worthwhile to estimate averages for different types or groups of sites. The average
file size for My Sites, media repositories, and different department portals can vary significantly.
4. Estimate the number of list items in the environment. This value is known as L in the formula.
List items are more difficult to estimate than documents. We generally use an estimate of three times
the number of documents (D ), but this will vary based on how you expect to use your sites.
5. Determine the approximate number of versions. Estimate the average number of versions any
document in a library will have. This value will usually be much lower than the maximum allowed
number of versions. This value is known as V in the formula.
The value of V must be above zero.
As an example, use this formula and the characteristics in the following table to estimate the required storage
space for data files in a content database for a collaboration environment. The result is that you need
approximately 105 GB.
INPUT VALUE
Number of documents (D) 200,000

Calculated by assuming 10,000 users times 20 documents
Average size of documents (S) 250 KB
List items (L) 600,000
Number of non-current versions (V) 2

Assuming that the maximum versions allowed is 10
Database size = (((200,000 x 2)) × 250) + ((10 KB × ( 600,000 + ( 200,000 x 2))) = 110,000,000 KB or 105 GB
NOTE
Efficient File I/O in SharePoint Server is a storage method in which a file is split into pieces that are stored and updated
separately. These pieces are streamed together when a user requests the file. This increases the I/O performance but it
normally does not increase the file size. However, small files can see a small increase in the disk storage that is required.
Features that influence the size of content databases

The following SharePoint Server features can significantly affect the size of content databases:
Recycle bins Until a document is fully deleted from both the first stage and second stage recycle bin, it
occupies space in a content database. Calculate how many documents are deleted each month to
determine the effect of recycle bins on the size of content databases.
Auditing Audit data can quickly compound and use large amounts of space in a content database,
especially if view auditing is turned on. Rather than letting audit data grow without constraint, we
recommend that you enable auditing only on the events that are important to meet regulatory needs or
internal controls. Use the following guidelines to estimate the space that you must reserve for auditing
data:
Estimate the number of new auditing entries for a site, and multiply this number by 2 KB (entries
generally are limited to 4 KB, with an average size of about 1 KB ).
Based on the space that you want to allocate, determine the number of days of audit logs you
want to keep.
NOTE
Office Online Server is the next version of Office Web Apps Server. Using Office Online Server with SharePoint Servers
2016 and 2019 doesn't affect the size of the content database. To deploy Office Online Server in your SharePoint Server
2016 farm, see Deploy Office Online Server.
Estimate content database IOPS requirements

IOPS requirements for content databases vary significantly based on how your environment is being used,
available disk space, and the number of servers that you have. In general, we recommend that you compare
the predicted workload in your environment to one of the solutions that we tested. For more information, see
Performance and capacity test results and recommendations (SharePoint Server 2013).
In tests, we found that the content databases tend to range from 0.05 IOPS/GB to around 0.2 IOPS/GB. We
also found that a best practice is to increase the top-end to 0.5 IOPS/GB. This is more than necessary and can
be much more than you'll need in your environment. Note that if you use mirroring, this results in much more
IO than the primary content databases. Simply be aware that the mirrored content databases are never
lightweight.
Estimate service application storage needs and IOPS
After you estimate content storage and IOPS needs, you must determine the storage and IOPS required by
the service applications that are being used in your environment.
SharePoint Server service application storage and IOPS requirements
To estimate the storage requirements for the service applications in the system, you must first be aware of the
service applications and how you'll use them. Service applications that are available in SharePoint Server
2016 and that have databases are listed in the following tables. The storage and IOPs data for all of the
service applications in SharePoint Servers 2016 and 2019 remains the same as in SharePoint Servers 2010
and 2013.
Search service application storage and IOPS requirements
DATABASE SCALING DISK IOPS DISK SIZE 10M ITEMS 100M ITEMS
Crawl One DB per Medium/High Medium 15GB 110GB

20M items 2GB log 50GB log
SQL IOPS: 10
per 1 DPS
Link One DB per Medium Medium 10GB 80GB

60M items 0.1GB log 5GB log
SQL IOPS: 10
per 1M items
Analytics Split when Medium Medium Usage Usage

Reporting reaching 100- dependent dependent
300GB
Search One DB Low Low 0.4GB 1GB data

Administration 1GB log 2GB log
Service application storage requirements and IOPS recommendations
SERVICE APPLICATION SIZE ESTIMATION RECOMMENDATION
User Profile The User Profile service application is associated with three
databases: Profile, Synchronization, and Social Tagging.
Note: The testing for the User Profile database storage
requirements and IOPS recommendations is not yet
complete. Check back for additional information.
For User Profile database information, see Database types
and descriptions in SharePoint Server.
Managed Metadata Service The Managed Metadata service application has one
database. The size of the database is affected by the
number of content types and keywords used in the system.
Many environments will include multiple instances of the
Managed Metadata service application.
Secure Store Service The size of the Secure Store service application database is
determined by the number of credentials in the store and
the number of entries in the audit table. We recommend
that you allocate 5 MB for each 1,000 credentials for it. It
has minimal IOPS.
State Service The State service application has one database. We

recommend that you allocate 1 GB for it. It has minimal
IOPS.
Word Automation Services The Word Automation service application has one
database. We recommend that you allocate 1 GB for it. It
has minimal IOPS.
PerformancePoint Services The PerformancePoint service application has one database.

We recommend that you allocate 1 GB for it. It has minimal
IOPS.
Business Data Connectivity service The Business Data Connectivity service application has one
database. This database is small and significant growth is
unlikely. It has minimal IOPS.
SERVICE APPLICATION SIZE ESTIMATION RECOMMENDATION
App Management The App Management service application has one

database. This database is small and significant growth is
unlikely. It has minimal IOPS.
Power Pivot The Power Pivot Service application has one database. This
database is small and has no significant I/O impact. We
recommend that you use the same IOPS as the SharePoint
content database. Note that content databases have
significantly higher I/O requirements than the Power Pivot
Determine availability needs

Availability is how much a SharePoint Server 2016 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 requirements can significantly increase your storage needs. For detailed information, see Create a
high availability architecture and strategy for SharePoint Server. Also, see the SQL Server 2012 white paper
AlwaysOn Architecture Guide: Building a High Availability and Disaster Recovery Solutions by Using
AlwaysOn Availability Groups.
Choose SQL Server version and edition

We recommend that for SharePoint Servers 2016 and 2019 you consider running your environment on the
Enterprise Edition of the following SQL Servers to take advantage of the additional performance, availability,
security, and management capabilities that these versions provide.
SQL Server 2014 with Service Pack 1 (SP1) (SharePoint Server 2016 only)
SQL Server 2016 (SharePoint Servers 2016 and 2019)
SQL Server 2017 RTM (SharePoint Servers 2016 and 2019)
For more information about the benefits of these versions, see Features Supported by the Editions of SQL
Server 2014, Editions and supported features of SQL Server 2016, and Editions and supported features of
SQL Server 2017.
We recommend that for SharePoint Server 2013 you consider running your environment on the Enterprise
Edition of SQL Server 2008 R2 with Service Pack 1 (SP1), SQL Server 2012, or SQL Server 2014 to take
advantage of the additional performance, availability, security, and management capabilities that these
versions provide. For more information about the benefits of SQL Server 2008 R2 with SP1, SQL Server
2012, and SQL Server 2014 Enterprise Edition, see Features Supported by the Editions of SQL Server 2014,
Features Supported by the Editions of SQL Server 2012, and Features Supported by the Editions of SQL
Server 2008 R2.
In particular, you should consider your need for the following features:
Backup compression Backup compression can speed up any SharePoint backup, and is available in
every edition of SQL Server 2008 and later. By setting the compression option in your backup script, or
by configuring the server that is running SQL Server to compress by default, you can significantly
reduce the size of your database backups and shipped logs. For more information, see Backup
Compression (SQL Server) for SQL Server 2014 and Backup Compression (SQL Server) for SQL
Server 2016 and SQL Server 2017 RTM.
NOTE
SQL Server data compression is not supported for SharePoint Server, except for the Search service application
databases.
Transparent data encryption If your security requirements include the need for transparent data
encryption, you must use SQL Server Enterprise Edition.
Content deployment If you plan to use the content deployment feature, consider SQL Server
Enterprise Edition so that the system can take advantage of database snapshots.
NOTE
If you are using a Remote BLOB storage provider that does not support database snapshots, you can't use
snapshots for content deployment or backup.
Remote BLOB storage If you want to take advantage of remote BLOB storage to a database or
location outside the files associated with each content database, you must use the Enterprise Edition of:
SQL Server 2016
SQL Server 2017 RTM
SQL Server 2014 (SP1)
SQL Server 2016
SQL Server 2017 RTM
SharePoint 2013
SQL Server 2008 R2 with SP1
SQL Server 2012 Enterprise Edition
Resource governor Resource Governor is a technology introduced in SQL Server 2008 to enable you
to manage SQL Server workloads and resources by specifying limits on resource consumption by
incoming requests. Resource Governor enables you to differentiate workloads and allocate CPU and
memory as they are requested, based on the limits that you specify. For more information about how to
use Resource Governor, see Resource Governor for SQL Server 2014 and Resource Governor for SQL
Servers 2016 and 2019.
We recommend that you use Resource Governor with SharePoint Server to:
Limit the amount of SQL Server resources that the web servers targeted by the search crawl
component consume. As a best practice, we recommend limiting the crawl component to 10
percent CPU when the system is under load.
Monitor how many resources are consumed by each database in the system — for example, you
can use Resource Governor to help you determine the best placement of databases among
computers that are running SQL Server.
Microsoft Power Pivot for SharePoint Enables users to share and collaborate on user-generated
data models and analysis in Excel on the web while automatically refreshing those analyses. You must
have Office on the web to use Excel on the web with Power Pivot for SharePoint and SharePoint Server
2016. You can use SQL Server 2014 (SP1) or SQL Server 2016 RTM Enterprise Edition and SQL
Server Analysis Services for business intelligence with SharePoint Server 2016. However, you can only
use Power Pivot for SharePoint with SQL Server 2016 RTM, not with SQL Server 2014 (SP1).
Power Pivot for SharePoint 2013 Enables users to share and collaborate on user-generated data
models and analysis in Excel and in the browser while automatically refreshing those analyses. It is part
of SQL Server 2008 R2 Analysis Services (SSAS ) Datacenter and Enterprise Edition, SQL Server 2012
SP1 Analysis Services (SSAS ) Enterprise Edition, and SQL Server 2014 Analysis Services (SSAS )
Enterprise and Business Intelligence Edition.
Design storage architecture based on capacity and I/O requirements

The storage architecture and disk types that you select for your environment can affect system performance.
In this section:
Choose a storage architecture
Choose disk types
Choose RAID types
Choose a storage architecture
SharePoint Server supports Direct Attached Storage (DAS ), Storage Area Network (SAN ), and Network
Attached Storage (NAS ) storage architectures, although NAS is only supported for use with content
databases that are configured to use remote BLOB storage. Your choice depends on factors within your
business solution and your existing infrastructure.
Any storage architecture must support your availability needs and perform adequately in IOPS and latency. To
be supported, the system must consistently return the first byte of data within 20 milliseconds (ms).
Direct Attached Storage (DAS)
DAS is a digital storage system that is directly attached to a server or workstation, without a storage network
in between. DAS physical disk types include Serial Attached SCSI (SAS ) and Serial Attached ATA (SATA).
In general, we recommend that you choose a DAS architecture when a shared storage platform can't
guarantee a response time of 20 ms and sufficient capacity for average and peak IOPS.
Storage Area Network (SAN)
SAN is an architecture to attach remote computer storage devices (such as disk arrays and tape libraries) to
servers in such a way that the devices appear as locally attached to the operating system (for example, block
storage).
In general, we recommend that you choose a SAN when the benefits of shared storage are important to your
organization.
The benefits of shared storage include the following:
Easier to reallocate disk storage between servers.
Can serve multiple servers.
No limitations on the number of disks that can be accessed.
Network Attached Storage (NAS)
A NAS unit is a self-contained computer that is connected to a network. Its sole purpose is to supply file-
based data storage services to other devices on the network. The operating system and other software on the
NAS unit provide the functionality of data storage, file systems, and access to files, and the management of
these functionalities (for example, file storage).
NOTE
NAS is only supported for use with content databases that are configured to use remote BLOB storage (RBS). Any
network storage architecture must respond to a ping within 1 ms and must return the first byte of data within 20 ms.
This restriction does not apply to the local SQL Server FILESTREAM provider, because it only stores data locally on the
same server.
NOTE
Some confusion exists about if you use the Internet Small Computer System Interface (iSCSI) and assume that it is a
NAS protocol. If you access this iSCSI storage through the Common Internet File System (CFIS), it is a NAS protocol. This
means that you can't use this storage with content databases if they aren't configured to use RBS. If however, you
access this iSCSI storage through a locally attached hard disk, it is considered a SAN architecture. This means that you
can use it with NAS.
Choose disk types

The disk types that you use in the system can affect reliability and performance. All else being equal, larger
drives increase mean seek time. SharePoint Server supports the following types of drives:
Small Computer System Interface (SCSI)
Serial Advanced Technology Attachment (SATA)
Serial-attached SCSI (SAS )
Fibre Channel (FC )
Integrated Device Electronics (IDE )
Solid State Drive (SSD ) or Flash Disk
For information about using solid state drives for storage in SQL Server, see the SQL Server PRO
article Using Solid State Disks in SQL Server Storage Solutions.
Choose RAID types
RAID (Redundant Array of Independent Disks) is often used to both improve the performance characteristics
of individual disks (by striping data across several disks) and to provide protection from individual disk
failures.
All RAID types are supported for SharePoint Server. However, we recommend that you use RAID 10 or a
vendor-specific RAID solution that has equivalent performance.
When you configure a RAID array, make sure that you align the file system to the offset that is supplied by the
vendor.
For more information about provisioning RAID for SQL Server, see RAID.
Estimate memory requirements

The memory that is required for SharePoint Server is directly related to the size of the content databases that
you are hosting on a server that is running SQL Server.
As you add service applications and features, your requirements are likely to increase. The following table
gives guidelines for how much memory we recommend.
COMBINED SIZE OF CONTENT DATABASES RAM RECOMMENDED FOR COMPUTER RUNNING SQL SERVER
Minimum for small production deployments 8 GB
Minimum for medium production deployments 16 GB
Recommendation for up to 2 terabytes 32 GB
Recommendation for the range of 2 terabytes to 5 64 GB

terabytes
Recommendation for more than 5 terabytes Additional RAM over 64 GB can improve SQL Server
caching speed
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 Server environment. For more information about SQL Server system requirements, see
Hardware and Software Requirements for Installing SQL Server 2014 and Hardware and Software Requirements for
Installing SQL Server for SQL Servers 2016 and 2017.
For information about SQL Server capacity limits and specifications see Compute Capacity Limits by Edition
of SQL Server and Maximum Capacity Specifications for SQL Server.
Other factors that may influence the memory that is required include the following:
The use of SQL Server mirroring.
The frequent use of files larger than 15 megabytes (MB ).
Understand network topology requirements

Plan the network connections within and between farms. We recommend that you use a network that has low
latency.
The following list provides some best practices and recommendations:
All servers in the farm should have LAN bandwidth and latency to the server that is running SQL
Server. Latency should be no greater than 1 millisecond.
We do not recommend a wide area network (WAN ) topology in which a server that is running SQL
Server is deployed remotely from other components of the farm over a network that has latency
greater than 1 ms., because this topology has not been tested.
Plan for an adequate WAN network if you plan to use SQL Server the AlwaysOn implementation suite,
mirroring, log shipping, or Failover Clustering to keep a remote site up-to-date.
We recommend that web servers and application servers have two network adapters: one network
adapter to handle user traffic and the other to handle communication with the servers that are running
SQL Server.
NOTE
If you use iSCSI, make sure each network adapter is dedicated to either network communication or iSCI, not
both.
Configure SQL Server
The following sections describe how to plan to configure SQL Server for SharePoint Server.
In this section:
Estimate how many servers are required
Configure storage and memory
Set SQL Server options
Configure databases
Estimate how many servers are required
In general, SharePoint Server is designed to take advantage of SQL Server scale out. For example, SharePoint
Server may perform better with many medium-size servers that are running SQL Server than with only
several large servers.
Always put SQL Server on a dedicated server that is not running any other farm roles or hosting databases
for any other application. The only exception to this recommendation is if you deploy the system on a stand-
alone server for a development or a non-performance oriented test environment. Although SQL Server can
run on the same server as SharePoint, we recommend running SQL Server on a separate server for better
performance.
The following is general guidance for when to deploy an additional server that will run a SQL Server instance:
Add an additional database server when you have more than four web servers that are running at
capacity.
Add an additional database server when your current server has reached its effective resource limits of
RAM, CPU, disk IO throughput, disk capacity, or network throughput.
For more information, see Compute Capacity Limits by Edition of SQL Server and Maximum Capacity
Specifications for SQL Server.
To promote secure credential storage when you are running the Secure Store service application, we
recommend that the Secure Store database be hosted on a separate database instance where access is limited
to one administrator.
Configure storage and memory
On the server that is running SQL Server, we recommend that the L2 cache per CPU have a minimum of 2
MB to improve memory.
Follow vendor storage configuration recommendations
For optimal performance when you configure a physical storage array, adhere to the hardware configuration
recommendations supplied by the storage vendor instead of relying on the default values of the operating
system.
If you do not have guidance from your vendor, we recommend using the PowerShell storage cmdlets that are
available for Windows Server 2012 R2. For more information, see Storage Cmdlets in Windows PowerShell.
Provide as many resources as possible
Ensure that the SQL Server I/O channels to the disks are not shared by other applications, such as the paging
file and Internet Information Services (IIS ) logs.
Provide as much bus bandwidth as possible. Greater bus bandwidth helps improve reliability and
performance. Consider that the disk is not the only user of bus bandwidth — for example, you must also
account for network access.
Set SQL Server options
The following SQL Server settings and options should be configured before you deploy SharePoint Server.
Do not enable auto-create statistics on a server that hosts SQL Server and supports SharePoint Server.
SharePoint Server configures the required settings upon provisioning and upgrade. Auto-create
statistics can significantly change the execution plan of a query from one instance of SQL Server to
another instance of SQL Server. Therefore, to provide consistent support for all customers, SharePoint
Server provides coded hints for queries as needed to provide the best performance across all scenarios.
To ensure optimal performance, we strongly recommend that you set max degree of parallelism
(MAXDOP ) to 1 SQL Server instances that host SharePoint Server databases. For more information
about how to set max degree of parallelism, see Configure the max degree of parallelism Server
Configuration Option.
Configure databases
The following guidance describes best practices to plan for as you configure each database in your
environment.
Separate and prioritize your data among disks
Ideally, you should place the tempdb database, content databases, Usage database, search databases, and SQL
Server 2014 (SP1), SQL Server 2016, SQL Server 2017 RTM, SQL Server 2008 R2 with SP1 and SQL Server
2012 transaction logs on separate physical hard disks.
The following list provides some best practices and recommendations for prioritizing data:
When you prioritize data among faster disks, use the following ranking:
Tempdb data files and transaction logs
Database transaction log files
Search databases, except for the Search administration database
Database data files
In a heavily read-oriented portal site, prioritize data over logs.
Testing and customer data show that SharePoint Server farm performance can be significantly impeded
by insufficient disk I/O for tempdb. To avoid this issue, allocate dedicated disks for tempdb. If a high
workload is projected or monitored — that is, the average read action or the average write action
requires more than 20 ms — you might have to ease the bottleneck by either separating the files across
disks or by replacing the disks with faster disks.
For best performance, place the tempdb on a RAID 10 array. The number of tempdb data files should
equal the number of core CPUs, and the tempdb data files should be set at an equal size. Count dual
core processors as two CPUs for this purpose. Count each processor that supports hyper-threading as
a single CPU. For more information, see Optimizing tempdb Performance.
Separate database data and transaction log files across different disks. If files must share disks because
the files are too small to warrant a whole disk or stripe, or you have a shortage of disk space, put files
that have different usage patterns on the same disk to minimize concurrent access requests.
Consult your storage hardware vendor for information about how to configure all logs and the search
databases for write optimization for your particular storage solution.
Use multiple data files for content databases
Follow these recommendations for best performance:
Only create files in the primary filegroup for the database.
Distribute the files across separate disks.
The number of data files should be less than or equal to the number of core CPUs. Count dual core
processors as two CPUs for this purpose. Count each processor that supports hyper-threading as a
single CPU.
Create data files of equal size.
IMPORTANT
Although you can use the backup and recovery tools that are built in to SharePoint Server to back up and recover
multiple data files, if you overwrite in the same location, the tools can't restore multiple data files to a different location.
For this reason, we strongly recommend that when you use multiple data files for a content database, you use SQL
Server backup and recovery tools. For more information about how to back up and recover SharePoint Server, see Plan
for backup and recovery in SharePoint Server.
For more information about how to create and manage filegroups, see Physical Database Files and
Filegroups.
Limit content database size to improve manageability
Plan for database sizing that will improve manageability, performance, and ease of upgrade for your
environment.
To help ensure system performance, we recommended that you limit the size of content databases to 200 GB,
except when specific usage scenarios and conditions support larger sizes. For more information about content
database size limits, see the "Content database limits" section in Software boundaries and limits for
We generally recommend that a site collection should not exceed 100 GB unless it is the only site collection in
the database so that you can use the SharePoint Server granular backup tools to move a site collection to
another database if you need to.
Proactively manage the growth of data and log files
We recommend that you proactively manage the growth of data and log files by considering the following
recommendations:
As much as possible, pre-grow all data and log files to their expected final size.
We recommend that you enable autogrowth for safety reasons. Do not rely on the default autogrowth
settings. Consider the following guidelines when you configure autogrowth:
When you plan content databases that exceed the recommended size (200 GB ), set the database
autogrowth value to a fixed number of megabytes instead of to a percentage. This will reduce
the frequency with which SQL Server increases the size of a file. Increasing file size is a blocking
action that involves filling the new space with empty pages.
If the calculated size of the content database is not expected to reach the recommended
maximum size of 200 GB within the next year, set it to the maximum size the database is
predicted to reach in a year — with 20 percent additional margin for error — by using the
ALTER DATABASE MAXSIZE property. Periodically review this setting to make sure that it is
still an appropriate value, depending on past growth rates.
Maintain a level of at least 25 percent available space across disks to allow for growth and peak usage
patterns. If you are managing growth by adding disks to a RAID array or allocating more storage,
monitor disk size closely to avoid running out of space.
Validate and monitor storage and SQL Server performance

Test that your performance and backup solution on your hardware enables you to meet your service level
agreements (SLAs). In particular, test the I/O subsystem of the computer that is running SQL Server to make
sure that performance is satisfactory.
Test the backup solution that you are using to make sure that it can back up the system within the available
maintenance window. If the backup solution can't meet the SLAs your business requires, consider using an
incremental backup solution such as Microsoft System Center Data Protection Manager.
It is important to track the following resource components of a server that is running SQL Server: CPU,
memory, cache/hit ratio, and I/O subsystem. When one or more of the components seems slow or
overburdened, analyze the appropriate strategy based on the current and projected workload. For more
information, see Monitor and Tune for Performance for SQL Server 2014 (SP1) and Monitor and Tune for
Performance for SQL Server 2016 and SQL Server 2017 RTM.
The following section lists the performance counters that we recommend that you use to monitor the
performance of the SQL Server databases that are running in your SharePoint Server environment. Also
listed are approximate healthy values for each counter.
For details about how to monitor performance and use performance counters, see Windows Performance
Monitor and Monitoring Performance.
SQL Server counters to monitor
Monitor the following SQL Server counters to ensure the health of your servers:
General statistics This object provides counters to monitor general server-wide activity, such as the
number of current connections and the number of users connecting and disconnecting per second from
computers that are running an instance of SQL Server. Consider monitoring the following counter:
User connections This counter shows the number of user connections on your computer that is
running SQL Server. If you see this number increase by 500 percent from your baseline, you may
see a performance reduction.
Databases This object provides counters to monitor bulk copy operations, backup and restore
throughput, and transaction log activities. Monitor transactions and the transaction log to determine
how much user activity is occurring in the database and how full the transaction log is becoming. The
amount of user activity can determine the performance of the database and affect log size, locking, and
replication. Monitoring low -level log activity to gauge user activity and resource usage can help you
identify performance bottlenecks. Consider monitoring the following counter:
Transactions/sec This counter shows the number of transactions on a given database or on the
entire server per second. This number is more for your baseline and to help you troubleshoot issues.
Locks This object provides information about SQL Server locks on individual resource types. Consider
monitoring the following counters:
Average Wait Time (ms) This counter shows the average amount of wait time for each lock
request that resulted in a wait.
Lock Wait Time (ms) This counter shows the wait time for locks in the last second.
Lock waits/sec This counter shows the number of locks per second that couldn't be satisfied
immediately and had to wait for resources.
Number of deadlocks/sec This counter shows the number of deadlocks on the computer that
is running SQL Server per second. This should not increase above 0.
Latches This object provides counters to monitor internal SQL Server resource locks called latches.
Monitoring the latches to determine user activity and resource usage can help you identify
performance bottlenecks. Consider monitoring the following counters:
Average Latch Wait Time (ms) This counter shows the average latch wait time for latch
requests that had to wait.
Latch Waits/sec This counter shows the number of latch requests that couldn't be granted
immediately.
SQL Statistics This object provides counters to monitor compilation and the type of requests sent to
an instance of SQL Server. Monitoring the number of query compilations and recompilations and the
number of batches received by an instance of SQL Server gives you an indication of how quickly SQL
Server is processing user queries and how effectively the query optimizer is processing the queries.
Consider monitoring the following counters:
SQL Compilations/sec This counter indicates the number of times the compile code path is
entered per second.
SQL Re-Compilations/sec This counter indicates the number statement recompiles per
second.
Buffer Manager This object provides counters to monitor how SQL Server uses memory to store data
pages, internal data structures, and the procedure cache, and also counters to monitor the physical I/O
as SQL Server reads and writes database pages. Consider monitoring the following counter:
Buffer Cache Hit Ratio
This counter shows the percentage of pages that were found in the buffer cache without having
to read from disk. The ratio is the total number of cache hits divided by the total number of
cache lookups over the last few thousand page accesses. Because reading from the cache is
much less expensive than reading from disk, you want this ratio to be high. Generally, you can
increase the buffer cache hit ratio by increasing the memory available to SQL Server.
Plan Cache This object provides counters to monitor how SQL Server uses memory to store objects
such as stored procedures, unprepared and prepared Transact-SQL statements, and triggers. Consider
monitoring the following counter:
Cache Hit Ratio
This counter indicates the ratio between cache hits and lookups for plans.
Physical server counters to monitor
Monitor the following counters to ensure the health of your computers that are running SQL Server:
Processor: % Processor Time: _Total This counter shows the percentage of time that the processor is
executing application or operating system processes other than Idle. On the computer that is running
SQL Server, this counter should be kept between 50 percent and 75 percent. In case of constant
overloading, investigate whether there is abnormal process activity or if the server needs additional
CPUs.
System: Processor Queue Length This counter shows the number of threads in the processor queue.
Monitor this counter to make sure that it remains less than two times the number of core CPUs.
Memory: Available Mbytes This counter shows the physical memory, in megabytes, available to
processes running on the computer. Monitor this counter to make sure that you maintain a level of at
least 20 percent of the total available physical RAM.
Memory: Pages/sec This counter shows the rate at which pages are read from or written to disk to
resolve hard page faults. Monitor this counter to make sure that it remains under 100.
For more information and memory troubleshooting methods, see the following resources:
SQL Server 2014 (SP1) -Monitor Memory Usage
Monitor Disk Usage
Monitor CPU Usage
SQL Server 2016 & SQL Server 2017 -Monitor Memory Usage
Monitor Disk Usage
Monitor CPU Usage
For more information and memory troubleshooting methods, see Monitoring Memory Usage for SQL Server
2008 R2 with SP1, Monitoring Memory Usage for SQL Server 2012, and Monitor Memory Usage for SQL
Server 2014.
Disk counters to monitor
Monitor the following counters to ensure the health of disks. Note that the following values represent values
measured over time — not values that occur during a sudden spike and not values that are based on a single
measurement.
Physical Disk: % Disk Time: DataDrive This counter shows the percentage of elapsed time that the
selected disk drive is busy servicing read or write requests-it is a general indicator of how busy the disk
is. If the PhysicalDisk: % Disk Time counter is high (more than 90 percent), check the PhysicalDisk:
Current Disk Queue Length counter to see how many system requests are waiting for disk access.
The number of waiting I/O requests should be sustained at no more than 1.5 to 2 times the number of
spindles that make up the physical disk.
Logical Disk: Disk Transfers/sec This counter shows the rate at which read and write operations are
performed on the disk. Use this counter to monitor growth trends and forecast appropriately.
Logical Disk: Disk Read Bytes/sec and Logical Disk: Disk Write Bytes/sec These counters show
the rate at which bytes are transferred from the disk during read or write operations.
Logical Disk: Avg. Disk Bytes/Read This counter shows the average number of bytes transferred
from the disk during read operations. This value can reflect disk latency — larger read operations can
result in slightly increased latency.
Logical Disk: Avg. Disk Bytes/Write This counter shows the average number of bytes transferred to
the disk during write operations. This value can reflect disk latency — larger write operations can result
in slightly increased latency.
Logical Disk: Current Disk Queue Length This counter shows the number of requests outstanding
on the disk at the time that the performance data is collected. For this counter, lower values are better.
Values greater than 2 per disk may indicate a bottleneck and should be investigated. This means that a
value of up to 8 may be acceptable for a logical unit (LUN ) made up of 4 disks. Bottlenecks can create a
backlog that can spread beyond the current server that is accessing the disk and result in long wait
times for users. Possible solutions to a bottleneck are to add more disks to the RAID array, replace
existing disks with faster disks, or move some data to other disks.
Logical Disk: Avg. Disk Queue Length This counter shows the average number of both read and
write requests that were queued for the selected disk during the sample interval. The rule is that there
should be two or fewer outstanding read and write requests per spindle. But this can be difficult to
measure because of storage virtualization and differences in RAID levels between configurations. Look
for larger than average disk queue lengths in combination with larger than average disk latencies. This
combination can indicate that the storage array cache is being overused or that spindle sharing with
other applications is affecting performance.
Logical Disk: Avg. Disk sec/Read and Logical Disk: Avg. Disk sec/Write These counters show the
average time, in seconds, of a read or write operation to the disk. Monitor these counters to make sure
that they remain below 85 percent of the disk capacity. Disk access time increases exponentially if read
or write operations are more than 85 percent of disk capacity. To determine the specific capacity for
your hardware, refer to the vendor documentation or use the Diskspd Utility, storage testing tool to
calculate it. For more information, see Diskspd: A Robust Storage Performance Tool.
Logical Disk: Avg. Disk sec/Read This counter shows the average time, in seconds, of a read
operation from the disk. On a well-tuned system, ideal values are from 1 through 5 ms for logs
(ideally 1 ms on a cached array), and from 4 through 20 ms for data (ideally less than 10 ms).
Higher latencies can occur during peak times. However, if high values occur regularly, you
should investigate the cause.
Logical Disk: Avg. Disk sec/Write This counter shows the average time, in seconds, of a write
operation to the disk. On a well-tuned system, ideal values are from 1 through 5 ms for logs
(ideally 1 ms on a cached array), and from 4 through 20 ms for data (ideally less than 10 ms).
Higher latencies can occur during peak times. However, if high values occur regularly, you
should investigate the cause.
When you are using RAID configurations with the Logical Disk: Avg. Disk Bytes/Read or
Logical Disk: Avg. Disk Bytes/Write counters, use the formulas listed in the following table to
determine the rate of input and output on the disk.
RAID LEVEL FORMULA
RAID 0 I/Os per disk = (reads + writes) / number of disks
RAID 1 I/Os per disk = [reads + (2 × writes)] / 2
RAID 5 I/Os per disk = [reads + (4 × writes)] / number of disks
RAID 10 I/Os per disk = [reads + (2 × writes)] / number of disks
For example, if you have a RAID 1 system that has two physical disks, and your counters are at the values that
are shown in the following table.
COUNTER VALUE
Avg. Disk sec/Read 80
Logical Disk: Avg. Disk sec/Write 70
Avg. Disk Queue Length 5
The I/O value per disk can be calculated as follows: (80 + (2 × 70))/2 = 110
The disk queue length can be calculated as follows: 5/2 = 2.5
In this situation, you have a borderline I/O bottleneck.
Other monitoring tools
You can also monitor disk latency and analyze trends by using the sys.dm_io_virtual_file_stats dynamic
management view in SQL Server 2008. For more information, see sys.dm_io_virtual_file_stats (Transact-SQL ) .
SQL Server 2012 for SharePoint Server 2013
Thanks to Bill Baer, Microsoft Senior Product Marketing Manager and Brian Alderman, CEO and Founder of
MicroTechPoint for providing a series of online SQL Server 2012 training modules. Special thanks to Channel
9 Microsoft for hosting these online training modules. The following training modules provide details about
SQL Server 2012 database settings to help you learn how to improve SharePoint Server 2016 performance,
availability, and security.
Tuning SQL Server 2012 for SharePoint 2013: (01) Key SQL Server and SharePoint Server Integration
Tuning SQL Server 2012 for SharePoint 2013: (02) Best Practices for SQL Server Database Settings
Tuning SQL Server 2012 for SharePoint 2013: (03) Server Settings for SQL Server
Tuning SQL Server 2012 for SharePoint 2013: (04) SQL Server and SharePoint Availability
See also
Concepts
Best practices for SQL Server in a SharePoint Server farm
Capacity management and sizing for SharePoint Server 2013
Other Resources
Overview of SQL Server in a SharePoint Server 2013 environment
Manage databases in SharePoint Server

The following articles and related resources provide information about database management with SharePoint
Server.
CONTENT DESCRIPTION
Add content databases in SharePoint Server 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 Server implementation.
Attach or detach content databases in SharePoint Server 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 in SharePoint Server 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 in SharePoint Server This article describes how to move content databases between
servers that are running SQL Server, between instances of
SQL Server, or from one SharePoint Server Web application to
another. You can also move a content database to load
balance a database server or Web application.
Move all databases in SharePoint Server This article describes how to move all of the databases
supported by SharePoint Server from one database server to
another database server. If your SharePoint databases are
hosted on different servers, this procedure applies to the
database server that hosts the configuration database.
Move or rename service application databases in SharePoint Learn how to move and rename service application databases
Server by using SQL Server, and then how to point the service
application to the moved or renamed database.
Run a farm that uses read-only databases in SharePoint A read-only farm can be part of a disaster recovery
Server 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 Server
farm in which content databases are set to be read-only (a
read-only farm).
Manage RBS in SharePoint Server Learn about Remote BLOB Storage (RBS) and how to manage
RBS in SharePoint Server.
CONTENT DESCRIPTION
Best practices for SQL Server in a SharePoint Server farm Learn about best practices for SQL Server in a SharePoint
Server farm.
See also
Concepts
Overview of backup and recovery in SharePoint Server
Plan for backup and recovery in SharePoint Server
Database types and descriptions in SharePoint Server
Add content databases in SharePoint Server

You can add a content database to a SharePoint Server farm by using the SharePoint Central Administration
website or Microsoft PowerShell. The tool that you use depends on the kind of environment that you have
deployed, your schedule requirements, and service level agreements that you have made with your organization.
Before you begin

You can add a new content database or attach an existing content database from a backup file.
The user account that is performing this operation must be a member of the Farm Administrators
SharePoint group.
If you use Windows authentication to connect to SQL Server, the user account must be a member of the
dbcreator fixed server role on the SQL Server instance where the database is to be created.
Adding a content database to a SharePoint Server web application

You can use the procedures that are described in this article to create a new content database and attach it to a
web application. 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.
To add a content database to a web application by using Central Administration
1. Verify that the user account that is performing this operation is a member of the Farm Administrators
SharePoint group.
2. Start Central Administration.
3. On the SharePoint Central Administration website, click Application Management.
4. In the Databases section, click Manage content databases.
5. On the Manage Content Databases page, click Add a content database.
6. On the Add Content Database page:
Specify a web application for the new database.
Specify a database server to host the new database.
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.
Specify the name of the failover database server, if one exists.
Specify the number of top-level sites that can be created before a warning is issued. By default, this is 2,000.
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 PowerShell
cmdlets.
NOTE

New-SPContentDatabase -Name <ContentDbName> -WebApplication <WebApplicationName>
Where:
<ContentDbName> is the name of the content database to create.

<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 Microsoft PowerShell cmdlet Mount-
SPContentDatabase. For more information, see Mount-SPContentDatabase.
NOTE
See also
Concepts
Attach or detach content databases in SharePoint Server
Move site collections between databases in SharePoint Server
Attach or detach content databases in SharePoint
Server

You can attach or detach SharePoint Server content databases by using the SharePoint Central Administration
website or Microsoft PowerShell
Before you begin

If you want to create a new content database while 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.
If the database already exists, it must be the same version as the SharePoint Server 2016 farm or this
operation will fail. To attach a content database that is a different version than the farm, use the To attach or
detach a content database by using Windows PowerShell procedure in the following section.
Attaching and detaching content databases

You might want to attach or detach content databases for the following reasons. You want to add a new content
database for new site collections to keep content databases at a manageable size. You are restoring a content
database from another farm and you want the sites that it contains to be accessed from a web application. You
have archived 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 in SharePoint Server
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 content databases in SharePoint Server.
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.
4. On the Application Management page, in the Databases section, click Manage content databases.
6. On the Add Content Database page:
Use the Web Application drop-down menu to select the web application to which you want to attach a
content database.
Specify the database server that hosts the database.
Specify the database name. If the database does not already exist, it will be created.
Specify the authentication method for the database, and supply an account name and password if you are
using SQL authentication.
NOTE
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 a nonencrypted
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.
Click OK.
To detach a content database by using Central Administration
SharePoint group.
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 PowerShell
cmdlets.
NOTE

3. At the PowerShell command prompt, type the appropriate command
To attach an existing content database:
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:
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 PowerShell. 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 Dismount-SPContentDatabase and Mount-SPContentDatabase.
NOTE
See also
Other Resources
Get-SPContentDatabase
New -SPContentDatabase
Remove-SPContentDatabase
Move site collections between databases in
SharePoint Server

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 SharePoint Server, you should view this procedure as moving
the site collection to a larger database.
However, if site collections do not grow to their expected capacity, it might be convenient to combine several site
collections onto one content database. In SharePoint Server, this process does not merge content databases,
instead the site collections are moved to and joined on a new database.
You can move site collections between databases in a SharePoint Server farm by using Microsoft PowerShell. You
can also move site collections by using Backup and Restore procedures. For information about how to do this, see
Back up site collections in SharePoint Server and Restore site collections in SharePoint Server.
Before you begin

Before you begin this operation, 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
Determining the size of the source site collection

When you move site collections to another content database the auditing data is copied. The size of the auditing
data varies depending on the event collection settings for the site collection. If the auditing data is large, you can
move the data to another database before you move the site collection. To do this, use the To archive and trim
audit data by using Microsoft PowerShell procedure.
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..
To determine the size of the site collection by using PowerShell

cmdlets.
NOTE

$used = (Get-SPSiteAdministration -Identity <http://ServerName/Sites/SiteName>).DiskUsed
$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 that is 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 PowerShell
cmdlets.
NOTE

(Get-SPSite -Identity <http://ServerName/Sites/SiteName>).Audit.TrimAuditLog(deleteEndDate)
Where:
To delete the audit data without archiving it first, type the following command:
(Get-SPSite -Identity <http://ServerName/Sites/SiteName>).Audit.DeleteEntries(deleteEndDate)
For more information, see Get-SPSite.
NOTE
Moving site collections between content databases

You can use the 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
cmdlets.
NOTE

Move-SPSite <http://ServerName/Sites/SiteName> -DestinationDatabase <DestinationContentDb>
Where:
<DestinationContentDb> is the name of the destination content database.
To move multiple site collections
cmdlets.
NOTE

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
See also
Concepts
Add content databases in SharePoint Server
Move content databases in SharePoint Server

This article describes how to move content databases between servers that are running SQL Server, between
instances of SQL Server, or from one SharePoint Server web application to another.
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 Server, see Move or rename service application databases in SharePoint Server and Move
all databases in SharePoint Server.
You can move content databases by using the SharePoint Central Administration website or Microsoft PowerShell,
and SQL Server tools. Which tool that you use depends on what kind of environment you have deployed, what
your schedule requires, and what service level agreements that you have made with your organization.
Before you begin

Before you begin this operation, moving a content database, review the following tasks. Each task is a procedure
that must be done in the order in which it is listed. Note that when you move content databases, you must use
both SharePoint Server tools and SQL Server tools. You can use either Central Administration or Windows
PowerShell 3.0 for this operation.
1. Record the content database name and the web application it is associated with.
2. Pause any service applications and services that might run against the content database, including timer
jobs and search crawls.
3. Remove the SharePoint Server content database from the web application.
4. Detach the content database from the current SQL Server instance.
IMPORTANT
To move the content database file within the same instance SQL Server we recommend that you use the FILENAME
clause of the ALTER DATABASE statement. For more information, see Move User Databases.
IMPORTANT
To move a content database to another instance of SQL Server or to another server, we recommend that you use
procedures found in Database Detach and Attach (SQL Server) or Back Up and Restore of SQL Server Databases.
5. Copy or move the content database .mdf, .ndf, and .ldf files from the source location to the destination
location using File Explorer.
6. Attach the content database to the new SQL Server instance.
7. Add the content database to the destination web application in SharePoint Server.
IMPORTANT
Use the identical name when you add the content database or SharePoint Server creates a new content database.
8. Restart all service applications and services that you paused in step 2.
Moving content databases by using Central Administration

Use the following procedure to move the content databases in your SharePoint Server farm by using Central
Administration.
The procedures in this section use Central Administration to move content databases. However when you perform
the following procedures, you must use the correct tool:
1. To record which content databases are associated with each web application ─ PowerShell
2. To detach the content databases from SQL Server ─ SQL Server tools
3. To move the content databases to a new location ─ File Explorer or Windows Explorer
4. To attach the content databases to the new instance of SQL Server ─ SQL Server tools
NOTE
The procedures in this section use Central Administration to move content databases. However, the first procedure, must be
performed by using PowerShell.
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 is moved. For more information, see
Account permissions and security settings in SharePoint Server 2016.
The destination farm must be running the same version or a later version of SharePoint Server than the source
farm is running.
1. To record which content databases are associated with each web application
The dbcreator and securityadmin fixed server roles on the destination server, in order to attach the
database and configure SQL Server logins.
cmdlets.
NOTE

Get-SPContentDatabase -WebApplication <http://SiteName>
Where: _\<http://SiteName\>_ is the URL of the web application.
> [!NOTE]
> We recommend that you use Microsoft 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.
2. To pause timer jobs by using Central Administration

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.
3. To detach the content databases from a web application by using Central Administration
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.
4. To detach the content databases from SQL Server
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.
5. 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 File 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.
6. 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
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.
7. To attach the content databases to the web application by using Central Administration
group.
2. In Central Administration, in the Application Management section, click Manage Content databases.
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.
8. To restart timer jobs by using Central Administration
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.
Moving content databases by using PowerShell

Use the following procedure to move the content databases in your SharePoint Server farm by using PowerShell
The procedures in this section use PowerShell to move content databases. However when you perform the
following procedures, you must use the correct tool:
4. To detach the content databases from SQL Server ─ SQL Server tools
5. To move the content databases to a new location ─ File Explorer
6. To attach the content databases to the new instance of SQL Server ─ SQL Server tools
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 is moved.
The destination farm must be running the same version or a later version of SharePoint Server than the source
farm is running.
1. To record which content databases are associated with each web application
cmdlets.
NOTE

Get-SPContentDatabase -WebApplication <http://SiteName>

Where: _\<http://SiteName\>_ is the URL of the web application.
For more information, see Get-SPContentDatabase
NOTE
2. To pause timer jobs by using PowerShell

cmdlets.
NOTE

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
3. To detach content databases from a web application by using PowerShell
cmdlets.
NOTE

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](/powershell/module/sharepoint-server/Dismount-

SPContentDatabase?view=sharepoint-ps) and [Get-SPContentDatabase](/powershell/module/sharepoint-server/Get-
SPContentDatabase?view=sharepoint-ps).
> [!NOTE]
versions.
4. To detach the content databases from SQL Server

2. In 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.
5. 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 File 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.
6. 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
2. In Management Studio, open the destination SQL Server instance.
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.
7. To attach content databases from a web application by using PowerShell
cmdlets.
NOTE

Mount-SPContentDatabase "<ContentDB>" -DatabaseServer "<DBServer>" -WebApplication <http://SiteName>
Where:
<ContentDB> is the name of 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](/powershell/module/sharepoint-server/Dismount-
SPContentDatabase?view=sharepoint-ps).
> [!NOTE]
versions.
8. To restart timer jobs by using PowerShell

cmdlets.
NOTE

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](/powershell/module/sharepoint-server/Get-SPTimerJob?

view=sharepoint-ps), [ForEach-Object](http://go.microsoft.com/fwlink/p/?LinkID=717315&clcid=0x409), [Get-
Content](http://go.microsoft.com/fwlink/p/?LinkID=717318&clcid=0x409), and [Enable-SPTimerJob]
(/powershell/module/sharepoint-server/Enable-SPTimerJob?view=sharepoint-ps).
> [!NOTE]
versions.
See also
Concepts
Move all databases in SharePoint Server

You can use the SharePoint Central Administration website, or SQL Server tools to move all databases that are
associated with SharePoint Server to a new database server.
Before you begin

The procedures in this article explain how to move the following kinds of databases that are hosted on a single
database server:
Configuration database
Central Administration content database
Content databases
Service application databases
IMPORTANT
To move database files within the same instance of SQL Server we recommend that you use the FILENAME clause of the
ALTER DATABASE statement. For more information, see Move User Databases.
NOTE
To move a database to another instance of SQL Server or to another server, we recommend that you use procedures found
in Database Detach and Attach (SQL Server) or Back Up and Restore of SQL Server Databases.
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 db_owner fixed database role
In some environments, you must coordinate the move procedures with the database administrator. Be sure to
follow applicable policies and guidelines for managing databases.
IMPORTANT
When you move databases, all farm sites and assets are unavailable to users until the process is complete. Complete this
operation outside normal business hours.
Move all databases

To move all databases from one database server to another database server, you have to work in both SharePoint
Server and SQL Server.
Before you begin this operation, review the steps in this process:
1. Prepare the new database server.
2. Close all open SharePoint Management Shell windows.
3. Stop all services that are related to SharePoint Server and Internet Information Services (IIS ).
4. Detach the databases from the current SQL Server instance.
5. Copy or move all files that are associated with the databases (.mdf, .ndf, and .ldf), to the new destination
server that runs SQL Server.
6. Make sure that all of the SQL Server logins, fixed server roles, fixed database roles, and permissions for the
databases are configured correctly on the new destination database server.
NOTE
It is important that the destination server where you move the databases has the same database information that
the current SQL Server instance has. For details about how to do this, see How to transfer logins and passwords
between instances of SQL Server. For more information, see Server-Level Roles and Database-Level Roles.
7. Attach the databases to the new destination server that runs SQL Server.
8. Use SQL Server connection aliases to point to the new database server and update all web servers.
If you do not want to use SQL Server connection aliases use one of the following procedures to update the
database connections for your SharePoint Server farm.
Scenario 1: Use this procedure to update the database connections if you use SharePoint Server and SQL
Server AlwaysOn Availability Groups for high availability or disaster recovery.
Scenario 2: Use this procedure if you must use manual steps or if you move the databases from a
SharePoint Server Single-server farm role installation to a new Single-server farm role installation.
9. Restart all services that you stopped in step 3.
To prepare the new database server
Use the procedures in Configure SQL Server security for SharePoint Server to configure the new database server.
The new database server must run either the same version of Windows Server and SQL Server as the existing
database server, or one of the following versions:
For SharePoint Server 2019:
Windows Server 2019
Windows Server 2016
SQL Server 2016
SQL Server 2017
For SharePoint Server 2016:
Windows Server 2016
SQL Server 2014 Service Pack 1 (SP1)
SQL Server 2016
For SharePoint 2013:
Windows Server 2008 R2 Service Pack 1 (SP1)
Windows Server 2012
SQL Server 2008
SQL Server 2012
SQL Server 2014
The version of the existing SharePoint Server and Windows Server must also support the version of the new SQL
Server where the DBs are being moved. For more information, see Hardware and software requirements for
SharePoint Server 2016 and Hardware and software requirements for SharePoint 2013.
To close all open sessions of SharePoint Management Shell
1. Close all open SharePoint Management Shell windows, and all open command prompt windows.
To stop the farm
1. On the server that is running Central Administration, stop the following services:
SharePoint Timer
SharePoint Tracing
SharePoint Server Search 16
2. On the server that is running Central Administration, at a command prompt, type iisreset /stop.
To detach databases
1. In SQL Server Management Studio on the original database server, detach the databases that you want to
move from the instance to which they are attached. If you are running many databases, you may want to
run a Transact-SQL script to detach databases.
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: Database Detach and Attach (SQL Server), Detach a Database, and
sp_detach_db (Transact-SQL ).
To move database files to the new server
1. Verify that the user account that is performing this procedure is a member of the following:
On the database server from which the databases are being moved, you must be a member of the
following:
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:
2. Use Windows Explorer to locate the .mdf, .ldf, and .ndf files that are associated with each database that you
are moving.
3. Copy or move the files to the destination directory on the new computer that is running SQL Server.
To set up permissions on the new server
2. On the destination database server, start Management Studio and transfer your logon credentials 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 How to transfer logins and passwords
between instances of SQL Server.
For more information about how to transfer SQL Server metadata between instances, see Managing
Metadata When Making a Database Available on Another Server Instance.
To attach databases to the new instance of SQL Server
2. On the destination database server, attach the databases to the new instance. For more information, see Attach
a Database and sp_attach_db (Transact-SQL ).
The following procedures provide methods to connect to the new SQL Server instance or update the database
connections. Use the procedure that works best for your SharePoint Server farm environment.
IMPORTANT
If you're using SharePoint Server and SQL Server AlwaysOn Availability Groups before moving the databases, you should
point to the AG Listner. If you're moving from a single-server farm to an AlwayOn Availability Group then you should use
the cliconfg.exe.
To point the web application to the new database server by setting up SQL Server connection aliases
1. This procedure must be performed on all servers in the SharePoint Server farm that connect to the
instance of SQL Server that hosts the databases.
3. Start the SQL Server Client Network Utility (cliconfg.exe). This utility is typically located in the
C:\Windows\SysWOW64 and C:\Windows\System32 folder.
4. On the General tab, verify that TCP/IP is enabled.
5. On the Alias tab, click Add. The Add Network Library Configuration window appears.
6. In the Server alias box, enter the name of the current instance of SQL Server.
7. In the Network libraries area, click TCP/IP.
8. In the Connection parameters area, in the Server name box, enter the new server name and instance to
associate with the alias, and then click OK. This is the name of the new server that is hosting the
SharePoint Server databases.
9. Repeat steps 3 through 8 on all servers in the farm that connect to the new instance of SQL Server.
10. Optional. If your environment relies on System Center 2012 - Data Protection Manager (DPM ) or a third-
party application that uses the Volume Shadow Copy Service 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 Install SQL Server 2014 from the Installation Wizard (Setup)
and Windows Server Installation and Upgrade.
You can use these Microsoft PowerShell cmdlets to deploy, manage, and remove availability groups in SQL
Server with SharePoint Server:
Add-DatabaseToAvailabilityGroup
Remove-DatabaseFromAvailabilityGroup
Get-AvailabilityGroupStatus
Use the following procedure to update the database connections if you use SharePoint Server and SQL Server
AlwaysOn Availability Groups for high availability or disaster recovery.
Scenario 1: To update the database connections by using PowerShell
cmdlets.
NOTE

Add-DatabaseToAvailabilityGroup -AGName "<AGGroupName>" -DatabaseName "<DatabaseName>" [-FileShare "

<\\server\share>"]
Where:
<AGGroupName> is the name of the Avaliability Group.
<DatabaseName> is the name of the database that you are adding to the Availability Group
If the optional -FileShare parameter is used, <\server\share> is the name of the server and the share that
you use.
4. Repeat these steps for all databases that you move, including the Configuration and Central Administration
Content databases.
Use the next procedure for the following scenarios:
If you must use manual steps
If you move the databases from a SharePoint Server 2016 Single-Server Farm role type to a new Single-
Server Farm role type or from a SharePoint 2013 single-server installation to a new single-server
installation.
NOTE
The Single-Server Farm role replaces the Standalone Install mode available in previous SharePoint Server releases.
For more information, see Overview of MinRole Server Roles in SharePoint Server 2016.
If you use Availability Groups then you must manually add the databases to the availability groups as
appropriate to their high availability/disaster recovery support. For more information, see Add a Database
to an Availability Group (SQL Server)
If you use SQL Mirroring then make sure your mirroring is setup appropriately. For more information, see
Setting Up Database Mirroring (SQL Server) and Database Mirroring (SQL Server).
Scenario 2: To update the database connections by using Microsoft PowerShell
$db = Get-SPDatabase -Identity <guid>
Where <GUID> is the ID of the database that you move.

NOTE
Use Get-SPDatabase without parameters to see a list of all databases with GUIDs.
$db.ChangeDatabaseInstance("<DBServerName>")
Where <DBServerName> is the name or alias of the new SQL Server or is the AlwaysOn Availability Group
listener DNS name.
$db.Update()
3. If you use SQL Server database mirroring then you must remember to populate the FailoverServiceInstance
property on the SharePoint database.
$db.failoverserviceinstance("<DBServerName>")
Where <DBServerName> is the name or alias of the mirrored SQL Server.
$db.update()
4. Repeat these steps for all databases that you move, including the Configuration and Central Administration
Content databases.
To restart the services in the farm
SharePoint group.
2. On the server that is running the SharePoint Central Administration website, at a command prompt, type
iisreset /start.
3. In the Microsoft Management Console Services snap-in, start all of the services that are related to
SharePoint Server and IIS. These include the following services:
SharePoint Timer
SharePoint Tracing
SharePoint Server Search
See also
Concepts
Database types and descriptions in SharePoint Server
Other Resources
Quick reference guide: SharePoint Server 2016 databases
Databases that support SharePoint 2013
Add a database server to an existing farm in SharePoint 2013
Move or rename service application databases in
SharePoint Server

Learn how to move or rename service application databases in SharePoint Server.
The main reason to move service application databases to another farm database server is to load balance the
farm. Or you might need to move it to newer hardware.
Renaming service application databases is often done to remove the GUID from the database name after you've
used SharePoint Products Configuration Wizard and SharePoint Server Product Configuration Wizard to create
the service application databases in your farm. You might also need to align the database names with your
organization's naming standards.
Both moving and renaming service application databases follow the same basic process, but there are a few more
steps when you are moving service application databases.
1. Move or rename SharePoint Server service application databases using Microsoft SQL Server
Management Studio or Microsoft PowerShell.
2. Point the SharePoint service application to the moved or renamed database using either the SharePoint
Central Administration website or PowerShell.
Depending on how many service application databases you move or rename, pointing the service
application to the database can be complex. Different service applications require different methods to
point to the moved or renamed database.
These service application databases use the following steps:
Managed Metadata Service
PerformancePoint Service
SharePoint Translation Service
State Service
Subscription Settings Service
1. Stop or disable the service application.
2. Detach the database.
3. Move or rename the database.
4. Attach the database.
5. Point the service application to the moved or renamed database.
6. Restart the service application.
The Business Data Connectivity Service and User Profile Service applications databases require the following
steps to move or rename the databases:
1. Stop or disable the service application.
2. Detach the database.
3. Move or rename the database.
4. Attach the database.
5. Point the service application to the moved or renamed database.
6. Delete the service application.
7. Recreate the service application.
8. Restart the service application.
The Search Service application databases require the following steps:
1. Pause the service application.
2. Set the Search service application to Read-Only.
3. Backup the service application.
4. Set the max degree of parallelism to 1 in the new server that hosts SQL Server.
5. Restore the Search service application to a new database server.
6. Set the Search Service application to read/write.
7. Start the service application.
8. Point the Search service application to the moved or renamed databases.
General steps to move or rename service application databases by

using SQL Server
To move a service application database, you must use SQL Server. To rename a service application database, you
must use SQL Server and File Explorer.
Cau t i on
Don't attempt to move and rename a database in one procedure. You should either move a database or rename a
database, not perform both actions at the same time.
When you move or rename service application databases, the first step is to stop the service application for the
database that you are changing. You can stop or start services by using Central Administration or PowerShell.
Step 1: To stop the service application by using Central Administration
1. Use an account that is a member of the Farm Administrators SharePoint group.
2. In Central Administration click System Settings.
3. On the System Settings page, in the Servers section, click Manage services on server.
4. Find the service application that you want to stop, click Stop or Disable in the Action column for the
service, and then click OK.
To stop a service by using PowerShell
1. Use an account with these memberships:
NOTE
For additional information about Microsoft PowerShell permissions, see Permissions.

3. You need to know the service GUID for the next step. Use the Get-SPServiceInstance cmdlet to retrieve a
list of all services in the farm together with their GUIDs.
Stop-SPServiceInstance -Identity <ServiceGUID>
Where <ServiceGUID> is the GUID of the service.

For more information, see Stop-SPServiceInstance.
Move a database by using SQL Server Management Studio and File Explorer
Moving a database requires that you first detach the database from the SQL Server, move the files to the new
location by using File Explorer, and then attach the database to the new instance of SQL Server.
Step 2: To detach a database from SQL Server
1. Use an account that has the db_owner fixed database role for all of the databases that you're moving.
2. In SQL Server Management Studio, connect to the SQL Server instance that the service application
database is attached to, and then expand the Databases node.
3. Right-click the database, point to Tasks, and then click Detach. Repeat this step for each database that you
want to move.
Step 3: To move the database files to a new location by using File Explorer
1. Use an account that has read permission on the source location and write permission on the target location.
2. In File Explorer, find the .mdf, .ndf, and .ldf files for the service application databases and select the ones you
want to move. The database files are typically found here,
C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLServer\MSSQL\Data
3. Either copy or move the database files to the new location.

Step 4: To attach a database to a new instance of SQL Server
2. In SQL Server Management Studio, open the destination SQL Server instance.
4. In the Attach Database dialog box, browse to where you moved the .mdf, .ndf, and .ldf files, select the .mdf
file for the database that you want to attach, and then click OK. Repeat this step for each database that
you're moving.
Rename a database by using SQL Server Management Studio
Renaming a service application database is a two step process, first stop the service, just as if you were going to
move the database. You then rename the database by using SQL Server Management Studio.
Step 3: To rename a database by using SQL Server
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're renaming.
Point a SharePoint Server service application to a moved or renamed database
Pointing to the moved or renamed database is the next step. You can do this with either Central Administration or
PowerShell. Using Central Administration to point service applications to the moved or renamed databases is the
same for most of the SharePoint Server service applications. Using PowerShell to point service applications to the
moved or renamed databases differs for each service application. This section provides guidance for each service
application and database.
Step 5: To point the service application to a moved or renamed database by using Central Administration
3. On the Manage Service application page, click the empty area in the row next to the service application
name. The ribbon becomes active, click Properties and the Edit Service Application dialog box appears.
4. Change the database server or database name, and then click OK.
To point the Managed Metadata service application to a moved or renamed database by using PowerShell
NOTE

$app = Get-SPServiceApplication -Name "<ServiceApplicationName>"

Set-SPMetadataServiceApplication -Identity "<Name/GUID of service application>" $app -DatabaseName "
<DatabaseName>" -DatabaseCredentials PSCredential object>
Where:
<ServiceApplicationName> is the name of the Managed Metadata service application.
<DatabaseName> is the name of the renamed database.
To point the PerformancePoint service application to a renamed or moved database by using PowerShell
NOTE

Set-SPPerformancePointServiceApplication -Identity "<ServiceApplicationName>" -SettingsDatabase "

<DatabaseServerName\DatabaseName>"
Where:
<ServiceApplicationName> is the name of the PerformancePoint service application.
<DatabaseServerName\DatabaseName> is the location of and the name of the renamed or moved
database. Do not include the location if you are just renaming the database.
The State Service database stores temporary state information data. You can use PowerShell to point the State
Service service application to a moved database by performing one of the following procedures:
Add a new database in the new location, or create a database with a new name. Then add the new database
to the service application, and delete the old database. For details, see To add a new database to the State
service application, and remove an old database by using Microsoft PowerShell.
Dismount the old database, move it by using SQL Server, and then remount the State Service database. For
details, see To point the State service application to a moved database by using Microsoft PowerShell.
The following procedures all include the steps shown in the bullet list. So, they do not require that these
steps are already performed:
Stopping a service application
Moving a database by using SQL Server Management Studio and Windows
To add a new database to the State Service service application and remove an old database by using PowerShell
NOTE

3. At the PowerShell command prompt, type the following command to create a new database:
New-SPStateServiceDatabase -Name "<NewDatabaseName>"

Then type the following command to remove the old database:
Remove-SPStateServiceDatabase -Name "<OldDatabaseName>"
Where:
<NewDatabaseName> is the name of the new database that you want to create.
<OldDatabaseName> is the name of the old database that you want to disassociate with the State
service and detach from SQL Server.
To point the State Service service application to a moved database by using PowerShell
2. At the PowerShell command prompt, type the following command to dismount the database:
Dismount-SPStateServiceDatabase -Identity <DatabaseID>
Where <DatabaseID> is the State Service database to remove from the service application. The type must
be a valid GUID in the form 12345678-90ab-cdef-1234-567890bcdefgh, a valid name of a state database,
or an instance of a valid SPStateServiceDatabase object.
For more information, see Dismount-SPStateServiceDatabase.
3. Move the database. For details, see Move a database by using SQL Server Management Studio and File
Explorer.
4. At the PowerShell command prompt, type the following command to mount the renamed or moved
database:
Mount-SPStateServiceDatabase -Name "<DatabaseName>" -DatabaseServer "<ServerName>"
Where:
<DatabaseName> is the name of the database to associate with the State service.
<ServerName> is the name of the SQL Server that hosts the State service database.
To point the Usage and Health data collection service application to a moved database by using PowerShell
NOTE

Set-SPUsageApplication -Identity "<ServiceApplicationName>" -DatabaseName "<DbName>" -DatabaseServer "
<SQLServerName>"
Where:
<ServiceApplicationName> is the name of the usage and health data collection service application.
<DatabaseName> is the name of the database.
<SQLServerName> is the name of the database server.
To point the Word Automation service application to a renamed or moved database by using PowerShell
NOTE

$app = Get-SPServiceApplication -Name "<ServiceApplicationName>"

Set-SPWordConversionServiceApplication -Identity $app -DatabaseName "<DatabaseName>" -DatabaseServer "
<DatabaseServer>"
Where:
<ServiceApplicationName> is the name of the Word Automation 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 pointing to a renamed database in the same location.
To point the Subscription Settings Services service application to a moved database by using PowerShell
NOTE

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 database.
<DatabaseServer> is the name of the renamed database.
Step 6: To start the service application by using Central Administration
4. Find the service application that you want and click Start in the Action column for the service, and then
click OK.
Steps to move or rename the Business Data Connectivity Service and

User Profile Service application databases
When moving or renaming the Business Data Connectivity service application and User Profile service application
databases requires extra steps. The extra steps required for both service application databases is that after you
move or rename the databases we recommend that you delete the service application and then re-create it.
The following procedures show how to move or delete the Business Data Connectivity service application.
To stop the Business Data Connectivity service application
4. Find the service application that you want to stop, click Stop or Disable in the Action column for the
service, and then click OK.
To stop a service by using PowerShell
Stop-SPServiceInstance -Identity <ServiceGUID>
Where <ServiceGUID> is the GUID of the service. If you don't 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 and Get-SPServiceInstance.
Step 2: To detach a database from SQL Server
2. In SQL Server Management Studio, connect to the source SQL Server instance, and then expand the
Databases node.
3. Right-click the database, point to Tasks, and then click Detach. Repeat this step for each database that you
want to move.
Step 3: To move the database files to a new location by using File Explorer or Windows Explorer
1. Use an account that has read permission on the source location and write permission on the target location.
2. In File Explorer, find the .mdf, .ndf, and .ldf files for the service application databases and select the ones you
want to move. The database files are typically found here,
C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLServer\MSSQL\Data
3. Either copy or move the database files to the new location.

Step 4: To attach a database to a new instance of SQL Server
2. In SQL Server Management Studio, open the destination SQL Server instance.
4. In the Attach Database dialog box, browse to where you moved the .mdf, .ndf, and .ldf files, select the .mdf
file for the database that you want to attach, and then click OK. Repeat this step for each database that
you're moving.
Point the Business Data Connectivity service application to a moved database
The method for pointing a service application to a 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.
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 PowerShell cmdlets that are described in the article Document farm configuration settings
To delete the service application by using Central Administration
2. In Central Administration, click Application Management, and then, click Manage service
applications.
3. On the Service Applications page, place your cursor next to Business Data Connectivity service and then
click the empty row.
The ribbon becomes active.
4. On the ribbon, click Delete.
5. In the Delete Service Application 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 create the service application
To create a Business Data Connectivity service application, follow the procedure in Configure a Business Data
Connectivity service application in SharePoint Server.
To start the service application
1. To start a service application, see Start or stop a service in SharePoint Server.
Steps to move or rename the Search Service application databases

To move the Search service application databases, you must use SQL Server, SQL Server Management Studio,
and Windows Explorer. To point to the moved databases, you must use PowerShell. Complete the following steps
in the listed order.
Important:
The account, or accounts, that you use to do the operations must have these memberships and permissions:
Member of the Farm Administrators SharePoint group.
Member of the Administrators group on the local server.
Read permission on the source location and write permission on the target location.
db_owner fixed database role for all of the databases that you are moving.
db_creator and securityadmin roles for all of the databases that you are moving.
The Search Service account must have the following roles:
db_owner fixed database role on the Administration, Link, and Crawl databases.
SPSearchDBAdmin database role on the Analytics Reporting database.
In some environments, you must coordinate the rename and move procedures with the database administrator. Be
sure to follow applicable policies and guidelines for managing databases.
To pause the Search service application by using PowerShell

Where <SearchServiceApplicationName> is the name of the Search service application associated with the
database move.
To change the read-only mode for Search service application databases
1. Use an account that 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. Set the following databases to read-only mode:
Analytics Reporting
Crawl
Link
Right-click the database that you want to set to read/write or read-only, and then click Properties.
In the Database Properties dialog box, on the Options properties page, in the State section, select
True or False in the list next to Database Read-Only, and then click OK.
Click Yes.
To back up the Search service application databases
1. Use an account that is a member of the SQL Server db_backupoperator fixed database role on the
database server where each database is stored.
2. Start SQL Server Management Studio and connect to the database server where the Search service
application databases are stored.
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 the type of backup to use, see Recovery Models (SQL Server).
6. In the Backup component area, click Database.
7. Either use the default name or specify a name for the backup set in the Name box.
8. Specify the expiration date for the backup set.
This date determines when the backup set can be overwritten by subsequent 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 the following databases:
Analytics Reporting
Crawl
Link
To set the value of max degree of parallelism to 1 in the new server that hosts SQL Server
1. Start SQL Server Management Studio and connect to the new server that hosts SQL Server where you'll
move the Search service application databases.
2. In Object Explorer, right-click the database server and then click Properties.
3. Click Advanced.
4. In the Max Degree of Parallelism box, select 1 to limit the number of processors to use in parallel plan
execution.
For more information, see Configure the max degree of parallelism Server Configuration Option.
To restore the Search service application databases to a new database server
1. Use an account that is a member of the SQL Server sysadmin fixed server role on the database server
where each database is stored.
2. Start SQL Server Management Studio and connect to the database server.
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 list.
6. Select the restore source from the From database 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 Recovery Models (SQL Server) 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.
To set the Search service application databases to read/write
1. Follow the steps in To change the read-only mode for Search service application databases.
To point the Search service application to moved databases by using PowerShell
2. Point the Search Service Application database to the new location. At the PowerShell command prompt,
type the following commands:

$ssa | Set-SPEnterpriseSearchServiceApplication [-DatabaseName "<NewDbName>"] -DatabaseServer "
<NewServerName>"
Where:
<NewDbName> is the name of the database.
<NewServerName> is the new database location.
3. Point the Analytics Reporting database to the new location. At the PowerShell command prompt, type the
following commands:
Add-SPServerScaleOutDatabase -ServiceApplication $ssa -DatabaseServer <OriginalServerName> [-DatabaseName

<NewDbName>]
$temp = Get-SPServerScaleOutDatabase -ServiceApplication $ssa
Remove-SPServerScaleOutDatabase -Database $temp[0] -ServiceApplication $ssa
Where:
<OriginalServerName> is the name of the original SQL server.
4. Point the CrawlStore database to the new location. At the PowerShell command prompt, type the following
commands:
$CrawlDatabase0 = ([array]($ssa | Get-SPEnterpriseSearchCrawlDatabase))[0]

$CrawlDatabase0 | Set-SPEnterpriseSearchCrawlDatabase [-DatabaseName "<NewDbName>"] -DatabaseServer "
<NewServerName>"
5. Point the LinkStore database to the new location. At the PowerShell command prompt, type the following
commands:
$LinksDatabase0 = ([array]($ssa | Get-SPEnterpriseSearchLinksDatabase))[0]

$LinksDatabase0 | Set-SPEnterpriseSearchLinksDatabase [-DatabaseName "<NewDbName>"] -DatabaseServer "
<NewServerName>"
6. Set all Search service instances to Online. Run the following commands for each search service in the farm,
until the Search service instance is reported as Online. At the PowerShell command prompt, type the
following commands:
Get-SPEnterpriseSearchServiceInstance -Identity <Search Server> Do {write-host -NoNewline .;Sleep 10;

$searchInstance = Get-SPEnterpriseSearchServiceInstance -Identity <Search Server>} while
($searchInstance.Status -ne "Online")
Where <Search Server> is the name of the server that hosts the search components.
7. Resume the Search service application. At the PowerShell command prompt, type the following commands:

Where <SearchServiceApplicationName> is the name of the Search service application associated with the
database move.
8. Restart each server that hosts a search component.
See also
Concepts
Run a farm that uses read-only databases in
SharePoint Server

You can use Microsoft PowerShell or SQL Server tools to set your SharePoint Server databases to read-only. The
tool that you use depends on the kind of environment that you have deployed, your schedule requirements, and
service level agreements that you have made with your organization.
Before you begin

Before you begin this operation, review the following information about the settings that make a read-only farm.
A farm is considered read-only if one of the following is true:
All content databases are set to read-only.
Service application databases are set to read-only.
NOTE
The Search service application does not function when its databases are set as read-only.
The functionality and user experience in a read-only farm depends on the databases that are set to read-only.
NOTE
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.
Prepare users for the read-only experience

If you plan to give users access to a read-only site or farm, you should set expectations for tasks that users can
complete on the site and the behavior of the user interface (UI).
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:
A statement at the top of the home page states that the site is read-only.
Common tasks that do not require writing to the content database are fully available.
Common tasks that require writing to the content database are not available either because the UI for the
task is not available or because the user cannot apply changes to complete the task.
Some common tasks that require writing to the content database and that appear to be available return
errors.
Farms that use read-only service application databases
The user experience on 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 and that appear to be available return errors.
Set content databases to read-only

Before you set content databases to read-only, you may need to determine the content database that is associated
with a particular site collection.
To determine the content database that is associated with a site collection by using PowerShell
cmdlets.
NOTE

Get-SPContentDatabase -Site <Site URL>
Where:
<Site URL> is the site collection URL for which you want to know the associated content database.
The command returns the content database that is associated with the site.
NOTE
You can follow these steps 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 ).
IMPORTANT
Do not perform this procedure on databases in a failover environment that were log-shipped or mirrored. If a database in a
failover environment that is either log-shipped or mirrored is set as read-only then no updates are performed and the
backup is not valid.
To set content databases to read-only by using SQL Server

role in each database.
2. Start SQL Server Management Studio.
3. Right-click the content database that you want to make 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 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 read-only

It is possible to set any service application database to read-only. However, some service applications do not
function when their databases are set to read-only, such as those that are associated with Search and Project
Server.
To set service application databases to read-only by using SQL Server
role in each database.
2. Start SQL Server Management Studio.
3. Right-click the database that you want to make 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.
Manage RBS in SharePoint Server

Remote BLOB Storage (RBS ) is an add-in that you can install when you install SQL Server 2008 or SQL Server
2014 Service Pack 1 (SP1). 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 Server are 4 gigabytes (GB ) or
larger, consider using RBS as part of your data storage solution.
Read the following articles about managing RBS.
** CONTENT** DESCRIPTION
Overview of RBS in SharePoint Server Conceptual overview of how RBS works with SQL Server 2014
Service Pack 1 (SP1). It contains important information about
RBS features and providers. We strongly recommend that you
read this article before you implement RBS.
Deciding to use RBS in SharePoint Server Information to help you decide whether to use Remote BLOB
Storage (RBS) in a SharePoint Server environment, and if you
use RBS, to understand the benefits and costs of using RBS in
your environment.
Install and configure RBS with FILESTREAM in a SharePoint How to install and configure RBS and implement the
Server farm FILESTREAM provider for use with SharePoint Server.
Install and configure RBS with a 3rd party provider for How to install and configure RBS using a 3rd party provider.
SharePoint Server
Set a content database to use RBS with FILESTREAM in How to set a content database to use Remote BLOB Storage
SharePoint Server (RBS) that uses the FILESTREAM provider.
Migrate content into or out of RBS in SharePoint Server How to migrate content into or out of RBS, or to a different
RBS provider.
Maintain RBS in SharePoint Server How to perform maintenance tasks that are associated with
Remote BLOB Storage (RBS).
Disable RBS on content databases in SharePoint Server How to disable RBS in a SharePoint Server environment.
Overview of RBS in SharePoint Server

This article describes how to use SharePoint Server together with Remote BLOB Storage (RBS ) and 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 Server installation, see Deciding to use
RBS in SharePoint Server.
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.
Introduction to RBS
In SharePoint Server, 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 Office document or a video file. By default, these
BLOBs, also known as unstructured data, are stored directly in the SharePoint content database together 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. Therefore, 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 SQL Server library API set that is incorporated as an add-in feature pack that you can install when you
install the following:
SQL Server 2014 Service Pack 1 (SP1)
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2 Express
SQL Server 2008 R2
SQL Server 2008
The RBS feature enables applications, such as SharePoint Server, 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 Server uses the RBS feature to store BLOBs outside the content database. SQL Server and SharePoint
Server 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 SharePoint
Server, SQL Server, 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 an
add-in feature of SQL Server 2014 Service Pack 1 (SP1) that enables storage of and efficient access to
BLOB data by using a combination of SQL Server 2014 (SP1) and the NTFS file system. For more
information about FILESTREAM, see FILESTREAM (SQL Server) For information about how to enable and
configure FILESTREAM, see Enable and Configure FILESTREAM.
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 Server 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 features, such as backup and restore in Central Administration, can be used.
The RBS FILESTREAM provider is available as an add-in when you install SQL Server 2014 Service Pack 1 (SP1).
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 a 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 Server 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 Server

SharePoint Server 2016 supports the FILESTREAM provider that is included in SQL Server 2014 (SP1). This
version of RBS is included on the SQL Server installation media, but is not installed by the SQL Server Setup
program..
SharePoint 2013 supports the FILESTREAM provider that is included in the SQL Server Remote BLOB Store
installation package from the Feature Pack for SQL Server 2008 R2, SQL Server 2012, and SQL Server 2014.
These versions of RBS are available at the following locations:
Microsoft SQL Server 2008 R2 Feature Pack
Microsoft SQL Server 2012 Feature Pack
Be aware that SQL Server Remote BLOB Store installation package for SQL Server 2014 is the only version of
RBS that is supported by SharePoint Server 2016. SQL Server Remote BLOB Store installation package from the
Feature Pack for SQL Server 2008 R2 and later are the only versions of RBS that are supported by SharePoint
2013. 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 Server.
In SharePoint Server, 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
Server farm database backup and restore operations.
To use RBS, you must install an RBS provider on each server where SharePoint Server 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.
NOTE
If Visio web services runs on SharePoint Server application servers that do not have an RBS provider installed, a Visio error
occurs when you attempt to open a Visio diagram from this server. You must install an RBS client on SharePoint Server
servers that run the Visio Graphics Service if you want to open Visio diagrams on that server.
SharePoint Server 2016: To run RBS on a remote server, you must be running SQL Server 2014 (SP1)
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 Server 2016 content databases,
you must run SQL Server 2014 (SP1). This is true for all RBS providers.
SharePoint Server 2013: To run RBS on a remote server, you must be running SQL Server 2008 R2, SQL Server
2012, or SQL Server 2014 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 2013 content databases, you
must run SQL Server 2008 with SP1 and Cumulative Update 2, SQL Server 2012, or SQL Server 2014. 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 2013 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 changing those BLOBs is not supported using any
tool or product other than SharePoint Server. All access must occur by using SharePoint Server only.
See also
Other Resources
Binary Large Object (Blob) Data (SQL Server)
FILESTREAM (SQL Server)
Remote BLOB Store Provider Library Implementation Specification
Install and configure RBS with SharePoint 2013 and SQL Server 2012

This article provides information to help you decide whether to use Remote BLOB Storage (RBS ) in a SharePoint
Server environment, and to understand the benefits and costs of using RBS.
IMPORTANT
RBS does not increase the storage limits of content databases. All limitations still apply to RBS-enabled content databases.
RBS is intended to lower storage costs by allowing you to store large read-intensive BLOBs on less expensive drives. For
example, if you have 150 GB of RBS data and you have a content database that is 70 GB, this still exceeds the limits.
In SharePoint Server, a binary large object (BLOB ) is a file, such as a Microsoft Office 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 in SharePoint Server.
Limitations of RBS
Each RBS provider has different capabilities and limitations. The FILESTREAM provider has the following
limitations:
RBS has specific content database size limits for specific scenarios. For more information about these
limitations, see the "Content database limits" section in Software boundaries and limits for SharePoint
2013 and Content database 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.
Optimal use of RBS

Because RBS is a solution created for a specific set of conditions, there is point at which the benefits of using RBS
outweigh the costs. The optimal environment for using RBS is one in which the following conditions are 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 operational complexity that
the use of RBS might be introduce.
Least effective use of RBS

RBS is not a good solution for all environments because, in specific environments, the costs will outweigh the
benefits. The least beneficial environment for using RBS is one where the following conditions are 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 operational complexity that the use of RBS might introduce is greater than
high-cost drive space.
Under these conditions, even a content database that is less than 200 GB will produce a noticeable performance
bottleneck as the small BLOBs are frequently accessed for writing. The bottleneck 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 become very large and 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.
Implications of using RBS in different scenarios

You should evaluate the implications of using RBS in different site scenarios. Because RBS was created to resolve
specific problems, RBS might not perform equally well in all situations. The situations 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 200GB 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 database limits" section in Software boundaries and limits for SharePoint 2013 and Content database 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.
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 Server, 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. When you use this
provider, the backup and restore features in SharePoint Server 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. For more
information, see FILESTREAM Compatibility with Other SQL Server Features.
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 Server, or migrating the SharePoint sites to another environment. These costs should
be considered when you evaluate whether to use RBS.
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 set up 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 with
FILESTREAM in a SharePoint Server farm.
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.
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
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 in SharePoint Server.
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.
Evaluate provider options

RBS requires a provider that connects the RBS APIs and SQL Server. SQL Server 2014 Service Pack 1 (SP1),
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 SQL Server 2014 (SP1), 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
Server 2016 requires you to use the version of RBS that is included with the SQL Server 2014 (SP1). Earlier versions of RBS
will not work with SharePoint Server 2016.
IMPORTANT
SharePoint Server 2013 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 SQL Server 2008 R2. Earlier versions of RBS will not work with SharePoint
2013. 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 Server 2016 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 Yes Only if supported by the RBS provider
recovery of the BLOB Store that you are using.
Scripted migration to BLOBs Yes Yes
Supports mirroring No No
Log shipping Yes Yes, with provider implementation
Database snapshots No* No*
Geo replication Yes No
Encryption NTFS only Only if supported by the RBS provider

that you are using.
Local drives supported Yes Yes, with provider implementation
Network attached storage (NAS) Only supported by SharePoint Server Yes, with provider implementation
with iSCSI and if Time to First Byte is
less than 20 milliseconds.
Direct attached storage (DAS) Not supported by SharePoint Server Yes, with provider implementation
Internet small computer system Yes Yes, with provider implementation

interface (iSCSI)
* If 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
Remote Blob Store (RBS ) (SQL Server)
SQL Server Remote BLOB Store and FILESTREAM feature comparison
Install and configure RBS with FILESTREAM in a
SharePoint Server farm

SharePoint Server uses the RBS feature to store binary large objects (BLOBs) outside the content database. For
more information about RBS, see Overview of RBS in SharePoint Server.
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.
TIP
This solution uses the FILESTREAM RBS provider that is included with SQL Server 2014, Service Pack 1 SP1, SP2, SQL Server
2016, SQL Server 2016 SP1, and SQL Server 2008. If you want to install and configure RBS using a different provider, use
the procedure in Install and configure RBS with a 3rd party provider for SharePoint Server.
Before you begin

You only have to install and configure RBS with the FILESTREAM provider one time for the farm. However, if you
want to enable RBS using different providers for specific content databases, you must configure RBS to use those
providers. For more information about doing that, see Install and configure RBS with a 3rd party provider for
SharePoint Server.
The user account used to perform the steps in the Provision a BLOB store for each content database section
must be a member of the db_owner fixed database role on each database that you are configuring RBS for.
The user account installing the client library in the steps in the Install the RBS client library on SQL Server
and each Front-end or Application server section must be a member of the Administrators group on all of
the computers where you are installing the library.
The user account enabling RBS in the Enable RBS for each content database section must have sufficient
permissions to run Microsoft PowerShell.
Enable FILESTREAM on the database server

By default, the FILESTREAM feature is installed when you install SQL Server. But it is not enabled. You must
enable and configure FILESTREAM on the computer that is running SQL Server that hosts the SharePoint Server
databases. You must:
1. Enable FILESTREAM for Transact-SQL access
2. Enable FILESTREAM for file I/O streaming access.
3. Allow remote clients to have streaming access to FILESTREAM data if you need remote client access.
To enable FILESTREAM for file I/O and to allow clients access, follow the instructions in Enable and Configure
FILESTREAM. You only have to configure these settings 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 that you want to use RBS
with.
To provision a BLOB store
1. Confirm that the user account performing these steps is a member of the db_owner fixed database role on
each database that you are configuring RBS for.
3. Connect to the instance of SQL Server that hosts the content database.
4. Expand Databases.
5. Click the content database for which you want to create a BLOB store, and then click New Query.
6. 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'll 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.
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'
use [WSS_Content]
if not exists
(select groupname from sysfilegroups
where groupname=N'RBSFilestreamProvider')
alter database [WSS_Content]
add filegroup RBSFilestreamProvider contains filestream
use [WSS_Content]
alter database [WSS_Content]
add file (name = RBSFilestreamFile, filename =
'c:\Blobstore')
to filegroup RBSFilestreamProvider
Install the RBS client library on SQL Server and each Front-end or
Application server
You must install RBS client library on the SQL Server node and all Front-end or Application servers in the
SharePoint farm. The RBS client library is installed only one time 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.
Cau t i on
Do not install the RBS client library by running the RBS_amd64.msi file and starting the Install SQL Remote
BLOB Storage wizard. The wizard sets certain default values that are not recommended for SharePoint Server
To install the RBS client library on the SQL Server.
1. Confirm that the user account performing these steps is a member of the Administrators group on the
computer where you are installing the library.
2. On SQL Server node, download the correct RBS client based on the SQL Server version and SharePoint
level that you use.
SharePoint Server 2016 supports the FILESTREAM provider that is included in the , SP1, SP2, SQL Server
2016, and SQL Server 2016 SP1.
SharePoint 2013 supports the FILESTREAM providers that are included in all versions of SQL Server 2008
R2, SQL Server 2012, and .
You only need to download the RSB.msi file from the Feature Pack but make sure you download the correct
processor type for your server, either x86 or x64.
For SharePoint Server 2016, choose the correct install from the following list:
Microsoft SQL Server 2014 SP1 Feature Pack
For SharePoint 2013, choose the correct install from the following list:
Microsoft® SQL Server® 2008 R2 Feature Pack
Microsoft SQL Server 2008 R2 SP1 Feature Pack
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 action
should finish within approximately one minute.
msiexec /qn /lvx* rbs_install_log.txt /i RBS_amd64.msi TRUSTSERVERCERTIFICATE=true FILEGROUP=PRIMARY
DBNAME="WSS_Content" DBINSTANCE="DBInstanceName" FILESTREAMFILEGROUP=RBSFilestreamProvider
FILESTREAMSTORENAME=FilestreamProvider_1
To install the RBS client library on all SharePoint Front-end and Application servers
2. On any web server, download the correct RBS client based on the SQL Server version and SharePoint level
that you use. Use one of the following lists to choose the correct install. Run the self-extracting download
package to create an installation folder for the X64 RBS.msi file.
SharePoint Server 2016 supports the FILESTREAM provider that is included in the , SP1, SP2, SQL Server
2016, and SQL Server 2016 SP1.
SharePoint 2013 supports the FILESTREAM providers that are included in all versions of SQL Server 2008
R2, SQL Server 2012, and .
You only need to download the RSB.msi file from the Feature Pack but make sure you download the correct
processor type for your server, either x86 or x64.
For SharePoint Server 2016, choose the correct install from the following list:
For SharePoint 2013, choose the correct install from the following list:
Microsoft® SQL Server® 2008 R2 Feature Pack
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 action should
finish within approximately one minute.
msiexec /qn /lvx* rbs_install_log.txt /i RBS_amd64.msi DBNAME="WSS_Content" DBINSTANCE="DBInstanceName"
ADDLOCAL=Client,Docs,Maintainer,ServerScript,FilestreamClient,FilestreamServer
> [!NOTE]
> If you attempt to install SQL Server 2012 Remote Blob Store for an additional database on the same instance
of SQL Server, you will receive an error. For more information, see [KB2767183]
(https://support.microsoft.com/en-us/kb/2767183).
For subsequent content databases for which you want to enable RBS, change the msiexec command similar to
below.
msiexec /qn /lvx* rbs_install_log_ContentDbName.txt /i RBS_amd64.msi REMOTEBLOBENABLE=1

FILESTREAMPROVIDERENABLE=1 DBNAME="WSS_Content_2" ADDLOCAL="EnableRBS,FilestreamRunScript"
DBINSTANCE="DBInstanceName"
4. Repeat this procedure for all Front-end servers and Application servers in the SharePoint farm.
NOTE
If you install Visio web services on SharePoint Server application servers that do not have an RBS provider installed, a
Visio error occurs when you attempt to open a Visio diagram from this server. You must install an RBS client on
SharePoint Server servers that run the Visio Graphics Service if you want to open Visio diagrams on that server.
To confirm the RBS client library installation

1. The rbs_install_log.txt log file is created in the same location as the RBS_amd64.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 Service Pack 1 (SP1) or 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".
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 one time for each content database.
NOTE
You can only enable RBS by using Microsoft PowerShell.
To enable RBS by using Microsoft PowerShell

$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.
Assign db_owner permissions to the web application

IMPORTANT
Make sure that the web application that accesses the RBS-enabled content database is a member of the db_owner fixed
database role for that database.
Test the RBS installation

You should test the RBS installation on one Front-end server in the SharePoint farm to make sure 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.
7. Browse to the file list and open the file that has the most recent changed date. This should be the file that
you uploaded.
See Also
Enable and Configure FILESTREAM
Install and configure RBS with a 3rd party provider
for SharePoint Server

SharePoint Server uses the RBS feature to store BLOBs outside the content database. For more information about
RBS, see Overview of RBS in SharePoint Server.
IMPORTANT
This solution uses a third-part provider. Before continuing, make sure that you read the instructions from the manufacturer
of the provider. If you want to install and configure RBS using the FILESTREAM provider, use the procedure in Install and
configure RBS with FILESTREAM in a SharePoint Server farm.
Do not directly access BLOBs when you are using third-party providers. Always access these BLOBs by using
SharePoint Server.
Before you begin

You only have to install and configure RBS with the specific third-part provider one time for the farm. However, if
you want to enable RBS using the FILESTREAM provider, use the procedure in Install and configure RBS with
The user account provisioning RBS stores must be a member of the db_owner fixed database role on each
database that you are configuring RBS for.
The user account installing the client library must be a member of the Administrators group on all of the
computers where you are installing the library.
The user account enabling RBS must have sufficient permissions to run PowerShell.
Install the RBS client library on each front-end or application server

You must install RBS client library on all Web servers in the SharePoint farm. The RBS client library is installed
only one time 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, and also a set of stored procedures to be
installed on SQL Server.
Cau t i on
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 Server.
To install the RBS client library on the on the first front-end or application server
2. On any front-end or application server, for SharePoint Server 2016, download the Microsoft SQL Server
2014 Feature Pack. Run the self-extracting download package to create an installation folder for the X64
RBS.msi file.
For SharePoint 2013, download the RBS_amd64.msi file.
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
msiexec /qn /lvx* rbs_install_log.txt /i RBS-x64.msi TRUSTSERVERCERTIFICATE=true FILEGROUP=PRIMARY

DBNAME="WSS_Content" DBINSTANCE="DBInstanceName
To install the RBS client library on all additional front-end and application servers
2. On any web server, for SharePoint Server 2016, download the Microsoft SQL Server 2014 Feature Pack.
Run the self-extracting download package to create an installation folder for the X64 RBS.msi file.
For SharePoint 2013, download the RBS_amd64.msi file.
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
msiexec /qn /lvx* rbs_install_log.txt /i RBS_x64.msi DBNAME="WSS_Content" DBINSTANCE="DBInstanceName"

ADDLOCAL=Client,Docs,Maintainer,ServerScript,FilestreamClient,FilestreamServer
4. Repeat this procedure for all Web servers in the SharePoint farm.
5. Run the following command on each application server in the SharePoint farm:
Msiexec /qn /1vx* rbs_install_log.txt /I RBS_x64.msi ADDLOCAL="Client"
To confirm the RBS client library installation

1. The rbs_install_log.txt log file is created in the same location as the RBS_x64.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 2014 Service Pack 1 (SP1) or 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 third-party provider

The steps that you use to install the third-part 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 front-end server in the SharePoint farm. It is not important which front-end 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 one time for each content database.
NOTE
You can only enable RBS by using Microsoft PowerShell.
To enable RBS by using PowerShell

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

Test the RBS installation

You should test the RBS installation on one Web server in the SharePoint farm to make sure that that the system
works correctly.
3. Confirm that the folder is empty.
4. On the SharePoint farm, upload a file to a document library.
7. Browse to the file list and open the file that has the most recent changed date. This should be the file that
you uploaded.
See also
Concepts
Other Resources
Enable and Configure FILESTREAM
Set a content database to use RBS with FILESTREAM

This article describes how to set a content database to use Remote BLOB Storage (RBS ) that uses the
FILESTREAM provider. If you are using a third-party provider, these instructions might not apply. For more
information, contact the manufacturer of the provider. These instructions assume that you have already installed
RBS for use with SharePoint Server. To install and configure RBS, see Install and configure RBS with
Before you begin

You must perform this procedure on every content database that you want to set to use RBS.
The user account that you use to perform this procedure is a member of the Administrators group on the
Web.
The user account that you use to perform this procedure is a member of the SQL Server dbcreator and
securityadmin fixed server roles on the computer that is running SQL Server 2014 Service Pack 1 (SP1),
SQL Server 2008 R2 with Service Pack 1 (SP1), SQL Server 2012, or SQL Server 2014.
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 front-end or application server, and then test the
RBS data store.
These instructions assume that you have installed SQL Server Management Studio on the database server. You
can perform the following procedures on any front-end or application server in the farm.
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 SQL Server 2014 SP1, SQL Server 2008 R2 with Service Pack 1
(SP1), SQL Server 2012, or SQL Server 2014.
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.
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'
use [ContentDbName]
if not exists (select groupname from sysfilegroups where groupname=N'RBSFilestreamProvider')
alter database [ContentDbName] add filegroup RBSFilestreamProvider contains filestream
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. Right-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:
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. The operation should finish within approximately one minute.

1. Connect to a document library on any front-end or application server.
2. Upload a file that is at least 100 kilobytes (KB ) to the document library.
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, make sure that RBS is installed and enabled correctly.
See also
Concepts
Migrate content into or out of RBS in SharePoint Server
Other Resources
Migrate content into or out of RBS in SharePoint
Server

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 Microsoft PowerShell 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 decrease in performance for users. Migration moves all content from
the specified content database into the storage mechanism of the newly named provider.
Migrate a content database

This operation can be performed on any front-end or application server in the farm. You only have to perform the
operation one time on one front-end or application server for each content database that you want to migrate.
To migrate a content database by using Microsoft PowerShell
3. At the PowerShell command prompt, type the commands in the following steps.
4. To obtain the content database RBS settings object:
$rbs=(Get-SPContentDatabase <ContentDbName>).RemoteBlobStorageSettings
Where _\<ContentDbName\>_ is the name of the content database.
5. To view a list the RBS providers installed on the Web server:
$rbs.GetProviderNames()
6. To set the active RBS provider:
$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 completely and back into SQL Server inline storage, set
this value to `()`.
7. Migrate the data from RBS to the new provider or to SQL Server:
$rbs.Migrate()
See also
Concepts
Set a content database to use RBS with FILESTREAM in SharePoint Server
Maintain RBS in SharePoint Server

You perform most of the maintenance tasks associated with RBS in SharePoint Server by using the RBS
Maintainer, which is a tool in SQL Server. The RBS Maintainer performs periodic garbage collection and other
maintenance tasks for a SharePoint Server RBS deployment. You can schedule these tasks for each database that
uses RBS by using Windows Task Scheduler or 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.
Configure RBS Garbage collection

SharePoint Server automatically marks unreferenced or deleted BLOB data for removal. SharePoint Server counts
references to BLOBs by looking at the list of BLOB IDs stored by SharePoint Server 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 Server 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 Server and will be marked for removal.
Because SharePoint Server 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 Server 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 Server content
database that has 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 were marked for deletion for some 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, such as how to configure the settings, see Running RBS Maintainer.
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 Server 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 Server 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 command
line parameters that are listed in Running RBS Maintainer.
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 follow these steps every time that you schedule a task to run the
RBS Maintainer:
On the Start menu, click Administrative Tools, and then click Task Scheduler.
On the Action menu, click Create Task.
On the Actions tab, click New.
In the New Action dialog box, in the Action drop-down list, select Start a program.
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>
Click OK.
On the Triggers tab, click New.
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.
On the General tab, under Security, make sure that the user account has the appropriate permissions to
run the task. You can change permissions by clicking Change User or Group.
On the General tab, click Run whether user is logged on or not, and then click OK.
See also
Concepts
Install and configure RBS with FILESTREAM in a SharePoint Server farm
Migrate content into or out of RBS in SharePoint Server
Disable RBS on content databases in SharePoint Server
Disable RBS on content databases in SharePoint
Server

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 Microsoft
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.
Disable RBS for a content database

This operation can be performed on any Web server in the farm. You only have to perform the operation one time
on one Web server for each content database for which you want to disable RBS.
Cau t i on
Do not use the Disable() method on the RemoteBlobStorageSettings object. This method is used only to
uninstall RBS, and we do not recommend that you just disable the writing of new BLOBs into RBS. To completely
remove RBS, perform the below task and then use Move-SPSite to move all sites into a non-RBS enabled
database. This will allow you to delete the content database that previously had RBS enabled.
You must use Microsoft PowerShell cmdlets to disable RBS. There is no user interface option for this task.
To disable RBS by using PowerShell
$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.
See also
Concepts
Best practices for SQL Server in a SharePoint Server
farm

When you configure and maintain SharePoint Server 2016 and 2019 relational databases on SQL Server 2014
with Service Pack 1 (SP1), SQL Server 2016, or SQL Server 2017 RTM, you have to choose options that promote
performance and security. Likewise, you have to choose options that promote performance and security when you
configure and maintain SharePoint Server 2013 relational databases on SQL Server 2008 R2 with Service Pack 1
(SP1), SQL Server 2012, and SQL Server 2014.
The best practices in this article are ordered based on the sequence in which they would apply, from installing and
configuring SQL Server, to deploying SharePoint Server, and then maintaining the farm. Most of the practices
apply to all versions of SQL Server. Practices that are unique to SQL Server versions are shown in separate
sections.
NOTE
If you plan to use SQL Server Business Intelligence components in a SharePoint Server 2016 farm you must use SQL Server
2016 CTP 3.1 or later. You can now download SQL Server 2016 CTP 3.1 or later to use the SQL Server Power Pivot for
SharePoint add-in. You can also use Power View by installing SQL Server Reporting Services (SSRS) in SharePoint-integrated
mode and the SSRS front-end add-in from the SQL Server installation media.
NOTE
If you plan to use SQL Server Business Intelligence components in a SharePoint Server 2013 farm you must use SQL Server
2012 with Service Pack 1 (SP1) or SQL Server 2014. For information about SQL Server 2012 with SP1 BI and SharePoint
Server 2013, see Install SQL Server BI Features with SharePoint 2013 (SQL Server 2012 SP1). For more information about
SQL Server 2014 and SharePoint Server 2013, see Install SQL Server 2014 Business Intelligence Features.
IMPORTANT
Best practices in this article apply to the Relational Database Management System (RDBMS) of SQL Server with SharePoint
Server.
Use a dedicated server for SQL Server

To ensure optimal performance for farm operations, we recommend that you install SQL Server on a dedicated
server that does not run other farm roles and does not host databases for other applications. The only exception is
deployment of SharePoint Server 2016 or 2019 in a Single-Server farm role or SharePoint 2013 on a stand-alone
server, which is meant for development or testing, and is not recommended for production use. For more
information, see Description of MinRole and associated services in SharePoint Servers 2016 and 2019 and Install
SharePoint Servers 2016 or 2019 on one server.
NOTE
The recommendation to use a dedicated server for relational databases also applies to deploying SQL Server in virtual
environments.
Configure specific SQL Server settings before you deploy SharePoint

Server
To ensure consistent behavior and performance, configure the following options and settings before you deploy
SharePoint Server.
Do not enable auto-create statistics on SharePoint content databases. Enabling auto-create statistics is not
supported for SharePoint Server. SharePoint Server configures the required settings during provisioning
and upgrade. Manually enabling auto-create statistics on a SharePoint database can significantly change
the execution plan of a query. The SharePoint databases either use a stored procedure that maintains the
statistics (proc_UpdateStatistics) or rely on SQL Server to do this.
For SharePoint Server 2013, Maintenance Plans are managed by SharePoint:
SQL statistics are managed by the health rule “Databases used by SharePoint have outdated index
statistics” that calls proc_updatestatics
Content databases have the Auto Update Statistics property set to False
For SharePoint Servers 2016 and 2019, SQL administrator must create Maintenance Plans for SharePoint
content databases:
SQL statistics are not managed by the health rule “Databases used by SharePoint have outdated index
statistics”
Content databases have the Auto Update Statistics property set to True `
Set max degree of parallelism (MAXDOP ) to 1 for instances of SQL Server that host SharePoint databases
to make sure that a single SQL Server process serves each request.
IMPORTANT
Setting the max degree of parallelism to any other number can cause a less optimal query plan to be used that will
decrease SharePoint Server performance.
To help simplify maintenance, such as to make it easier to move databases to another server, create DNS
aliases that point to the IP address for all instances of SQL Server. For more information about DNS or
Hostname aliases, see How to Add a Hostname Alias for a SQL Server Instance.
For more information about these SQL Server settings and options, see Set SQL Server options.
Harden the database server before you deploy SharePoint Server

We recommend that you plan for, and harden the database server before you deploy SharePoint Server. For more
information, see:
Securing SQL Server
Security Center for SQL Server Database Engine and Azure SQL Database
Configure database servers for performance and availability

As is the case with front-end servers and application servers, the configuration for database servers affects how
well SharePoint Server performs. Some databases have to be on the same server as other databases. Conversely,
some databases cannot be on the same server as other databases. For more information, see Description of
MinRole and associated services in SharePoint Servers 2016 and 2019 and Storage and SQL Server capacity
planning and configuration (SharePoint Server).
For guidance about highly available databases that use mirroring, see Database Mirroring (SQL Server).
SQL Server Failover Clustering and Always On Availability Groups
SQL Server 2012 introduced the AlwaysOn Availability Groups feature. This feature is a high availability and
disaster recovery solution that's an alternative to database mirroring and log shipping solutions. AlwaysOn
Availability Groups now support up to nine availability replicas.
NOTE
Database mirroring will be deprecated in future versions of SQL Server. We recommend using Always On Availability Groups.
AlwaysOn Availability Groups require a Windows Server Failover Clustering (WSFC ) cluster. A WSFC resource
group is created for every availability group that is created. For more information, see the following resources:
AlwaysOn Availability Groups (SQL Server)
Overview of AlwaysOn Availability Groups (SQL Server)
Failover Clustering and Always On Availability Groups (SQL Server)
Configure SQL Server AlwaysOn Availability Groups for SharePoint Server
Design storage for optimal throughput and manageability

We recommend that you separate, and prioritize your data among the drives on the database server. Ideally, you
should place the tempdb database, content databases, usage database, search databases, and transaction logs on
separate physical hard disks. The following list provides some guidance. For more information, see Configure
databases.
For collaboration or update-intensive sites, use the following ranking for storage distribution.
The highest ranked item should be in the fastest drives.
RANK ITEM
1 tempdb data files and transaction logs
2 Content database transaction log files
3 Search databases, except for the Search administration

database
4 Content database data files
In a heavily read-oriented portal site, prioritize data and search over transaction logs as follows.
The highest ranked item should be in the fastest drives.
RANK ITEM
1 tempdb data files and transaction logs
2 Content database data files
3 Search databases, except for the Search administration

database
4 Content database transaction log files
Testing and user data shows that insufficient disk I/O for tempdb can significantly impede overall farm
performance. To avoid this issue, allocate dedicated disks for the drive that stores tempdb data files.
For best performance, use a RAID 10 array for the drive that stores tempdb data files. The number of
tempdb data files should equal the number of CPU cores, and each tempdb data file should be set to the
same size.
Separate database data and transaction log files across different disks. If data and log files must share disks
due to space limitations, put files that have different usage patterns on the same disk to minimize
concurrent access requests.
Use multiple data files for heavy-use content databases, and put each on its own disk
To improve manageability, monitor and make adjustments as needed to keep content databases below 200
GB, rather than restrict the database size.
NOTE
If you manually restrict database size in SQL Server, you can cause unexpected system downtime when the capacity
is exceeded.
Proper configuration of I/O subsystems is very important to the optimal performance and operation of SQL
Server systems. For more information, see Monitoring Disk Usage
TIP
Consider that how you measure disk speed varies between data files and log files. The fastest drives for database data may
not be the fastest for log files. Consider usage patterns, I/O, and file size.
Proactively manage the growth of data and log files

Following are recommendations to proactively manage the growth of data and log files:
When possible, increase all data files and log files to their expected final size, or periodically increase these
at set periods, for example, every month or every six months, or before rollout of a new storage-intensive
site such as during file migrations.
Enable database autogrowth as a protective measure to make sure that you do not run out of space in data
and log files. Consider the following:
IMPORTANT
You must factor in the performance and operations issues associated with using autogrowth. For more information,
see Considerations for the "autogrow" and "autoshrink" settings in SQL Server.
The default settings for a new database are to grow by 1 MB increments. Because this default setting
for autogrowth results in increases in the size of the database, do not rely on the default setting.
Instead, use the guidance provided in Set SQL Server options.
Set autogrowth values to a fixed number of megabytes instead of to a percentage. The bigger the
database, the bigger the growth increment should be.
NOTE
Use care when you set the autogrowth feature for SharePoint databases. If you set a database to autogrow
as a percentage, for example at a 10-percent (%) growth rate, a database that is 5 GB grows by 500MB
every time that a data file has to be expanded. In this scenario, you could run out of disk space.
Consider for example, a scenario where content is gradually increased, say at 100MB increments,
and autogrowth is set at 10MB. Then suddenly a new document management site requires a very
large amount of data storage, perhaps with initial size of 50 GB. For this large addition, growth at
500 MB increments is more appropriate than 10MB increments.
For a managed production system, consider autogrowth to be merely a contingency for unexpected
growth. Do not use the autogrow option to manage your data and log growth on a day-to-day basis.
Instead, set the autogrowth to allow for an approximate size in one year and then add a 20 percent
margin for error. Also set an alert to notify you when the database runs low on space or approaches
a maximum size.
Maintain a level of at least 25 percent available space across drives to accommodate growth and peak
usage patterns. If you add drives to a RAID array or allocate more storage to manage, monitor capacity
closely to avoid running out of space.
Continuously monitor SQL Server storage and performance

We recommend that you continuously monitor SQL Server storage and performance to make sure that each
production database server is adequately handling the load put on it. Additionally, continuous monitoring enables
you to establish benchmarks that you can use for resource planning.
Take a comprehensive view of resource monitoring. Do not limit monitoring to resources that are specific to SQL
Server. It is equally important to track the following resources on computers that are running SQL Server: CPU,
memory, cache/hit ratio, and the I/O subsystem.
When one or more of the server resources seems slow or overburdened, consider the following performance
guidelines based on the current and projected workload.
Monitor and Tune for Performance
Performance Monitoring and Tuning Tools
Server Performance and Activity Monitoring
Windows Performance Monitor
Use backup compression to speed up backups and reduce file sizes

Backup compression can speed up SharePoint backup operations. It is available in SQL Server Standard and
Enterprise Edition. If you set the compression option in your backup script or configure SQL Server to compress
by default, you can significantly reduce the size of your database backups and shipped logs. For more information,
see Backup Compression (SQL Server) and Data Compression, or Enable Compression on a Table or Index
Acknowledgements
The SharePoint Server Content Publishing team thanks the following contributors to this article:
Kay Unkroth, Senior Program Manager, SQL Server
Chuck Heinzelman, Senior Program Manager, SQL Server
See also
Concepts
Storage and SQL Server capacity planning and configuration (SharePoint Server)
Other Resources
Configure log shipping in SharePoint Server

With log shipping, you back up the transaction logs from a primary database to a secondary database on a
separate instance of SQL Server. In the scenario described here, SQL Server log shipping is used together with
Distributed File System Replication (DFSR ) to copy databases and transaction logs to the recovery farm in
Microsoft Azure as illustrated below.
In this disaster recovery scenario the SharePoint Server production farm is located on-premises and the recovery
farm is located in Azure. You can also adapt the guidance in this topic for other types of disaster-recovery
scenarios.
Elements of a warm standby solution in Azure
In the illustration:
Two environments are illustrated side by side: the on-premises SharePoint farm and the recovery (standby)
farm in Azure.
Each environment includes a file share.
Log shipping is used to copy logs from the secondary database server in the on-premises environment to
the local file share.
DFSR copies files from the file share in the on-premises environment to the file share in the Azure
environment. In a WAN scenario, DFSR is more efficient than shipping the logs directly to the secondary
server in Azure.
Log shipping replays the logs from the file share in the Azure environment to the primary replica in the
SQL Server AlwaysOn availability group in the recovery environment.
Log-shipped databases are not attached to the SharePoint Server farm until a recovery exercise is
performed.
The following diagram shows the seven phases that the complete SharePoint Server disaster recovery in Azure
solution contains. Phase 6: Set up log shipping to the recovery farm is highlighted in this diagram and explained in
the following sections.
Using log shipping for disaster recovery

Log shipping enables you to automatically send transaction log files for databases from a primary database server
instance to a secondary database server instance. In our on-premises test environment, we use AlwaysOn
availability groups with two replicas for high availability. We configured log shipping on both replicas. Each replica
must be able to ship transaction logs. Only the replica that is active and owns the database can ship logs. However,
if a failover event occurred and the secondary replica became active, it would have to ship transaction logs instead
of the failed replica.
After the transaction logs are received in the Azure environment, they are restored, one at a time, to each
SharePoint database on the secondary database server. For more information about our test environment, see
Microsoft proof of concept environment.
NOTE
Some organizations use a third database server as a monitor to record the history and status of backup and restore
operations. This optional monitor server creates alerts when backup operations fail.
For detailed information about log shipping, refer to the articles listed in the following table.
Table: Reference articles for log shipping
URL DESCRIPTION
About Log Shipping (SQL Server) Describes log shipping transaction log backups and the
options that are available.
Configure Log Shipping (SQL Server) Describes how to configure log shipping in SQL Server 2012
by using SQL Server Management Studio or Transact-SQL.
View the Log Shipping Report (SQL Server Management Explains how to view the Transaction Log Shipping Status
Studio) report in SQL Server Management Studio. You can run a
status report at a monitor server, primary server, or
secondary server.
Performance considerations
Log shipping consists of three jobs. Each job performs one of the following operations:
1. Backs up the transaction log at the primary server instance.
2. Copies the transaction log file to the secondary server instance.
3. Restores the log backup on the secondary server instance.
Each job operates on a schedule and runs for an interval, which can have a significant impact on the database
server and, by default, SharePoint farm performance.
To correctly set the backup, copy, and restore job intervals for log shipping, you must analyze the amount of data
that is being log shipped. The amount of log shipped data is affected by the daily amount of change in the content
databases. The percentage of change can vary greatly depending on the content, maintenance changes, and usage
peaks.
To get an accurate percentage of change, calculate the sum of changes in the transaction log backups for each
content database that you log ship over a given interval. Use this data to calculate the percentage of change
compared to the primary database.
The following guidance is derived from the log-shipping experience of Microsoft field personnel with several
releases of SharePoint Server.
Avoid performance degradation due to all jobs starting at the same time by making sure that all log-
shipping jobs are offset with at least a one-minute delay from the previous job.
It is better to back up and copy many small transaction logs instead of a few large transaction logs.
Schedule log backups and copying at frequent intervals. You can restore the transaction logs at less frequent
intervals. For example, start by using backup and copy intervals of five minutes, and a restore interval of 15
minutes.
Prerequisites for configuring log shipping

Make sure that you meet the following prerequisites for using log shipping for a disaster-recovery solution.
The SQL Server logins are domain accounts that have the permission levels needed for log shipping. The
log-shipping stored procedures require membership in the sysadmin fixed server role.
The primary database must use the full or bulk-logged recovery model.
Cau t i on
If you switch the database to simple recovery, log shipping will stop working.
Before you configure log shipping, you must create a share to make the transaction log backups available to
the secondary server. This is a share of the directory where the transaction log backups are generated.
In addition to your Recovery Point Objectives (RPO ), ensure that the recovered farm data is as complete and
uncorrupt as possible. To reach these goals, you must carefully plan and schedule every aspect of log shipping.
Log shipping infrastructure

The log-shipping infrastructure used for our disaster-recovery solution environment is shown in the following
diagram.
Log shipping infrastructure and data flow
The previous diagram shows the log shipping infrastructure and data flow. The diagram shows the SQL Server
database servers and the file servers in the production farm and the Azure recovery farm. These farms are nearly
identical, and each contains a primary and secondary replica for each AlwaysOn availability group. The file servers,
FIL1 and AZ -FIL1, are configured the same, including the number of hard disks and disk sizes. Additional servers
in the farm are not shown.
To provide high availability, each replica in an availability group stores a backup (full, differential, and transaction
logs) of the other replica.
The primary and secondary replicas (SQL -HA1 and SQL -HA2, respectively) make backups that are stored on its
partner in the availability group.
Transaction log shipping is configured on the secondary replica to minimize the impact of backups on the
production databases. These transaction logs are written to a shared folder on the on-premises file server (FIL1).
The Windows Server Distributed File System (DFS ) Replication Service copies the transaction logs from FIL1 to
AZ -FIL1. The transaction logs on AZ -FIL1 are restored to AZ -SQL -HA1, the primary replica for the availability
group in the recovery farm.
Steps required to configure and validate log shipping

The required steps to configure, run, and validate log shipping are condensed and summarized in the following list:
1. Back up the database.
2. Configure the full and differential backups to a local folder and also a shared folder on the file server.
3. Verify backups were made to both the local folder and shared folder.
4. Set up and test Distributed File System (DFS ) Replication.
5. Create Namespace and Replication to transfer the transaction logs and backup files between the on-
premises and Azure farms on the shared folder in file server.
6. Verify all transfers after log shipping runs.
7. Set up and test log shipping.
8. Set up log shipping on the primary database server by using the following script: Primary-
Logshippingsetupparameter. This script creates backup jobs, schedules them for log shipping and then
initiates the jobs.
SET NOCOUNT ON
USE MSDB
GO
--@PrimServer : Primary Server name
--@SecServer : DR/Secondary Server Name
--@SecInstance : DR/Secondary FQDN
--@Domain : Domain Name
--@BkpDrive : Production Backup server Name
--@DBName : DatabaseName
DECLARE @LS_BackupJobIdAS uniqueidentifier, @LS_PrimaryIdAS uniqueidentifier , @SP_Add_RetCode As int
DECLARE @Time as nvarchar(10),@SecInstance as nvarchar(250), @PrimServer as nvarchar(50),@SecServer as
nvarchar(50),
@Domain as nvarchar(50),@DBName as nvarchar(max),@BkpDrive as nvarchar(250),@CMD as nvarchar(max),@Counter int
----------------------------------------------------------------------------
IF OBJECT_ID ('tempdb.DBO.#LogShipping','U') IS NOT NULL DROP TABLE #LogShipping
Create table #LogShipping ( LSDBs nvarchar(max))
Set @PrimServer ='SQL1'
Set @SecServer ='SQL2'
Set @SecInstance ='SQL2.corp.adventureworks.com'
Set @Domain ='corp.adventureworks.com'
Set @BkpDrive ='FS1.corp.adventureworks.com'
Set @DBName = 'Social_DB'
Set @Time = '0130'
SET @DBName = UPPER(REPLACE(@DBName, ' ', ''))
SET @DBName = '''' + REPLACE(@DBName, ',', ''', ''') + ''''
Set @CMD = ' Select ' +
'''DECLARE @SP_Add_RetCode As int, @LS_BackupJobIdAS uniqueidentifier, @LS_PrimaryIdAS uniqueidentifier
EXEC @SP_Add_RetCode = master.dbo.sp_add_log_shipping_primary_database ' + CHAR(10) +
'@database = '''''' + db.Name + ''''''' + CHAR(10) +
',@backup_directory = ''''\\' + @BkpDrive + '\LS\' + ''' + db.Name + ''''' + '''' + CHAR(10) +
',@backup_share = ' + '''''\\' + @BkpDrive + '\LS\' + ''' + db.Name + ''''' + '''' + CHAR(10) +
',@backup_job_name = ''''' + 'LSBackup_' + ''' + db.Name + ''''' + '''' + CHAR(10) +
',@backup_retention_period = 4320
,@backup_compression = 1
,@backup_threshold = 180
,@threshold_alert_enabled = 1
,@history_retention_period = 5760
,@backup_job_id = @LS_BackupJobId OUTPUT
,@primary_id = @LS_PrimaryId OUTPUT
,@overwrite = 1 ' +
'IF (@@ERROR = 0 AND @SP_Add_RetCode = 0)
BEGIN
DECLARE @LS_BackUpScheduleUIDAs uniqueidentifier ,@LS_BackUpScheduleIDAS int
EXEC msdb.dbo.sp_add_schedule
@schedule_name = ''''' + 'LSBackupSchedule_'+ @PrimServer + '_' + ''' + db.Name + ''''' + '''' + CHAR(10) +
',@enabled = 1
,@freq_type = 4
,@freq_interval = 1
,@freq_subday_type = 4
,@freq_subday_interval = 13
,@freq_recurrence_factor = 0
,@active_start_date = 20090506
,@active_end_date = 99991231
,@active_start_time = ' + @Time + CHAR(10) +
',@active_end_time = 235900
,@schedule_uid = @LS_BackUpScheduleUID OUTPUT
,@schedule_id = @LS_BackUpScheduleID OUTPUT
EXEC msdb.dbo.sp_attach_schedule @job_id = @LS_BackupJobId ,@schedule_id = @LS_BackUpScheduleID
EXEC msdb.dbo.sp_update_job @job_id = @LS_BackupJobId ,@enabled = 1
END
EXEC master.dbo.sp_add_log_shipping_alert_job
EXEC master.dbo.sp_add_log_shipping_primary_secondary
@primary_database = ''' + ''''' + db.Name + ''''' + '''' + CHAR(10) +
',@secondary_server = ''''' + @SecInstance + '''''' + CHAR(10) +
',@secondary_database = ''' + ''''' + db.Name + ''''' + '''' + CHAR(10) +
',@overwrite = 1 ''' +
' [LSDBs] FROM sys.databases db where name in (' + @DBName + ')' +
'and db.name not in (''master'',''model'',''msdb'',''tempdb'',''metricsops'',''periscope'' )
and Not (exists (select lss.Secondary_database from msdb.dbo.log_shipping_Secondary_databases lss where
db.Name = lss.Secondary_database)
or exists (select lsp.primary_database from msdb.dbo.log_shipping_primary_databases lsp where db.Name =
lsp.primary_database)
)'
Insert #LogShipping (LSDBs)
Exec ( @CMD)
Set @Counter = @@rowcount
While (@counter > 0)
Begin
select top 1 @CMD = LSDBs from #LogShipping
exec sp_executesql @CMD
set @counter = @counter - 1
delete top (1) from #LogShipping
End
-- ****** End: Script to be run at Primary: [DB1-PSMSQL-01] ******
2. Set up log shipping on a secondary database server by using the following script: Secondary-
Logshippingsetupparameter scripts. In our lab environment, the secondary database server is in recovery
farm located in Azure.
-- ****** Begin: Script to be run at Secondary: 9.3 BUILD******

SET NOCOUNT ON
USE MSDB
GO
--@PrimServer : Primary Server name
--@SecServer : DR/Secondary Server Name
--@SecInstance : DR/Secondary FQDN
--@Domain : Domain Name
--@PrimaryBkpDrive : Production Backup server Name
--@BkpDrive : Secondary Backup server Name
--@DBName : DatabaseName
DECLARE @LS_BackupJobIdAS uniqueidentifier, @LS_PrimaryIdAS uniqueidentifier , @SP_Add_RetCode As int
DECLARE @Time as nvarchar(10),@SecInstance as nvarchar(250), @PrimServer as nvarchar(50),@SecServer as
nvarchar(50),
@Domain as nvarchar(50),@DBName as nvarchar(max),@PrimaryBkpDrive as nvarchar(250),@BkpDrive as
nvarchar(250),@CMD as nvarchar(max),@CMD2 as nvarchar(max),@Counter int
DECLARE @Delimeter char(1),@DB nvarchar(200), @StartPos int, @Length int
Create table #LogShipping ( LSDBs nvarchar(max))
IF OBJECT_ID ('tempdb.DBO.#DBs','U') IS NOT NULL DROP TABLE #DBs
Create TABLE #DBs (Name nvarchar(200))
Set @PrimServer ='az-sql-ha1'
Set @SecServer =' az-sql-ha2'
Set @SecInstance ='SQL1.corp.adventureworks.com'
Set @Domain =' corp.adventureworks.com '
SET @PrimaryBkpDrive = 'fs1.corp.adventureworks.com'
Set @BkpDrive =' az-sp-fs.corp.adventureworks.com '
Set @DBName = 'Social_DB'
Set @Time = '0130'
--Parsing Function
SET @Delimeter = ','
WHILE LEN(@DBName) > 0
BEGIN
SET @StartPos = CHARINDEX(@Delimeter, @DBName)
IF @StartPos < 0 SET @StartPos = 0
SET @Length = LEN(@DBName) - @StartPos - 1
IF @Length < 0 SET @Length = 0
IF @StartPos > 0
BEGIN
SET @DB = Rtrim(Ltrim(SUBSTRING(@DBName, 1, @StartPos - 1)))
SET @DBName = SUBSTRING(@DBName, @StartPos + 1, LEN(@DBName) - @StartPos)
END
ELSE
BEGIN
SET @DB = Rtrim(Ltrim(@DBName))
SET @DBName = ''
END
INSERT #DBs (Name) VALUES(@DB)
END
--SET @DBName = UPPER(REPLACE(@DBName, ' ', ''))
--SET @DBName = '''' + REPLACE(@DBName, ',', ''', ''') + ''''
Set @CMD = 'Select ' +
''' DECLARE @LS_Secondary__CopyJobId AS uniqueidentifier, @LS_Secondary__RestoreJobId AS uniqueidentifier
,@LS_Secondary__SecondaryId AS uniqueidentifier , @LS_Add_RetCode As int ,@LS_Add_RetCode2 As int
DECLARE @LS_SecondaryCopyJobScheduleUIDAs uniqueidentifier ,@LS_SecondaryCopyJobScheduleIDAS int,
@LS_SecondaryRestoreJobScheduleUIDAs uniqueidentifier ,@LS_SecondaryRestoreJobScheduleIDAS int
EXEC @LS_Add_RetCode = master.dbo.sp_add_log_shipping_secondary_primary
@primary_server = ''''' + @PrimServer + ''''''+ CHAR(10) +
',@primary_database = '' + ' + ''''''''' + db.Name + ''''''''' + CHAR(10) +
' + '',@backup_source_directory = ' + '''''\\' + @PrimaryBkpDrive + '\LS\'' + db.Name + ''''''' + CHAR(10) +
' ,@backup_destination_directory = ' + '''''\\' + @BkpDrive + '\LS\'' + db.Name + ''''''' + CHAR(10) +
',@copy_job_name = ''''LSCopy_DB1-PSMSQL-01_'' + db.Name + ''''''' + CHAR(10) +
',@restore_job_name = ''''LSRestore_'+ @PrimServer + '_'' + db.Name + ''''''' + CHAR(10) +
',@file_retention_period = 4320
,@overwrite = 1
,@copy_job_id = @LS_Secondary__CopyJobId OUTPUT
,@restore_job_id = @LS_Secondary__RestoreJobId OUTPUT
,@secondary_id = @LS_Secondary__SecondaryId OUTPUT
IF (@@ERROR = 0 AND @LS_Add_RetCode = 0)
BEGIN
@schedule_name =''''DefaultCopyJobSchedule''''
,@enabled = 1
,@freq_type = 4
,@freq_interval = 1
,@active_start_time = ' + @Time + '
,@active_end_time = 235900
,@schedule_uid = @LS_SecondaryCopyJobScheduleUID OUTPUT
,@schedule_id = @LS_SecondaryCopyJobScheduleID OUTPUT
EXEC msdb.dbo.sp_attach_schedule
@job_id = @LS_Secondary__CopyJobId
,@schedule_id = @LS_SecondaryCopyJobScheduleID
@schedule_name =''''DefaultRestoreJobSchedule''''
,@enabled = 1
,@freq_type = 4
,@freq_interval = 1
,@active_start_time = ' + @Time + '
,@active_end_time = 235900
,@schedule_uid = @LS_SecondaryRestoreJobScheduleUID OUTPUT
,@schedule_id = @LS_SecondaryRestoreJobScheduleID OUTPUT
EXEC msdb.dbo.sp_attach_schedule
@job_id = @LS_Secondary__RestoreJobId
,@schedule_id = @LS_SecondaryRestoreJobScheduleID
END
IF (@@ERROR = 0 AND @LS_Add_RetCode = 0)
BEGIN
EXEC @LS_Add_RetCode2 = master.dbo.sp_add_log_shipping_secondary_database
@secondary_database = ' + ''''''' + db.Name + ''''''' + CHAR(10) + '
,@primary_server = ''''' + @PrimServer + '''''
,@primary_database = '+ ''''''' + db.Name + ''''''' + CHAR(10) +
',@restore_delay = 0
,@restore_mode = 1
,@disconnect_users= 1
,@restore_threshold = 180
,@threshold_alert_enabled = 1
,@history_retention_period= 5760
,@overwrite = 1
END
IF (@@error = 0 AND @LS_Add_RetCode = 0)
BEGIN
EXEC msdb.dbo.sp_update_job @job_id = @LS_Secondary__CopyJobId ,@enabled = 0
EXEC msdb.dbo.sp_update_job @job_id = @LS_Secondary__RestoreJobId ,@enabled = 1
END ''' + '[LSDBs] FROM #DBs db'
--Print @CMD
Exec ( @CMD)
Set @Counter = @@rowcount
While (@counter > 0)
Begin
select top 1 @CMD = LSDBs from #LogShipping
exec sp_executesql @CMD
set @counter = @counter - 1
delete top (1) from #LogShipping
End
IF OBJECT_ID ('tempdb.DBO.#DBs','U') IS NOT NULL DROP TABLE #DBs
-- ****** End: Script to be run at Secondary: 9.3 Build ******
3. Verify that the transaction logs are shipped to the share and that DFS is replicating these logs to the share on
the Azure file server. Open the Job Activity Monitor in SQL Server to verify the transaction logs were shipped
successfully. Open the shared folders on both file servers in the production and Azure farms to verify DFS is
transferring the transaction logs.
See also
Concepts
Configure SQL Server AlwaysOn Availability Groups for SharePoint Server
Other Resources
About Log Shipping (SQL Server)
Replication Tutorials
Overview of backup and recovery in SharePoint
Server

The SharePoint Server backup architecture and recovery processes include farm backup and recovery, granular
backup and recovery, and recovery from an unattached content database. You can complete backup and recovery
operations by using the SharePoint Central Administration website or PowerShell cmdlets. Note that some built-
in backup and recovery tools may not meet all the requirements of your organization.
SharePoint 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 in SharePoint Server

SharePoint Server provides two backup systems: farm and granular.
Farm backup architecture in SharePoint Server 2016
The farm backup architecture in SharePoint Server starts a SQL Server backup of content and service
application databases, writes configuration content to files, and also backs up the Search index files and
synchronizes them with the Search database backups.
The following illustration shows the farm backup system.
SharePoint backup system for a farm
The architecture supports both full and differential backups. Full backups create a new backup of the complete
system. Differential backups create a backup of all changes that are stored in databases since the last full backup.
The farm backup system is organized hierarchically. The components in a farm that you can select for backup
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 were made through the object model or Central Administration
NOTE
Changes to the Web.config file that were made to support claims-based applications that use 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 in
SharePoint Server.
Services and service applications (not shared) An example of a service that is not shared is the State
Service. Service and service application backups contain the settings for a service or service application
and any databases associated with it.
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. You select the
service application in one backup, and you select the associated service application proxy in the second backup.
Many service application databases cannot be backed up individually from SharePoint Server. 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. Select the Shared Services node to back up all of the service applications and the related service
application proxies on the farm.
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.
Note that some settings in the SharePoint Server 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
Search service application backup process
Back up and recovery of the Search service application is a special case because of the complexity of interactions
between the components of the application.
When you start a backup of the Search service application, SharePoint Server starts a SQL Server backup of the
Search administration database, crawl databases, and property databases. The process also backs up the index
partition files in parallel.
Consider how the backup and recovery processes for the Search service application affect your service-level
agreement. For example, consider how pausing all crawls might affect the freshness of search results.
The backup process is as follows:
1. Master merges are paused to preserve the master index.
2. A full database backup starts.
3. The master index is backed up.
4. Crawls are paused.
The pause in crawling is much shorter than during a backup of earlier versions of SharePoint search, and
does not last the full duration of the backup process.
5. All shadow indexes are backed up.
6. An incremental database backup starts.
7. Crawls are resumed.
8. Master merges are resumed.
Configuration-only backup use and benefits
A configuration-only backup extracts and backs up the configuration settings from a configuration database. You
can use built-in tools to 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 farm configurations
You can be restore a configuration backup to the same or another server farm. When you restore a configuration,
you overwrite settings in the farm if values for those settings are in the configuration backup. Settings in the
farm that are not in the configuration backup are not changed. For detailed information about how to restore a
farm configuration, see Restore farm configurations in SharePoint Server.
NOTE
Web application and service application settings are not included in a configuration backup. You can use PowerShell
cmdlets to document and copy settings for service applications. For more information, see Document farm configuration
settings in SharePoint Server and Copy configuration settings between farms in SharePoint Server.
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 Server stores the following kinds of settings in the configuration-only backup:
Antivirus
Information rights management (IRM )
Outbound email 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 use
PowerShell to create a backup script, and then use Windows Task Scheduler to run the backup script
regularly.
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 as System Center Configuration Manager.
SharePoint Server 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 recommend that you use backup compression. For more
information about backup compression, see Backup Compression (SQL Server).
If you decide to run databases with transparent data encryption, you must manually back up the key and
restore the key. SharePoint Server backup and restore will not remind you about the key. For more
information about transparent data encryption, see Transparent Data Encryption (TDE ).
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
to which you recover the backup.
SharePoint Server 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 share 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 establish any inter-farm trusts again.
For more information, see Exchange trust certificates between farms in SharePoint Server.
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 register the membership and role providers again in the
Web.config file, and then deploy the providers again. 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 web applications in SharePoint Server, and Plan for user
authentication methods in SharePoint Server.
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, you 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 make sure that data remains consistent while the backup or export is in progress. After you create a
snapshot, SharePoint Server uses it to create the backup or export package, and then deletes the snapshot.
Database snapshots are linked to the source database. When the source database is offline, the snapshot is
unavailable. For more information about database snapshots, see Database Snapshots.
Benefits of backing up a site collection by using a snapshot include the following:
The snapshot makes sure 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.
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 use 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 Server site collection backup for site collections larger than 85 GB.
The following illustration shows the granular backup and export system.
Site collection backup
Recovery processes in SharePoint Server

SharePoint Server supports the following primary, built-in recovery options:
Restore from a farm backup that was created by using built-in tools.
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.
Restores service applications. Service application recovery can be complex because SharePoint Server
cannot fully reconfigure service application proxies during the restore process. Although service
application proxies are restored, they are not put in proxy groups. Therefore, service application proxies
are not associated with any web applications. For more information about how to restore a Search service
application, see Search service application recovery process . For specific information about how to restore
specific service applications, see Restore service applications in SharePoint Server.
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 Server recovery restores all objects as new instances of the object, instead of overwriting
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:
Recreate alternate access mapping settings. SharePoint Server recovery only restores the Default
zone of the web application.
Reconfigure settings for any Business Data Connectivity and Managed Metadata service
application external sources.
Associate service application proxies with proxy groups again 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 name and URL of a web application that you provide match the name and URL an existing
web application in the farm, SharePoint Server 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 recreate 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.
Search service application recovery process
The recovery process for the Search service application varies depending on whether you are restoring as new
or restoring as overwrite. When you restore as overwrite, no additional steps are necessary.
The restore as new process is as follows:
1. Restore the service application as new, and specify the new farm topology information as you restore.
2. Restore the service application proxy as new. If you did not restore the service application proxy, you must
create a new service application proxy and associate it with the Search service application.
3. Associate the service application proxy with the appropriate proxy group and associate the proxy group (if
it is not the default proxy group) with the appropriate Web application.
4. For least-privilege deployments, start the Search service and the Search admin query Web service with
the appropriate account.
For more information about how to recover the Search service application, see Restore Search service
Restoring from a site collection backup
Only site collections can be recovered from a site collection backup.
Recovering from an unattached content database
An unattached content database is a database that is attached to an instance of SQL Server but is not associated
with a web application. SharePoint Server can connect to and back up from an unattached database. For
example, SharePoint Server can connect to read-only content databases that were 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 to SharePoint Server.
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 that is configured to use the SQL
FILESTREAM RBS provider. SharePoint Server uses the currently defined storage provider for that content
database to store recovered content. 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.
See also
Concepts

Typically, you want to have a backup and recovery plan available before you deploy your SharePoint Server
environment. You then need to maintain and update your backup and recovery plan as your SharePoint Server
changes to protect your data.
The stages involved in planning for backup and recovery include determining backup and recovery strategies
for a SharePoint Server 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 backup and recovery for disaster recovery, consider common events, failures, and errors; local
emergencies; and regional emergencies. The sections in this article describe the stages that you must address in
your backup and recovery plan. Each stage is a step toward the final goal of a good backup to use to recover
your SharePoint Server farm. You can customize the stages to meet your needs. Note that your overall backup
and recovery plan is dynamic and must reflect your current SharePoint Server environment.
For more information about SharePoint Server backup and recovery, see Overview of backup and recovery in
SharePoint Server.
Define business requirements for SharePoint farms and services

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 that 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.
Choose what to protect and recover in your SharePoint environment

Your business requirements will help you determine which components of the environment that you must
protect, and the granularity with which you must be able to recover them.
The following tables list 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. As you'll notice, both tables are similar but
specific backup components are shown for each SharePoint Server edition.
SharePoint Server 2016 components for backup and recovery
SYSTEM CENTER
2016 - DATA
PROTECTION
SQL SERVER 2014 MANAGER
SHAREPOINT SERVICE PACK 1 UPDATE ROLLUP 2 FILE SYSTEM
COMPONENT BACKUP (SP1) SQL SERVER 2016 (UR2) BACKUP
Farm Yes Yes (6)
Service Yes
applications
Web application Yes
Content Yes Yes Yes Yes

databases
Site collection Yes (1, 2) Yes (1, 2) Yes (1, 2) Yes (1, 2)
Site Yes (2) Yes (2) Yes (2) Yes
Document Yes (2) Yes (2) Yes (2) Yes

library or list
List item or Yes

document
Content stored Yes (3) Yes (3) Yes (3) Yes (3)
in remote BLOB
stores
Customizations Yes (7) Yes (7) Yes (7) Yes (6, 7)

deployed as
solution
packages
Changes to Yes Yes Yes Yes (4)

Web.config
made by using
Central
Administration
or an API
SharePoint Yes (2, 8) Yes (2, 8) Yes (2, 8) Yes (2, 9)

configuration
settings
Customizations Yes, files can be Yes

not deployed as recovered if
solution protected as
packages files. (4, 5)
Changes to Yes (4) Yes

Web.config not
made by using
Central
Administration
or an API
SYSTEM CENTER
2016 - DATA
PROTECTION
SQL SERVER 2014 MANAGER
SHAREPOINT SERVICE PACK 1 UPDATE ROLLUP 2 FILE SYSTEM
COMPONENT BACKUP (SP1) SQL SERVER 2016 (UR2) BACKUP
IIS Yes (5) Yes

configurations
not set through
SharePoint
Server 2016
SQL Server Yes Yes Yes

Reporting
Services
databases
(1) Farm-level and database-level backup and restore can be used for site collection recovery if a single site
collection is stored in a database.
(2) Farm-level and database-level backups can be used with SharePoint Server 2016 unattached database
recovery to restore site collections, sites, lists, and configurations.
(3) Content stored in remote BLOB stores cannot be restored by using System Center Data Protection
Manager.
(4) Changes to Web.config can be backed up by using file system backup from DPM.
(5) IIS configurations can be recovered by using a bare-metal backup from DPM.
(6) DPM can recover this item by using a combination of a bare-metal backup and SharePoint Server 2016
backup. It cannot be backed up and recovered as an object.
(7) Fully-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.
(8) Configuration settings can be recovered from farm-level backups. For more information, see Restore farms
(9) The Central Administration content database and the configuration database for a SharePoint Server 2016
farm can be recovered but only as part of a full-farm recovery to the same farm, with the same computers.
For more information, see Announcement: Protect your Server 2016 workloads with Enhanced Security.
SharePoint 2013 components for backup and recovery
SQL SERVER 2008

WITH SERVICE SYSTEM CENTER
PACK 1 (SP1) AND 2012 - DATA
SHAREPOINT CUMULATIVE PROTECTION FILE SYSTEM
COMPONENT BACKUP UPDATE 2 SQL SERVER 2012 MANAGER (DPM) BACKUP
Farm Yes Yes (6)
Service Yes
applications
Web application Yes

SQL SERVER 2008
Content Yes Yes Yes Yes

databases
Site collection Yes (1, 2) Yes (1, 2) Yes (1, 2) Yes (1, 2)
Site Yes (2) Yes (2) Yes (2) Yes
Document Yes (2) Yes (2) Yes (2) Yes

library or list
List item or Yes

document
Content stored Yes (3) Yes (3) Yes (3) Yes (3)
in remote BLOB
stores
Customizations Yes (7) Yes (7) Yes (7) Yes (6, 7)

deployed as
solution
packages
Changes to Yes Yes Yes Yes (4)

Web.config
made by using
Central
Administration
or an API
SharePoint Yes (2, 8) Yes (2, 8) Yes (2, 8) Yes (2, 9)

configuration
settings
Customizations Yes, files can be Yes

not deployed as recovered if
solution protected as
packages files. (4, 5)
Changes to Yes (4) Yes

Web.config not
made by using
Central
Administration
or an API
IIS Yes (5) Yes

configurations
not set through
SharePoint 2013
SQL SERVER 2008
SQL Server Yes Yes Yes

Reporting
Services
databases
(1) Farm-level and database-level backup and restore can be used for site collection recovery if a single site
collection is stored in a database.
(2) Farm-level and database-level backups can be used with SharePoint 2013 unattached database recovery to
restore site collections, sites, lists, and configurations.
(3) Content stored in remote BLOB stores cannot be restored by using System Center Data Protection
Manager.
(4) Changes to Web.config can be backed up by using file system backup from DPM.
(5) IIS configurations can be recovered by using a bare-metal backup from DPM.
(6) DPM can recover this item by using a combination of a bare-metal backup and SharePoint 2013 backup. It
cannot be backed up and recovered as an object.
(7) Fully-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.
(8) Configuration settings can be recovered from farm-level backups. For more information, see Restore farms
(9) The Central Administration content database and the configuration database for a SharePoint 2013 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 2013 with Windows Server Backup by using the stsadm.exe -o -registerwsswriter
operation to configure the Volume Shadow Copy Service (VSS) writer for SharePoint 2013. Windows Server Backup then
includes SharePoint 2013 in server-wide backups. When you restore from a Windows Server backup, you can select
SharePoint Foundation (regardless of which version of SharePoint 2013 is installed), and all components reported by the
VSS writer for SharePoint 2013 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 in 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 use solution packages to deploy customizations and use Central
Administration or the SharePoint APIs and object model to configure the Web.config file.
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 SharePoint Designer, 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:
The Visual Studio assemblies for the Activities are stored in the global assembly catalog (GAC ).
The XML definition files (.ACTIONS files) are stored in the 15\TEMPLATE {LCID }\Workflow
directory.
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 Server 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 Server 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. For more information, see "Back up workflows in SharePoint" in Back up customizations in
SharePoint Server.
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 Server farm,
make sure that you back up the folder where you store your workflow project files by using Windows
Server Backup or another file system backup application.
Protecting service applications
Service applications in a SharePoint Server 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 service applications in SharePoint Server.
Protecting SQL Server Reporting Services databases
SharePoint Server backup and recovery does not include SQL Server Reporting Services databases. You must
use SQL Server tools for SharePoint Server. For more information, see Backup and Restore Operations for
Reporting Services.
Choose SharePoint backup and recovery 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 make sure 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.
For detailed information about the backup and recovery systems that can be used with SharePoint Server, see
the following resources:
Backing Up and Restoring Databases in SQL Server
DPM overview
Determine SharePoint backup and recovery 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 Server 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 for SharePoint Server. 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 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 Server 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 Remote Blob Storage (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 Server 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 Server. 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 high availability
and disaster recovery for SharePoint Server.
Plan for performance when designing your SharePoint backup and

recovery strategy
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 and storage for a SharePoint Server
environment. For more information, see Storage and SQL Server capacity planning and configuration
(SharePoint Server).
Minimize latency between SQL Server and the backup location
In general, use a local disk instead of 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 will perform well. If
your farm has multiple servers in it (including the computer that is running SQL Server, 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 Server backups use SQL Server backups. When using compression with your backups, be careful
not to overwhelm SQL Server. 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 Enterprise, we recommend that you use backup compression. For more
information, see Backup Compression (SQL Server).
If you are using SQL Server or 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 backup and restore performance, see
Optimizing Backup and Restore Performance in SQL Server.
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.
See also
Concepts
Other Resources
Data Protection and Recovery
Prepare to back up and restore farms in SharePoint
Server

It is important to make sure that you have backed up and can recover the data that you need if a failure occurs.
Consider the information, procedures, and precautions in this article before you back up and restore your
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.
Requirements to back up and restore SharePoint Server

Before you back up data, create a shared folder that stores the data. For best performance, 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 SQL Server 2008 R2 and SQL Server 2012
database software, must be started for the SharePoint Server 2013 VSS Writer service to work correctly.
By default, the SharePoint Server 2013 VSS Writer service is not automatically started.
This does not apply for SharePoint Server 2016 when you use SQL Server 2014 Service Pack 1 (SP1) or
SQL Server 2016 because both of these database servers automatically start the VSS Writer service.
For SharePoint Server 2013, make sure that the SharePoint Foundation 2013 Administration service is
started on all farm servers before you perform a backup. By default, this service is not started on stand-
alone installations.
Make sure that the user accounts that you want to perform a backup have access to the shared backup
folder.
If you use Central Administration to back up, 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 use SQL Server with Transparent Data Encryption (TDE ), and you use either SharePoint tools or
SQL Server tools to back up your environment, the TDE encryption key is not backed up or restored. You
must manually back up the key. When you restore the environment, you must manually restore the key
before you restore the data. For more information, see Understanding Transparent Data Encryption (TDE ).
Restrictions when you back up and restore SharePoint Server
You can't back up or restore everything in a SharePoint environment. For more information about backup and
recovery architecture and about backup and restore restrictions, see Overview of backup and recovery in
SharePoint Server.
You cannot use a backup made from one version to restore to another version.
You can use a backup made from one version to upgrade to another version.
The update level of the farm to which you restore cannot be lower than the update level of a backup.
The destination farm must have the same or newer update level. For information about how to upgrade,
see Upgrade to SharePoint Server 2016.
If you perform a backup while a task that creates or deletes databases is running, pending changes might not be
included in the backup.
Do not modify the spbackup.xml file. SharePoint Server uses this file. A change can make the backups unusable.
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 SQL Server database software and from the computer that
hosts the SharePoint Central Administration website.
To create a shared folder
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, make sure 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 folder.
4. On the Sharing tab of the Properties dialog box, click Advanced Sharing, and then click Permissions,
add the following accounts and assign them Full Control of the shared folder:
SQL Server service account (MSSQLSERVER )
The SharePoint Central Administration application pool identity account
The SharePoint Timer service account.
See also
Concepts
Backup solutions in SharePoint Server
Restore solutions in SharePoint Server
Configure backup and restore permissions in
SharePoint Server

You can configure backup and restore permissions for SharePoint Server by using the SharePoint Central
Administration website or Microsoft PowerShell. The backup tool that you use depends on the kind of environment
that you have deployed, your backup schedule requirements, and service level agreements that you have made
with your organization.
Before you begin

Before you back up or restore SharePoint Server, you must make sure that the timer service account, SQL Server
service account, and users who run the backup or restore operations have the correct permissions or are members
of the correct Windows security groups or SharePoint groups. You must configure these permissions and group
memberships when you first deploy SharePoint Server. You have to update permissions and group memberships
when you add new farm components to the environment and if you want to add users who will perform backup
and restore operations.
Permissions for the SharePoint Timer service and SQL Server account
The SharePoint Timer Server and the SQL Server service account in SharePoint Server perform backup and
restore operations on behalf of users. 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 make sure all user accounts that use Central Administration to back up or restore your farm and farm
components have the group memberships that are described in the following table.
MEMBER OF ADMINISTRATORS GROUP ON MEMBER OF FARM ADMINISTRATORS

FARM COMPONENT THE LOCAL COMPUTER SHAREPOINT GROUP
Farm Yes No
Service Application Yes No
Content Database Yes No
Site Collection No Yes
Site, list, document library No Yes
Setting permissions to run SharePoint backup and restore operations

by using PowerShell
You must make sure that all user accounts that use PowerShell to back up or restore your farm and farm
components 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 have 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 you add new farm components to your environment or when you want to add users to
perform backup and restore operations.
IMPORTANT
The Add-SPShellAdmin cmdlet grants the SPDataAccess role but this is not enough to complete the restore operation. This
is because the restore-spsite cmdlet uses direct insert statements to add content rather than stored procedures which
accommodate other interactions. The Add-SPShellAdmin cmdlet worked fine in SharePoint 2010 because as part of the
SPDataAccess schema it added dbo permissions. For SharePoint Servers 2019, 2016 and 2013 the db_owner fixed database
role permissions are required to complete restore operations from the SharePoint Management Shell.
To add a user to or remove a user from the SharePoint_Shell_Access role by using PowerShell
cmdlets.
NOTE

Add-SPShellAdmin -Username <User account> -Database <Database ID>
Where:
<Database ID> is the GUID assigned to the database.
To add a user account to all the databases in the farm, type the following command:
ForEach ($db in Get-SPDatabase) {Add-SPShellAdmin -Username <User account> -Database $db}

Where:
<User account> is the user whose account you want to add.
To remove a user account from all the databases in the farm, type the following command:
ForEach ($db in Get-SPDatabase) {Remove-SPShellAdmin -Username <User account> -Database $db}
Where:
<User account> is the user whose account you want to remove.
To view the user accounts currently added to the databases in the farm, type the following command:
ForEach ($db in Get-SPDatabase) {Get-SPShellAdmin -Database $db}
For more information, see Add-SPShellAdmin.
NOTE
You might also have to grant additional permissions to the users who run the backup or restore operation by using
PowerShell. The following table shows the permissions that are required.
MEMBER OF ADMINISTRATORS MEMBER OF FARM

GROUP ON THE LOCAL ADMINISTRATORS FULL CONTROL ON BACKUP
FARM COMPONENT COMPUTER SHAREPOINT GROUP FOLDER
Farm Yes No Yes
Service Application Yes No Yes
Content Database Yes No Yes
Site Collection No Yes Yes
Site, list, document library Yes No Yes
See also
Concepts
Prepare to back up and restore farms in SharePoint Server

The following articles provide information about backup solutions for SharePoint Server. These articles 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. While backups allow
you to restore data after a failure they are also useful to keep for routine purposes. These purposes include
copying a database from one server to another, setting up database mirroring, and archiving to comply with
regulatory requirements.
If you make appropriate backups, you can recover from many system failures, 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)
Natural disasters
Articles about backup for SharePoint Server

The following articles about backup are available to view online. Writers update articles on a continuing basis as
new information becomes available and as users provide feedback.
CONTENT DESCRIPTION
Back up farms in SharePoint Server Back up complete farms.
Back up farm configurations in SharePoint Server Back up farm configuration settings.
Back up web applications in SharePoint Server Back up web application that are associated with the farm and
include configuration and content databases.
Back up service applications in SharePoint Server Back up service applications that are associated with the farm
and include configuration and content databases.
Back up User Profile service applications in SharePoint Server Back up User Profile Service applications that are associated
with the farm and include configuration and content
databases.
Back up Search service applications in SharePoint Server Back up Search service applications that are associated with
the farm and include configuration and indexes.
Back up the Secure Store Service in SharePoint Server Back up the Secure Store service application that is associated
with the farm and includes configuration and content
databases.
CONTENT DESCRIPTION
Back up content databases in SharePoint Server Back up content databases that are associated with the farm.
Back up databases to snapshots in SharePoint Server Back up databases to snapshots in the farm.
Back up customizations in SharePoint Server Back up customizations that are associated with the farm. This
article includes how to back up workflows in SharePoint
Server.
Back up site collections in SharePoint Server Back up site collections that are associated with the farm.
Back up apps for SharePoint in SharePoint Server Back up apps for SharePoint in SharePoint Server.
Export sites, lists, or document libraries in SharePoint Server Export a list, site, or document library that is associated with
the farm. Then import the items into another farm or move
them to another place in the existing farm.
See also
Concepts
Back up farms in SharePoint Server

You can back up a SharePoint Server farm by using the SharePoint Central Administration website, Microsoft
PowerShell, or SQL Server tools. The backup tool that you use depends on the kind of environment that you
have deployed, your backup schedule requirements, and service level agreements that you have with your
organization.
Before you begin

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 so that all the farm data and configurations
are available for recovery, if that is required.
For information about which tool to use for backups, see Plan for backup and recovery in SharePoint Server.
Before you begin this operation, review the following information to help you prepare your farm backup:
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
restore farms in SharePoint Server.
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.
Ensure 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 SharePoint Server tools. For more information about how to back up and
restore all the farm databases, see Move all databases in SharePoint Server.
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 were 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 for user authentication methods in SharePoint Server.
SharePoint Server 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 be unable to locate the data source.
SharePoint Server 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 you restore the data. For more information, see Understanding Transparent Data Encryption (TDE ).
Use PowerShell to back up a farm in SharePoint Server

You can use 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 PowerShell
Server cmdlets.
NOTE

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
Use Central Administration to back up a SharePoint Server farm
You can use Central Administration to back up the farm.
To back up a farm by using Central Administration
SharePoint 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 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
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 SharePoint Server farm

If you want to back up the complete farm, you must use either 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. The databases that
are associated with the farm are determined by the services and features that you have installed on the farm.
To back up the databases associated with a farm by using SQL Server tools
1. Verify that the user account that is performing this procedure is a member of the SQL Server db_owner
fixed database role on all databases that are to be backed up.
2. Open SQL Server Management Studio and connect to the correct instance of the SQL Server Database
Engine.
5. In the Back Up Database dialog box, confirm the database name.
6. Next, 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 Recovery Models (SQL Server).
8. Either use the default name that is provided or specify a name for the backup set in the Name text box.
11. Repeat steps 1-10 for each farm database.
See also
Back up farm configurations in SharePoint Server

You can back up a farm configuration by using the SharePoint Central Administration website or Microsoft
PowerShell. The backup tool that you use depends on the kind of environment that you have deployed, your
backup schedule requirements, and service level agreements that you have with your organization.
Before you begin

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 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 make sure 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 in
SharePoint Server.
For information about which tool to use for backups, see Overview of backup and recovery in SharePoint Server.
Backing up the farm configuration will not back up the information that you need 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 how to back up service applications, see Back up service
You cannot use either SQL Server tools or Data Protection Manager to back up the farm configuration.
Use PowerShell to back up a SharePoint farm configuration

You can use 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 PowerShell
Server Products cmdlets.
NOTE

Backup-SPConfigurationDatabase -Directory <BackupFolder> -DatabaseServer <DatabaseServerName> -

DatabaseName <DatabaseName> -DatabaseCredentials <WindowsPowerShellCredentialObject> [-Verbose]
Where:
<BackupFolder> is the path to the folder that has 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
Use Central Administration to back up a SharePoint 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
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 farm configurations in SharePoint Server
Back up web applications in SharePoint Server

You can back up a web application by using the SharePoint Central Administration website, PowerShell, or SQL
Server tools. The backup tool that you use depends on the kind of environment that you have deployed, your
backup schedule requirements, and service level agreements that you have with your organization.
Before you begin

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 make sure 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.
Before you begin, you must create a network folder in which to store the backups. Both the SharePoint
Timer Service (SPTimerV4) 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 restore farms in SharePoint Server.
You can back up only one web application at a time by using the procedures in this article. You can back up
all web applications by backing up the complete 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.
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 were 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
for user authentication methods in SharePoint Server.
Use PowerShell to back up a web application

You can use 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 PowerShell
NOTE
Alternately, the user can be a member of the db_backupoperator fixed database role on all databases that are to
be updated if you do not want to assign full rights of the db_owner role.
cmdlets.
NOTE

Backup-SPFarm -Directory <BackupFolder> -BackupMethod {Full | Differential} -Item <WebApplicationName>

[-Verbose]
Where:
<BackupFolder> is the path of the folder that you use for storing backup files.
<WebApplicationName> is the name of the web application. To display the name of the web
application, at the PowerShell command prompt, type the following command:
Backup-SPFarm -ShowTree
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
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
group.
3. In Central Administration, on the home page, in the Backup and Restore section, click Perform a backup.
4. 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.
NOTE
If you are backing up the web application for the first time, you must use the Full option. You must perform a full
6. In the Back Up Only Configuration Settings section, click Back up content and configuration
settings.
the Backup section. The status page updates every 30 seconds automatically. You can manually update the
in step 6.
Use SQL Server tools to back up a databases that are associated with 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
PowerShell or Central Administration.
To back up a database associated with a web application by using SQL Server tools
Engine.
6. Next, 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 Recovery Models (SQL Server).
11. Repeat steps 1-10 for each farm database.
See also
Concepts
Restore web applications in SharePoint Server
Back up service applications in SharePoint Server

You can back up a service application by using the SharePoint Central Administration website or Microsoft
PowerShell. Which backup tool you use depends on what kind of environment you have deployed, what your
backup schedule requires, and what service level agreements you have made with your organization.
Before you begin

We recommend that you regularly back up at the farm level. However, business or IT requirements might require
you to 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
make sure 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 the same
time. For information about what to back up and which tools to use, see Plan for backup and recovery in
SharePoint Server. For more information, see Back up farms in SharePoint Server.
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 Server 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.
SharePoint Server backup backs up the SQL Server Remote BLOB Store installation package from the
Feature Pack for SQL Server 2008 R2 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 SQL Server
Remote BLOB Store installation package from the Feature Pack for SQL Server 2008 R2 or the farm.
If you back up the SQL Server Remote BLOB Store installation package from the Feature Pack for SQL
Server 2008 R2 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 SQL Server Remote BLOB
Store installation package from the Feature Pack for SQL Server 2008 R2 might be unable to locate the
data source.
Use PowerShell to back up a service application in SharePoint

You can use 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 PowerShell
2016 cmdlets.
NOTE

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. To
display the name of the service application, at the PowerShell command prompt, type the following
command: Backup-SPFarm -ShowTree .
To back up all the service applications, at the PowerShell command prompt, type the following command:
Backup-SPFarm -Directory <BackupFolder> -BackupMethod {Full | Differential} -Item "Farm\Shared

Services" [-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.
NOTE
Use Central Administration to back up a service application in

SharePoint
You can use Central Administration to back up a service application.
To back up a service application by using Central Administration
SharePoint group.
4. 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.
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.
6. In the Backup File Location section, in the Backup location box, type the path of the backup folder, and
then click Start Backup.
in step 5.
See also
Concepts
Restore service applications in SharePoint Server
Back up User Profile service applications in
SharePoint Server

You can back up the User Profile service application by using the SharePoint Central Administration website,
Microsoft PowerShell, or SQL Server tools. Which backup tool you use depends on what kind of environment you
have deployed, what your backup schedule requires, and what service level agreements you have made with your
organization.
IMPORTANT
The steps in this article apply to only SharePoint Servers 2019, 2016, and 2013.
Before you begin

you to back up the User Profile Service service application. Regularly backing up the User Profile 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 make sure that all service application-related data and configurations
are available for recovery, if that is required.
For information about what to back up and which tools to use, see Plan for backup and recovery in SharePoint
Server. You can back up all the service applications in the farm by backing up the complete farm. For more
information, see Back up farms in SharePoint Server.
Backing up the User Profile service application does not affect the state of the farm. However, it does
require resources. Therefore, backing up the 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.
Use PowerShell to back up a User Profile service application

You can use PowerShell to back the User Profile service application manually or as part of a script that can be run
at scheduled intervals.
NOTE
Backup of a User Profile service application can fail the first time that you use PowerShell to perform the backup. If this
occurs, repeat the backup procedure using PowerShell. For details about a backup failure, see the spbackup.log or
sprestore.log files in the backup directory.
To back up the User Profile service application by using PowerShell
Products cmdlets.
NOTE

Backup-SPFarm -Directory <BackupFolder> -BackupMethod Full -Item Farm\Shared Services\Shared Service

Applications\<ServiceApplicationName> [-Verbose]
Where:
<ServiceApplicationName> is the name of the User Profile Service service application that you want
to back up.
NOTE
The User Profile Service service application always requires a full backup,
4. You must also back up the service application proxy. To do this, at the PowerShell command prompt, type
Backup-SPFarm -Directory <BackupFolder> -BackupMethod Full -Item Farm\Shared Services\Shared Service

Proxies\<ServiceApplicationProxyName > [-Verbose]
Where:
<ServiceApplicationProxyName> is the name of the User Profile Service service application proxy
that you want to back up.
NOTE
Use Central Administration to back up a User Profile Service

application
You can use Central Administration to back up the User Profile service application.
NOTE
Backup of a User Profile service application can fail the first time that you use Central Administration to perform the backup.
If this occurs, repeat the backup procedure using Central Administration. For details about a backup failure, see the
spbackup.log or sprestore.log files in the backup directory.
To back up the User Profile service application by using Central Administration

SharePoint group.
4. On the Perform a Backup — Step 1 of 2: Select Component to Back Up page, select the User Profile Service
service application from the list of components, and then click Next.
NOTE
The User Profile service application always requires a full backup. You must use the Full option.
7. You must also back up the service application proxy. To do this, in Central Administration, on the home
page, in the Backup and Restore section, click Perform a backup.
8. On the Perform a Backup — Step 1 of 2: Select Component to Back Up page, select the User Profile Service
service application proxy from the list of components, and then click Next.
in step 5.
Use SQL Server tools to back up a User Profile service application

database
You cannot back up the whole User Profile service application or service application proxy. You must use either
PowerShell or Central Administration. However, you can back up all the databases that are associated with the
User Profile Service service application.
To back up a User Profile service application database by using SQL Server
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. Before you back up the User Profile Service service application databases, you must export the Microsoft
Identity Integration Server Key (MIIS ) encryption key. You will import this exported key before you restore
the databases. By default, the key is located on the server that runs SharePoint Server 2016 that is hosting
the Microsoft Forefront Identity Manager services in the following directory: <root directory
drive>\Program Files\Microsoft Office Servers\16.0\Synchronization Service\Bin or <root directory
drive>\Program Files\Microsoft Office Servers\15.0\Synchronization Service\Bin. To export the key, type
the following at the command prompt:
miiskmu.exe
Use the Microsoft Identity Integration Server Key Management Utility Wizard to export the key set.
12. Repeat steps 1-10 for each User Profile service application database.
See also
Concepts
Other Resources
Windows PowerShell for SharePoint Server reference
Back up Search service applications in SharePoint
Server

You can back up a Search service application in a farm by using the SharePoint Central Administration website,
Microsoft PowerShell, or SQL Server tools. Which backup tool you use depends on what kind of environment
you have deployed, what your backup schedule requires, and what service level agreements you have made with
your organization.
Before you begin

you to back up the search service and related resources. Regularly backing up the search system reduces the
possibility of data losses that might occur from hardware failures, power outages, or other problems. It is a simple
process that helps make sure that data and configurations that compose the search system are available for
recovery, if that is required.
network folder.
You cannot use SQL Server tools or Data Protection Manager to back up all of the search components.
Backing up search does not affect the state of the farm. However, it does require resources. Therefore,
backing up search might affect farm performance while the backup is running. You can avoid performance
issues by backing up search during hours when farm use is lowest.
Back up a thesaurus file

Thesaurus files are used to specify synonyms for words or phrases that occur in search queries. You create and
maintain the thesaurus files in systems external to SharePoint Server before you import them into SharePoint
Server to make them available to the search system. The thesaurus files are therefore not included in the
SharePoint Server search backup procedures outlined below.
To back up your thesaurus files, you need to make sure that they are included in the backup procedures for the
external system you are using to create and maintain the thesaurus files.
Use PowerShell to back up search in SharePoint Server

You can use PowerShell to back up search manually or as part of a script that can be run at scheduled intervals.
This procedure backs up all of the search components including the databases, the search service configuration,
and all of the index files.
To back up search by using PowerShell
Products cmdlets.
NOTE

Backup-SPFarm -Directory <BackupFolder> -BackupMethod {Full | Differential} -Item "Farm\Shared

Services\Shared Services Applications\<SearchServiceApplicationName>" [-Verbose]
Where:
<BackupFolder> is the path of the folder that you use for storing backup files.
<SearchServiceApplicationName> is the name of the Search service application that you are
backing up.
NOTE
before you can perform a differential backup. To view the progress of the backup operation, use the Verbose
parameter. The Differential option only applies to the search databases. The search index files are always fully
backed up, even when you use the Differential option.
NOTE
Use Central Administration to back up search in SharePoint Server

You can use Central Administration to back up search. This procedure backs up all of the search components
including the databases, the search service configuration, and all of the index files.
To back up search by using Central Administration
SharePoint group.
3. In Central Administration, on the home page, in the Backup and Restore section, click Perform a
backup.
4. On the Perform a Backup — Step 1 of 2: Select Component to Back Up page, in the list of components,
expand Shared Services and then expand Shared Services Applications to view the list of service
applications in the farm. Select the search service application from the list of components, and then click
Next.
NOTE
The search service application might consist of several components. You must select the top-level component. By
default, the service application is named "Search Service Application".
NOTE
If you are backing up search for the first time, you must use the Full option. You must perform a full backup before
you can perform a differential backup. The Differential option only applies to the search databases. The search
index files are always fully backed up, even when you use the Differential option.
status details by clicking Refresh. Backup and recovery are timer service jobs. Therefore, it might take
in step 6.
Use SQL Server tools to back up search

You cannot back up the complete SharePoint Search service application by using SQL Server tools. However, you
can use SQL Server tools to back up the databases that are associated with the Search service application. To
back up the complete Search service application, use either PowerShell or Central Administration.
To use SQL Server to back up the databases that are associated with the Search service application, you must
follow these steps:
1. Pause the Search service application.
2. Back up all the Search service application databases with SQL Server tools.
3. Resume the Search service application.
To pause the Search service application by using PowerShell
cmdlets.
NOTE

$ssa = Get-SPEnterpriseSearchServiceApplication -Identity <SearchServiceApplicationName>

Where:
<SearchServiceApplicationName> is the name of the Search service application that you are backing
up.
To back up all the Search service application databases 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.
7. In the Backup component area, click Database..
11. Repeat steps 1-10 for the following databases:
Analytics Reporting
Crawl
Link
To resume the Search service application by using PowerShell
cmdlets.
NOTE

$ssa = Get-SPEnterpriseSearchServiceApplication -Identity <SearchServiceApplicationName>

Where:
<SearchServiceApplicationName> is the name of the Search service application.
See also
Concepts
Back up the Secure Store Service in SharePoint
Server

You can back up the Secure Store Service by using the SharePoint Central Administration website, or Microsoft
PowerShell. The backup tool that you use depends on the kind of environment that you have deployed, your
backup schedule requirements, and service level agreements that you have made with your organization.
Before you begin

The Secure Store Service provides the capability of securely storing credential sets and associating credentials to
specific identities or a group of identities. Every time that you enter a new passphrase, SharePoint Server creates a
new Master Key and re-encrypts the credentials sets with that key. The passphrase gives you access to the Master
Key created by SharePoint Server that is used to encrypt the credential sets.
You should back up the Secure Store Service and record the passphrase after the Secure Store Service is first
configured and again every time that you make configuration changes to the Secure Store Service or re-encrypt
the credential information.
network folder.
Record the passphrase. You will need the passphrase when you access the restored Secure Store Service.
Ensure that you back up the Secure Store Service every time that you change or refresh the Master Key.
When you change or refresh the Master key, the database is automatically re-encrypted with the new key.
Backing up the Secure Store Service makes sure that the database and the Master key are synchronized.
Keep the passphrase in a secure location.
Use PowerShell to back up the Secure Store Service in SharePoint

You can use PowerShell to back up the Secure Store Service manually or as part of a script that can be run at
scheduled intervals.
To back up the Secure Store Service by using PowerShell
Products cmdlets.
NOTE

Backup-SPFarm -Directory <BackupFolder> -BackupMethod Full -Item <SecureStoreService > [-Verbose]
Where:
<SecureStoreService> is the name of the Secure Store Service application that you want to back up.
NOTE
You must use the Full option to back up the Secure Store Service.
NOTE
Use Central Administration to back up the Secure Store Service in

SharePoint
You can use Central Administration to back up the Secure Store Service.
To back up the Secure Store Service by using Central Administration
1. Verify that the user account that performs this procedure is a member of the Farm Administrators
SharePoint group.
4. On the Perform a Backup — Step 1 of 2: Select Component to Back Up page, expand the Shared Services
Applications node, select the Secure Store Service application from the list of components, and then click
Next.
NOTE
The Secure Store Service application might consist of several components. You must select the top-level component.
in step 5.
See also
Concepts
Restore Secure Store Service applications in SharePoint Server
Back up content databases in SharePoint Server

You can back up a content database by using the SharePoint Central Administration website, Microsoft
PowerShell, or SQL Server tools. The backup tool that you use depends on the kind of environment that you have
deployed, your backup schedule requires, and service level agreements that you have made with your
organization.
Before you begin

SharePoint Server 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 make sure that all the data is
available for recovery, if that is required. You can only back up one content database at a time.
network folder.
SharePoint Server 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.
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 Transparent Data Encryption (TDE ).
Use PowerShell to back up a content database in SharePoint Server

You can use 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 PowerShell
cmdlets.
NOTE

Backup-SPFarm -Directory <BackupFolder> -BackupMethod {Full | Differential} -Item <ContentDatabaseName>

[-Verbose]
Where:
<BackupFolder> is the path of the backup folder.
<ContentDatabaseName> is the name of the database that you want to back up. To display the
name of the content database, type the following command at the PowerShell command prompt:
Get-SPContentDatabase .
To view the progress of the backup operation, use the Verbose parameter.
NOTE
If you are backing up the content database for the first time, you must use the Full option. You must perform a full
NOTE
Use Central Administration to back up a content database in

SharePoint Server
You can use Central Administration to back up a content database.
To back up a content database by using Central Administration
SharePoint group.
4. 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 PowerShell to back
up the content database.
NOTE
If you are backing up the content database for the first time, you must use the Full option. You must perform a full
the Readiness section. You can view the status of the current backup job in the lower part of the page in the
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 5.
Use SQL Server tools to back up a content database in SharePoint

Server
You can use SQL Server tools to back up a content database.
To back up a content database by using SQL Server tools
Engine.
11. Repeat steps 1-10 for each content database.
See also
Concepts
Restore content databases in SharePoint Server
Back up databases to snapshots in SharePoint Server

You can only back up databases to snapshots in SharePoint Server by using SQL Server Enterprise tools.
Before you begin

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 make
sure that all the farm data and configurations are available for recovery, if that is required. For more information,
see Back up farms in SharePoint Server. However, IT requirements might require you to backup databases to
snapshots. Although you can back up any farm database to a snapshot, you typically back up content databases.
IMPORTANT
Database snapshots do not replace a backup and restore strategy. To fully protect your SharePoint Server environment we
advise you to perform regular backups to protect your farm in case you need to restore data after a failure..

You must first create a folder on the database server for your backup files. 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 completed.
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 was created (transactions
in the database are not affected). For more information about database snapshots, see Database Snapshots
(SQL Server).
Use SQL Server tools to back up a database to a snapshot in

SharePoint Server
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 service applications and features that you have installed on the farm.
To back up a database to a snapshot by using SQL Server tools
fixed database role.
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.
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 (SQL Server)
Database Snapshots with AlwaysOn Availability Groups (SQL Server)
Back up customizations in SharePoint Server

You can back up customizations that are made to SharePoint Server sites by using the SharePoint Central
Administration website or Microsoft PowerShell. Which backup tool you use depends on what kind of
environment you have deployed, what your backup schedule requires, and what service level agreements you
have made with your organization.
Before you begin

Before you begin this operation, review the following list of possible customizations that you can make to your
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 are
located 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
NOTE
Each of these kinds of customizations requires a different type of backup.
Back up solution packages in SharePoint Server
Solution packages can be created by using SharePoint Designer or Visual Studio. We strongly recommend that all
customizations be deployed as solution packages. For more information, see Creating SharePoint 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 (partially trusted code).
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 Server 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 Server 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 and 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
group.
4. 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.
5. 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
the Readiness section. You can view the status of the current backup job in the lower part of the page in the
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 PowerShell
cmdlets.
NOTE

3. At the 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".
Backup-SPFarm -backupmethod full -directory <UNC location> -item "farm\solutions"
Where:
<UNC location> is the UNC location of the directory where you store the backup file.
NOTE
Backing up sandboxed solutions in SharePoint Server

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.
Back up authored site elements in SharePoint Server

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.
Back up workflows in SharePoint Server

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 that were created in SharePoint Designer, are stored in the content
database for the site collection to which they are deployed. Backing up the content database protects these
workflows.
The Visual Studio 2013 assemblies for the actions are stored in the global assembly cache (GAC ).
The XML definition files (.ACTIONS files) are stored in the 16\TEMPLATE< LCID>\Workflow
directory.
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 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 GAC, and the XML definition
files are stored in the Features directory. This is the same as other types of SharePoint 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 Server farm, make sure that you back up the
folder where you store the workflow project files by a file system backup application.
Back up changes to the Web.config file in SharePoint Server

A common customization to SharePoint Server 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 Server 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 Server 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 Server backup. In this case, make sure that you back up the Web.config file by using a file system backup.
Back up third-party products in SharePoint Server

If third-party products are deployed as solution packages, they are protected by SharePoint Server backup. We
recommend that you keep all the original files, distribution media, documentation, and the license and product
keys that are required for installation.
Back 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 Server 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.
%PROGRAMFILES%\Common files\Microsoft Shared\Web Commonly updated files, custom assemblies, custom

Server Extensions\16 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
See also
Concepts
Restore customizations in SharePoint Server
Back up site collections in SharePoint Server

You can back up a site collection in SharePoint Server by using the SharePoint Central Administration website or
Microsoft PowerShell.
Before you begin

We recommend that you regularly back up the complete farm. However, IT practices might require you to also
back up a site collection. For more information about what to back up, see Plan for backup and recovery in
SharePoint Server.
You must first 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
If the site collection's Lock status is set to Not locked or Adding content prevented, SharePoint Server
temporarily sets the site to Read-Only while the backup operation is occurring. SharePoint Server does
this to reduce the possibilities of users changing the site collection while it is being backed up. After the
backup is complete, 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.
Use PowerShell to back up a site collection in SharePoint Server

You can use 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 PowerShell
cmdlets.
NOTE
Backup-SPSite -Identity <SiteCollectionGUIDorURL> -Path <BackupFile> [-Force] [-NoSiteLock] [-

UseSqlSnapshot] [-Verbose]
Where:
<SiteCollectionGUIDorURL> is the ID or URL for the site collection you want to back up.
<BackupFile> is the path to where the backup file is located.
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 enable users to change the site collection while it is being
backed up and could lead to possible data corruption during backup. To display the site collection GUID or
URL at the PowerShell command prompt, type the following command:
Get-SPSite | format-list -property id,url
If the database server is running an Enterprise Edition of 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.
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 how to use SQL snap-shots, see Back up databases to snapshots in
SharePoint Server.
For more information, see Backup-SPSite.
NOTE
Use Central Administration to back up a site collection in SharePoint

Server
You can use Central Administration to back up a site collection.
To back up a site collection by using Central Administration
Additionally, verify that the Windows SharePoint Services Timer V4 service has Full Control permissions
on the backup folder.
3. In Central Administration, on the home page, in the Backup and Restore section, click Perform a site
collection backup.
4. On the Site collection backup page, select the site collection from the Site Collection list.
5. 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.
6. Click Start Backup.

7. 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 site collections in SharePoint Server
Back up apps for SharePoint in SharePoint Server

you to back up the apps for SharePoint in addition to normal farm backups. If you regularly back up the apps for
SharePoint environment, you reduce the possibility of data losses that might occur from hardware failures, power
outages, or other problems. It is a simple process that helps make sure that data and configurations that compose
the apps for SharePoint environment are available for recovery, if that is required.
The app for SharePoint content and packages are in the SharePoint Server content databases in individual site
collections. All app for SharePoint license and security data is stored in the App Management Service and the
Secure Store Service application databases. Additional app for SharePoint data is stored in the SharePoint Server
configuration database, in the form of Internet Information Services (IIS ) web sites or web applications, and Web
Part packages. You must back up the following SharePoint Server databases at the same time:
Content - WSS_Content
Configuration - SharePoint_Config
Secure Store Service application - Secure_Store_Service_DB_<GUID>
App Management service application - App_Management_<GUID>
If you have to eventually restore the databases, you have to restore the same version of each database that you
backed up. In other words, don't restore a content database that's six months older than the configuration
database.
You can back up an apps for SharePoint environment by using the SharePoint Central Administration website,
Microsoft PowerShell, or SQL Server tools.
Back up content databases

Content databases can store data for multiple site collections. However, if you have many site collections, we
recommend that you add enough content databases to keep the size of each database below 200 GB for optimal
system performance. For more information, see Back up content databases in SharePoint Server.
NOTE
SharePoint Server content databases become very large. We recommend that you back up each content database as a
separate process from other database or farm backups.
Back up the configuration database

The SharePoint Server configuration database stores data about all SharePoint databases and Internet
Information Services (IIS ) web sites or web applications. This includes trusted solutions, web part packages, site
templates, and web application settings, and farm settings that are specific to SharePoint Server, such as default
quota and blocked file types. For more information, see Back up farm configurations in SharePoint Server.
Back up the Secure Store Service application database

The Secure Store Service database stores and maps credentials such as account names and passwords. To back up
the Secure Store database for an apps for SharePoint environment, see Back up the Secure Store Service in
SharePoint Server.
NOTE
Make sure that you record the passphrase when you back up the Secure Store database. You must have the passphrase
available to restore the Secure Store database.
Back up the App Management service application database

The App Management service application database stores the app licenses and permissions for all apps
downloaded from the App Catalog site in SharePoint Server. To back up the App Management database, follow
the same procedures as most other SharePoint Server service applications. For more information, see Back up
service applications in SharePoint Server.
Back up a site collection

You may have multiple site collections that host apps for SharePoint in your environment. When you backup apps
for SharePoint you must also back up all site collections where the apps are hosted.
To back up a site collection by using PowerShell
cmdlets.
NOTE

Backup-SPSite -Identity <SiteCollectionGUIDorURL> -Path <BackupFile> [-Force] [-NoSiteLock] [-

UseSqlSnapshot] [-Verbose]
Where:
<SiteCollectionGUIDorURL> is the ID or URL for the site collection you want to back up.
<BackupFile> is the path of where the backup file is located.
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 enable users to change the site collection while it is being
backed up and could lead to possible data corruption during backup. To display the site collection GUID or
URL at the PowerShell command prompt, type the following command:
Get-SPSite | format-list -property id,url
If the database server is running an Enterprise Edition of 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.
NOTE
If the RBS provider that you are using does not support snapshots, you can't use snapshots for content deployment
or backup. For example, the SQL FILESTREAM provider does not support snapshots.
For more information about how to use SQL snap-shots, see Back up databases to snapshots in SharePoint
Server.
For more details, see Back up site collections in SharePoint Server
For more information, see Backup-SPSite.
NOTE
See also
Concepts
Restore apps for SharePoint in SharePoint Server
Export sites, lists, or document libraries in SharePoint
Server

You can export a site, list, or document library in SharePoint Server by using the SharePoint Central
Administration website or Microsoft PowerShell. The backup tool that you use depends on the kind of
environment that you have deployed, your backup schedule requirements, and service level agreements that you
have made with your organization.
Before you begin

We recommend that you regularly back up the complete farm. However, business or IT requirements might
require you to 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 make sure 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 in SharePoint
Server.
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.
You cannot use SQL Server tools or Data Protection Manager to export a site, list or document library.
Use PowerShell to export a site, list, or document library in SharePoint

Server
You can use 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 PowerShell
cmdlets.
NOTE

Export-SPWeb -Identity <SiteURL> -Path <Path and File Name> [-ItemUrl <URL of Site, List, or Library>]
[-IncludeUserSecurity] [-IncludeVersions] [-NoFileCompression] [-GradualDelete] [-Verbose]
Where:
<SiteURL> is URL for the site, list, or library that you are exporting.
<Path and FileName> is path and name for the site, list, or library that you are exporting.
<URL of Site, List, or Library> is the URL for the site, list, or library where you are exporting.
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 at one time, which reduces its effect 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
Use Central Administration to export a site, list, or document library in

SharePoint Server
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
group.
3. In Central Administration, on the home page, click Backup and Restore.
4. On the Backup and Restore page, in the Granular Backup section, click Export a site or list.
5. 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.
6. If you are exporting a site, skip this step, Select the list or document library from the List list.
7. 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.
8. 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.
9. 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.
10. 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
11. When you have specified the settings that you want, click Start Export.
12. 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.
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.
See also
Concepts
Other Resources
Use Windows PowerShell to administer SharePoint Server

The following articles provide information about how to restore SharePoint Server 2016 data. These articles 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.
CONTENT DESCRIPTION
Restore farms in SharePoint Server Solutions you can use to restore the complete farm from a
backup.
Restore farm configurations in SharePoint Server Restore the farm configuration to the same farm from a
backup.
Document farm configuration settings in SharePoint Server Document the configuration settings for your farm.
Copy configuration settings between farms in SharePoint Copy configuration settings from one farm to another.
Server
Restore web applications in SharePoint Server Restore a Web application from a backup.
Restore service applications in SharePoint Server Restore a service application from a backup.
Restore User Profile Service applications in SharePoint Server Restore the User Profile Service application instead of
restoring the complete farm.
Restore Search service applications in SharePoint Server Restore the Search service application from a backup.
Restore Secure Store Service applications in SharePoint Server Restore the Secure Store service application from a backup.
Restore content databases in SharePoint Server Restore a content database from a backup.
Attach and restore read-only content databases in SharePoint Attach a read-only content database to the farm.
Server
Restore content from unattached content databases in Restore or copy content, such as sites, site collections, lists, or
SharePoint Server document libraries, from a content database without having
to attach the content database to the farm.
Restore customizations in SharePoint Server Restore customizations that are associated with the farm from
backups.
Restore site collections in SharePoint Server Restore a site collection from a backup.
Restore apps for SharePoint in SharePoint Server Restore apps for SharePoint in SharePoint Server.
CONTENT DESCRIPTION
Import a list or document library in SharePoint Server Restore a site, list, or document library from a backup.
See also
Concepts
Restore farms in SharePoint Server

You can restore a SharePoint Server farm by using the SharePoint Central Administration website, Microsoft
PowerShell, or SQL Server tools. The backup tool that you use depends on the kind of environment that you have
deployed, the backup schedule, and service level agreements that you have made with your organization.
Before you begin

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 Server deployment from one farm to another farm.
Before you begin this operation, review the following information about how to recover a farm in SharePoint:
You cannot back up from one version of SharePoint Server 2019 and restore to another version of
SharePoint Server 2019. The same applies to SharePoint Servers 2016 and 2013.
Backing up the farm will back up the configuration and Central Administration content databases, but
these cannot be restored using SharePoint Server tools. For more information about how to back up and
restore all of the farm databases, see Move all databases in SharePoint Server.
When you restore the farm by using SharePoint Server, the restore process will not automatically start all
of the service applications. You must manually start them by using Central Administration or Microsoft
PowerShell. Do not use SharePoint Products Configuration Wizard to start the services because doing this
will also re-provision the services and service proxies. For more information, see Start or stop a service in
SharePoint Server.
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:
The change logs for all databases are retained when you restore a farm.
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 Server 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 Server 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 you are sharing service applications across farms, be aware that trust certificates that were exchanged
are not included in farm backups. You must back up your 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 in SharePoint Server.
After a Web application that is configured to use claims-based authentication is restored, duplicate or
additional claims providers are often visible. If duplicates appear, then you must manually save each Web
application zone to remove them. For more information, see Restore web applications in SharePoint
Server.
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 web applications in SharePoint Server.
Using PowerShell to restore a farm in SharePoint

You can use Microsoft PowerShell to restore a farm.
To restore a farm by using PowerShell
cmdlets.
NOTE

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,
at the Microsoft PowerShell command prompt,type the following command:
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.
4. To restart a service application, at the PowerShell command prompt, type the following command:
Start-SPServiceInstance -Identity <ServiceApplicationID>
Where <ServiceApplicationID> is the GUID of the service application.

For more information about how to restart service applications by using PowerShell, see Start-
SPServiceInstance.
For more information about how to restore the farm by using PowerShell_2nd_NoVer, see Restore-
SPFarm.PShell_stsadm_deprecated
Using 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
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, make sure that Farm appears in the Restore the following component 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 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
several seconds for the recovery to start.
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 Systems Settings section, click Manage services on
server. On the Services on Server page, start any services related to service applications that you want to
run by clicking Restart in the Action column next to the service application.
8. Re-establish any trust relationships. For more information, see Exchange trust certificates between farms in
SharePoint Server.
Using 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 PowerShell. For more information about how to restore the farm's configuration
settings, see Restore farm configurations in SharePoint Server.
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 Server, 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.
Use the following procedure to restore your farm databases.
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 SharePoint 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.
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).
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.
IMPORTANT
If you are restoring the User Profile database (by default named "User Profile Service_ProfileDB_<GUID>"), then also
restore the Social database (by default named "User Profile Service_SocialDB_<GUID>"). Failing to do this can cause
inaccuracies in the User Profile data that might be difficult to detect and fix.
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 how to restore
the farm configuration, see Restore farm configurations in SharePoint Server.
13. Start the SharePoint Timer service.
14. Start any service applications that have to be restarted. In Central Administration, on the home page, in the
Systems Settings section, click Manage services on server. On the Services on Server page, start any
services related to service applications that you want to run by clicking Restart in the Action column next
to the service application.
Related content
The following list shows other recovery methods that you can use when you only need to restore part of your
farm:

You can restore a farm configuration in SharePoint Server by using the SharePoint Central Administration
website or Microsoft PowerShell. Which backup tool you use depends on what kind of environment you have
deployed, what your backup schedule requires, and what service level agreements you have made with your
organization.
Before you begin

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
how to restore the complete farm, see Restore farms in SharePoint Server. 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.
NOTE
In earlier versions of SharePoint, you could not restore the configuration database and, therefore, you could not restore the
configuration of a farm. Now you do not have to restore the configuration database because you can restore the farm
configuration directly.
Using PowerShell to restore a farm's configuration in SharePoint

You can use PowerShell to restore a farm's configuration.
To restore a farm's configuration by using PowerShell
cmdlets.
NOTE

Restore-SPFarm -Directory <RestoreShare> -RestoreMethod Overwrite -ConfigurationOnly
Where <RestoreShare> is network location where the backup file is stored. For more information, see
Restore-SPFarm.
NOTE
versions.
Using Central Administration to restore a farm's configuration in

SharePoint
You can use Central Administration to restore a farm's configuration.
To restore a farm's configuration by using Central Administration
SharePoint group on the computer that is running Central Administration.
2. Verification: Optionally, include steps that users should perform to verify that the operation was
successful.
You must also be a member of the sysadmin fixed server role on the database server where each
database is stored.
backup.
4. 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.
next to the farm, and then click Next.
section, make sure that "Farm" appears in the Restore the following content list.
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

7. 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
in step 2.
See also
Concepts
Document farm configuration settings in SharePoint
Server

You can document your farm configuration settings in SharePoint Server by using PowerShell.
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 if a failure were to occur.
Using PowerShell to document farm configuration settings in

SharePoint Server
The following procedure describes how to create and run a PowerShell script for SharePoint Server. You can then
use this script to restore the farm configuration settings if a failure were to occur.
To document SharePoint Server configuration settings by using PowerShell
cmdlets.
NOTE
2. Use a text editor, such as Notepad, to create a text file by pasting the following code 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.
##
## 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
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 claims authentication
Get-SPTrustedIdentityTokenIssuer | Export-Clixml .\Get-SPTrustedIdentityTokenIssuer.xml
Get-SPTrustedServiceTokenIssuer | Export-Clixml .\Get-SPTrustedServiceTokenIssuer.xml
Get-SPTrustedRootAuthority | Export-Clixml .\Get-SPTrustedRootAuthority.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 specific information about the certificate authority
Get-SPCertificateAuthority | Export-Clixml .\Get-SPCertificateAuthority.xml
Get-SPClaimProvider | Export-Clixml .\Get-SPClaimProvider.xml
Get-SPClaimProviderManager | Export-Clixml .\Get-SPClaimProviderManager.xml
#Retrieve information about content deployment jobs
Get-SPContentDeploymentJob | Export-Clixml .\Get-SPContentDeploymentJob.xml
Get-SPContentDeploymentPath | Export-Clixml .\Get-SPContentDeploymentPath.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 InfoPath form services
Get-SPInfoPathFormsService | Export-Clixml .\Get-SPInfoPathFormsService.xml
Get-SPInfoPathFormTemplate | Export-Clixml .\Get-SPInfoPathFormTemplate.xml
###WARNING: The following cmdlet requires run as administrator rights.
Get-SPInfoPathUserAgent | Export-Clixml .\Get-SPInfoPathUserAgent.xml
#Retrieve information about common Web service settings
Get-SPServiceHostConfig | Export-Clixml .\Get-SPServiceHostConfig.xml
##
## Common service application settings
##
##
#Access Services
#Retrieve specific information for the Access Services service application
Get-SPAccessServiceApplication | Export-Clixml .\Get-SPAccessServiceApplication.xml
#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
#Excel Services Application
#Note: An Excel service application must be provisioned for the following cmdlets to succeed.
Get-SPExcelServiceApplication | Get-SPExcelBlockedFileType | Export-Clixml .\Get-SPExcelBlockedFileType.xml
Get-SPExcelServiceApplication | Get-SPExcelDataConnectionLibrary | Export-Clixml .\Get-
SPExcelDataConnectionLibrary.xml
Get-SPExcelServiceApplication | Get-SPExcelDataProvider | Export-Clixml .\Get-SPExcelDataProvider.xml
Get-SPExcelServiceApplication | Get-SPExcelFileLocation | Export-Clixml .\Get-SPExcelFileLocation.xml
Get-SPExcelServiceApplication | Export-Clixml .\Get-SPExcelServiceApplication.xml
Get-SPExcelServiceApplication | Get-SPExcelUserDefinedFunction | Export-Clixml .\Get-
SPExcelUserDefinedFunction.xml
Get-SPWebApplication | Get-SPInfoPathWebServiceProxy | Export-Clixml .\Get-SPInfoPathWebServiceProxy.xml
Get-SPWebApplication | Get-SPManagedPath | Export-Clixml .\Get-SPManagedPath.xml
#Managed Metadata Service

#Note: A Managed Metadata service application must be provisioned for the following cmdlets to succeed.
Get-SPServiceApplication | ?{$_.TypeName -eq "Managed Metadata Service"} | %{$id = $_.Id;Get-
SPMetadataServiceApplication -Id $_ | Export-Clixml .\Get-SPMetadataServiceApplication-$id.xml}
Get-SPServiceApplicationProxy | ?{$_.TypeName -eq "Managed Metadata Service Connection"} | %{$id = $_.Id;Get-
SPMetadataServiceApplicationProxy -Id $_ | Export-Clixml .\Get-SPMetadataServiceApplicationProxy-$id.xml}
Get-SPSite | Get-SPTaxonomySession | Export-Clixml .\Get-SPTaxonomySession.xml
#PerformancePoint Service Application
#Note: A PerformancePoint service application must be provisioned for the following cmdlets to succeed.
Get-SPPerformancePointServiceApplication | Export-Clixml .\Get-SPPerformancePointServiceApplication.xml
Get-SPPerformancePointServiceApplication | Get-SPPerformancePointServiceApplicationTrustedLocation | Export-
Clixml .\Get-SPPerformancePointServiceApplicationTrustedLocation.xml
#Search
#Retrieve search information
#Note: A Search service application must be provisioned for the following cmdlets to succeed.
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchAdministrationComponent | Export-Clixml
.\Get-SPEnterpriseSearchAdministrationComponent.xml
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchCrawlContentSource | Export-Clixml .\Get-
SPEnterpriseSearchCrawlContentSource.xml
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchCrawlCustomConnector | Export-Clixml .\Get-
SPEnterpriseSearchCrawlCustomConnector.xml
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchCrawlDatabase | Export-Clixml .\Get-
SPEnterpriseSearchCrawlDatabase.xml
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchCrawlExtension | Export-Clixml .\Get-
SPEnterpriseSearchCrawlExtension.xml
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchCrawlMapping | Export-Clixml .\Get-
SPEnterpriseSearchCrawlMapping.xml
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchCrawlRule | Export-Clixml .\Get-
SPEnterpriseSearchCrawlRule.xml
$searchApp = Get-SPEnterpriseSearchServiceApplication; Get-
SPEnterpriseSearchExtendedClickThroughExtractorJobDefinition -SearchApplication $searchApp | Export-Clixml
.\Get-SPEnterpriseSearchExtendedClickThroughExtractorJobDefinition.xml
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchExtendedConnectorProperty | Export-Clixml
.\Get-SPEnterpriseSearchExtendedConnectorProperty.xml
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchExtendedQueryProperty | Export-Clixml .\Get-
SPEnterpriseSearchExtendedQueryProperty.xml
###WARNING: The following command generates a 120MB file that records the out of the box settings###
#Note: The Get-SPEnterpriseSearchQueryAuthority and Get-SPEnterpriseSearchQueryDemoted cmdlets require the
Owner and SearchApplication parameters#
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchLanguageResourcePhrase | Export-Clixml
.\Get-SPEnterpriseSearchLanguageResourcePhrase.xml
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchMetadataCategory | Export-Clixml .\Get-
SPEnterpriseSearchMetadataCategory.xml
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchMetadataCrawledProperty | Export-Clixml
.\Get-SPEnterpriseSearchMetadataCrawledProperty.xml
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchMetadataManagedProperty | Export-Clixml
.\Get-SPEnterpriseSearchMetadataManagedProperty.xml
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchMetadataMapping | Export-Clixml .\Get-
SPEnterpriseSearchMetadataMapping.xml
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchQueryAuthority | Export-Clixml .\Get-
SPEnterpriseSearchQueryAuthority.xml
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchQueryDemoted | Export-Clixml .\Get-
SPEnterpriseSearchQueryDemoted.xml
Get-SPEnterpriseSearchQueryAndSiteSettingsService | Export-Clixml .\Get-
SPEnterpriseSearchQueryAndSiteSettingsService.xml
Get-SPEnterpriseSearchQueryAndSiteSettingsServiceInstance | Export-Clixml .\Get-
SPEnterpriseSearchQueryAndSiteSettingsServiceInstance.xml
Get-SPEnterpriseSearchQueryAndSiteSettingsServiceProxy | Export-Clixml .\Get-
SPEnterpriseSearchQueryAndSiteSettingsServiceProxy.xml
Get-SPEnterpriseSearchService | Export-Clixml .\Get-SPEnterpriseSearchService.xml
Get-SPEnterpriseSearchServiceInstance | Export-Clixml .\Get-SPEnterpriseSearchServiceInstance.xml
###WARNING: The following command generates a file per site collection###
#Note: The Get-SPEnterpriseSearchQuerySuggestionCandidates and Get-SPEnterpriseSearchRankingModel cmdlets
require the Owner and SearchApplication parameters#
Get-SPSite | %{$id = $_.Id;Get-SPEnterpriseSearchQueryKeyword -Site $_ | Export-Clixml .\Get-
SPEnterpriseSearchQueryKeyword-$id.xml}
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchQueryScope | Export-Clixml .\Get-
SPEnterpriseSearchQueryScope.xml
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchQueryScope | Get-
SPEnterpriseSearchQueryScopeRule | Export-Clixml .\Get-SPEnterpriseSearchQueryScopeRule.xml
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchQuerySuggestionCandidates | Export-Clixml
.\Get-SPEnterpriseSearchQuerySuggestionCandidates.xml
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchRankingModel | Export-Clixml .\Get-
SPEnterpriseSearchRankingModel.xml
Get-SPEnterpriseSearchServiceApplication | Get-SPEnterpriseSearchSecurityTrimmer | Export-Clixml .\Get-
SPEnterpriseSearchSecurityTrimmer.xml
Get-SPEnterpriseSearchServiceApplication | Export-Clixml .\Get-SPEnterpriseSearchServiceApplication.xml
Get-SPEnterpriseSearchServiceApplicationProxy | Export-Clixml .\Get-
SPEnterpriseSearchServiceApplicationProxy.xml
Get-SPEnterpriseSearchSiteHitRule | Export-Clixml .\Get-SPEnterpriseSearchSiteHitRule.xml
#Security Token Service Application
#Retrieve information about the security token service used for incoming SOAP messages.
Get-SPSecurityTokenServiceConfig | Export-Clixml .\Get-SPSecurityTokenServiceConfig.xml
#State Service
#Retrieve information about the State Service.
Get-SPSessionStateService | Export-Clixml .\Get-SPSessionStateService.xml
Get-SPStateServiceApplication | Export-Clixml .\Get-SPStateServiceApplication.xml
Get-SPStateServiceApplicationProxy | Export-Clixml .\Get-SPStateServiceApplicationProxy.xml
Get-SPStateServiceDatabase | Export-Clixml .\Get-SPStateServiceDatabase.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
#Visio Service
#A Visio service application must be provisioned for the following cmdlets to succeed.
Get-SPVisioServiceApplication | Get-SPVisioExternalData | Export-Clixml .\Get-SPVisioExternalData.xml
Get-SPVisioServiceApplication | Get-SPVisioPerformance | Export-Clixml .\Get-SPVisioPerformance.xml
Get-SPVisioServiceApplication | Get-SPVisioSafeDataProvider | Export-Clixml .\Get-SPVisioSafeDataProvider.xml
Get-SPVisioServiceApplication | Export-Clixml .\Get-SPVisioServiceApplication.xml
Get-SPVisioServiceApplicationProxy | Export-Clixml .\Get-SPVisioServiceApplicationProxy.xml
#Web Analytics Service Application
A Web Analytics service application must be provisioned for the following cmdlets to succeed.
Get-SPServiceApplication | ?{$_.TypeName -eq "Web Analytics Service Application"} | %{$id = $_.Id;Get-
SPWebAnalyticsServiceApplication -Id $_ | Export-Clixml .\Get-SPWebAnalyticsServiceApplication-$id.xml}
Get-SPServiceApplicationProxy | ?{$_.TypeName -eq "Web Analytics Service Application Proxy"} | %{$id =
$_.Id;Get-SPWebAnalyticsServiceApplicationProxy -Id $_ | Export-Clixml .\Get-
SPWebAnalyticsServiceApplicationProxy-$id.xml}
Get-SPWebApplication | Get-SPWebApplicationHttpThrottlingMonitor | Export-Clixml .\Get-
SPWebApplicationHttpThrottlingMonitor.xml
Get-SPWebPartPack | Export-Clixml .\Get-SPWebPartPack.xml
#Word Automation Services
###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}
NOTE

5. Change to the directory where you saved the file.
For more information, see Export-Clixml, Get-SPWebApplication, Get-SPServiceApplication.
NOTE
Example of using a cmdlet in SharePoint Server

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.
Get-SPAlternateURL | Export-Clixml .\Get-SPAlternateURL.xml
The following section lists the content of the Get-SPAlternateURL.xml file. Some sections are collapsed.
- <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.
Import-Clixml .\Get-SPAlternateURL.xml
Once an XML file is imported, you can use the objects in the pipeline as if they were real objects of the given type.
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.
Import-Clixml .\Get-SPAlternateURL.xml | %{$_.Uri | Get-Member}
See also
Other Resources
Export-Clixml
Import-Clixml
Get-SPAlternateURL
ForEach-Object
Get-Member
Copy configuration settings between farms in
SharePoint Server

You can copy configuration settings between SharePoint Server farms by using Microsoft PowerShell.
Before you begin

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 have to copy them.
Back up and restore a farm without the content databases attached. This method gives you farm settings
and Web application settings, in addition to the settings for any service applications that you select.
Back up and restore configurations only. This method provides you with the core SharePoint Foundation
settings only.
NOTE
This method does not include Web application or service application settings. If Web application settings are required
in the restored farm, use one of the other methods.
Create a deployment script, based on your documented configuration. This method may be more work at
first, but is easy to use to maintain standardization.
Backup and restore a farm without content databases to copy

configuration settings in SharePoint Server
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 restore a farm without content databases by using PowerShell

cmdlets.
NOTE

3. At the PowerShell command prompt, type the following command to document the current Web
application URLs and content database mappings.
Get-SPWebApplication | %{$_.Name;$_.Url;%{$_.ContentDatabases|%{$_.Name};Write-Host ""}}
4. Either unmount all content databases, as in the following example:
Get-SPContentDatabase | Dismount-SPContentDatabase
Or unmount a specific content database, as in the following example:
Get-SPContentDatabase WSS_Content | Dismount-SPContentDatabase
5. Back up the farm.
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.
6. After the backup is complete, re-mount the content databases.
Mount-SPContentDatabase -Name <WSS_Content> -WebApplication <http://servername>
Replace the placeholders with each of the mappings documented in step 1.

Where:
<WSS_Content> is the <name and ID of the database>.
<http://servername> is <the URL of the Web Application>.
NOTE
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 farm configurations in
SharePoint Server.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 farm
configurations in SharePoint Server.
See also
Concepts

You can restore a web application in SharePoint Server by using the SharePoint Central Administration website,
Microsoft PowerShell, or SQL Server tools. Which backup tool you use depends on what kind of environment
you have deployed, what your backup schedule requires, and what service level agreements you have made with
your organization.
Before you begin

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.
Before you begin this operation, review 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 at the same time restore all the web applications in the farm by restoring the complete farm.
If a 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 in SharePoint Server.
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.
Using PowerShell to restore a web application in SharePoint Server

You can use 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 PowerShell
Server cmdlets.
NOTE

Restore-SPFarm -Directory <BackupFolderName> -RestoreMethod Overwrite -Item <WebApplicationName> [-

BackupId <GUID>] [-Verbose]
Where:
<BackupFolderName> is the full path of the folder that 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:
Get-SPBackupHistory -Directory <BackupFolderName> -ShowBackup
For more information, see Restore-SPFarm.
NOTE
Using Central Administration to restore a web application in

SharePoint Server
You can use Central Administration to restore a web application.
To restore a web application by using Central Administration
Additionally, verify that the SharePoint Timer service and the Farm Database Access account have Full
Control permissions on the backup folder.
backup.
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.
next to the web application, and then click Next.
section, make sure that Farm\<Web application> appears in the Restore the following content list.
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.

Job Status page. You can also find more details in the Sprestore.log file at the UNC path that you specified.
Using SQL Server tools to restore databases associated with a web

application in SharePoint Server
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
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.
running stored procedures to finish. Do not restart the service until after you restore the databases.
Database.
processes.
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.
If you have included all the transaction logs that you must restore, select RECOVER WITH RECOVERY.
NOTE

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 in SharePoint Server
After you restore a web application that uses forms-based authentication, you must follow these 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.
Additional steps to remove duplicate claims providers after restoring a

web application that uses claims-based authentication in SharePoint
Server
After a web application that is configured to use claims-based authentication is 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.
Additional steps to re-configure object cache user accounts in

SharePoint Server
If you configured object cache user accounts for the web application, the restore process will not restore these
settings. You must re-configure the settings for the web application. For more information, see Configure object
cache user accounts in SharePoint Server.
See also
Concepts

You can restore a service application in SharePoint Server by using the SharePoint Central Administration
website or Microsoft PowerShell. Which backup tool you use depends on what kind of environment you have
deployed, what your backup schedule requires, and what service level agreements you have made with your
organization.
Before you begin

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 and
the User Profile Service service application — provide data to other services and sites. As a result, users might
experience some service interruption until the recovery process is completed.
Before you begin this operation, review the following information about how to restore service applications:
You cannot back up from one version of SharePoint and restore to another version of SharePoint.
SharePoint Server backs up the Business Data Connectivity service metadata store, which includes
external content types, external systems, and Business Data Catalog models. 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 Server 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.
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 PowerShell to restore a service application in SharePoint Server

You can use PowerShell to restore a service application.
To restore a service application by using PowerShell
cmdlets.
NOTE
permissions.

Restore-SPFarm -Directory
<BackupFolder>
-Item "
<ServiceApplicationName>
" -RestoreMethod Overwrite [-BackupId
<GUID>
] [-Verbose]
Where:
<BackupFolder> is the path for the backup folder where the service application was backed up.
<ServiceApplicationName> is the name of 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
To restore all the service applications, at the PowerShell command prompt, type the following command:
Restore-SPFarm -Directory
<BackupFolder>
-Item "Farm\Shared Service Applications" -RestoreMethod Overwrite [-BackupId
<GUID>
] [-Verbose]
Where:
<GUID> is the ID of the backup to use.
NOTE
Use Central Administration to restore a service application in

SharePoint Server
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
SharePoint group.
backup.
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.
5. 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.
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
7. 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
in step 3.
Use SQL Server tools to restore the databases associated with a

service application in SharePoint Server
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 Microsoft 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 sysadmin fixed
server role on the database server where each database is stored.
Database.
database drop-down list.
6. Select the restore source from the From database drop-down list.
For more information about which recovery type to use, see Recovery Models (SQL Server) in SQL Server
Books Online.
See also
Concepts
Back up service applications in SharePoint Server
Restore User Profile Service applications in
SharePoint Server

You can restore the User Profile Service application by using the SharePoint Central Administration website,
Microsoft PowerShell, or SQL Server tools. Which backup tool you use depends on what kind of environment you
have deployed, what your backup schedule requires, and what service level agreements you have made with your
organization.
IMPORTANT
The steps in this article apply to SharePoint Server 2016.
Before you begin

This article describes how to restore the User Profile Service application instead of restoring the complete farm.
Before you begin this operation, review the following information about how to restore a User Profile service
application:
The User Profile service application provides data to other services and sites. As a result, users might
experience some service interruption until the recovery process is completed.
You cannot back up from one version of SharePoint Server and restore to another version of SharePoint
Server.
For information about how to at the same time restore all the service applications in a farm, see Restore
farms in SharePoint Server.
Using PowerShell to restore the User Profile service application in

SharePoint Server
You can use Microsoft PowerShell to restore a User Profile service application.
To restore the User Profile service application by using PowerShell
cmdlets.
NOTE

Restore-SPFarm -Directory <BackupFolder> -Item Shared Services\Shared Services Applications\

<ServiceApplicationName> -RestoreMethod Overwrite [-BackupId <GUID>] [-Verbose]
Where:
<BackupFolder> is the path of the folder where the backups are stored.
<ServiceApplicationName> is the name of the service application.
<GUID> is the identifier of the backup to use in the restore process.
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.
NOTE
Using Central Administration to restore a User Profile service

application in SharePoint Server
Use the following procedures to restore a User Profile service application by using the SharePoint Central
Administration Web site.
To restore the User Profile service application by using Central Administration
SharePoint group.
backup.
NOTE
backup folder, and then click Refresh. You cannot use a configuration-only backup to restore the User Profile Service
Applications, select the check box that is next to the User Profile Service service application, and then click
Next.
section, make sure that Farm\Shared Services Applications\<User Profile Service service
application name> appears in the Restore the following component list.
7. Click Start Restore.
status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take a
in step 3.
Using SQL Server tools to restore the databases associated with the
User Profile service application in SharePoint Server
You cannot restore the complete service application or service application proxy 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 PowerShell or Central Administration.
IMPORTANT
If you are restoring the User Profile database (by default, it is named User Profile Service_ProfileDB_ <GUID>), you must also
restore the Social database (by default, it is named User Profile Service_SocialDB_ <GUID>). Failing to do this can cause
inaccuracies in the User Profile data that might be difficult to detect and fix.
To restore the databases associated with the User Profile 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.
3. In Central Administration, in the System Settings section, click Manage services on server.
4. On the Services on Server page, find User Profile Service. If the service is started, click Stop to stop the
service.
5. Before you restore the User Profile Service service application databases, you must import the Microsoft
Identity Integration Server (MIIS ) encryption key that you exported before backing up the databases. You
only have to do this one time for the restore process. To do this, on the server to which you are restoring the
service application, type the following at the command prompt:
miiskmu.exe /i exported.key {<GUID>}

Where _\<GIUD\>_ is the identifier of the key.
8. Right-click the database that you want to restore, point to Tasks, and then click Restore Database.
9. In the Restore Database dialog box, on the Options page, select the kind of recovery that you want to
perform from the Recovery state list.
For more information about which recovery type to use, see Recovery Models (SQL Server) .
10. On the General page, in the Destination for restore section, select the database from the To database
list.
11. In the Source for restore section, select the backup source from the From database list.
12. Alternatively, if you have moved the backup files to another computer, select the From device option. If the
correct backup is not listed in the Select the backup sets to restore box, browse to the file by clicking the
ellipsis button.
13. Select the backup to restore from the Select the backup sets to restore box, and then click OK.
15. Repeat steps 5-11 for the following databases associated with the User Profile Service service application
(the names that are listed are the default names):
User Profile Service_ProfileDB_ <GUID>

User Profile Service_SocialDB_ <GUID>
User Profile Service_SyncDB_ <GUID>
16. In Central Administration, in the System Settings section, click Manage services on server.
17. On the Services on Server page, find User Profile Service. If the service is stopped, click Start to start the
service.
See also
Concepts
Back up User Profile service applications in SharePoint Server
Other Resources
Windows PowerShell for SharePoint Server reference
Restore Search service applications in SharePoint
Server

You can restore SharePoint Server search by using the SharePoint Central Administration website, Microsoft
PowerShell, or SQL Server tools. The restore tool that you use depends on the kind of environment that you
have deployed, your schedule requirements, and service level agreements that you have made with your
organization.
Before you begin

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 SharePoint Search service application, Business
Data Connectivity service application, and the User Profile Service service application — provide data to other
services and sites. As a result, users might experience some service interruption until the recovery process is
completed.
Backing up and restoring search does not affect the state of the farm. However, it does require resources.
Therefore, backup and restore for search might affect farm performance while the backup is running. You
can avoid performance issues by backing up search during hours when farm use is lowest.
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.
Restore a thesaurus file

Thesaurus files are used to specify synonyms for words or phrases that occur in search queries. You create and
maintain the thesaurus files in systems external to SharePoint Server before you import them into SharePoint
Server to make them available to the search system. The thesaurus files are therefore not included in the default
SharePoint Server search backup procedures, and also not in the search recovery procedures outlined below.
To restore a thesaurus file
1. Follow one of the procedures below to restore the SharePoint Server Search service application.
2. If necessary, restore the thesaurus file using the restore procedures for the external system you are using
to create and maintain thesaurus files.
3. Import the thesaurus file to the SharePoint Server search system by using the Import-
SPEnterpriseSearchThesaurus PowerShell cmdlet as described in Deploy a thesaurus.
Use PowerShell to restore a SharePoint Search service application

You can use PowerShell to restore a service application.
To restore a Search service application by using PowerShell
cmdlets.
NOTE
2. Make sure that the server you are restoring to use the same drive mapping as the server where you
created the backup.
Restore-SPFarm -Directory <BackupFolder> -Item "<ServiceApplicationName>" -RestoreMethod Overwrite [-

Where:
<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
To restore all the service applications, at the PowerShell command prompt, type the following command:
Restore-SPFarm -Directory <BackupFolder> -Item "Farm\Shared Service Applications" -RestoreMethod

Overwrite [-BackupId <GUID>] [-Verbose]
Where:
_<GUID>_is the ID of the backup to use.
5. When you restore a Search service application, it is automatically paused. To resume the Search service
application when the restore has completed, type the following command:
$ssa = Get-SPEnterpriseSearchServiceApplication <SearchServiceApplicationName>$ssa.ForceResume(0x02)
Where:
<SearchServiceApplicationName> is the name the service application you want to resume.
NOTE
Index files are restored to one replica per index partition. After the restore has completed, the index for each replica is
replicated to the other index replicas. During this process the search topology is fully functional for crawling and queries,
but is not fault tolerant.
Depending on the size of the farm and the index, the process can take several hours and the index replicas appear
as degraded in the Search Administration UI and in the output of the Get-SPEnterpriseSearchStatus Microsoft
PowerShell cmdlet.
NOTE
Use Central Administration to restore a SharePoint Search service

application
Use the following procedure to restore a search service application by using the SharePoint Central
To restore a Search service application by using Central Administration
SharePoint group.
2. Make sure that the server you are restoring to use the same drive mapping as the server where you
created the backup.
backup.
NOTE
backup folder, and then click Refresh. > You cannot use a configuration-only backup to restore the farm.
Applications, select the check box that is next to the Search service application, and then click Next. To
restore all the service applications, select the Shared Services Applications node.
section, make sure that Farm\Shared Services Applications\<Service application> appears in the
Restore the following component list.
8. 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
in step 3.
9. When you restore a Search service application, it is automatically paused. To resume the Search service
application when the restore has completed you need to use PowerShell:
Verify that you are a member of the Administrators group on the server on which you are running the
PowerShell cmdlets.
cmdlets.
NOTE


$ssa.ForceResume(0x02)
Where:
<SearchServiceApplicationName> is the name the service application you want to resume.
NOTE
Index files are restored to one replica per index partition. After the restore has completed, the index for each replica is
replicated to the other index replicas. During this process the search topology is fully functional for crawling and queries,
but is not fault tolerant. Depending on the size of the farm and the index, the process can take several hours. The index
replicas appear as degraded in the Search Administration UI and in the output of the Get-SPEnterpriseSearchStatus
Microsoft PowerShell cmdlet during the process.
Use SQL Server tools to restore the databases for a Search service
application
You cannot restore the complete SharePoint Search 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 Search service application, use either PowerShell or Central Administration.
To restore the databases for a Search 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.
Database.
database drop-down list.
6. Select the restore source from the From database drop-down list.
For more information about which recovery type to use, see Recovery Models (SQL Server) .
See also
Concepts
Restore Secure Store Service applications in
SharePoint Server

You can restore the Secure Store service application by using the SharePoint Central Administration website or
PowerShell. The restore tool that you use depends on the kind of environment that you have deployed, your
schedule requirements, and service level agreements that you have made with your organization.
Before you begin

The Secure Store Service provides the capability of securely storing credential sets and associating credentials to
specific identities or a group of identities.
Before you begin this operation, review the following information about the Secure Store service application:
Every time that you enter a new passphrase, SharePoint Server creates a new Master Key and re-encrypts
the credentials sets with that key. The passphrase gives you access to the Master Key created by SharePoint
Server that is used to encrypt the credential sets.
You will need the passphrase that was recorded when the Secure Store Service was backed up to restore
the Secure Store Service.
Using Central Administration to restore the Secure Store Service in

SharePoint Server
Use the following procedure to restore the Secure Store Service by using Central Administration.
To restore the Secure Store Service by using Central Administration
backup.
contains the backup that you want, 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
backup folder, and then click Refresh. You cannot use a configuration-only backup to restore the Secure Store
Service.
Applications and select the check box that is next to the Secure Store Service application backup group,
and then click Next.
section, make sure that Farm\Shared Services\Shared Services Applications\<Secure Store Service
name> appears in the Restore the following component list.
status details by clicking Refresh. Backup and recovery are Timer service jobs. Therefore, it may take a
Job Status page. You can also find more details in the Sprestore.log file at the path that you specified in step
3.
8. After the restore operation has successfully completed, you must refresh the passphrase.
9. In Central Administration, on the home page, in the Application Management section, click Manage
10. On the Service Applications page, click the Secure Store Service name. You might receive an error that says
"Unable to obtain master key."
11. On the Secure Store Service page, on the ribbon, click Refresh Key.
12. In the Refresh Key dialog box, type the passphrase in the Pass Phrase box, and then click OK.
Using PowerShell to restore the Secure Store Service in SharePoint

Server
You can use PowerShell to restore the Secure Store Service.
To restore the Secure Store Service by using PowerShell
cmdlets.
NOTE

Restore-SPFarm -Directory <BackupFolder> -Item <SecureStoreServicename> -RecoveryMethod Overwrite [-
Where:
<SecureStoreServicename> is the name of the Secure Store Service application.
If you have multiple backups use the BackupId parameter to specify which backup to use. To view all of the
backups for the farm, type the following command at the PowerShell command prompt:
Get-SPBackupHistory -Directory <BackupFolder> -ShowBackup
NOTE
If you do not specify a value for the BackupId parameter, the most recent backup will be used. You cannot restore
the Secure Store Service from a configuration-only backup.
4. After the restore operation has successfully completed, you must refresh the passphrase. At the PowerShell
command prompt, type the following command:
Update-SPSecureStoreApplicationServerKey -Passphrase <Passphrase>
Where <Passphrase>, is the one that you currently use.

For more information, see Restore-SPFarm and Update-SPSecureStoreApplicationServerKey.
NOTE
See also
Concepts
Back up the Secure Store Service in SharePoint Server

You can restore a content database in SharePoint Server by using the SharePoint Central Administration website,
PowerShell, or SQL Server tools. The restore tool that you use depends on the kind of environment that you have
deployed, your schedule requirements, and service level agreements that you have made with your organization.
Before you begin

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 farms in SharePoint Server.
Before you begin this operation, review the following information about how to restore a content database:
SharePoint Server restores 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.
Using PowerShell to restore a SharePoint content database

You can use PowerShell to restore a content database.
To restore a content database by using PowerShell
cmdlets.
NOTE

Restore-SPFarm -Directory <BackupFolder> -RestoreMethod Overwrite -Item <ContentDatabase> [-BackupId

<GUID>] [-Verbose]
Where:
<BackupFolder> is the name and path for the backup folder where the service application was
backed up.
<ContentDatabase> is the name of the content database.
If you do not use the BackupId parameter, the most recent backup will be used. To view all of the backups
for the farm, type the following command at the PowerShell command prompt:
Get-SPBackupHistory -Directory <Backup folder>
NOTE
Using Central Administration to restore a SharePoint 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
SharePoint group.
backup.
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.
next to the content database, and then click Next.
NOTE
If the content database is not selectable, you must use PowerShell or SQL Server tools to restore the content
database.
6. 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.
in step 2.
Using SQL Server tools to restore a SharePoint 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.
running stored procedures to finish. Do not restart the service until after you restore the content databases.
Database.
processes.
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.
If you have included all the transaction logs that you must restore, select RECOVER WITH
RECOVERY.
NOTE

11. Repeat steps 4 through 10 for each database that you are restoring.
12. Start the SharePoint Timer service.
See also
Concepts
Attach and restore read-only content databases in
SharePoint Server

You can attach and restore a read-only content database in SharePoint Server by using PowerShell.
Before you begin

A SharePoint Server farm in which content databases are 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
Using PowerShell to attach and restore a read-only content database

You can use only PowerShell to attach and restore a read-only content database.
To attach and restore a read-only content database by using PowerShell
Server cmdlets.
NOTE

Mount-SPContentDatabase -Name <DatabaseName> -WebApplication <WebApplicationID> [-Verbose]
Where:
<DatabaseName> is name of the read-only database.
<WebApplicationID> is ID assigned to the read-only database.
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.
NOTE
See also
Concepts
Restore content from unattached content databases

You can restore content from an unattached content database in SharePoint Server by using the SharePoint
Central Administration website or PowerShell. The restore tool that you use depends on the kind of environment
that you have deployed, your schedule requirements, and service level agreements that you have made with your
organization.
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.
Using PowerShell to recover content from an unattached content

database in SharePoint Server
You can recover content from an unattached content database by using PowerShell. The following procedure
shows how to use the Get-SPContentDatabase cmdlet to recover content from an unattached content database. You
can also import a list or document library with the Import-SPWeb cmdlet. For more information, see Import a list or
document library in SharePoint Server.
To recover content from an unattached content database by using PowerShell
Server cmdlets.
NOTE

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.
NOTE
Using Central Administration to recover content from an unattached

content database in SharePoint Server
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
group and is a member of the db_owner fixed database role.
3. In Central Administration, on the home page, click Backup and Restore.
4. On the Backup and Restore page, in the Granular Backup section, click Recover data from an
unattached content database.
5. 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.
6. Select the database authentication method that you want to use.
7. Select the Browse content option, and then click Next.
8. 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.
9. Type the file location where you want to store the backup file, and then click Start Backup. For more
information about using the Backup site collection option, see Back up site collections in SharePoint
Server.
If you chose Export site or list in the previous page, you must select Export Full Security and choose the
version that you want to export in the Export Versions drop-down menu. For more information about
using the Export site or list option, see Export sites, lists, or document libraries in SharePoint Server.
See also
Concepts
Attach or detach content databases in SharePoint Server
Restore customizations in SharePoint Server

You can restore any customizations that are made to SharePoint Server by using Central Administration or
PowerShell. The restore tool that you use depends on the kind of environment that you have deployed, your
schedule requirements, and what service level agreements that you have made with your organization.
Before you begin

We recommend that you keep a backup of the original .wsp file and of the source code used to build the .wsp
file for both trusted and sandboxed solutions.
Restoring solution packages in SharePoint Server

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 complete 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 Server 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 Server farm, Web application, content database, and site collection backups,
but are not visible in the restore hierarchy, and cannot be selected or restored individually.
To restore a trusted solution by using Central Administration
SharePoint group.
backup.
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.
next to the solution, and then click Next.
section, make sure that Solution appears in the Restore the following component list.
box appears that asks you to confirm the operation. Click OK.
in step 3.
To restore a trusted solution by using PowerShell
Server cmdlets.
NOTE

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).
NOTE
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.
Restoring authored site elements in SharePoint Server

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.
Restoring workflows in SharePoint Server

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 that are created in SharePoint Designer, are stored in the content
database for the site collection to which they are deployed. Restoring the content database or site collection
restores these workflows.
The Visual Studio 2013 assemblies for the actions are stored in the global assembly cache (GAC ).
The XML definition files (.actions files) are stored in the 16\TEMPLATE< LCID>\Workflow directory.
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 2013, are
stored in two locations. The Visual Studio 2013 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
Server 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 are not deployed must be restored separately by using a file system backup application.
Restoring changes to the Web.config file in SharePoint Server

You can recover changes to the Web.config file made by using Central Administration or the SharePoint Server
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.
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.
%PROGRAMFILES%\Common files\Microsoft Shared\Web Commonly updated files, custom assemblies, custom

Server Extensions\16 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
See also
Concepts
Back up customizations in SharePoint Server
Restore farms in SharePoint Server

You can only restore a site collection in SharePoint Server by using PowerShell.
Using PowerShell to restore a site collection in SharePoint Server

You can use PowerShell to restore a site collection manually or as part of a script that can be run at scheduled
intervals.
To restore a site collection by using PowerShell
Server cmdlets.
NOTE

Restore-SPSite -Identity <SiteCollectionURL> -Path <Backup file> [-DatabaseServer <DatabaseServerName>]

[-DatabaseName <ContentDatabaseName>] [-HostHeader <Host header>] [-Force] [-GradualDelete] [-Verbose]
Where:
<SiteCollectionURL> is URL for the site collection you want to restore.
<DatabaseServerName> is name of the database server where the site collection resides.
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 SharePoint Server.
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
See also
Concepts
Restore apps for SharePoint in SharePoint Server

You can restore an apps for SharePoint environment by using the SharePoint Central Administration website,
Microsoft PowerShell, or SQL Server tools. The restore tool that you use depends on the kind of environment that
you have deployed, your schedule requirements, and service level agreements that you have with your
organization.
The app for SharePoint content and packages are stored in the SharePoint Server content databases in individual
site collections. The restore process requires you to restore all services that the app references. The apps for
SharePoint can reference the following SharePoint Server databases which you may have to restore. You should
also restore the site collection where the app for SharePoint is located if you are restoring the apps for SharePoint
to the same environment.
Content
Configuration
Before you begin

Content databases can store data for multiple site collections. If you have apps for SharePoint hosted in many site
collections you may also have multiple content databases. To back up and restore all of the apps for SharePoint in
your environment, you must back up and restore all content databases and site collections in the farm.
Restore content databases

You can restore a single content database or several content databases one at a time. For information about how
to restore a content database in a farm, see Restore content databases in SharePoint Server. For information about
how to back up and restore all the content databases in a farm at the same time, see Back up farms in SharePoint
Server.
Restore the configuration database

In SharePoint Server you do not have to restore the configuration database because you can restore the farm
configuration directly. For more information, see Restore farm configurations in SharePoint Server.
Restore the Secure Store Service application database

The Secure Store Service database stores and maps credentials to specific identities or a group of identities. You
must have the passphrase that was recorded when the Secure Store Service was backed up to restore it. To restore
the Secure Store database, see Restore Secure Store Service applications in SharePoint Server.
Restore the App Management service application database

The App Management service application database stores the app licenses and permissions for all apps
downloaded from the App Catalog site in SharePoint Server. You must restore this database to make sure that the
apps for SharePoint licenses and permissions are available in your farm. To restore the App Management
database, follow the same procedures as most other SharePoint Server service applications. For more information,
see Restore service applications in SharePoint Server.
Restore a site collection

You can only restore a site collection in SharePoint Server by using PowerShell. Use this section to restore a site
collection that contains apps for SharePoint to the same SharePoint Server environment. To restore to a new farm,
see Restore apps for SharePoint to a new farm.
Cau t i on
Any apps for SharePoint that contain remote components that are present on the backup copy of a site collection
could cause problems. This is because two copies of the app for SharePoint are accessing the remote connection
and can cause information disclosure or data loss. For example, when a site collection in a production environment
is copied by a backup for a development purpose, this could unintentionally grant developers access to production
data in remote sites if the app for SharePoint is not designed correctly.
To restore a site collection by using PowerShell
Server cmdlets.
NOTE

Restore-SPSite -Identity <SiteCollectionURL> -Path <Backup file> [-DatabaseServer <DatabaseServerName>]

[-DatabaseName <ContentDatabaseName>] [-HostHeader <Host header>] [-Force] [-GradualDelete] [-Verbose]
Where:
<SiteCollectionURL> is URL for the site collection you want to restore.
<DatabaseServerName> is name of the database server where the site collection resides.
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 SharePoint Server.
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 effect
on server performance.
For more information, see Restore site collections in SharePoint Server

For more information, see Restore-SPSite.
NOTE
Restore apps for SharePoint to a new farm

To restore apps for SharePoint to a new farm you must also backup and restore any services that the app
references. These SharePoint Server service applications can include the Secure Store Service service application,
Access Services in SharePoint, and the App Management Service. For more information, see the following articles:
Restore Secure Store Service applications in SharePoint Server
See also
Concepts
Back up apps for SharePoint in SharePoint Server
Import a list or document library in SharePoint
Server

You can import a site, list, or document library in SharePoint Server by using PowerShell.
Before you begin

Although you can use either PowerShell or Central Administration to export a site, list, or document library, you
can use only PowerShell to import a site, list, or document library. For information about how to export lists or
libraries, see Export sites, lists, or document libraries in SharePoint Server.
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 read-only content databases in SharePoint Server.
You cannot import a site, list or document library exported from one version of SharePoint Server to
another version of SharePoint Server.
Importing a site, list, or document library in SharePoint Server

You can use PowerShell to manually import a site, list, or document library or as part of a script that can be run
regularly.
To import a site, list or document library by using PowerShell
Server cmdlets.
NOTE

Import-SPWeb -Identity <SiteURL> -Path <ImportFileName> [-Force] [-NoFileCompression] [-Verbose]
Where:
<SiteURL> is the URL for the site that you are importing to.
<ImportFileName> is the name of the file that you are exporting from.
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 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 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 to import a subset of the items within the export file. Therefore, the
import operation will import everything from the file.
For more information, see Import-SPWeb.
NOTE
See also
Concepts
Export sites, lists, or document libraries in SharePoint Server
Backup and restore best practices in SharePoint
Server

Best practices for backup and restore help make sure that backup and restore operations in SharePoint Server are
successful and that the environment is protected against data loss or continuity gaps.
Performance best practices for SharePoint backup and restore

operations
Backup and restore operations consume server resources and limit server performance while the operations are
running. Follow these recommended practices to help reduce resource usage and increase the performance of
servers and the backup or restore task.
Minimize latency between SQL Server and the backup location
In general, it is efficient to back up to a local disk on the database server instead of a network drive. You can 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 perform well.
NOTE
If you cannot back up to local drives, use network drives with similar latency. Because network backups are subject to network
errors, verify the backup action after it finishes. For more information, see "Backing Up to a File on a Network Share" in
Backup Devices (SQL Server).
To avoid I/O bottlenecks, perform the main backup to a separate disk from the disk running SQL Servers 2017
RTM, 2016, 2014, 2012, or 2008 R2 with Service Pack 1 (SP1). For more information, see Define a Logical Backup
Device for a Disk File (SQL Server).
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 latency for I/O requests. This is typical and should not be
considered a problem. For more information, see Monitor Disk Usage.
Avoid processing conflicts
Do not run backup jobs during times when users need access to the system. Typically, systems run 24 hours a day,
seven days a week. A best practice is to always run incremental backups to safeguard against server failure.
Consider staggering backups so that all databases are not backed up at the same time.
Keep databases small for faster recovery times
Keep databases small to speed both backup and restore. For example, use multiple content databases for a web
application instead of one large content database. For more information, see Database types and descriptions in
SharePoint Server.
For a graphical overview of the databases that support SharePoint Server 2016, see Quick reference guide:
SharePoint Server 2016 databases.
Use incremental backups for large databases
Use incremental backups for large databases because you can make them quickly and maintain performance of the
environment. Although you can restore full backups faster than incremental backups, continuous incremental
backups minimize data loss. For more information about types of backups, see Backup Overview (SQL Server).
Use compression during backup
In some circumstances, you can use compression to decrease the size of backups and the time to complete each
backup. Backup compression was introduced in SQL Server 2008 Enterprise. Backup compression increases CPU
usage and this can affect SQL Server concurrent operations.
IMPORTANT
SharePoint Server supports SQL Server backup compression. SQL Server data compression is not supported for SharePoint
Server databases.
For more information about how backup compression affects performance in SQL Server, see Backup
Compression (SQL Server).
Follow SQL Server backup and restore optimization recommendations
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 number of transaction logs 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.
Use RAID 10 if you use RAID
Carefully consider whether to use redundant array of independent disks (RAID ) on the device to which you back up
data. For example, RAID 5 has slow write performance, approximately the same speed as for a single disk. This is
because RAID 5 has to maintain parity information. RAID 10 can provide faster backups because it doesn't need to
manage parity. Therefore, it reads and writes data faster. For more information about how to use RAID with
backups, see Configure RAID for maximum SQL Server I/O throughput and RAID Levels and SQL Server.
Configure SharePoint settings to improve backup or restore performance
You can only configure file compression and log file settings in PowerShell. You can configure backup and restore
threads in both the SharePoint Central Administration website and PowerShell to increase backup or restore
efficiency and performance.
If you use the Export-SPWeb PowerShell cmdlet, you can use the NoFileCompression parameter. By default,
SharePoint Server 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. However, the exported file uses approximately 25% less disk space. If you use
the NoFileCompression parameter when you export, you have to also use it when you import the same content.
You can also use the NoLogFile parameter. By default, SharePoint Server always creates a log file when you export
content. Although you can use this parameter to suppress log file creation to save resources, we recommend that
you always create logs. Logs are important for troubleshooting and log creation does not use many resources such
as CPU or memory.
When you use the Backup-SPFarm cmdlet, you can also use the BackupThreads parameter to specify how many
threads SharePoint Server will use during the backup process. A higher number of threads will consume more
resources during backup. But the overall time to make the backup is decreased. Because each thread is recorded in
the log files, the number of threads does affect log file interpretation. By default, three threads are used. The
maximum number of available threads is 10.
NOTE
The backup threads 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 you determine the tools to use
If the business requires site collection backups in addition to farm-level or database-level backups, choose a backup
tool that is based on the size of the site collection.
15-100 GB: Usethe Backup-SPSite , a SharePoint Server 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 site
collections in SharePoint Server.
Larger than 100 GB: Use a differential backup solution, such as SQL Server or System Center Data
Protection Manager R2, instead of the built-in backup and recovery tools.
Quality assurance best practices to back up a SharePoint farm

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 enough storage space
Be certain that the system has enough disk space to accommodate the backup. Configure a backup job in Central
Administration to verify the required disk space.
Routinely test backup quality
Routinely test backups and validate their consistency. Run practice recovery operations to validate the contents of
the backup and to make sure that you can restore the complete environment. To prepare for disaster recovery of
geographically dispersed environments, set up a remote farm. Then you can restore the environment by using the
database-attach method to upload a copy of the database to the remote farm and redirect users. Periodically
perform a trial data recovery action to verify that the process correctly backs up files. A trial restoration can expose
hardware problems that do not come up with software verifications and can also to make sure that the recovery
time objectives (RTO ) are met.
Back up ULS trace logs
The SharePoint Server backup process doesn't back up the Unified Logging Service (ULS ) trace logs. Data in ULS
trace logs can be useful for performance analysis, troubleshooting, and monitoring compliance with service level
agreements. Therefore, protect this data as part of the routine maintenance.
By default, SharePoint log files are at C:\Program files\Common Files\Microsoft Shared\Web Server Extensions\
<16 or 15>\Logs. The files are named with the server name followed by the date and time stamp. The SharePoint
trace logs are created at set intervals and when you use the IISRESET command.
Store a copy of backup files off-site
To safeguard against loss from a natural disaster that destroys the primary data center, maintain duplicate copies of
backups in separate locations from the servers. Duplicate copies can help prevent 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 to back up and restore SharePoint Server

Use the following procedural best practices to plan and perform backup and restore operations.
Use FQDN server names
When you refer to servers in a different domain, always use fully qualified domain names (FQDN ).
Keep accurate records
When you deploy SharePoint Server, record the accounts that you create, the computer names, passwords, and
setup options. Keep this information in a safe and secure location. Possibly, keep multiple records to make sure this
information is always available.
Have a recovery environment ready
Use a farm in a secondary location to validate the success of restore operations as part of your disaster recovery
strategy. For more information, see Choose a disaster recovery strategy for SharePoint Server. In a disaster
recovery situation, you can then restore the environment by using the database-attach method to upload a copy of
the database to the remote farm and redirect users. For more information, review and follow the steps in Restore
farms in SharePoint Server. Also for a high availability solution, 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. For more information, see Describing high availability.
Schedule backup operations
Use PowerShell backup and recovery cmdlets to create a script file (*.ps1) and then schedule it to run with
Windows Task Scheduler. This makes sure that all backup operations are run at the best time when the system is
least busy and users are not accessing it. For more information, see the following:
Running Scripts
Backup and recovery cmdlets in SharePoint Server 2016
Use the SQL FILESTREAM provider with BLOB storage
Remote BLOB Storage (RBS ) is supported in a SharePoint Server farm. There are both pros and cons associated
with using RBS in SharePoint Server. One related limitation of RBS with a SharePoint farm is that System Center
Data Protection Manager cannot use the FILESTREAM provider to back up or restore RBS. SharePoint Server
supports the FILESTREAM provider for backup and restore operations. A benefit of RBS with a SharePoint farm is
that you can use either SharePoint tools or SQL Server tools to back up and restore the content database with the
Remote BLOB Store (RBS ) defined. This backs up and restores both the RBS and the content database. We do not
recommend that you use RBS with other restore methods. For more information about the benefits and limitations
of using RBS, see Deciding to use RBS in SharePoint Server. Download Microsoft SQL Server 2014 Feature
Packthat includes RBS.
NOTE
SharePoint Server 2019 supports the FILESTREAM provider that is included with SQL Server 2017. SharePoint Server 2016
supports the FILESTREAM provider that is included with SQL Server 2014. For more information, see Enable and Configure
FILESTREAM.
NOTE
SharePoint Server 2013 supports the FILESTREAM provider that is included in the Microsoft® SQL Server® 2008 R2 Feature
Pack. The SQL Server 2012 and SQL Server 2014 installation media includes RBS as an optional add-on component.
See also
Concepts
Other Resources
Transparent Data Encryption
High availability and disaster recovery concepts in
SharePoint Server

High availability and disaster recovery is the highest priority when you create a plan and system specifications for
a SharePoint Server farm. Other aspects of the plan, such as high performance and capacity, are negated if farm
servers are not highly available or a farm cannot be recovered.
To design and implement an effective strategy that maintains efficient and uninterrupted operations, you should
understand the basic concepts of high availability and disaster recovery. These concepts are also important to
evaluate and pick the best technical solutions for your SharePoint environment.
Introduction to business continuity management

Business continuity management is a management process or program that defines, assesses, and helps manage
the risks to the continued running of an organization. Business continuity management focuses on creating and
maintaining a business continuity plan, which is a roadmap for continuing operations when normal business
operations are interrupted by adverse conditions. These conditions can be natural, man-made, or a combination
of both. A continuity plan is derived from the following analyses and inputs:
A business impact analysis
A threat and risk analysis
A definition of the impact scenarios
A set of documented recovery requirements
The result is a solution design or identified options, an implementation plan, a testing and organization
acceptance plan, and a maintenance plan or schedule.
An example of business continuity management is Disaster recovery and protection for data and applications,
which provides a snapshot of the business continuity program at Microsoft.
Obviously Information Technology (IT) is a significant aspect of business continuity planning for many
organizations. However, business continuity is more encompassing - it includes all the operations that are needed
to make sure that an organization can continue to do business during and immediately after a major disruptive
event. A business continuity plan includes, but is not limited to, the following elements:
policies, processes and procedures
possible options and decision-making responsibility
human resources and facilities
information technology
Although high availability and disaster recovery are often equated to business continuity management; they are
in fact, subsets of business continuity management.
Describing high availability

For a given software application or service, high availability is ultimately measured in terms of the end user's
experience and expectations. The tangible and perceived business impact of downtime may be expressed in terms
of information loss, property damage, decreased productivity, opportunity costs, contractual damages, or the loss
of goodwill.
The principal goal of a high availability solution is to minimize or mitigate the impact of downtime. A sound
strategy for this optimally balances business processes and Service Level Agreements (SLAs) with technical
capabilities and infrastructure costs.
A platform is considered highly available per the agreement and expectations of customers and stakeholders. The
availability of a system can be expressed as this calculation:
Actual uptime/Expected uptime X 100%
The resulting value is often expressed by industry in terms of the number of 9's that the solution provides; meant
to convey an annual number of minutes of possible uptime, or conversely, minutes of downtime.
NUMBER OF 9'S AVAILABILITY PERCENTAGE TOTAL ANNUAL DOWNTIME
2 99% 3 days, 15 hours
3 99.9% 8 hours, 45 minutes
4 99.99% 52 minutes, 34 seconds
5 99.999% 5 minutes, 15 seconds
Planned versus unplanned downtime

System outages are either anticipated or planned for, or they are the result of an unplanned failure. Downtime
need not be considered negatively if it is appropriately managed. There are two key types of foreseeable
downtime:
Planned maintenance. A time window is preannounced and coordinated for planned maintenance tasks
such as software patching, hardware upgrades, password updates, offline re-indexing, data loading, or the
rehearsal of disaster recovery procedures. Deliberate, well-managed operational procedures should
minimize downtime and prevent any data loss. Planned maintenance activities can be seen as investments
needed to prevent or mitigate other potentially more severe unplanned outage scenarios.
Unplanned outage. System-level, infrastructure, or process failures may occur that are unplanned or
uncontrollable, or that are foreseeable, but considered either too unlikely to occur, or are considered to
have an acceptable impact. A robust high availability solution detects these types of failures, automatically
recovers from the outage, and then reestablishes fault tolerance.
When establishing SLAs for high availability, you should calculate separate key performance indicators (KPIs) for
planned maintenance activities and unplanned downtime. This approach allows you to contrast your investment
in planned maintenance activities against the benefit of avoiding unplanned downtime.
Degraded availability
High availability should not be considered as an all-or-nothing proposition. As an alternative to a complete
outage, it is often acceptable to the end user for a system to be partially available, or to have limited functionality
or degraded performance. These varying degrees of availability include:
Read-only and deferred operations. During a maintenance window, or during a phased disaster
recovery, data retrieval is still possible, but new workflows and background processing may be temporarily
halted or queued.
Data latency and application responsiveness. Due to a heavy workload, a processing backlog, or a
partial platform failure, limited hardware resources may be over-committed or under-sized. User
experience may suffer, but work may still get done in a less productive manner.
Partial, transient, or impending failures. Robustness in the application logic or hardware stack that
retries or self-corrects upon encountering an error. These types of issues may appear to the end user as
data latency or poor application responsiveness.
Partial end-to-end failure. Planned or unplanned outages may occur gracefully within vertical layers of
the solution stack (infrastructure, platform, and application), or horizontally between different functional
components. Users may experience partial success or degradation, depending upon the features or
components that are affected.
The acceptability of these suboptimal scenarios should be considered as part of a spectrum of degraded
availability leading up to a complete outage, and as intermediate steps in a phased disaster recovery.
Quantifying downtime
When downtime does occur, either planned, or unplanned, the primary business goal is to bring the system back
online and minimize data loss. Every minute of downtime has direct and indirect costs. With unplanned
downtime, you must balance the time and effort needed to determine why the outage occurred, what the current
system state is, and what steps are needed to recover from the outage.
At a predetermined point in any outage, you should make or seek the business decision to stop investigating the
outage or performing maintenance tasks, recover from the outage by bringing the system back online, and if
needed, reestablish fault tolerance.
Recovery objectives
Data redundancy is a key component of a high availability database solution. Transactional activity on your
primary SQL Server instance is synchronously or asynchronously applied to one or more secondary instances.
When an outage occurs, transactions that were in flight may be rolled back, or they may be lost on the secondary
instances due to delays in data propagation.
You can both measure the impact, and set recovery goals in terms of how long it takes to get back in business,
and how much time latency there is in the last transaction recovered:
Recovery Time Objective (RTO ). This is the duration of the outage. The initial goal is to get the system
back online in at least a read-only capacity to facilitate investigation of the failure. However, the primary
goal is to restore full service to the point that new transactions can take place.
Recovery Point Objective (RPO ). This is often referred to as a measure of acceptable data loss. It is the
time gap or latency between the last committed data transaction before the failure and the most recent
data recovered after the failure. The actual data loss can vary depending upon the workload on the system
at the time of the failure, the type of failure, and the type of high availability solution used.
NOTE
A related objective is Recovery level objective (RLO). This objective 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. For more information, see Plan for backup and recovery in SharePoint Server.
You should use RTO and RPO values as goals that indicate business tolerance for downtime and acceptable data
loss, and as metrics for monitoring availability health.
Justifying ROI or opportunity cost
The business costs of downtime may be either financial or in the form of customer goodwill. These costs may
accrue with time, or they may be incurred at a certain point in the outage window. In addition to projecting the
cost of incurring an outage with a given recovery time and data recovery point, you can also calculate the
business process and infrastructure investments needed to attain your RTO and RPO goals or to avoid the outage
all together. These investment themes should include:
Avoiding downtime. Outage recovery costs are avoided all together if an outage doesn't occur in the first
place. Investments include the cost of fault-tolerant and redundant hardware or infrastructure, distributing
workloads across isolated points of failure, and planned downtime for preventive maintenance.
Automating recovery. If a system failure occurs, you can greatly mitigate the impact of downtime on the
customer experience through automatic and transparent recovery.
Resource utilization. Secondary or standby infrastructure can sit idle, awaiting an outage. It also can be
leveraged for read-only workloads, or to improve overall system performance by distributing workloads
across all available hardware.
For given RTO and RPO goals, the needed availability and recovery investments, combined with the projected
costs of downtime, can be expressed and justified as a function of time. During an actual outage, this allows you
to make cost-based decisions based on the elapsed downtime.
Monitoring availability health
From an operational point of view, during an actual outage, you should not attempt to consider all relevant
variables and calculate ROI or opportunity costs in real time. Instead, you should monitor data latency on your
standby instances as a proxy for expected RPO.
In the event of an outage, you should also limit the initial time spent investigating the root cause during the
outage, and instead focus on validating the health of your recovery environment, and then rely upon detailed
system logs and secondary copies of data for subsequent forensic analysis.
Planning for disaster recovery
While high availability efforts entail what you do to prevent an outage, disaster recovery efforts address what is
done to re-establish high availability after the outage.
As much as possible, disaster recovery procedures and responsibilities should be formulated before an actual
outage occurs. Based upon active monitoring and alerts, the decision to initiate an automated or manual failover
and recovery plan should be tied to pre-established RTO and RPO thresholds. The scope of a sound disaster
recovery plan should include:
Granularity of failure and recovery. Depending upon the location and type of failure, you can take
corrective action at different levels; that is, data center, infrastructure, platform, application, or workload.
Investigative source material. Baseline and recent monitoring history, system alerts, event logs, and
diagnostic queries should all be readily accessible by appropriate parties.
Coordination of dependencies. Within the application stack, and across stakeholders, what are the
system and business dependencies?
Decision tree. A predetermined, repeatable, validated decision tree that includes role responsibilities, fault
triage, failover criteria in terms of RPO and RTO goals, and prescribed recovery steps.
Validation. After taking steps to recover from the outage, what must be done to verify that the system has
returned to normal operations?
Documentation. Capture all of the above items in a set of documentation, with sufficient detail and clarity
so that a third party team can execute the recovery plan with minimal assistance. This type of
documentation is commonly called a 'run book' or a 'cook book'.
Recovery rehearsals. Regularly exercise the disaster recovery plan to establish baseline expectations for
RTO goals, and consider regular rotation of hosting the primary production site on the primary and each
of the disaster recovery sites.
See also
Concepts
Choose a disaster recovery strategy for SharePoint Server
Other Resources
What workloads can you protect with Azure Site Recovery?
Replicate a multi-tier SharePoint application for disaster recovery using Azure Site Recovery
Choose a disaster recovery strategy for SharePoint
Server

We define disaster recovery as the ability to recover from a situation in which the primary data center that hosts a
SharePoint Server farm is unable to continue to operate. Regardless of the nature of event and its cause, the data
center outage is significant enough to set into motion the actions defined in your organization's disaster recovery
plan. This means putting a fully operational farm into production using computer resources that are located in a
data center that is not affected by the event.
SharePoint Servers 2019, 2016, 2013, and the SQL Servers that support them provide configuration and content
recovery options that can meet the Recovery Time Objective (RTO ) and Recovery Point Objective (RPO ) that are
required for your business if there is a disaster. For more information about these and other disaster recovery
concepts, see High availability and disaster recovery concepts in SharePoint Server.
Introduction
An effective disaster recovery strategy for a SharePoint Server farm must be sufficient to meet your
organization's business requirements, which are typically expressed by using two measures: Recovery Time
Objective (RTO ) and Recovery Point Objective (RPO ). RTO and RPO requirements are derived by determining the
downtime cost to the organization if a disaster happens.
IMPORTANT
As a best practice we recommend that you clearly identify and quantify your organization's RTO and RPO before you
develop a recovery strategy and implement a technical solution. Focus on what is required, not how to do it.
Downtime costs vary significantly between and within industries, especially due to the different effects of
downtime. Business size is the most obvious factor. However, it is not the only one. Setting a measure means
establishing the nature and implications of the failure. Reduced to the simplest level, a failure of a critical
application could lead to the following types of losses:
Loss of the application service. The effect of downtime varies with the application and the business.
Loss of data. The potential loss of data due to a system outage can have significant legal and financial
impact.
Most organizations will incur a downtime cost from both of the previous types of loss but the nature of the
business will determine which type of loss has the biggest effect. The following article, written by Chris
Preimesberger at eWEEK, highlights the financial effect of data center downtime. Unplanned IT Downtime Can
Cost $5K Per Minute: Report.
In most scenarios, SharePoint products is one of several applications that must be recovered in the event of a data
center shutdown that qualifies as a disaster. For this reason we have not included information about disaster
recovery planning but focus on options for making sure that you can recover your SharePoint Server farm at
another location.
Regardless of the type and scale of a disaster, recovery involves the use of a standby data center that you can
recover the farm to.
Standby data center recovery options
Standby data centers are required for scenarios where local redundant systems and backups cannot recover from
the outage at the primary data center. The time and immediate effort to get a replacement farm up and running in
a different location is often known as a hot, warm, or cold standby. Our definitions for these farm recovery data
centers are as follows:
Cold standby. A secondary data center that can provide availability within hours or days.
Warm standby. A secondary data center that can provide availability within minutes or hours.
Hot standby. A secondary data center that can provide availability within seconds or minutes.
Each of these standby data centers has specific characteristics and requirements, and also an associated cost to
operate and maintain.
Cold standby disaster recovery strategy: A business ships backups to support bare metal recovery to local
and regional offsite storage regularly, 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 with Azure Site Recovery.
Pros: Often fairly 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 fairly fast to recover.
Cons: Can be very expensive to configure and maintain.
IMPORTANT
No matter which of the previous disaster recovery solutions that you decide to apply, there is likely going to be some data
loss.
Cold standby recovery

In a cold standby disaster recovery scenario, you 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 the farm using a backup
solution such as System Center - Data Protection Manager (DPM ). DPM protects your data at the computer
operating system 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:
Warm standby recovery
In a warm standby disaster recovery scenario, you create a warm standby environment by creating a duplicate
farm at the alternate data center and ensure that it is updated regularly by using full and incremental backups of
the primary farm.
Virtual warm standby environments
Virtualization provides a workable and cost effective option for a warm standby recovery solution. You can use
Hyper-V as an in-house solution or Azure as a hosted solution to provide necessary infrastructure for recovery.
You can create virtual images of the production servers and ship these images to the standby data center. By
using the virtual standby solution, you have to make sure that the virtual images are created often enough to
provide the level of farm configuration and content freshness that you must have for recovering the farm. 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. For more information, see Deploying SharePoint Server 2016 with
SQL Server AlwaysOn Availability Groups in Azure
Hot standby recovery
In a hot standby disaster recovery scenario, you set up a failover farm in the standby data center so that it can
assume production operations almost immediately after the primary farm goes offline. An environment that has a
separate failover farm has the following characteristics:
A separate configuration database and the SharePoint Central Administration website content database
must be maintained on the failover farm.
All customizations must be deployed on both farms.
TIP
There is consistency between the two farms and to reduce the possibility of error we recommend that you use
scripted deployment to create the primary and failover farm by using the same configuration settings and
customizations.
Operating system, SQL Server and SharePoint Server software updates must be applied to both farms, to
maintain a consistent configuration across both farms.
You can copy SharePoint Server content databases to the failover farm by using asynchronous mirroring,
asynchronous commit on an availability group replica, or log-shipping.
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.
The SQL Server database mirroring feature will be removed in future versions. We recommend that you
avoid using this feature in new deployments. Plan to change applications that currently use this feature.
Use AlwaysOn Availability Groups instead.
Service applications vary in whether they can be log-shipped to a farm. For more information, see Service
application redundancy later in this article.
The hot standby farm topology can be repeated across more than one data center, as long as you configure SQL
Server log shipping to one or more additional data centers.
IMPORTANT
Available network bandwidth and latency are major considerations when you are using a failover approach for disaster
recovery. We recommend that you consult with your SAN vendor to determine whether you can use SAN replication for
SQL databases or another supported mechanism to provide the hot standby level of availability across data centers. Note
that using SAN replication for SharePoint servers is not supported.
Service application redundancy

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 being
used.
The databases associated with the service application can be log-shipped, asynchronously mirrored, or
replicated using asynchronous commit.
The service application can run against read-only databases.
Review the Supported high availability and disaster recovery options for SharePoint databases article before
designing a disaster recovery solution that uses a warm or hot standby data center.
System requirements for 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 have to 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 Server versions and all updates
In addition to the previous requirements, farm recovery time will also be affected by availability of facilities and
infrastructure components. Make sure that the following requirements are met:
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
Concepts
High availability and disaster recovery concepts in SharePoint Server
Other Resources
Plan for SQL Server Always On and Microsoft Azure
for SharePoint Server Disaster Recovery

Use SQL Server 2014 and SQL Server 2016 Always On Availability Groups and Microsoft Azure to create a hybrid
disaster-recovery environment for your on-premises SharePoint Server farm. This article describes how to design
and implement this solution.
The solution in this article applies to the following:
Microsoft Azure
SQL Server 2014 Enterprise
Windows Server 2012 R2 Datacenter
SharePoint Server 2016 Enterprise
SQL Server 2014 with Service Pack 1 (SP1)
SQL Server 2016 Enterprise edition
Windows Server 2016 Datacenter edition
SharePoint Server 2019 Enterprise
SQL Server 2016
SQL Server 2017
Windows Server 2016
Windows Server 2019
Acknowledgments: This SharePoint Server disaster recovery solution is the result of the design, testing, and
writing done by Tejinder Rai (MCS ). This solution combines Microsoft best practices with hands-on, real world
customer experiences. David Williams and Matthew Robertshaw also made significant contributions to this article
by their work with SQL Server failover automation and recovery testing.
NOTE
The references and instructions for SharePoint Server 2016 in this article also apply to SharePoint Server 2019.
Introduction to hybrid disaster recovery for SharePoint Server

Setting up a suitable disaster recovery environment can be an expensive and very complicated process. It requires
careful planning to deploy and test a solution that meets your business goals for getting your production
environment and applications up and running again.
When it comes to disaster recovery, SharePoint Server raises the bar for complexity and the need for careful
planning, design, and testing. Some of the constraints that you have to consider are the different types of failover
that SQL Server supports for Availability Group replicas, as well as the fact that several SharePoint databases don't
support asynchronous commit to a replica, and special handling is required to recover these special cases.
SharePoint Server Search recovery
SharePoint Search is one of the cases that requires a different approach and special techniques for recovery in a
disaster scenario. This is because you can't maintain database fidelity for the search index and file system if you use
Always On Availability Groups with asynchronous commit to a secondary replica.
It is important to understand the four available disaster recovery options for Search in a SharePoint Server farm.
Each option has its pros and cons, and the best option is driven by business continuity and recovery requirements.
For more information about the supported options, which include a hybrid option for recovering the Search
service in a farm hosted in a public cloud, see Disaster recovery best practices and strategies for SharePoint 2016
search.
Disaster recovery criteria
Before the availability of cloud technologies, organizations had to set up and maintain a secondary data center as a
standby environment that could run mission critical systems if there was a disaster. The costs associated with
creating and operating a secondary data center prevented many organizations from setting up a disaster recovery
environment for SharePoint.
The availability and maturity of cloud infrastructure and platform services make Microsoft Azure a viable and cost
effective alternative to operating a secondary data center.
In addition to the basic costs associated with a secondary datacenter, businesses also need to determine recovery
requirements for critical systems and corporate data. Recovery requirements are determined by answering the
following two questions:
How long can we be offline before the business suffers significant losses? For example, these losses could be
revenue, damaged business relationships, or credibility.
How much data can we lose before the business suffers significant losses? In addition to the offline
examples, some sectors are totally data driven and dependent.
In the disaster recovery world these criteria are quantified as Recovery Time Objectives (RTOs) and Recovery Point
Objectives (RPOs).
NOTE
A related objective is Recovery Level Objective (RLO). This objective 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. For more information, see Plan for backup and recovery in SharePoint Server.
The cost of a disaster recovery solution is tied to these objectives—the reality is that better RTO and RPO cost
more. The objective and cost level also determine the recovery environment you choose. The industry terminology
for three basic disaster recovery environments are: Cold Standby, Warm Standby, and Hot Standby. There are
variations of course, depending on the business sector.
For more information about disaster recovery solutions, see High availability and disaster recovery concepts in
SharePoint Server and Choose a disaster recovery strategy for SharePoint Server.
This article provides a framework that you can use to deploy a hybrid disaster recovery solution for SharePoint
Server.
What's not in this article
The following topics are out of scope for this article:
Creating a business continuity and associated disaster recovery plan.
Service level requirements for RTO and RPO.
Cost assessment based on service level requirements.
Detailed steps for the following:
Configuring a Windows Server Failover Cluster (WSFC ) cluster
Provisioning an Azure environment (storage accounts, virtual networks, cloud services, availability
sets, and virtual machines)
Configuring a VPN tunnel from on-premises farm to Azure recovery environment
Disaster recovery solution description and architecture

Our hybrid solution uses a topology that provides cross-continental redundancy in North America. The following
test farms are deployed in two locations:
An on-premises production farm running in a datacenter in Redmond, WA (West coast).
A recovery farm deployed on Microsoft Azure. This farm is hosted in a datacenter in the Eastern part of the
United States. This farm is set up as a warm standby recovery environment.
The solution we describe uses SQL Server Always On Availability Groups as an end-to-end solution that provides
high availability and disaster failover recovery. In addition to providing high availability in a production
environment SQL Server Always On improves RTO because the SQL Server instances in the secondary datacenter
contain a replica of the databases from the primary datacenter.
Our test environment and conditions are designed to represent the type of SharePoint production farm and
disaster recovery solution that mainstream customers are building.
Logical architecture
The next illustration (Figure 1) shows the logical architecture for this solution and highlights the use of Availability
Group replicas on-premises and in Azure.
Figure 1 Logical architecture for hybrid environment
Detailed architecture
The next figure (Figure 2) shows the detailed architecture for the on-premises test farm. The farm is configured as a
highly available farm with enterprise search.
NOTE
All the diagram labels are based on the naming convention we used to build out and test this disaster recovery scenario.
They provide reference points for the article.
Figure 2 On-premises production farm

The next figure (Figure 3) shows the detailed topology of the warm standby farm deployed in Azure.
Figure 3 Warm standby recovery farm
What you need for this SharePoint Server disaster recovery solution
Use the following requirements as a guide to start planning the deployment of this disaster recovery solution.
Infrastructure and general configuration
The following list is a summary of the infrastructure and general configuration requirements for the on-premises
farm and the recovery farm:
Two SharePoint Server farms. A production farm in your primary datacenter and a warm standby farm that
uses Azure as the secondary datacenter. An added benefit to using Azure is that you don't have to worry
about using identical hardware for both farms.
Each farm is online in both datacenters.
Software versions and patch levels. Both farms use the same software version and patch level for:
Windows Server 2012 R2 or Windows Server 2016
SQL Server 2014 or SQL Server 2016
SharePoint Server 2016 or SharePoint Server 2013
Both farms are configured to use the same service accounts for administering SharePoint.
Content databases and service application databases are distributed across one or more SQL Server
Availability Groups.
Use synchronous commit mode for the replicas in the on-premises environment. This is the typical high
availability configuration for a SharePoint farm because it supports automatic failover and minimizes data
loss.
Use asynchronous commit mode for the replica in the recovery environment. Although automatic failover
isn't supported, data throughput is usually better which can be a very important factor when the distance
between the production and recovery farms is significant.
NOTE
There are cases where synchronous commit to a replica in a recovery environment have been tested and
implemented because throughput is the same as using asynchronous commit to the recovery replica. However, this is
not broadly accepted or recommended.
Each farm has its own service applications that have synchronized databases between the two
environments. Because read-only databases are used for service applications in the disaster recovery farm,
service applications do not need to be re-provisioned when the production farm fails over.
Search crawling with Read-Only databases in the disaster recovery instance. If this is required you need to
configure a separate Search Service Application for the recovery farm. For more information, see Supported
high availability and disaster recovery options for SharePoint databases.
TIP
Use automation wherever and whenever possible. Scripted deployment and configuration ensures configuration consistency
and reduces errors caused by typing commands or navigating through the user interface to configure the farm.
Mandatory configuration requirements for both farms

The following technologies are needed to deploy the disaster recovery solution described in this article:
Windows Server 2012 R2 or Windows Server 2016
SharePoint Server 2016 or SharePoint Server 2013 with Service Pack 1 and the May 2014 cumulative
update
SQL Server 2014 or SQL Server 2016
A secure connection between the primary data center and the recovery farm in Azure. We used a VPN
connection but if ExpressRoute is available in your area consider using it.
Understand database requirements: SQL Server Always On and

SharePoint Server
The primary datacenter will utilize availability group synchronous-commit replicas to achieve high availability in
the primary farm. The secondary datacenter must utilize asynchronous-commit replicas. This is due to the latency
on the network between the primary and secondary datacenters. It is important to monitor the latency of replaying
log buffers to the disaster recovery farm during testing.
Dependencies, prerequisites, and best practices
Review the following dependencies, prerequisites, and best practices before building out the test farms.
Windows Server Failover Clustering (WSFC ) cluster
The WSFC cluster will span two datacenters. All the nodes in the on-premises datacenter and the recovery
environment belong to the same WSFC cluster.
SQL Server configuration for SharePoint
Create SQL Server volumes to separate the SQL databases, farm databases, database log files, tempdb
databases, and tempdb database log files.
Distribute the farm databases over the volumes according to read/write speed. Using fastest to slowest to
set priorities, the following distribution is typical:
Tempdb data and transaction log files
Database Transaction log files
Search database files
Content databases
Set up the accounts for the SQL Server service and the SQL Agent service.
Use the configurations in the following table when you deploy SQL Server for the SharePoint farms.
COMPONENT SETTINGS
COMPONENT SETTINGS
Port Block UDP port 1434.

We recommend that you block TCP port 1433, and assign the
port that is used by the default instance to a different port.
However, this is not mandatory.
Make sure that the port number that is to be assigned to the
default instance is not in the registered ports. Refer to Service
Name and Transport Protocol Port Number Registry to avoid
using the registered port.
Ensure that you follow the security guidance in Configure SQL
Server security for SharePoint Server.
Firewall Rules: Create new Inbound rules for the non-default
port used by the SQL Server instance.
Hide instance: Hide the SQL Server instance from client
computers.
Lock pages in memory Grant the SQL Server service account permissions to lock
pages in memory. For more information, see Enable the Lock
Pages in Memory Option (Windows) and Server Memory
Server Configuration Options.
Disable Auto-create statistics Do not enable auto-create statistics on SQL Server. This is not
supported for SharePoint Server. For more information, see
Best practices for SQL Server in a SharePoint Server farm.
Set Max Degree of Parallelism Set the max degree of parallelism (MAXDOP) to 1 in SQL
Server instances that host SharePoint Server databases.
Note: SharePoint Server installation on SQL Server will fail by
design unless the installer account has permission to change
it.
For more information, see Best practices for SQL Server in a
Trace Flags Add the trace flags 1222 (return resources and types of locks
participating in a deadlock) and 3226 (suppress log backup
entries in the SQL error log).
DBCC TRACEON (1222,-1)
DBCC TRACEON (3226,-1)
SQLAgent Job History Make sure that SQLAgent has these settings,
(Jobhistory_max_rows = 50000 and
Jobhistory_max_rows_per_job = 10000).
Minimum memory Min Memory = 512 Mb. (However, this is based on our test
configuration and may not apply to your SQL Server
installation so you should calculate your requirement.) For
more information, see Server Memory Server Configuration
Options and Configure the min memory per query Server
Configuration Option.
Maximum memory Set the maximum memory limit for SQL Server based on the
following formula:
Total Server RAM (GB) - 4 GB = [max server memory]
For more information, see Server Memory Server
Configuration Options.
COMPONENT SETTINGS
DNS aliases We recommend that you create DNS aliases for all SQL Server
instances. This helps to simplify maintenance, such as to make
it easier to move databases to another server. For example,
the SharePoint farm in the Azure disaster recovery datacenter,
connects directly to the SQL Server instance names. You
should create a DNS alias rather than configure the farm with
the instance names directly.
Note: The client alias and DNS alias should match to ensure
clients which don't use SQL client aliases can also contact SQL
servers.
For more information, see Best practices for SQL Server in a
Database collation Latin1_General_Cl_AS_KS_WS

The SQL Server database collation must be configured for
case-insensitive, accent-sensitive, kana-sensitive, and width-
sensitive. This is to ensure file name uniqueness consistent
with the Windows operating system.
Design requirements and considerations

Each SQL Server instance that is part of an Always On Availability Group must also be part of the same WSFC
cluster. An Availability Group has a primary replica, which has the most current data, and secondary replicas that
receive updates from the primary replica. Each availability replica must reside on a different node of a single
Windows Server Failover Clustering (WSFC ) cluster. All of the SQL Server nodes, which are part of a single
Windows Server Failover Cluster, require their own storage, unlike SQL Server Failover Cluster Instances (FCIs).
For more information about prerequisites, restrictions, recommendations, and general usage for availability
groups, see:
Prerequisites, Restrictions, and Recommendations for AlwaysOn Availability Groups (SQL Server)
AlwaysOn Availability Groups (SQL Server)
The next figure (Figure 4) shows the Availability Group replica infrastructure that we used for the SharePoint
databases.
Figure 4 Availability Group replica infrastructure
In the infrastructure shown in Figure 4, a common practice is to have the database servers in the recovery
environment on a separate subnet, which must be taken into account when configuring WSFC and Availability
Group listeners.
You also need to plan for and test network latency between the on-premises farm and the recovery environment.
The latency between replicas will have an impact on your Recovery Point Objective (RPO ).
Finally, think about provisioning the database servers in the recovery environment in their own Azure cloud
service, which is how the test environment was built. Cloud services lets you group server roles so you can manage
Azure VMs as a single entity. For more information, see Should I choose cloud services or something else?.
Like SharePoint Server, it is easier to design the architecture up front, rather than having to redesign Azure's
platform services later.
Availability group commit modes and failover types
It is important to understand how commit modes affect the different types of failover for each Availability Group
configuration because this will affect farm recovery. The following table is from the SQL Server documentation.
This table summarizes which forms of failover are supported under different availability and failover modes. For
each pairing, the effective availability mode and failover mode is determined by the intersection of the modes of
the primary replica plus the modes of one or more secondary replicas. For more information, see Failover and
Failover Modes (AlwaysOn Availability Groups).
SYNCHRONOUS-COMMIT SYNCHRONOUS-COMMIT
MODE WITH AUTOMATIC- MODE WITH MANUAL- ASYNCHRONOUS-COMMIT
FAILOVER TYPE FAILOVER MODE FAILOVER MODE MODE
Automatic failover Yes No No
Planned manual failover Yes Yes No
Forced failover Yes (1) Yes Yes

(1) If you issue a forced failover command on a synchronized secondary replica, the secondary replica behaves the
same as for a manual failover.
The amount of time that the database is unavailable during a failover depends on the type of failover and its cause.
Supported high availability and disaster recovery options for SharePoint databases
The tables in this section summarize the supported high availability and disaster recovery options for SharePoint
Server databases. For more detailed information, see Supported high availability and disaster recovery options for
SharePoint databases.
HIGH AVAILABILITY (SYNCHRONOUS DISASTER RECOVERY (ASYNCHRONOUS

DATABASE NAME SUPPORT) SUPPORT)
SharePoint Config Yes No
SharePoint Admin Content Yes No
State Service Yes No
WSS Content X Yes Yes
The following table lists the SharePoint service application databases.

App Management Yes Yes
Business Connectivity Services Yes Yes
Managed Metadata Yes Yes
PerformancePoint Yes Yes
PowerPivot Yes Yes
Project (SharePoint Server 2013 only) Yes Yes
Secure Store Yes Yes
Subscription Settings Yes Yes
Machine Translation Services Yes Yes
UPS Profile Yes Yes
UPS Social Yes Yes
UPS Sync Yes No
Usage Yes No
Word Automation Yes Yes

The following table lists the SharePoint Search databases.

Search Admin Yes No
Search Crawl Yes No
Search Link Store Yes No
Search Analytics Store Yes No
Build out the test farms in six phases

There are several phases to building out a SharePoint environment which provides High-Availability (HA) and
Disaster Recovery (DR ). We organized the steps for configuring the on-premises and recovery farms into the
following phases:
1. Build phase 1: Configure the Windows Server Failover Cluster and SQL Server Always On for the on-
premises environment.
2. Build phase 2: Install and configure SharePoint Server to create the on-premises farm.
3. Build phase 3: Configure Windows Server Failover Cluster and SQL Server in the recovery environment.
4. Build phase 4: Install and configure SharePoint Server to create the recovery farm.
5. Build phase 5: Finish configuring the recovery endpoint and replicate databases to the recovery farm.
6. Build phase 6: Finish configuring SharePoint Server on the recovery farm.
Do some preparation before you start
The following table lists the key infrastructure components for this disaster recovery scenario. We've identified
prerequisites and provided configuration guidance.
INFRASTRUCTURE COMPONENT NOTES
Domain controller For our on-premises test environment we deployed a domain

controller and created the corp.adventureworks.com domain.
If you decide to run a proof of concept disaster recovery
scenario you can use your organization's domain name.
Note: After we configured the domain, we also provisioned all
of the VMs we'd be using for the farm and patched the OS to
the same level. This made things more manageable than
taking a piecemeal approach.
INFRASTRUCTURE COMPONENT NOTES
Windows Server 2012 R2 and Windows Server 2016 failover Windows Server 2012 R2 or Windows Server 2016 on each
clustering farm server configured according to best practices (Windows
Server and SharePoint Server). For more information, see
Windows Server Failover Clustering (WSFC) with SQL Server.
Every server that will be a cluster node must have the Failover
Cluster feature and the Failover Cluster Management MMC
installed.
A file share for the WSFC Quorum. As a best practice this
should be configured in a third site that can be accessed by
the on-premises site and the recovery site.
Document and stick to a consistent naming convention for the
cluster.
SQL Server database configuration and Always On Availability SQL Server 2014 or SQL Server 2016 configured according to
Groups SharePoint requirements and the best practices identified in
"Dependencies, prerequisites and best practices".
Databases use full recovery model. For more information, see
Recovery Models (SQL Server).
SQL Server instance names. (We used the Default instance
name, which is supported in this design across all the cluster
nodes).
The same file paths for the database and log file locations for
each SQL Server instance. We used the following drive layouts,
(System (L:) for SQL databases and SharePoint databases),
(User (S:) for tempdb databases and log files), and (Local disk
(T:) for SharePoint SQL backups).
Document and stick to a consistent naming convention for the
Availability Groups, the replicas, and the listeners.
Networking Cluster nodes - Three static IP Cluster IP addresses (two for

the on-premises farm and one for the recovery farm).
Availability Group Listeners - A static IP addresses for each
listener. (Our test farm used four listeners.)
Microsoft Azure gateway server A server in Azure that provides the endpoint for the VPN
gateway connection from the on-premises farm. It is
configured with the Active Directory Domain Services (AD DS)
and DNS Services roles and is designated as a global catalog
server for the test domain (corp.adventureworks.com).
When there is a disaster this server can become the primary
domain controller.
VPN gateway A site-to-site VPN or ExpressRoute configured between the

primary datacenter and the Windows Azure Subscription
where the disaster recovery farm will be configured.
For more information, see Create a VNet with a Site-to-Site
connection using the classic portal (classic) and Create and
modify an ExpressRoute circuit using PowerShell (classic).
Microsoft Azure and the recovery environment

The first steps in building out the recovery environment are to deploy a server in Azure and then establish a VPN
or ExpressRoute connection between the on-premises farm and the Azure server.
Azure Infrastructure as a Service (IaaS ) has many similarities to an on-premises private cloud that uses Windows
Server Hyper-V virtualization and System Center Virtual Machine Manager (VMM ). However, even IT
professionals with extensive experience working in a private cloud get tripped up by the differences!
The Appendix data sheet in the appendix will help you plan, deploy, and operate SharePoint Server 2016 in the
Azure environment. It doesn't replace the Azure documentation and hands-on experience, but it will ease you into
the Azure world from a SharePoint perspective. For information about Azure disaster recovery solutions, see
Replicate a multi-tier SharePoint application for disaster recovery using Azure Site Recovery and Azure Site
Recovery.
Build phase 1
The next table provides more information about the steps in Build phase 1.
STEP NOTES AND GUIDANCE
1. Configure a two-node WSFC cluster Use the Windows Server article, Create a Failover Cluster to
create a two-node cluster. For Windows Server 2016
information, see Failover Clustering in Windows Server 2016.
2. Configure a file share witness The preferred configuration for WSFC in a SharePoint
environment is to use a file share witness and a node majority.
Both cluster nodes in the on-premises farm have a quorum
vote. The cluster node in the recovery farm doesn't have a
vote.
For more information, see Configure and Manage the Quorum
in a Windows Server 2012 Failover Cluster. For Windows
Server 2016, see Deploy a Cloud Witness for a Failover
Cluster.
Use the following Microsoft PowerShell cmdlet to configure a
file share and node majority Quorum:
Set-ClusterQuorum -NodeAndFileShareMajority
"\\fileserver\share"
Use the following PowerShell cmdlet to assign votes:
(Get-ClusterNode {CLUSTERNODENAME}).NodeWeight=1
Use the following PowerShell syntax to configure a Cloud
Witness:
Set-ClusterQuorum -CloudWitness -AccountName
<StorageAccountName> -AccessKey
<StorageAccountAccessKey>
3. Install SQL Server on each Windows cluster node Install SQL Server on both Windows Server cluster nodes.
Note the following:
Do not run the SQL Server setup program for a failover
cluster. These nodes are not part of a SQL Failover Cluster
Instance (FCI) Cluster.
Make sure that the SQL Server data paths are exactly the
same for each instance.
For more information, see Install SQL Server 2014 from the
Installation Wizard (Setup) or Install SQL Server 2014 from the
Command Prompt. Also, see Install SQL Server from the
Installation Wizard (Setup).
4. Enable SQL Server Always On Use the guidance in Enable and Disable AlwaysOn Availability
Groups (SQL Server) to enable Always On. Use theSQL
Server2016 guidance in Enable and Disable Always On
Availability Groups (SQL Server).
The database grouping section after this table shows how you
can logically group SharePoint databases and map them to
different availability groups to meet your disaster recovery
requirements as well as your high availability requirements.
5. Configure farm account security Configure the appropriate permissions in each SQL Server
instance for the SharePoint setup user administrator account.
This account must be a member of the db_owner role and
assigned to the securityadmin and dbcreator SQL Server
security roles during setup and configuration.
For more information, see Configure SQL Server security for
SharePoint Server and Account permissions and security
settings in SharePoint Server 2016.
6. Create availability groups, Always On Endpoints, and Create the availability groups for synchronous-commit mode
Availability Group Listeners for high availability. (It is common practice to configure the
availability groups logically for the logical failover of
databases). After you create the Always On Endpoints, create
Availability Group listeners to enable client connectivity to
each availability group.
Note: You can create the availability groups with temporary
database names so SharePoint can use the listeners when the
farm is configured. This is so the database connection strings
point to the appropriate DNS entries created by the listeners.
This saves you having to reconfigure the listeners later.
For more information, see Configure SQL Server AlwaysOn
Availability Groups for SharePoint Server.
For information, see Create a Database Mirroring Endpoint for
AlwaysOn Availability Groups (SQL Server PowerShell). For
SQL Server 2016 information, see Database Mirroring -
Always On Availability Groups- PowerShell.
For information, see Availability Group Listeners, Client
Connectivity, and Application Failover (SQL Server). For SQL
Server 2016 information, see Listeners, Client Connectivity,
Application Failover.
Note: If you create the Availability Group Listeners using SQL
Server Management Studio, you have to add an IP address for
the disaster recovery subnet for each listener. This is not
required if you provision Availability Group Listeners using the
SQL Server New-SqlAvailabilityGroupListener PowerShell
cmdlet. The recovery farm will reference the SQL instances
through DNS host (A) entries and not the Availability Group
listeners. For more information, see New-
SqlAvailabilityGroupListener.
Database grouping for disaster recovery

We recommend that you group SharePoint databases and assign them to different availability groups based on
your disaster recovery requirements.
You need to do this because each availability group has a synchronous commit replica on-premises for high
availability and an asynchronous commit replica in the disaster recovery environment.
As noted in the Supported high availability and disaster recovery options for SharePoint databases section,
databases that support synchronous commit don't necessarily support async replicas. The following table is an
example of how databases can be grouped for specific Always On Availability Groups.
AVAILABILITY GROUP NAME SHAREPOINT DATABASES
AG_SPConfig (1) SharePoint Config, SharePoint Admin Content, State Service,

and UPS Sync (AG Synchronous only)
AG_SPContent WSS Content X
AG_SPServices App Management, Business Connectivity Services, Managed

Metadata, PerformancePoint, PowerPivot, Secure Store Service,
Subscription Settings, Machine Translation Services, UPS Profile
and UPS Social, Word Automation, and Usage (This database
supports only synchronous commit, and because it holds
transient data that's used for data mining, we don't
recommend replicating this data in a disaster recovery
scenario.) (2)
AG_SPSearch Search Admin, Search Crawl, Search Link, and Search Analytics
Reporting
(1) These names are only examples. You can use your own naming convention.
(2) The Usage database can be created independently on each SQL Server instance in the cluster. In addition to
storing transient data, it also has very high transactions, which is another reason not to place it in an availability
group. You can utilize the Set-SPUsageApplication cmdlet to create the database in the secondary SQL instance.
Then use the Set-SPUsageApplication cmdlet with the -FailoverDatabaseServer option to specify the secondary
SQL instance in the highly available environment.
The next table describes our test configuration at the end of Build phase 1.
SERVER NAME DESCRIPTION
DC2 Domain controller
SP-WFE1, SP-WFE2 Web content servers
SP-APP1 to SP-APP6 inclusive Application servers (for example, Central Administration,

services, and search)
SP-SQL-HA1, SP-SQL-HA2 These servers are configured as two nodes in our WSFC
cluster (SPDRCluster), each with one vote. Host the farm
databases, configured with Always On Availability Groups. SP-
SQL-HA1 has the primary replica role and SP-SQL-HA2 has
the secondary replica role. These availability groups and
listeners are configured: Availability groups = PROD-AG1,
PROD-AG2, PROD-AG3, PROD-AG4; Listeners = SQL-PROD-
AG1, SQL-PROD-AG2, SQL-PROD-AG3, SQL-PROD-AG4
FS1 This server provides the file share cluster quorum

(Hybrid5SPDRClusterQuorum) for the WSFC cluster. It is also
used as a shared distribution software point for the test farm.
SERVER NAME DESCRIPTION
OP-FILESERVER (optional) This server provides a Distributed File System Replication

(DFSR) service endpoint for the on-premises environment. The
other endpoint is in our Azure environment. DFSR serves two
purposes. First, we use it to store SQL Server backups
(incremental and full) which are written to a server (AZSP-FS1)
in Azure. We did this to simulate off-site storage and in a
disaster scenario, we can use this backups to restore
SharePoint search. The DFSR configuration also lets us move
files between the two farms relatively easily.
Build phase 2

1. Create build scripts We recommend that you develop a set of build scripts to
install SharePoint Server 2016. These scripts can also be used
to build out the recovery farm (and future SharePoint farms).
Because the recovery farm will have service applications that
are identical to those in the on-premises farm, it's a best
practice to use identical service application and database
names. Scripting reduces configuration errors and ensures
consistency in farm configuration.
Note: Service applications reference their databases by the
database name, unlike the Content databases, which also have
a database ID that's stored in the SharePoint configuration
database.
There are several examples of scripted SharePoint installations
that you might be able to leverage in your environment. For
example, SharePointDsc or AutoSPInstaller is an end-to-end
open source program available at Codeplex.
Ensure that the farm configuration database, the content
databases, and service application databases point to the DNS
alias of the SQL Server instance that you use. The SharePoint
Server 2016 databases will be created with a connection string
mapped to the SQL Server instance. Later they will be moved
to availability groups using SharePoint Server PowerShell
cmdlets.
After you create the farm configuration databases, we
recommend scripting the following common tasks:
Join a SharePoint Server to the farm by using the
Join-SharePointFarm cmdlet
Register Managed Accounts by using the
New-SPManagedAccount cmdlet
Create Web Applications
Create Site Collections
Create Service Applications
Set the SharePoint App domain and Prefix
2. Install prerequisites and binaries For more information, see Install prerequisites for SharePoint
Server from a network share.
3. Configure Farm SMTP Settings, Web Apps, and Site Use the New-SPWebApplication cmdlet to create Web
Collections Applications and use the New-SPSite cmdlet to create Site
Collections.
4. Configure Service Applications Use the Service Application cmdlets in Index of Windows
PowerShell cmdlets for SharePoint Server 2016 to configure
5. Add the on-premises production farm databases to When you finish configuring the farm, add the farm databases
availability groups and synchronize the replicas to the appropriate availability groups. Use these PowerShell
cmdlets to add the databases and verify that they've been
added to the availability group you specify,
Add-DatabasetoAvailabilityGroup and
Get-AvailabilityGroupStatus
Important: Make sure that you enable the full recovery
model on all databases that are to be added to an availability
group before you add them.
After you add the farm configuration database to an
availability group you must restart all the servers in the farm
to ensure farm stability.
Synchronize the availability group replicas. For more
information, see Select Initial Data Synchronization Page
(AlwaysOn Availability Group Wizards).
Build phase 3
1. Add two nodes to the Azure disaster recovery datacenter Configure these settings on the server that will be the new
which will stretch the on-premises WSFC cluster cluster node; Install the Windows Failover clustering feature,
test the cluster, and then remove the quorum vote from the
new node.
Open the Windows PowerShell command line as an
Administrator and run the following cmdlet to install the
Windows Failover clustering feature and management tools:
Install-WindowsFeature -Name Failover-Clustering -
IncludeManagementTools
Test the cluster with the following cmdlet: Test-Cluster
Remove the Quorum vote from the server with the following
commands:
(Get-ClusterNode {CLUSTERNODENAME}).NodeWeight=0
For more information, see Configure and Manage the Quorum
in a Windows Server 2012 Failover Cluster. For Windows
Server 2016 information, see Deploy a Cloud Witness for a
Failover Cluster.
Note: If you use the same architecture as our test
environment, you'll have to perform these configuration steps
on both the SQL Server instances in the recovery
environment.
2. Install the SQL Server instances Install SQL Server on both nodes. Ensure that the data paths
are exactly the same for each SQL instance and that the
configurations are identical, for example, port configurations,
database collation, and so on. For more information, see Install
SQL Server 2012 from the Installation Wizard (Setup). Also,
see Install SQL Server from the Installation Wizard (Setup).
3. Enable SQL Server Always On Availability Groups Use SQL Server Configuration Manager to enable SQL Server
Always On Availability Groups. For more information, see
Enable and Disable AlwaysOn Availability Groups (SQL Server).
For SQL Server 2016 guidance, see Enable and Disable Always
On Availability Groups (SQL Server).
Refer to the table in Build phase 1 for examples of the logical
grouping of SharePoint Server 2016 databases to availability
groups.
4. Configure farm account security Configure the appropriate permissions in each SQL Server
instance for the SharePoint setup user administrator account.
This account must be a member of the db_owner role and
assigned to the securityadmin and dbcreator SQL Server
security roles during setup and configuration.
For more information, see Configure SQL Server security for
SharePoint Server, Account permissions and security settings
in SharePoint Server 2016, and Account permissions and
security settings in SharePoint 2013
Build phase 4

1. Create build scripts We recommend that you develop a set of build scripts to
install SharePoint Server. These scripts can also be used to
build out the recovery farm (and future SharePoint farms).
Because the recovery farm will have service applications that
are identical to those in the on-premises farm, it's a best
practice to use identical service application and database
names. Scripting reduces configuration errors and ensures
consistency in farm configuration.
Note: Service applications reference their databases by the
database name, unlike the Content databases which also have
a database ID that's stored in the SharePoint configuration
database.
There are several examples of scripted SharePoint installations
that use PowerShell. For example, SharePointDsc or
AutoSPInstaller is an end-to-end open source program
available at Codeplex.
Ensure that the farm configuration database, the content
databases, and service application databases point to the DNS
alias of the SQL Server instance that you use. The SharePoint
Server databases will be created with a connection string
mapped to the SQL Server instance. Later they will be moved
to availability groups using SharePoint PowerShell cmdlets.
After you create the farm configuration databases, we
recommend scripting the following common tasks:
Join a SharePoint Server to the farm by using the
Join-SharePointFarm cmdlet. Register Managed Accounts
by using the New-SPManagedAccount cmdlet. Create Web
applications, site collections, and service applications. Finally,
set the SharePoint App domain and prefix.
2. Install the prerequisites and binaries For more information, see Install prerequisites for SharePoint
Server from a network share.
3. Configure farm SMTP settings, Web Applications, and Site Use the New-SPWebApplication cmdlet to create Web
Collections Applications and use the New-SPSite cmdlet to create Site
Collections.
4. Configure Service Applications Use the Service Application cmdlets in Index of Windows
PowerShell cmdlets for SharePoint Server 2016 to configure
Note: Service Applications are created in the disaster recovery
farm, with the exact same name as the primary farm. Ensure
the database names are also named exactly the same as the
primary farm, as the database will be referenced by the Service
Applications in the disaster recovery farm, where the service
application databases will eventually be created as replicas. As
part of the process, the databases in the disaster recovery
farm will be restored from the primary replicas, when the
asynchronous replicas are added to the SQL Availability
Group.
The content databases in the disaster recovery farm can be
removed from the SharePoint configuration as the primary
farm content databases will have a read-only replica available
in the disaster recovery SQL Server instance.
Use the SharePoint 2016 Management Shell to run the
following PowerShell cmdlet to dismount any content
databases from the disaster recovery farm
Remove-SPContentDatabase .
If any additional content databases exist on the SQL Server
instances in the disaster recovery farm, delete all of them. You
can use any of these methods, DROP DATABASE (Transact-
SQL), Database.Drop Method (), or Delete a Database.
5. Shut down the farm Shut down the farm after you finish configuring SharePoint.
Now you can create asynchronous replicas for the databases
on the on-premises farm.
Build phase 5
1. Verify that the SQL instance can access the database and Each node in an availability group must have access to a
backup shares. common backup location. This is required for the initial
database seeding during the process of adding replicas to the
availability group.
The SQL Server account must have access to the common
backup location.
2. Create a SQL Server endpoint and grant connect You must create a logon on the disaster recovery SQL Server
permissions to the endpoint. instance in order to create a secondary replica and join the
databases to the Availability Groups. For more information,
see Set Up Login Accounts for Database Mirroring or
AlwaysOn Availability Groups (SQL Server) and Set Up Login
Accounts - Database Mirroring Always On Availability.
A SQL Server endpoint is required on the primary replica so
the SQL instance can send log buffers to the secondary
replicas. Use the process in Create a Database Mirroring
Endpoint for AlwaysOn Availability Groups (SQL Server
PowerShell) and Database Mirroring - Always On Availability
Groups- PowerShell to create the endpoint.
You must give the service account on the primary SQL Server
instance access to the endpoint in order to transfer log buffers
to the disaster recovery instances. Connect permission is
required.
For more information, see GRANT Endpoint Permissions
(Transact-SQL).
3. Create secondary replicas of the user content and service Each Availability Group requires a secondary replica in the
application databases in the recovery farm instance. disaster recovery farm. You must be connected to the SQL
instance that is hosting the primary replica before you can
create the secondary replica.
For more information, see Add a Secondary Replica to an
Availability Group (SQL Server).
4. Ensure that the replicas in the recovery farm are configured The availability replicas in the DR SL Server instances are
for Read-Only access. configured as readable secondary replicas. The disaster
recovery farm will access the service application and content
databases in read-only mode. This is because the recovery
farm is already referencing the service application database
names. This reduces the Recovery Time Objective (RTO) when
we failover to the DR environment.
Note: If this is not configured correctly, you may experience
errors in the recovery environment.
For more information, see Configure Read-Only Routing for an
Availability Group (SQL Server) and Configure Read-Only
Access on an Availability Replica (SQL Server).
5. Copy logons from the primary SQL Server instance to the You have to copy SQL logons and passwords from the
secondary SQL Server instances. primary instance to the secondary instances. SQL Server
copies only the content of an availability group database.
Logons and passwords are not copied from one instance to
another.
For more information, see How to transfer logins and
passwords between instances of SQL Server and Troubleshoot
Orphaned Users (SQL Server).
Build phase 6
1. Power up the recovery farm Now that the service application and content databases are
available in read-only mode in the recovery farm SQL
instances, you can power up the SharePoint farm.
2. Mount the content databases to the web application(s) For every content database that has a read-only replica in the
disaster recovery SQL instance, which holds the most current
content in the primary farm, the database needs to be
mounted in the appropriate web applications in the disaster
recovery farm. You can use the Mount-SPContentDatabase
cmdlet to mount the content databases.
3. Refresh sites in configuration database We recommend that you refresh the sites in the SharePoint
configuration database. Use the PowerShell example shown in
the (1) note after this table, to refresh the sites for each
content database.
4. Check the farm services Verify that all the farm services are running as expected.
5. Perform a farm health check Perform health checks on the farm to make sure that the farm
is stable and working correctly.
(1) Use the following PowerShell syntax for step 3 in the Build phase 6 table.
# Refresh sites in the configuration database

Get-SPContentDatabase -WebApplication http://webapplicationsitename | ForEach {
Write-host "Refreshing sites in configuration database for database: " $_.Name
$_.RefreshSitesInConfigurationDatabase()}
Test farm failover and recovery

The procedures in this section explain how to simulate a farm failover and then a recovery. After the recovery use
the procedures to failback to the on-premises farm.
Service applications on the DR farm were created as part of the build process. Since the service applications will be
recovered from a full site failure, they will be in write mode in the disaster recovery site as the recovery of the SQL
Availability Groups in the disaster recovery SQL instances will become the primary replica after the disaster
recovery failover is complete. Data movement to the SQL Server instances in the primary data center will no
longer continue and will be placed in a paused state until they are manually restarted. When a SQL instance hosts
a primary Availability Group Replica, all other replicas are considered secondary replicas in the Availability Group.
Use the following steps to recover the SharePoint farm in the failover environment when you start a failover.
Failover step 1
A disaster recovery decision is typically started based on management decisions by Business Continuity
Management (BCM ) teams and service owners. The DR decision is usually considered when the primary site is no
longer accessible and the following procedures will perform a failover of the primary farm to the disaster recovery
farm.
Failover step 2
Start a cluster and availability group failover
Perform a failover of the cluster and the availability groups by using the PowerShell cmdlets shown in the
following list.
1. Stop the Cluster Service by running Stop-Service Clussvc .
2. Start the cluster node and fix the Quorum by using the following command:
Start-ClusterNode -Name <ACTIVE SQL NODE> -FixQuorum
3. Move the cluster group to an active SQL node in the disaster recovery data center by using the following
command.
Move-ClusterGroup -Cluster <CLIUSTER GROUP> -node <ACTIVE SQL NODE>
4. Confirm the Cluster Service is started by using the following command.
Get-ClusterNode -Name "<NodeName>"
5. Adjust the voting rights for the cluster. All SQL Server nodes in the disaster recovery site must be provided
Quorum voting rights. Repeat the following command for each cluster node in the disaster recovery datacenter.
(Get-ClusterNode -Name "NodeName").NodeWeight=1

Get-ClusterNode | fl Name, NodeWeight
6. After the remote node is granted a vote for the Quorum, use the following command to remove the votes of the
two nodes in the on-premises farm.
(Get-ClusterNode -name "Node1").NodeWeight=0

(Get-ClusterNode -name "Node2").NodeWeight=0
7. Use the following command to check the node weight settings.
Get-ClusterNode | fl Name,NodeWeight
8. When the node weights are applied successfully, the availability groups can be moved to the appropriate SQL
Server instances in the disaster recovery farm by using the SQL Server Switch-SqlAvailabilityGroup cmdlet.
You must use the -AllowDataLoss parameter when you run this cmdlet. For example:
Switch-SqlAvailabilityGroup -Path SQLSERVER:\Sql\<SQLNODE>\<MSQLINSTANCE>\AvailabilityGroups\<AGName> -

AllowDataLoss
9. Perform this operation for each Availability Group.
For more information, see Perform a Planned Manual Failover of an Availability Group (SQL Server).
Failover step 3
SharePoint Content Databases
Mount any additional SharePoint content databases that were not part of the original farm configuration.
Additional content databases were probably created since the initial deployment and added to an availability group.
IMPORTANT
It is very important as part of an operational process that any content databases created in the primary farm are added to
the availability groups and mounted in the disaster recovery farm.
Use the Mount-SPContentDatabase cmdlet to mount the content databases.

We recommend that you refresh the sites in the SharePoint Configuration database. For each Content database,
use the following code to refresh the sites in the Configuration database. This ensures that the site map is up to
date.
# Refresh sites in the configuration database

Get-SPContentDatabase -WebApplication http://webapplicationsitename | ForEach {
Write-host "Refreshing sites in configuration database for database: " $_.Name
$_.RefreshSitesInConfigurationDatabase() }
Failover step 4
Service Applications
Log on as a member of the Farm Administrators SharePoint group and complete the following tasks:
1. Verify the service applications are accessible.
2. Start the User Profile Synchronization Service on one server in the disaster recovery farm.
3. Perform a full import of the user profiles.
NOTE
The Secure Store Service might require the SharePoint Farm Administrator to refresh the key in order to decrypt the
applications that are registered in the Secure Store. The administrator must have full permissions to the Secure Store before
refreshing the key. You can also use the Update-SPSecureStoreApplicationServerKey cmdlet to update the Secure Store
key.
NOTE
The User Profile Synchronization timer job must be re-enabled and profile imports should be scheduled. Since the databases
are now in write mode after a failover, the imports should be scheduled accordingly.
Failover step 5
Configure DNS Redirection
Update DNS to provide the following redirections:
To the recovery farm for web applications and site collections.
To the recovery farm for the application domain.
Failover step 6
Validate the recovery
Run Test Cases in your environment to ensure that the recovery is as expected.
After you validate the recovery:
Enable the User Profile Synchronization Service Timer job.
Schedule a full backup of the recovery farm.
Failover step 7
Send out notifications
Notify the appropriate business stakeholders once the recovery validation is complete.
Conclusion
After you failover and validate the recovery, you are in a position to start configuring the farm to meet the current
and future operational requirements such as capacity and high availability. These requirements are determined by
the duration of the downtime and recovery of the farm in the on-premises datacenter.
As a final note, you have to review and validate your plan for falling back to the on-premises farm when it's
operational again.
Appendix
Appendix 1: Getting started in Microsoft Azure
ITEM NOTES
Azure subscriptions and storage accounts At a minimum, you will need one subscription to create the
Azure recovery farm. After you have a subscription, you can
create up to 100 uniquely named storage accounts. As in the
case of other Azure services, there are standard and premium
storage accounts. For more information, see Introduction to
Microsoft Azure Storage.
Cloud services When you create the server for the VPN gateway, a cloud
service gets created for the virtual machine. At this point, you
have to determine how many cloud services you want to have
for the recovery farm. You obviously don't want a cloud
service for every server in the farm; but should you use one or
several? There are good arguments for both options. By
grouping virtual machines into separate cloud services, you
can work with several servers as a single unit. In our test farm,
we used four cloud services. The first was for the VPN gateway
and then one for each of the following tiers: front end web
servers, application servers, and the database servers. For
more information, see Should I Choose Cloud Services?.
Networking Virtual networks are important in this disaster recovery

scenario. For more information, see Virtual Network
documentation.
ITEM NOTES
PowerShell PowerShell Azure cmdlets can help you automate tasks in your
virtual environment. For more information, see Windows
Azure PowerShell Cmdlets (v2.2.2).
Automation Azure supports using runbooks to automate a broad range of

provisioning and management tasks. For more information,
see Getting started with Azure automation.
Virtual Machines, Machine sizing Azure VMs are available in multiple series which have different
performance and capacity characteristics. You can mix and
match machines based on your workloads and farm tiers.
For more information, see Sizes for Windows virtual machines
in Azure.
Availability sets Availability sets are an option we recommend because they

ensure that the virtual machines in a set (a minimum of two)
are hosted on different racks for high availability. They are also
required if you want to take advantage of the Azure SLA. In
addition to managing the availability of your virtual machines,
availability sets work in conjunction with load balancing and
support scaling for a group of servers.
Note: SharePoint Server 2016 doesn't support automatic
scale up or scale down of farm servers.
For more information, see Manage the availability of Windows
virtual machines in Azure.
See also
Other Resources
SharePoint Server 2016 in Microsoft Azure
Supported high availability and disaster recovery
options for SharePoint databases

This article describes the supported high availability and disaster recovery options for SharePoint Server
databases. For detailed information about these databases, such as size and supported backup and recovery tools,
see Database types and descriptions in SharePoint Server.
Introduction
The scope of this article is the supported high availability and disaster recovery solutions for each SharePoint
Server system and service application database. These solutions address the database level, instead of the
database instance or database server level and include the following: database mirroring, database availability
groups, and log shipping.
When you evaluate a high availability or a disaster recovery option for SharePoint, you must understand that not
all of the options are supported by each SharePoint database. This is because of design requirements and feature
characteristics.
This article identifies the supported option for each SharePoint database. These databases are grouped by SKU
and then by feature.
SharePoint Server system databases

The Configuration, Central Administration Content, and Content databases are the databases that are
automatically installed when you deploy any SharePoint 2013 edition, and any SharePoint Server 2016 and
SharePoint Server 2019 server roles using the MinRole feature. For more information, see Description of
MinRole and associated services in SharePoint Servers 2016 and 2019.
The following tables provide the supported high availability and disaster recovery options for the SharePoint
system databases.
Configuration database
CATEGORY DESCRIPTION
Default database name when it is installed with the SharePoint_Config

Purpose The configuration database contains data about SharePoint

databases, Internet Information Services (IIS) web sites, web
applications, Trusted solutions, Web Part packages, and Site
templates.
The configuration database also contains specific data for
SharePoint Server farm settings, such as default quota
settings and blocked file types.
Supports SQL Server 2014 with Service Pack 1 (SP1), SQL Yes
Server 2016, and SQL Server 2017 RTM synchronous
mirroring in a farm for availability
Supports SQL Server 2008 R2 and SQL Server 2012
synchronous mirroring in a farm for availability
Supports SQL Server AlwaysOn Availability Group with Yes

synchronous-commit for availability
Supports SQL Server 2014 (SP1), SQL Server 2016, and SQL No. This is a farm specific database.
Server 2017 RTM asynchronous mirroring or log-shipping to
another farm for disaster recovery
Supports SQL Server 2008 R2 asynchronous mirroring or log-
shipping to another farm for disaster recovery
Supports SQL Server AlwaysOn Availability Group with No. This is a farm specific database.
asynchronous-commit for disaster recovery
Central Administration content database
Default database name when it is installed with the SharePoint_AdminContent_<GUID>

Purpose This database stores all configuration data for the Central
Administration site collection. If SQL Server 2016 RTM, Power
Pivot for SharePoint Server 2016 or SQL Server 2012 Power
Pivot for SharePoint 2013 is installed the Central
Administration content database also stores the Excel Online
and Excel worksheets and Power Pivot data files that are used
in the Power Pivot Management Dashboard.
Note: Power Pivot for SharePoint Server 2016 is only
available with SQL Server 2016 RTM.
Supports SQL Server 2014 (SP1), SQL Server 2016, and SQL Yes
Server 2017 RTM synchronous mirroring in a farm for
availability

Supports SQL Server 2014 (SP1), SQL Server 2016, and SQL No. This is a farm specific database.
asynchronous mirroring or log-shipping to another farm for
disaster recovery
Supports SQL Server AlwaysOn Availability Group with No. This is a farm specific database.
Content database
Default database name when it is installed with the WSS_Content

Purpose Content databases store all content for a site collection. This
includes site documents or files in document libraries, list
data, Web Part properties, audit logs, and some apps for
SharePoint data if the apps are installed, in addition to user
names and rights.
Content databases also store user data for SQL Server 2016
CTP 3.1 or later, Power Pivot for SharePoint Server 2016 and
SQL Server 2012 Power Pivot for SharePoint 2013, if you
installed it in your SharePoint Server environment.
Additionally Content databases also store the Project Server
2016 extensions in SharePoint Server 2016.
availability

disaster recovery

SharePoint Servers 2016 and 2019 service application databases

All SharePoint Servers 2016 and 2019 service applications store specific data and objects in either a unique
database or a system database. These databases are created to support features that are used in SharePoint
Server 2016 and 2019 farms.
The following sections describe the supported high availability and disaster recovery options for SharePoint
Server 2016 and 2019 service application databases.
The following table provides the supported high availability and disaster recovery options for the App
Management database.
App Management database
Default database name when it is installed with the 2016/2019: AppMng_Service_DB_<GUID>

SharePoint Products Configuration Wizard 2013: AppManagement
Purpose Stores app licenses and permissions that are downloaded

from the SharePoint Store or App Catalog.
availability

disaster recovery

Business Data Connectivity service database

The following table describes the supported high availability and disaster recovery options for the Business Data
Connectivity database.
Business Data Connectivity service database
Default database name when it is installed with the Bdc_Service_DB_<GUID>

Purpose Stores external content types and related objects.
availability

disaster recovery

Managed Metadata Service database

The following table describes the supported high availability and disaster recovery options for the Managed
Metadata Service database.
Managed Metadata Service database
Default database name when it is installed with the 2016/2019: Managed Metadata Service_<GUID>
SharePoint Products Configuration Wizard 2013: Managed Metadata Service
Application_Metadata_<GUID>
Purpose Stores managed metadata and syndicated content types.
availability

disaster recovery

NOTE
The Managed Metadata Service is the Taxonomy service. This database cannot be attached to a Managed Metadata Service
Application in read only mode.
PerformancePoint Services database

The following table describes the supported high availability and disaster recovery options for the
PerformancePoint Services database.
PerformancePoint Services database
Default database name when it is installed with the 2016/2019: PerformancePoint Service Application_<GUID>
SharePoint Products Configuration Wizard 2013: PerformancePoint Service_<GUID>
Purpose Stores temporary objects and saved user comments and

settings.
availability

disaster recovery

Power Pivot Service database

The following table describes the supported high availability and disaster recovery options for the Power Pivot
Service database.
NOTE
Power Pivot for SharePoint Server 2016 is only available with SQL Server 2016 CTP 3.1 or later.
NOTE
Power Pivot for SharePoint 2013 is only available with SQL Server 2012 SP1 Analysis Services (SSAS).
Power Pivot Service database
Default database name when it is installed with the Power DefaultPowerPivotServiceApplicationDB_<GUID>

Pivot for SharePoint Configuration Tool
Purpose Stores data refresh schedules, and workbook usage data for
internal use by Power Pivot service applications.
Supports SQL Server 2016 RTM synchronous mirroring in a Yes, but not recommended. Use AlwaysOn in Synchronous-
farm for availability Commit Mode instead.
Supports SQL Server AlwaysOn Availability Group in Yes, recommended.

Synchronous-Commit Mode for availability
Supports SQL Server 2016 RTM asynchronous mirroring or Yes

log-shipping to another farm for disaster recovery
disaster recovery

Project Server database

IMPORTANT
The Project Server service application database is only found in SharePoint Server 2013. Project Servers 2016 and 2019
don't create a database for SharePoint Servers 2016 and 2019 but use the Content database (WSS_Content).
The following table describes the supported high availability and disaster recovery options for the Project Server
database.
NOTE
Project Server creates a separate database for each instance of Project Web App
Project Server database
Default database name when it is installed with the ProjectWebApp

Purpose Each Project Web App database contains the following data:
All Project and Portfolio Management (PPM) data
Time tracking and Timesheet data
Aggregated SharePoint project site data
Supports SQL Server 2008 R2 and SQL Server 2012 Yes


Supports SQL Server 2008 R2 and SQL Server 2012 Yes

disaster recovery

SharePoint Search service databases

The SharePoint Search service application uses the following databases:
Analytics Reporting
Crawl
Link
The following tables provide the supported high availability and disaster recovery options for the Search
databases.
Search Administration database
Default database name when it is installed with the Search_Service_Application_DB_<GUID>

Purpose Stores the Search application configuration and system access

control list (SACL) for the crawl component.
availability

Supports SQL Server 2014 (SP1), SQL Server 2016, and SQL No. Taking a copy of the Search Administration database and
Server 2017 RTM asynchronous mirroring or log-shipping to using it to re-create the Search service application is
another farm for disaster recovery supported.
disaster recovery
Supports SQL Server AlwaysOn Availability Group with No. Taking a copy of the Search Administration database and
asynchronous-commit for disaster recovery using it to re-create the Search service application is
supported.
Analytics Reporting database
Default database name when it is installed with the Search_Service_Application_AnalyticsReportingStoreDB_<GUI

SharePoint Products Configuration Wizard D>
Purpose Stores the results for usage analysis reports and extracts
information from the Link database when it is needed.
availability

disaster recovery
Supports SQL Server AlwaysOn Availability Group with No

Crawl database
Default database name when it is installed with the Search_Service_Application_CrawlStoreDB_<GUID>

Purpose Stores the state of the crawled data and the crawl history.
availability

Supports SQL Server 2014 (SP1), SQL Server 2016, and SQL No
disaster recovery

Link database
Default database name when it is installed with the Search_Service_Application_LinkStoreDB_<GUID>

Purpose Stores the information that is extracted by the content

processing component and click through information.
availability

disaster recovery

Secure Store database

The following table provides the supported high availability and disaster recovery options for the Secure Store
database.
Secure Store database
Default database name when it is installed with the Secure_Store_Service_DB_<GUID>

Purpose Stores and maps credentials, such as account names and

passwords.
availability

disaster recovery

SharePoint Translation Services database

The following table describes the supported high availability and disaster recovery options for the Translation
Services database.
Translation Services database
Default database name when it is installed with the 2016/2019: TranslationService_<GUID>

SharePoint Products Configuration Wizard 2013: SharePoint Translation Services_<GUID>
Purpose Stores information about pending and completed batch

document translations with enabled file name extensions.
availability

disaster recovery

State Service database

The following table describes the supported high availability and disaster recovery options for the State Service
database.
State Service database
Default database name when it is installed with the 2016/2019: StateService_<GUID>

SharePoint Products Configuration Wizard 2013: SessionStateService_<GUID>
Purpose Stores temporary state information for InfoPath Forms

Services, Exchange Server, the chart Web Part, and Visio
Services.
availability

disaster recovery

Subscription Settings service application

The following table provides the supported high availability and disaster recovery options for the Subscription
Settings service application database.
Subscription Settings database
Default database name when it is installed with the 2019: Subscription

SharePoint Products Configuration Wizard 2013/2016: SettingsServiceDB
Purpose Stores features and settings for hosted customers.
availability

disaster recovery

Usage and Health Data Collection database

The following table provides the supported high availability and disaster recovery options for the Usage and
Health Data Collection database.
Usage and Health Data Collection database
Default database name when it is installed with the 2016/2019: WSS_Logging

SharePoint Products Configuration Wizard 2013: SharePoint_Logging
Purpose Stores health monitoring and usage data temporarily, and can
be used for reporting and diagnostics.
Supports SQL Server 2014 (SP1), SQL Server 2016, and SQL Yes, but not recommended
availability
Supports SQL Server AlwaysOn Availability Group with Yes, but not recommended
Note: It is not possible to run PSConfig, (SharePoint Products
Configuration Wizard or Microsoft PowerShell) to apply
SharePoint CUs when this database is a member of an Always
On Availability Group.
Supports SQL Server 2014 (SP1), SQL Server 2016, and SQL Yes, but not recommended
disaster recovery
Supports SQL Server AlwaysOn Availability Group with No. This database is farm specific. However, you can copy it to
asynchronous-commit for disaster recovery a disaster recovery environment for data mining.
User Profile Service databases

The User Profile Service application uses the following databases:
Profile: The Profile database stores and manages users and associated information. It also stores
information about a user's social network in addition to memberships in distribution lists and sites.
Synchronization: The Synchronization database stores configuration and staging data for use when profile
data is being synchronized with directory services such as Active Directory.
Social Tagging: The Social Tagging database stores social tags and notes

Share Point

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Share Point

Hochgeladen von

Copyright:

Verfügbare Formate

Contents

End user content

Learn about SharePoint

Before you start

Manage your environment

Upgrade and update

APPLIES TO: 2013 2016 2019 SharePoint Online

SharePoint Server 2016 conformance statement

Accessibility features in SharePoint Server

APPLIES TO: 2013 2016 2019 SharePoint Online

APPLIES TO: 2013 2016 2019 SharePoint Online

Detailed description of new features

Detailed description of new Microsoft PowerShell SharePoint Server

Detailed description of new SharePoint Health Analyzer rules

Detailed description of improved features

APPLIES TO: 2013 2016 2019 SharePoint Online

Features deprecated in SharePoint Server 2019

Removed features in SharePoint Server 2019

SharePoint Business Intelligence Scenarios

APPLIES TO: 2013 2016 2019 SharePoint Online

FEATURE DESCRIPTION MORE INFORMATION

Customized web parts The compile time for customized XSLT NA

Durable links Resource-based URLs now retain links NA

Detailed description of features

Fast Site Collection Creation

Hybrid in SharePoint Server 2016

SERVER ROLE DESCRIPTION

Front-end Service applications, services, and components that serve user

Application Service applications, services, and components that serve

Distributed Cache Service applications, services, and components that are

Search Service applications, services, and components that are

Custom Custom service applications, services, and components that

Single-Server Farm Service applications, services, and components required for a

Set-SPCentralAdministration -Port <number> -SecureSocketsLayer

Psconfig.exe -cmd adminvs -port <number> -ssl

3. The SMTP server must have a server certificate installed.

$WebApp = Get-SPWebApplication -IncludeCentralAdministration | ? { $_.IsAdministrationWebApplication -eq $true

Site folders view

$WebApp = Get-SPWebApplication -IncludeCentralAdministration | ? { $_.IsAdministrationWebApplication -eq $true

APPLIES TO: 2013 2016 2019 SharePoint Online

FEATURE DESCRIPTION MORE INFORMATION

APPLIES TO: 2013 2016 2019 SharePoint Online

SharePoint Server 2016 (Feature Pack 2)

APPLIES TO: 2013 2016 2019 SharePoint Online

Features deprecated in SharePoint Server 2016

Tags and Notes

Export-SPTagsAndNotesData -Site <http://site.contoso.com> -FilePath <tagsandnotes.zip>

Work Management Service Application

APPLIES TO: 2013 2016 2019 SharePoint Online

ARE YOU DEPLOYING... READ

SharePoint Server 2019 2019 Hardware and software requirements

SharePoint Server 2016 2016 Hardware and software requirements

SharePoint Server 2013 2013 Hardware and software requirements

How large is your company?

I have SharePoint Server installed

WHAT DO YOU NEED TO DO? READ

I have SharePoint Server and want to move to the cloud

ARE YOU WANTING TO... READ

APPLIES TO: 2013 2016 2019 SharePoint Online

Enable TLS and SSL support in Describes how to enable Transport

Plan security hardening for SharePoint Learn about security hardening

Federal Information Processing Learn about SharePoint Server 2016

APPLIES TO: 2013 2016 2019 SharePoint Online

About administrative and service accounts