Troubleshooting: DPM Protection Agent Service Startup Issues in Data Protection Manager

Updated: 09 Jul, 2025 • 0 • min read

Table of Contents

DPM Protection Agent Service Troubleshooting

When managing data protection for your enterprise using Microsoft System Center Data Protection Manager (DPM), encountering issues with the DPM protection agent service on protected servers can halt critical backup and recovery operations. A common error observed during the startup of the DPMRA service (DPM protection agent service) is The DPMRA service terminated with service-specific error 10048 (0x2740). This error specifically indicates a problem related to network communication ports required by the agent service. Understanding the root cause and implementing the correct troubleshooting steps is crucial for restoring the agent’s functionality and ensuring your data sources remain protected.

Symptoms¶

Following the successful deployment of the DPM protection agent onto a server designated for backup (a “protected server”), the DPM protection agent service fails to start. Attempts to manually start the service via the Services console or command line will result in the service terminating almost immediately. The specific error code 10048 (0x2740) will be logged in the Windows Event Log, typically within the System or Application logs, indicating the reason for the service failure. This prevents the DPM server from communicating with the agent, thus blocking any protection activities like synchronization, recovery point creation, or restores for data sources residing on that server.

Causes¶

The service-specific error 10048 (0x2740) is a Windows Sockets error code, specifically WSAEADDRINUSE. This code signifies that the requested address is already in use. In the context of the DPM protection agent service, this error occurs because the service is unable to bind to one or more of the specific TCP ports it requires for communication. There are primarily two reasons why this port conflict might occur:

Port Conflict: Another application or service running on the protected server is already using TCP port 5718 or TCP port 5719. These two ports are essential for the DPM server and the DPM protection agent to establish communication channels for various operations, including initial configuration, synchronization jobs, recovery operations, and agent status reporting. If another process has bound to one or both of these ports before the DPM agent service attempts to start, the agent will fail to start and report the 10048 error.
Firewall Blocking: While the error code 10048 specifically points to a port being in use, firewall issues can sometimes manifest with similar symptoms or prevent the service from establishing connections even if it starts. However, a direct 10048 error strongly suggests a local port conflict rather than a firewall blocking traffic between the DPM server and the agent. Nonetheless, it’s vital to ensure these ports are open in any firewall configurations (local Windows Firewall, network firewalls, etc.) once the service starts, as communication will fail otherwise. For troubleshooting the startup failure indicated by 10048, the focus is on the port conflict.

Understanding that the error specifically relates to a port being unavailable because another process holds it is key to effective troubleshooting. The DPM agent attempts to listen on these specific ports upon startup, and if the required port is already bound by another application, the binding fails, leading to the service termination.

Resolution 1: Identifying and Resolving Port Conflicts¶

The primary method to resolve the 10048 error is to identify which process is using the required TCP ports (5718 and 5719) and then either stop that process or reconfigure it to use different ports.

The netstat and tasklist command-line tools are invaluable for this task. netstat -ano displays active TCP connections and listening ports, along with the Process ID (PID) associated with each connection or listener. tasklist lists all running processes and their PIDs, and tasklist /svc extends this by listing the services running under each process.

Here is a detailed approach using these tools:

