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?

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

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 BenariMicrosoft employee, Owner Wednesday, May 12, 2010 6:07 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 BenariMicrosoft employee, Owner Wednesday, May 12, 2010 6:07 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 BenariMicrosoft employee, Owner Wednesday, May 12, 2010 6:07 PM

Hi Mister Iks,

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

Tom

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

Update.

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

     Any idea is appreciated.

Best Regards

Miguel Silva

Sounds like a routing issue to me...

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

Cheers

JJ

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
===========================================================================

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

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

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

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

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 :(

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.

Hello again...

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

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.

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.

That rule exist's on the DA Client, and is configured with allow edge transversal....

Just to be clear, Remote Assistance and Remote Desktop have different requirements for firewall rules...

Does nothing but ping

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)

Jason,

How do i get you that information?

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 

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?

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 ;)

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

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

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.

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

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

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"

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, ping, 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 1 hour 26 minutes ago

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 22 hours 27 minutes ago

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

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