DPM Server won't let you backup as a Primary DPM Server because previously it has been a Secondary for the same thing

 We recently came across a scenario where a protected server that used to be protected by another primary DPM server with Secondary protection on another had caused a problem where we couldn't make the Primary become that secondary server.

Original Scenario:

DPM-A protects Server called MYSERVER
DPM-B is setup as Secondary protection for MYSERVER getting the data from DPM-A

For various reasons, we now want DPM-B to be the Primary server (forever) for MYSERVER.

You could "switch protection" - but that (a) assumes the Primary DPM still exists and (b) that this won't be a problem later since it will forever live in "Switched Protection" mode.

Better would be to simply remove all the protection and start fresh.

When you do this, you might encounter the error:

One or more of the selected data sources are already configured for protection on the primary DPM Server. When you switch back protection, the replicas of these data sources will be protected from the primary DPM server (ID: 31162).

This of course isn't correct as DPM-A is no longer backing up that Server MYSERVER at all - but it still thinks it is involved via DPM-B.

The cause is that there are entries in the database for this in DPM-B that still thinks DPM-A has responsibility.

Fortunately there is a solution and the blog of Charbel Nemnom has written a script to solve this very issue - saving us all the job (what a helpful chap!) - check out: 

(Solution) Move Protected Server Between Two DPM Servers - (ID: 31162) - CHARBEL NEMNOM - MVP | MCT | CCSP - Cloud & CyberSecurity

You should no longer have a problem if you use the script - follow his guidance and you'll be good - and as he suggests, backup your DPM Database first!

I mean you don't need telling that surely as you're administering backups... but y'know, Back it up!

DPM 2019 - Upgrade leaves Secondary Protection Servers Inaccessible

It is now 2022. We're still using DPM (Data Protection Manager) as our primary backup solution. It continues to be the hidden gem of the Microsoft System Center suite and a product I really hope they never screw around with because overall it is fantastic. It might have a simple interface, it might not have all the bells and whistles, but at the core, it does backup, and most importantly, restore workloads.

We've recently upgraded our DPM 2016 suite to DPM 2019 and after the upgrades almost all was well. It took a few jumps as we had to first update SQL Server on each of the DPM servers as DPM2019 didn't support the older version we used, but equally DPM 2016 didn't support a new enough version for us to have bothered until now.

I strongly recommend you backup the DPM database via SQL Enterprise Manager before you begin using a "Copy Only" backup. Do this on every DPM Server. Then find the SQL server version that is supported by both the current DPM version you use, and the one you intend using (in our case supported by DPM 2016 UR10 and 2019 UR4)

The only problem we found remained was that Secondary Protection didn't work - the Primary DPM Server insisted that there was a problem with the agent version of the Secondary DPM Server but we knew that to be bogus.

DPM itself would say:

"Data Protection Manager ID: 296"

"The protection agent is incompatible with the version of DPM that is installed on this computer. All subsequent protection and recovery tasks will fail on this computer until you update the protection agent"

This is a bogus error - and indeed if you refresh the status of the secondary server you'll briefly see another error that comes/goes - indicating something else is amiss.

The "Recommended action" is a bit misleading in the case of secondary protection servers as it ultimately advises you should reinstall the agent or update the agent but that isn't something you can do on a Secondary DPM Server - assuming your Secondary Protection DPM server already runs the same release of DPM as your Primary (eg if it was DPM 2019 so too must the Secondary be - but also they should be up to the same Update Rollup), then this isn't the problem.

More likely is that the Primary server has not got permissions setup properly to allow the Secondary to talk to it. To fix this:

(1)

On the PRIMARY DPM Server, go into the Local Users and Groups section, and find the group named "DPMRADmTrustedMachines" - make sure the Secondary Server name is listed in this group - and if not, add it. 

In our case, adding the machine back to this group (it was clearly lost during the upgrade), then refreshing the agent status twice on the Secondary server corrected the issue and DPM now thinks all is well and has started providing secondary protection.

(2)

On the PRIMARY DPM Server, go to the "DPMDRTrustedMachines" group and ensure the Secondary DPM Server is listed there - if you don't do this your Agent Status is likely to say "OK" but you'll find you get error 33119 and issues enumerating the contents of the Primary DPM Server and/or a Protected Server it has already protected that you're trying to setup or modify the Secondary protection of.