SharePoint 2007 - Disaster. Recovery?

Nowhere on any Microsoft website will you find a clear and complete guide on what is obviously one of the most fundamental and critical aspects of any system – disaster recovery.

In order to save others much pain and suffering I have outlined my lessons learnt below:

• It really, really helps if the environments you are working between match as closely as possible.
  • This includes - but is by no means limited to - ensuring that the root site is of the same type in both locations.
• Farm-level backup does not include the following:
  • Items in the Global Assembly Cache (any custom DLLs)
  • Web config files
  • IIS web app settings
  • Customisations and some elements in the 12 hive

These items should be backed up separately and applied to the new location first.

The following is an approach to migrating a farm (single- or multi-server) from one environment to the other. It is provided here free of charge and should be used as a guide only. I have attempted to list and present these items in some form of chronological order but no doubt everyone's needs and tastes here will differ.

1. Web Apps
   • Recreate these on the destination server(s) first. You don’t want to copy anything here because these would usually be using different host headers, URLs etc.
2. Custom DLLs in GAC
   • These can just be copied across. I keep a separate folder of all custom DLLs on another box (dev) and just copy these to C:\Windows\assembly on the target server(s) – all WFE (web front ends).
   • These also need to be registered as Safe Controls in your web.config.
   • You can usually determine what your custom items are from the web.config files.
3. 12 Hive
   • It’s quite possible that developers have made changes here. Usually they add any custom logos, images and page copies in here.
   • The good news is that the 12 hive from one default installation to the next is identical.
   • Modifications will usually have been restricted to the TEMPLATE folder so you can start by just copying that.
4. Web.config(s)
   • You will have a web.config file for each web app on each WFE. Ignore the confusing existence of web.config files in the 12 hive CONFIG directory. These don’t appear to get used at all.
   • What no one bothers telling you is WHICH web.config file(s) need to be changed! There are dozens and it’s bluddy confusing. The ones you actually need to affect changes in are again on the WFEs only, within the relevant IIS folder – e.g. C:\Inetpub\wwwroot\wss\VirtualDirectories\www.yourwebapp.com80
   • Easiest method is to copy an existing one to the new location. Make a copy of the destination file first.
   • If you have a diff tool (there are dozens but I like the one that ships free with TortoiseSVN) you can compare them to see the differences for yourself.

There you have it. Four fairly simple steps (once you know what you need!).

Once all that is in place you should be able to do a Farm or site collection restore on the server and hopefully everything will just work for you. In our case we also had to reconfigure the following because MOSS seems to use hard-coded site roots in some areas:

• Content Query Web Parts (and others based on it) – sometimes but not in all cases these need to be reconfigured
• Send To links – this field only accepts an absolute URL so any values you’ve applied here need updating
• Publishing Layout Pages – inheritance paths for these sometimes still point to the old server.
  • You can check this by trying to edit the Page Settings for any publishing page.
  • If you get an error then you are affected by this bug. It can be resolved using one of two methods described in another blog entitled Page Settings: Bad Paths - MOSS Restore Issues continued.

Once you’ve got the new environment up and running then using Content Deployment seems to be the easiest way to get new content across. The main issue I ran into here was that we wanted to use the same GUIDs but Content Deployment doesn’t like this.

Seems pretty strange when you consider that any custom solution, workflow, site definition etc., all use GUIDs natively to determine what content is being referenced!