Category: Best Practices

The number of items in this list exceeds the list view threshold error when you view a SharePoint Online list in Office 365

This article describes SharePoint Online view threshold limits that apply to SharePoint Online.

Having already encountered the notorious 5000 items threshold limit in SharePoint. I would like to further detail the following:-

  • What exactly is the list view threshold (LVT),
  • How to prevent the LVT, and
  • How to resolve when the limits have been crossed.

The following article provides tips and recommendations for addressing this issue in case you have or plan to have a really large document library.

What is a SharePoint List?

A SharePoint List is a container with rows and columns in which data can be stored in SharePoint, similar to an Excel spreadsheet. These pieces of content are called “list items”.

What are Boundaries, Limits and thresholds in SharePoint Lists?

Let’s define what we mean by the boundaries and limits, so as to, establish the terms that will be used to ensure we’re on the same page.

Boundaries are absolute limits that cannot be breached. This is a design choice by Microsoft.

Limits are suggested guidelines that have been settled on, and are affected by system performance and testing by the product team. These can go beyond the suggested Microsoft limits but there could be performance issues at a later stage.

Thresholds are restrictions within which the default value can’t be exceeded, unless that design, or structure is modified.

Important SharePoint List Thresholds & Boundaries

There are many more important restrictions, related to SharePoint. However, let us just focus on the LVT, to keep in mind which are:

Boundaries:

File Size: Less than 10 GB per file. Files attached to list items can be up to 250 MB in size.

Document Count: A flat count of 30,000,000 items per library (if applying metadata, folders and views etc).

Item Count: This is also limited to 30,000,000 items per list.

Thresholds:

List View Threshold: 5,000 items per view.

Admin View Threshold: 20,000 items per view.

Sync – For optimum performance, we recommend storing no more than 100,000 files in a single OneDrive or team site library. If you use the previous OneDrive for Business sync client (Groove.exe), the sync limit per library is 5,000 items.

For the most part, these limits will be applicable to both SharePoint Online on Office 365 & SharePoint On-Premises, but with one key difference; the list thresholds in place cannot be changed for SharePoint Online. Also, the restrictions in place are in effect for everyone within the tenant, and any change could impact all customers within that shared environment.

 

The 5000 Items List View Threshold

To minimize database contention SQL Server, the back-end database for SharePoint, often uses row-level locking as a strategy to ensure accurate updates without adversely impacting other users who are accessing other rows. However, if a read or write database operation, such as a query, causes more than 5,000 rows to be locked at once, then it’s more efficient for SQL Server to temporarily lock the entire table until the database operation is completed.

Note: The actual number is not always 5,000, and can vary depending on your site, the amount of activity in the database, and your site’s configuration.

When the whole table is locked, it prevents other users from accessing the table. If this happens too often, then users will experience a degradation of system performance. Therefore, thresholds and limits are essential to help minimize the impact of resource-intensive database operations and balance the needs of all users.

The following diagram summarizes the key points about what happens behind the scenes when you access many items in a list or library.

  1. List or library data in a site collection is stored in a SQL Server database table, which uses queries, indexes and locks to maintain overall performance, sharing, and accuracy.
  2. Filtered views with column indexes (and other operations) create database queries that identify a subset of columns and rows and return this subset to your computer.
  3. Thresholds and limits help throttle operations and balance resources for many simultaneous users.
  4. Developers can use object model code to query lists, even if thresholds have been reached.
  5. Information workers can use appropriate views, styles, and page limits to speed up the display of data on the page.

How to manage large lists and libraries

There are many ways you can work with or query a SharePoint list or library without receiving a List View Threshold warning. You can store up to 30 million items or documents in a SharePoint list or library. Using the following ideas, you can get the information you need and stay within the 5000 item List View Threshold. Here are just a few:-

  • Indexed Columns & Filtered Views
  • Using folders to organize
  • SharePoint search box
  • Document Center solutions
  • Using Documents sets
  • Editing the default view

Indexed Columns & Filtered Views

To prevent running into the threshold limit is to have SharePoint automatically create the index for you. You can do this by enabling Metadata Navigation and Filtering as a site feature, and applying it to the lists and libraries you think will eventually reach the view threshold.

