SharePoint Best Practices

We never share your data. Privacy Policy

Overview

Microsoft SharePoint is the premier information management and sharing platform. It provides organizations with the information management, collaboration, workflow and data integration capabilities they need to drive their business forward. However, in order to be effective, the SharePoint solution has to be properly configured and secured. Here are the SharePoint best practices that will help you to achieve these goals and get the most from your investment.

SharePoint Configuration Best Practices

Design your farm architecture well

Here are the primary factors to consider when deciding on a farm architecture:

  • Budget available, along with previous hardware and other investments that can be reassigned to the new initiative
  • High availability (HA) and disaster recovery (DR) requirements (RTO/RPO)
  • Anticipated content size
  • Anticipated total number of users
  • Anticipated number of concurrent users
  • Services required

SharePoint Server can represent a significant monetary cost. Hardware requirements are on the upper end of many document management systems. Each SharePoint Server must be licensed, along with each SharePoint user. Plus, since SharePoint Server does not support SQL Express, you’ll need to pay for a licensed edition of SQL Server.

Maintaining a highly available SharePoint farm also involves ongoing operational costs. The more servers and services there are to manage, the more expensive the farm becomes over time.

What services are provisioned on the farm will also impact costs and performance. If your farm has over 500 million items to crawl, you’ll need to provision a new Search Service application. If you have multiple Search Service applications, you might need to provision additional SharePoint servers to handle the load. 

Use network load balancers with your SharePoint site if it is heavy loaded

Network load balancers are essential to high availability of SharePoint for your end users. One feature to pay attention to is SSL Offloading. Although many load balancers offer it, you should avoid using it whenever possible because it removes the encryption on the load balancer and sends the resulting request in clear text to the target services, such as SharePoint. Moreover, SSL Offloading no longer provides an advantage in performance in terms of CPU utilization on a server with a modern AMD or Intel processor.

Define a proper topology for your SharePoint farm

Here are the most common SharePoint topology strategies:

  • Single-server farm. A single server farm consists of a single SharePoint Server with SQL Server installed either on that server or its own server. This farm architecture has a specific installation role named “Single Server Farm.” If you choose this role, it is not possible to add additional SharePoint servers to the farm; however, it is possible to change the role post-installation to accommodate a farm expansion.
  • Three-tier farm. The three-tier farm is one of the most common farm types. These farms consist of a single web front end, a single application server and a single SQL Server. The web front end is simply the SharePoint Server that is handling end-user traffic, while the application server is a SharePoint Server that handles most SharePoint services, such as Business Data Connectivity Services and the Managed Metadata Service.
  • Traditional highly available farms. Other topologies provide basic high availability because they can suffer the loss of one or more SharePoint servers and SQL servers while still serving users. An example of this would be two web front ends, two application servers and two SQL servers using a form of high availability, such as SQL clustering, database mirroring, or AlwaysOn availability groups with failover clustering.
  • MinRole farms. Introduced in SharePoint Server 2016, MinRole is a farm topology based on a set of predefined server roles. For example, if a SharePoint Server is deployed with the “Distributed Cache” MinRole, SharePoint will automatically provision the Distributed Cache service. If other services are started that do not comply with the MinRole selected for a given SharePoint Server, that server will be considered out of compliance and marked as such in Central Administration. The following MinRole options are available:
    • Distributed Cache — Runs Distributed Cache, but does not handle end-user traffic directly
    • Front-end— Not only handles end-user traffic, but also runs many services that require low latency for end users, such as the Managed Metadata Service or User Profile Service
    • Application — Tuns non-latency-sensitive services, such as workflows or the PowerPoint Conversion Service
    • Search — Runs the specific Search roles, such as Admin or Content Processing.
  • Zero downtime MinRole farms. Zero downtime requires a minimum of eight SharePoint servers within the farm when using dedicated MinRole:
    • Two servers with the Distributed Cache MinRole
    • Two servers running the Front-end MinRole (they are behind a load balancer that can detect server failure and route end-user traffic to the available server)
    • Two Application MinRole servers
    • Two Search MinRole servers

