Terminal Services (revised)

... as promised... more TS info... this time with less fluff.  I started re-reading my previous post... and quickly decided... mmmkay too much fluff.  It needs a rewrite...  so... this time... I'm not going to be so "non-tech" friendly.  Forgive me if I glance over several things & get right to the meat of this.

In short... here's the goal of what we're looking for when it comes to  getting redundancy going...

Shamelessly "borrowed" from technet's site.

Although there you see 5 servers in this model... we only have 2 to play with.  (in this particular environment) but hey.... the the process is still similar.  Lets cut this down a bit more & see what we end up with.

Woohooo 3 servers... makin' progress...  of course... we're not even touching the gateway services yet... and the session broker ends up becoming the weak link.   What if it dies? ... evil phone-calls.

Lemme break down the steps in simple terms:

1. The client does a DNS lookup for our server's name... in this example up above, "Farm1".  In production... this will be a FQDN, publicly accessible.
2. DNS server responds with a list of multiple answers... one for each "session host" server.
3. The client randomly picks one of the servers from the list and connects to it.  If that server is unavailable... the client will pick another one from the list.
4. The randomly selected server... talks to the session broker behind the scenes & asks where the client needs to go.
5. The session responds with where the client needs to go.
6. The Session host tells the client where to connect...
7. The client connects to the specific server...
8. Finally, the session host updates the session broker with it's new connection.

 Ideally... that's how the magic all works!  Woohoo!

Ok... lets add a few more pieces to this puzzle.

Those purple servers are Gateway Servers...  If you look at the previous diagrams... they use private IP addresses... the job of the gateway server... is to securely bridge that gap between the public internet... and the private network.  Why 2? .... and why doesn't one have any lines connected to it? ... well... round robin DNS is round robin DNS... int his particular example... the random server it found was the top one.  The client's connection sticks with that server.  Had the client randomly picked the other server... the lines would all point to the other server.


In order for this to work... the client needs an additional config option set to use the gateway servers.  Not really a big deal as you'll probably end up deploying a .rdp file or setting up a portal to your users.  When a gateway is thrown into the mix, the clients actually use a HTTPS connection rather than the standard RDP (tcp 3389) connection... and add a *needed* additional layer of security. 

So... the process changes a bit.

1. Client does a DNS lookup for the gateway server.
2. Client gets multiple servers to connect to... randomly picks one...
3. Client connects to random gateway server using basic HTTPS authentication... and start a RPC over HTTP session.
4. The Gateway Server does another round-robin DNS lookup for the Session Host Server.
5. List of Session host servers is returned... and a random one is picked...
6. The Gateway Server passes the RPC session over to the Session Host server.

and from there it behaves like normal... juggling around between servers until the new session finds the correct server.  (Either resuming a disconnected session, or starting a new one on the least-used server.) 

And now, for the final piece.  That connection broker represents a single point of failure.  We're trying to build a setup with minimal points of failure.  So... the "Microsoft Answer" ... is to throw yet another server into the mix as a fail over.

So... there we have the "Microsoft" plan.  6 servers... to go from a single session host to adding a 2nd session host to the mix.  Admittedly, this is a great model for scalability to a HUGE deployment.  Most small businesses won't really need this level of scalability.  A single server can easily host 20-50 sessions... or even more with the right hardware or moderate to light weight applications.

In my situation and probably many others...  I can't justify that sort of expense when more than half of those servers will be sitting relatively idle... So... I set out to consolidate the roles each server performs... while still keeping the redundancy and all the benefits of each role.

12:54AM .... and tomorrow is another day.  I'll layout how I consolidated each roll into 2 servers tomorrow.