Top 10 SharePoint misconfigurations and how to avoid them

SPDockit helps SharePoint admins around the globe in provisioning and maintaining the best SharePoint farms out there. How does it do that, you might ask.

There are hundreds of different settings in a SharePoint farm and its supporting systems, like IIS and SQL Server, for example. No one knows all these settings by heart, and when multiple admins administer a single environment, problems can easily accumulate.

We in Syskit have built an extensive library of Microsoft and community recommended SharePoint best practices. SPDockit uses that library; it gathers all the configuration settings from a client’s SharePoint farm and compares them to the best practices documentation. So, as you can imagine, we have a pretty good insight into what our clients configure wrongly. Here’s what our telemetry says are the most commonly misconfigured settings in a SharePoint Farm.

1. Loopback is not disabled

This one is fairly easy to overlook and it can lead to many problems with the performance of your farm, and some services (such as Search) failing to perform tasks. Make sure you understand the entire problem in detail before proceeding to make any changes on this one.

2. Check if SharePoint and SQL servers are running out of disk space 

Make sure you actively monitor free disk space on servers in your farm. Ever-expanding SharePoint logs and databases could lead to a complete stop of the entire farm if one of the critical servers runs out of disk space and shuts down.

3. Enable Blob Caching

No end user is ever going to complain if the web page they requested loads faster. Sites with enabled blob caching will ensure all the supporting content (such as images, JavaScript, and CSS) are pre-cached and loaded faster.

4. Make sure you regularly backup your farm

This one is no-brainer. Backup your SharePoint, and then back it up some more. From time to time, test your restore routines and verify the validity of the backups you have.

5. There are technical limits to the size of SharePoint databases

The database is the main performance bottleneck for most SharePoint farms, yet many customers allow them to grow beyond Microsoft’s recommended boundaries for SharePoint content databases. Once your database outgrows these limits you should employ smart governance and information architecture policies, and when possible separate content into different content databases.

6. Content databases with the default autogrowth setting 

One of the hidden worst practices is hidden in your SQL Server. For every service and content database, the provisioned SQL Server is going to apply the default autogrowth setting, leading to autogrowth taking place at random times and your database growing in small chunks, fragmented within the database. Make sure you plan your database capacity, adjust your autogrowth settings, and pre-grow your databases based on expected usage and data input.

7. Improve page load performance by enabling Publishing Cache 

Like Blob Cache (see above), Publishing Cache can improve performance for users on SharePoint sites that use Publishing infrastructure.

8. SharePoint servers do not have enough RAM

Microsoft clearly states the hardware requirements for each version of SharePoint. Before you dig into any other performance-related investigation, make sure your servers are running on properly sized hardware.

9. Limit the number of IIS application pools 

One SharePoint farm can host only so many SharePoint Web Applications, and you should not have more than 10 application pools per web-front end. For farms that need more, consider spinning up a separate SharePoint farm.

10. Farm Accounts Used Interactively 

When planning a deployment of a SharePoint farm, one of the most important planning tasks is to plan proper service accounts. There are many recommendations available on the web, such as Microsoft’s accounts planning recommendations and Microsoft’s initial deployment accounts recommendations. Once you have determined the accounts that will be your service accounts, you should treat them as such. Do not use them to log-in to your servers. Make sure that every SharePoint admin who uses RDP to connect to a server has a dedicated admin account.

Conclusion

Not every best practice applies to every single SharePoint farm out there, but many are still worth checking. There are more than a hundred different best practices that SPDockit will check after a snapshot of your farm configuration is created.