Issues that are fixed in System Center 2012 R2 Data Protection Manager Update Rollup 1 - System Center: Data Protection Manager Engineering Team Blog - Site Home - TechNet Blogs

Issues that are fixed in System Center 2012 R2 Data Protection Manager Update Rollup 1

Issues that are fixed in System Center 2012 R2 Data Protection Manager Update Rollup 1

  • Comments 3
  • Likes

 Update Rollup 1 for System Center 2012 R2 Data Protection Manager is now available and resolves the following issues:

Issue 1: A 0x80070057 error occurs when a session is closed prematurely. This error is caused by a failure during a consistency check.

Issue 2: Lots of concurrent threads or calls to Microsoft SQL Server from the Data Protection Manager (DPM) console cause slow SQL Server performance. When this issue occurs, the DPM console runs out of connections to SQL Server and may hang or crash.

Issue 3: The DPM console crashes, and an error that resembles the following is logged:

Paths that begin with \\?\GlobalRoot are internal to the kernel and should not be opened by managed applications.

For complete details please see the following:

KB2904687 - Issues that are fixed in System Center 2012 R2 Data Protection Manager Update Rollup 1 (http://support.microsoft.com/kb/2904687)

For a download link please see the following:

KB2904734 - Description of Update Rollup 1 for System Center 2012 R2 (http://support.microsoft.com/kb/2904734)

J.C. Hornbeck | Solution Asset PM | Microsoft GBS Management and Security Division

Get the latest System Center news on Facebook and Twitter:

clip_image001 clip_image002

System Center All Up: http://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: http://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: http://blogs.technet.com/momteam/
System Center – Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm

Windows Intune: http://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The AD RMS blog: http://blogs.technet.com/b/rmssupp/

App-V Team blog: http://blogs.technet.com/appv/
MED-V Team blog: http://blogs.technet.com/medv/
Server App-V Team blog: http://blogs.technet.com/b/serverappv

The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Problems for us... First it failed because of a missing installation source (looks like an MSP was lost from c:\windows\installer) but we copied one from elsewhere that looked appropriate. Then it looked like a problem because our DPMDB wasn't in a standard location, so we changed the DPM registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Data Protection Manager\Setup\DatabasePath to be correct. Installation looks like it's succeeded, and it reports 4.1.3426.0 in the application and in programs/features. But the clients are still on 4.1.3417.0 and are not asking for an upgrade. Noticed that registry key has kicked back to default on installation completion too.... The other server we did worked just fine, but it was more standard. What's up here, anyone know if we can trigger the agent update, or otherwise verify that the installation has completed all tasks correctly? (If we run setup again, it says it completes fine.. I'm not so sure). Can we re-run the SQL post-installation part maybe ? Problem due to ignoring that key, in the installation logic, perhaps ?

  • Why doesn't DPM 2012 R2 support all the Windows OS releases that are currently still in production. I'm staggered to discover that anything older than Server 2008 R2 SP1 is not supported - surely that can't be right? Didn't DPM start out as 'the right choice' because Microsoft would always know best how to back up their products? How can you be the safe pair of hands if you're not supporting great chunks of the production environment (2003 doesn't EOL until 2015, 2008 in 2020)? I'm genuinely puzzled.

  • Could not get DPM 2012 R2 to backup to Azure before rollup 1 or after rollup 1. I am perplexed how little information there is available for DPM 2012 R2. It has been released for months and Microsoft stills references 2012 SP1 on most web pages, etc. I have followed all the steps and all looks setup correctly. If just always fails in less than a minute when creating an online recovery point.