none
Microsoft Documentation Wrong! DMPRA and Agent coordinator ports 5718 and 5719 RRS feed

  • Question

  • Having problems with a new vanilla install.

    MS documentation says that port 5718 is used by the Agent coordinator service and 5719 for the DMPRA agent

    Not on my system it aint!

    I see another similar thread here where the ports are swapped around claiming the documentation is wrong.

    I find it hard to believe but if I manually install the DPMRA agent on a protected server it listens on port 5718 and not 5719 as suggested. Verified using NETSTAT -a and using the current agent installer

    Procedure used to install agent on protected sever.

    1. On the server to be protected and logged on as administrator Turn firewall off (NB I have actually created all of the rules beforehand) then Open a CMD prompt and run as admin

    2. Map a drive say X:\ to the folder on the DPM server where the current agent installation files are

    3. CD X:\

    4> In command prompt run the following

    DPMAgentInstaller_KB2963543_AMD64.exe DPMServer

    Files are copied locally and the install completes successfully. I can see the DPM groups and the DMPRA service is listed.

    HOWEVER I see no mention of the agent coordinator service and this is not installed as a service

    NETSTAT -a shows the port 5718 listening with the PID for dmpra.exe

    NETSTAT -a run on the DPM server shows both 5718 and 5719 listening

    Trying to add the protected server on the DPM server as an agent attach install for the domain fails with error :270 - cannot connect to the agent coordinator

    I have checked dcom permissions. I have verified the protected server can open up channels to the DPM server. I can telnet on port 5718/5719 in both directions. I can see dynamic RPC connections at both ends. I have tested the WMI connections All OK.

    What am I missing? Is this a bug?

    I am running Server 2012 R2 on the server to be protected. I am running Server 2012 on the DPM server which is DPM 2012 R2 with rollup 2.

    Any assistance gratefully received


    prd

    Wednesday, June 25, 2014 7:28 PM

Answers

  • Hi,

    If you perform a manual installation of the agent using DPMAgentInstaller_x64.exe <DPMSERVERNAME> - then the coordinator service is not needed.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, June 25, 2014 9:34 PM
    Moderator
  • After 3 long days trying everything I could think of and following all of the excellent guidance out there ( thanks guys) I have a workaround.

    The answer was to make the dpm server computer account a member of the domain admins group.

    After I restarted the DPM server I saw that although the protected server account was still in error - the error message changed from 270 to 316.

    So I then add the protected server computer account to the domain admins group

    After I restarted the computers I could see the magic OK in the status of the DPM console.

    As an experiment I removed the protected servers computer account from domain admins and restarted the server. After the restart DPM could no longer communicate with error 316 again.

    So I tried adding the DPM server computer account to the protected servers local administrators group but this did not work.

    Deeply unhappy with making a computer account a member of domain admin group but it works.

    The question is why? There is obviously a security permissions issue that does not affect domain admins.

    I am running this on freshly built servers on a simple, single domain. Microsoft you need to look into this.


    prd

    Thursday, June 26, 2014 8:34 PM

