So I have Windows Server 2012 set up with DirectAccess (single NIC config, behind NAT, using IPHTTPS).  Everything works over Direct Access except for Remote Assistance.  I can ping/RDP to the DA clients, and they can ping me back, access file shares, etc.

So what is wrong with Remote Assistance?  I've been looking at exactly what happens when I offer Remote Assistance (RA) to a client - My machine makes a connection to port 135 on the DA client, telling it to initiate a RA request using raserver.exe, to my computer.  This works, and raserver.exe from the DA computer provides my machine with a list of all the IP addresses the DA client has - one of these is indeed the IPHTTPS IPV6 address that I can ping/RDP to.

However, on the DA client machine...the msra.exe process is only listening on the link-local IP from the IPHTTPS interface, not the "proper" IPV6 address.  And so Remote Assistance times out, as my machine attempts to talk to the DA client on each IP/port that the raserver.exe  process from the DA client has provided.  I have been struggling with this for quite some time now, and as far as I can see, the msra process will never listen to the non link-local IPV6 IP on the IPHTTPS interface, meaning that Remote Assistance will never work.

Can anyone throw me some idea of how to get this to work?

Hi,

Thank you for the post.

You may create firewall rule to allow RA access as per:http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/ac17fd54-fc87-44af-b399-9aeacbba7e14/

Regards,

Nick,

I've seen that thread, and read through all of the UAG/DA guides.  However, those pertain to using UAG with DA on 2008R2.  I already have those firewall rules set up and in place.  Everything works except for Remote Assistance.

My problem is that MSRA.exe on the DA client computer is only listening on its Link-Local (fe80::) IPv6 address from IPHTTPS.  Of course, my manage out client cannot connect to that link-local address.  Again, to reiterate:  if the MSRA process isn't listening on the proper IP...no matter what the firewall rules are, RA isn't going to work, right?

Here is how I see the process occur:

I offer RA from my (ISATAP, internal to the domain) computer to the DA client.

My MSRA process successfully connects to TCP 135 on the DA client computer.

The DA client computer starts raserver.exe, which successfully connects to my computer.

My computer attempts to connect to the DA client on its IPv6 address, but MSRA is only listening on the link-local address, and so the connection fails.

I've seen no one claim successful use of RA over a Windows 2012 DA - only tons of people saying how to do it via 2008 R2 DA and UAG.

Just hit this issue myself - did you find a solution that works?

As of yet, no.  I suspect that there is a fundamental problem in the MSRA process such that it will not listen on non-link-local IPv6 addresses from IPHTTPS, although I can't imagine why that would be.  It will listen on Teredo.  Turning Teredo off, still the same problem.

Glad to have some confirmation that it isn't just us though.  I think we need to put a call in the MS Pro Support - I just haven't had the time.  I will update this thread with an answer if I get one - please do the same.

I did some hunting myself and went to this link:

http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/ac17fd54-fc87-44af-b399-9aeacbba7e14/

I created a GPO utiling the rules as specifed in the 'answer' post and applied it to the DA computers group (also added Remote Desktop for good measure) and it seems to work, from the DA server at least - I was able to establish a RA session (unsolicited Remote Assistance) to my own computer from this server and open it successfully, and a Remote Desktop session too. Needs more testing still but looks pretty sound.

NB: I'm single NIC Server 2012 DA server running behind a firewall, no UAG/TMG in use. WIndows 7 enterprise clients.

I take that back - really hit and miss - sometimes works, mostly does not.

• Edited by healthyCamper Wednesday, January 23, 2013 2:37 AM

RDP works just fine, it is only RA that I have a problem with.

It will work from the DirectAccess server, as it shares a link-local subnet with the client...but try from a machine inside your network, with ISATAP enabled.

You should be able to ping the DA client, RDP to it (these all work), but I cannot get Remote Assist to work.

RDP works just fine, it is only RA that I have a problem with.

It will work from the DirectAccess server, as it shares a link-local subnet with the client...but try from a machine inside your network, with ISATAP enabled.

You should be able to ping the DA client, RDP to it (these all work), but I cannot get Remote Assist to work.

I have exactly the same problem with RA.

Please can someone from MS confirm this is an issue and advise when a fix will be available.

Thanks

I have also this problem.

Is this a limitiation of single NIC DA2012, bug or something is not configured correctly?

Thanks.

Still not working for me and no response from MS - I thought they monitored this forum?

