Why you MUST document your SharePoint farm configuration

11/09/2010 Update: Sean McDonough has written about “Configuration-Only Backup and Restore in SharePoint 2010” on his blog. I highly recommend you check it out if you are interested in ensuring your SharePoint 2010 farm configuration is documented.

I was reading through a forum post this evening from a user in the SharePoint community that was asking how to go about restoring a MOSS farm to another environment. The OP described his attempt to backup and restore his farm using the in-built recovery tools within Central Administration, and I answered the query initially by offering up the backup and restore SQL tools as an alternate method of taking a full fidelity farm backup (which I have used in the past with success).

However, it then dawned on me that what the OP is trying to do is not a supported scenario in MOSS, nor in SharePoint 2010 for that matter. That’s right folks, whilst it is quite straightforward to take a backup of it, it is not possible to restore a SharePoint configuration database. That’s confirmed in this KB article in the context of MOSS. There are two primary reasons for that: a.) site orphans (sites that exist in content databases but not in the configuration DB due to restoration) and b.) environment settings (the config database contains, amongst other details server names).

Of course, this limitation only applies to the farm configuration database. You can restore SharePoint content and even SSP’s (service applications to those on 2010) without too much trouble – and content is key in the context of DR given that without a working backup it is irrecoverable (even the most complex farm configuration database can be re-created from scratch with sufficient resources – but no amount of SharePoint admins can “re-create” that massive archive of finance documents without a backup).

@spmcdonough was kind enough to take the time out to confirm this. Sean has done a lot of work in the SharePoint DR space and a book on SP2010 DR that he is co-authoring is soon to be released to an Amazon site near you. Sean added weight to the discussion by mentioning that (amongst other items detailed below), file system modifications are not captured as part of a full farm backup and so need to be dealt with separately. In the past, I have used the Windows Server NTBackup tool for 12 hive (SharePoint root in the 2010 world) and IIS file (e.g. web.config) changes – I’ve never had a problem with it and recommend it given that it is included with Windows server.

Whilst I am on the subject, here are a few of the other file-system customisations you will almost certainly want to consider in your SharePoint backup strategy. Most of these were taken from Professional SharePoint 2010 Administration by Todd Klindt, Shane Young, and Steve Caravajal – I hope they don’t mind. It’s a good book that you will often hear me raving about.

Common SharePoint File system customisations you will want to backup

  • IIS site configuration
  • Assemblies deployed to the GAC
  • Features
  • Site Definitions
  • Any master pages, images, CSS files or page layouts that are not stored in your content DBs
  • iFilters and corresponding registry modifications
  • Third party solutions (again, these often include assemblies deployed to the GAC)
  • Resource files (.resx)

But back to our precious SharePoint farm configuration – what can we do to protect it? In MOSS, SQL database mirroring is an option that can certainly increase availability of the database, but ultimately you must ensure that you have a fall back in the form of thorough documentation. Luckily, Microsoft provide a handy list of settings that you should document on Technet. Essentially, these can be found by clicking through central administration:

MOSS Farm configuration settings you should document:

  • Application pool settings, including service accounts (all accounts that run as Web applications, including the crawler account and the search account).
  • Alternate access mapping settings.
  • Farm-level search settings.
  • External service connection settings.
  • Workflow management settings.
  • E-mail settings.
  • A/V settings.
  • Usage analysis processing settings.
  • Diagnostic logging settings.
  • Content deployment settings.
  • Timer job settings.
  • HTML viewer settings.
  • Recycle Bin settings and other Web application general settings.
  • Administrator-deployed form templates.
  • Default quota templates.
  • Database names and locations.
  • Web application names and databases. Be sure to document the content database names associated with each Web application.
  • Crawler impact rules.
  • Activated features.
  • Blocked file types.
  • Farm solutions (e.g. WSP files) that have been deployed (thanks to one of my readers for this one).

OK, so what about SharePoint 2010? I’ve already mentioned that the configuration DB cannot be restored due to it containing environment specific settings and potential synchronisation issues. Whilst that is true, Microsoft have mitigated this limitation by providing us with a “Configuration Only” backup option. This capability is great news given that being able to restore the configuration directly is the equivalent of restoring the database itself. What’s even better is that the configuration backup can be used to restore farm settings to another environment – which will prove incredibly useful for those wishing to create consistent pre-production environments.

For those using PowerShell, a farm configuration backup can be taken by running the following script:

Backup-SPConfigurationDatabase -Directory <Backup folder> -DatabaseServer <Database server name> -DatabaseName <Database name> -DatabaseCredentials <PowerShell Credential Object> [-Verbose]

So do you still need to document your farm configuration in SharePoint 2010? Yes, but your job is made significantly easier given that a config-only backup does some of the work for you. For those still running MOSS, documenting those central administration settings is not optional – it’s essential in ensuring you have a true “full fidelity” backup.

11/09/2010 Update: As detailed by Sean McDonough on his blog, documenting a SharePoint 2010 farm’s configuration is unfortunately still very much a manual process. There are certainly some improvements compared to MOSS, but we are pretty far from a one-click SharePoint farm cloning capability. In particular, AAM settings, environment specific settings (IP addresses, machine names), and Service Applications are NOT backed up as part of a config-only SharePoint 2010 farm backup.

One thought on “Why you MUST document your SharePoint farm configuration

  1. Veronica

    Hi Benjamin,

    Great post, it´s always a bit messy to collect all the needed information of a SharePoint farm, and though we know more or less all the points to take into account this post list all together. Thanks.



Leave a Reply

Your email address will not be published. Required fields are marked *