All replies

  • Can anyone tell me if you perform a manual install on a protected server then you expect that protected server to be listening on both 5718 and 5719?

    Or do you only expect the DPMRA service to be listening on port 5718?

    Similarly after I install the manual method the agent coordinator service is removed from services panel

    My issue is that installing the manual method removes the agent coordinator service that listens on port 5719 so that the server only listens on 5718. This is verified on the protected server using NETSTAT -a.

    I am unable to add the server by attach method in DPM console and get error :370


    prd

    Wednesday, June 25, 2014 2:56 PM
  • Hi,

    Both 5718 and 5719 are used by DPM, the ports are required for these various operations.

    1) New agent installations from DPM Server.
    2) Agent upgrades (on servers that already have the agent installed)
    3) Agent communication for backups and restores.

    If you want to push agents to protected servers that have firewalls enabled, add the rules in the below article. 

    System Center Data Protection Manager 2012 agent installation fails with error 319


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, June 25, 2014 8:43 PM
    Moderator
  • Thanks for responding Mike Yes I have followed that error 319 doc. It does not help me. What is really puzzling me is that in that article the paths in the article don't exist! There is no such directory as it is in program files. Netsh advfirewall firewall add rule name="Microsoft System Center 2012 R2 Data Protection Manager" dir=in program="C:\Microsoft Data Protection Manager\DPM\bin\msdpm.exe" profile=Any action=allow Still I followed the article but I still have the situation where the agent coordinator service is not installed on the protected server and nothing is listening on port 5719. The MS documentation states that port 5718 is used by the agent coordinator service and that 5719 is used by dpmra - this is not the case and is confusing. Can you please confirm that if I run the installer on the protected server then it should install both the agent coordinator and dpmra services and that both 5718 and 5719 should be listening

    prd

    Wednesday, June 25, 2014 9:28 PM
  • Hi,

    If you perform a manual installation of the agent using DPMAgentInstaller_x64.exe <DPMSERVERNAME> - then the coordinator service is not needed.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, June 25, 2014 9:34 PM
    Moderator
  • Still not working.I have followed the  troubleshooting article "Data Protection Manager Agent Network Troubleshooting" checked absolutely everything and I am still getting error 270 when I try to add the protected server via the DPM console on the DPM server. It seems to add but when I refresh a couple of times it gives this error 270.

    I have enabled firewall logging and can see communications between the dpm server and the protected server - none of the packets are dropped. I cannot see any traffic on ports 5718/5719.

    I do see 135,137, 138, 445, various RPC dynamic ports

    Really stuck on this and need some help please


    prd

    Thursday, June 26, 2014 3:16 PM
  • After 3 long days trying everything I could think of and following all of the excellent guidance out there ( thanks guys) I have a workaround.

    The answer was to make the dpm server computer account a member of the domain admins group.

    After I restarted the DPM server I saw that although the protected server account was still in error - the error message changed from 270 to 316.

    So I then add the protected server computer account to the domain admins group

    After I restarted the computers I could see the magic OK in the status of the DPM console.

    As an experiment I removed the protected servers computer account from domain admins and restarted the server. After the restart DPM could no longer communicate with error 316 again.

    So I tried adding the DPM server computer account to the protected servers local administrators group but this did not work.

    Deeply unhappy with making a computer account a member of domain admin group but it works.

    The question is why? There is obviously a security permissions issue that does not affect domain admins.

    I am running this on freshly built servers on a simple, single domain. Microsoft you need to look into this.


    prd

    Thursday, June 26, 2014 8:34 PM
  • The article referenced is incorrect. The netsh commands point to a non-existent directory. They should read as

    Netsh advfirewall firewall add rule name="Microsoft System Center Data Protection Manager" dir=in program="C:\Program Files\Microsoft Data Protection Manager\DPM\bin\msdpm.exe" profile=Any action=allow
    Netsh advfirewall firewall add rule name="Microsoft System Center Data Protection Manager Replication Agent" dir=in program="C:\Program Files\Microsoft Data Protection Manager\DPM\bin\dpmra.exe" profile=Any action=allow
    Netsh advfirewall firewall add rule name="Microsoft System Center Data Protection Manager DCOM setting" dir=in action=allow protocol=TCP localport=135 profile=Any
    Netsh advfirewall firewall set rule group="@FirewallAPI.dll,-28502" new enable=yes
    Netsh advfirewall firewall add rule name="DPMAM_WCF_SERVICE" dir=in program="C:\Program Files\Microsoft Data Protection Manager\DPM\bin\AMSvcHost.exe" profile=Any action=allow
    Netsh advfirewall firewall add rule name="DPMAM_WCF_PORT" dir=in action=allow protocol=TCP localport=6075 profile=Any


    prd

    Friday, June 27, 2014 1:12 PM
  • Hi,

    Thanks - not sure how that got munged - will get it updated as soon as possible.


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, June 27, 2014 3:33 PM
    Moderator
  • Hi Mike and co.

    There's another angle to this. Firewall rules are missing.

    The article "Configuring firewalls" at http://technet.microsoft.com/en-us/library/hh757794.aspx states that ports 5718 and 5719 are used by DPM, including DPM 2012 R2. So, since these ports are needed, why are there not created any Windows Firewall Exceptions for these, in Windows firewall? Not on the DPM server, not on the protected server. I see this on my new 2012 R2 installations.

    Do we need to create rules manually for 5718/5719?

    Best regards, 

    Thomas

    Thursday, July 3, 2014 10:53 AM
  • Hi Thomas When you manually install the DPMRA agent it does creat some rules. However you do need to open both 5718 and 5719. The dpmra service listens on port 5718. Did you have trouble installing the agent coordinator from the dpm server console? Apparently although it failed on my system it did actually install the agent coordinator service but not dpmra. When I manually installed dpmra this worked but note that this manual install automatically removes the agent coordinator service fron the protected server which threw me for a while.

    prd

    Thursday, July 3, 2014 11:28 AM
  • Hi,

    The ports 5718 an 5719 are covered by the DPMRA rule which opens ALL ports for the dpmra.exe program.

    C:\Program Files\Microsoft Data Protection Manager\DPM\bin>setdpmserver -dpmservername dpmlib2
    Configuring dpm server settings and firewall settings for dpm server =[dpmlib2]
    Configuring dpm server settings and firewall settings for dpm server =[Contoso.com\DPMLIB2]

    The following firewall exceptions has been added:
            - Exception for DPMRA.exe in all profiles.
            - Exception for Windows Management Instrumentation service.
            - Exception for RemoteAdmin service.
            - Exception for DCOM communication on port 135 (TCP and UDP) in all profiles.
    Configuration completed successfully!!!


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.

    • Proposed as answer by Thomas Makro Friday, July 4, 2014 12:42 PM
    Thursday, July 3, 2014 2:55 PM
    Moderator
  • Hi guys.

    Mike, thank you very much. I see what you mean, so that explains it.

    Thank you.

    Best regards, Thomas

    Friday, July 4, 2014 12:41 PM
  • Did you have trouble installing the agent coordinator from the dpm server console? Apparently although it failed on my system it did actually install the agent coordinator service but not dpmra. 

    Hi Peter.

    Forgive me if this is irrelevant, but just to clarify: On my DPM 2012 R2, there's no agent coordinator service on the protected server. That service is only on the DPM server itself. 

    I had no problems installing DPMRA in my test environment. Here, DPMRA push-install works fine.

    However, in the live environment I'm currently working with, push install doesn't work. It's a rather secure environment, so something else than DPM ports hinder push installations. Instead I install DPMRA manually on the protected servers, and attach them in DPM.

    Best regards, Thomas

    Friday, July 4, 2014 12:53 PM
  • Hi Thomas In my dpm 2012r2 environment the push install from the dpm server failed. However it did install the agent coordinator service on the protected server so the first part of the push install worked. The agent coordinator service is automatically removed by the dpmra install but because the push install did not complete successfully dpmra was not installed. So I installed manually which worked but when I tried to add the protected server to the dpm console it failed repeatedly. After a lot of troubleshooting work which was not uncovering the cause I decided to try an extreme step of adding the computer account of the protected server and also the dpm server to the domain admins group before adding via dpm console - this worked. It seems that there is a permission required by dpm in active directory and that by adding the computer accounts to domain admins group it was able to work properly. This is not satisfactory. Perhaps someone can identify exactly what ad permissions are required for the computer accounts for this to work. I expected the software install to take care of issues like this. It took me three days to resolve this issue and believe me I am deeply unhappy having to make computer accounts a member of domain admins. I did actually remove the protected server from dpm. Then taking away membership of domain admins before trying to add it back in -this failed so I put the computer account back into domain admins and tried adding it in dpm - this worked

    prd

    Friday, July 4, 2014 2:26 PM
  • Hi Peter.

    I've never heard of that before. I agree with you, that's not safisfactory.

    I'm not sure it's of relevance here, but my experiences regarding DPMRA permissions are:

    On the protected computer, local administrator permissions are needed for the install, as for most other installations. No surprise here.

    On the DPM server, the attach procedure requires local admin permissions. That's no surprise either, as it's a change in DPM. However, this attach procedure, for some annoying reason, also requires local admin permissions on the protected server. I don't see why that's neccessarry, as all DPMRA configurations on the protected server, are performed when DPMRA is installed using the proper command line switches.

    Best regards, Thomas

    Monday, July 7, 2014 7:07 AM