In the list/library list settings, an option exists to create a maximum of 20 indexed columns.

When you index a column, you’re asking SharePoint to make that column more accessible and serviceable in a query than other columns.

You should be aware that this prioritization comes at a cost, which is an increased overhead on the database level. Therefore, you only want to index columns that are going to be searched and filtered on often.

Filtered views, which can be used to cut out irrelevant items within a list. To make a filtered view more effective, it’s necessary for the first column within the list to be indexed to keep the returned results below the view threshold.

 

Using folders to organize

When you create a folder, behind the scenes you are creating an internal index. This internal index is also created for the root folder, or top-level of a list or library. When you access items in a folder, you are effectively using this internal index to access the data.

Important: If a folder contains subfolders, each subfolder and any subfolders, and their files and folders, are also counted as an item and contribute to the LVT.

It is important to consider the following when you use folders to organize a large list or library:

  • A folder can contain more items than the List View Threshold, but to avoid being blocked, you may still need to use a filtered view based on column indexes.
  • A newly created folder also creates a new internal index within the underlying database. This means that whenever a folder is accessed, its index is used to retrieve the relevant data.
  • If you choose the Show all items without folders option in the Folders section when you create or modify a view in this list or library, you must then use a filter that is based on a simple index to ensure you don’t reach the List View Threshold.

Note: If you move items into the SharePoint Recycle Bin, those items will still be counted when determining whether the filter expression exceeds the List View Threshold. If you clear the recycle bin they are no longer counted.

SharePoint search box

There are usually two search boxes on a SharePoint page, the site search at the top of the page, and the specific list or library search box. When you use the list or library’s Search box, you can progressively expand the scope of the search operation:

  • By default, the search scope is initially based on all the items in the current view and any subfolders. You see the results as columns that you can further filter and sort. If the List View Threshold is currently exceeded, not all results are displayed.

  • If you don’t find what you are looking for, you can expand your search scope to include the entire list including all subfolders, regardless of the current view or List View Threshold.

  • Finally, you can expand the scope to search the entire site. In this case, you see all the results in the standard Search site page. You can further narrow the results by using the Refinement panel to filter, for example, by the author of a document or the creation date of a list item. You can even use Boolean syntax and logical operators to formulate more elaborate queries.

 

Document Center solutions

You can use a Document Center site when you want to create, manage, and store large numbers of documents. A Document Center is based on a site template and is designed to serve as a centralized repository for managing many documents. Features, such as metadata and tree view navigation, content types, and web parts, help you organize and retrieve documents in an efficient and meaningful way for your users.

What functions are lost when you cross the List View Threshold?

Once you cross the view threshold limit you may and eventually will experience “database locking”. Users and administrators of this document library will start to lose from trivial operations like adding columns, making certain adjustments to views, setting permissions, sharing and even managing column indexes.

Eventually, further loss of functional you will experience will be unable to delete content from the libraries, delete large lists/libraries and eventually complete loss of access.

Microsoft Flows or PowerApps may run into the 5000 item limit, depending on what you are doing and even making REST calls.

That means that you won’t be able to index columns until you are you will need to bring down the number of files in your repository to go lower than the threshold limit

How to fix a document library when you have already crossed the LVT?

If you already have a library and ran into the threshold issue. It is still possible to fix, but this has now become a much more difficult to resolve. Effectively, a phase two – a transition.

First, you will need to bring down the number of items in your SharePoint list / library you to lower than the threshold limit.  This can be accomplished by splitting the data into multiple document libraries.

Once this has been accomplished you can, start applying the methods outlined above.

SharePoint 2013 Service Accounts Best Practices

Applies to: SharePoint Server 2013, SharePoint Foundation 2013

The document describes how important Service Accounts were in the installation of SharePoint 2013, if they are not set up correctly they can open big security holes in your organization and give you serious problems further down the road.

The document also suggested that you cannot have only one set of Service accounts for every scenario, since not all scenarios require the same security (ex: a development environment does not require same security a UAT and likewise the production one). So, I suggested three sets of service accounts for different deployment scenarios of SharePoint 2013.