Open Command Prompt as Administrator: It is crucial to run these commands from an elevated command prompt to ensure they can list all processes and their network activity, including those running under system accounts. Right-click on Command Prompt and select “Run as administrator.”
Capture Network and Process Information: Execute the following commands in the administrative Command Prompt window. These commands redirect the output to text files for easier review.
```
netstat -ano > netstat.txt
tasklist > tasklist.txt
tasklist /svc > svclist.txt
```
- netstat -ano: This command lists all active network connections (-a), displays addresses and port numbers in numerical form (-n), and shows the PID owning the connection or listening port (-o).
- tasklist: This command provides a standard list of running processes by name and PID.
- tasklist /svc: This command is similar to tasklist but also lists the services hosted within each process, which is particularly useful as many applications run as services.
Running these commands saves the current state of network port usage and running processes/services to three separate text files in the directory where the command prompt was opened (usually C:\Windows\System32 unless you navigate elsewhere).
Analyze the Output Files: Open the generated text files using a text editor like Notepad.
```
notepad netstat.txt
notepad tasklist.txt
notepad svclist.txt
```
- Examine netstat.txt: Scroll through or search this file for entries corresponding to TCP ports 5718 and 5719. Look under the “Local Address” column for lines ending in :5718 or :5719. Pay close attention to entries where the “State” column indicates “LISTENING”. Note down the Process ID (PID) shown in the rightmost column for any such entries on ports 5718 or 5719. There might be entries with a foreign address and a state like “ESTABLISHED”, but you are primarily looking for a process that is listening on these specific local ports.
```
Proto  Local Address          Foreign Address        State           PID
TCP    0.0.0.0:5718           0.0.0.0:0              LISTENING       XXXX
TCP    0.0.0.0:5719           0.0.0.0:0              LISTENING       YYYY
... other entries ...
```
(Where XXXX and YYYY are the PIDs you need to identify).
- Examine tasklist.txt and svclist.txt: Once you have the PIDs from netstat.txt, open tasklist.txt first. Search for the noted PIDs. The corresponding line will show the image name (executable file name) of the process.
```
Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
... other processes ...
process_name.exe              XXXX Console                  1     50,000 K
another_process.exe           YYYY Services                   0     75,000 K
...
```
If you cannot find the PID in tasklist.txt, open svclist.txt. This file shows which services are running under a particular PID. Look for the PID here to identify the service name(s) associated with it. This is common for processes like svchost.exe which host multiple Windows services.
```
Image Name                     PID Services
========================= ======== ============================================
... other processes ...
svchost.exe                   YYYY ServiceA, ServiceB, ServiceC
...
```
In this case, if PID YYYY was listening on port 5719, the conflict is caused by one of the services (ServiceA, ServiceB, ServiceC) running under that svchost.exe instance. Further investigation might be needed to pinpoint which specific service is binding the port, potentially using tools like Process Explorer from Sysinternals, but often identifying the PID and the primary process/services is sufficient.
Identify the Conflicting Application/Service: Based on the process name or service name(s) identified in steps 3, determine which application is using the ports required by DPM. Common culprits on servers might include other backup software, monitoring agents, or specific roles like Microsoft Exchange System Attendant (as mentioned in the original KB, though this is less common in modern Exchange versions which use different ports).
Resolve the Conflict: Once the conflicting process/service is identified, you have a few options:
- Stop the Conflicting Service/Application: If the application is not critical or can be temporarily stopped, the easiest solution is to stop its service via the Services console (services.msc) or Task Manager. After stopping the conflicting process, attempt to start the DPMRA service again. If it starts, you’ve confirmed the conflict. You will then need a more permanent solution.
- Reconfigure the Conflicting Application: If possible, reconfigure the identified application to use different TCP ports that do not conflict with 5718 and 5719. This is the preferred long-term solution if the application must continue running. Consult the documentation for the conflicting application to see if its network ports are configurable.
- Uninstall or Disable the Conflicting Application: If the application is no longer needed or cannot be reconfigured, consider uninstalling it or permanently disabling its service.

Using SetAgentCfg.exe to Change DPM Agent Ports¶

In scenarios where you cannot stop, reconfigure, or remove the conflicting application, or if changing the other application’s ports is impractical, you can reconfigure the DPM agent to use alternative ports. The SetAgentCfg.exe tool is provided by DPM for this specific purpose.

Important Considerations:
* You must ensure that the new ports you assign to the DPM agent are not in use by any other application on the protected server. You can use netstat -ano again to verify the availability of potential alternative ports before using SetAgentCfg.exe.
* The DPM server must also be configured to communicate with the agent on these new ports. The SetAgentCfg.exe tool handles the necessary configuration changes on both the protected server and the DPM server automatically when run correctly.

