Monday, November 26, 2012

When you trying to protect W8 clients, you get an error ID:30156, ID:31207 or ID:31209

When you try to protect W8 clients with DPM 2010 or DPM 2012 (RU3), you get some error messages :

DPM is unable to continue protection for because the change tracking information is corrupt (ID 30156 Details: The system cannot find the file specified (0x80070002))

Cannot perform creation of a recovery point on a replica which is pending manual replica creation (ID: 31207)

Cannot perform creation of a recovery point on a replica which is inconsistent (ID: 31209)


# DPM 2012 workaround
On the protected W8 clients :
  1. Located the dpmfilter.inf file and right-click and choose install.
  2. Open an administrative command prompt and run: fltmc load dpmfilter
(dpmfilter.inf => C:\Program Files\Microsoft Data Protection Manager\DPM\bin)

# DPM 2010 workaround
On the protected W8 clients :

  1. browse to the registry path : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Data Protection Manager\Agent\2.0.
  2. Create a DWORD registry value named ForceFixup and set it to1.
Or
  1. Located the dpmfilter.inf file and right-click and choose install.
  2. Open an administrative command prompt and run: fltmc load dpmfilter
As soon as you apply a workaround, you may have to perform a consistency check and your W8 protections will be fine.

Friday, November 9, 2012

Available: Update Rollup 7 for DPM 2010

This hotfix rollup resolves the following issues:

# When a Microsoft SharePoint site collection name contains a space, SharePoint item-level recovery fails in System Center Data Protection Manager 2010.

For more information about this issue, click the following article number to view the article in the Microsoft Knowledge Base: 2755678 - SharePoint item-level recovery fails when the site collection name contains a space in System Center Data Protection Manager 2010. (http://support.microsoft.com/kb/2755678/ )

# After you rename a SharePoint site in System Center Data Protection Manager 2010, you cannot restore the site.

For more information about this issue, click the following article number to view the article in the Microsoft Knowledge Base: 2763004 - System Center Data Protection Manager 2010 is unable to restore SharePoint after renaming a site. (http://support.microsoft.com/kb/2763004/ )

# In System Center Data Protection Manager 2010, the SharePoint Recovery Point Status report displays incorrect data.

For more information about this issue, click the following article number to view the article in the Microsoft Knowledge Base: 2763010 - System Center Data Protection Manager 2010 SharePoint Recovery Point Status Report shows stale data .(http://support.microsoft.com/kb/2763010/ )


Download the Rollup Package 7 for System Center Data Protection Manager 2010



Sunday, November 4, 2012

DPM 2012 RU3 - DPMDB database and log file could get very big when running SharePoint Catalog Task

Hi all,

DPM 2012 RU3 has introduced a spelling mistake in SQL Store Procedure leading to dysfonction of Sharepoint Catalog task: http://social.technet.microsoft.com/Forums/en-ZA/dataprotectionmanager/thread/e0e70be6-7249-438d-b43c-a0456f7c1338

The store procedure prc_PRM_SharePointRecoverableObject_Update should be modified. 

Open Microsoft SQL Manager Studio :

Go to DPMDB / Programmability / Stored Procedures

### before ###
USE [DPMDB]
GO
/****** Object: StoredProcedure [dbo].[prc_PRM_SharePointRecoverableObject_Update] Script Date: 11/04/2012 09:53:37 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[prc_PRM_SharePointRecoverableObject_Update]
(
@Caption nvarchar(40),
@ComponentType nvarchar(16),
@RecoverableObjectId BIGINT
)
AS
DECLARE @error INT,
@rowCount INT
SET @error = 0

SET NOCOUNT ON
UPDATE tbl_RM_SharePointRecoverableObject SET Caption = @Caption
UPDATE tbl_RM_SharePointRecoverableObject SET Caption = @Caption,
ComponentType = @ComponentType
WHERE RecoverableObjectId = @RecoverableObjectId

SELECT @error = dbo.udf_DPS_CheckRowCount(1)
SET NOCOUNT OFF
RETURN @error


### After ###
USE [DPMDB]
GO
/****** Object: StoredProcedure [dbo].[prc_PRM_SharePointRecoverableObject_Update] Script Date: 11/04/2012 09:53:37 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[prc_PRM_SharePointRecoverableObject_Update]
(
@Caption nvarchar(40),
@ComponentType nvarchar(16),
@RecoverableObjectId BIGINT
)
AS
DECLARE @error INT,
@rowCount INT
SET @error = 0

SET NOCOUNT ON
-- UPDATE tbl_RM_SharePointRecoverableObject SET Caption = @Caption
UPDATE tbl_RM_SharePointRecoverableObject SET Caption = @Caption,
ComponentType = @ComponentType
WHERE RecoverableObjectId = @RecoverableObjectId

SELECT @error = dbo.udf_DPS_CheckRowCount(1)
SET NOCOUNT OFF
RETURN @error


This bug will most likely fixed in the SP1.