Terminal Server Questions

How many users is this? I wouldn't put more than 50 on one RDS Host, and at 100+ built in windows tools start breaking
 
How many users is this? I wouldn't put more than 50 on one RDS Host
Agreed.

In fact I'd generally go much lower, if we're talking about concurrent users. Assuming folder redirection is in use and no user files are stored on the RDSH(s) (which would be a really bad idea), probably the main thing to consider is the amount available RAM per user.

As an example, one setup I have has around 90 users, with never more than about 30 concurrent logins. Most of the users are RemoteApps only (on-site), while some are full Remote Desktop (depending on the ever-changing COVID rules!). So memory usage per user varies from less than 1GB to about 3GB, averaging at somewhere around 1.5GB. A single RDSH with 64GB of RAM would probably suffice in this example, but instead I have 4 x 16GB RDSH servers. 2 x 32GB RDSH servers would've worked equally well but the users in this case are spread across 2 sites and multiple physical servers.

Most of the time, all 4 RDSH servers are in use, which provide ample resources at the busiest times. However, the users can get by on 2 RDSH servers (1 per site), which is very useful when I need to update or resolve an issue with one of the servers. If users report an issue with one of the servers, for example, I just block new logins to that server and ask them to log out and in again and there's no pressure on me to fix the issue immediately. When everyone is eventually logged out of the problem server (usually the next day), I can fix the issue and bring it back online. Likewise, once a month when the Windows updates are due, I'll block logins for 2 of the servers, install the updates the following day, then toggle the login block to the other 2 servers ready to update those servers the next day. In many cases there will be plenty of out-of-hours opportunities to fix issues and update servers of course, but this particular customer requires close to 24/7 access.
 
Yeah, we've spec'd for 20 users per server, which means we have 7 servers, but unfortunately can only turn off connections for 1 at a time, I'm pretty sure 2 would cause performance complaints.

2GB per user, that's with their goal is running as much as they can in the server (which I think is a waste of money vs distrubing compute across workstations) so that means LoB app, Teams, Chrome, MS Office. (MS Office is the least offender for resource usage in this list)

We're using FSLogix for the user profiles in order to reduce the storage required on each server, and make sure user settings and data 'roam.' We've also found performance with FSLogix to be better than with redirected folders when making a bunch of small calls. There is extra overhead for each call to a network path that can add up.
 
You are going to have a nightmare with Teams running on RDSH. I advise some thorough testing before rolling that out into production.

Video calling will simultaneously eat all your bandwidth and cripple your CPU with video encoding/rendering demands. You can use GPU accelerated VM's to alleviate the hardware strain but that's going to get expensive fast with 7 RDSH

Even with just voice calling it's not suited to sending such latency sensitive traffic over an RDP session. You are adding an extra hop which is never great.

Unfortunately, solutions for this are lacking at the moment.

- You have Citrix & Horizon with their Teams Optimizations to offload encoding to the workstation/thin client and initiate the session directly. But they cost mega $$$ if you only need this one feature
- You have WVD which does a similar thing, this essentially requires a full move into Azure.
- You can run Teams locally on the users workstation/thin client. This is what we do currently. Bit annoying to be minimizing windows whenever you want to make a call but we don't have any feasible alternative. Our "VIP" users were given a 3rd monitor so RDP session is fixed to 2 monitors and Teams runs locally on the 3rd.

I'm praying Microsoft filter down the optimisations from WVD into Server 2022 when that arrives. Can't see it happening though, think they like the added selling point for WVD to push people into the cloud.
 
If the client does decide to go this way, we'll probably have between 15 and 20 remote users at maximum. They currently have 38 employees, I think, and everyone has an office and a computer and a printer. They will be likely be moving to a smaller office next year with the thought that 40% or so of their employees will be WFH at any one time. There will be shared offices used by whoever is onsite for the day. I don't know if they intend to support fulltime WFH for anyone, but I suppose that's possible.

I'm guessing they could make this work with half the square footage they have now, a huge savings, maybe enough to pay for the technology.

