text: Note: This is the second of a three part series for troubleshooting the DPM RA (Data Protection Manager Remote Agent). Please check out the earlier blog, and the next (all start with the same title).
  Network security protocols between the DPM Server and the Agent can directly affect Agent communication as can DNS configuration and registration issues. Check these settings on each server to ensure that there are no network issues blocking the agent and server from communicating with each other.
  1. Check SMB (Server Message Block) signing on the DPM and PS (Protected Server) servers and verify the following settings on both servers.
  Windows XP and 2003 – local computer Group Policy
  Workstation/Client:
  Microsoft network client: Digitally sign communications (always) Security Setting: disabled
  Microsoft network client: Digitally sign communications (if server agrees) Security Setting: enabled
  Server
  Microsoft network server: Digitally sign communications (always) Security Setting: disabled
  Microsoft network server: Digitally sign communications (if client agrees) Security Setting: disabled
  2. Check and make sure that Windows Firewall is disabled on both the DPM and PS servers. If it must be enabled, make sure that the following ports are open. (More information in 947682 –). Also, if it must be enabled, make sure it is enabled before installing the agent as the DPM installation process automatically configures the firewall exclusions to allow DPM agent communication.
  a. 53 UDP
  b. 88 TCP\UDP
  c. 135 TCP
  d. 137 UDP
  e. 138 UDP
  f. 139 TCP
  g. 389 TCP\UDP
  h. 5718 TCP (DPM)
  i. 5719 TCP (DPM)
  j. Add the DPMRA application to the exclusion list.
  3. Make sure that there are no firewalls in between the DPM and protected servers and if there are, make sure the exceptions specified above have been applied.
  4. If a Netlogon Event error is displayed in the System Event log or the below error in the DPM Administrator’s Console, make sure that the DPM Agent’s machine account exists in the domain and has not been reset. On the DPM Agent computer, check the System Event log for an Event 5721 from Netlogon indicating what the account problem is.
  - If the machine account has been deleted, correct this by recreating the account and disjoining and rejoining the computer to the domain.
  - If the machine account has been reset, then SID in the account will match the machine’s SID and you can use NetDOM or NLTEST to reset the machine account’s secure connection to the DCs.
  Data Protection Manager Error ID: 318
  Error: The agent operation failed because DPM was unable to identify the computer account for: <FQDN for agent machine>
  Detailed Error Code: No mapping between account names and security IDs was done.
  Recommended Action: Verify that both <FQDN> and the domain controller are responding. Then in Microsoft Management Console (MMC), open the Group Policy Object Editor snap-in for the local computer and verify the local DNS client settings in Local Computer Policy\Computer Configuration\Administrative Templates\Network\DNS Client.
  5. If DCOM appears to be OK after checking WBEMTEST and DCOM sections (to follow, below) and we are still seeing what appears to be network communications issues, try pinging the DPM server from the protected server and vice versa by FQDN as well as IP. If this works, check to see if there have been any manual updates to the HOST file on the machines in question. Also check, using NSLOOKUP, to ensure the protected server is dynamically updating the DNS servers properly as this will also cause agent installation\communication to fail.
  .
  WBEMTEST:
  WBEMTEST is a tool we can use to test connectivity between the DPM Server and the DPM Agent system. We will use WBEMTEST to test our DCOM connectivity.
  Logon the DPM server using the same credentials you are using to deploy the DPM File agents. Try to connect using WBEMTEST from the DPM Server to the Server you plan on installing the DPM Agent onto. If you received the following error, please verify that the DCOM settings are correct.
  Number: 0x80070005
  Facility: Win32
  Description: Access is denied
  To test the DCOM connectivity via WBEMTEST, click on ‘Start\Run’ and type ‘wbemtest’ and hit enter. The following screen appears.
  Click on the "Connect" button and the following screen will appear with ‘root\default’ in the ‘Namespace’ field. Type in the name of the DPM Agent machine and specify the ‘root\default’ namespace to connect to.
  The UNC-style connection will initiate a DCOM connection from the DPM Server (local) to the DPM Agent Server (remote) and try to open up the ‘default’ namespace. If this fails, then there are still DCOM issues on the system.
  A working example appears below.
  Once a connection has been made, the button appear ‘live’ as in the screen shot above. Now click on the ‘Enum Classes…’ button at the top of the left-hand column.
  Once this screen appears, you can specify a class name if you know one but the easiest confirmation is done by selecting the ‘Recursive’ button and clicking on OK. This will show all of the top-level classes in the Default namespace. Once you have this information, you have confirmed that DCOM works. The below screen shot is an example of what a successful recursive query will return.
  Cluster Nodes:
  The Cluster Service must be running in order for the DPM Agent installation to proceed. Without the Cluster service running, MSDTC will not be accessible and this will affect the agent installation of DCOM. There doesn’t need to be an MSDTC resource in the cluster for the DPM Agent installation to work.
  All other settings for local security and DCOM are the same as the Non-Clustered Member Server settings above.
  Author:
  Victor Reavis
  Support Engineer
  Microsoft
  Join the conversationAdd Comment
  Hi folks, There are some great DPM troubleshooting articles on the Windows Server 2008 core blog (
  So I have this problem with DPM saying WMI is unavailable on the production server. I’ve tried WBEMTEST against the machine as recommended above and it fails when I use the server name. But it works fine when I target the IP addresses in the namespace – all of them (multihomed server). And yes, I made sure that the server name resolves to only the tested IP addresses. Any ideas what this might indicate?