cancel
Showing results for 
Search instead for 
Did you mean: 

Juniper SA vs. Windows terminal server session broker

SOLVED
Alexander Bochma
New Contributor

Juniper SA vs. Windows terminal server session broker

Hi,

I've seen this or similar questions in the archive, but unfortunately none of the posts had a useful answer...

We're running into problems when our Windows people activate the TS Session Broker feature on a Server 2008 R2 terminal server farm: Each time a connection is redirected by the session broker to another server, the Juniper TS client is closed with a "server denied the connection" message.

In our case, the session broker role is activated on one of the actual terminal servers. Our SSL-VPN box is a SA4500 running 7.1R5.

Does anyone have a setup where this works?

1 ACCEPTED SOLUTION

Accepted Solutions
Alexander Bochma
New Contributor

Re: Juniper SA vs. Windows terminal server session broker

As it turns out, Terminal Server load balancing actually works, and my problem was something completely different:

I had been using hostnames in the relevant policies that were resolved by local host entries on the SA. For some reason these policies didn't match when the TS connection was sent to another host in the farm (possibly TS session broker uses IP addresses as destinations when deflecting connections, couldn't find that out in detail).

As soon as I directly used the IP addresses of the destination systems in my policies, the problem went away, and sessions were distributed to all terminal servers in the farm without further problems.

Just a small display problem left, but one I can live with: The TS client will display the IP address of the inital host in it's address bar, not the one it's been connected to in the end.

View solution in original post

4 REPLIES 4
zanyterp_
Respected Contributor

Re: Juniper SA vs. Windows terminal server session broker

Can you please open a case with support for this?

When you say that the connection is redirected, what exactly does this mean: that the user starts on boxA but then is sent to boxB mid-session OR the user authenticates to boxA/the broker and then the connection is sent to boxB?

 

Thanks!

Alexander Bochma
New Contributor

Re: Juniper SA vs. Windows terminal server session broker

As it turns out, Terminal Server load balancing actually works, and my problem was something completely different:

I had been using hostnames in the relevant policies that were resolved by local host entries on the SA. For some reason these policies didn't match when the TS connection was sent to another host in the farm (possibly TS session broker uses IP addresses as destinations when deflecting connections, couldn't find that out in detail).

As soon as I directly used the IP addresses of the destination systems in my policies, the problem went away, and sessions were distributed to all terminal servers in the farm without further problems.

Just a small display problem left, but one I can live with: The TS client will display the IP address of the inital host in it's address bar, not the one it's been connected to in the end.

View solution in original post

vieregg_
Occasional Contributor

Re: Juniper SA vs. Windows terminal server session broker

So how did you enter more than one IP address into the host field? As far as I understand it, having all RDP session hosts with the same name but different IP addresses in the DNS is part of the key to load balancing.

 

Regards

Dirk

vieregg_
Occasional Contributor

Re: Juniper SA vs. Windows terminal server session broker

I meanwhile found a solution that works for me. Here are the steps:

 

1. Create your terminal server farm / remote desktop session host farm according to http://technet.microsoft.com/en-us/library/cc753891.aspx.

 

2. Create a new terminal services resource profle on your SSL VPN gateway. Make sure to unselect "create an access control policy allowing terminal service access to this server.

 

3. Manually create a terminal services resource policy. Enter all involved terminal server names, the farm name and the ip addresses as resources. Apply this policy to the roles needed.

 

Regards

Dirk