This document explains all the three sets of service accounts, explaining the difference between the sets and also what every account does!

[info-box type=”note”]NOTE: These sets only cover the basic installation and configuration of SharePoint 2013 and SQL. Other Service accounts will be needed for some Service Applications (Ex: Excel, Visio, Performance Point, etc)[/info-box]

Low Security Option

Summary

The Low security option is of course the one with the least accounts possible to install SharePoint in a proper manner. It uses only 1 SQL account that will be the SQL administrator and also run the services, and 5 SharePoint accounts: The Farm Administrator, the Web Application pool account, the SharePoint Service Application Pool account the Crawl account and the User Profile Synchronization account. More details under each section

For the SQL Server

NameDescriptionLocal RightsDomain Rights
SQL_Adminwrite vThe SQL Server service account is used to run SQL Server. It is the service account for the following SQL Server services: MSSQLSERVER SQLSERVERAGENT. SQL Admin on the SQL ServeralueLocal Administrator on the SQL ServerDomain User

Explanation
As Stated previously, in the Low Security Option, we only use one Service Account for our SQL Server. This account needs to be a Local Administrator on the SQL server in order to be able to install SQL. We will also run the SQL AGENT and the Database Engine services with this account. This the account that will have the full power on your SQL server and you will use it to grant rights to your SP_Farm.

For the SharePoint Server

NameDescriptionLocal RightsDomain Rights
SP_FarmThe server farm account is used to perform the following tasks: -Setup -SharePoint Products Configuration Wizard -Configure and manage the server farm. -Act as the application pool identity for the SharePoint Central Administration Web site. -Run the Microsoft SharePoint Foundation Workflow Timer Service. Local Administrator on all the SharePoint Servers. SecurityAdmin and DB_Creator rights on the SQL InstanceDomain User
SP_PoolThe Pool account is used to run the Web Application PoolsNoneDomain User
SP_ServicesThe Services Account is used to run the Service Application PoolNoneDomain User
SP_CrawlThe Default Content Access Account for the Search Service ApplicationNoneDomain User
SP_UserProfilesThe User Profile Synchronization AccountNoneReplicate Directory Changes permission on the domain

Explanation
The Low Security Option uses the minimum amount of accounts while also keeping a level of security. Here is the account breakdown:

SP_Farm is your main SharePoint account in this configuration. It needs to have Local Administrator rights to be able to install SharePoint Server and also the Securityadmin and DBcreator roles on the SQL Server to create the configuration and other databases. This account will be your main Farm Administrator and also run the Timer Service and the web application for Central Administration use to access the SharePoint content database

SP_Pool is a domain account used for application pool identity.. ex: When you create a Web Application, and you create a pool for it, you select this account!

SP_Services is a domain account used for the Service Applications Pools. ex: When you create a Managed Metadata Service application and create a pool for it, you select this account!

SP_Crawl is used within the Search Service Application to crawl content. The Search Service Application will automatically grant this account read access on all Web Applications. It will also run the SharePoint Windows Search Service.

SP_UserProfiles is the account used for the User Profile Synchronization between your Service Application and your Active Directory. This account does not need any local rights, however you need to give it Replicate Directory Changes rights on the Active Directory in order to allow the synchronization

Medium Security Option (Sweet Spot)

Summary
The Medium Security option is the Sweet Spot of a SharePoint installation. It uses slightly more accounts than the Low Security Option however it provides a huge security improvement. By giving less rights to each account you limit the possible damage in case an account gets hacked and also follow Microsoft’s recommendation of installing SharePoint 2013 with least-privilege administration. More details on the changes under every section!

For the SQL Server

NameDescriptionLocal RightsDomain Rights
SQL_AdminSQL Admin on the SQL Server. Used to Install the SQL Server.Local Administrator on the SQL ServerDomain User
SQL_ServicesIt is the service account for the following SQL Server services: MSSQLSERVER SQLSERVERAGENT.NoneDomain User

Explanation

