Category: 100 Days of Cloud

Its Day 92 of my 100 Days of Cloud journey and in todays post we’ll continue our Demo build of an Azure Virtual Desktop environment!

In Part 1, we got through the following tasks:

• Created our Log Analytics Workspace for logging our monitoring data
• Created our Test Users in Azure AD
• Created the Host Pool
• Created the Assignments to allow users to access the desktops
• Created the Service Hosts
• Verified that Diagnostic Settings are working
• Added our Session Hosts into Monitoring

Lets dive back in where we left off and configure our Application Groups.

Application Groups

An Application Group is a logical grouping of applications installed on session hosts in the host pool. They are of two types:

• RemoteApp
• Desktop

An application group of type ‘Desktop’ was created automatically while creating the Session Hosts.

Lets check to ensure our users are assigned to the Desktop application group. To do this, we click into the Desktop Group, choose the “Assignments” option under “Manage”.

We can see that the users are assigned, but do not have an “Assigned VM”. This is because for Personal Host Pools the users will be automatically assigned a VM when they try to launch the desktop, and their user session will be load-balanced to an available session host if they haven’t already connected to the host pool. There is an option to configure direct assignment – you can find more details and commands on how to do this in the article here.

Because we are using a Personal Host Pool and alreay have a Desktop pool assigned, it means we cannot add an RemoteApp Application Group to the same host pool – if we wanted to do that we would need to either use a Pooled Host Pool or else create a new Host Pool.

We can see if we try to create a new Application Group in the same Host Pool, we get an error when we select the existing Host Pool:

The official line in the Microsoft Docs article here states:

• We don’t support assigning both the RemoteApp and desktop app groups in a single host pool to the same user. Doing so will cause a single user to have two user sessions in a single host pool. Users aren’t supposed to have two active user sessions at the same time, as this can cause the following things to happen:
  • The session hosts become overloaded
  • Users get stuck when trying to login
  • Connections won’t work
  • The screen turns black
  • The application crashes
  • Other negative effects on end-user experience and session performance

And this makes sense – its easier to have Desktop Sessions as part of one host pool and Application Sessions as part of another.

Lets move on to looking at the different methods for connecting our users to their Desktop Sessions.

Access the Published Desktop using Browser or Remote Desktop Client

Open the following URL in a new private mode browser tab (or incognito mode) in your own workstation/laptop. This URL will lead us to the Remote Desktop Web Client.

aka.ms/wvdarmweb

This will launch a logon screen – we’ll use the “Bruce Wayne” account to sign on:

And once we get signed on, we can see our Session Desktop available:

We’ll launch the session and this will ask to to allow access to local reesources. Choose your preferences here and click “Allow”

This will again ask for credentials, so we enter these and click Submit:

And it fails …..

Hmmm, why is that. Time to go off into the weeds to look into this.

So a few hours later and I’m still trying to get this working. And what I’ve found out in that time is as follows:

For Azure AD-Joined VMs, in order to access the session host the desktop you are connecting from must meet one of the following conditions:

• The local PC is Azure AD-joined to the same Azure AD tenant as the session host.
• The local PC is hybrid Azure AD-joined to the same Azure AD tenant as the session host.
• The local PC is running Windows 11 or Windows 10, version 2004 or later, and is Azure AD registered to the same Azure AD tenant as the session host.

So, this was never going to work from my local PC across the internet.

So to get around that, I spun up a new Windows 10 VM in Azure and Azure AD-joined it in the same way as my session hosts are. And tried to access my Azure Virtual Desktop pool from there…..

And it failed with the same errors……

I’ve also checked and ensured the following:

• The users are assigned the Virtual Machine User Login Role for both the Host Pool and the Resource Group where the Session Host VM’s are deployed.
• The users are assigned the Virtual Machine Administrator Login Role for both the Host Pool and the Resource Group where the Session Host VM’s are deployed.

The funny thing (if we can call it funny…) is that although Log Analytics is reporting errors with signins, everything looks to be set up correctly. Johan Vanneuville has already written an excellent article about this, and advised that signin errors can be fixed by enabling PKU2U authentication in the Local Security Policy on each VM:

Thats been checked, its enabled but its still not allowing logins.

So as a last resort, I added a Public IP Address to each of the Session Hosts and tried to RDP and logon directly to them using both Bruce and Clark’s Azure AD logins. And they can both logon over RDP, but not using Azure Virtual Desktop!

So this hasn’t worked unfortunately 😦 ….. Sorry!

