none
DPM 2010 over DirectAccess RRS feed

  • Question

  • I have a DPM server at a remote site, and I want to protect a computer at my local site.  I have DirectAccess (native, not via Forefront UAG) set up and working between the two sites.  I installed the DPM Agent manually on the local computer.  I attached it from the DPM server.  I can create a Protection Group, but no data is getting transferred from the local (protected) computer to the DPM Server.

    Replica creation fails after about 7 to 8 minutes with the following message "DPM failed to communicate with protected-computer.mydomain.com because the computer is unreachable. (ID 41 Details: No such host is known (0x80072AF9))

    I can ping the protected computer (the ping replies as expected come from the protected computers IPv6 ISATAP address.  I have successfully tested DCOM from both ends using wbemtest.

    netstat -aonp tcpv6 run from the DPM server shows that the RpcEptMapper on the DPM server connects to port 135 on the protected computer, and then msdpm.exe establishes a connection to a RPC-assigned high port on the protected computer.  This connection remains established.  Meanwile, the RpcEptMapper keeps initiating more connection attempts, which get momentarily established but then revert to a TIME_WAIT state.

    Any suggestions as to what is going wrong here?

    Thanks.

    Friday, May 21, 2010 9:41 PM

Answers

  •  

    DPM will work in a pure IPv6 environment; however, if DPM has both ipv4 and ipv6 we expect the Protected Server (ps) to have IPV4 enabled, as our preferred channel is ipv4.  If some of the agents have only ipv6 enabled then we must have only ipv6 on DPM, and on all PS's. 


    There is a workaround, but it was not thoroughly tested.  If you set the following registry key, we should work in a mixed environment.

      Please note that this was not thoroughly tested in house and is not formally supported, but good for testing to see if it helps.

    Software\Microsoft\Microsoft Data Protection Manager\Agent\2.0
       PingBeforeConnect: REG_DWORD:0x1

    Regards

    Mike J.


    Regards, Mike J [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by sejong Tuesday, May 25, 2010 5:53 PM
    Tuesday, May 25, 2010 12:03 AM
    Moderator

All replies

  • Can you check the firewall settings on the protected machine to allow Edge traversal?

    Please follow the below steps to enable Edge traversal:

    From elevated prompt launch WF.msc -> Inbount Rules -> Right click and select DPMRA_DCOM_135 Propertes -> Advanced -> Allow Edge Traversel (Here change the value "Allow edge traversal" ) // Allowing Edge traversal for DCOM.

    From elevated prompt launch WF.msc -> Inbount Rules -> Right click and select DPMRA Propertes -> Advanced -> Allow Edge Traversel (Here change the value "Allow edge traversal" ) // Allowing Edge traversal for DPMRA.


    Praveen D [MSFT]
    • Proposed as answer by Praveen D [MSFT] Monday, May 24, 2010 11:06 AM
    • Unproposed as answer by sejong Monday, May 24, 2010 1:54 PM
    Monday, May 24, 2010 11:06 AM
  • Thanks for your reply.

    I enabled "Allow Edge Traversal" on proteced server on the two firewall rules you mentioned, but the problem persists; the failure error is the same - the computer is unreachable. (ID 41 Details: No such host is known (0x80072AF9).

    Some things I have observered:

    1.  If I move the DPM Server to the local subnet, data transfer proceeds normally.

    2.  The failure I have described in this threads occur if the DPM Server has a public IPv4 address (and 6to4 is used), or if the DMP Server is behind NAT router and has a private IPv4 adddres (and Teredo is used).  So the problem does not seem to be related to NAT.

    Monday, May 24, 2010 1:02 PM
  •  

    DPM will work in a pure IPv6 environment; however, if DPM has both ipv4 and ipv6 we expect the Protected Server (ps) to have IPV4 enabled, as our preferred channel is ipv4.  If some of the agents have only ipv6 enabled then we must have only ipv6 on DPM, and on all PS's. 


    There is a workaround, but it was not thoroughly tested.  If you set the following registry key, we should work in a mixed environment.

      Please note that this was not thoroughly tested in house and is not formally supported, but good for testing to see if it helps.

    Software\Microsoft\Microsoft Data Protection Manager\Agent\2.0
       PingBeforeConnect: REG_DWORD:0x1

    Regards

    Mike J.


    Regards, Mike J [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    • Marked as answer by sejong Tuesday, May 25, 2010 5:53 PM
    Tuesday, May 25, 2010 12:03 AM
    Moderator
  • Mike J.-

    I am pleased to report that your workaround worked.  Thanks. 

    For others who follow this thread, the PingBeforeConnect REG_DWORD value must be added to the protected server, not the DPM server.

    As I see it, the ability to position a DPM server offsite and, using DirectAccess, have it protect servers as if it were on the local LAN is a major advantage for small and medium businesses (SMB's) who want offsite backup.

    Tuesday, May 25, 2010 5:48 PM
  • Yes, good point, the registry entry needs to be applied on the protected server.  I'm glad to hear that resolved your issue.
    Regards, Mike J [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, May 26, 2010 12:05 AM
    Moderator
  • Follow-up:  if you want to do a recovery (from the DPM Server to the protected server) , you need to add this registry entry to the DPM Server.  The comunication and logic is just the reverse of the backup scenario.
    Friday, May 28, 2010 3:49 PM
  • Mike, we've been having the exact same issue testing DPM 2012.  Do you know if the registry value is still valid for DPM 2012?  We've made the registry change and the problem persists (PingBeforeConnect DWORD:0x1).  Also, does the DPMRA service need to be restarted for the change to take effect?  Or does the server have to be rebooted?  Just curious on the last two for future reference.  We've tried the change, rebooted, but the problem still persists with DPM 2012.

    I posted this in the DPM 2012 beta forum but nobody is responding there.


    Rob
    Tuesday, January 10, 2012 11:59 PM
  • Hi,

    No reboot or restart is required, the agent look for this key during every session.  Don't know about supported in DPM 2012, but I pinged some people to see if I can get you some help in the DPM 2012 beta forum.

     


    Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, January 11, 2012 12:25 AM
    Moderator
  • Mike, thanks.  I did a process monitor and saw the agent still reads the key.  But the problem persists so maybe something changed in 2012.  Thanks for your help and quick response!


    Rob
    Wednesday, January 11, 2012 12:41 AM
  • Mike, I posted my issue here ( http://social.technet.microsoft.com/Forums/en-US/dataprotectionmanager2012beta/thread/77872d9f-5db5-4bad-9794-70b870b5c39f) and separated it from my previous thread which also talked about an app crash with IPv6.  No one from Microsoft has responded to any of my threads for over 10 days.  In any case, I put the log into the thread.  The pingbeforeconnect seems to be read and acknowledged since it is noted in the log.  Some other errors appears to be in the agent at this point.  If you wouldn't mind pinging the DPM 2012 group I'd appreciate it.  If it is a bug, that's fine, then we can stop trying to debug it on our end.
    Rob
    Thursday, January 12, 2012 2:43 PM
  • Hi Rob,

    The product group has been made aware of your post and I suspect you will hear from them in the near future. 

    Thanks for testing dpm 2012.


    Regards, Mike J. [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, January 12, 2012 4:31 PM
    Moderator
  • Hi Mike,

    It there any further news on this issue?

    It would appear that DPM 2012 R2 still prefers to use IPv4 over IPv6!

    We are now having to use IPv6 as we can't get IPv4 - this DPM bug really needs to fixed in this day and age!

    Regards,

    Daniel

    Friday, January 17, 2014 9:42 PM
  • Hi guys, any update?

    I have exactly the same issue with DPM 2012 and direct access...

    Regards

    Maurizio

    Wednesday, December 3, 2014 11:07 AM