I recently joined a logistics company as the only IT operations person and inherited about 18 standalone Remote Desktop Session Host virtual machines running on a Nutanix cluster. There is no Connection Broker, shared RDS deployment, profile-management solution, or folder redirection. Users are assigned to specific servers and sign in to the same one every day, while their profiles and work data remain on that server's local C: drive.
Their workload is fairly simple: one line-of-business application and Microsoft Office. The arrangement became a major problem when a faulty Microsoft update caused several session hosts to hang at login. Because users were tied to particular servers and their data was stored locally, moving them to another host was difficult and disruptive.
What would a sensible modernization plan look like? Should I build a conventional RDS deployment with a broker and shared profiles, move to a cloud desktop platform, or keep the current model and simplify it?
4 Answers
The usual direction would be one RDS deployment with a Connection Broker and multiple interchangeable session hosts. Put user profiles in FSLogix containers on reliable SMB storage, and move Desktop/Documents data to a central file service or supported cloud sync solution. Once profiles and data are no longer tied to a host, you can drain a server for maintenance or move users elsewhere without losing their environment.
Build the hosts from a common template so they stay consistent, and use staged patching rather than automatic updates everywhere at once. Patch a small group first, validate logons and the business application, then continue with the remaining hosts.
A hosted desktop option such as Azure Virtual Desktop could also fit: pooled session hosts, profile containers on shared storage, and users assigned to a pool instead of a particular machine. It reduces the need to maintain the whole RDS control plane yourself, but licensing, networking, storage performance, and application compatibility need to be checked first. It is not automatically cheaper just because it is in the cloud.
Before choosing the platform, find out how many users there actually are and whether the servers are joined to Active Directory. If there are only a few users, consolidating onto fewer hosts may be enough. If there are many users or uptime matters, a proper RDS deployment with centralized identity, profiles, storage, and patch management is more appropriate. Also inventory each local profile and copy the required data before moving anyone; profile migration is manageable, but it needs a deliberate plan.
Don’t redesign only the desktop layer. Check whether the line-of-business application can be replaced with, or accessed through, a web-based system. If that application is the main reason users need full remote desktops, modernizing it could eliminate much of the RDS complexity. In the meantime, avoid a risky big-bang migration: document the current setup, pilot a small group, migrate profiles and data, test printing and the business application, and keep a rollback path.
I’d also make sure the file storage has proper redundancy and tested backups. Centralizing profiles removes the single-server dependency, but it creates an important dependency on the storage layer.