Follow these steps to use the SetAgentCfg.exe tool:

Locate SetAgentCfg.exe: This utility is located on the DPM server. The default path is typically %PROGRAMFILES%\Microsoft DPM\DPM\Setup\SetAgentCfg.exe.
Copy SetAgentCfg.exe to the Protected Server: Copy the SetAgentCfg.exe file from the DPM server to the protected server experiencing the issue. Place it in the DPM agent’s binary directory. The default path for the agent’s binary directory is %PROGRAMFILES%\Microsoft Data Protection Manager\DPM\bin.
Open Administrative Command Prompt on Protected Server: On the protected server, open a Command Prompt window with administrative privileges.
Navigate to DPM Agent Bin Directory: Change the current directory in the command prompt to the location where you copied SetAgentCfg.exe.
```
cd "%PROGRAMFILES%\Microsoft Data Protection Manager\DPM\bin"
```
(Replace %PROGRAMFILES%\Microsoft Data Protection Manager\DPM\bin with the actual path if DPM is installed elsewhere).
Run SetAgentCfg.exe: Execute the following command. You will need to replace <port number> with the current conflicting port (either 5718 or 5719) and <alternate port number> with a new, unused TCP port you wish to assign to the DPM agent for that function. If both ports are conflicted, you would run the command twice, once for each port.
```
SetAgentCfg e dpmra <port number> <alternate port number>
```
- e: This option is used to edit the DPM agent configuration.
- dpmra: Specifies that you are configuring the DPMRA service.
- <port number>: The original DPM agent port that is causing the conflict (e.g., 5718 or 5719).
- <alternate port number>: The new, available TCP port you want the DPM agent to use instead for this function (e.g., 5720, 5721, or any other unused port above 1024).
Example: If port 5718 is in use and you want to use 5720 instead:
```
SetAgentCfg e dpmra 5718 5720
```
Example: If port 5719 is in use and you want to use 5721 instead:
```
SetAgentCfg e dpmra 5719 5721
```
Run the command for each port that is conflicted.

The tool communicates with the DPM server to update its configuration for this specific protected server, informing the DPM server to use the newly assigned ports for future communications.
Restart the DPMRA Service: After successfully running SetAgentCfg.exe for the affected ports, attempt to start the DPMRA service on the protected server.
```
net start dpmra
```
If the port conflict was the sole issue, the service should now start without error.

Resolution 2: Reserving Ports (Advanced)¶

In certain environments, particularly on servers that host services known to dynamically allocate ports (like older versions of Exchange System Attendant, or other applications that use a wide range of ephemeral ports), preventing these services from claiming ports 5718 and 5719 might be necessary. While not directly fixing a port conflict after it has happened, this resolution describes a preventative measure.

Windows operating systems use a range of ephemeral ports for outbound connections and dynamically allocated inbound listeners. You can exclude specific ports or ranges of ports from this dynamic allocation pool by configuring the registry. This ensures that the operating system reserves these ports, preventing other applications configured for dynamic port usage from binding to them.

The method to reserve ports involves modifying the Windows registry using the ReservedPorts value under the Tcpip\Parameters key.

Caution: Modifying the registry incorrectly can cause serious system issues. Always back up the registry before making changes and consider consulting Microsoft documentation or a qualified professional if you are unsure.

Open Registry Editor: Run regedit from the Run dialog or Command Prompt.
Navigate to the Tcpip Parameters Key: Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.
Create or Modify ReservedPorts Value: Look for a Multi-String Value named ReservedPorts. If it exists, modify it. If not, create a new Multi-String Value and name it ReservedPorts.
Add Port Ranges: Edit the ReservedPorts value. In the “Value data” field, enter the port ranges you want to reserve, one range per line. To reserve single ports 5718 and 5719, you would enter:
```
5718-5718
5719-5719
```
This tells the system to reserve the range consisting only of port 5718 and the range consisting only of port 5719.
Restart the Server: For the ReservedPorts setting to take effect, you must restart the protected server.

