Deploying Windows 2016 Terminal Services help needed

I currently am running 5 servers for 2008 R2 Terminal servers. I need to upgrade to 2016. From what I understand, 2008R2 will not work with 2016. Things like the license manager and etc will need to be replaced. Can I transfer some of my 2008 R2 terminal licenses to 2016?

For 2016 Terminal services, I will not be using RemoteApp or Virtual desktops. It will be session based desktops. I will also be using an external load balancer for  loading balancing.
across the RDS servers. With that in mind which of the services do I need to fully push out a working 2016 TS system?

Remote Desktop Connection Broker (RD Connection Broker):
Remote Desktop WebAccess (RD Web Access)

Remote Desktop Session Host (RD Session Host RDSH):

Remote Desktop Gateway (RD Gateway):
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Cliff GaliherCommented:
So, first, you'll *REALLY* want to set up a lab.  Microsoft re-architected RDS significantly in 2012.  Things you knew no longer apply.

1) You can transfer licenses, yes, as long as you have the necessary info.

2) You want *two* connection brokers.  Your load balancers will balance between those two things.  They will, in turn, handle redirecting connections to the various session hosts (which are divided into one or more "collections" in 2012.)

3) RDWA is optional, but useful. It is used not just to present a web interface for selecting session collections, but is also used to present an XML feed for group policy based distribution or modern app feed subscriptions.

4) RDSH is the core for a session based deployment.  It is the actual environment users end up logging into.

5) RDGateway should be set up if you want to allow access externally.  It tunnels RDP traffic over 443 and handles external authentication in a secure way.  Again, you may be load balancing across multiple gateways for highly available external access.


Take note, Microsoft has recently(ish) announced their "modern infrastructure" design plan.   You can find blog posts and an ignite session on it, and shifts much of the infrastructure requirements to Azure as well as Azure AD support (much needed IMO) so depending on your timeline, that is worth keeping an eye on.  

iamuserAuthor Commented:
So if i was using an external LB then the flow would be this?

  • user connects LB
  • LB redirects user to one of the connection brokers
  • Connection broker then connects the user to a RDSH server that's in the farm

A few more questions

  • Since I am using an external LB for load balancing/HA. Is it necessary to configure HA within the connection brokers?
  • Can I start the farm with 1 Broker and 1 RDSH and then add more later?
Cliff GaliherCommented:
You have the workflow basically understood.  To clarify though, you define "collections" in 2012 R2.  So your statement of "Connection broker then connects the user to a RDSH server that's in the farm" is only partially accurate. It's easier to understand with an example:

Let's say I have an accounting package that a lot of our company uses. Since it does so many things (purchase orders, sales orders, etc), I might want servers dedicated to running that and load balancing across then.  So I define a "quickbooks" collection and assign servers 1, 2, and 3 to it.

Collection #2 is a LOB app that only the company's warehouse folks use for tracking inventory.  So server 4 is assigned to collection #2.

Collection #3 runs a CRM that all of the call center reps connect to.  So availability is important as is getting multiple servers running it for performance.  So servers #5 and #6 are in collection #3.

Back to your workflow.  When you connect, you need to specify a collection.  RDWA does this for you by default, but you can do so manually (but not in the GUI) in the .rdp file.  You connect to a connection broker and tell it you are connecting to collection #2.  The connection broker queries its database to see if you already have a connection to that collection.

If so, it redirects you to the server with the idle session so you reconnect and get all of your windows as you left them and don't end up on a new server, wasting resources.

If you *don't* have an existing connection though, it creates a new connection to a server in the collection (it picks the server with the fewest existing connections...but only for THAT collection), and redirects you to the server it picked. It then writes this information to the database, so if you disconnect for any get back to the same server when a connection is re-established.  The connection broker tracks all of this information in a SQL database, which is why it takes two to be highly available.

It also means that if you are connecting to the accounting collection, you will never get redirected to server #5.  Every server in a collection should have the same apps installed, but with multiple collections, you can still specialize.  Your accounting software doesn't need to be installed on the CRM servers so you get isolation of roles and security as well.

So, on to your questions:

As for your first question, I'm not sure I see the point of a LB in front of a single connection broker.  The load balancer isn't "balancing" any load at that point since everything would be going to one CB.  It also isn't providing any sort of high availability since the CB is a single point of failure.  I'd cut out the LB in such a topology.

Which goes to your second question.  Yes, you *can* run one CB and one RDSH and add more later.  When you add the second CB, that's the point you'll want to load balance between them.  Add both. Or neither.  But I don't really see an LB in front of a single CB as useful.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
The Five Tenets of the Most Secure Backup

Data loss can hit a business in any number of ways. In reality, companies should expect to lose data at some point. The challenge is having a plan to recover from such an event.

iamuserAuthor Commented:
Thanks, very helpful information

In regards to collections

  • Can 2 different CB point to the same collection?
  • Can the same servers be in 2 different collections?
Cliff GaliherCommented:
For the first, yes, but that'd be unusual. You'd usually only have one CB... Or two configured for HA. When configured for HA, they share a SQL database so they effect Tibet share their entire configuration. You don't configure them individually.

For the second, no. A server is a member of a single collection.
iamuserAuthor Commented:
Thanks, if we add another CB we will be using an external LB between the 2 so configuring HA for the 2 CB will prob be overkill.

So if i understand everything correctly, If i end with 6 servers in 1 farm, This will be the outcome

  • 2 will be CB,  
  • 4 will be RDSH,
  • 2 of RDSH will be in 1 collection for the 1st CB
  • Remaining 2 RDSH will be in another collection for the 2nd CB.

While it's not a supported solution (searching online) I see that it is possible to run with just the licensing and RDSH portion. It technically will not be a farm and  management tools will be missing since there is no more TSADMIN.  But I can use the LB and round robin users to different RDS servers
Cliff GaliherCommented:
You'd have issues. Speaking of, overkill or not you'd have issues running two CB without configuring HA. Since they'd be unaware of each other resources would be misallocated and potential issues with licensing and profiles as well.

Configuring HA is trivial. Configure it right the firat time and you won't have problems down the road. Advice applies to running tow connection brokers or none. Just  stick to the supported scenarios. The management overhead and the troubleshooting effort just kills any benefit from breaking outside that box.
Cliff GaliherCommented:
Also, as an aside, your suggested topology makes me question if one of your questions was clear. Or if my answer was.

You can transfer your 2008  CALs to a to a 2016 licensing server. And that 2016 licensing server can issue licenses to clients connecting to a 2008/ R2 RDSH server. But connecting to a 2016 RDSH server will require 2816 CALs. Transferring old CALs doesn't cover new servers. It only helps you not have to run multiple licensing servers in a homogenous network with many different RDSH versions.
iamuserAuthor Commented:
Oh wait, the more i think i understand the less I do

if i am using an external LB between the 2 CB. I still require HA within the 2 CB or not? I just realized that i will still have to set up load balancing for RDSH and the external LB will not do that for me.
Cliff GaliherCommented:
Yes, you should still set up HA for the connection brokers.
iamuserAuthor Commented:
thanks for all the help
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2016

From novice to tech pro — start learning today.