It seems my Twitter posts about being able to run on-premises workloads brokered by Windows Virtual Desktop (WVD), an Azure offering, caused quite a stir. So far it has been a great, vivid discussion with the community.

As many asked how was this possible and how this was done, here we are, with this blog post.

Before I explain how that is done and what you need in place, I need to emphasize that running certain things on-premises DO violate Microsoft’s EULA/Licensing Agreements. As I am no licensing expert or a lawyer, please take that into consideration. Of course, certain things are well-known (i.e. running Windows 10 multi-user on-premises for production workloads – that does violate the licensing agreement). Others, not so much. At this point, no one was able to point out if running Windows Server or Windows 10 single-user on-premises brokered by WVD violates the agreement.

With that in mind, how is this done? It is actually quite simple. There are some pre-requisites as expected:

• You need a site-to-site VPN to Azure in place.
• You need your AD in sync with AAD.

Once you do have that in place, it is just a matter of creating empty host pools within WVD and using the registration key (‘token’) on your on-premises workloads.

The step-by-step process is like this:

1. Create a new host pool within WVD and do not create any VMs. Choose the appropriate type (like pooled, personal) of course.
2. Within the host pool overview, get the ‘Registration key’.

3. Now on your on-premises VMs (let’s say you created five Windows Server 2019 VMs), you must install the WVD Bootloader and the WVD Agent. Once the agent install starts it will ask for the token. Paste the ‘Registration key’ there and finish installing.
4. Reboot the VMs. Within the Azure Portal you will see your VMs as ‘Available’ after a while (it will probably show ‘Upgrading’ at one stage as Microsoft upgrades the WVD components on your VMs).

5. All you need to do then is to create an ‘Application group’ and associate it with a ‘Workspace’ (within WVD). Do not forget the proper assignments (which user gets access to that AG). Once you do that, the users will be able to see whatever you gave them access to (i.e. RemoteApp vs Full Desktop), exactly like they would see with Azure hosted workloads.
6. As expected, certain details about your workload will NOT be available as WVD does expect these to be running on Azure in order to retrieve information, as seen below:

7. As Denis pointed out, certain things like diagnostics are also gone if your workloads are on-prem. And that is fine from a learning standpoint as you can indeed run some on Azure to learn about that. Now, If you look into the registry of the VMs where the agents are loaded, you can see it references the IDs for all that (subscription, VM, etc) and as these VMs are not on Azure, it cannot retrieve that. But all this works and I must say it works perfectly.

Now the question is why do this? There are several extremely valid reasons:

• For people willing to learn, Azure does get you free trial accounts but these are severely limited (with very low quotas – for example you will not be able to run more than like 3 VMs in total as the vCPU count may go over the quota). This forces you to go for a ‘Pay-as-you-go’ subscription and as expected, you will have to pay for compute costs. Moving all the workloads to your own on-premises lab, this cost disappears and you can actually test all sorts of different loads on multiple VMs, as many as you want and/or your lab hardware supports. At virtually zero costs.
• For real production environments (again this may NOT be legal), chances are a ton of your data (files/databases) are on-premises. Being able to run the workloads where the data is gives you MUCH better performance and reduces costs as all the data does not have to traverse the site-to-site VPN connection.
• Comparisons. This gives you a very simple and great way to compare workloads running on Azure with workloads running on-premises, brokered by the SAME infrastructure (eliminating unknowns in that respect). You can for example have a database on-prem and on Azure, with your workloads on both. Users can then connect to published resources on both and see side-by-side how an app performs on the on-prem host pool accessing the on-prem data versus the Azure host pool accessing the Azure hosted data. All with the same brokering.

On top of that I tested a script that monitors load on my on-prem VMs in a host pool and once it reaches a certain number it then powers on additional VMs on Azure, part of the same host pool (as this DOES work – your host pool CAN be hybrid).

The only thing I could not test, as I do not have a physical PC that is domain-joined to my lab to do this, is being able to access it remotely like ‘Remote PC’. I am 99.9% sure if the PC is indeed domain joined, it will work perfectly as I did test loading the bootloader/agent on my Surface Pro 7 and as expected it did register with the host pool. The issue is, it is not domain-joined and then the agent upgrade/registration fails at one point. If this works as expected, you do open up another scenario that would be to provide users access to their own PCs at the office, using WVD (a great scenario especially now during the COVID-19 pandemic).

Why Microsoft does not consider these as very valid scenarios and more than that, use cases that would greatly benefit customers is beyond me. All I can hope is that they are listening and after seeing this and the Twitter discussions they take this into serious consideration.

I hope Microsoft sees this post as a favor during COVID-19 as I am actually reducing the load on Azure, helping with the capacity issues we have experienced.

Happy on-prem WVD testing folks.

CR