This means we'll be looking primarily at creating "Full Desktop Experience" users, as opposed to remote app users. I *love* the maintenance-friendly setup of having at least 2 RDSHs so you could take one offline for updates without causing downtime, then when that was done, swapping so you can update the other.

I'm guessing from @SAFCasper 's comments that some training will be necessary to make sure remote workers run Skype, Zoom, etc., on their local computer, NOT on the remote session.

Also, part of the cost of doing this for this client would be switching from Exchange Online Plan 1 to E3 licenses for Microsoft365. That isn't insubstantial. Currently, they buy perpetual licenses for Office H&B with each new computer, and they replace workstations on an individual 5-year cycle. On average, we do 1 per month, sometimes 2. I've tried to convert them before, but they have always been more comfortable with the capital expense per computer than adding to their monthly expenses. At 38 licenses, right now they are paying (38 * $5) = $190 plus $250 for the single Office license they purchase per month = $440/mo. If I switch them to E3, it becomes (38 * $35) = $1,330/mo.
 
You are going to have a nightmare with Teams running on RDSH. I advise some thorough testing before rolling that out into production.

Video calling will simultaneously eat all your bandwidth and cripple your CPU with video encoding/rendering demands. You can use GPU accelerated VM's to alleviate the hardware strain but that's going to get expensive fast with 7 RDSH

Even with just voice calling it's not suited to sending such latency sensitive traffic over an RDP session. You are adding an extra hop which is never great.

Unfortunately, solutions for this are lacking at the moment.

- You have Citrix & Horizon with their Teams Optimizations to offload encoding to the workstation/thin client and initiate the session directly. But they cost mega $$$ if you only need this one feature
- You have WVD which does a similar thing, this essentially requires a full move into Azure.
- You can run Teams locally on the users workstation/thin client. This is what we do currently. Bit annoying to be minimizing windows whenever you want to make a call but we don't have any feasible alternative. Our "VIP" users were given a 3rd monitor so RDP session is fixed to 2 monitors and Teams runs locally on the 3rd.

I'm praying Microsoft filter down the optimisations from WVD into Server 2022 when that arrives. Can't see it happening though, think they like the added selling point for WVD to push people into the cloud.
They don't do calls with it on the servers, but it's still a PITA for ballooning the FSLogix profiles, we have to have a script to shrink them. Web app works pretty slick, so I wish we just didn't have it installed at all.
 
If the client does decide to go this way, we'll probably have between 15 and 20 remote users at maximum. They currently have 38 employees, I think, and everyone has an office and a computer and a printer. They will be likely be moving to a smaller office next year with the thought that 40% or so of their employees will be WFH at any one time. There will be shared offices used by whoever is onsite for the day. I don't know if they intend to support fulltime WFH for anyone, but I suppose that's possible.

I'm guessing they could make this work with half the square footage they have now, a huge savings, maybe enough to pay for the technology.

This means we'll be looking primarily at creating "Full Desktop Experience" users, as opposed to remote app users. I *love* the maintenance-friendly setup of having at least 2 RDSHs so you could take one offline for updates without causing downtime, then when that was done, swapping so you can update the other.

I'm guessing from @SAFCasper 's comments that some training will be necessary to make sure remote workers run Skype, Zoom, etc., on their local computer, NOT on the remote session.

Also, part of the cost of doing this for this client would be switching from Exchange Online Plan 1 to E3 licenses for Microsoft365. That isn't insubstantial. Currently, they buy perpetual licenses for Office H&B with each new computer, and they replace workstations on an individual 5-year cycle. On average, we do 1 per month, sometimes 2. I've tried to convert them before, but they have always been more comfortable with the capital expense per computer than adding to their monthly expenses. At 38 licenses, right now they are paying (38 * $5) = $190 plus $250 for the single Office license they purchase per month = $440/mo. If I switch them to E3, it becomes (38 * $35) = $1,330/mo.
How come M365 E3 and not M365 Business Premium?
 
