What I Build
I deploy Windows Remote Desktop Services for businesses that need staff working from home, from a branch office, or from a laptop on a job site, while the applications and the data stay on a server you control. That usually means one or more RD Session Hosts running the line of business software, a Connection Broker deciding which host a user lands on, an RD Gateway publishing sessions over HTTPS, and a licensing server holding the CALs so you do not hit the day 120 grace period wall.
A lot of RDS installs I get called into were set up by clicking Add Roles on a single box and never revisited. They work until the first thing breaks: profiles bloat, the licensing grace period quietly expires, printers stop redirecting, or someone forwards port 3389 through the firewall to make remote access work at all. I rebuild those properly. I am a solo operator, so the person who scopes the deployment is the person who builds it and the person you call when a session host stops accepting logons.
The Roles, and What Each One Is For
RDS is five separate roles that people tend to collapse into one server. Splitting them is what makes the deployment survivable.
RD Session Host
Where users actually work. Sized on real concurrency and RAM per session, with applications installed in install mode, and drain mode used for patching so nobody gets kicked mid shift.
Connection Broker
Distributes users across the host collection and reconnects a dropped session to the same host, not a fresh one. Essential the moment you have a second session host.
RD Gateway
Wraps RDP inside TLS on port 443 so remote staff connect through one hardened endpoint with a real certificate. This is the role that lets you close 3389 at the firewall and keep it closed.
RD Web Access
Publishes full desktops or individual RemoteApp programs to a browser page or the Remote Desktop client feed. Users launch the one application they need instead of a whole desktop.
RD Licensing
Holds and issues the RDS CALs. Installed on a server that is not going to be rebuilt casually, activated, and pointed at by Group Policy so hosts stop guessing where the license server lives.
Profile Storage
A dedicated SMB share for FSLogix containers, on storage that is backed up and has room to grow. Profiles are the part of RDS that fails loudest when it is an afterthought.
Licensing, Sorted Before It Bites
RDS licensing is the single most common reason I get an urgent call. A session host without a discoverable, activated license server runs on a grace period, and when that grace period ends the host simply refuses connections. It fails on a Monday morning, it fails for everyone at once, and it looks like the server is dead when it is actually just unlicensed.
I set the licensing mode deliberately rather than accepting the default. Per User CALs suit staff who connect from several devices, Per Device suits shift workers sharing one terminal, and the two are not interchangeable after the fact without work. The license server gets activated, the CAL pack gets installed and documented, licensing mode and server discovery get pushed by Group Policy instead of being clicked into each host, and I leave you with a written record of what was purchased and where it lives. Licensing is bought from Microsoft or your reseller, so you own it directly and I never sit between you and your CALs.
Profile Management
Users judge an RDS deployment on one thing: whether their desktop looks the same today as it did yesterday. That is a profile problem, not a server problem.
FSLogix Containers
The profile lives in a VHDX on an SMB share and attaches at logon, so signatures, mapped drives, and application settings follow the user to whichever session host the broker picks.
Office and Search Data
Cached Outlook data and the search index are handled inside the container rather than rebuilt on every logon, which is what turns a two minute mailbox reload into an instant one.
Redirections and Exclusions
Temp folders, caches, and downloads are excluded so containers do not silently grow into the tens of gigabytes. Growth gets monitored, not discovered when the share fills up.
Printers and Drive Mapping
Easy Print for redirected local printers, Group Policy preferences for network printers and drive letters, and a tested logon script so a new starter is productive on day one.
Secure Remote Access Without Publishing RDP
Port 3389 open to the internet is still the most common way a small business gets ransomed. I do not deploy it that way. Remote sessions terminate on an RD Gateway with a valid public certificate, connection authorization and resource authorization policies limit which groups can reach which hosts, account lockout thresholds and logon auditing are set, and the firewall permits nothing else inbound. Where a client prefers it, sessions ride an existing site to site or client VPN instead, and the Gateway sits behind that as a second layer.
The rest is ordinary discipline that rarely gets done: session time limits so abandoned sessions release their RAM, idle disconnect separated from logoff so work is not lost, clipboard and drive redirection scoped by policy rather than left wide open, and Windows Update handled with drain mode and a maintenance window instead of a surprise reboot. I document the whole configuration and hand it over, so this is not a black box only I can maintain.
How A Deployment Runs
Assess
Concurrent user count, the applications that must run in a session, current licensing, and what the hardware or hypervisor can actually carry. This is where a rebuild gets separated from a repair.
Build
Roles deployed onto right sized servers or VMs, licensing activated, profiles containerized, Gateway certificate installed, policies applied, then a pilot group runs on it before anyone else moves.
Hand Over
Backups verified by restore, monitoring in place, a written runbook covering licensing, patching, and adding a user, plus ongoing support if you want it.
A Deployment I Run: Sage 50 For 30 Users
The clearest case for RDS is an application that was never designed to be used remotely. Sage 50 is one of them.
The Problem
Sage 50 keeps its company data in a file on a share, and every workstation maps a drive to it. That is fine on a switch in the same building. Across a VPN or a branch link it is slow, and a connection that drops mid write is how a company file gets damaged.
What I Built
One session host carrying 30 users. The application and the data file sit on the same LAN segment, so nothing but screen updates travels to the user. Profiles are containerized, so the accounting team gets the same layout and mapped drives on every logon.
Why It Holds
Nobody reaches it over open RDP. Sessions come in through the Gateway, updates run in a maintenance window with drain mode rather than a surprise reboot, and the backup is verified by restoring it, not by reading a green tick.
The Infrastructure Underneath
RDS is only as good as the servers, storage, and network it sits on. Both of these are work I have already built and documented.
Infrastructure & DevOps
Git servers, Synology NAS administration, automated deployment workflows, and hosting panel management. The same storage and backup discipline that profile containers depend on.
View Details →Server Builds
Proxmox hypervisors, hardened firewalls, VM sizing, and production hosting. Session hosts are usually VMs, so this is where an RDS deployment starts.
View Details →Need Remote Desktop Services Help?
Tell me what you are running now and what keeps breaking. A 24 hour answering service picks up and routes straight to my cell when something is down; scheduled work happens in agreed windows. I am based in Lynchburg, onsite across Central Virginia, and remote for clients nationwide.
Get in Touch