I manage a small office with roughly 10–15 employees. Most users run simple accounting software and Microsoft Office, while two or three occasionally use AutoCAD for relatively light 2D drawings. The existing computers range from older systems to newer ones, and some users experience brief freezes when opening larger drawings, documents, or accounting files.
I tested Windows Server 2022 with Remote Desktop Services on an existing server, and the experience seemed smoother. My idea is to centralize the workloads on one properly sized server and use inexpensive wired thin clients at each desk. The server would have around 12–16 CPU cores and 48–64 GB of RAM, with additional graphics capability if the AutoCAD users need it.
The potential advantages are more consistent performance, less duplicated memory usage, simpler backups, easier expansion, centralized storage, and reduced power consumption. I would also use NVMe storage with redundancy, a UPS, and daily backups. The accounting software supports multiple users.
However, I am concerned about the drawbacks: Windows Server and RDS licensing, AutoCAD performance over RDP, the risk of one server becoming a single point of failure, and the time required to maintain the environment. Would RDS be a sensible choice for an office this size, or would individually upgraded workstations be more practical and reliable?
4 Answers
RDS itself is still a valid option for 10–15 light users, but you need to evaluate the whole system rather than just the apparent hardware savings. One server, its storage, the network, licensing, and the RDS configuration become shared dependencies. If one of them fails, everyone may be unable to work.
Make sure you price Windows Server licenses, user or device CALs, RDS CALs, and any Office licensing requirements. RAID improves availability and performance, but it is not a backup, so keep separate backups and regularly test restoring them. Also test the actual AutoCAD workloads with several users working at once; basic office applications are much easier to host than graphics-heavy CAD sessions.
Be especially cautious with AutoCAD. Even light drawings can feel poor over standard remote desktop when users pan, zoom, or work with multiple viewports. A dedicated GPU or virtual GPU solution may be needed, and that can make the server considerably more expensive and complicated. You could keep the ordinary office and accounting users on RDS while leaving CAD on local workstations, but that reduces some of the simplicity of a single centralized platform.
For this office size, I would first compare the five-year total cost with simply replacing or upgrading the PCs. Put more RAM and SSDs in the general machines, and give the AutoCAD users systems with stronger CPUs, graphics, and memory. Centralization can save hardware, but the administration, licensing, monitoring, backup, and recovery work can outweigh those savings.
A cloud-managed setup with device management, cloud document storage, and automatic provisioning may also be worth considering. Replacing a failed workstation is then relatively simple, while an RDS failure affects the entire office.
The biggest unanswered question is what happens when the central server fails. Hardware failures are uncommon, but motherboard, memory, CPU, storage-controller, power, and failed updates can all cause downtime. A daily virtual-machine backup helps with some disasters, but restoring it to replacement hardware may still take time.
If you choose RDS, use a UPS, redundant storage, tested backups, spare hardware or a documented recovery procedure, and a way to keep working during an outage. Size the server for the busiest expected period plus roughly 20% headroom, not just the average workload. If you cannot justify that recovery plan, separate workstations are safer because one failure normally affects only one person.
I would test the CAD users thoroughly before committing. They mostly work with simple 2D drawings, but I would still plan for a suitable GPU rather than assume the normal RDS display experience will be enough.