If it had, the virtual desktop would have launched and looked similar to the screenshot below:

To close off this section, I’m sure it does work, but I’m probably going to rip up the environment and start again. However, I’ve seen other threads such as this one and this one which have both included some excellent suggestions from the community, but there has yet to be a definitive answer or fix on what the issue is and how to resolve it.

Log Analytics

Lets close this post off by looking at Log Analytics and the data that was gathered from our Azure Virtual Desktop deployment. We’ll go to our Resource Group and click into our Log Analytics Workspace:

If we click on “Log” under the “General” menu, this gives is a splashscreen with a list of builtin queries available to run for a number of different Azure resources, and there is a full section for Azure Virtual Desktop:

If we run the “Connection Errors” query, this will paste a Kusto Query Language (KQL) query and will generate a set of results based on the query:

There are also a number of options to create alert rules based on queries or export the query results to CSV, Excel or Power BI.

Conclusion

So thats the end of this post, where we attempted (but ultimately failed for now) to get our Azure Virtual Desktop demo working. We did manage to capture all of the data in Log Analytics though, so maybe a bit more sifting through that will give the answer.

And here’s a chance for all you community memmbers to get involved – lets see if we can get this working! In the meantime, I’ll keep working on this and may rebuild the environment from scratch again to see if I’ve missed anything.

For those of you with any doubts, Azure Virtual Desktop does work! The Azure AD integration is a recent feature, and AVD is mostly deployed using synced AD DS identities.

Next time, I’ll give a run through of FSLogix and also how to create custom images for AVD.

Hope you enjoyed this post, until next time!

Its Day 91 of my 100 Days of Cloud journey and as promised in todays post we’ll start our Demo build of an Azure Virtual Desktop environment!

In the last post, we looked at a high-level overview of the benefits and concepts of Azure Virtual Desktop, and the management responsibilities of both Microsoft and the Customer.

Lets dive straight into the Demo and set up our sample Azure Virtual Desktop environment.

Prerequisites

We need to set up our prerequisites and in this case there are only 2 that we need. Firstly lets set up a Log Analytics workspace which we can send all of our log data to. So we log onto the Portal, click “Create a resource” and search for Log Analytics Workspace. And click Create:

We’ll select our Subscription and create a new Resource Group. We’ll also give our Workpace and name and select a region where it will be stored. Once thats done, click “Review and Create”:

As you can see, we default to a “Pay-as-you-go” pricing tier. Click “Create” to create ourLog Analytics Workspace:

Once thats created, the next thing we need is Authentication. To deploy Azure Virtual Desktop environment, we need either:

• Azure Active Directory
• Active Directory Domain Services

I’m going to use Azure AD for the purposes of the lab, and have created some users already. Its always great to see Bruce, Clark and Tony ready for action:

And thats the prerequisistes done – we are now ready to create the host pool.

Create Host Pool

A Host Pool is a collection of Azure virtual machines that register to Azure Virtual Desktop as session hosts when you run the Azure Virtual Desktop agent. All session host virtual machines in a host pool should be sourced from the same image for a consistent user experience.

So what we’ll do in this section is as follows:

• Create a Host Pool named MD-AVD-HP01 of personal type.
• Register the default desktop application group from this hostpool to a new workspace named MD-AVD-WS01.

Lets go to the Azure portal and search for Azure Virtual Desktop. This will bring us into the Azure Virtual Desktop management window:

Now select Host pools under Manage blade and then click on “Create” to add new Host Pool:

We will provide the details required to create a Host Pool.

• Project Details – Defines the Host Pool environment
  • Subscription: Choose the default subscription.
  • Resource Group: Select md-avd-demo from the drop down.
  • Host Pool Name: MD-AVD-HP01
  • Location: North Europe (this should be same as the region of your resource group).
  • Validation environment: Yes (Validation host pools let you monitor service updates before rolling them out to your production environment. This needs to be set to Yes here as we are joining this to an Azure AD environment).
  • Host Pool Type: Personal (I need to choose Personal for the demo as I’m using Azure AD. This is not currently supported for Pooled desktops).

Note – when you select “Pooled” as the host pool type, you have additional options. I’ve included a screenshot of what this looks like:

• Load Balancing Algorithm: there are two types:
  • Breadth-first load balancing allows you to evenly distribute user sessions across the session hosts in a host pool.
  • Depth-first load balancing allows you to saturate a session host with user sessions in a host pool.)
• Max Session Limit: limits the simultaneous number of users on the same session host.