The difference between the Low Security and the Medium Security option for the SQL is that we now use two different accounts :The SQL_Admin and the SQL_Services. The big security improvement is that the account running the Agent and Database Engine services is not a local administrator anymore. Here is the account breakdown:

SQL_Admin: This will be your main SQL Administrator!. It needs Local Administrator rights in order to install the SQL server.

SQL_Services: This account does not have any local rights, it is only used to run the SQL Agent and Database Engine windows services.

For the SharePoint Server

NameDescriptionLocal RightsDomain Rights
SP_FarmThe server farm account is used to perform the following tasks: -Configure and manage the server farm. -Act as the application pool identity for the SharePoint Central Administration Web site. -Run the Microsoft SharePoint Foundation Workflow Timer Service.SecurityAdmin and DB_Creator rights on the SQL InstanceDomain User
SP_AdminThe server farm account is used to perform the following tasks: -Setup -SharePoint Products Configuration WizardLocal Administrator on all the SharePoint Servers. SecurityAdmin and DB_Creator rights on the SQL InstanceDomain User
SP_PoolThe Pool account is used to run the Web Application PoolsNoneDomain User
SP_ServicesThe Services Account is used to run the Service Application PoolNoneDomain User
SP_CrawlThe Default Content Access Account for the Search Service ApplicationNoneDomain User
SP_SearchService Account to run the SharePoint Search “Windows Service”NoneDomain User
SP_UserProfilesThe User Profile Synchronization AccountNoneDomain User

Explanation

In the Medium Security option we increase the security by adding two new accounts: The SP_Admin and the SP_Search. Instead of giving all the Farm Administration power to the SP_Farm account, the SP_Admin will be the one that installs and configures SharePoint 2013 and have the local administrator rights, while the SP_Farm will only run the services and connect to the database. Furthermore, instead of letting the SP_Crawl account run both the Windows Service and have FULL-READ rights on all the web applications, the SP_Search will now run the Windows Service. Here is the breakdown of the accounts:

SP_Farm is a domain account that the SharePoint Timer service and the web application for Central Administration use to access the SharePoint content database. This account does not need to be a local administrator. The SharePoint configuration wizard grants the proper minimal privilege in the back-end SQL Server database.The minimum SQL Server privilege configuration is membership in the roles securityadmin and dbcreator.

SP_admin is a domain account you use to install and configure the farm. It is the account used to run the SharePoint Configuration Wizard for SharePoint 2013.The SPAdmin account is the only account that requires local Administrator rights. To configure the SPAdmin account in a minimum privilege scenario, it should be a member of the roles securityadmin and dbcreator on the SQL server.

SP_Pool is a domain account used for application pool identity.. ex: When you create a Web Application, and you create a pool for it, you select this account!

SP_Services is a domain account used for the Service Applications Pools. ex: When you create a Managed Metadata Service application and create a pool for it, you select this account!

SP_Crawl is used within the Search Service Application to crawl content. The Search Service Application will automatically grant this account read access on all Web Applications.

SP_Search Is used to run the SharePoint Windows Search Service.

SP_UserProfiles is the account used for the User Profile Synchronization between your Service Application and your Active Directory. This account does not need any local rights, however you need to give it Replicate Directory Changes rights on the Active Directory in order to allow the synchronization.

High Security Option

Summary

The High Security Option is the ones that provides the best security and of course the most Service Accounts. This only ads a small amount of extra security to the farm, however that extra security might be needed in some scenarios

For the SQL Server

NameDescriptionLocal RightsDomain Rights
SQL_AdminSQL Admin on the SQL Server. Used to Install the SQL Server.Local Administrator on the SQL ServerDomain User
SQL_AGENTIt is the service account for the following SQL Server services: SQL SERVER AGENTNoneDomain User
SQL_ENGINEIt is the service account for the following SQL Server services: Database Engine.NoneDomain User

Explanation

The difference between the Medium Security and High Security Option is that we now have a separate account for each of the two base services: SQL_Agent and Database Engine. Nothing changes for the SQL_Admin

SQL_Admin: This will be your main SQL Administrator!. It needs Local Administrator rights in order to install the SQL server.

SQL_Agent: This account does not have any local rights, it is only used to run the SQL Agent Windows Service

