SharePoint Protection and Recovery using DPM 2007 – Part I

With SharePoint gaining popularity in the last year and the recent release of DPM 2007 which supports the protection of SharePoint this has become a hot topic in the last few months. The protection and recovery of SharePoint data is not small undertaking and there is quite a bit of flexibility with what you can recover. For this reason, let me caution you in that this can be a complex undertaking but once the methods are understood, its benefits far surpass the trouble of the initial learning curve.

So let’s start with the basics of what is required in order to protect SharePoint with DPM and we will expand from there. Over the course of this series, we will cover protection and recovery on several various levels, each of which will have it’s own nuances which dictate this breadth of coverage.

  • Protection Requirements
  • Recovery of a SharePoint Farm
  • Recovery of a SharePoint DB
  • Recovery of a SharePoint Object (Site, sub-Site, folder, file, etc.)

We begin with the Protection Requirements. Below is a list of what is needed to fully protect and recover SharePoint data.

  • DPM 2007 only protects “Microsoft Windows SharePoint Services 3.0” and “Microsoft Office SharePoint Server (MOSS) 2007”. If this is not what is installed in your environment, now is a good time to look at upgrading.
  • The SharePoint patch from 941422 must be installed on all servers. Install Knowledge Base article 941422, "Update for Windows SharePoint Services 3.0" ( )
  • There must be a second SharePoint Farm installed. This can be a VM somewhere as it only needs to be a single server install. It does however, require that you have enough space presented to the VM in order to restore any site and its database. Consider the size of your largest Content database and its URL structure and add about 20%. This is your starting point for the storage on your recovery server.
  • The recovery server will have to have a web application called DPMRecoveryWebApplication created on it. If this name is not found, recovery of some SharePoint data will not be possible.
  • The WSS writer must be registered and configured for DPM to use.
  • DPM must have use of an account which is a Farm Administrator otherwise, it will not have sufficient permissions.
  • The DPM Agent specifically requires the VSS patch 940349 and .NET Framework 2.0 to be installed in addition to the SharePoint requirements.

Let’s start with the following assumptions:

  1. SharePointA – Production SharePoint server
    • Port 8080 – Administration port
    • Port 8081 – Production Website port
    • Port 8083 – Alternate Recovery Site on production Farm.
  2. SharePointB – Recovery SharePoint server
  3. DPMRecoveryWebApplication – web application only created on SharePointB.
  4. DPM Agent installed on both SharePoint servers.
  5. SharePoint patch 941422 has been installed on both SharePoint servers.

With this configuration, we can restore any site to its original or alternate location or we can also recover a Content Database or the entire Farm.

To start and register the WSS Writer service:

  1. Open a command prompt window using elevated privileges. From within the Command Windows, navigate to C:\Program Files\Microsoft Data Protection Manager\DPM\bin and launch ‘ConfigureSharepoint.exe’
  2. In the command window that appears, you will see the request "Enter the user name for “WSSCmdletsWrapper:" Enter the account name for the user account you granted Farm Administrator credentials
    • If you enter an invalid account, you will receive the following:
    • Invalid user name.
    • Examples of valid user name are "username@domain" and "domain\username".
    • Once you add a Fully Qualified account name and hit enter, you are presented with the next line requesting a password.
  3. Enter the password for ‘WSSCmdletsWrapper’:

After a moment of configuring, the entry "The command completed successfully" will appear and the CMD window will close.

DPM only offers the option of protecting the entire SharePoint farm as seen in the screenshot below. This changes when the discussion revolves around recovery of data, as we will see in the next section. DPM provide a great deal of granularity when it comes to recovery of SharePoint data.


If the WSSCmdletsWrapper is not registered properly, then the SharePoint farm you see in the screen shot above will not appear. If it is missing, run the ConfigureSharePoint.exe utility on a SharePoint front-end web server to allow DPM to reconfigure the necessary options.

At this stage, you should be able to create a DPM Protection Group which contains the SharePoint servers take an initial replication of the content. Depending on the size of the sites, this can take a few minutes to hours to complete.

Since there are numerous distributed SharePoint implementations across many servers, we need to talk about which of these servers to protect. Here is a short list.

Web Front-end servers – Since all are the same, only one will need to have the ConfigureSharePoint.exe on it to register the WSS Writer.

Configuration Database Server – The data stored here is unique and not stored on other database servers so it is vital that you have a DPM Agent installed to protect it.

Content Database Servers – Content databases host all the information, content, and data of the farm. Each needs to be protected by a DPM Agent.

Creating the DPMRecoveryWebApplication in SharePoint

Before DPM can be used to recover any data to a protected Farm, the DPMRecoveryWebApplication must be created on the recovery farm’s server. As a requirement of the restoration process, it is helpful to understand the process necessary to create this SharePoint Web Application.

Below are the steps necessary to create the DPMRecoveryWebApplication.

  1. Open the SharePoint 3.0 Central Administration console from the Start Menu.
  2. Once the SharePoint 3.0 Central Administration console is open, click on the Application Management tab which opens to display all of the various options for managing your SharePoint installation.
  3. Look under the SharePoint Web Application Management heading to find the Web application list at the bottom and select this menu item.
  4. When the Web Application List appears, check through the list to confirm that the DPMRecoveryWebApplication does not already exist. If it does exist, you are free to delete it and continue with these instructions or you may continue with the one that exists. If it does not exist, please continue through the following steps to create one.
  5. Click the “back arrow” to return to the Application Management page. Under the SharePoint Web Application Management heading, click on the Create or Extend Web application.
  6. The Create or Extend Web application page appears with two options. The first called Create a new Web application is the one we will choose. The second option, Extend an existing Web application is not needed for this purpose.
  7. After clicking the Create a new Web application link, the Create New Web Application page appears displaying various necessary fields for details about the web application that is being created. Here is a brief summary of the important fields of this page.
    • Chose the Create a new IIS web site and in the description, name it “DPMRecoveryWebApplication”.
    • In the Port field, give it a unique port which is not shared by any other internal application. In the example below, note that the port is 911 since this is our emergency recovery web application for SharePoint failures.
    • The Host Header and Path fields can remain unchanged.
    • Scroll down to the radio button Create new application pool and in the Application pool name box, note that the entry name includes the port number and the SharePoint recovery server name.
    • Under the Select a security account for this application pool, select the Configurable radio button and type in a suitable account and password in the fields that follow. Note the security warning at the top of the page indicating that the credentials of this account may be transmitted in clear-text across the network.
    • Lastly, in the Database Name box, type in DPMRecoveryWebApplication.

This is the last entry to make before hitting OK to have the web application created. This will take a few moments but once complete, DPM will be able to recover SharePoint data. Upon completion of the DPMRecoveryWebApplication web application, the Application Created screen appears. At this point, schedule time to run ‘iisreset /noforce’ and once complete, DPM will be able to recover SharePoint data using this recovery farm.

Once these steps have been completed such as the installation of the DPM Agent on the various SharePoint servers, registering the WSS writer, creation of the DPMRecoveryWebApplication on the recovery server, and creation of a recovery site in the production farm, you are ready to protect your SharePoint data.

Next, we will take a look at the steps necessary to recover the entire SharePoint farm whether the production farm is available or not.