Creating a WVD Session Host in the Azure console

Before you launch into creating host pools in Windows Virtual Desktop (WVD), you’ll need to do some preparations. I’ve detailed those previously here:

Moving to the Cloud  – Part 1

Moving to the Cloud – Part 2

Moving to the Cloud – Part 3

What you need for Windows Virtual Desktop (WVD)

Creating a WVD host pool in the Azure console

this article will show you how to add hosts (i.e. Virtual Machines (VMs)) to the host pool you have already created.

Open the Azure portal and navigate to Windows Virtual Desktop in your tenant and you should see the above screen.

Select the option for Host pools from the menu on the left as shown.


You should now see a list of Host Pools already created. You’ll need to have at least one host pool to continue, so if you don’t have one yet, you’ll need to go and create it.

Select the host pool you wish to add hosts machines (i.e. VMs) to.


In this case, I selected Host Pool P2 and see the above screen which should also see some similar. You will note that this Host Pool currently has no Session Hosts in it. To add a Session Hosts (i.e. a VM), select the Session hosts from the menu on the left as shown above.


Select the +Add button on the right as shown to add a new host VM.


You’ll now be stepped through a host creation wizard. There generally won’t be anything you can change on this initial page, because the settings are determined already by the Host Pool. So, select the Next: Virtual Machines > button, at the bottom of the page, to continue.


Select the Resource Group and the Location (i.e. data center) for the host machines. I’d suggest that you keep all of these together in the same data center.

Next, select the Size of the VMs you wish. Have a think here. Any machines you also add to this Host Pool will need to match any machines you add to this pool down the track. So, have a think about how machines you are likely to need in total before you select the size of the VM you want.

Now select the total number of VM’s you wish to create at this time. Again, start small and grow if you need to is the suggestion. That helps keep costs down. You can also enter a Prefix that will be added to each host as it is created. This make it easy to keep track of which hosts below to each pool. My best practice if to use an identifier that let’s you know what pool this host is part of.

When complete, scroll down for more options.


Next, you’ll need to select where to get the image to put on hosts (i.e what initial operating systems and any additional apps). You can use your own custom image if you wish, but you’ll need to have it prepared beforehand. Here a standard one from the gallery is selected.

Then, select the type of hard disk you wish for the hosts.

These hosts need to live on an existing VNET and Subnet that need to have been set up prior. Again, it’s important that this VNET, and other resources live in the same region. If you mix regions, then some of the resources may not show in the wizard. Best practice again, is to keep all of the WVD infrastructure together in the same region.

If you wish to access these hosts directly from the Internet via something like RDP, you can give them a public IP address. This can be handy for troubleshooting but is not recommended best practices as they will be exposed to attack when running. By default, hosts in a pool are only accessible via the WVD service.

Scroll down the screen for more options.


If you have configured a sub domain or want to use specific OU’s in your domain for these these new hosts, you’ll need to set the Specify domain or unit option to Yes and add the appropriate configuration.

In my case, as I detailed here:

Moving to the Cloud – Part 3

I set up Azure AD Domain Services, specifically for WVD. Best practice, when I did that, was to create a subdomain like:

Thus, I needed to select Yes, here and enter the whole subdomain into the field that appears. You don’t necessarily have to do that, it all comes down to how you have configured your networking. But make sure you put the right entry here or adding hosts will fail.

The last fields on this page ask you for an account to be used to join the hosts to the domain. This can be the source of plenty of pain and frustration. My advice, is to test and ensure that this account actually can manually logon to Azure without MFA and also can actually add machines to the domain. Remember, this join account can’t have MFA enabled due to the automated nature of the join process about to take place. This may require manually adding a VM to the domain using this account, to verify before completing this wizard. Also, be aware that if you get the wrong details and continue with the wizard, not only will the attach fail but the account you are using might get locked out! So, lots to be aware of here and I highly recommend double checking everything as this is the most common point of failure in my experience. Remember, once the hosts are joined you can disable the login for your join account to keep it secure.

When you have made all your selections, press the Next button at the bottom of the page to continue.