SQL_Engine: This account does not have any local rights, it is only used to run the Database Engine windows service.

For the SharePoint Server

NameDescriptionLocal RightsDomain Rights
SP_FarmThe server farm account is used to perform the following tasks: -Configure and manage the server farm. -Act as the application pool identity for the SharePoint Central Administration Web site. -Run the Microsoft SharePoint Foundation Workflow Timer Service. SecurityAdmin and DB_Creator rights on the SQL InstanceDomain User
SP_AdminThe server farm account is used to perform the following tasks: -Setup -SharePoint Products Configuration WizardLocal Administrator on all the SharePoint Servers. SecurityAdmin and DB_Creator rights on the SQL InstanceDomain User
SP_PoolThe Pool account is used to run the Web Application PoolsNoneDomain User
SP_ServicesThe Services Account is used to run the Service Application PoolNoneDomain User
SP_CrawlThe Default Content Access Account for the Search Service ApplicationNoneDomain User
SP_SearchService Account to run the SharePoint Search “Windows Service”NoneDomain User
Sp_MySitePoolUsed for the My Sites Web ApplicationNoneDomain User
SP_UserProfilesThe User Profile Synchronization AccountNoneReplicate Directory Changes permission on the domain.

Explanation

The only difference between the Medium security and the High Security option is that we now have a separate account for the Web Application Pool hosting the ‘My Sites’ since it has a different security policy than the other Web Applications . I will only give the details for the new account in the breakdown:

SP_MySitePool is a domain account used for the My Sites Web Application Pool Identity. It’s very similar to the SP_Pool, however it is only used for the My Sites Web Application.

Hardware and Software Requirements for SharePoint 2013

Applies to: SharePoint Server 2013, SharePoint Foundation 2013

Summary: Lists the minimum hardware and software requirements to install and run SharePoint 2013 with Service Pack 1.

In this article:

 

Important

The information in this article applies to SharePoint Foundation 2013 and SharePoint Server 2013. For information about the features that each version supports, see the SharePoint 2013 Product Page.
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.

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

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 <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.)
  • 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. For more information, see Create a high availability architecture and strategy for SharePoint 2013.

 

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 Service Pack 1 in a single / multiple server farm installation under a Windows Server 2012 environment.

Please note: 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 five times as much free space as you have RAM for development, UAT & production environments.

Installation Scenario Deployment type and scale RAM Processor Hard disk space
Web server in a three-tier farmPilot, user acceptance test deployment of SharePoint Server 2013 or SharePoint Foundation 2013.16 GB64-bit, 4 cores250 GB for system drive
Application server in a three-tier farmProduction, user acceptance test, or production deployment of SharePoint Server 2013 or SharePoint Foundation 2013.32 GB64-bit, 4 cores250 GB for system drive

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 apply to SQL Server 2014.

Component Minimum requirement
Processor64-bit, 8 cores for small deployments (fewer than 1,000 users)
RAM• 64 GB for small deployments (fewer than 1,000 users) 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..
Hard disk500 GB for system drive

Software requirements

The requirements in the following section apply to the following installations:

  • Single server with built-in database
  • Server farm with a single server in the farm
  • Server farm with multiple servers in the farm
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.

The Microsoft SharePoint Products Preparation Tool can assist you in the installation of the software 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 on a single server with SQL Server 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:
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.

Minimum software requirements

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:
    • 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)
  • Microsoft .NET Framework version 4.5

Minimum requirements for a single server with built-in database:

  • 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)
  • 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:
    • Web Server (IIS) role
    • Application Server role
    • Microsoft .NET Framework version 4.5
    • SQL Server 2008 R2 SP1 Native Client
    • Microsoft WCF Data Services 5.0
    • Microsoft Information Protection and Control Client (MSIPC)
    • Microsoft Sync Framework Runtime v1.0 SP1 (x64)
    • Windows Management Framework 3.0 which includes Windows PowerShell 3.0
    • Windows Identity Foundation (WIF) 1.0 and Microsoft Identity Extensions (previously named WIF 1.1)
    • Windows Server AppFabric
    • Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server (KB 2671763)

