Windows Virtual Desktop brings us a modern, cloud-centric way to deliver desktops and applications to end-users. Although the service takes care of the overhead of managing RDS infrastructure roles (such as the connection broker and gateway), the host servers themselves still need to be managed and maintained.
Windows Virtual Desktop is a combination of RDS as a Service, where the underlying RDS roles are managed by Microsoft, and a new licensing model for Windows 10 with Windows 10 Enterprise multi-session. These new features make it easier and cheaper to deliver desktops and applications from Azure to end-users than ever before. However, the base Windows Virtual Desktop feature set does not specifically include a way to maintain and update the session host VMs that host the desktops and apps. Additionally, there are no built-in monitoring tools for the host servers.
Windows Virtual Desktop provides RDS and related services. However, in a production environment, WVD needs to be layered on top of additional tooling and processes to manage the VMs that make up the deployment.
When it comes to keeping the WVD hosts updated, both the operating system and applications need to be considered. The different ways to keep these updated on the WVD hosts are the same as with most Azure VMs. The two main choices are traditional update management or VM re-deployment.
With traditional update management, the host servers are treated just like servers are on-premises. They are added to the existing update management software and patched and rebooted on a set schedule with the rest of the servers in the enterprise. That software could be something traditional - like SCCM or third-party tools - or an Azure service like Update Management. In either case, the VMs are long-lived and updated monthly.
In a VM re-deployment approach, the VMs aren't typically ever patched. Instead, new VMs with the latest OS and software updates get deployed and added to the host group. Then, the VMs with older versions get set to drain mode (where no new RDS connections are allowed). Once they have no active user sessions, they can be removed from the WVD host pool and deleted entirely. This approach works specifically well with pooled hosts that are stateless. This can be achieved by using FSLogix to store user data in a central location and ensuring applications don't store any important data on the hosts. The re-deployment process would typically be fully automated using ARM templates and PowerShell scripts tied together with an Azure DevOps deployment pipeline.
With either approach, it's important to establish a procedure for rolling out updates to a subset of hosts for pilot testing before a general rollout. This gives users a chance to test new versions before they are deployed to all users. If any issues are found, the deployment can be stopped for further diagnosis.
Monitoring and Management
Within Windows Virtual Desktop, session host monitoring comes down to a basic "is the VM checking in with the WVD service or not". For more in-depth monitoring, external tools need to be integrated. That could be Azure Monitor, third-party tools, or a combination of them. For example, session hosts need memory and CPU usage to be closely monitored. As more users connect to each host, these can become fully consumed and cause serious performance issues on the affected VMs. Monitoring and alerting is critical to ensure that this is headed off before it becomes an issue. WVD doesn't provide any in-depth host monitoring of this sort so existing tooling needs to be integrated.
Windows Virtual Desktop is a great way to deliver RDS desktops and applications from Azure VMs. However, it's important to keep in mind that it isn't a complete solution on its own. It's a single piece of the puzzle that solves the infrastructure and delivery questions of RDS, but the host VMs still need to be managed and maintained like any other VM.