> Working with Microsoft DPM can be incredibly frustrating at times. Some of the error messages can be a little too vague and sometimes the replicas can just be inconsistent for no apparent reason. However what it does very well, is potentially get you out of a massive hole should something go catastrophically wrong.

Recently, I’ve been on a project to migrate our Microsoft SQL databases (<2012) to a new SQL Server 2012 Enterprise server on our brand new Hyper-V cluster. During this, all users and databases have been put in one place and DPM has been used to look after the task of backups.

After setting up the protection for the new server by adding the DPM agent to the server, DPM refused to backup any of the databases citing ‘consistency check failed’. This isn’t actually what’s happening but what is happening is that if you go to your monitoring tab on DPM and go into ‘Failed jobs for yesterday and today’ on the left, the error that you really get is: ‘The DPM job failed for SQL Server 2008 database DBSERVER\database_name on DBSERVER.network.local because the SQL Server instance refused a connection to the protection agent. (ID 30172 Details: Internal error code: 0x80990F75)’.

Digging a little deeper, DPM uses the NT AUTHORITY\SYSTEM account to connect to do the backups. My SYSTEM account had lost its ‘sysadmin’ server role for whatever reason (or it was never there to begin with). To fix this, go to your ‘Security’ section in your SQL Server Management Studio, ‘Logins’, and then right click and go to the properties of NT AUTHORITY\SYSTEM. In your context window, select ‘Server roles’ on the left, and then add the sysadmin role (as seen below).

dpm

There you go, you should now have a fully working and very importantly, protected SQL server.

Edit: one minor point that I’ve missed so far is that you have the Windows Server Backup feature installed on the server, as this isn’t installed by default and DPM uses this in conjunction with the agent to do your server backup.