locked
Windows Remote Assistance and UAG DirectAccess RRS feed

  • Question

  • I want to be able to offer remote assistance to laptop users. Remote Assistance works when the laptop is on the LAN, but when the laptop is not on directly on the LAN but does have a DirectAccess connection up and running then remote assistance doesn’t work anymore.

    Does anyone have experience of getting Windows Remote Assistance running together with UAG DirectAccess?

    Saturday, May 8, 2010 10:44 AM

Answers

  • To get Remote Assistance running on Windows 7 on a laptop that has a DirectAccess tunnel active I've added the following firewall rules (GPO)

     

    135:TCP:*:Enabled:Remote Assistance (DCOM-In)
    2869:TCP:*:Enabled:Remote Assistance (SSDP TCP-In)
    1900:UDP:*:Enabled:Remote Assistance (SSDP UDP-In)
    3540:UDP:*:Enabled:Remote Assistance (PNRP-In)

    And these defined program exceptions:

    %SystemRoot%\system32\raserver.exe:*:Enabled:Remote Assistance (RA Server TCP-In)
    %SystemRoot%\system32\msra.exe:*:Enabled:Remote Assistance (TCP-In)

    For all rulles i've set "edge traversal" to "Allow"

     

    • Marked as answer by Erez Benari Wednesday, May 12, 2010 6:07 PM
    Tuesday, May 11, 2010 8:50 PM

