Troubleshoot SharePoint Protection and Recovery
Updated: May 13, 2016
Applies To: System Center 2012 SP1 - Data Protection Manager, System Center 2012 - Data Protection Manager, System Center 2012 R2 Data Protection Manager
This topic documents the following known issues and resolutions relating to protection and recovery of SharePoint data protected by System Center 2012 – Data Protection Manager (DPM):
On a secondary DPM server (DPM-DR), even though incremental and express full jobs happen successfully for a SQL Server database that belongs to a SharePoint farm, recovery points are not displayed in the Recovery task area and no alerts are triggered
In DPM, to search for SharePoint items such as list items in the Recovery task area, follow these steps:
On the Search tab, in the Search list, select SharePoint.
In the SharePoint search pane, click Search Documents.
In the Name list, select Contains as the search string.
Enter the name of the list item you want to recover.
This happens when in the SharePoint farm, the name of the SQL Server is not configured as a fully qualified domain name (FQDN), and only a NETBIOS name is provided. To resolve this issue, reconfigure the SharePoint server with the FQDN of the SQL Server by running the command Stsadm –o renameserver on the front-end Web server from where you plan to protect the SharePoint farm data.
When rebuilding the primary DPM server from the secondary DPM server data, one of the old recovery points shows databases that were not backed up. To resolve this issue, try to recover that database from another recovery point that might be older or newer.
In a DPM primary server, if you are protecting a SQL Server database that belongs to a SharePoint farm, then ensure that you do not protect that database independently on the secondary DPM server. To resolve this issue, you must identify all such databases, perform Stop protection with the delete data option, and then re-protect the SharePoint farm.
In SharePoint, if documents were checked out from the documentation library or were located in the first or second stage of the recycle bin during the time your data was backed up, they cannot be restored. To restore these documents, you must pick a point in time at which the documents were not checked out or in the recycle bin before restoring the data.
DPM does not calculate the expected number of recovery points correctly in the DPM Protection Report. Therefore the percentage that shows the historical recovery point availability against the existing recovery points is incorrect.
If you are having trouble continuing protection of a SharePoint site that is already part of a protection group after adding a content database, check to see if you have met all the DPM prerequisites for protecting Microsoft SQL Server 2005. In the process of adding a content database for protection, DPM may implicitly protect the back-end SQL database without validating the prerequisites.
When a shared folder is specified as the temporary location for the recovery of a SharePoint site or item the recovery will fail. To resolve this issue, use a local folder as the temporary location for either the recovery farm or the production farm.
If your SharePoint farm protection is failing with the ID 30111 error on the Jobs tab in the Monitoring pane in DPM Administrator Console, it could be because there is a volume with no mount points on the front-end Web server of your SharePoint farm. To resolve this issue, assign a mount point or drive letter to the dismounted volume and perform a consistency check.
Due to constraints in SharePoint, DPM cannot pause a profile import. Backups scheduled to run when a profile import is taking place will fail. The backups fail with error code 32010.
Message: DPM was unable to get the Content Sources of the SSP <Name of data source>; to a consistent state.
Check to see that the protected SSP is online and running.
Check to see that the WSSCmdletWrapper DCOM component is configured correctly on the front-end Web server hosting the protected farm.
Retry the operation and make sure no other application or process is trying to resume the crawl of the SSP during backup.
If this is happening after you have changed the administrator password, do the following to resolve the issue:
From the command prompt, run dcomcnfg.
In the DCOM Config utility, search for the WSSCmdletWrapper object. Right-click the object and select Properties.
On the Identity tab, enter the new password.