- Azure AD without on-prem Windows Active Directory? - Mon, Oct 25 2021
- An overview of Azure security - Mon, Mar 29 2021
- An introduction to Azure AD administrative units - Wed, Jan 6 2021
Windows Virtual Desktop requirements
Subscription
The first requirement for any Azure service, including WVD, is an Azure subscription. There is no charge for creating a subscription, and Microsoft offers a free subscription that comes with a $200 credit and a year of other free services. If you don't have a subscription, follow the link below to get started.
Free Azure Subscription https://azure.microsoft.com/en-us/free/
There is no fee to use the WVD service. However, there is a fee associated with the virtual machines used to host the user sessions. The cost depends on the size of the virtual machine, OS type, and disk used to deploy the server and the region of the virtual machine. The charge for Azure virtual machines can be stopped by deallocating the virtual machine from within Azure.
Active Directory domain services
Windows Virtual Desktop uses Azure AD for client authentication. Azure AD is the authentication method used for logging into the HTML5 web client or the Remote Desktop client, which support modern authentication.
In addition to Azure AD, the WVD Session Hosts must join a domain at the time of deployment. A user that logs into the WVD desktop or application must be a member of the domain to which the VM joins. There are two options: the Session Hosts can join a Windows AD domain or an Azure AD DS domain.
A Windows AD domain controller must be available if you are joining the session host to a Windows AD domain. Connectivity is accomplished by deploying a Windows AD domain controller on an IaaS server in Azure or with a VPN or express route between an on-premises Windows AD network and Azure.
For organizations that don't want to deploy domain controllers in Azure, Azure AD DS is an option. Windows Virtual Desktop Session Hosts can join an Azure AD DS domain at the time of deployment. There is a fee for Azure AD DS, and the service has to be in place for the WVD deployment to succeed. Although identities are synchronized between the directory services, the Azure AD DS domain is a separate domain from the on-premises Windows AD Domain. Azure AD DS does not support domain or forest trust relationships, and it is not possible to extend the schema. These restrictions may limit an organization's ability to use the product.
Networking
A Virtual Network (VNet) is required to deploy WVD Session Hosts. Not only is a VNet needed, but it also requires access to an Active Directory domain, either Windows AD or Azure AD DS. The need for existing domain connectivity is a point that is often missed and will cause errors during deployment.
There are a few steps that happen when you deploy a WVD Session Host. At a high level, WVD creates the IaaS VM, which is then added to the domain. Next, the WVD agent is installed and registered in the WVD environment. The IaaS VM has to register to an Active Directory domain for the deployment to succeed. If the domain is not available, the deployment will fail.
Deploy Windows Virtual Desktop
Now that all the prerequisites are in place, it's time to deploy the WVD service. The following steps will deploy a new WVD and prepare it for user access. This deployment uses a Windows 10 multi-session image available from the Microsoft Image Gallery.
From within the Azure Portal, search for and select Windows Virtual Desktop.
Search for WVD
Once in the WVD window, click Create a host pool. This action starts the wizard.
Create a host pool
Creating a Host Pool will start the wizard. From the Basic window, select your subscription and Resource Group. Alternatively, you can create a new resource group Give the host pool a name and select the location for the host pool. Leave the Validation environment option set to No.
Create a basic host pool
Set the Host pool type to Pooled, leave the Max session limit blank, and set the Load balancing algorithm option to
Breadth-first.
Host pool type
Click Next: Virtual Machines to configure the virtual machines.
In Create a host pool, set Add virtual machines to Yes. Change the following settings as shown below: - Resource Group—Defaulted to the same as the host pool.
- Virtual machine location—Leave the default.
- Virtual machine size—Set to a smaller size for a lab deployment such as B2ms.
- Number of VMs—Set to 2 for the lab deployment.
- Name prefix—Give the VMs a name. The prefix will have a dash and number added to each VM.
- Image type—Leave as Gallery.
- Image—Select Windows 10 Enterprise Multi-session.
- OS disk type—Leave as Standard SSD.
Under Network and Security, set the Virtual Network to the VNet with connectivity to your Azure AD environment. Update the following settings as shown below:
- Subnet—Set to a subnet for the deployment.
- Public IP—No public IP needed.
- Network security group—Leave as Basic.
- Public inbound ports—Leave as No.
Network and security
Leave the Specify domain or unit as is and add a domain user account with rights to add computers to the domain, along with the account password. Click Next: Workspace
once finished.
Administrative account
In Workspace, set Register desktop app group to Yes and create a new workspace. Click Review + create to finish. The deployment should pass the validation and be ready for deployment.
Workspace
Click Create at the bottom of the window to create the host pool. The deployment will begin and take a few minutes to finish.
Administrative account 1
Once finished, the portal will show a message that the deployment is complete.
Your deployment is complete
Troubleshooting
Hopefully, the steps provided above helped you deploy a WVD environment without issues. If you have problems, there are a couple of things to try that may identify the issue. The first is to verify that the VNet has connectivity to the Active Directory domain, and the domain join account has the correct rights to join a computer to the domain.
An easy way to test this is by deploying a new Windows IaaS VM on the same VNet and subnet used for the WVD deployment. Once it is running, log on as local admin and join it to the Active Directory domain using the same domain join account used for the deployment. If that fails, the WVD deployment will also fail. Troubleshoot and resolve the failure with the test VM before continuing with the WVD deployment.
If you experience an error that has to do with capacity or quotas, the Azure subscription may have reached a limit in the amount or type of VCPUs in use. A subscription has a VCPU quota and will not deploy servers if the VCPU limit is reached for a VM type or region. Go to Subscriptions in Azure > Usage > Quotas and change the filter to Microsoft.compute. The portal will display the number of VCPUs in use by VM family and region. Any quotas can be increased by submitting a support request.
Usage and quotas
Verification
Once the deployment finishes, it's time to test by logging into the host pool. Before we can log on, there is one more step needed to complete the deployment. By default, no user is assigned to log on to the desktop application group. Follow the steps below to give a user access to the remote desktop.
Search for and go to Windows Virtual Desktop.Search for WVD
Go to Application Groups
and select the default desktop application group added in the deployment. This example was WVD_HP-DAG.
WVD application group
From within the application group, go to Manage > Assignments.
Application group assignments
At the top of the Assignments window, click Add.
Add assignments
Search for and add a user or group that will test desktop access. Click Select
when finished.
Add user assignment
Now for the moment of truth. If all went well, there should be functioning WVD Session Hosts for the test account to log on to. The steps below will use the HTML5 client to test functionality.
Open an HTML5-compliant web browser (Chrome or Edge) and go to:
https://rdweb.wvd.microsoft.com/arm/webclient/index.html
Log on to Azure AD with a user account that was added when the host pool was set up.
Log on to WVD web
Click the desktop icon to start the session.
WVD desktop
Log on to the default Windows desktop with the Active Directory domain services credentials of a user account granted access to the application group.
At this point, you should be logged on to a desktop hosted on WVD.
Stop charges
One last but important step for lab and test environments is to deallocate the Session Hosts when not in use. There is no charge for the WVD service, but there is a charge for the compute, storage, and network services used for the Session Hosts in the host pool. Costs can be reduced by deallocating the servers from within Azure when they are not in use.
Deallocate a VM
Summary
The deployment of WVD requires some prerequisites. An Azure subscription and a virtual network are needed. The virtual machines that host users' sessions must have connectivity to either Windows Active Directory or Azure AD domain services. Once the prerequisites are in place, the service can be deployed and tested with the HTML5 or Remote Desktop client.
The information above is a starting point for implementing WVD. Other sizing and management considerations need to be considered before deploying the service in a production environment. A solid foundation in the basics of the requirements and deploying the service provide a good starting point for anyone considering the solution.