All replies

  • Hi Mister Iks,

    Check out the UAG DirectAccess Step by Step guide - it includes that scenario.

    You need to create a firewall rule in Windows Firewall with Advanced Security to allow the connection.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Saturday, May 8, 2010 12:43 PM
  • To get Remote Assistance running on Windows 7 on a laptop that has a DirectAccess tunnel active I've added the following firewall rules (GPO)

     

    135:TCP:*:Enabled:Remote Assistance (DCOM-In)
    2869:TCP:*:Enabled:Remote Assistance (SSDP TCP-In)
    1900:UDP:*:Enabled:Remote Assistance (SSDP UDP-In)
    3540:UDP:*:Enabled:Remote Assistance (PNRP-In)

    And these defined program exceptions:

    %SystemRoot%\system32\raserver.exe:*:Enabled:Remote Assistance (RA Server TCP-In)
    %SystemRoot%\system32\msra.exe:*:Enabled:Remote Assistance (TCP-In)

    For all rulles i've set "edge traversal" to "Allow"

     

    • Marked as answer by Erez Benari Wednesday, May 12, 2010 6:07 PM
    Tuesday, May 11, 2010 8:50 PM
  • Hi Mister Iks,

    Very good! Good to hear you got it working and thanks for the follow up!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Wednesday, May 12, 2010 11:20 PM
  • Hi all,

         Im having this problem also. I already configured a group policy with the rules tha Mister Iks, they are applied succefully on the direct access client.

         The Direct Access Client connects without a problem to the network, can access all the resources, can remote desktop and remote assistance to any client on the LAN, but we cannot remote desktop to it. What can i check more?

    Please help, im looping here....

     

    Thank you

    Miguel Silva

    Thursday, May 20, 2010 10:22 AM
  • Update.

         I can access clients from the UAG/Direct Access server....but no other machine.

         Any idea is appreciated.

    Best Regards

    Miguel Silva

    Thursday, May 20, 2010 4:46 PM
  • Sounds like a routing issue to me...

    Can you provide a "route print" of your IPv6 routing table?

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, May 20, 2010 10:45 PM
  • The route print from the DA client

    IPv6 Route Table
    ===========================================================================
    Active Routes:
     If Metric Network Destination      Gateway
     15    286 ::/0                     fe80::5efe:172.28.0.68
      1    306 ::1/128                  On-link
     15   4126 2002::/16                fe80::5efe:172.28.0.68
     15    286 2002:3e1c:49a1::/64      fe80::5efe:172.28.0.68
     15     38 2002:3e1c:49a1:8000::/49 On-link
     15     38 2002:3e1c:49a1:8000::/64 On-link
     15    286 2002:3e1c:49a1:8000:0:5efe:172.28.2.30/128
                                        On-link
     15    286 2002:3e1c:49a1:8100::/64 fe80::5efe:172.28.0.68
     15    286 2002:3e1c:49a2::/64      fe80::5efe:172.28.0.68
     11    281 fe80::/64                On-link
     15    286 fe80::5efe:172.28.2.30/128
                                        On-link
     11    281 fe80::1492:ddbc:f6fa:5eab/128
                                        On-link
      1    306 ff00::/8                 On-link
     11    281 ff00::/8                 On-link
    ===========================================================================
    Persistent Routes:
      None

     

    From the UAG / DirectAccess

    IPv6 Route Table
    ===========================================================================
    Active Routes:
     If Metric Network Destination      Gateway
     16   1105 ::/0                     2002:c058:6301::c058:6301
      1    306 ::1/128                  On-link
     17     58 2001::/32                On-link
     16   1005 2002::/16                On-link
     16    261 2002:3e1c:49a1::/64      On-link
     16    261 2002:3e1c:49a1::3e1c:49a1/128
                                        On-link
     19    261 2002:3e1c:49a1:8000::/49 On-link
     19    261 2002:3e1c:49a1:8000::/64 On-link
     19    261 2002:3e1c:49a1:8000::/128
                                        On-link
     19    261 2002:3e1c:49a1:8000:0:5efe:172.28.0.68/128
                                        On-link
     19    261 2002:3e1c:49a1:8001::/96 On-link
     20    306 2002:3e1c:49a1:8100::/64 On-link
     20    306 2002:3e1c:49a1:8100::/128
                                        On-link
     20    306 2002:3e1c:49a1:8100:d00c:75be:f00e:5015/128
                                        On-link
     16    261 2002:3e1c:49a2::/64      On-link
     16    261 2002:3e1c:49a2::3e1c:49a2/128
                                        On-link
     15    261 fe80::/64                On-link
     14    261 fe80::/64                On-link
     17    306 fe80::/64                On-link
     20    306 fe80::/64                On-link
     19    261 fe80::5efe:172.28.0.68/128
                                        On-link
     18    261 fe80::200:5efe:62.28.73.161/128
                                        On-link
     18    261 fe80::200:5efe:62.28.73.162/128
                                        On-link
     17    306 fe80::8000:f227:c1e3:b65e/128
                                        On-link
     15    261 fe80::8926:d123:5a89:cee9/128
                                        On-link
     14    261 fe80::b1dc:720a:74af:a81a/128
                                        On-link
     20    306 fe80::d00c:75be:f00e:5015/128
                                        On-link
      1    306 ff00::/8                 On-link
     20    306 ff00::/8                 On-link
     17    306 ff00::/8                 On-link
     15    261 ff00::/8                 On-link
     14    261 ff00::/8                 On-link
    ===========================================================================
    Persistent Routes:
     If Metric Network Destination      Gateway
      0 4294967295 2002:3e1c:49a1::/64      On-link
      0 4294967295 2002:3e1c:49a2::/64      On-link
      0 4294967295 2002:3e1c:49a1:8000::/64 On-link
      0 4294967295 2002:3e1c:49a1:8001::/96 On-link
      0 4294967295 2002:3e1c:49a1:8000::/49 On-link
      0 4294967295 2002:3e1c:49a1:8100::/64 On-link
    ===========================================================================

    Friday, May 21, 2010 8:37 AM
  • Where are you trying to manage from?

    Is this IPv6 capable and configured? The NAT64 element of UAG is inbound only, so for "manage out" you need IPv6 connectivity (ISATAP is ok).

    What is the IPv6 routing table on that machine (sorry should have been specific above)?

    Can you resolve client names to their correct IPv6 address when DA connected?

    If you need to manage a machine when the user is not logged on, you will need to add the management machines to the management servers list in the DA wizard so they can use the infrastructure tunnel. If they user is logged in, you can connect from any IPv6 capable machine via the intranet tunnel (assuming it has the correct routing).

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Friday, May 21, 2010 10:55 AM
  • Hi,

    Thanks for the reply.

    Im trying to acces from a windows 7 client (in this case a laptop), that has IPv6 enabled.

    I can resolve names of DA clients without a problem, they register automatically in dns when connect.

    I added a server (for testing proposes) to the management servers in UAG/Direct Access, but even from there i cant access the DA client.

    The server is a 2008 R2. It can ping the DA client without a problem but cannot RD to it.

    What is the correct routing for the intranet tunnel?

    The Routing IPv6 table from the laptop i use to try and access the DA client

    IPv6 Route Table
    ===========================================================================
    Active Routes:
     If Metric Network Destination      Gateway
     13    281 ::/0                     fe80::5efe:172.28.0.68
      1    306 ::1/128                  On-link
     13   4121 2002::/16                fe80::5efe:172.28.0.68
     13    281 2002:3e1c:49a1::/64      fe80::5efe:172.28.0.68
     13     33 2002:3e1c:49a1:8000::/49 On-link
     13     33 2002:3e1c:49a1:8000::/64 On-link
     13    281 2002:3e1c:49a1:8000:0:5efe:172.28.24.31/128
                                        On-link
     13    281 2002:3e1c:49a1:8100::/64 fe80::5efe:172.28.0.68
     13    281 2002:3e1c:49a2::/64      fe80::5efe:172.28.0.68
     12    276 fe80::/64                On-link
     13    281 fe80::5efe:172.28.24.31/128
                                        On-link
     12    276 fe80::5828:fcad:7b30:babe/128
                                        On-link
      1    306 ff00::/8                 On-link
     12    276 ff00::/8                 On-link
    ===========================================================================
    Persistent Routes:
      None

     

    The IPv6 routing table of the server in Direct Acces Management Servers that i use to test the Remote Desktop connection

     

    IPv6 Route Table
    ===========================================================================
    Active Routes:
     If Metric Network Destination      Gateway
     12    266 ::/0                     fe80::5efe:172.28.0.68
      1    306 ::1/128                  On-link
     12   4106 2002::/16                fe80::5efe:172.28.0.68
     12    266 2002:3e1c:49a1::/64      fe80::5efe:172.28.0.68
     12     18 2002:3e1c:49a1:8000::/49 On-link
     12     18 2002:3e1c:49a1:8000::/64 On-link
     12    266 2002:3e1c:49a1:8000:0:5efe:172.28.7.46/128
                                        On-link
     12    266 2002:3e1c:49a1:8100::/64 fe80::5efe:172.28.0.68
     12    266 2002:3e1c:49a2::/64      fe80::5efe:172.28.0.68
     15    261 fe80::/64                On-link
     12    266 fe80::5efe:172.28.7.46/128
                                        On-link
     15    261 fe80::f102:581e:dc18:77e0/128
                                        On-link
      1    306 ff00::/8                 On-link
     15    261 ff00::/8                 On-link
    ===========================================================================
    Persistent Routes:
      None

    Friday, May 21, 2010 11:31 AM
  • Are the DA clients using teredo or IP-HTTPS? (sorry for all the question, just trying to home in quickly!) 
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Friday, May 21, 2010 12:01 PM
  • Teredo....IPHttps is not working.
    Friday, May 21, 2010 12:05 PM
  • Ok bit of a guess as I've not used ISATAP a lot, but can you try adding the following static route:

    add route 2001::/32 <Network Interface Name> <IPv6 Address of UAG>

    which I think in your case will be:

    add route 2001::/32 <Network Interface Name> 2002:3e1c:49a1:8000:0:5efe:172.28.0.68

    I don't believe this should be necessary as the default IPv6 route should ensure that intranet ISATAP hosts can reach DirectAccess clients, but you can easily remove it if not...

    Cheers

    JJ

     


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Friday, May 21, 2010 12:18 PM
  • If you have enabled ISATAP (and I assume that you have if you don't have a native IPv6 network), then the UAG DA server is going to be the ISATAP router for your network, and the one that the management computers on your network will use to access the DirectAccess clients for management.

    The WFAS rules required to allow "manage out" RDP connections to the DirectAccess client require that you also enable Edge Traversal on the rules.

    The best way to get experience with the configuration is to go through the UAG DirectAccess Test Lab Guide, over at http://technet.microsoft.com/en-us/library/ee861167.aspx

    You'll see that Step 13 includes details on how to configure for "manage out"

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Friday, May 21, 2010 12:33 PM
  • Thanks Tom - it sounded like the OP has done everything necessary as it works from the UAG server itself. This implies there is something wrong with traffic flow from the management machine to the DA client via the UAG ISATAP router...any ideas?

    I think my advice was better placed for a native IPv6 environment :(


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    Friday, May 21, 2010 12:42 PM
  • Thank you all for your repplies.

    I cant test the feed back from Jason Jones today, but i will try it has soon has possible and get back to you with feedback.

     

    Friday, May 21, 2010 1:26 PM
  • Hello again...

     

    Just try it but didnt work. Still dont know what to do....

    Monday, May 24, 2010 4:30 PM
  • Do you see any traffic in the TMG logs when the management client tries to connect to the DA client?
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Monday, May 24, 2010 10:58 PM
  • Wich traffic should i log?

    I tried to log, the DA client name (FQDN).

    The FQDN from the remote management server.

    The RDP protocol, etc...

    No traffic is shown in TMG of UAG...

    I did a Tracert from the Management Server and i got this reply:

     1    <1 ms    <1 ms    <1 ms  2002:3e1c:49a1:8000:0:5efe:172.28.0.68 (UAG)
     2   122 ms   114 ms   108 ms  2001:0:3e1c:49a1:4c8:1ffb:b2c9:da48 (DA client)

    It can access the DA client but cant Remote desktop. The DA client has the firewall rules enabled correctly.

    Tuesday, May 25, 2010 11:10 AM
  • Hi,

    Did you try Tom's suggestion regardig edge traversal?

    You should create an inbound firewall rule on the client that allows the RDP protocol on the public profile. Open the properties of this firewall rule, and under advanced you have to allow edge traversal.

    This is a must for all scenarios where you are initiating traffic from inside the organization to a DirectAccess client.

    Tuesday, May 25, 2010 2:17 PM
  • That rule exist's on the DA Client, and is configured with allow edge transversal....

    Tuesday, May 25, 2010 3:10 PM
  • Just to be clear, Remote Assistance and Remote Desktop have different requirements for firewall rules...

    Does nothing but ping work?


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, May 25, 2010 3:42 PM
  • I know it is painful, but can you screenshot your firewalls settings in detail? You could use something like PSR.EXE to make it easier and you can click on every setting before outputting to a single MHT file.
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, May 25, 2010 3:49 PM
  • Also, this firewall rule should be a rule that you created, and not a built-in firewall rule that you enabled edge traversal on.

    In this rule you can specify the remote endpoint as your corporate IPv6 prefix. (if using ISATAP, it will be 2002:xxxx:xxxx:8000::/49)

    Tuesday, May 25, 2010 5:06 PM
  • Jason,

    How do i get you that information?

    Wednesday, May 26, 2010 9:59 AM
  • Hi,

    I have uploaded some screenshots for WFAS from one of my blog labs to here:

    http://cid-a2e64de91bfcad09.skydrive.live.com/self.aspx/.Public/WFAS%20Screenshots%20for%20Forums.pdf

    Try comparing these to your own rules and/or create new ones to mirror mine.

    Note: You will need to update the IPv6 prefix in the scope to be relevant for your environment, not mine.

    I will be adding this type of info to a future blog post in my 'Path to DirectAccess' series, so they are handy screenshots for me anyhow ;)

    Cheers

    JJ 


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Wednesday, May 26, 2010 2:24 PM
  • Hi Jason,

    I created the rules in GPO and applied them to the DA client. No luck....they are exacly the same has yours...:(.

    I can access from the UAG/Direct Access server but no where else....

    With this test can we say for sure that the problem isnt in the client firewall?

    Thursday, May 27, 2010 2:55 PM
  • I guess so...those rules work in my lab and also in my production setup :(

    TBH I am running out of ideas now...if PING works, you must have correct routing to the DA client via UAG. If remote tools work from UAG you must have the firewall rules correct to access local client services...

    Very weird :(

    Hopefully Tom/Yaniv have some more ideas, cos i'm on empty ;)


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, May 27, 2010 3:05 PM
  • When i solve this issue i will send you a bottle of champaigne for your hard working and help...:D

    Thank you for trying. :D

    Thursday, May 27, 2010 3:25 PM
  • Hi Moreifi,

    Check the Windows Firewall with Advanced Security console and confirm that the new firewall settings are being applied to the clients.

    To which GPO are you applying these firewall rules?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Thursday, May 27, 2010 3:33 PM
  • I already check it, they are applied succefully. The GPO is a new GPO that i have created to apply these rules to DA clients only.
    Thursday, May 27, 2010 3:38 PM
  • Moreirfi,

    can you also make sure the firewall rules you created are active? You can do that by looking in Windows Firewall with Advanced Security, under Monitoring\Firewall. If the rules that you created also exist there, then it means they're active.

    We've seen some cases where the windows firewall was configured to allow all inbound traffic by default, but this actually blocked traffic since the "default allow" rule doesn't allow edge traversal.

    Anyway, if that doesn't help, you can always run netsh wfp capture start on the client, and look at the XML :) It will tell us exactly which firewall filter is dropping the traffic.

     

    Thursday, May 27, 2010 3:51 PM
  • Hi,

    The rules are all in Monitorin\firewall.

    netsh wfp capture start shows these errors several times...


    ERROR_IPSEC_IKE_QM_ACQUIRE_DROP

    ERROR_IPSEC_IKE_QUEUE_DROP_MM

    ERROR_IPSEC_IKE_QUEUE_DROP_NO_MM

    ERROR_IPSEC_IKE_DROP_NO_RESPONSE

    ERROR_IPSEC_IKE_MM_DELAY_DROP

    ERROR_IPSEC_IKE_QM_DELAY_DROP

    ERROR_IPSEC_IKE_ERROR

    ERROR_IPSEC_IKE_CRL_FAILED

    ERROR_IPSEC_IKE_INVALID_KEY_USAGE

    Thursday, May 27, 2010 4:49 PM
  • Did this ever get fixed?  How?
    Thursday, June 16, 2011 3:17 PM
  • Hello everyone,

           My problem was fixed, but i cant tell you what it was, but i can tell you what i did:

           I installed SP1 for UAG and the SP1 update 1

           Installed all updates to TMG (at this time until SP1 rollup 4)

           Then i follow this site: http://blogs.technet.com/b/edgeaccessblog/archive/2010/09/14/how-to-enable-remote-desktop-sharing-rds-rdp-from-corporate-machines-to-directaccess-connected-machines.aspx

           After that all worked just fine. im able to connecto through Remote Assistance and remote desktop to my direct access clients.

    Hope it helps someone

    Wednesday, July 27, 2011 9:19 AM
  • To get Remote Assistance running on Windows 7 on a laptop that has a DirectAccess tunnel active I've added the following firewall rules (GPO)

    135:TCP:*:Enabled:Remote Assistance (DCOM-In)
    2869:TCP:*:Enabled:Remote Assistance (SSDP TCP-In)
    1900:UDP:*:Enabled:Remote Assistance (SSDP UDP-In)
    3540:UDP:*:Enabled:Remote Assistance (PNRP-In)

    And these defined program exceptions:

    %SystemRoot%\system32\raserver.exe:*:Enabled:Remote Assistance (RA Server TCP-In)
    %SystemRoot%\system32\msra.exe:*:Enabled:Remote Assistance (TCP-In)

    For all rulles i've set "edge traversal" to "Allow"


    This also seems to work for single NIC Server 2012 DA situations - add the Remote Desktop application and you have remote access. Nice!
    Tuesday, January 15, 2013 12:36 AM
  • Hi,

    Has anyone actually offered Remote Assistance to a DA Client successfully?  I have tried all suggestions in this thread, installed Hotfix KB2912883, and followed steps in blog http://goo.gl/TTJJj7.  We just get "Your offer to help could not be sent".

    Every other Manage Out connections works fine.  Indeed Remote Assistance works fine using the invitation method, just not when offered from an internal host (msra /offerra).  As a test, I have opened the DA Client firewall wide open.  Windows Firewall allows all inbound traffic.  Nothing blocked in WF log.  We only use IPHTTPS, so no Edge Traversal is needed.  We can ping, RDP, VNC, telnet on ports 3389 and 135, etc.  Just not offer RA.

    We have ticked "Allow this computer to be controlled remotely".

    Our DA Clients are on a 2002:: IPv6 address, so according to Hotfix KB2912883, it should fix this scenario.  It does not.

    Any other suggestions, or should I raise this as a bug with PSS?

    Many thanks







    • Edited by Calliper Wednesday, January 28, 2015 1:26 PM
    Wednesday, January 28, 2015 10:21 AM
  • Hi! We are experiencing exactly the same issue as Calliper lists above. Was this problem ever resolved?
    Monday, December 18, 2017 1:58 PM