none
Cannot connect to RDP farm through Direct Access RRS feed

  • Question

  • 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.

    Wednesday, July 24, 2013 2:56 PM

All replies

  • 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? 

    Friday, August 2, 2013 8:16 AM
  • 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.

    Tuesday, August 6, 2013 1:06 PM
  • 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?

    Tuesday, August 13, 2013 2:12 PM
  • 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!

    Wednesday, August 14, 2013 12:14 PM
  • 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... :-(
    Thursday, September 5, 2013 7:01 AM
  • 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
    Thursday, November 7, 2013 4:16 PM
  • 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?
    Thursday, November 7, 2013 7:13 PM
  • 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

    Thursday, November 7, 2013 9:17 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

    Wednesday, December 4, 2013 3:43 PM
  • 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 5, 2013 1:09 PM
    Wednesday, December 4, 2013 7:49 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

    Thursday, December 5, 2013 7:48 AM
  • 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

    Thursday, December 5, 2013 9:49 AM
  • 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

    Thursday, December 5, 2013 1:05 PM
  • 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

    Thursday, December 5, 2013 1:11 PM
  • 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

    Tuesday, April 8, 2014 6:32 AM
  • 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

    Tuesday, April 8, 2014 8:10 AM
  • 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 8, 2014 11:06 AM addition
    Tuesday, April 8, 2014 11:03 AM
  • This is an old post but just to keep it alive and confirming it works - this worked for us too with 2012 R2. However, I wonder if this is the "real" solution because this KB, this post and this post and this blog post talk about ISATAP. Any comments.

    Anyway, my findings using the method mentioned in this forum post...

    We simply ping'ed the servername FQDN from an DA Client on the outside, got the IPv6 addresses and configured them on each RDSH session host IPv6 network configuration. If you look at Event ID 801 in Microsoft-Windows-TerminalServices-SessionBroker/Operational you will see BEFORE changing anything:

    RD Connection Broker successfully processed the connection request for user DOMAIN\username. Redirection info:
    Target Name = RDSH1
    Target IP Address = 10.10.10.5, fdc8:ecbe:a63:7777::aff:1c85
    Target Netbios = RDSH1
    Target FQDN = RDSH1.domain.com
    Disconnected Session Found = 0x0

    When adding the IPv6 address, it will on the Target IP Address add it also:

    Target IP Address = 10.10.10.5, 95c8:ebae:a21:7777::abb:2c95

    No need to reboot or anything.

    IF the client still can't connect, it might because you are missing the following patch for Windows 7/8.1: That was not the reason for us but might be useful for others reading.
    https://support.microsoft.com/en-us/kb/2964833

    The reason: This problem occurs because the client does not try all the endpoint addresses that are passed in the redirection packet of the RD Connection Broker server.

    I'd wish Microsoft would have solved this differently. I can't see DirectAccess getting this to work since DA simply does not understand IPv4. But maybe in Windows 2016 the client will try the server FQDN instead of the IPv4 address?


    • Edited by MikaelJones Friday, August 12, 2016 11:44 AM
    Friday, August 12, 2016 11:34 AM
  • So I did some more investigation. Basically, the forum posts and blog post I referenced to will configure ISATAP. That will probably work but since we have a "multi-site DA"-deployment this way is not possible nor supported according to: https://support.microsoft.com/en-us/kb/3123137

    So in the above KB there is a workaround with a PowerShell script. Basically what that does is to set one or more IPv6 addresses just as I did manually ubt you don't have to go through the effort of getting the IPv6 addresses manually. Manually is fine with a few servers but we have 30+ servers to add. So the script they reference helps a lot.

    Friday, August 12, 2016 2:35 PM
  • I know this post is old now, but we've just recently deployed Windows 10 in our business and we have an old RDS 2008 R2 farm that houses an old business system.  We needed this for our DirectAccess clients.

    We went through all of the above problems and we finally fixed it.  I'll share...
    Our setup is 1 x 2008 R2 connection broker and 3 x RDS session hosts.  We publish a RemoteApp icon for users - we don't use RDWeb.

    Same setup as everyone, IPv4 on the inside, DirectAccess IPv6 on the client side.  The DA server is simply a clever NAT/proxy device.  We experienced users being able to hit the 2008 R2 Broker, but everything failed after that.

    Our fix.. (and we didn't use ISATAP).
    Firstly check out this link from Microsoft

    On our DA server, run this powershell

    Get-NetNatTransitionConfiguration

    Copy the IPv6 address under PrefixMapping e.g. fd66:123:abc:7777::

    On each of your RDS session hosts, open your NIC Properties, make sure IPv6 is ticked (no address needed to be configured).

    From that MS Link, run the powershell code under 2008 R2, inserting your IPv6 address from DA server into the $prefix = "inserthere".   This will add a static IPv6 address to your NIC.  It will include the portion from your DA server plus extra for the host in question.

    And now, the check box of doom!.  Open the  RDS Session Host Configuration console (still on the session host).  Open the properties of your RD Connection Broker.  Click RD Connection Broker tab, at the bottom will be your IPv4 address and the magic check box next to IPv6 address. Give that little box a good beating.  Repeat this on all your RDS Sessions Hosts, then lastly do this on your connection broker too.

    If you look on your Connection Broker event viewer (Apps & Svc\MS\Windows\TerminalServices-SessionBroker\Operational), you will now see IPv4 and IPv6 addresses being advertised for client redirections under Event ID 801.

    It worked for us :-)



    • Edited by CrackinRyder Wednesday, January 24, 2018 8:17 PM
    Wednesday, January 24, 2018 8:06 PM
  • Thanks Russel! As soon as IPv6 are added on Session Hosts servers everything work fine.

    I have Windows Server 2019 RDS environnement (1 broker, 1 Web access, 3 Sessions hosts), Windows 10 clients and Direct Access on 2012 R2.

    And it works fin also for our 2008 R2 farm. Don't forget to check box IPv6 on RD session Host Configuration window (it's in farm parameters view).
    • Edited by Conte0 Thursday, March 12, 2020 7:46 AM
    Thursday, February 6, 2020 1:28 PM