Servers That SleepA 100-Seat RDS on GCP — On Only When Needed

Most businesses don't have an IT problem — they have a desktop problem. Every employee needs a computer, and every computer eventually needs repairs, updates, virus protection, and replacement. Multiply that by 100 seats, and you have a full-time job for an IT team that most companies can't afford.

Remote Desktop Services (RDS) changes the model: instead of managing 100 physical machines, you run a handful of servers and let every employee connect to their own Windows desktop hosted on them. The desktop lives in the data center, not on the desk. This brings three big advantages:

• One image, one patch cycle — fix one server, every desktop is fixed
• Applications like AutoCAD run on powerful server hardware, not ageing office PCs
• Users connect securely from anywhere through the RD Gateway — office, home, or site

The real estate company in this case study took that idea one step further. They realized that if their desktops live on servers, then the servers should only run when employees are actually working. This book is the story of how that thinking saved them real money.

Every engagement follows the same 6 clear phases. You always know where you are, what happens next, and what you are paying for.

🏢The Customer

Sterling Realty Group is a real estate company with 100+ employees — brokers, designers, project managers, accounts, and site teams. Their work is split between design-heavy tasks (AutoCAD drawings), client communication (a softphone for calling prospects), and daily office work (Microsoft Office and Chrome).

Their old setup: a hundred physical PCs, each loaded with AutoCAD, the softphone, Office, and Chrome. Each PC needed licensing, updates, and repairs. And every desktop was a risk — people installed WhatsApp, YouTube, and social media on the same machine they used for work, slowing everything down.

😟The Problem

• 100 ageing PCs — replacements alone would cost lakhs, every few years
• AutoCAD was painfully slow on office desktops; only the design team had decent hardware
• No control over personal apps — WhatsApp and social media ate bandwidth and productivity
• Site staff and brokers needed access to files and email from outside the office, over an insecure VPN
• Servers that were already virtualized ran 24×7 even when nobody used them after hours

The company had already moved some servers to Google Cloud, so they understood the cloud concept. What they didn't have was a plan for desktops — and a way to stop paying for compute nobody was using.

🤝Our First Step — No-Cost Discovery

We started with a free assessment. We interviewed every department head, mapped which applications each team used, and — crucially — measured when they actually worked. The data told a clear story:

• Accounts and admin worked 9–6, Monday to Saturday
• Brokers and sales worked through the evening, sometimes till 9–10 PM
• Designers used AutoCAD in bursts — long idle stretches between drawing deadlines
• The file server was needed almost 24×7 because brokers shared documents at odd hours

🏗️The Architecture — RDS + Gateway in GCP

We designed a full Remote Desktop Services environment in Google Cloud: Session Hosts running Windows Server with the golden image (AutoCAD, softphone, Office, Chrome), a Connection Broker to route users, and an RD Gateway so every employee connects securely over HTTPS from anywhere — no VPN.

• Session Hosts split into pools: a CAD pool on high-core VMs for designers, and an office pool for everyone else
• Golden image with AutoCAD, softphone (Zoiper), Microsoft Office, and Chrome — patched once, delivered everywhere
• RD Gateway with MFA for all remote access; users sign in from office, home, or site
• URL filtering and Group Policy to block WhatsApp Web and social media on the work desktop
• File servers with quotas and versioning — brokers stop losing documents

⏰The Hero — Servers That Sleep

The biggest cost in a virtual desktop environment is compute that runs when nobody uses it. So we classified every server into three tiers — and this is where the real savings came from:

The business-hours tier uses Google Cloud's native Instance Schedules — a start time and a stop time attached to each VM, so servers come up at 8:45 AM and shut down at 6:15 PM automatically, Monday to Saturday, in the correct time zone. No one remembers to switch anything on or off; the schedule does it.

The on-demand tier is the interesting part. When a team needs a server outside business hours, their HOD raises a request — the server is started on approval. Then a custom idle watchdog takes over: if no one has been working on the server for 15 minutes, it shuts itself down automatically. If designers work till 11 PM, the server stays on. The moment the last user logs off and the CAD host sits idle for 15 minutes, it powers down on its own.

🔁The Rollout — Departments, Not Fireworks

We piloted with accounts first (9–6 users, simplest workload). Then admin, then brokers, then designers last — the hardest, because AutoCAD had to feel fast over remote desktop. Designers were the real test: AutoCAD on a session host with many cores and high CPU quota actually ran faster than on their old PCs.

🚀After Go-Live — We Stayed

• 2 weeks of hypercare with dedicated on-call support
• Power schedules monitored and tuned against real usage for the first month
• Monthly cost review — the first one found another 8% by resizing the CAD pool
• Their small IT team trained to manage images, schedules, and the idle watchdog themselves