I recently joined a logistics company as the only IT operations person and inherited an aging remote desktop environment. There are about 18 standalone RDS session-host VMs running on a Nutanix cluster, but no Connection Broker, RDS farm, profile management, or folder redirection. Users are assigned to specific servers and sign in to the same host every day. Their profiles and work files are stored locally on each server's C: drive, which makes moving users between hosts difficult. Their main workloads are Microsoft Office and one line-of-business application. A faulty RDS update recently caused several hosts to hang at the Welcome screen, and because users were tied to particular servers, failover was extremely difficult. What would a modern, practical redesign look like, and what migration steps would you prioritize?
5 Answers
First determine how many users and concurrent sessions there actually are. If the environment is small, consolidating onto fewer hosts may be simpler than maintaining all 18. If the user count is significant, use a proper farm with multiple hosts and a broker. Either way, move profiles and data off the local C: drives so a user can connect to another host without losing their settings or files. Keep the design as simple as the workload allows rather than adding components just because they are considered modern.
Azure Virtual Desktop is another option if the company is comfortable with cloud services and already has the appropriate Microsoft licensing. A pooled multi-session host setup with FSLogix and Azure file storage would provide flexible capacity and make host replacement easier. It still requires careful application testing, identity design, network planning, and cost analysis, so it should not be chosen solely because it sounds newer.
Do not assume the current architecture must be replaced immediately. Find out whether users are actually experiencing frequent outages, poor performance, or support issues. If the environment is stable, document it, fix the backup and recovery gaps, and plan the migration around host end-of-life. If it is unstable, start with a pilot farm and profile migration rather than attempting an all-at-once rebuild.
The line-of-business application deserves a separate review. If the vendor offers a web interface or hosted version, moving that application away from the session hosts could eliminate much of the RDS dependency. Otherwise, test it thoroughly in the new pooled environment, including printing, file access, Office integration, and any licensing tied to a specific server.
The usual target would be a single RDS deployment with Connection Brokers, pooled session hosts, and user profiles stored outside the hosts. Put FSLogix profile containers on resilient SMB storage, then use folder redirection or OneDrive Known Folder Move for user documents. Build the session hosts from a common image so they stay consistent, and drain individual hosts before maintenance. Migrate a small group first, validate the line-of-business application, and then move users in batches. Also replace automatic, uncontrolled patching with staged maintenance rings: patch a couple of hosts first, monitor them, and continue only if they remain healthy.
Before doing any of that, verify whether the servers are joined to Active Directory and whether users are domain accounts. If they are local accounts, standardizing identity and permissions is the first major project.
I would also inventory the application’s data, licensing, printer requirements, and any per-user settings before migrating. Those details often cause more trouble than the RDS configuration itself.