Greetings my stressed out readers. Quite a few of you are no doubt working long hours right now in an attempt to provide a functioning remote working environment for your company’s employees. I myself am helping many different companies as they deploy our Remote Desktop Commander Suite and other tools to keep an eye on employee attendance, as well as the health and functioning of their Remote Desktop Services deployments.
That being said, unless you have a big budget and/or are already running your Remote Desktop Environment in the cloud where you can immediately scale up your remote working capacity with a few mouse clicks in a portal, you may be currently stuck with the hardware you have. With that in mind, here are some thoughts on how to “stretch your RDS compute” against the incoming deluge of teleworkers.
Kill the Memory Hogging Applications On Your Terminal Servers
In many RDS environments, the enemy of capacity on a terminal server is not the CPU usage but rather the memory utilization. Common culprits are web browsers, collaboration tools like Teams (sorry Microsoft), and Microsoft Office applications. It’s seldom the line of business application that your employees are supposed to be running that is eating up all of the server resources, in most circumstances. As much as possible, prevent use of the memory hogging programs by preventing them from being used (either through NTFS permissions, GPO settings, or application whitelisting technologies like AppLocker). Users should be running Teams, browser sessions, and other collaboration tools on their client devices as much as possible, not on the terminal servers.
Rein in the Browser Tab Jockeys
If you have to permit web browser use, install some plugins that will control the %$*!$ users who insist on opening 10 tabs at a time and then leaving them running. If you use Google Chrome as your browser du jour, deploy The Great Suspender plugin to automatically suspend browser tabs that have not been used for a while, freeing up their CPU and memory resources. If you are using other web browsers, search for similar plugins (they exist) by looking up phrases like “Tab Suspender.”
Overflow Users Back On To Their Internal Workstations
If you’ve deployed a Remote Desktop Gateway server, and you should for security reasons, you can overflow incoming teleworkers back to their internal company workstations. Simply craft an RDP file that has the public IP address or FQDN of the gateway, but that specifies the user’s internal workstation, and then distribute that RDP file to them. Make sure to update the Resource Authorization Policies (RAPs) on your Gateway server to permit connections to user workstations inside the firewall.
Stand Up a Connection Broker, If You Haven’t Already
Many organizations have a haphazard array of VMs running Remote Desktop Services, with different number of users assigned to each VM. This can generate a lot of wasted compute, as one terminal server may have 10 users, and another with 20, yet both VMs are sized with the same number of virtual processors and memory. Instead, introduce a connection broker into the environment, standardize the apps offered on each terminal server, and then add the terminal servers to an RDS collection controlled by the connection broker. The connection broker will then load balance all users across all of the terminal servers in the collection, allowing you to support a higher capacity of concurrent users.
Convert Full Desktop Collections to RemoteApp Collections Instead
If your users primarily only need to access a handful of line of business applications to do their jobs, create a RemoteApp collection on your connection broker, and then place your terminal servers into that RemoteApp collection and publish only the apps they need to use. Because RemoteApp sessions don’t provide access to the full desktop, or generate as many Windows dependency processes as a full desktop session, you can support a higher number of concurrent users per terminal server.
When All Else Fails, Establish and Enforce Shift Working With User Login Hours and Group Policies
Ideally you don’t want to place restrictions on when users can sign in to do work or access network resources. However, in a worst case scenario, you can enforce shift working by users in different departments by using the Logon Hours feature of Active Directory, and combining it with a GPO that force disconnects users after their shift ends. You could then expand upon that further in the GPO controlling your terminal servers so that disconnected users are auto-logged off after a set period of time. For further ideas around this topic, please review this blog article.