SharePoint 2013 best practices

When you work as a consultant or as a SharePoint administrator, there are many things that you need to set up to get the best SharePoint performance. Moreover, you need to be very careful in planning the infrastructure and testing.

Microsoft’s Best Practices have been published on their site and blogs, but also there are some great recommendations from MVPs and other SharePoint folks and communities, who are trying to squeeze the last bit of performance from SharePoint to get a better SharePoint system.

In general, the best practices are divided into best practices for performance, security and infrastructure planning. In this post, we will show you how some small changes to a configuration can greatly improve SharePoint stability, security, and performance.

As you all know, SharePoint 2013 is often virtualized. So, besides the SharePoint and SQL server configurations, you need to know all about your virtualization software and the underlying hardware. In this post, I will use Hyper-V as the virtualization platform, but some of the stuff is universal to other platforms. So let’s see how this looks for some example farm on the picture!

Infrastructure layer

Before you even begin to install SharePoint, you need to start at the infrastructure layer and follow the best practices for it and then move up to the SQL server layer and at the end to the SharePoint layer.

This is often a part of the system that the average SharePoint admin is not in charge of, but when implementing SharePoint you also need to think about it. Even if your storage, network and server admins are doing their best to keep this part up and running, there are some special configurations that can help you to improve your SharePoint system.

Recommendations for the Infrastructure layer:

• Do not use dynamic memory for SharePoint VMs because this is not supported by SharePoint.
• Use VLANs to divide the traffic (i.e. a central admin site and end user sites) and to make SharePoint more secure.
• Do not use time synchronization with the parent host for the SharePoint VM because it can mess up SharePoint Timer jobs and led to unpredictable behavior.
• Do not take any snapshots of a VM in a production environment because these will degrade the performance of your VM.
• Use Jumbo frames on your network if you have the right equipment, because they will help your network to perform faster.
• Check with your storage guy what NTFS allocation unit size is best for your storage to improve the performance of your SharePoint site.

These are just a few examples to show you how important it is to understand that even non SharePoint stuff can have a direct impact on SharePoint stability and performance. Beware that some of the recommendations might not apply to your environment, because almost every environment is unique.
You can see further details about some of the recommendations with a detailed explanation for a Hyper-V environment here.

SQL Server layer

In most cases, poor performance occurs because of a SQL Server misconfiguration. Using the default values for SQL Server is probably, in most cases, the worst configuration. SharePoint doesn’t support some configurations and it is best that SharePoint has its own dedicated SQL instance. Also SQL Server has rules for how it should be virtualized and you need to follow these rules and check what SharePoint requires from SQL.

Recommendations for the SQL Server layer:

• Data partitions that holds databases should have an allocation unit size of 64k (in most cases) to get the best performance from SQL server.
• You should put TempDB on a separate (faster) drive to boost performance because this database is I/O intensive.
• Logs for your databases shouldn’t be on same drive as the database files, again for performance reasons.
• MAXDOP must be set to 1 for SharePoint to work normally.
• You should restrict the minimum and maximum memory values for your SQL server.
• Do not enable auto-create statistics on a SQL instance that hosts SharePoint databases because is not supported.
• Use reasonable initial settings for your SharePoint databases, especially the growth value (the default is 5 MB).

There are numerous SQL recommendations that you need to follow to get the most from your SQL, and, in the end, your SharePoint server. Security is also an important factor and also needs to be carefully planned. Achieving high availability is critical for databases and you should have disaster recovery scenarios prepared and most importantly tested regularly.

You can read details of some SQL recommendations here.

SharePoint Application/WFE layer

SharePoint is the last layer in our stack. When we are setting everything up that SharePoint needs to work properly, we need to take decisions about the farm architecture. For your scenario, you need to make decisions on how many servers you need, how many will be APP or WFE servers, whether you need load balancers and other stuff.

After the initial design has been adopted, it is a good strategy to re-evaluate the whole design from time to time, especially if you see bottlenecks in some part of SharePoint. For example, if you see that the Search Service Application is slow, maybe it is time to add a couple of new servers to your farm for Search only. These are individual decisions that you will need to make based on your scenario.
The general strategy is to keep your SharePoint healthy, clean and speedy!

Recommendations for the SharePoint layer:

• You will have a couple of installers that you can modify for you needs – use the PowerShell installer instead of the built-in Configuration Wizard.
• Use dedicated service accounts – this is good security practice because these accounts will have only the rights that they really need.
• Use caching – this will speed up responses for end users.
• Use SSL for the central administration site.
• Patch your SharePoint regularly and take backups.
• Write the logs from SharePoint to another drive – if you forget to set logging up properly (i.e. trimming of logs), you can fill up the system partition and stop the whole server.

TechNet has a wiki page with lots of resources on this theme.

Conclusion

In this article, I have tried through some simple recommendations to show you how important it is to understand the big picture. Sometimes you will need to identify bottlenecks that are, maybe, not directly SharePoint’s fault, but are due to some connected services or underlying service that stops SharePoint from performing well. In most cases, it is difficult to track all of these recommendations for all of the above, so I’m pleased to be able to recommend the Documentation Toolkit for SharePoint, which has built-in Best Practices reports.

These reports will show you what you can do better within your farm. They will tell you a lot about your current setup and configuration and will save you some time. Finding the right recommendations and checking whether they have changed is time-consuming, so I believe that these reports will help you.

Managing and maintaining SharePoint is complicated, but is easier if you understand the best practices and which ones are relevant for your environment. There are a lot of resources regarding this online and I would definitely recommend that you regularly check Microsoft articles and follow SharePoint MVPs’ and consultants’ blogs because in them you can find a lot of really great tutorials and explanations about best practices.