After the server restarts, the operating system will prevent other services that use dynamic port allocation from binding to ports 5718 and 5719. This should allow the DPMRA service to bind to these ports successfully upon startup, provided no application is statically configured to use these ports (in which case, Resolution 1 is still necessary).

Firewall Verification¶

Although the 10048 error points to a local port conflict, successful communication between the DPM server and the agent on ports 5718 and 5719 also requires these ports to be open in any firewalls between the two machines.

Windows Firewall: On the protected server, ensure that Windows Firewall has inbound rules allowing TCP traffic on ports 5718 and 5719 for the DPMRA process. The DPM agent installation typically configures these rules automatically, but they might be disabled or overridden by group policies or manual configuration. Verify the rules in the “Windows Defender Firewall with Advanced Security” console (wf.msc).
Network Firewalls: If there are network firewalls or other security appliances between the DPM server and the protected server, ensure that rules are in place to allow bidirectional TCP traffic on ports 5718 and 5719 between the IP addresses of the DPM server and the protected server. Consult your network security team if necessary.

Even if the DPMRA service starts after resolving the 10048 error, communication problems due to firewalls can lead to other issues, such as “Agent Unreachable” status in the DPM console or failed synchronization jobs.

Verification and Further Steps¶

After applying the resolutions (either resolving the conflicting process or reconfiguring the DPM agent ports), attempt to start the DPMRA service again.

net start dpmra

If the service starts successfully, verify communication from the DPM server by attempting to perform a task involving the protected server (e.g., running a consistency check on a protected data source).

If the service still fails to start with error 10048, re-run the netstat -ano command to ensure the ports are truly free before the DPMRA service attempts to start. There might be another process starting after your initial check that is quickly grabbing the port.

If the service starts but you experience communication issues (e.g., agent status shows as inactive or unreachable), review the Windows Event Logs on both the DPM server and the protected server for DPM-related errors or warnings. Also, verify firewall configurations meticulously.

More Information¶

Data Protection Manager relies heavily on robust network communication between the DPM server and its protection agents. TCP ports 5718 and 5719 are designated for this agent-to-server and server-to-agent communication flow, facilitating crucial operations like initial agent registration, metadata exchange, data transfer during backups (synchronization and express full backups), and coordination during recovery operations.

Historically, conflicts with services like the Microsoft Exchange System Attendant service occurred because these services sometimes utilized dynamic port ranges that could overlap with DPM’s required ports. While modern operating systems and applications are better at managing dynamic port allocation, conflicts can still arise with custom applications, third-party software, or misconfigured services.

Beyond ports 5718 and 5719, DPM utilizes several other ports for different functions, including SQL Server communication (often TCP 1433 or dynamic ports), the DPM console connection, and MSRPC endpoints. However, startup issues with the agent service specifically pointing to 10048 are almost always tied to the agent’s inability to bind to its primary communication ports (5718/5719).

Ensuring the DPM agent and the DPM server can communicate freely on their designated ports is fundamental to the reliable operation of your data protection infrastructure. Regular network health checks and clear documentation of port requirements for all applications running on protected servers can help prevent these types of conflicts.

Conclusion¶

Resolving the DPM protection agent service startup error 10048 (0x2740) is typically a straightforward process involving identifying and addressing TCP port conflicts on the protected server. By using command-line tools like netstat and tasklist, you can pinpoint the application or service blocking ports 5718 or 5719. Depending on the situation, you can either stop the conflicting process, reconfigure it, or utilize the SetAgentCfg.exe tool to instruct the DPM agent to use alternative ports. Additionally, ensuring proper firewall exceptions are in place for these ports is crucial for successful ongoing communication. Proactive measures like reserving ports can also help prevent future conflicts.

Have you encountered this specific DPM agent error? How did you resolve it in your environment? Share your experiences or ask any further questions in the comments below!

Computacionvinchi