Ash Roberts
SwitchITUp

SwitchITUp

Setting up an Azure Virtual Desktop Lab

Setting up an Azure Virtual Desktop Lab

Ash Roberts's photo
Ash Roberts
·Sep 3, 2022·

8 min read

Table of contents

  • Introduction
  • Architecture
  • LAB Design
  • Azure AD Users/Groups
  • Resource Groups
  • VNET / Subnets
  • Bastion
  • Azure Active Directory Domain Services
  • Storage Account
  • Azure Virtual Desktop
  • Test Bastion
  • Summary

Introduction

This article is going to give you the basis to form an Azure Virtual Desktop (AVD) lab you can use to practice the technology in Azure.

Pre-requisites

  • An Azure Subscription (I'm using MPN with £115.00 credit per month) part of MVP benefits. If you are Microsoft Certified you can apply: login @ my.visualstudio.com

Azurebenefit.jpg

  • Microsoft 365 developer program - Here you can sign up for a 365/Azure tenant for DEV/Training purposes fully loaded with sample users and full Licensing. I invite my MPN subscription holder into the tenant then transfer the subscription into the DEV tenant so I can use my credits ;) developer.microsoft.com/en-us/microsoft-365..

developer program.jpg

  • Global Administrator Account
  • Enable "Microsoft.DesktopVirtualization" resource provider on your subscription. You wont be able to deploy AVD without this. (see below)

subscription-resourceprovider.jpg

There will be a cost associated with this setup AADDS alone is approx £90 a month for basic SKU, that's before you take into account storage costs and VM run times etc.

But follow this guide and you will have plenty of credit to burn just remember to turn off VMs when not using them and decom your environment when not in use to save costs.

Architecture

First lets quickly review the architecture:

architecture.jpg

The reference Architecture above, courtesy of Microsoft, shows how in a perfect world you would consider setting up your resources. The setup above takes into account On-Premise ADDS that is being synced to Azure Active Directory Via AD Connect. The on-premise domain is also extended into the cloud with virtual domain controllers sat in Azure. The idea being is putting these DC's in the same region as your AVD can speed up DNS/Authentication response times.

You also need to take into account how you extend your on-premise network into Azure. The above shows express route but you could also use site-to-site VPN.

I am going to make this a little less complicated by going cloud only and replacing ADDS with Azure Active Directory Domain services (AADDS). It's perfectly viable and great to just be able to get into the nitty gritty of how this all fits together.

LAB Design

Below I have altered the reference architecture diagram to show my cloud only setup:

mytopology.jpg

ADDS will be replaced with Azure ADDS

I have added a Bastion subnet so you can access the session hosts without the need for a public IP to make any required changes locally on the VM. I have written a post on Azure Bastion so if you need more info on how this works/what it does check the link below:

switchitup.tech/azure-bastion-secure-admin-..

Lets get Building!

Azure AD Users/Groups

Create the following groups in your Azure Active Directory. You will need to fully license your testuser1, if you are using the 365 dev program you can assign full E5 Licensing.

user-group-creation.jpg

Example:

testuser1.jpg

Resource Groups

I will create three resource groups to hold our resources.

  • RG_VNETS (UK SOUTH) - Hold the VNET/Bastion/Subnets

  • RG_AADDS (UK SOUTH) - You will deploy AADDS to this RG

  • RG_VirtualDesktop (UK SOUTH) - All AVD infrastructure components here

VNET / Subnets

  • VN_Production - 192.168.0.0/16 (UK SOUTH)

vnet-addressspace.jpg

When you create your AADDS tenant shortly you will be given two IPs of your DC/DNS servers on the properties page. You will need to put these IPs into the DNS settings of your "VN_Production" VNET. This is so your session hosts can reach the domain controllers so they can domain join, otherwise this will fail later.

dnsservers.jpg

Subnets

  • Subnet - 192.168.1.0/24 - AADDS

  • Subnet - 192.168.2.0/24 - AVD

  • Subnet - 192.168.3.0/24 - Bastion

vnet-subnets.jpg

Bastion

You can create Bastion from the "Security" tab of the VNET creation Wizard, this will create a subnet called "AzureBastionSubnet" on the address range you specified, in this case 192.168.3.0/24. You will need to create a new public IP to attach to Bastion this is also part of the wizard you follow.

setup-bastion.jpg

You will see Bastion in the "RG-VNETS" resource group upon completion of the VNET setup wizard you can click on it to verify the setup:

bastion-verfication.jpg

Azure Active Directory Domain Services

  • Create a domain name e.g - switchitup.tech

  • Forest Type = User

  • Region = UK South (keep consistent with other resources)

  • Resource Group = RG_AADDS

After deployment two IP addresses for your domain controllers/DNS will be available you can find this in properties (see example below)

