J. Gregs Brain Corral

Ever have a disaster with one of your servers?  No?  You lucky bastard…

Recently we had corruption of a number of our Virtual Machines (caused by a fault in the firmware of our “enterprise” storage system from a Nameless Mainstream Vendor, which was triggered by unexpected filesystem behavior from an Evil Mainstream Company’s virtualization platform).  This event forced us to exercise our system disaster recovery tools, (also from a Nameless Evil Mainstream Company) and brought us to the subsequent discovery that some backup products just don’t do DR.  There is much that could be said about that, but I will leave it there.

Anyway, we thought we would have a look at Microsoft DPM 2007 SP1 to see if the DR story there is any better.

Here are some sticking points I have hit while evaluating the product:

• Server Recovery Tool (SRT) – This is the Bare Metal Recovery component of DPM.  As it turns out, it only can protect Server 2003 and XP systems.  Server 2000 is a no go (no tears here…), as are Server 2008 and Server 2008 R2 (aargh!).  SRT is pretty easy to setup and configure, but keep in mind that it must run on a Server 2003 OS (not Server 2008!).
• DPM Reporting Services – The DPM installer creates a IIS instance on your machine, and configures/installs SQL 2005 with Reporting Services.  Very nice!  Unfortunately, the installer misses one critical IIS setting when installed on Server 2008:
  http://scdpm.blogspot.com/2009/07/reporting-does-not-work-with-dpm-2007.html
  You need edit the feature permissions on the the “HTTP Handler Mappings” feature on the Reporting Services IIS site to allow “Script” access (not script execution, just script access).  After that, you should be able to run reports from the DPM console.
• Updates – In addition to SP1, there are numerous hotfix rollup packages available, of which you should take advantage. 

• Here the the most current DPM update pack, as of the time of this writing:
  http://www.microsoft.com/downloads/details.aspx?familyid=14E1A04B-2323-4344-B737-A3194B9AB3ED&displaylang=en
  In my case, I need this to address errors in the WSSCmdletsWrapper that crop up when attempting to create a protection group for Windows SharePoint Services.  Keep in mind that you need to update the server and your DPM Agents.
• You may also need VSS updates:
  http://support.microsoft.com/kb/940349
  It appears that VSS updates are available only for Server 2003.  I guess Server 2008 is perfect and does not need VSS update

• You must configure your WSS VSS Agent to run as an account that has both local Administrator rights on the SharePoint WFE, and Farm Administrator rights.  The writer must be configured after installing the DPM agent and before attempting backup.  Use “ConfigureSharePoint.exe” in the DPM bin directory to make these changes.
• You also can configure backup of MOSS Search, which is accomplished using a different switch to the “ConfigureSharePoint.exe” tool.
• The VSS updates mentioned above are required before backing up a WSS farm.
• Server 2008 DR – Documentation on this really bites.  I sent the following feedback to the DPM whitepaper team for their document on Server 2008 Bare Metal recovery (How to do Bare Metal Recovery of WS08 with DPM 2007 SP1):

There are a few points in the white paper that require some clarification as they will confuse most readers.  I also have a few questions about the reasoning behind some of the steps in the document.

1. In the section "Before you create the protection group" under "Configuring Backups for BMR" it is unclear on which system you should be performing these steps.  A seasoned DPM admin will be able to figure out that these steps need to be performed on every system which will be backed up, but a newbie will not know this.  The instructions should be more explicit. 
2. The instructions have us create a share on the local server rather than simply backing up the WSB image to a named volume.  Why?  It would seem that backing up to a local share adds unnecessary complexity to this operation.  Using a local volume will be simpler and more secure. 
3. Similarly, in the recovery instructions we are told to restore the system image to a local share.  Why?  In a bare metal recovery scenario, there is no local share to recover to!  The server referred to as "%computername%" in the recovery will likely be offline, and thus not available as a recovery target.
4. In step 3 of "Configuring Backups…" we instructed to add the PreBackupScript commands to the "PSDataSourceConfig.xml" file, but we are not told within which XML tags to insert the code.  I was unable to make Pre-backup scripts run when following these instructions.  Instead, I placed the code snippet into "ScriptConfig.xml" (where other documentation suggests that this code actually belongs), and my backup jobs then started to run.
5. There is no guidance here about the frequency with which BMR sets should be created.  Unfortunately, I can find very little in the way of best-practices on this subject (Server 2008 disaster recovery, as a general topic).  It seems that weekly (or perhaps even monthly) BME sets followed by daily "standard" DPM backups would be adequate to protect most operating systems, but it would be nice to have some verification of this.  Can you point me to any additional documentation on this subject.

• Server 2008 DR needs some improvement, to be blunt about it.  The team promises better BMR integration under DPM 2010, but details are not yet available.