There are (I think) tens of millions of users of remote desktop / VDI instances out there in the world – most of which are hosted (gasp) outside of Azure! I know it may sound crazy, but sometimes VDI desktops need to be near data, and often that data hasn’t found it’s way to the cloud… yet.
That’s where Azure Virtual Desktop for Azure Stack HCI comes into play – you can deploy VDI desktops just about anywhere you can put an Azure Stack HCI cluster and take advantage of the AVD infrastructure in Azure without the need for all those pesky VDI roles on VMs like gateways and brokers!
Even while it’s still in preview (as of this writing – January 2024) there is a great deal of interest in ability deploy remote / VDI desktops using Azure Stack HCI, and I’ve been getting a lot of questions about migration and deployment. I’m not going to go deep on how to deploy a net new AVD on HCI installation – that’s something that’s getting attention here: Deploy Azure Virtual Desktop – Azure Virtual Desktop | Microsoft Learn.
What I will focus on is how to might migrate an existing VDI deployment to AVD on HCI (I haven’t seen any guidance yet on that!). In a series of posts, I’ll walk through the steps I’ve used to move a VDI deployment … using an existing RDS Personal VM installation (although you could do something similar with virtually any on premises VDI… you would just have to work out things like 3rd party agent removal and disk format conversion from VMDK, QCOW2, RAW VDI to VHD/VHDX).
Starting Infrastructure – RDS Personal VM Deployment
To start with, I have what I consider to be a simple RDS deployment in my data center (basement) running on AD domain joined hosts and VMs:
Users connect to it using the old classic RDWEB page hosted on a Windows Server:
…and I have LOTS of VMs ready to go for new users who might log in (as well as persistent VMs already assigned to current users):
Migration Process Overview
Remember that this is merle a walkthrough of how I moved an RDS deployment for “personal” VMs to AVD on Azure Stack HCI, and a discussion of the associated considerations / steps – you may need to do other things to successfully migrate your VDI environment to Azure Stack HCI.
Here are the high-level steps I used (which will each be the topics of separate posts linked below):
Some more details / thoughts on these steps are below, as well as
links to the more detailed blog posts below:
- Discover / Inventory VDI Resources
- Review RDS environment / virtualization host(s)
- Install Azure Stack HC
- Review administration tools (Admin Center, Hyper-V Manager, Cluster Manager)
- Create virtual network with same name as RDS virtualization host(s)
- Prepare Azure / AVD Environment
- Check “landing zone”
- Create AVD Host Pool / save registration key
- Collect Agents and other “bits” for installation
- Migrate VM(s)
- Collect RDS deployment information – Servers, VMs, and user assignments
- Migrate VM
- Shutdown VM
- Export VM to share on HCI cluster
- Import VM on HCI cluster and configure for HA
- Start VM and install agents / register VM with AVD host pool.Assign user to VM in AVD
- Point Users to New AVD Infrastructure
- Cleanup
- Remove VM from RDS deployment
- Delete VM from RDS Virtualization host (if desired)
- Remove install residue on AVD VMs (if desired)
- Transition users to new access method
- RDP Shortpath – what it is, why you want it, and how to enable it
Once done, users can access their desktops using AVD control plane:
Assumptions!
There are so many things that must be “right” to migrate virtual machines between hosts… let alone switching between VDI technologies! Remember that is a “sample” process to demonstrate the art of the possible – it works for me in my controlled environment. There is very little in the way of error handling or recovery processing built into my PowerShell. Here are just a few of the things I feel are important to remember:
- Only migrating RDS Personal VMs – Session hosts could also be moved but profile management and the need for a licensing server complicate moving other types of VDI deployments.
- Using Windows 10 – that’s what I did because frankly it’s simpler to move! the TPM/Bitlocker “stuff” with Windows 11 presents certain challenges that I wasn’t willing to face for this effort
- RDS session VMs have WinRM enabled to allow for remote command execution (installation of the AVD agent / bootloader)… I did this via GPO using guidance from https://woshub.com/enable-winrm-management-gpo/
- Hyper-V settings are similar between RDS virtualization host and the HCI cluster – for example: the Virtual Network on all hosts have the same name, or VM imports on the Hyper-V host (HCI cluster) will fail). I did migrate from AMD to Intel (hardware I have) which meant I needed to start “Saved” VMs and shut them down rather than migrate state.
- Users have an Entra ID (Azure Active Directory) UPN that match their Active Directory UPN – you could get by without that (if for example SID is populated in Entra ID from ADConnect) but without a matching UPN, things can be complicated. AVD relies on Entra ID (formerly known as Azure Active Directory) to use the service even if the VMs themselves are AD joined and users log into those VMs using those AD credentials.
I’ll also setup a separate post with the complete PowerShell examples.
All the Scripts
Happy migrating!
-John
