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.
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.
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.
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.
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.
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.
Like Blob Cache (see above), Publishing Cache can improve performance for users on SharePoint sites that use Publishing infrastructure.
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.
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.
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.
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. Download the trial to take a snapshot of your farm and check what’s going on.