none
DirectAccess and RDS - Connection failing to one Session Host RRS feed

  • Question

  • Hi,

    Unfortunately I cannot find an answer to this particular conundrum anywhere so I am reaching out to you for help.

    I have a Server 2012 R2 RDS deployment as follows:

    1 x Connection Broker (also acts as a Session Host) - SRV01

    1 x Session Host - SRV00

    1 x RDWeb Host and License Server - SRV05

    This deployment is only used "Internally" so the certificate used is an internally generated one from the CA: *.domain.local

    I also have DirectAccess running on the same domain which seems to work flawlessly with RDS since I added the IPv6 addresses to the above servers, with the exception of SRV00.  

    The problem is as soon as I bring SRV00 into the available pool of RD Session Hosts, users running a RemoteApp while connecting through DirectAccess that get directed to SRV00 by the CB get the "Initializing remote connection" timeout and it gets no further.  

    The frustrating thing here is that it is working perfectly to both servers when the client is either onsite or connected over a separate VPN connection (Cisco Meraki) but as soon as they connect using DA, if the Connection Broker determines it's session should be hosted by SRV00, it times-out.  Sometimes it will decide that SRV01 can host the session and that will immediately connect, even over DA.  The problem therefore looks to be with the additional session host server SRV00, but I cannot for the life of me work out why.

    Any suggestions would be very much appreciated, and thanks for taking the time to read the above.

    Cheers,

    Ken

    Wednesday, July 3, 2019 8:10 AM

Answers

  • Typically I have found the solution to this issue shortly after posting this, and it turned out to be an oversight on our part, as follows:

    We had a DA server working which broke due to GPO settings changing the security in the background.  We couldn't get it to work quickly enough so decided to build a new one from scratch.  Of course the new one had a different IPv6 prefix and though we were under the impression the new one had been added to the host servers, it had not.  I therefore re-ran MS's script with the new prefix added and Voila!  Our faces are red...

    • Marked as answer by KenSayers Wednesday, July 3, 2019 10:57 AM
    Wednesday, July 3, 2019 10:57 AM

All replies

  • Typically I have found the solution to this issue shortly after posting this, and it turned out to be an oversight on our part, as follows:

    We had a DA server working which broke due to GPO settings changing the security in the background.  We couldn't get it to work quickly enough so decided to build a new one from scratch.  Of course the new one had a different IPv6 prefix and though we were under the impression the new one had been added to the host servers, it had not.  I therefore re-ran MS's script with the new prefix added and Voila!  Our faces are red...

    • Marked as answer by KenSayers Wednesday, July 3, 2019 10:57 AM
    Wednesday, July 3, 2019 10:57 AM
  • Thanks for sharing, Ken. I'd like to add the link to the reference Microsoft KB article for configuring Remote Desktop server farms to support DirectAccess, just in case anyone else comes across this post. :)

    https://support.microsoft.com/en-us/help/3123137/remote-desktop-server-farm-is-unavailable-over-directaccess-single-mul 


    Richard M. Hicks
    Microsoft Cloud & Datacenter MVP
    Founder and Principal Consultant - Richard M. Hicks Consulting, Inc.
    directaccess.richardicks.com

    Wednesday, July 3, 2019 7:40 PM