Hey everyone, hope you can help/

I have an issue connecting to the RD Farm when connected through Direct Access. I have tried specifying the RD Gateway to no avail. Cannot ping RD farm or session hosts through v4 but can v6. The address comes back as the 6to4 address and is different for each ping to each session host.

When trying to RDP to the farm (or directly to a SH) certificate trust comes up so confirm that i am happy to trust the certificate for the connection, and it goes through to the point of initiating remote connection and then fails with the standard "Remote Desktop cant connect to the remote computer..." message.

I am not entirely sure where or how to troubleshoot this first. Users local side of the wan are ok, its only external. 

Apparently after numerous attempts the connection works but I am yet to witness this.

So further investigation shows that round robin doesnt seem to be working over DA. Once I have confirmed the Direct Access client is all connected and everything there is happy, I try an RDP session to my farm.

The certificate notification comes up for a particular session host (#3) of which i confirm that i trust it. It then connects in fine. 

If i then log back off the rdp session and disable logon to that #3 session host, retry the rdp connection to the farm, it fails. 

My big question is where does this fail? I am thinking the obvious of the redirect not functioning properly in some way. Getting rather desperate for assistance now as no one remotely can do invoicing and people are chomping at the bit...anyone? 

Have you confirmed that you can RDP directly into each terminal server directly over DirectAccess to make sure that packets are flowing correctly? If you have any trouble getting into any TS directly, this would obviously cause you problems. For example, if your clients are connected using Teredo and some of your terminal servers are firewalled so that they do not respond to ICMP (when you ping them they timeout), you are going to have trouble connecting to those servers from Teredo clients. If you open up ICMP and allow it to respond on those servers, they will then connect. So I would start by making sure that you can consistently access the servers directly before worrying about the load balancing.

Also you mentioned trying to ping RD hosts via v4 and v6. Over DirectAccess nothing moves over IPv4, all traffic and all ping responses will be IPv6.

Have you confirmed that you can RDP directly into each terminal server directly over DirectAccess to make sure that packets are flowing correctly? If you have any trouble getting into any TS directly, this would obviously cause you.............

Also you mentioned trying to ping RD hosts via v4 and v6. Over DirectAccess nothing moves over IPv4, all traffic and all ping responses will be IPv6.

Thanks for your reply Jordan! Gave me something to look into at least. So I have two testing scenarios both of which use the 3G services, one of which is on APN directly connected to our IP VPN WAN, the other my mobile completely separate to the network. Both of which are now allowing Direct Access to connect completely and the DA connectivity assistant shows everything working...great!

I can ping what I want, it all responds with the IPv6 address, I can RDP onto what ever I like...apart from directly to the session hosts that are part of this farm. I can even connect directly into the connection broker. I wouldn't expect to be able to connect to the session host directly anyway as they ask the connection broker if they should be hosting that session, is that not correct?

So my thought is the redirect isn't working over IPv6 and I cant find any resource on tinter-web with this same issue? It is as if the re-direct (or response) that comes from a different IP is being blocked...I am not entirely sure how to prove this theory though, hope this makes sense?

I have experienced the same issue trying to work with out RDS farm that is using session brokering.  My basic understanding is that the session broker hands back the client an IPv4 address of the RDS host in the farm that you should connect to.  When that happens DA doesn't know what to do with the IPv4 address.

Something similar was discussed in this thread:

http://social.technet.microsoft.com/Forums/windowsserver/en-US/7bde59b5-387b-4c4c-9fc9-00a987033593/uag-directaccess-and-rd-connection-broker

Microsoft if you are listening here.  This all your own technology, please help us fix access to RDS farms from DA!

Microsoft if you are listening here.  This all your own technology, please help us fix access to RDS farms from DA!

The gods are on vacation...clearly... :-(

We had a similar issue with a recent 2012 R2 and 2012 DA installation, where the DA clients cold conenct to the Connection Broker but when it received the redirection information, was unable to connect directly to the Session Host.

This is because it was returning the IPV4 address of the Session Host, which the DA client was unable to use.

We assigned a static IPV6 address to the Session Hosts and then the Connection Broker included that in the redirection information and the DA client was able to connect successfully.

Cheers for now

Russell

Thanks for the response.  Can you just clarify what (if any) configuration within your network infrastructure you had to do to enable this?  That is did you (or your network team) have to make any changes within the network infrastructure in order to properly route this traffic?

No configuration changes required, the DA and RDS solutions worked fine in their own rights but when we tried to access the RDS system from a DA client it would authenticate the user, show the RemoteApp then the connection would drop.

On further investigation we could see that the connection broker was returning the IPV4 address of the session host to the DA client and, as I'm sure you know, the DA client can't use the IPV4 address.

We then added a static IPV6 address to the Session Host and did the same test and it worked. The Connection broker passes the same information back to the DA client but also includes the IPV6 address of the session host.

Hope this helps

Russell

We had a similar issue with a recent 2012 R2 and 2012 DA installation, where the DA clients cold conenct to the Connection Broker but when it received the redirection information, was unable to connect directly to the Session Host.

This is because it was returning the IPV4 address of the Session Host, which the DA client was unable to use.

We assigned a static IPV6 address to the Session Hosts and then the Connection Broker included that in the redirection information and the DA client was able to connect successfully.

Cheers for now

Russell

• Proposed as answer by RSBurnell Wednesday, November 13, 2013 6:39 PM

Hello!

We are facing the exact same problem with a TS-Farm and DirectAccess Clients. Unfortunately the above proposed solution does not seem to work for us. However, we are not quite sure which IPv6 we should set and whether IPv6 DNS or even GW are required too. Testing various things did not give any positive result so far.

Could anyone give a few more hints? If Russel is reading that may you elaborate a bit more?

Thanks

Ralf

Ralf,

Not sure that I can give any more details but for what it's worth we are using Windows Server 2012 R2 for the RDS Servers and Direct Access with Windows 8.0 clients.

We initially got both systems working fine and could use the DA clients to connect directly to the RD Sessions Hosts but when we provisioned the RemoteApps to the clients via RemoteApp and Desktop Connections (RADC) we would see the initial screen and then the connection dropped. Further investigation showed the Connection Broker was passing the correct information (FQDN and IPv4 address) to the DA client but of course it can't then use the IPv4 Address to connect to the Session Host.

We then added a static IPv6 address (same as the IPv4 address) to each of the RD Session Hosts and saw that the Connection Broker included this in the packet to the Client, which then used this to connect to the relevant Session Host.

Cheers for now

Russell

Ralf,

Not sure that I can give any more details but for what it's worth we are using Windows Server 2012 R2 for the RDS Servers and Direct Access with Windows 8.0 clients.

We initially got both systems working fine and could use the DA clients to connect directly to the RD Sessions Hosts but when we provisioned the RemoteApps to the clients via RemoteApp and Desktop Connections (RADC) we would see the initial screen and then the connection dropped. Further investigation showed the Connection Broker was passing the correct information (FQDN and IPv4 address) to the DA client but of course it can't then use the IPv4 Address to connect to the Session Host.

We then added a static IPv6 address (same as the IPv4 address) to each of the RD Session Hosts and saw that the Connection Broker included this in the packet to the Client, which then used this to connect to the relevant Session Host.

Cheers for now

Russell

• Proposed as answer by RalfDK 22 hours 43 minutes ago

Ralf,

Not sure that I can give any more details but for what it's worth we are using Windows Server 2012 R2 for the RDS Servers and Direct Access with Windows 8.0 clients.

We initially got both systems working fine and could use the DA clients to connect directly to the RD Sessions Hosts but when we provisioned the RemoteApps to the clients via RemoteApp and Desktop Connections (RADC) we would see the initial screen and then the connection dropped. Further investigation showed the Connection Broker was passing the correct information (FQDN and IPv4 address) to the DA client but of course it can't then use the IPv4 Address to connect to the Session Host.

We then added a static IPv6 address (same as the IPv4 address) to each of the RD Session Hosts and saw that the Connection Broker included this in the packet to the Client, which then used this to connect to the relevant Session Host.

Cheers for now

Russell

• Proposed as answer by RalfDK Thursday, December 05, 2013 1:09 PM

Russel,

thanks for your reply. Our Scenario is pretty similar. 2x 2012 (not R2) DA, TS-Farm with 2008R2 RDSHs, RemoteApps on Win 8 Clients connected through DA. DA works perferctly since implementation in July 2013. Remote Apps work great with a single TS. Now we set up the farm and things go off as described.

The colleague in charge of that is pulling his hair our for days now. He tried assigning static IPv6, tried it with ISATAP but no avail. He now asked me to find out what the shape/typw of the IPv6 should be? Does it need to correspond with the IPv6 of the DA Proxy? Sorry I am not  an IPv6 expert and thus my question may Sound stupid, but due to language barrier I am basically posting on behalf of my colleague.

Brgds Ralf

Ralf,

I wonder if the problem is that you're using 2008 R2 for the Connection Broker? You can look at the Connection Broker event in Event Viewer and see the request from teh client and the reply sent back, which will include the FQDN and IPv4 address of the Session Host that the Connection Broker has determined that the client should connect to. With the 2012 R2 Connection Broker we can also see the IPv6 address ebing passed back to the DA client, which it then uses (automatically) to connect to the Session Host.

I think we found out wich IPv6 to use by pinging the name of each Session Host from a DA client and then added it to the NIC of each one.

I know someone else who's implemented a 2008 R2 RDS Solution with DA and will see how they got around the problem and report back :-)

Cheers for now

Russell

Russel,

the problem has been solved now! The final thing missing was just a check in a  checkbox.
Below a comprehensive explanation that may help others.

We basically did what you proposed:
We sent a ping from one of the DA-Clients to the TS-Farm members. Since we got replies, we knew that IPv6 communication generally is okay. The answer received was an IPv6. In this scenario we had not yet given any IPv6 to the farm-members! Thus we knew it must be comming from the DA DNS-Proxy. There are a number of DA-GPOs and one of them is dictating the net portion of the IPv6 to be used in DA-communication, appended by a hex-translation of the target computers IPv4. Therefore the DA DNS-Proxy is taking the GPO-set IPv6-value, adds the IPv4 in hex and sends it  back as an ICMP echo.
With this in place and working correctly one can ping any domain host from any DA-Client. This is configured when initially setting up DA and is handled by the wizzard. Once DA is installed this should all be in place without extra user interaction.

We then took those IPv6 answeres and turned them into fixed IPv6es of the farm-members (each member its own IPv6). So far so good, but this is where it still did not work. Evaluation of the Connection Broker log showed that the redirect reply still included only the IPv4 of the target farm-member. With that (after a short while) we realized that one has to set a check in the Connection Brokers Settings, so that the IPv6 LAN-Connection will be used for redirects as well and not only the IPv4 LAN-connection..... How stupid is that? :-)

But as we all know - in dealing with server configuration - you should always "know before you go". But even though you may think you do, when finally arriving you know you didn't.... And that's what we call experinece.

Thanks to Russel for your interest and help.

Brgds Ralf

Ralf,

Glad I was able to help you get the problem sorted and thanks for the detailed description of what was required.

For what it's worth, it's much easier in 2012 as none of the "tick boxes" you mention are required :-)

Cheers for now

Russell

Hi

it looks like that is what I am looking for

can you please show  or point where is that Check should be done on the Node or on the Broker itself ?

can you send a screen shot please

thanks

Hi

it looks like that is what I am looking for

can you please show  or point where is that Check should be done on the Node or on the Broker itself ?

can you send a screen shot please

thanks

No check boxes, you just have to ping your Session Host(s) from a DA enabled client and you'll get an IPv6 address returned. Manually add the IPv6 address to each Session Host and then it should work.

Cheers for now

Russell

Hello Yaki!

Is it a 2012 or 2008 RDS Farm?

The "tick box-szenario" we had on a 2008 farm. Per what Russel wrote you don't have that on 2012 based machines.

Brgds

RalfDK

• Edited by RalfDK 23 hours 49 minutes ago addition

Hello Yaki!

Is it a 2012 or 2008 RDS Farm?

The "tick box-szenario" we had on a 2008 farm. Per what Russel wrote you don't have that on 2012 based machines.

Brgds

RalfDK

• Edited by RalfDK Tuesday, April 08, 2014 11:06 AM addition