I was just following @Moltuae 's statement earlier in this thread



- I'll admit I'm not at the point where the details need to be verified yet.

Ah, so Moltuae would be referring to Office365 E3, it sounds like you are looking at Microsoft 365 E3 pricing. Welcome to the world of Microsoft's cloud services branding... :(
 
Yeah, Office 365. 'Shared Computer Activation' I believe they call it, for which E3 is the minimum requirement (or the last time I checked it was).

I have O365 installed on the RDSH servers so that the customer has the choice. If the user really needs O365 access from inside an RD session, then we put them on an E3 licence, otherwise O365 gets installed on their local machine (or they just use the Web apps, depending on their individual requirements). I also deploy (via GPOs/scripts) LibreOffice for users who do not need an O365 subscription or email address.
 
Also, part of the cost of doing this for this client would be switching from Exchange Online Plan 1 to E3 licenses for Microsoft365. That isn't insubstantial. Currently, they buy perpetual licenses for Office H&B with each new computer, and they replace workstations on an individual 5-year cycle. On average, we do 1 per month, sometimes 2. I've tried to convert them before, but they have always been more comfortable with the capital expense per computer than adding to their monthly expenses. At 38 licenses, right now they are paying (38 * $5) = $190 plus $250 for the single Office license they purchase per month = $440/mo. If I switch them to E3, it becomes (38 * $35) = $1,330/mo.

I know some people have a tough time with this...but a lot of the cost of managing a client is considering the IT guys (and gals) time in getting things done. People see the so called "savings" of buying home Office accounts.....but for a larger organization, they don't realize the complexity and additional effort and time spent and what's involved in doing computer replacements...reloading software, or nuke/paves of computers...reloading software. That's time that the IT person is spending. And time in documenting/managing licenses, credentials, etc. If you're direct billing...and being honest in billing for your time...I suppose that might be good for you, you're billing more labor. So where are the savings in $ for the client? But many IT people often don't bill enough for things like this, or chop the time spent down. Or worse...if it's an MSP client...all this extra time spent is "volunteer time"....so your client is much less profitable for you. For me to MSP a client...it's 365 or MS Volume licensing, period. No way in heck I'm dealing with home Offices.
 
Welcome to the world of Microsoft's cloud services branding... :(

Ugh - you're right, of course. This page looks like the right one. So, $20/mo/user instead of $35. So $760/mo vs. $440. Not so bad of a bump as before.

In my case, we're talking about providing the full desktop experience for remote workers, so Office will need to be part of that. They are heavy Excel users (Actuaries, duh.) as well as heavy Word users. Maybe a dozen Adobe Standard users, too. Everyone has Sharefile (or whatever Citrix is calling it this week) for secure file exchange with clients and their advisors. Two big LOB apps, 1 minor one, and lots of printers. They have pretty much a full time employee who does nothing but scan incoming mail. Fund Statements, client, attorney & investment communications, 200-page documents, etc. Before they converted to digital, they had maybe 100 file cabinets in the filing room. Literally tons of paper. Now they have a third of that (still working on historical data scanning), and a contract with a shredding company.

I'm not an MSP, so I bill for my time, but I would certainly prefer any simplification possible. I have presented the switch to O365 to them at least twice before, but each time they chose to keep going with their purchase of perpetual Office licenses. Yes, it's a pain to keep track of, but not impossible. I have a spreadsheet - it works. I will welcome this "forced" move to E3 licenses, though, for the reasons already stated.

Here's a new question - every employee has dual monitors, and almost everyone who is working part-time remotely now has dual monitors setup on their home computer so they can continue that experience with RDP. Can we provide dual monitors on the "desktop experience" for each user with the RDSH?
 
Here's a new question - every employee has dual monitors, and almost everyone who is working part-time remotely now has dual monitors setup on their home computer so they can continue that experience with RDP. Can we provide dual monitors on the "desktop experience" for each user with the RDSH?

Dual-monitor, triple monitor etc works perfectly on on RDSH. We have tons of people using it.

