+44 (0)1482 770583
hello@systechitsolutions.co.uk
Remote Desktop Services (RDS) Consultancy & Support
Designing, fixing and running RDS estates, including the ones that should stay exactly where they are.
The estate you have, working properly
In short: Session-based Remote Desktop Services designed, fixed and supported: RD Session Host sizing, Connection Broker and Gateway design, profile and logon performance, and CAL licensing. For organisations running RDS who need it to work properly, not a sales pitch to move. Where moving is genuinely right we will say so, and where it is not we will say that too.
Most advice about Remote Desktop Services now consists of telling you to stop using it. That is a convenient position for whoever is selling the replacement, and it is wrong often enough to be worth checking before you spend anything.
The problem
An RDS estate that nobody owns degrades in a specific and predictable way. Profiles grow, logons stretch from seconds to minutes, one badly behaved application starts affecting everybody on the same host, and the fix gets postponed because nobody is confident what a change will break. Meanwhile the users experience it every single morning.
What we would do
Fix the estate you have before deciding whether to replace it. Most RDS complaints trace to profiles, storage or one misbehaving application rather than to the platform, and those are cheap to fix. Judging RDS on a neglected deployment is how organisations pay for a migration they did not need.
- If the hardware is at end of life anyway, that is when the cloud comparison is genuinely fair: new spend against new spend.
- If people need access from anywhere and a VPN is holding it together, the access model is the problem, not the session platform.
- If the Windows Server version is unsupported, that is a security decision rather than a performance one, and it comes first.
When we are not the answer: If you have already decided to move and want it executed, plenty of firms will do that competently and cheaper. We are worth paying for when the question is still open, or when something is wrong and nobody can say why. We will also tell you to keep what you have, which a migration specialist has no reason to say.
Remote Desktop Services is the session-based platform that has been publishing Windows desktops and applications since long before anyone called it virtual desktop, and it is still supported, still shipping in Windows Server, and still the right answer for a lot of organisations. We design, troubleshoot and run RDS estates: RD Session Host sizing, Connection Broker and Gateway design, profile and logon performance, application delivery, and the CAL licensing that catches people out.
More on how we deliver Remote Desktop Services
This is the practice the business was built on, and it is the same specialism our founder's Microsoft MVP award is in. That matters here because RDS problems are rarely the ones the error message describes: slow logons are usually storage or profiles, a session that hangs for everyone is usually one application on one host, and a Gateway that works from the office but not from home is usually certificates. Long experience of the platform is mostly experience of which symptom means what.
Systech is founder-led by Ryan Mangan, a Microsoft MVP for Azure Virtual Desktop and Windows 365, a Chartered Fellow of the BCS (FBCS) and author of Packt's two-edition Mastering Azure Virtual Desktop.
Where the question of whether to move is genuinely open, the AVD vs Windows 365 vs traditional desktops guide works through the same decision in detail.
Everything you need, managed for you
Is Remote Desktop Services still supported?
Yes. Remote Desktop Services remains a role in current versions of Windows Server, and Microsoft continues to ship it. The confusion comes from marketing rather than lifecycle: the attention has moved to Azure Virtual Desktop and Windows 365, and it is easy to read that as RDS being retired.
What does matter is the Windows Server version underneath it. An RDS estate on an unsupported Server build is a genuine problem, but that is an operating system lifecycle question rather than a verdict on session-based computing, and the answer may well be to move the roles onto a current Server version rather than to change platform entirely.
So the useful question is not whether RDS has a future. It is whether your particular estate, on its particular hardware, with its particular applications, is better served by staying, upgrading in place, or moving. That is a different answer for different organisations and it deserves to be worked out rather than assumed.
Why are logons so slow, and what actually fixes it?
Almost always the profile, and almost never the thing people first suspect. A slow logon is the single most common RDS complaint and it is also the most consistently misdiagnosed, usually as the server being underpowered.
In rough order of how often we find them:
- Roaming profiles that have grown for years and are copied at every logon and logoff.
- Folder redirection missing or misconfigured, so documents and caches travel with the profile.
- Storage that cannot serve the burst when forty people sign in within the same ten minutes.
- Group Policy processing that has accumulated over a decade, including policies aimed at machines that no longer exist.
- Logon scripts running in sequence, each waiting on something slow.
- Antivirus scanning the profile path during the copy.
FSLogix changes the shape of the problem rather than tuning it. Instead of copying a profile at logon it attaches a container holding the profile, so sign-in stops scaling with profile size. It is the single most effective change on most estates, and it is included with the licences most organisations already hold.
It is not a cure for underlying storage, though. A profile container on storage that cannot serve the morning burst moves the bottleneck without removing it, which is why the first thing worth measuring is what the storage is doing at nine o'clock rather than at two in the afternoon.
How many users should a session host support?
There is no honest per-server number, and any supplier who gives you one without asking what runs on it is guessing. Density is decided by the applications and the working pattern, not by the specification sheet.
A host serving a line-of-business application and Outlook behaves completely differently from one where everybody keeps thirty browser tabs open, and browsers are usually the largest single consumer of memory on a modern session host. The number that matters is concurrency at peak rather than total headcount, because the estate has to be sized for the morning, not for the average.
The sizing method that works is measurement: watch what real users consume on the applications they actually run, size for the peak, and leave headroom for the loss of one host. That last part is the one most often skipped, and it is why an estate that is fine on Monday falls over when a host reboots on Tuesday.
Grouping matters as much as sizing. Putting a heavy, unstable or memory-hungry application on the same hosts as everybody else means one application's bad day is everybody's bad day, and separating it is often cheaper than adding capacity.
What do the RDS roles actually do?
Worth setting out, because most estates we inherit have at least one of them doing something it should not.
The roles and what each is for:
- RD Session Host: where sessions actually run, and where the applications are installed.
- RD Connection Broker: decides which host a user lands on and reconnects them to an existing session rather than starting a second one.
- RD Gateway: lets people connect from outside without a VPN, tunnelling RDP over HTTPS.
- RD Web Access: the portal listing published desktops and applications.
- RD Licensing: issues the RDS CALs, without which sessions stop after the grace period.
The Connection Broker is the one worth checking first on an inherited estate. If it is not deployed or not working, users get a new session on a different host each time they reconnect, which presents as lost work and mysteriously duplicated sessions rather than as a broker fault.
The Gateway is where the security posture usually sits. An estate publishing RDP directly to the internet is exposed to constant automated attack, and putting a Gateway in front of it, with multi-factor authentication, is one of the highest-value changes available on a legacy deployment.
How does RDS licensing work, and where do people get it wrong?
You need two things and organisations routinely have only one: a Windows Server licence for the servers, and an RDS Client Access Licence for every user or device connecting to them. RDS CALs are a separate purchase, and the grace period at the start is what allows an unlicensed estate to run for a while and then abruptly stop.
The choice between per-user and per-device CALs is the one that costs money. Per-device suits shift patterns where several people use the same physical machine across a day, such as a ward, a factory floor or a shop counter. Per-user suits people who connect from several devices, which now includes almost every office worker with a laptop and a phone.
The common expensive mistake is buying per-device out of habit for a workforce that has since gone hybrid, and then buying more when people started working from home on their own machines.
Worth knowing when comparing against the cloud: Azure Virtual Desktop and Windows 365 do not use RDS CALs, and their access rights come through Microsoft 365 or Windows Enterprise licensing you may already hold. That changes the comparison, and it is a real part of the arithmetic rather than a technicality.
Should we move from RDS to AVD or Windows 365?
Sometimes, and the timing matters more than the destination. The strongest case is when the hardware is due for replacement anyway, because then you are comparing new spend against new spend rather than against a server that is already paid for.
Reasons that genuinely justify moving:
- The hardware is at end of life and would need replacing to continue.
- People need access from anywhere and the current answer is a VPN nobody enjoys.
- Demand is uneven, and being able to scale down out of hours is worth real money.
- You have no appetite to keep running Windows Server infrastructure at all.
- You already hold the Microsoft 365 licensing that carries the access rights.
Reasons to stay, at least for now:
- The estate works, the hardware has life left, and the complaints are fixable.
- Applications depend on local hardware, licensing dongles or on-premises data with heavy traffic.
- Connectivity at your sites would make a cloud-hosted session a worse experience.
- The predictable capital cost suits how the organisation buys things.
Where the question is genuinely open we model it properly rather than asserting an answer, and the comparison guide covering that decision goes through the trade-offs in detail.
What does an inherited RDS estate usually need first?
A week of finding out what is actually there, which is unglamorous and consistently the highest-value part of the engagement.
Estates built years ago and left alone accumulate: hosts that were added for a project and never removed, published applications nobody uses, Group Policy aimed at machines that no longer exist, and at least one setting somebody applied during an incident that was never reviewed.
What we look at first:
- Whether the Connection Broker is doing its job, because that is often the whole complaint.
- Profile and logon path, measured at the morning peak rather than when it is quiet.
- Whether RDP is reachable from the internet without a Gateway in front of it.
- Licensing position, including whether CALs are the right type and actually installed.
- Which applications are on which hosts, and whether one of them is affecting everybody.
- What happens when a single host is lost, tested rather than assumed.
That normally produces a short list of cheap fixes and a smaller list of real decisions, which is a better starting point than a migration proposal written before anyone looked.
| Remote Desktop Services | Azure Virtual Desktop | Windows 365 | |
|---|---|---|---|
| Where it runs | Your servers, on your terms | Azure, sized and tuned by you | Microsoft-hosted, fixed per-user size |
| Cost shape | Capital, plus RDS CALs | Consumption, varies with usage | Fixed monthly per user |
| Access licensing | RDS CALs, bought separately | Carried by Microsoft 365 or Windows Enterprise | Carried by the Cloud PC subscription |
| Scaling down out of hours | No saving, the servers are yours either way | Real saving, if configured for it | No, the subscription is fixed |
| Session model | Shared session hosts | Shared or personal | Personal Cloud PC per user |
| Best when | Hardware has life left and the estate works | Demand is uneven and you want control | You want predictability and no infrastructure |
Questions we hear a lot
Is Remote Desktop Services being discontinued?
No. RDS remains a role in current versions of Windows Server and Microsoft continues to ship it. What has changed is where the attention goes, which is now Azure Virtual Desktop and Windows 365, and that is easy to mistake for a lifecycle announcement. The question that does matter is the Windows Server version your estate runs on, because an unsupported Server build is a real problem, but the fix for that is often moving the roles to a current version rather than changing platform.
Why are our RDS logons so slow?
Nine times out of ten it is the profile rather than the server. Roaming profiles that have grown for years get copied at every sign-in, folder redirection is missing so caches travel with them, and storage cannot serve the burst when everybody arrives at once. FSLogix usually transforms this, because it attaches a profile container instead of copying a profile, so logon stops scaling with profile size, and it is included in licensing most organisations already hold. It will not rescue storage that cannot cope with the morning peak, which is why we measure at nine rather than at two.
How many users can one session host handle?
There is no honest general number, and a supplier who gives you one without asking what runs on the host is guessing. Density is set by the applications and the working pattern: a line-of-business app and Outlook behaves nothing like a workforce keeping thirty browser tabs open, and browsers are usually the biggest memory consumer on a modern host. We size against measured concurrency at peak, with headroom for losing one host, because that is the scenario most estates have never tested.
Do we still need RDS CALs?
If users or devices are connecting to a Windows Server session host, yes, and they are a separate purchase from the Server licence itself. The choice between per-user and per-device is where money is won or lost: per-device suits shared machines on shifts, per-user suits people connecting from a laptop and a phone. The expensive and common mistake is a per-device estate bought for an office-based workforce that has since gone hybrid. Azure Virtual Desktop and Windows 365 do not use RDS CALs at all, which is a genuine part of any cost comparison.
Is it safe to publish RDP to the internet?
No, and it is one of the first things we look for on an inherited estate. RDP exposed directly to the internet is subject to constant automated attack and is a recurring route into ransomware incidents. The supported answer is RD Gateway, which tunnels the connection over HTTPS and lets you put multi-factor authentication and Conditional Access in front of it. On a legacy deployment that is usually the single highest-value security change available, and it is not an expensive one.
Can you take over an RDS estate nobody understands any more?
That is the most common way this work starts. The first piece is discovery rather than change: what hosts exist, whether the Connection Broker is actually doing its job, where profiles live, what the licensing position is, which applications sit where, and what happens when a host is lost. Estates left alone accumulate hosts added for finished projects, published applications nobody uses and settings applied during an incident years ago and never reviewed. The output is usually a short list of cheap fixes and a smaller list of real decisions.
Should we just move to the cloud instead?
Possibly, and the timing matters more than the destination. The fair moment to compare is when the hardware needs replacing anyway, because then it is new spend against new spend rather than against a server already paid for. Moving makes sense if access from anywhere is a real requirement, if demand is uneven enough that scaling down out of hours is worth money, or if you have no appetite to run Windows Server at all. It makes less sense if the estate works, the hardware has life in it, and the complaints are the fixable kind. We will tell you which of those you are.
Remote Desktop Services is delivered UK-wide from our office in Brough, East Yorkshire, with on-site support across the county where it helps. We work with businesses in Doncaster, Wakefield, Harrogate, Huddersfield, Scarborough and Bradford and 6 more Yorkshire towns and cities, and remotely with clients right across the UK.
Get an AVD cost and performance assessment
Book a free Azure Virtual Desktop assessment with a Microsoft MVP renewed specifically for AVD, and get a written TCO analysis of your host pools, storage and licensing before you commit to a build or a rebuild.