Add any tags you wish on this screen and then select the Next button at the bottom of the screen to continue.


Azure will then evaluate your selections and let you know if there are any issues that require attention.


If the validation passes, you should see a green banner at the top of the page as shown and the Create button at the bottom will become available. Select this to continue.


You should then see the deployment process begin as shown above.


It will then continue on, through the various stages and take around 10 minutes to complete. That may vary depending on the amount and size of hosts you wish created.


If all goes as expected, you should then be greeted with a successful deployment page as shown above.


If you look at the hosts you just created in the Host Pool, you may see their status as Upgrading as shown above. This shouldn’t take long to complete.


and a few minutes later, the host status should be Available as shown above.


If you click on any individual host, you should see a summary screen like that shown above.

That completes the process of adding hosts (VMs) to the Host Pool. The next step will be to give users access to these machines which I’ll cover in a upcoming article.

Creating a WVD host pool in the Azure console

Before you launch into creating host pools in Windows Virtual Desktop (WVD), you’ll need to do some preparations. I’ve detailed those previously here:

What you need for Windows Virtual Desktop (WVD)

Once you have all that in place, navigate to Windows Virtual Desktop in your portal and you should see the following screen.


A host pool is the container in which the virtual machines hosting your desktops and apps will live in. You’ll need at least one of these before you configure anything else


Select Host pools from the menu on the left.


If you have no host pools as yet you can select the Create host pool button at the bottom of the page as shown or you can select the Add button at the top of the page.


Step one will be to nominate a Resource group for your pool, as well as a Name for your host pool. You’ll then need to select a Location for the pool metadata to live. Note, at this time, these locations are in the US but will expand in the future.


You have a number of options to select from when it comes to Host pool type. Typically, you are going to select the type as Pooled, rather than Personal. This will allow multiple users to share multiple hosts that you create.

You then need to determine Max session limit, which is the maximum number of users your hosts can have. The number you place here will depend on the size of your configuration. The suggestion is to keep it low initially as adding additional hosts is easy when required.

A few suggestions here. I’d suggest you keep all of your WVD infrastructure in the same Azure Resource group and in the same region. To be able to deploy hosts onto the VNet you have already created prior to this, things will need to be in the same region. The location of the metadata configured in this screen is not that important, but where you put your pool and hosts does matter. So, keep it all together in the same Resource group and region I suggest.

Press the Next: Virtual machines button at the bottom of the page to continue.


Here, you can add hosts (VMs) to you pool at the time you create your pool if you wish. You can always add hosts later, so to reduce complexity here, leave this set as No and select the Next: Workspaces button at the bottom of the page to continue.


You can also create a Workspace at the same time you create your pool. Think of a Workspace as a way to group virtual hosts and apps together. You can always add Workspaces later, so to reduce complexity, leave this set as No and select Next: Tags button at the bottom of the page to continue.


Azure tags are a great way to easily categorise Azure resources to help with things like billing and management. Here you can use pre-existing tags or create new tags.

When complete, select the Next: Review + create button at the bottom of the page to continue.


Your selections will then undergo validation as shown above.


If the validation passes, you should see the Create button at the bottom of the page. if you get an error here it maybe because the total number of cores exceeds the quota for the tenant as I detailed here:

Watch the core limit in your Azure tenant

Press the Create to complete the process.


You should then see a deployment screen as shown above and short time later you will see that the process has completed successfully.


If you return to your WVD console and look in Host pools you should now see the pool you just created as shown above.


If you select the Host pool name you should see the details of that pool as shown above.


If you look in the Application groups option from the menu on the left, you’ll see that a default Desktop application group (<Pool name?-DAG) has been created but has no users assigned as yet. You’ll see no RemoteApp application groups have been created as yet.


If you look in Session hosts, you see that nothing in here as yet either. We’ll be added hosts to this pool in the next step in a following article.

Remember, this host pool creation process is part of the Spring 2020 update to WVD. You can also create host pools with PowerShell, which I’ll cover in an upcoming article. However, you now have a container in which you can start adding virtual hosts.

