Thank you Mahesh, another question, will this work with our current internal DNS Round Robin Broker on private addresses which users currently use? Or would we have to point all computers to the external DNS Round Robin?
Mahesh thanks again, one last question, because the servers are in a farm will both solutions work side by side I.e internal DNS Round Robin for corporate network, and public DNS for public network?
So if user a connects to external DNS record of broker farm.coaro.co.uk which then goes to public DNS Round Robin, which then goes to internal server IP address via NAT, with the same internal server ip addresses which are also part of the internal DNS Round Robin?
The reason I ask is if I a attempt to connect to say one of the terminal server internal ip addresses the broker still flips me around via internal DNS Round Robin without the FQDN being needed?
donovan williams
ASKER
Mahesh thanks again, one last question, because the servers are in a farm will both solutions work side by side I.e internal DNS Round Robin for corporate network, and public DNS for public network?
So if user a connects to external DNS record of broker farm.coaro.co.uk which then goes to public DNS Round Robin, which then goes to internal server IP address via NAT, with the same internal server ip addresses which are also part of the internal DNS Round Robin?
The reason I ask is if I a attempt to connect to say one of the terminal server internal ip addresses the broker still flips me around via internal DNS Round Robin without the FQDN being needed?
Thanks Mahesh, I believe the behaviour you describe for 2012/r2 is the same as we experience on our 2008r2 environment, When connecting to a specific servers ip address it does bounce you to another server than the one requested via iP, I know this is the case as the server can ask for credentials twice?
Mahesh
yes you are right but with little difference
2008 R2 you may need to authenticate twice because of jumping no matter you connect through IP or farm FQDN
But in case of 2012 / 2012 R2, MS has added SSO feature within RDS console and removed farm concept, farm concept is replaced with collection which do not have any farm FQDN
So server bouncing and jumping is taken care by SSO and you would not asked for credentials again
In that case MS is saying that you should directly connect to FQDN of broker server and it will take care of rest
This works well for quick deployment where broker, session host and RD web are all on same server
But if model is distributed, like all 3 roles installed on separate server, connecting to FQDN of broker does not work, it won't be able to redirect you to appropriate RD session host server
In that case you need to create session host farm and grant him FQDN and then this round robin setup will work as mentioned in last comment
In fact, in any scenario, if you tried to connect to RD session host through RD web server, that request 1st goes to rd broker and then it will take care of rest
Mahesh.
Mahesh
Answers are given in detailed
Author did not respond
Again thanks