aadds settings.jpg

This can take awhile to deploy so be patient.

Return to your VNET DNS Settings and populate the IP addresses with your two DC IPs (as shown above under VNET section)

Storage Account

Used to store Gold Images and hold user profile data if you deploy FSLogix profile containers. (I will cover this in another post but we will pre-stage it here)

  • name (must be globally unique) = sasiufslogix (Storage Account Switch it up FSLogix)

  • General V2

  • Performance Standard

I have used the above to keep costs down. For a minimal lab this will suffice. In production it's recommended you use premium SSD storage Azure Files or Netapp Files for environments over 200 users.

storageaccount-settings.jpg

Create a file share

  • Name = FSLogix-Profiles

fileshare-creation.jpg

For more information on Azure File Shares see my other post "Managing Azure File Shares": switchitup.tech/managing-azure-file-shares

Domain Join the storage Account to AADDS

On your FSLogix-Profiles share click on the Active directory (Not configured) hyper-link.

domainjoin-sa-1.jpg

Select Azure Active Directory Domain Services - Configure, on the pop out blade tick the box, this will go away and join to AADDS. Why do we need this? It allows you to use NTFS permissions for more granular control within you VMs. This will be needed for FSLogix setup (I will cover this in another post).

domainjoin-sa-2.jpg

Create a Service Endpoint

Go back to your Virtual network and select "Service Endpoints", we are going to create an endpoint to our Storage from AVD subnet.

serviceendpoint-creation.jpg

serviceendpoint-descriptionb.jpg

basically access will go across Microsofts backbone and not be exposed publicly. If you navigate back to your file share you will notice you don't have permission to the resource. This is due to this change and you can add a rule in the Storage Accounts networking tab to allow access from YOUR public IP.

nopermission-storageaccount.jpg

storageaccount-networking.jpg

After allowing your public IP access you will be able to navigate back to the Azure Share.

Azure Virtual Desktop

Now we have our basics setup we are ready to deploy AVD. Search "Azure Virtual Desktop" in Azure services and select it to be taken to the AVD page. Here we are going to create a new host pool with the wizard which will create everything we need:

  • Host Pool

  • Application Group

  • Workspace

  • Session Host VM(s)

avd-create a host pool.jpg

hostpoolcreation-basics-1.jpg

hostpool-vmcreation-1.jpg

hostpool-vmcreation-2.jpg

hostpool-vmcreation-3.jpg

hostpool - workspace creation.jpg

createhostpool - validation.jpg

Create your deployment.

When your deployment is complete you can select hostpools in AVD to see your new hostpool1 and session hosts within here allows you to view the VM session host we created

hostpool1 - verification.jpg

sessionhost- verification.jpg

Drill into your session host again and we can see the deployment status - handy for checking if it domain joined! We can see here it has and has switchitup.tech as FQDN.

sessionhost- deploymentcheck.jpg

Key Points

  • Domain Join account must exist in Azure AD, be a member of AAD DC Administrators and NOT have MFA enabled or Domain join will fail. I did not need to license this account.

aaddcadministrator.jpg

  • You must also have your AADDS DC IP's in your VNET DNS server settings. Do not edit DNS servers in the Session host(s).

  • If Domain Join fails you can login to the session host via Bastion locally and join it to the domain with your chosen account with the above settings.

  • If you select Azure AD in your VM creation you won't be domain joined but registered to the Azure AD Tenant (NOT AADDS).

  • I have created a single session host to keep costs down with depth first load balancing, this will fill the session host up to max sessions we chose (10) at creation before sending new connections to a second session host (if we had one). Or you can get more fancy with an automation account and increase the session host number when you reach a certain session limit or usage.

  • Multi-session windows 10 image with office 365 apps is pre optimized for multi-session use and has 365 apps pre-installed it also comes with FSLogix Agent pre-installed so you can play with user profile containers later with minimal setup :).

  • This is a pooled deployment - desktops are not assigned or persistent.

Test Bastion

Navigate to "RG_VirtualDesktop" resource group and select your session host VM resource. Select connect > Bastion. Enter the local admin credentials you created when we created the session host (vmadmin)

If you're like me and forgot what account you setup (lol) go to the Session host VM resource - Export Template - Scroll down to OS profile and you will see the admin account name. (no password unfortunately but I didn't have that problem).

vmad-verfication.jpg

bastiontest1.jpg

If successful your connection will open in your browser.

sessionhost-bastion-validation.jpg

Summary

Finally we have a complete AVD base setup we can use to lab with. My next blog post will cover how we setup access for users to our AVD setup.

Don't forget to turn off your session hosts when finished to minimize costs. If you don't plan to come back to this for a few days you may want to decom and rebuild to make more savings.

 
Share this