This is part 3 of our posts regarding Windows Virtual Desktop, until now we have covered:
- Part 1 – Created a Windows Virtual Desktop tenant – Part 1
- Part 2 – Created a service principal and some customization of our on-premises AD – Part 2
In this part we will create a host pool, first thing is to go to the Azure portal and create a new resource.
Search for Windows Virtual Desktop and select Windows Virtual Desktop – Provision a host pool.
When Windows Virtual Desktop – Provision a host pool is shown click Create.
In this test we will create a new Resource group, Create new.
Name the resource group.
We will then set the region we want to use here West Europe, name the hostpool, select the Desktop type here Pooled, and finally enter our test user from our on-premise AD which is synchronized to Azure AD (test1@mindcorelab.dk) – this user was created in Part 2.
Then continue by clicking Next: Configure virtual machine.
For now the only Metadata location is United States!
Windows Virtual Desktop comprises the Windows desktops and apps you deliver to users and the management solution, which is hosted as a service on Azure by Microsoft. Desktops and apps can be deployed on virtual machines (VMs) in any Azure region, and the management solution and data for these VMs will reside in the United States (US East 2 region). This may result in data transfer to the United States.
For the test we will choose Light Usage Profile, total users set to 5, and then change the size.
We select A2_v2 for this test.
This will result in a single A2 v2 host for this test setup.
Our prefix will be set to DSK.
The prefix will be used for the names of the virtual machines. For example, if you enter DSK like here, the virtual machines will be called DSK-0, DSK-1, and so on as shown in this example:
When ready continue to next page Virtual machine settings.
For this test we will use an image from the galley – Windows 10 Enterprise multi-session with Office 365 ProPlus, this will be an easy way to start, but of course you can use your own images.
We will use Disk type as Standard SSD for performance.
AD domain join UPN will be set to the domain joint account we created in Part 2, and the password we gave the service account.
We need to be aware that this account (same username and password) will be created on the virtual machines as a local account.
In this test we want the computers to be created in our OU called WVD, so we specify Domain to join and OU Path (uppercase for OU= and DC=).
For the virtual network and subnet I will use the network connected to our on-premises infrastructure with a VPN tunnel.
In order for us to continue we need the saved service principal password from Part 2.
We also need Windows Virtual Desktop tenant group name (TenantGroupName), Windows Virtual Desktop tenant name (TenantName) and Azure AD tenant ID (AadTenantId).
You can get these values if you connect to Windows virtual desktop and use the command Get-RdsTenant.
And last we need the Application ID (Appid) of the service principal, you can get this value by connecting to Azure AD and use the commands.
$AzureADServicePrincipal = get-AzureADApplication -SearchString "Windows Virtual Desktop Service Principal"
$AzureADServicePrincipal.AppId
With all information collected let’s fill it in, and remember to use Service principal.
Hopefully this should result in validation passed, and we can create.
Deployment will then start.
If all behaves the way we expect you should see the deployment complete.
In our on-premises Active Directory we can now find the computer joined to our domain and placed in the correct OU.
Since this is only a test I will enable auto-shutdown of my hosts to save money.
In part 4 we will add FSLogix to the equation – stay tuned.