Minimum requirements for front-end web servers and application servers in a farm:

  • 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)
  • The Microsoft SharePoint Products Preparation Tool installs the following prerequisites for front-end web servers and application servers in a farm:
    • Web Server (IIS) role
    • Application Server role
    • Microsoft .NET Framework version 4.5
    • SQL Server 2008 R2 SP1 Native Client
    • Microsoft WCF Data Services 5.0
    • Microsoft Information Protection and Control Client (MSIPC)
    • Microsoft Sync Framework Runtime v1.0 SP1 (x64)
    • Windows Management Framework 3.0 which includes Windows PowerShell 3.0
    • Windows Identity Foundation (WIF) 1.0 and Microsoft Identity Extensions (previously named WIF 1.1)
    • Windows Server AppFabric
    • Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server (KB 2671763)

Minimum requirements for client computers

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.

Environment Optional software
Single server with built-in database, front-end web servers, and application servers in a farm• .NET Framework Data Provider for SQL Server (part of 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 This add-in is used by Access Services for SharePoint 2013. • 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 Service Pack 1 (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 • 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 2013 • 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.

Links to applicable software

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 prerequisites and then install them from a network share. For more information, see Install prerequisites for SharePoint 2013 from a network share.

Prerequisite installer operations and command-line options

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)
  6. Microsoft Sync Framework Runtime v1.0 SP1 (x64)
  7. Windows Identity Extensions
  8. Microsoft Information Protection and Control Client
  9. Microsoft WCF Data Services 5.0
  10. Windows Server AppFabric
  11. Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server (KB 2671763)

You can run prerequisiteinstaller.exe at a command prompt with the following options. When you run 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 prerequisiteinstaller.exe with the /continue option.

  • /? 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>

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.

 

Backup and restore best practices in SharePoint 2013

by Michael Pomfret on 14th June 2016

 

Applies to: SharePoint Server 2013 Standard, SharePoint Server 2013 Enterprise, SharePoint Foundation 2013

 

Summary: Learn how to implement best practices before you back up and restore a SharePoint 2013 farm.

 

Best practices for backup and restore help make sure that backup and restore operations in SharePoint 2013 are successful and that the environment is protected against data loss or continuity gaps.

 

In this article:

 

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 best practices to 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 Server 2008 R2 with Service Pack 1 (SP1) and SQL Server 2012. For more information, seeDefine 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, seeDatabase types and descriptions (SharePoint 2013).

 

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 the following resources:

 

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 2013 supports SQL Server backup compression. SQL Server data compression is not supported for SharePoint Server 2013 databases.

 

For more information about how backup compression affects performance in SQL Server, see the following resources:

 

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 Windows PowerShell. You can configure backup and restore threads in both the SharePoint Central Administration website and Windows PowerShell to increase backup or restore efficiency and performance.

If you use the Export-SPWeb Windows PowerShell cmdlet, you can use the NoFileCompression parameter. By default, SharePoint 2013 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 2013 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 2013 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.

  • Less than 15 gigabytes (GB): Use the Backup-SPSite Windows PowerShell cmdlet. For more information, see Back up site collections in SharePoint 2013.
  • 15-100 GB: Use a SharePoint 2013 tool, a SQL Server tool, or other database backup tool to protect the content database that contains the site collection. For more information, seeBack up site collections in SharePoint 2013.
  • Larger than 100 GB: Use a differential backup solution, such as SQL Server 2008 R2 with SP1 or System Center 2012 – Data Protection Manager (DPM), 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 2013 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 filesCommon FilesMicrosoft SharedWeb Server Extensions15Logs. 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 2013

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 2013, 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 2013. 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 2013. 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 Windows 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:

 

Use the SQL FILESTREAM provider with BLOB storage

Remote BLOB Storage (RBS) is supported in a SharePoint 2013 farm. There are both pros and cons associated with using RBS in SharePoint 2013. One related limitation of RBS with a SharePoint farm is that System Center 2012 – Data Protection Manager (DPM) cannot use the FILESTREAM provider to back up or restore RBS. SharePoint 2013 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 2013.