Something you might find is thin clients with a Linux OS sometimes don't handle dual monitor well. We had some older Dell models that claimed dual-monitor support but instead of rendering two individual displays it rendered one large display that stretched across both monitors (hope that makes sense). This meant if you maximised a window it took up both displays.

Later models don't seem to have this issue and neither does anything based on Win10 IoT.
 
I'm not an MSP, so I bill for my time, but I would certainly prefer any simplification possible. I have presented the switch to O365 to them at least twice before, but each time they chose to keep going with their purchase of perpetual Office licenses. Yes, it's a pain to keep track of, but not impossible. I have a spreadsheet - it works. I will welcome this "forced" move to E3 licenses, though, for the reasons already stated.

May be time to point out the error of those nearly unmanageable ways....and remind them that come time to switch, you'll have to "throw out" those homie licenses...thus making them quite a waste of money, and replace with 365 recurring licensing, or 1x time volume licensing (but sometimes the old volume licensing can get a little fidgety with activation so I still really prefer 365.
 
Just going to point out that Microsoft added shared activation rights to M365 Business Premium. So you can use that with a terminal server, you don't have to go to E3. You also get inTune, Defender Advanced, and a ton of other really useful stuff you don't get with E3.
 
Ahh, and incredibly, it's the same price as O365 E3. Probably not a coincidence. Thanks.
And probably a reason why they're not interesting in making Exchange Online fully multi-tenant compatible. Once you hit that 300 user mark, it becomes quite a bit more expensive to get the same features.
 
I'm configuring a lab setup, and have gotten stuck - little help?

Server 2019 VMs created for
  • DC = LAB-DC = Licensing Server Role
  • Application Server = LAB-APPSVR = SQL server, Server 2017 Express and SSMS installed
  • RDP Session Host = LAB-RDSH = Connection Broker, Web Access and Session Host roles, RD Gateway role.
Everything is on a VLAN with internet access. 172.28.4.0/24
Host and all 3 VM servers have static IPs, all machines are patched to date

I've read through 600 pages of my shiny new 'Mastering Windows Server 2016 Hyper-V" book, and I'm following this guide, just so you know I'm not winging this setup entirely. :-)

Here is a screenshot of server manager on the DC, RDS overview:
1609249779188.png

I'm at the step of configuring the RD Connection Broker for High Availability, so I'm completing this screen:
1609250095509.png
I'm having trouble with the connection string. I *think* the one I want is something like this:

DRIVER=SQL Server Native Client 11.0;SERVER=LAB-APPSVR;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=HCHRDCDB

I'm using this for the database folder:

C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA

Which exists on the LAB-APPSVR, but the database doesn't exist yet.

I'm getting this error:
1609250631894.png

I may be bollixed up because I stuck with SQL Express 2017 instead of installing 2019 - mostly due to the lack of guidance.

I thought that the database would be CREATED by this step, so it shouldn't have to exist in advance. I also could be mistaken here.

DNS is working and I have added firewall rules on the LAB-APPSVR to allow TCP 1433 inbound and UDP 1434 Outbound, as well as an exception for the SQL executable. I also tried disabling the firewall on both the LAB-APPSVR and LAB-RDSH as a test, which didn't help.

I guess my first question is how to build the connection string. Does the database need to exist prior to running the high-availability wizard?

Also, the database client for SQL Express 2017 has been deprecated, so it is not installed on the RDSH server, which has the connection broker role. I believe I read that this was no longer necessary, but I can't find that bit again.

Can someone get me back on the rails here? TIA!
 
If I recall correctly if you feed it a connection string that is telling it to use an existing database.

The connection broker does need the native client installed for whatever SQL version you're using.

I wish I could be more help, I've slept a few times since I last did this.

P.S. E3 used to be $23 / user / month, when MS released Biz Premium and added in shared activation rights to allow this work load into the SMB, that's when they dropped the price of E3 to match. It's the only price change on a major subscription I've ever witnessed on the service.
 
Back
Top