With this configuration, you can maintain availability even if any one particular role suffers a single SharePoint Server failure or there are multiple server failures across roles. If you use shared MinRole, you need only four servers.

  • Zero downtime traditional farms. Zero downtime can also be used with more traditional farm configurations, such as the three-tier highly available configuration. Each server would use the Custom role with all services remaining highly available within the farm. There are two topologies:
    • Traditional service application topology.This topology has been used for many years, and is often deployed today with SharePoint Server 2013. In this model, the Microsoft SharePoint Foundation Web Service (and, optionally, Distributed Cache) is installed on the web front end server; the application server runs all other services. This places a higher load on the application server in comparison to other topologies, while potentially reducing the load on the web front end. Increased network traffic may result from this topology; for example, a call to a Managed Metadata field would travel from the web front end to the application server, then back through the web front end before reaching the user’s browser.
    • Streamlined service application topology. The streamlined topology was born out of Microsoft’s experience with SharePoint Online and is the preferred topology. Services are tiered based on latency for end users: Services that required lower latency (faster access for end-user requests) are placed on the web front ends, while services that were not end-user interactive, such as the workflow service, are placed on back-end application servers (also called “batch” servers).

Configure the SharePoint Server BIOS properly to improve performance

Making a few changes to your server before you install SQL Server and SharePoint can improve its performance:

  • Check the BIOS/UEFI options for the hardware running SharePoint.
  • Disable Intel C-States (SpeedStep)/AMD Cool’n’Quiet to prevent the CPU from scaling back when not under load.
  • Disable C1E support, which is available on both Intel and AMD CPUs. Because SharePoint can spike in CPU load, enabling this option can cause a seesaw effect.
  • Look for OEM-specific options that could help improve performance. For HP, set the Power Regulator Mode to Static High Performance; for Dell, set the Power Management Mode to Maximum Performance.
  • Disable QPI power management to prevent throttling of lanes between multiple CPUs and physical memory.

Understand SharePoint web architecture

A SharePoint environment has three different site levels: web applications, site collections and webs (sites and subsites). The first two are actually simply containers that do not store any content directly; all content is stored in the webs. 

Web applications can be created only by SharePoint administrators who have Farm Administrator privileges as well as Local Administrator permissions on the SharePoint Server. Creating a web application will create a new site in IIS on every server running the Microsoft SharePoint Foundation Web Application service, as well as a new database in SQL. While two SharePoint web applications can be hosted in the same IIS application pool, they cannot have the same URL or be hosted in the same database. A web application can have one or more content databases attached to it. All the site collections created in that web application will go to one of those content databases. 

Every web application needs to have a root site collection, which is the site collection with the same URL as the web application. This is not created automatically, but is a requirement for supportability and stability of your SharePoint system. A site collection can be placed into its own content database, and can be moved between content databases that are attached in the same web application. 

Under the site collection, we find webs. Those webs can either be at the root of the site collection, meaning they have the same URL as the site collection, or they can be a subsite of the root web. Those webs cannot be moved to a different content database individually; they all reside in the same site collection container.

Use object cache account to improve rendering speeds

SharePoint publishing sites use two Object Cache Accounts to improve page rendering speeds on publishing pages, and reduce load on the SQL Server. Those accounts are often referred to Portal Super User and Portal Super Reader accounts. The Portal Super User account will have Full Control on the Web Application, while the Portal Super Reader account will only have Full Read on the Web Application. SharePoint will use those cache accounts, to create two versions of the object cache, one with the Portal Super Reader account, which will only see published items, and one with the Portal Super User account, which will see both published items and drafts. When a user queries a publishing page, the object cache will check that user’s permissions, and will return the appropriate cached object depending if he can see draft items or not. The Object Cache accounts are only needed for Web Applications that will run publishing sites, but there is no harm in setting them on all your Web Applications.

Implement high availability for SharePoint

Farms must have a 99% 1 ms round-trip time on average over 10 minutes; otherwise, you might encounter object synchronization issues, including timer job failures. Farms also must have 1 Gbps connectivity between all farm members and SQL servers that are serving the farm in a read-write capacity or are in a synchronous form of replication with the read-write SQL Server. In practice, this means that each farm member or SQL Server in synchronous replica mode must be within a radius of approximately 186 miles (300 km).

Create a disaster recovery plan for your SharePoint site

Here are the disaster recovery options for the SQL Server databases supporting your SharePoint farm: 

  • Database mirroring. Database mirroring for DR involves adding a High Performance mode node to the existing SQL Server configuration. This node can coexist with High Safety, with or without automatic failover in place. Failover in high-performance mode is a manual process; databases will not be brought online automatically.
  • Log shipping. Log shipping is the shipping of transaction log backups from one SQL Server to another. The destination SQL Server then restores the transaction log backups to the target database. This method allows you to keep the databases up to date with additional replication options available outside of SQL Server. For example, it is possible to ship a transaction log backup to a Windows file server, and using Distributed File Services (DFS-R), replicate the transaction log backup to a Windows file server in the DR datacenter, and have the DR SQL Server restore the transaction log backup to the destination database. This eliminates the SQL Server from being responsible for the replication of the transaction log backup. DFS-R also provides a faster and more reliable replication mechanism.
  • AlwaysOn availability groups. AlwaysOn availability groups provide the ability to add an asynchronous remote SQL Server to your availability group. This allows a highly available local availability group to have a single SQL Server in a DR location. Unlike with the synchronous local availability group, the remote SQL Server must be set to asynchronous mode. This mode has a manual failover process. This is the method we will be using in our DR example. Since the DR SQL Server must be failed over manually, as soon as the link between production has been severed, the databases will enter a read-write state, showing “Not Synchronized” in the SQL Server Management Studio. This means the databases are now in a read-write mode, allowing the disaster recovery farm to be brought online.

