Troubleshoot MABS agent communication failures by checking services, firewall, name resolution, credentials and connectivity.
Confirm the protected server's identity and agent version, then work outward through DPM/MABS services, name resolution and firewall/RPC.
A stalled sync and a stalled consistency check have different causes — check the specific job type in the MABS console before assuming it's connectivity.
Verify the correct computer name, IP address and MABS agent version.
Confirm the protected server's identity and agent version
Agent communication failures often trace back to a mismatch that has nothing to do with the network — the protected server was renamed, rejoined the domain with a new SID, or has an agent version that predates the MABS server's minimum supported version after an update. In the MABS Administrator Console, open Management → Agents and confirm the listed computer name and agent version match what's actually installed:
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Microsoft Data Protection Manager\Agent" | Select-Object InstallPath, ProductVersionCheck required services on the protected server
On the protected server, confirm both the agent coordinator and the DPM/MABS agent service are running:
Get-Service DPMRA, DPMLA -ErrorAction SilentlyContinueDPMRA (DPM Replication Agent) is the one that actually handles data transfer — if it's stopped, no protection job for that server will run regardless of how healthy the network path is. Check the Application log for source DPMRA for the specific failure reason before restarting the service.
Test name resolution in both directions
MABS agent communication is bidirectional — the MABS server needs to resolve the protected server, and the protected server needs to resolve the MABS server back. Test both, not just one:
# From the MABS server
Resolve-DnsName ProtectedServerName
# From the protected server
Resolve-DnsName MabsServerNameA one-directional failure (works from MABS server, fails from protected server) usually points to a stale DNS record or a protected server pointed at the wrong DNS servers — check with ipconfig /all on the protected server rather than assuming the MABS server's DNS configuration applies.
Check firewall and RPC connectivity
MABS agent communication relies on RPC (dynamic port range) plus a small set of fixed ports. Confirm basic reachability first:
Test-NetConnection -ComputerName ProtectedServerName -Port 135
Test-NetConnection -ComputerName ProtectedServerName -Port 5718
Test-NetConnection -ComputerName ProtectedServerName -Port 5719Port 135 (RPC endpoint mapper) succeeding but the actual data transfer still failing usually means the dynamic RPC port range itself is blocked somewhere in between — check any network firewall or NSG sitting between the MABS server and the protected server, not just the local Windows Firewall on either end.
Review agent logs on both sides
The agent's own logs are more specific than the MABS console error, which is often generic. Check DPMRA*.errlog under the agent's Temp directory (typically C:\Program Files\Microsoft Data Protection Manager\DPM\Temp) on the protected server, and correlate the timestamp with the exact time the job failed in the MABS console. Look for the underlying error code rather than just "communication failed" — a VSS writer failure and a genuine network timeout require different fixes but can surface with similar console-level messages.
Validate protection after the fix
Don't close the incident on a successful ping or service restart alone — run a manual synchronization from the console (right-click the datasource → Create recovery point, or Synchronize) and confirm it actually completes rather than just starts. A job that starts but hangs partway through usually means the underlying cause (RPC port range, VSS, disk space on the protected server) wasn't actually resolved.