Resolving DPM 2012 Untrusted Domain Server Communication Issues

I ran into this problem during the week with a multi-tenant DPM 2012 installation. This server was originally a DPM 2010 server of which we had configured untrusted domain server’s to communicate with. The solution that I have outlined in this post will work for both DPM 2010 and DPM 2012.

All was working fine on this server until I noticed an alert from SCOM detailing the following:

Alert: DPM2012: Recovery point creation failed (3114) Resolution state: New

When I analysed the alert I found the following text:

The protection agent operation failed because DPM could not communicate with the Protection Agent service on sql-srv.lab.local.

DPM failed to communicate with sql-srv.lab.local because of a communication error with the protection agent. (ID: 53)

I logged onto the DPM 2012 server - using my newly configured Central Console through SCOM!, checked the agents from within the ‘Management’ tab and found the screen below:

It was interesting that all of the servers in this particular untrusted domain had the same ‘Unavailable’ message and straight away got me thinking that it had to be a password or logon issue with the account that is created when the communication is originally setup between the untrusted domain server and the DPM server.

When I checked the ‘Local Users and Groups’ on the DPM 2012 server and looked at the accounts for the untrusted servers giving the error message, I saw that I had forgot to change the password policy on the local user account when I originally created them and they were set with the password policy in the screen below

Untick the ‘User must change password at next logon and change it to ‘Password Never Expires’ and then click ‘OK’ to continue

A new feature of DPM 2012 is to use Certificate authentication (PKI) between the untrusted domain and DPM servers and if this feature was in use here, then I wouldn’t have the problem I was now facing (as the original DPM 2010 server that this communication was setup from didn’t have PKI functionality).

To resolve the issue was fairly easy though and here’s what I did to get the agents back to a working state.

Firstly, logon to the server in the untrusted domain that is generating the error in DPM and open up an elevated command prompt.

Now browse to the following location on the C drive of your untrusted domain server:

C:\Program Files\Microsoft Data Protection Manager\DPM\bin

Once here, type the following to reset the password:

SetDpmServer.exe -dpmservername dpmservername.domainname.local -isnondomainserver –updatepassword

It should now present you with an option to type in your new password for the local account that the DPM server is using for communication between the untrusted domains.

Once you’ve typed your new password in twice, you should then get a message back stating that the configuration has completed successfully!

Now all that’s left to do is to go back to your DPM 2012 console, go to the Management tab and then select the ‘Agents’ option from the left hand side. Right mouse click on the agent that you have just updated the password for and select the ‘Refresh’ option

Once you have refreshed the agent status, it should now change to ‘OK’

 
Repeat this process for any other agents that you have with an error status similar to this one.