Use the SharePoint Recycle Bin

SharePoint includes a Recycle Bin that can be used to review and, if necessary, restore items previously deleted from SharePoint. Items that can be restored include documents, list items, document libraries, lists, folders and sites. Deleted items are placed in the Recycle Bin for the number of days defined by the SharePoint administrator. The SharePoint Recycle Bin has two levels of functionality:

  • Site Recycle Bin — When items are deleted from a site, they are listed in the site Recycle Bin until they are manually deleted or until the deletion date exceeds the purge period.
  • Site collection Recycle Bin — This bin stores all items deleted from any site in the site collection, including items purged from the site Recycle Bins before the purge period ends. It gives site collection administrators a higher degree of control over managing deleted items and helps ensure information is properly protected from inappropriate deletion.

Define your site’s taxonomy

Choose a set of naming rules to use on your site. Be clear and consistent; by looking at the names of subsites, menu options and other things, users should immediately understand what's in front of them. If these titles are misleading, users can get lost on the site regardless of their experience. Similarly, parallel content should share naming conventions. If the intranet gives a user the same options on separate pages, the taxonomy should be the same. If separate pages have identical sub-pages, the naming conventions should be similar.

Monitor and maintain your SharePoint regularly

SharePoint Server can be monitored with a variety of logs and tools, including the following: 

  • IIS logging. IIS logs all website activity to SharePoint. While not necessarily the primary place to examine for errors or performance issues, it can provide an indication of issues users are running into, including missing assets or server errors, such as HTTP 500 errors. Since IIS logs are plain text files, parsing them can be difficult with text editors like Notepad, but Microsoft’s Log Parser and Log Parser Studio can make finding specific types of log entries significantly easier.
  • ULS logging. ULS provides a valuable source of information about your SharePoint farm. This is the core logging mechanism of SharePoint and is often the first place a SharePoint administrator will look for any SharePoint-related errors. By default, ULS logs are located in C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\LOGS\.
  • Event Viewer. SharePoint stores a limited amount of information in the Event Viewer, but the Event Viewer is very useful for service-specific and ASP.Net errors. Generally, Windows services that run SharePoint, such as the SharePoint Timer or SharePoint Administration service, will show any startups or unexpected stops in the System Event log. SharePoint also logs data in a few application and service event logs, such as email statistics and log status, such as when the log reached its retention limit based on space used or date.
  • Usage logging. SharePoint records a variety of information to the Usage database. This database can be directly queried either through the tables or through the built-in views. For example, the Request Usage view provides information on how long a particular request took, how many CPU megacycle it consumed, the number of Distributed Cache reads, how long those Distributed Cache reads took, and so on. Usage logging can be configured in Central Administration. Gather data for only the scenarios you believe will be important for farm diagnostics; logging more than is required can lead to farm performance issues.
  • Central administration health analyzer. The built-in SharePoint Health Analyzer is a set of rules that run periodically via the SharePoint Timer Service. These rules detect various issues, such as SharePoint application pools recycling, databases with a large amount of free space, and other minor or major issues with the farm.
  • Performance Monitor. Performance Monitor can be a useful tool for diagnosing server performance issues; you can examine outstanding ASP.NET requests, CPU usage by process and so forth.

Use SharePoint document versioning

Enable document versioning to store a complete version history that allows users to track document changes and restore previous versions if required. You should limit how many major and minor versions are to be kept to control storage use. 10 major and 10 minor versions is often a good choice.

Tag Content with Metadata

Metadata is very useful for all content on your SharePoint site. When you add metadata to site content, you give it tags that indicate its content and value. When you use metadata in your SharePoint lists and libraries, your site’s information is much easier to find and interact with. SharePoint offers some default tags, called terms. You can also create new terms to better suit your purposes. 

Microsoft SharePoint Security Best Practices

Disable insecure transport security protocols

