More and more organisations are leveraging virtual desktops to scale up their compute resources. The security blueprint to protect your virtual desktops should be well designed, implemented, monitored, and controlled.
In the first part of a two part series we look at the availability for remote users on a VDI infrastructure and how to set this up. Part two will walk through how to ensure your VDI solution is scalable on Azure.
Azure Virtual Desktop (formerly known as WVD), is a desktop and app visualisation service that runs on Microsoft cloud. There are several things that you need to consider when deploying Azure Virtual Desktop:
- Set up a multi-session Windows 10 deployment that delivers a full Windows 10 with scalability;
- Virtualize Microsoft 365 Apps for enterprise and optimize it to run in multi-user virtual scenarios;
- Provide Windows 7 virtual desktops with free Extended Security Updates;
- Bring your existing Remote Desktop Services (RDS) and Windows Server desktops and apps to any computer;
- Virtualize both desktops and apps;
- Manage Windows 10, Windows Server, and Windows 7 desktops and apps with a unified management experience.
There is more information that I can share regarding Azure Virtual Desktop but most of these can be found here directly from Microsoft.
Scenario 1
Company A wishes to take advantage of Deploying Azure Virtual Desktops. The requirements, for starters are the following:
- A shared virtual desktop - Can be used by at least 3 users;
- Virtual Desktop should have 2vCPU's and 8GiB memory;
- Virtual Desktop should be running on Windows 10;
- Domain Joined;
- Connected to their network - Wants to have something outside of Azure Express Route;
- Organization already have an Azure Subscription and On-Premise users are already synced to Azure AD.
Approach
We deploy at least one or two Azure Virtual Desktop Instance(s) which is connected to their On-Premise AD. To achieve the domain-joined scenario, we will be using instead an Azure Virtual Network Gateway setup as a Site-to-Site connection. The organization will have an option to deploy their choice of VPN appliance but for now, we will utilize a Windows Server 2019 configured for Remote Access to enable connectivity. Below is the list of tasks that we are going to complete.
- Deploy Virtual Network and create an Azure VPN Gateway;
- Configure Remote Access on a Windows Server 2019 and establish connection;
- Deploy Azure Virtual Desktop and confirm connectivity and access.
Let’s roll!
Deploying Virtual Network and Azure VPN Gateway
Telstra begin by creating a Resource Group (avdRG) and then the setup of the Virtual Network. The Virtual Network we create is configured with an Address Space of 192.168.1.0/24 with a subnet (AVDSubnet) if 192.168.1.0/27 to be used by our Azure Virtual Desktop instances.
Once we have sorted out the Virtual Network, next we create the Azure VPN Gateway. It gets setup as a VPN, using Route-based policy. SKU selected is VPNGw1, to add more throughput than the basic SKU and support IKEv2. We then select an address range (192.168.1.32/27) that will be created within the Virtual Network as the GatewaySubnet. A resulting Public IP (23.100.19.191) will be created as well once we create the vpngwpubip resource included in this setup.
We are now done with the first task, let's move on to the next one.
Configure Remote Access and establish connection
We now jump into a Windows Server 2019 to use in replacement of an actual VPN appliance which is normally being used. We need to add the Remote Access role, and the role service DirectAccess and VPN(RAS).
Once the role and service has been setup, open the Routing and Remote Access page then configure the routing and remote access. The following screenshots should help set this up.
Once the configuration has been done, the next task is to configure the Demand-Dial connection. This will configure the connectivity between our Remote Access Server and Azure VPN Gateway.
We are going to use IKEv2 as the VPN type, which is supported by the Azure VPN Gateway SKU we have selected earlier. For the destination address, we use the Public IP that has been assigned to the Azure VPN Gateway SKU during creation.
For the static routes, we can include the Azure Subnet we created or we can include the whole address space that has been configured in the Virtual Network. For this example, the subnet assigned for the Azure Virtual Desktop has been used.
We purposely left the Dial-Out Credentials blank as we are going to use a preshared key as credential between our Remote Access Server and Azure VPN Gateway. Click Next and click Finish on the next window.
Once we are done, open the Properties window for the VPNtoAVD Demand-Dial we created.
Select Persistent Connection from the Options tab, and enter the preshared key(ex. 1234567890) then click OK.
Now that we have done the configuration for our Remote Access Server, we are going to setup the Site-to-Site connection from Azure VPN Gateway. From the Azure VPN Gateway, we go down to Connections and click Add.
In the Add connection pane, we configure a Name, and set the Connection Type to Site-to-Site (IPSec). We also enter the Shared Key that we configured on our Remote Access Server and select IKEv2 as the protocol.
Select Choose a local network gateway, click create new. Enter a name, select either IP Address or FQDN for the endpoint then enter the appropriate value. In this example we are using the public IP Address of the Remote Access Server. We also need to enter the local address space from our internal network.
Once we are done, we can go back to our Remote Access Server and initiate the connection from the Demand-Dial interface we configured.
Once it connects, both the Remote Access Server and Azure VPN Gateway should now say connected.
That was quite a long one! Now finally, on to our last task.
Deploy Azure Virtual Desktop and confirm connectivity and access
First thing that we need to do is to make sure that the domain is reachable via FQDN, since by default connectivity is allowed within Virtual Networks (including connected remote network) there are no additional configuration for Inbound rules. What we need to set in the Virtual Network is the IP Address of the DNS server from our On-Premise environment.
Once this is done, we move on to deploying our Azure Virtual Desktop. From the Azure Portal search window, we look for Azure Virtual Desktop and open it.
We first create a host pool, based on the requirement the instance should be shared and can be shared across 3 users. So we select the Host Type - Pooled with maximum of 3 users. For the load balancing algorithm, we have an option to either use Breadth-First (load balancing is spread out among all instances) while Depth-First distributes new sessions to an available instance with the highest number of connections. For this example, we use Breadth-First.
On the next screen, we enter the parameters to deploy the Azure Virtual Desktop instance. Based on the requirement we have selected the options as shown in the image.
The lower half of the page includes the settings to join the Azure Virtual Desktop to the domain. We select Active Directory (other available option is Azure AD), the admin credential to be used to join the domain, and OU (optional)
Local admin credentials are also required for the instance to be created.
Let us create a workspace as well as a placeholder for our Apps (including the Azure Virtual Desktop sessions)
Once it has been done, we can create the Azure Virtual Desktop instance.
As soon as the deployment is done, the Azure Virtual Desktop is joined to the domain and can be accessed internally.
To grant access to users to be able to access them via Windows Desktop Client and Web Client, we need to go to Azure Virtual Desktop and open Application Groups. Open the created Application Group.
Add the users that are tasked to use the Azure Virtual Desktop instances.
Once the users have been added, confirm connectivity by using a Web Client. Open https://rdweb.wvd.microsoft.com/arm/webclient and login using the Azure AD credential that has been delegated access.
Open the SessionDesktop and login using the same credential since the On Premise AD is synced to Azure AD.
Azure Virtual Desktop can be access via multiple options such as Windows Desktop Client, Mobile Clients, and Web Client. For accessing them using the mentioned options you can check the Microsoft Documentation here.
Conclusion
We have now configured the Azure Virtual Desktop and have joined the instance to the On-Premises domain. There are multiple applications and requirements that can be met using AVD and this is only one example. We will explore the capabilities of Azure Virtual Desktop and provide more insight in the future.