SharePoint health check (1): Auditing the SharePoint farm

This post is the first of a series explaining how to audit your SharePoint farm.

Auditing the SharePoint Infrastructure

audit2Maintenance is an essential part of running a healthy SharePoint farm. There’s a range of things to do to take care of the health of your farm, like

Tip: Read Todd Klindt’s blog “Hey! Should I install this SharePoint patch?” and the Bugs, Notes & Regressions of the CU/PU/SP before even considering to install any update on your farm.

I recommend also to check out the SharePoint Documentation Toolkit, a great tool developed by the guys at Acceleratio, co-founded by fellow SharePoint MVP Toni Frankola.

SPDocKit makes it easy to extract information like server names, installed customizations or lists of web applications. It generates a detailed document with everything you need to know about your farm, which can then be used as input to Microsoft Support or to a third party vendor when investigating an issue.

On top of that, SPDocKit can monitor the health of your farm by collecting and combining the information mentioned above instead of requiring you to collect all by yourself.

Looking into the cloud(s), let it be Microsoft’s SharePoint Online or any hosted service like Rackspace or FPWeb.net, the hosting provider takes care of keeping your environment healthy. So ususally there is not much to worry about there.

Tip: Follow Wictor Wilén, Spencer Harbar and Todd Klindt’s blogs who are the go-to resources for anything related to SharePoint infrastructure.

Wait, didn’t we miss something?

After working now 9 years with SharePoint, and I am sure most of you will agree, I can say with certainty that there is no such thing as a plain vanilla SharePoint environment. There is always a fair amount of customizations involved.

When it comes to these customizations usually things get more complicated. SharePoint administrators need to be careful about which types of custom code solutions they allow within their farm. Customizing SharePoint via the browser (e.g. with JavaScript hacks) or SharePoint Designer won’t relatively do too much harm as it normally affects only a page or a site, but full trust farm solutions for on-premises SharePoint farms have the potential for serious security and performance issues.

The full trust approach of course offers an unparalleled degree of choice for the developer. This can be great for very specific requirements and business needs. But it is important to be mindful of some of the more serious drawbacks of this approach:

  • Harder to upgrade: Custom solutions have to be upgraded manually with each SharePoint update.
  • A performance drain: Badly written custom code can cause performance issues which can reverberate across the farm.
  • Harder to get support: SharePoint support is widely available, but custom solutions are very often only supported by the company that built it (if you are lucky!).

Because of this high impact on a SharePoint environment resulting in higher maintenance efforts, Microsoft introduced the SharePoint App model for customizations in SharePoint 2013 and SharePoint Online. Apps are now the preferred way of future customizations. Read more about it in my blog “Five reasons to avoid ‘Full Trust’ solutions in SharePoint”.

Still, full trust farm solutions are well alive and certainly will be for many years as the current limitations of the app model, your very specific complex requirements, budget constraints preventing you to re-implement everything or your old SharePoint 2010 environment doesn’t leave you much other choice.

With all this in mind, it is important to run regular audits on your SharePoint farm to understand the health and status of any solution and app to answer the question: “What custom code solutions do exist and how do they affect the farm?”

Auditing the SharePoint Customizations

This is of course where the SharePoint Code Analysis Framework comes into place. SPCAF analyzes the customizations deployed to SharePoint environments including full trust farm solutions, sandboxed solutions, and SharePoint Apps. It looks for violations of predefined rules and gathers insight across five different areas (read more by clicking):

SPCAF integrates with Visual Studio and automated build systems like Team Foundation Server, Visual Studio Online or TeamCity, so development teams can check their code during the build process before it event gets to the farm.

errorlist

SPCAF results in Visual Studio

Further it allows the analysis of solution packages (WSPs) and apps in a client application which is very helpful when you do not have access to the original source code of the customizations.

SPCAF Analysis Dashboard

SPCAF Client Application

But how do I get all my customizations?

» Read on at “SharePoint health check (2): Extracting Customizations”