Rather than install a full SCADA client on every workstation, some organisations run all those clients on a single powerful machine and let users connect to their own session on it. That machine is the terminal server, and the pattern - one central host running many users' full desktops or applications - is a long-standing way to centralise SCADA client software. This guide explains the terminal-server, or remote desktop session host, model: how a full SCADA client runs on the central host while users receive published apps or desktops, why this centralises patching and licensing, and where its trade-offs, from session density to being a single point of failure, bite.
Terminal server for SCADA in one line: A terminal server for SCADA is a central session host - often a Remote Desktop Session Host or a Citrix host - that runs full SCADA client software and gives multiple users their own session on it, delivered as a published desktop or a published application. Instead of installing and maintaining the SCADA client on every workstation, the client lives once on the session host, which centralises patching and license management but concentrates load and risk on that host.
A terminal server flips the usual client-installation model on its head. Normally each workstation has the SCADA client installed locally and connects to the SCADA server; with a terminal server, the SCADA client is installed once on the session host, and each user gets their own independent session on that host in which the client runs. The user's own device becomes little more than a window onto their session, sending keyboard and mouse input and receiving the screen, while the actual client execution happens centrally. Many users share the one host, each isolated in their own session, all running the same installed client software.
What the user receives can be a full published desktop - the whole session environment presented as if it were their own machine - or a published application, where only the SCADA client window is delivered and the surrounding desktop stays hidden. Publishing just the application is often cleaner for operators, since it presents the SCADA client alone without exposing the underlying operating system, while a full desktop suits users who need more than the single application. Either way the delivery relies on a remote-session protocol carrying the display and input between the user's device and their session on the host.
This is the classic back-end for thin-client deployments, where deliberately minimal user devices depend on a central host to do the real work. The session host provides the compute, the memory, and the installed software for every user at once, which is why it must be sized for the aggregate of all concurrent sessions rather than for a single client. Understanding that the host carries the combined weight of everyone connected is the key to understanding both its appeal and its limits.
The strongest argument for a terminal server is that it collapses many client installations into one. Patching the SCADA client, updating its configuration, or applying an operating-system fix happens once on the session host and immediately benefits every user, instead of being repeated across dozens of scattered workstations that each have to be visited, updated, and verified. For a team responsible for keeping clients current and consistent, maintaining one carefully-managed host is far less work and far less error-prone than chasing the same change across a fleet of individual machines.
Licensing can be simpler in the same way, because the client software is installed in one place and the number of concurrent sessions on the host is naturally bounded and visible. Managing entitlements against a single host with a known session capacity is more contained than tracking installations spread across many endpoints, and the central point makes it easier to see and control how many clients are actually running. This tidiness is a real operational benefit even before considering the reduced maintenance effort.
Consistency is the quieter advantage that follows from centralisation. Because every user runs the same installed client on the same host, they all see the same version behaving the same way, with none of the drift that creeps in when individual machines fall behind on updates or accumulate local quirks. That uniformity reduces the surprises that come from a client behaving differently on one operator's station than another's, and it makes support simpler because there is effectively one environment to reason about rather than many.
The first trade-off is session density and the load it puts on the host. Because every user's client runs on the one machine, the host must have enough CPU, memory, and capacity to carry all concurrent sessions at once, and as more users connect, each competes for the shared resources. Push density too high and everyone's session slows together, so the host has to be sized generously for the busy peak, and there is a ceiling on how many sessions a single host can comfortably serve before performance degrades for all of them.
The second trade-off is that the session host becomes a concentrated single point of failure. When every user's SCADA client runs on one machine, losing that machine logs everyone out at once - not one operator inconvenienced, but the whole population that depends on the host cut off from their screens simultaneously. This concentration is the mirror image of the centralisation benefit: the same single point that makes patching and licensing easy also makes an outage of that point unusually costly, which pushes serious deployments toward redundancy across multiple hosts, adding back some of the complexity that a single host was meant to avoid.
The third trade-off is a subtler licensing wrinkle: the double-count. Running SCADA clients on a terminal server can require licenses for the session-host infrastructure itself - the remote-access technology delivering the sessions - in addition to the SCADA client licenses for the users, so the same access can be counted in two licensing schemes at once. This is where a terminal server contrasts with an HTML5 thin client that needs no session-host layer, and it is why the apparent simplicity of centralising clients has to be weighed against the extra licensing the session-host approach can introduce. The terminal server is a mature, capable pattern, but these three trade-offs - density, concentration of failure, and layered licensing - define where it fits and where a browser-native client may serve better.
A terminal server, or session host, is where the work happens: it runs the full SCADA client and hosts each user's session. A remote desktop gateway is the access edge that securely brokers a connection to that host from outside, handling the entry point rather than running the application. The gateway lets you reach the session host safely, but it is the session host itself that actually runs the SCADA clients for everyone connected.
Because two separate licensing layers can apply at once. You may need licenses for the SCADA client software each user runs, and separately for the remote-session infrastructure - the terminal-server or published-application technology - that delivers those sessions. The same user access is therefore counted in two schemes. This contrasts with a browser-native HTML5 thin client, which needs no session-host layer, and it is a cost to weigh against the centralisation benefits of the session-host approach.
It concentrates every user's client on a single machine, making that host a single point of failure. If it goes down, everyone relying on it loses their SCADA screens at once, not just one operator. It also has a session-density ceiling, since all concurrent sessions share the host's CPU and memory. Serious deployments address the failure risk by running multiple redundant hosts, which restores resilience at the cost of some of the simplicity a single host offered.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.