Remote Desktop app for WVD doesn’t work with WIP

*** Solution – ensure the WVD feed URL (e.g. is part of the appropriate definitions in your WIP network isolation configuration


When I tried to update the feeds on my Remote Desktop client on Windows 10 for use with the Spring release of WVD I was greeted with the above issue with Windows Information Protection. (WIP). I tried setting the Remote Desktop app (msrdcw.exe) to be a protected app in WIP and still had the same issue. Also tried setting to be an exempt app, but that also didn’t help-. Only disabling WIP seemed to allow me to refresh the feeds. Once you do this you can turn WIP back on if you need to.

Hopefully Microsoft will address this issue in upcoming releases of he Remote Desktop app for Windows 10. Until then, there doesn’t seem to be much option but disabling WIP.

Watch the core limit in your Azure tenant


So when spinning up a new host inside the new WVD experience I received the error as shown above:

The template deployment ‘AddVMsToHostPool-7b00d9c7-8690-455f-90fa-d69d2661601f-deployment’ is not valid according to the validation procedure. The tracking id is ‘867f4f35-b3dc-42c7-879d-b588517f15d0’. See inner errors for details

I wasted plenty of time looking in other location rather than looking in the “inner error: as recommended. To get there, press the copy button at the top right as shown and then paste the information. When I did do this and actually read what it said I saw:

Operation could not be completed as it results in exceeding approved Total Regional Cores quota. Additional details – Deployment Model: Resource Manager, Location: australiaeast, Current Limit: 10, Current Usage: 10, Additional Required: 2, (Minimum) New Limit Required: 12. Submit a request for Quota increase at

Damm! I gotta read those errors more fully I reminded myself, instead of ‘assuming’ and rushing off elsewhere for solution.

The end result was that I simply needed to lift the core quota for the tenant to allow for the additional VMs. Hopefully, this help someone else wasting time looking for a solution when it is really there in your face.

Azure AD Domain Services Cloud only user passwords

I have been creating a Windows Virtual Desktop (WVD) environment for internal testing. I’ll be sharing the process and tricks soon but this issue was one that I really didn’t know about for Azure AD Domain Services until someone pointed it out to me.  I am eternally grateful to gerry_1974 on the Microsoft Tech Community for this information that lead to the resolution. I thought I’d also share it here so others can avoid the oversight I made and prevent getting as frustrated as I did.

I recently wrote about setting up Azure AD Domain services for a cloud only environment

Moving to the Cloud – Part 3

The reason I needed to do this was to support my planned “cloud only” WVD test environment. Azure AD Domain Services is basically designed to create an ‘old style’ domain that WVD host machines connect to. That will change down the track, but for now WVD needs a traditional AD. Since I did not have an existing on premises domain, I planned to use Azure AD Domain Services.

After getting things working eventually (more about that soon), I was able to successfully login to my WVD environment with a user who didn’t have Multi Factor Authentication (MFA) enabled. I then tried a user with MFA and received:


The remote computer that you are trying to you are trying to connect to requires Network Level Authentication (NLA), but your Windows Domain controller cannot be contacted to perform NLA. if you are an administrator on the remote computer, you can disable NLA by using the options on the Remote tab of the System Properties dialogue box.

I put the issue down to being about MFA but as it turned out, I was so wrong!

When you have cloud only users with Azure AD Domain Services, no password hashes in a format that’s suitable for NT LAN Manager (NTLM) are automatically generated! To force this generation for cloud only users, it is required that the cloud only user change their password per:

Enable user accounts for Azure DS

which says:

The steps to generate and store these password hashes are different for cloud-only user accounts created in Azure AD versus user accounts that are synchronized from your on-premises directory using Azure AD Connect. A cloud-only user account is an account that was created in your Azure AD directory using either the Azure portal or Azure AD PowerShell cmdlets. These user accounts aren’t synchronized from an on-premises directory.

and most importantly:

For cloud-only user accounts, users must change their passwords before they can use Azure AD DS. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Azure AD.

After having this brought to my attention, I understand why this is but would also say this could be a very painful process if you have a lot of users that are wanting access to something like WVD.

Thus, another little configuration tip to remember if you are setting up a cloud only environment that utilises Azure AD Domain Services. Before users can potentially use services that are dependent on Azure AD Domain Services (like Windows Virtual Desktop) they need to change their password so the NTLM password hash can be generated for use by Azure AD Domain Services.

What you need for Windows Virtual Desktop (WVD)


Windows Virtual Desktop (WVD) is now generally available and I’ll be covering off how to set it up in upcoming articles. However, before you even login to your Azure tenant to start setting this up, here’s what you’ll need:

1. A Windows Virtual Desktop license for every user who want to use the service. These come with all Microsoft 365 and Windows E3 and E5 suites.

2. A paid Azure subscription. The majority of the cost of the WVD service will be your Virtual Machine hosts. The cost of these will vary on how many you want to use and how long they run for.

3. Azure Active Directory. The users who access the WVD service need to be in Azure AD. These users can be cloud only or synced from on premises using Azure AD Connect.

4. A Domain Controller (DC). At this point in time the WVD still requires a ‘traditional’ domain controller to allow the VMs to connect to for access. If you only have cloud users then the easiest option to achieve this is to add Azure AD Domain Services. If you already have an on premises Domain Controller (DC) you’ll need a Site to Site (S2S) VPN to link your on premises network to Azure. Note, that if you have an on premises DC that is using Azure AD Connect you can’t just add Azure AD Domain Services because Azure AD Connect doesn’t sync ‘traditional’ DC attributes. So, if you have an on premises DC, even if it is already using Azure AD Connect, you’ll still require a S2S VPN to Azure to allow the WVD service to connect VMs to that domain.

5. Azure AD tenant ID. Each Azure AD has a unique number which you can get from the web interface or via PowerShell. This is because it is possible to have multiple AD’s inside Azure and each can be configured and connected differently. The WVD service will need to know which specific Azure AD to connect to when provisioning.

6. Azure Subscription ID. The costs of the WVD service need to be applied against a unique subscription inside Azure. again, remember it is possible to have multiple independent subscriptions inside an Azure tenant. The WVD setup will need to know which subscription to bill for the service.

7. Azure tenant admin account. This will typically be a global administrator of your Azure environment. This will typically be the user who sets up, configures and manages WVD. They will also typically be an administrator of the domain that is connected to Azure AD.

8. Domain join account. This is an account that has the rights to join machines to the domain. The WVD service will create a number of VMs that need to be connected to the domain so that users on the domain can login to these machines in your WVD environment. You may wish to have a domain join user who is not a global administrator for security reasons but you should also be aware of the potential password requirement differences between your domain user and the Azure admin account. You may wish to use the same Azure admin account as your domain join account. If so, just beware of the password requirement policy for these.


As you can see above, the domain join account has to be at least 12 characters long, plus 3 of the following – 1 lower case character,  1 upper case character, 1 number, a special character. That requirement may be different from what your Azure AD or on premises AD requires. My recommendation would be to create a stand alone domain join account that meets the requirements and is only used for joining machines.

9. Azure Virtual Network (VNET). You’ll need a pre-existing VNET for the WVD machines to connect to. When you implement Azure AD Domain Services or a S2S VPN to connect an on premises DC, you’ll need a VNET. Make sure you understand the IP addressing and subnetting of your Azure VNET when you create it, as changing it later can be very painful.

10. Appropriate skill set. WVD requires a range of skills and understandings including:

– Identity management

– Azure AD

– PowerShell

– Azure IaaS including VNETs, VMs, Storage, etc

– Networking

– Azure backup, imaging, etc

Can you bumble you way through without these? Maybe, but life will be much easier if you do have these skills and really, if you are planning to work in the Microsoft Cloud environment, these should be considered mandatory.

There you have it, ten pre-requisite items to get sorted before you launch into creating a WVD for yourself. Get these sorted prior and your installation will be much smoother!

As I said, I’ll have upcoming articles on how to set this up, so stay tuned.