How to configure SharePoint protection in Data Protection Manager and troubleshoot related issues

~ Chris Butcher | Senior Support Escalation Engineer

FIXHi folks, Chris Butcher here again with another DPM blog series for you. We get quite a few calls regarding SharePoint protection in System Center 2012 Data Protection Manager (DPM 2012) so I decided it was time to take a more in-depth look at this and go over some of the more common problems you may run into.

I decided to break this down into three parts, both to make it easier to digest and to keep the article from getting too long and hard to manage. The first part, which you’ll find below, will focus on issues you might encounter when configuring SharePoint Protection in Data Protection Manager. In this scenario we have no protection set up and we are going from ground zero. Part 2 will cover problems you may see when backing up SharePoint. This will be broken down into three areas: Backing up SharePoint Configuration and content databases from SQL, creating SharePoint metadata, and creating the SharePoint catalog. Lastly, part 3 will cover issues with restoring SharePoint with Data Protection Manager.

So with that out of the way, let’s go ahead and get started by taking a look at creating SharePoint protection in DPM 2012 and some points in the process where you might run into issues. This scenario assumes that DPM 2012 is installed, storage is provisioned and agents have been deployed, however we have no protection set up yet for SharePoint. 

Creating SharePoint Protection

1. To configure SharePoint protection, open the DPM management console, click Protection, then New to start the Create New Protection Group wizard. Click Next on the Welcome to the New Protection Group Wizard.


2. Select Servers and then click Next on the Select Protection Group Type page as shown here:


3. Expand the server that holds the SharePoint Web Front End (WFE) role. If you have more than one SharePoint WFE server, the one to select is the server where you previously ran ConfigureSharePoint.exe –enablesharepointprotection.


NOTE If you don’t see SharePoint as a protectable item under your WFE server, this usually indicates that you have not run configuresharepoint –enablesharepointprotection on the WFE server. You must run this from an administrative command prompt on the Web Front End server where you want to enable protection. This will enable the SharePoint writer to allow DPM to protect it.

When we expand the SharePoint server, this is what happens.

a. DPM queries VSS to see what data DPM can protect from that server.

b. If the SharePoint database is on a remote server, the DPM Server will connect to the SQL server that is hosting the SharePoint configuration database. For that to work, the DPM Agent needs to be installed on that server or servers. If that SQL Server is member of a cluster, all nodes of that cluster must have a DPM agent installed as well.

c. If all is fine up to this point, we should be able to expand the SharePoint data source and see the farm information details.


There are few things that could go wrong and cause you to not be able to see the SharePoint icon shown above, or if you do see it, you may get an error when trying to expand it. If you see either of these problems, here are some things to check:

1. If the SharePoint writer is disabled then there is no way for DPM to know that SharePoint is installed on that box. By Default, SharePoint VSS Writer is set to disabled and you must enable it by running the ConfigureSharePoint –EnableSharePointProtection command.

NOTE The SharePoint writer is named SharePoint 2010 VSS Writer in Microsoft SharePoint 2010.

2. Make sure that SharePoint VSS Writer is started and running.  

3. Make sure that the SQL Server VSS Writer on the SQL Server is started and running.

4. Make sure that the user account used for SharePoint VSS Writer has sufficient permissions on the SQL server.

5. Make sure the SQL server has the DPM agent installed. If it is not, you will probably get the error below, however the wizard will still allow you to continue.

clip_image010 Error text: DPM cannot protect your Windows SharePoint Services farm until you install agents on the following servers…

6. Make sure that the SharePoint databases are not being protected as SQL data sources.

7. Make sure that the SQL Server VSS Writer is running on the SQL server that holds the SharePoint databases.

It’s possible that you may also receive the error below after expanding the SharePoint icon and selecting the SharePoint farm for protection:


Error text: DPM cannot protect this SharePoint farm as it cannot detect the configuration of the dependent SQL databases. (ID: 32008)

If this happens, it could be that SharePoint is using a SQL alias and there is no alias configured in cliconfg or SQL Server Configuration Manager.

So now that we’ve broached the SQL alias, cliconfg and SQL Server Configuration Manager, let’s take a quick look at these.

CLICONFG.EXE (%windir%\system32) allows you to create a SQL alias for 64-bit clients. If your application uses 32-bit calls to access SQL, an alias defined with this tool won’t do any good.

CLICONFG.EXE (%windir%\SysWOW64) allows you to create a SQL alias for 32-bit clients. If your application uses 64-bit calls to access SQL, an alias defined with this tool won’t do any good.

NOTE If you are running a 32-bit operating system, %windir%\system32 will contain the 32-bit version of CLICONFG. The 64-bit of CLICONFG will not be available.

NOTE There is no 32-bit version of SharePoint 2010. All versions of Windows come with cliconfg.exe

Here is what CLICONFG.EXE looks like:


CLICONFIG and SQL Server Configuration Manager share the same information so if you have an alias configured in one location it will also show up in the other.

If you open SQL Server Configuration Manager you will see that there is a SQL Native Client ** Configuration (32bit) and a SQL Native Client ** Configuration. By expanding these, you can see that each has aliases and you can view and modify the aliases there.

In the view shown below you can see that the 32-bit aliases can be found by expanding the red box and that 64-bit aliases are found by expanding the blue box.


The biggest issue of note when dealing with aliases is to make sure that the version of SQL Client Connectivity components are the version that DPM requires. This is based on the version of SharePoint being protected and not the version of DPM. These tools must be installed on the WFE server where you are establishing protection and are installed by launching the SQL installation media and selecting this option. It will not affect any other settings.

SharePoint Version

SQL Client Connectivity Tools Required


SQL 2005


SQL 2008 (or SQL 2008 R2)


SQL 2008 (or SQL 2008 R2)

Assuming there was no error selecting the SharePoint farm for protection, you can continue by setting up group information such as group name, retention rage, disk/tape backup etc. and complete the wizard.

That should cover the most common problems you’re likely to encounter when configuring SharePoint protection in Data Protection Manager. Next time we’ll take a look at some of the issues you might see when actually backing up SharePoint.

Chris Butcher | Senior Support Escalation Engineer | Microsoft GBS Management and Security Division
Wilson Souza | Senior Support Escalation Engineer | Microsoft GBS Management and Security Division

Get the latest System Center news on Facebook and Twitter:

clip_image001 clip_image002

System Center All Up:

Configuration Manager Support Team blog:
Data Protection Manager Team blog:
Orchestrator Support Team blog:
Operations Manager Team blog:
Service Manager Team blog:
Virtual Machine Manager Team blog:

Microsoft Intune:
WSUS Support Team blog:
The RMS blog:
App-V Team blog:
MED-V Team blog:
Server App-V Team blog:
The Surface Team blog:
The Application Proxy blog:

The Forefront Endpoint Protection blog :
The Forefront Identity Manager blog :
The Forefront TMG blog:
The Forefront UAG blog:

DPM 2012 R2 SharePoint 2010 SharePoint 2012