Same problem here, windows 2012 directaccess single nic setup, windows 8 enterprise clients, ip-https connection, everything works from client side, from server side everything is ok except remote assistance. All firewall rules are in place, i can remote desktop to clients, access file shares but remote assistance finds the client via computer name, starts session but then times out. Sometimes i get notification on client that someone tries to help me but that i already have remote assistance session running in background. Can someone from Microsoft please confirm that this is a problem/bug or give us resolution?

Thanks.

  

This is a known issue with Remote Assistance and IPv6...blog post should be out soon, but contact me offline if urgent

At my client we are currently in the proces of troubleshooting this same issue as well with help of Microsoft support.

To give you an idea, we have a dual nic, two server w2012 array behind an internal and external loadbalancer. ISATAP router is on a 3rd server. Clients can only use IP-HTTPS to connect to the corporate infrastructure. Everything works from a client perspective, managed-out also works properly (RDP, SMB etc) except for Remote Assistance.

What appears to be the issue in our case is in the DA client IPv6 Prefix we assign. We had decided to assign addresses from a prefix starting with FD47 to the DA clients. As mentioned, everything works, except remote assistance. So far it has been confirmed that the RDP code ignores any Ipv6 address starting with F. Msra uses the RDP code in the background, causing the remote assistance connection to fail.

I will keep you posted on our findings further on.

• Proposed as answer by Jason Jones [MSFT]Microsoft employee Friday, July 12, 2013 3:53 PM

My knowledge comes from Roshan, the support engineer covering that case I believe...this is my understanding based upon discussions with Roshan.

The problem lies within the RA code itself, not DA, as described below:

The root cause of the problem is that the IP-HTTPS IPv6 address of the DA client is not included in the list of available IP addresses sent to the RA client for the remote DA client. This happens only when using the IPv6 prefix FDXX:XXXX that is included with Windows Server 2012 DA when generating the IP-HTTPS IPv6 prefix (based upon RFC4193 I believe). The problem occurs because the RA client rdpcore.dll that builds this list of IPs has a check in place such that it would only include IPv6 addresses that start with 2 (Global) or with FE (link local). Hence the attempt made by the management client is made directly on the IPv4 address of the DA Client (which obviously wont succeed) and not the IP-HTTPS FDXX style IPv6 address.

Until the problem is fixed in the RA client, the only workaround at this time is to change the IP-HTTPS IPv6 prefix used on the DA clients so that the RA client can return a global (starting with 2) IPv6 address, not the IPv4 one.

The problem doesnt occur with UAG DA as this wasnt supported behind NAT and hence the IP-HTTPS IPv6 prefix was always derived from the 6to4 representation of the public IP address bound to the UAG external NIC (e.g. 2002.XXXX).

Props got to Roshan for finding the root cause in a tricky case! :)

Cheers

JJ

"the only workaround at this time is to change the IP-HTTPS IPv6 prefix used on the DA clients so that the RA client can return a global (starting with 2) IPv6 address, not the IPv4 one."

I think I understand the issue (at a high level), but not how to implement the fix - do you mean manually setting an IPv6 on the client-side that begins with a 2?

Ok, so hopefully this should help...

You need to configure the use of a custom IP-HTTPS prefix during DirectAccess setup as opposed to using the default FDXX ULA scheme - in order to comply with the current RA code this need to be based upon a prefix that starts with '2XXX:'. This prefix can be derived using several different methods as discussed below:

1) You can request and allocate a true IPv6 address space /64 that is allocated from a provider to your company. You can do this simply by setting up a tunnel broker with tunnelbroker.net. You do NOT have to make it publicly routable (though not sure why you wouldn't) - you just want it assigned for your use. Then use that /48 allocation to do specific /64 prefix to do the DA prefix function and call it a day. A bit of a kludge from a global IPv6 reachability standpoint but should be workable.

2) You can allocate 2001:db8::/32 (RFC 3849) address space which is reserved for documentation. It technically should still work and behave like global addresses but should be blackholed by all Internet edge routers (assuming they have the right filters set up) and therefore safe to use to band-aid a situation. I haven't actually tested this approach, but it should work.

3) You can generate a 6to4 derived prefix based upon one of you own IPv4 public IP addresses. Nice thing about this is if you control one of the public IPv4 addresses then you can base it off that. Nothing wrong with that at all except public IPv6 clients will attempt to send traffic back via 6to4 and be blackholed.

