Interesting case that I just resolved.
Customer is using a third party software to perform SharePoint restores. While trying to connect back to the DPM server from the other SharePoint application restoration server he was getting the following error:
After taking network traces and DPM MPS Reports, we started doing code reviews of how the connect-dpmserver.ps1 script works.
When you perform a connect-dpmserver.ps1, we initiate communication to the DPM server via RPC. Once the RPC connection is made, we then talk to the SQL server via TCP/IP.
We use a setting from the registry to let the connecting server know what the name of the server is and the instance of SQL that we try and connect too. In a default installation the database name is MS$DPM2007$. The connection string should reference <servername>\\\MS$DPM2007$. In our customers situation the connection string was localhost\\\MS$DPM2007$.
This caused the connecting server to initiate communication to the DPM server and then the DPM server told it to connect to the local host; there was no DPM database on this server because only the DPM Management Shell was installed.
After changing the connection string we saw the following:
Why was it still failing? DPM caches the information it collects from the registry to hand back to the servers that are trying to connect to it via the connect-dpmserver.ps1 script. Not until we either restart the DPM service or reboot the server will DPM be re-populated with the correct information.
After restarting the DPM service we now see the following:
Support Escalation Engineer
Microsoft Platforms Core Team: DPM