Windows SharePoint Recovery Issues

Article
05/17/2011

Applies To: System Center Data Protection Manager 2010

The following table provides troubleshooting guidance on recovery issues for computers running Windows SharePoint Services.

Windows SharePoint Services Recovery Issues

Issue	Possible Cause	Resolution
Microsoft Office SharePoint Server 2007 – Unable to see recovered list item.	The item may still be in the site or site administrator’s Recycle Bin.	We recommend that you recover the item from the site or site administrator’s Recycle Bin, if it is the same version of the file that you are looking for, rather than recover it from the replica. Alternatively, clear both the Recycle Bins in SharePoint and then retry the recovery.
Microsoft Office SharePoint Server 2010 – Recovering list item does not recover its permissions.	The item already exists in the list, or is in either the user’s Recycle Bin or the site administrator’s Recycle Bin.	If you are recovering an item that already exists in either the user’s or the site administrator’s Recycle Bin, DPM will restore a duplicate item and apply the parent folder’s permissions. However, if the item has been deleted from all Recycle Bins, then it will be restored along with the permissions.
Recovery points are not displayed for sites or documents in DPM Administrator Console in the Recovery task area. (If you double-click the content databases, the sites do not appear.)	DPM backs up the databases and then performs a catalog task to get a list of all the URLs in the content databases. By default, this process runs three hours after the first scheduled backup job of the day. If the catalog task has not completed, you will not be able to expand the content database in the DPM Recovery UI.	Run the catalog task.
After recovering a Windows SharePoint Services farm, you cannot attach a content database.	If you recover a Windows SharePoint Services farm that had a detached database prior to recovery, you cannot attach the database after the recovery if the front-end Web server was different than the database DPM used for the recovery.	To resolve this issue, do the following: Delete the config cache on the front-end Web server that was not used for the recovery. The cache is a set of XML files located in the following folder: <drive letter>:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\<config database ID>. Warning Do not delete the folder. Delete only the XML files in the folder. The cache will automatically rebuild, enabling you to attach the database.
Recovery of the Windows SharePoint Services farm fails.	If a Quick Fix Engineering (QFE) is installed after the Windows SharePoint Services farm is protected, the recovery will fail.	To resolve this issue, do the following: Recover the Windows SharePoint Services farm by using the Recovery Wizard. On the front-end Web server, from the command prompt, type psconfig -cmd upgrade -wait -force -inplace b2b.
Consistency check fails with "Data source not found".	If you perform a recovery after the content database is deleted from SQL Server Management Studio, and not through the Sharepoint Console, the consistency check will fail.	You must stop protection, and then use the New Protection Group Wizard to reprotect the Windows SharePoint Services farm.
Permissions or ACLs for the document or list item have not been restored.	The document or list item is being restored to an alternative URL within the same farm.	DPM recovers the permissions or ACLs only if the item is being restored to the original location.
Recovering a SharePoint content database to its original location fails.	The recovery point is located on the tape and the database has been removed from the SharePoint farm.	Recover the database by using the “Recover to any SQL Instance” option.