Option 3 is probably the quickest and simplest to achieve, but I have not personally had to make a change to IP-HTTPS IPv6 prefix information retrospectively after install/configuration. Based upon the stage of your deployment (pilot or production) you may be better to stick with what you have and try to get a fix to the RA client issue.

Cheers

JJ

• Edited by Jason Jones [MSFT]Microsoft employee Tuesday, July 09, 2013 10:43 AM Update
• Proposed as answer by Jason Jones [MSFT]Microsoft employee Friday, July 12, 2013 3:52 PM

Jason,  you indicated a blog post or something coming soon back in June.  As of yet, I've seen no movement on the "fix RA to liston on all addresses" part of the issue.  Do you have any further info at this time?

Hi

Haven't had time to look at this...however I believe the issue has been raised with the RDS product group.

Reconfiguring the IP-HTTPS is the only workaround I am aware of at the moment :(

Cheers

JJ

Jason,

Do you know how to accomplish creating a custom IP-HTTPS prefix when using the 'behind an edge device (with two network adapters)' topology, in an IPv4 only network?  When I go through the set up wizard, it configures a FDXX ULA address on my internal adapter, as expected, but i'm unable to see the prefix screen in the 'Remote Access Server' portion.  I'm also unable to modify the client prefix after the fact, even through PowerShell (error below). 

PS C:\Windows\system32> Set-DAServer -ClientIPv6Prefix 2002:XXXX:XXXX:1000::/64

Set-DAServer : The client IPv6 prefix is selected automatically and cannot be modified because the internal network is IPv4.

Ive tried resetting the configuration, assigning a 2002 address to the internal adapter, then running through the DA / Remote Access wizard (similarly to the steps for UAG DirectAccess when running on an IPv4 network).  It allows me to see the prefix information, and fills it in correctly, but the resulting DirectAccess Group policies have a mixture of FDXX and 2002 information for the various connection rules, even though the network adapter is only configured with a 2002 address.  I'm assuming this is because of the 'behind an edge device (with two network adapters) topology.  I have a ticket open with Microsoft, but no solution or workaround has been found yet.  As a side note, I previously had DirectAccess fully functional with the ULA scheme, except for Remote Assistance connections.  Thanks

Hi,

As this is a known issue now, I would urge you to raise a support case as opposed to making prefix changes. You may be pleasantly surprised ;)

Cheers

JJ 

Jason, if there is a hotfix available, why not just post it?

The hotfix is NOW public and can be found here: http://support.microsoft.com/kb/2912883

If you experience problems with Windows 8 clients, please log a support call.

Thanks

JJ

Jason thanks for information. The hotfix says it only applies to Windows 7? We have the same problems with Windows 8 and Windows 8.1; does this fix apply to them? Or are there separate fixes coming?

I believe there is a private fix for Windows 8.x so you would need to log a support case to gain access to that version of the fix. I believe the fix is still undergoing customer testing, hence why it has not been released publically yet.

Hope that helps!

Cheers

Thanks, good to know its on the way soon/in progress!

Jason,

Thanks for making the hotfix public.  I've verified that it does indeed fix the problem in our environment.  Unfortunate that it took more than a year to get this fixed, but..at least it is fixed now.

Well, it wasn't me personally, but I have been monitoring it internally as it was something I knew we needed to fix. Good to hear it was successful!

So, just to reiterate...

If you need the fix for Windows 8.x you will need to log a support call to obtain a private fix. This support call will be FREE as the issue is caused by a bug.

The more people who log the call privately, the quicker it can be tested, given higher priority and then released as a public fix. So, you kinda drive you own efforts here folks ;)

Cheers

JJ

I have created a support ticket requesting the fix. Will update here on progress. Thx

• Edited by bcehr Thursday, January 16, 2014 5:11 PM

@Jason - out of curiosity, when a hotfix like this is found to solve an issue, when does it become part of a WSUS deployable update?

To be honest Richard, I am not sure...but I will ask...

could someone tell me if Microsoft has a private hotfix for windows 8? How can I have access to this hotfix?

Thanks

Log a free support call and get the private fix, test it and report back to the support engineer

FYI to those looking for fix, the fixes in progress do work but are still a long way away from reaching GA and being able to use in production.  Hopefully our testing helped speed up process...

FYI - good news, looks like the Windows 8.1 fix is out as the fix got rolled into Windows 8.1 Update 1

I'm running into this problem and have Update 1 installed.

Is there a any update on the fix, is there a KB or hotfix number?