Moving a node between clusters might break secondary DPM service

I've recently moved a DPM protected Hyper-V node from one cluster to another. No problem, except I probably should have removed the DPM agent before doing so. I didn't, and while the primary DPM server never had any issues recognising the new cluster membership or with protecting the node seamlessly, the SECONDARY DPM server soon exhibited crashes at seemingly random intervals. Application log showed event ID 943: A MSDPM SQL database inconsistency.

Unable to connect to the DPM database because the database is in an inconsistent state.

Problem Details:
Microsoft.Internal.EnterpriseStorage.Dls.DB.DBCorruptionException: DLS error: Couldn't retrieve details
for 'movedclusternode' from the database. SP='dbo.prc_AM_ClusterNode_Get' Error=50001.

The stored procedure DPM calls to get information about a cluster node (prc_AM_ClusterNode_Get) returned 2 clusters for the, which is impossible and correctly flagged as inconsistent.

Looking at that stored procedure reveals the following query:

SELECT dbo.tbl_AM_ClusterNode.NodeID,
FROM dbo.tbl_AM_ClusterNode, dbo.tbl_AM_ClusterDetail
WHERE ServerName = @ServerName
AND dbo.tbl_AM_ClusterDetail.ClusterID = dbo.tbl_AM_ClusterNode.ClusterID
AND dbo.tbl_AM_ClusterNode.Deleted = 0

tbl_AM_ClusterNode indeed included two entries for my moved node, one for the previous ClusterID and one for the current ClusterID (use get-productioncluster to easily see which ID belongs to which cluster).

The solution was to set the "deleted" column of "tbl_AM_ClusterNode" to true for the previous ClusterID, so the stored procedure would return only one result.

This is probably highly unsupported, but it worked for me.