System Center DPM Not Working, Diagnosed and Fixed (2026 Guide)
Why System Center DPM Stops Working
I've seen this exact situation play out on dozens of enterprise environments: System Center Data Protection Manager was humming along fine, backups were running on schedule, and then one morning it just... stops. Protection agents go unreachable. Jobs fail silently. Error codes pop up that look like random numbers with zero context. The on-call admin gets paged at 2 AM, and nobody can figure out why System Center DPM is not working when nothing obviously changed.
The frustrating truth is that DPM is a deeply networked product. It doesn't just sit on one server, it reaches out and talks to every protected machine via the DPM Protection Agent (DPMRA) service. When that communication chain breaks anywhere, firewall rule, domain trust, time sync drift, DCOM permission, DPM breaks in ways that look completely unrelated to the actual cause.
Here's who typically runs into System Center DPM problems:
- Admins after a domain controller change. Kerberos authentication relies on synchronized clocks and valid domain membership. Move a DC, demote one, or change AD replication topology and DPM agents start throwing access-denied errors almost immediately.
- Teams after a Windows Server update. Patch Tuesday can reset firewall rules or restart the DPMRA service in a degraded state. The agent is technically installed but not responding.
- New DPM deployments where the server was never properly joined to the domain. Error code 7, "Unable to connect to the Active Directory Domain Services database", is one of the first things you'll see, and Microsoft's own documentation confirms that DPM must be a full domain member, not a workgroup machine.
- Virtualized environments after a live migration or cluster failover. If you're using clustered remote SMB storage, DPM can throw error 41 when a backup job tries to start right after the primary cluster owner is switched. It looks like a broken agent but it's actually just bad timing.
What makes System Center DPM error messages so unhelpful on their own is that the same root cause, say, a blocked firewall port, produces at least four different error codes depending on which direction the communication is failing and which phase of the operation DPM is in when it gives up. Errors 11, 13, 31, 33, 41 can all trace back to the same firewall rule. You have to look at the error code, the direction of communication it describes, and the Application event log on the protected computer together before you can pinpoint anything.
This guide walks you through the full diagnostic and fix process for System Center DPM agent issues, communication failures, error codes 0 through 43 (and beyond), and the configuration mistakes that silently break things over time. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you dive into registry edits and DCOM configuration, try this single sequence. In my experience, it resolves roughly 60% of System Center DPM protection agent failures outright.
Step 1, Restart the DPMRA service on the protected computer. Open Services.msc on the protected server (not the DPM server itself, on the machine DPM is trying to back up). Find DPM Protection Agent (DPMRA), right-click it, and choose Restart. If the service fails to restart, that's your smoking gun, skip straight to Step 3 of the full guide below and reinstall the agent.
Step 2, Wait 3–5 minutes, then retry the browse or backup job in the DPM console. After the DPMRA service comes back up, it takes a minute or two to re-establish its connection to the DPM server. Don't hammer the retry button immediately.
Step 3, If it still fails, check the Application event log on the protected server. Open Event Viewer, navigate to Windows Logs > Application, and filter by source DPMRA. The most recent entries will tell you exactly why the agent failed to respond, whether it's a certificate issue, a connectivity timeout, or something at the OS level. This is where System Center DPM hides its real error messages, not in the DPM console.
Step 4, Verify time synchronization. Run this on both the DPM server and the protected computer:
w32tm /query /statusIf the time offset is more than 5 minutes from the domain controller's clock, Kerberos authentication will silently fail. That produces access-denied errors (codes 12, 32, 42) that look like permission problems but are actually clock drift. Sync the time with w32tm /resync /force and retry.
System Center DPM is built on Active Directory. It's not optional, it's architectural. Error code 7 ("Unable to connect to the Active Directory Domain Services database") is almost always the first symptom when domain connectivity breaks, and it blocks everything downstream.
On the DPM server, open a Command Prompt as Administrator and run:
nltest /dsgetdc:<YourDomainName>
nltest /sc_verify:<YourDomainName>If the first command fails or returns an error, DPM cannot reach a domain controller at all. Check your DNS settings, the DPM server's preferred DNS must point to an internal DC, not a public resolver. Also confirm the DPM server's computer account is healthy in Active Directory Users and Computers. A disabled or stale computer account produces authentication failures that look identical to network errors.
On domain-joined protected computers, also run nltest /sc_verify to confirm the secure channel is intact. If it's broken, reset it with:
netdom resetpwd /server:<DomainController> /userd:<Domain\AdminAccount> /passwordd:*Once domain connectivity is confirmed on both ends, go back to the DPM Management console, click the Agents tab under the Management task area, and check each protected computer's status. A green check means the agent is reachable. Anything else means you move to the next step.
What you should see when it works: The nltest /sc_verify output ends with "Secure channel for domain... is in good standing." The DPM console shows protected computers with a healthy agent status.
This is the most common cause of DPM agent errors 11, 13, 14, 31, 33, 34, and 41. The firewall is blocking communication between DPM and the protected computer, and critically, DPM communicates in both directions. The DPM server reaches out to protected machines, and protected machines reach back to the DPM server. If either direction is blocked, different error codes appear.
On the DPM server, open Windows Defender Firewall with Advanced Security and ensure the following inbound rules exist and are enabled:
- TCP port 5718, DPM Agent Coordinator
- TCP port 5719, DPM Protection Agent
- TCP 135, DCOM/RPC Endpoint Mapper
On each protected computer, the same ports must allow inbound from the DPM server's IP. You can verify reachability with:
Test-NetConnection -ComputerName <DPMServerName> -Port 5718
Test-NetConnection -ComputerName <ProtectedServerName> -Port 5719If either returns TcpTestSucceeded: False, you've found your block. Add an inbound allow rule via PowerShell:
New-NetFirewallRule -DisplayName "DPM Agent 5718" -Direction Inbound -Protocol TCP -LocalPort 5718 -Action Allow
New-NetFirewallRule -DisplayName "DPM Agent 5719" -Direction Inbound -Protocol TCP -LocalPort 5719 -Action AllowIn environments with hardware firewalls between subnets, you'll need to coordinate with your network team. DPM backups between sites require these ports to be open bidirectionally across any intervening firewall appliance, not just Windows Firewall. If you're running a backup LAN configuration, also verify that the backup LAN's network settings in DPM are still valid, stale IP configuration here causes error 41 on backup job start.
What you should see when it works: TcpTestSucceeded: True on both port tests. Protected computer status in DPM Management goes from "Agent Unreachable" to "OK."
When the DPMRA service won't start at all, or when error codes 15 or 35 appear ("no agent is installed on <ServerName> or the computer is rebooting"), a clean reinstall of the protection agent is the right call. Trying to repair a corrupt agent install wastes time, a fresh deploy takes about five minutes.
First, remove the existing agent from the DPM Management console. Navigate to Management > Agents, select the affected computer, and in the Details pane, choose Remove Record if the agent status shows as failed or stale. This cleans up DPM's side of the relationship.
On the protected computer, uninstall the existing agent from Control Panel > Programs and Features, look for Microsoft System Center Data Protection Manager Protection Agent. If it's missing from the list but DPMRA processes are still running, kill them via Task Manager first.
Back in the DPM Management console, go to Management > Agents and click Install in the action pane. Follow the wizard, enter the target server name, provide domain admin credentials, and let DPM push the agent remotely. Alternatively, if you prefer manual installation, copy the agent installer from <DPMInstallDir>\agents\ra\<version>\<architecture>\ to the protected computer and run it there.
After installation, you'll be prompted to restart the protected computer. Do it. Error code 30 ("DPM can't contact <ServerName> until you complete the protection agent installation by restarting the computer") exists specifically because admins skip this restart. DPM knows it's pending and will refuse to communicate until the reboot completes.
What you should see when it works: After the restart, the protected computer appears in the DPM Management console Agents tab with a status of "OK." The DPMRA service shows as Running in Services.msc on the protected computer.
Error codes 12, 32, and 42 share a common theme: "access is denied." Once you've ruled out time sync issues, the next place to look is DCOM permissions. DPM uses DCOM to communicate between the DPM server and the protection agent, and if the DPM service account doesn't have the right DCOM launch and access permissions on the protected computer, you get cryptic access-denied failures that don't mention DCOM anywhere in the message.
On the protected computer, open Component Services (run dcomcnfg.exe). Expand Component Services > Computers > My Computer, then right-click My Computer and choose Properties. Click the COM Security tab.
Under Launch and Activation Permissions, click Edit Limits and ensure that the DPM server's computer account (or the domain group that contains it) has Local Launch, Remote Launch, Local Activation, and Remote Activation permissions set to Allow.
Under Access Permissions, click Edit Limits and confirm the same account has both Local Access and Remote Access set to Allow.
You can also set these via the registry under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\OleBut I'd recommend using the DCOMCNFG GUI to avoid any formatting errors in the binary security descriptor. After saving changes, restart the DPMRA service on the protected computer and retry the operation from the DPM console.
What you should see when it works: Error code 12, 32, or 42 stops appearing. The DPM Management console can browse the protected computer and enumerate its data sources without an access-denied error.
This one catches a lot of admins off guard during initial DPM setup. When you configure protection for a volume that contains a mount point, DPM will present you with a dialog that says: "<ObjectName> contains a mount point at <MountPointPath> whose destination volume is <VolumeName>. Do you also want to protect the volume <VolumeName>?" (error code 40).
This is not actually an error, it's a decision prompt. But if you dismiss it or configure DPM unattended and miss it, you end up protecting the mount point path without protecting the underlying volume's actual data. Backups complete, restore tests fail. That's a bad day during an incident.
When DPM asks if you want to protect the destination volume, answer Yes unless you have an explicit reason not to. The destination volume is a separate data source, and protecting only the mount point path without also protecting the volume it points to creates a gap in your recovery capability.
To check whether a protected data source has this gap right now, go to Protection > Protection Groups in the DPM console, expand each group, and review the protected members. If you see a folder path that is a mount point without a corresponding volume entry, edit the protection group and add the destination volume explicitly.
Also keep in mind what DPM explicitly cannot protect: the Recycle Bin, the System Volume Information folder, non-NTFS volumes, DFS links, CDs, the cluster Quorum Disk, and removable media. Error code 38 appears when DPM tries to enumerate these paths. You'll want to exclude them deliberately in your protection group configuration to avoid these enumeration errors cluttering your alert logs.
What you should see when it works: Protection groups show both the mount point path and the destination volume as separate protected members. No error 38 alerts for excluded system paths. Recovery point creation succeeds for all members of the group.
Advanced Troubleshooting for System Center DPM
Analyzing the Application Event Log for DPMRA Errors
If the five steps above haven't resolved your System Center DPM issue, it's time to go deeper. On the protected computer, open Event Viewer and navigate to Windows Logs > Application. Filter by event source DPMRA. The entries here are the closest thing to a real diagnostic trace you'll get from the protection agent side. Look for error-level events that were logged at or around the time the DPM job failed. Common patterns include certificate validation failures (agent and DPM server TLS certificates are out of sync), RPC binding failures (a sub-symptom of firewall or DCOM issues), and service account credential expiry.
On the DPM server itself, check Windows Logs > Application filtered by source MSDPM. Cross-reference the timestamps between the two machines, the sequence of events tells you who initiated the failure and who was responding to it.
Shadow Copy and Replica Association Failures (Error Code 0)
Error code 0, "Unable to create the Shadow Copy. The cause of the failure was the replica is lost association between the replica and diff area", is one of the more disruptive DPM failures because it means the VSS (Volume Shadow Copy Service) infrastructure on the protected volume has gotten out of sync with DPM's replica. This usually happens after an abrupt server shutdown or storage failover.
To resolve it, you need to run a consistency check. In the DPM console, navigate to Monitoring > Alerts, find the replica inconsistency alert, and select Run Consistency Check Now. If the consistency check itself fails, you may need to perform a fresh replica creation, be aware this can be time-consuming for large data sources.
You can also check VSS writer status on the protected server directly:
vssadmin list writersAny writer in a "Failed" or "Waiting for completion" state will block DPM's shadow copy creation. Restart the corresponding service to reset the writer state.
Removing Stale Agent Records
When a protected computer is decommissioned or renamed and the record isn't cleaned up in DPM, those ghost entries cause noise and sometimes interfere with re-adding machines with the same hostname. Go to Management > Agents, select the stale computer entry, and in the Details pane click Remove Record. This removes the entry from DPM's database without touching anything on the protected computer side, it's completely safe if the machine is already gone.
Clustered Environments and SMB Storage
In clustered configurations, DPM can throw error 42 ("access is denied to the protection agent") immediately after a cluster owner node switches. The issue is that DPM is still addressing the previous owner node while the cluster has already moved resources. Wait 2–3 minutes for the cluster to fully stabilize, then retry the operation manually. For ongoing issues in clustered environments, verify that the DPM server has DCOM permissions against the cluster's virtual computer object (VCO) in Active Directory, not just the physical node names.
Prevention & Best Practices for System Center DPM
Most System Center DPM failures I've seen are preventable. The product is actually quite stable when the environment it runs in is well-maintained. The problems come from environmental drift, firewall rules that change during patching, domain controller issues that aren't caught early, agent versions that fall behind the DPM server version after an upgrade.
Keep agent versions in sync with the DPM server. After every DPM server update, go to Management > Agents and check for the "Update required" status on any protected computers. Running mismatched agent versions is a leading cause of communication errors in DPM environments that have been running for more than a year.
Set up DPM alert notifications. DPM can send email alerts for failed jobs, agent health changes, and replica inconsistencies. Configure this under Options > SMTP Server in the DPM console. You want to know about agent unreachable errors within minutes, not hours, every missed backup job is a recovery point gap.
Run weekly consistency checks proactively. Don't wait for DPM to flag an inconsistency alert. Configure automatic consistency checks on your protection groups (available in the protection group properties under the Consistency Check tab). Running these on a schedule catches replica drift before it turns into a failed backup job at the worst possible moment.
Document your recovery point objectives and test restores quarterly. DPM's job is to make recovery possible, but a backup that's never been tested is a hypothesis, not a guarantee. Use the Recover task in the DPM console to do test restores to an alternate location at least quarterly. You'll catch configuration problems (like the mount point protection gap described in Step 5) long before you need them under pressure.
- Sync time on all protected computers and the DPM server with the same domain controller using
w32tm /resync /force, schedule this monthly - After every Patch Tuesday, log into DPM Management and check the Agents tab for any machines that went "Unreachable" during the patching window
- Keep a written record of every protection group, protected data source, and retention range, DPM console is your operational view but a spreadsheet is your safety net when the console itself is broken
- Before decommissioning any protected server, always remove the agent record from DPM first to avoid stale entries that confuse future deployments
Frequently Asked Questions
Why does System Center DPM say "host is unreachable" for a server I can ping just fine?
Ping (ICMP) and DPM's communication protocol are completely different things. DPM uses DCOM over TCP ports 5718, 5719, and 135 to talk to its protection agents, and those ports can be blocked by Windows Firewall or a network appliance even when ICMP is wide open. Use Test-NetConnection -ComputerName <ServerName> -Port 5719 to test the actual port DPM needs. Error codes 11, 31, and 41 all describe "host is unreachable" but trace back to these blocked ports, not to general network connectivity. Fix the firewall rules and the error goes away.
DPM shows "access is denied" but I'm running as a domain admin, what's going wrong?
Running as a domain admin doesn't automatically grant the DCOM launch and access permissions that DPM needs on the protected computer. Error codes 12, 32, and 42 all describe access-denied failures, but two of the most common root causes are: clock skew between the DPM server and the protected computer exceeding five minutes (which breaks Kerberos authentication silently), and missing DCOM permissions for the DPM server's computer account on the remote machine. Check time sync first with w32tm /query /status, then check DCOM permissions via dcomcnfg.exe on the protected computer as described in Step 4 of this guide.
DPM asked me "do you also want to protect the volume?", should I say yes?
In almost every case, yes. When DPM detects that a folder path you're protecting contains a mount point to a different volume, it's telling you that the actual data lives on that destination volume, and protecting only the mount point path without protecting the volume itself leaves a gap in your backups. If you back up just the path, DPM will report successful recovery point creation, but when you actually try to restore the data that lives on the mounted volume, it won't be there. The only exception is if that destination volume is already protected through a separate protection group, in that case you can safely say no to avoid duplicate protection.
How do I fix DPM error code 30, "can't contact until you complete agent installation by restarting"?
This one is straightforward: restart the protected computer. Error code 30 appears specifically because DPM's agent installation wrote files and made configuration changes that require a reboot to take effect, and DPM is aware of this pending restart. The console will continue showing this error until the protected computer fully restarts and the DPMRA service comes up clean. Don't try to work around it, just restart the machine. After the reboot, wait about 3–5 minutes for the agent to establish its connection back to the DPM server, then retry the browse or protection configuration from the console.
Can System Center DPM protect non-NTFS volumes, DFS links, or the Recycle Bin?
No, these are explicitly unsupported data sources for DPM protection. The product cannot protect Recycle Bin folders, the System Volume Information folder, non-NTFS volumes (such as FAT32 or ReFS volumes in some configurations), DFS links, optical media like CDs, the cluster Quorum Disk, or removable storage devices. When DPM tries to enumerate these paths during a browse operation, it returns error code 38. The fix is to deliberately exclude these paths in your protection group configuration, which stops DPM from attempting to enumerate them and clears the error alerts they generate.
DPM protection agent keeps going "unreachable" after every Windows update, how do I stop this?
Windows updates commonly restart the DPMRA service in a way that leaves it in a stopped state, especially when the update restarts the server and the DPMRA service startup type gets reset or the service fails its startup sequence. After updates, check Services.msc on each protected computer and confirm DPMRA is set to Automatic startup and is in a Running state. You can automate a post-reboot service health check using a scheduled task or a monitoring script that runs Get-Service DPMRA | Where-Object {$_.Status -ne 'Running'} | Start-Service after each reboot. Also check the DPM Management console's Agents tab within 24 hours of any patching window, catching an unreachable agent early prevents recovery point gaps from accumulating.