Now we click next and go the the the Virtual machines tab. I’m going to leave this at “No” for now – because I am using Azure AD for authentication I habve some additional steps to do before creating my Session Hosts.

We click next and move on to the Workspace tab. Once we select “Yes” to “Register desktop app group”, we need to create a workspace called MD-AVD-WS01:

Finally in the Diagnostics tab, we enable diagnostic settings and choose to send these to our Log Analytics Workspace. As you can see, we can also choose to archive to a storage account or send the events to an Event Hub:

Now we can click on “Review and Create” and review the details in the Validation screen:

Once we are happy click on “Create” to create our Host Pool and we’ll get a screen similar to below to tell us the Deployment is completed:

And we can see that we have a Host Pool created in our Azure Virtual Desktop console:

Configure Azure AD Authentication

Because I’m using Azure AD for the demo, I need to assign my users permissions to access the desktop. Firstly, I need to go to my DAG object in the Application Group of the Host Pool and go to “Assignments”:

We then click on “Add” and select our users:

Azure AD Role Assignments

To allow users to log on to the Virtual Machines, we also need to add Role Assignments. There are 2 we need to add:

• Virtual Machine Administrator Login
• Virtual Machine User Login

We can ensure that these roles are assigned automatically by assigning this at the IAM level of our Resource Group:

RDP Properties

In order for the Host Pool to know that the session hosts are Azure AD joined, we need to add an advanced RDP property. So we go back to my Host Pool, choose “RDP Properties” from the settings menu and under Advanced we add the following string:

targetisaadjoined:i:1

Click on “Save” to save the changes.

Create Session Hosts

We’re now ready to create our Session Hosts. So we’ll go back to our Host Pool, select “Session Hosts” from the “Manage” menu and click on “Add”:

The “Basics” tab is already pre-populated with the information from our Host Pool:

This will give us the options to provide details for the VMs we need to add:

• Resource Group: Select md-avd-demo from the drop down.
• Name prefix: md-avd-sh0
• Virtual machine location: North Europe (location should be same as location of your resource group).
• Availability options: Select No infrastructure redundancy required from the drop down (again, this is being used for the purposes of the demo).
• Image type: Gallery
• Image: Windows 10 Enterprise, version 21H2
• Virtual machine size: Standard B2s. (You can click on Change Size, then select the size you require and click on Select to choose the size)
• Number of VMs: 2
• OS Disk Type: Standard HDD (you can choose based on your requirements)

Next we scroll down to the “Network and security” section and specify the Virtual Network and Subnet that we wish to use:

Finally on this screen, we scroll down and specify whether we wish to join an Active Directory or Azure Active Directory. We also specify admin accounts for the Session Host VM’s we are creating:

Finally, on the “Advanced” tab we need to enable Diagnostic Settings and send the logs to our Log Analytics Workspace:

Once all of the info is correct and has been validated, we click Create to create our Session Hosts. Once thats created, we should see our Virtual Machines

And if we drill down into “Session hosts”, we should see both hosts set as available:

Note – this step may take up to 30 minutes to complete, and you may see errors on the Session Hosts. Don’t panic! If you’ve followed the steps above, the errors will eventually clear and the hosts will show as available.

Diagnostic Features

We now need to check and ensure diagnostic features for both the host pool and workspace to allow us to analyse monitoring data. We set this up when creating the host pool and session hosts, but lets make sure its set up and also we can see what we’re going to monitor.

Lets go to our host pool first and we go to Diagnostic Settings in the Monitoring menu:

We do the same check for Workspace to ensure that this is configured correctly:

Lets also enable this for our Session Hosts – we need to do that directly on the VMs in the Resource Group. So we go to the Monitoring menu, select Insights, and then click on “Enable”:

We’ll get a prompt telling us that the VM is not connected to a workspace. We select the Subscription and Workspace that we wish and click “Enable”:

Give that a few minutes and you’ll then go back in and see some data in the Insights page:

Conclusion

Thats where we’ll pause for breath! Lots of information there, so just to recap:

• We created our Log Analytics Workspace for logging our monitoring data
• Created our Test Users in Azure AD
• Created the Host Pool
• Created the Assignments to allow users to access the desktops
• Created the Service Hosts
• Verified that Diagnostic Settings are working
• Added our Session Hosts into Monitoring

We’ll continue the demo in the next post where we’ll create our Application Groups for both Desktop and Remote App, connect to our AVD resources using the different methods available. We’ll also look at our monitoring data that being collected.

Hope you enjoyed this post, until next time!