SharePoint Server 2016 introduced support for Transport Layer Security (TLS) 1.2. It is highly recommended to disable previous protocols, including Secure Socket Layer (SSL) 3.0, TLS 1.0, and TLS 1.1. TLS encrypts data as it is sent between services or between the end user and services, which helps protect sensitive data in transit over the network.

Use Kerberos or SAML for authentication

Kerberos is a modern authentication protocol that is used in every Active Directory implementation. Instead of passing password hashes to and from services, Kerberos passes tickets. Tickets are created upon user login to the client machine by Ticket Granting Service (TGS) and are retrieved from the Kerberos Distribution Center (KDC), which is an Active Directory domain controller. When a user makes a request to an external sharing service, such as SharePoint, the user’s ticket is sent to the target service for validation. In a mutual authentication scenario, the service sends information back to the client confirming the identity of the service. Each ticket has a specific lifetime, but it is generally long enough that users do not have to reauthenticate to the KDC to get a new ticket.

Security Assertion Markup Language (SAML) is a modern form of authentication that presents claims about a user to a service. Based on the identity claim contained in the SAML assertion, the service will authorize the user to the service. SAML is a favorite with modern services due to its ability to federate with disparate services that do not have a dependency on the authentication service the user authenticates with. For example, a user might authenticate against a local Active Directory Federation Services server using NTLM or Kerberos, and due to federation, assert their identity to a SharePoint farm running within a separate organization. Based on rules within the federation trust, SharePoint will authorize the user to have access to SharePoint resources. This configuration is significantly easier to manage than an Active Directory forest trust over the internet.

Patch your SharePoint servers regularly

Patching SharePoint is vital for its security and functionality, since as soon as you install the latest updates, you are secure from the latest known exploits. To upgrade a farm without taking it offline, you need to use “highly available upgrades” functionality that takes only one server in a farm offline at a time.

Track changes to your SharePoint sites

Every change to the configuration of your SharePoint farm should be documented and logged, and it is recommended to log all content changes as well. In order to configure content auditing in a SharePoint site, refer to our SharePoint auditing how-to’s and SharePoint Auditing Quick Reference Guide.

Identify and classify the data you store in SharePoint

To properly protect the data on your SharePoint, you need to identify all valuable assets stored there, such as health service numbers and credit card numbers, and classify them using data classification best practices. For this purpose, you can use third-party tools like Netwrix Data Classification. The data discovery and classification process will help you limit access permissions in accordance with principle of least privilege. It can also help you identify stale data on your SharePoint site so you can archive or delete it.

Manage site security properly

Site owners are responsible for assigning rights to users within their own sites. Rights can be assigned either directly to a user or to a group that users (or other groups) are members of. Security must be configured for every root site within SharePoint. When a new root site is created, the user who created it will specify the site collection administrators for the site, and by default, those individuals will be the only people with access to the new site. These site collection administrators will then identify the users who are to be granted rights to the site and provide them with the appropriate levels of user access. 

Subsites will either inherit their rights from the site in which they are contained or have unique permissions, as determined by the permission settings configured within the subsite. If security for a subsite is configured to be inherited from the parent site, security is not managed for the site directly; instead, security will be based on rights assigned in the parent site. If security for the subsite is configured to be unique, a site administrator will be required to assign the appropriate rights to individuals needing limited access to the site. 

When you create your own site, it is important to understand the security needs of the individuals who will be using SharePoint and assign them the appropriate permissions to work with materials in the site. To better understand SharePoint permissions and permission inheritance, please refer to this guide.

  • Configure permissions on the web application level only for site collection administrators. SharePoint allows granting of certain user permissions directly at the web application level. This is very useful for SharePoint administrators who need access to all the site collections in a web application but don’t want to add themselves to each one manually. SharePoint also uses web application policies to give certain accounts permissions to the web application. For example, the Search Crawl account has Full Read permissions on every web application in the farm it needs to crawl. You can also create custom policies and permission levels in the web application permission policy; however, it’s recommended to only use the default ones if possible. To add users to the web application policy, from the Web Application page in Central Administration, select the web application you want to apply the policy to, and select User Policy from the ribbon. A window will open that displays all the current policies for the web application.
  • Use managing SharePoint groups. You can group together user accounts and Active Directory security groups to make security assignment easier. You can also to configure SharePoint to use an alternate source for users and groups. You assign users and groups to SharePoint groups, and then use the SharePoint groups to assign permissions within sites. SharePoint groups can be used throughout a site collection hierarchy to assign rights within the various sites within the collection and can also be used to assign rights to SharePoint libraries and lists contained within the site.

Conclusion

Following these configuration and security best practices will help you keep your Microsoft SharePoint environment highly available and secure, driving adoption and enabling you to make the most of your investment in the collaboration platform.