Skip to main content

Native RDP Client & Azure Bastion

· 4 min read

In early February 2022, Azure Bastion Preview support for the native Windows SSH and RDP client came out, and this meant that we no longer have to rely on the Azure Portal and the limitations of a web browser - the support also includes File transfer through the clipboard by copying and pasted into the RDP session!

Azure Bastion is a fully managed service that provides more secure and seamless Remote Desktop Protocol (RDP) and Secure Shell Protocol (SSH) access to virtual machines (VMs) without any exposure through public IP addresses. Provision the service directly in your local or peered virtual network to get support for all the VMs within it.

Let’s test the native RDP client through a secure connection using Azure Bastion!


  • This configuration requires the Standard tier for Azure Bastion.
  • A Virtual Machine(s) to connect
  • Latest Azure CLI
  • Reader role on the Virtual Machine
  • Read role on the Network Interface Card of the Virtual Machine.
  • Reader role on the Azure Bastion resource
  • Virtual Machine Administrator (or User) login role using Microsoft Entra IDauthentication.

Create Azure Bastion

If you have a Virtual Machine but haven't set up Azure Bastion, run through the below to set it up:

  1. Log in to the Azure Portal
  2. Click on Create a resource
  3. Search for: Bastion Azure - Bastion
  4. Click Create
  5. This is a Networking resource to place it in the same Resource Group as my Virtual Network.
  6. Please type in a Name for the Bastion instance; I will call mine: Bastion
  7. Select the Region that matches the Virtual Network region
  8. Select Standard Tier
  9. Select the Virtual Network
  10. It now warns you about creating an: AzureBastionSubnet with a prefix of at least /27, so we need to create one; click on Manage Subnet Configuration.
  11. Click + Subnet
  12. For the Name type in: AzureBastionSubnet
  13. For the Subnet address range:, If you get an error that indicates the address is overlapping with another subnet, it may be because the Address space is only a /24; click Cancel and click on Address Space in the Virtual Network and change the /24 to/16 to increase the address range.
  14. Click Save to create the subnet Azure - Bastion
  15. Up the Top, click Create a Bastion. Your subnet should be selected automatically to go back to the Bastion setup.
  16. You do need a Public IP for Bastion, so confirm the name is appropriate, then click Next: Tags.
  17. Azure Bastion
  18. Add in appropriate tags, then click Next: Advanced
  19. Check the box next to Native client support (Preview)
  20. Azure Bastion
  21. Click Next: Review + Create
  22. Click on Create to create your Bastion instance!

Note: Bastion may take 10-20 minutes to provision.

Check Bastion SKU

If you already have an Azure Bastion instance, let's check the SKU and, if needed, change it to Standard. Just a note:

Downgrading from a Standard SKU to a Basic SKU is not supported. To downgrade, you must delete and recreate Azure Bastion.

  1. Log in to the Azure Portal
  2. Navigate to your Bastion resource
  3. Click on: Configuration
  4. Change Tier to Standard
  5. Check: Native client support (Preview)
  6. Click Apply
  7. Azure Bastion

Connect to VM using Native RDP Support

  1. Open command prompt or Terminal

  2. Type: az login

  3. Login to your Azure subscription

  4. We need the resource ID of the VM we need to connect to, type in: az VM show --resource-group 'appserver-rg' --name 'APP-P01' --show-details

  5. Change the resource group and VM name above to match your VM

  6. Copy the id of the Virtual Machine you want to connect to

  7. Because I am running the Azure CLI from a PowerShell terminal, I am going to use the following variables:

    $BastionName = 'Bastion'
    $BastionRG = 'network-rg'
    $VMResourceID= '/subscriptions/000000-0000-0000-0000000/resourceGroups/appserver-rg/providers/Microsoft.Compute/virtualMachines/APP-P01'
    az network bastion rdp --name $BastionName --resource-group $BastionRG --target-resource-id $VMResourceID
  8. Run the command, your Remote Desktop window should open up, and the tunnel has been established; if you close the Azure CLI window, your RDP session will be dropped!

  9. Azure Bastion

As you could most likely tell, there are no options to enable drive passthrough, etc. You would usually find when connecting to Remote Desktop, but the copying of files/text, etc., does work!


· 2 min read

Over the past few months, I have been busy working on a new project...

A news aggregator for Azure news and updates, I tested some desire for this using AzureFeeds, on LinkedIn as a platform (which will continue)...

I didn't want my LinkedIn connections, to be spammed by Azure updates every day, when some connections were connected to me for other non-Azure related services, so I created a separate account that interested people could subscribe to AzureFeeds.

I was lucky enough to acquire both and and wanted to do something a bit more substantial than just forwarding to the relevant Microsoft pages.

Inspired by PlanetPowerShell, I wanted an Azure specific service, so I created the AzureFeeds website.

Originally starting using official Microsoft services, due to the massive amount of updates and changes ongoing, I didn't want to make the feeds too busy, however with feedback from the community through a Twitter poll, I then added an author section and added community-based content to supplement official updates, mimicking the functionality of PlanetPowerShell being content community-driven a lot more.

You can subscribe to a single feed by clicking 'Download Feed' using your favourite RSS reader (even Outlook) and get the content delivered straight to you from official and community updates! Allowing you to keep up with Azure Updates and Azure community-driven updates easily, or just browse the webpage and filter by Author or Category for content that you may be after.

Check out..

Azure Feeds

Datto Remote Management Azure VM Application Deployment

· 14 min read

The Azure Compute Gallery (superseded the Shared Image Gallery) offers more than just Azure Image management and replication, and you can deploy Applications to your Virtual Machines.


An Azure Compute Gallery helps you build structure and organization around your Azure resources, like images and applications. An Azure Compute Gallery provides:

  • Global replication.
  • Versioning and grouping of resources for easier management.
  • Highly available resources with Zone Redundant Storage (ZRS) accounts in regions that support Availability Zones. ZRS offers better resilience against zonal failures.
  • Premium storage support (Premium_LRS).
  • Sharing across subscriptions, and even between Active Directory (AD) tenants, using Azure RBAC.
  • Scaling your deployments with resource replicas in each region.

With images, Azure VM applications that support both Linux and Windows operating systems get these benefits.

While you can create an image of a VM with apps pre-installed, you would need to update your image each time you have application changes. Separating your application installation from your VM images means there’s no need to publish a new image for every line of code change.

Application packages provide benefits over other deployment and packaging methods:

  • Grouping and versioning of your packages
  • VM applications can be globally replicated to be closer to your infrastructure, so you don’t need to use AzCopy or other storage copy mechanisms to copy the bits across Azure regions.
  • Sharing with other users through Azure Role Based Access Control (RBAC)
  • Support for virtual machines, and both flexible and uniform scale sets
  • If you have Network Security Group (NSG) rules applied on your VM or scale set, downloading the packages from an internet repository might not be possible. And with storage accounts, downloading packages onto locked-down VMs would require setting up private links.
  • VM applications can be used with the DeployIfNotExists policy.

Azure VM Application packages (stored in an Azure Storage account) uses multiple resources, as below:

Azure compute galleryA gallery is a repository for managing and sharing application packages. Users can share the gallery resource and all the child resources will be shared automatically. The gallery name must be unique per subscription. For example, you may have one gallery to store all your OS images and another gallery to store all your VM applications.
VM applicationThis is the definition of your VM application. This is a logical resource that stores the common metadata for all the versions under it. For example, you may have an application definition for Apache Tomcat and have multiple versions within it.
VM Application versionThis is the deployable resource. You can globally replicate your VM application versions to target regions closer to your VM infrastructure. The VM Application Version must be replicated to a region before it may be deployed on a VM in that region.

There is no extra charge for using VM Application Packages, but you will be charged for the following resources:

  • Storage costs of storing each package and any replicas.
  • Network egress charges for replication of the first image version from the source region to the replicated regions. Subsequent replicas are handled within the region, so there are no additional charges.

Before we deploy our first VM application, there are a few things we need to be aware of:

  • VM Application requires an Azure Compute Gallery
  • VM Application requires an Azure storage account to store your applications
  • The VM Application gets downloaded to the VM using the name of the VM application (not the actual name and Extension of your file in the storage account)
  • Currently, in order to retry a failed installation, you need to remove the application from the profile and add it back
  • No more than five applications per Virtual Machine deployed at a time
  • The maximum size of the application is 1 GB
  • You can't have multiple versions of the same application installed on a Virtual Machine, and a newer version will supersede an older version either via an upgrade command or complete reinstall.

In this article, we are going to deploy the Datto Remote Management & Monitoring Agent to a Windows Server 2022 Virtual Machine; this agent is a simple executable that installs on a virtual machine and allows remote access and management of a virtual machine, without requiring any other form of connectivity (Azure Bastion, RDP via Public IP, Site to Site VPN etc.) for an MSP (Managed Service Provider) using the Datto toolset, the same concept can be applied to any application (theoretically you can also use this to run PowerShell installs or chocolatey installs).

It's worth noting the VM Applications are currently in Public Preview, there is a good chance there will be changes in the way these operate and are configured when it becomes Generally Available.

Setup Azure VM Application Deployment


In order to use VM Applications, we need:

  • A storage account
  • Azure Compute gallery
  • VM application definition and version (in my example: the Datto RMM agent)

Following the guide, we will run through the creation of everything from scratch; I am, however, assuming you already have the executable or application package and know the instructions to install/uninstall it - as each application is different. The MicrosoftVM Applications docs give a few good examples for getting started with various applications.

Setup Storage Account

The Storage account is where your application will be placed; it uses blobs; depending on the importance of your application deployments, you may want to go for geo-replication etc., but in this example, I will be going with a locally redundant, StorageV2 general-purpose account.

  1. Open the Azure Portal
  2. Click on + Create a Resource
  3. Search for: Storage account, and select it
  4. Click Create
  5. Select your subscription
  6. Select a Resource Group for your storage account, or create a new one
  7. Enter your storage account name (this needs to be globally unique)
  8. Select your region that your application will be in; although the application can be replicated to other regions, it's better to select your primary region here.
  9. Select the performance and redundancy to match your requirements and click Next: Advanced
  10. Azure Portal - Create Storage Account
  11. You can leave most settings here as default, the application executable will need to be able to be accessed directly; make sure the Minimum TLS is at least 1.2.
  12. You don't need hierarchical namespace etc.; unselect 'Allow cross-tenant replication' unless this is a feature you use.
  13. Azure Portal - Create Storage Account
  14. Click Review + Create to skip to the last blade; most defaults are fine, but if you want to adjust the blob retainment and soft delete settings, go to the Data Protection tab, set them, then review your Configuration and select Create.
  15. Go back to your storage account and click Configuration
  16. Make sure: Allow storage account key access is: Enabled; if it is not, select Enabled and click Save.

Now that we have the Storage account to store your application binaries, we now need an Azure Compute Gallery (previously the Shared Image Gallery) to keep your application definition and version metadata.

  1. Open the Azure Portal
  2. Click on + Create a Resource
  3. Search for: Azure Compute Gallery and select it
  4. Click Create
  5. Select your subscription and resource group (in this case, I am going to use the same resource group as the Storage account I created earlier)
  6. Type in a name, and select your region
  7. Although not mandatory, use the opportunity to fill in a description for the purpose of the Compute Gallery for future reference
  8. Azure Portal - Create Storage Account
  9. Select Review + Create
  10. Verify everything is correct and click on: Create

Create Application Definition

VM application definitions are created within a gallery and carry information about the application and requirements for using it internally. This includes the operating system type for the VM application versions contained within the application definition. The name of your Application definition defines the name of the file that will be downloaded to your virtual machines.

  1. Open the Azure Portal
  2. Navigate to 'All Resources'
  3. Find and click on your Azure Compute Gallery you created earlier
  4. On the overview pane, select + Add
  5. Click on +VM application definition
  6. Your subscription and resource group should be automatically selected to the location of the Compute Gallery, type in the name of your applicatio.n
  7. Select your region
  8. Select the OS type - in my case, and I select Windows
  9. Azure Portal - Create Application Definition
  10. Click Next: Publishing Options
  11. The following fields are not mandatory, but I recommend filling in areas to help report on and manage your applications.
    • Description
    • End of life date
    • Eula link
    • Privacy URI
    • Release notes URI
  12. Azure Portal - Create Metadata
  13. Click Review + create
  14. Verify your Configuration and select Create

Create Application version

Now that we have the application definition setup, it's time to set up the version and upload our binary file.+

  1. Open the Azure Portal

  2. Navigate to 'All Resources'

  3. Find and click on your Azure Compute Gallery you created earlier

  4. Click on Definitions(besides the Get Started link)

  5. Select your Application definition

  6. Click on: +Add

  7. Enter in your version number, and this will increment and grow as you adjust and troubleshoot your application; I recommend starting with 0.0.1 then working your way up, with 1.0.0 being potentially your final/production-ready releast.

  8. Select your Region

  9. Now we need to select our source application package (you can enter in your blob URL if you know it); we haven't uploaded it to our storage account yet, so we will select Browse

  10. Select your Storage account

  11. Press + Container

  12. Enter in the name of your container ( it has to be in lowercase), such as the application name (to keep things separate, consider a container per application)

  13. Press Upload

  14. Browse to your file and select it

  15. Expand Advanced

  16. Make sure that Blob type is: Blob

  17. Azure Portal - Azure Blob

  18. Click Upload

  19. Select your newly uploaded file and click Select

  20. Note: You can only upload one file as part of your package, you can upload a ZIP file and have your Install script extract it

  21. The Install script is the command to install to your application, by default windows applications are set to install cmd. This already knows the directory your files are in because the file will be uploaded as the application name (i.e. DattoRMM), it needs to be renamed to include .exe and then ran, I will switch to PowerShell for the Install script, so will enter:

    powershell.exe -command "Rename-Item '.\DattoRMM' -NewName 'DattoRMM.exe'; Start-Process '.\DattoRMM.exe'"
  22. If you have a script to uninstall the application, enter it (in my case, I am just going to put a '.' to skip this, as I don't currently have an uninstall script developed)

  23. The rest of the Configuration isn't mandatory; the Update script is used by Azure when a new version of an application is created; by default, the Azure VM extension will treat an upgrade like a completely new install and run the install steps unless an update script is defined.

  24. Azure Portal - Application Version

  25. Click Next: Replication

  26. Like Azure Compute Images, you can replicate your Azure VM applications across multiple regions (depending on where your workloads are), such as Australia East to West Europe, and store it then Zone Redundant or Local storage. In my example, I am going to leave mine as one replica in Australia East on locally-redundant storage and click Review + create

  27. Verify everything looks ok and click Create to create your application version! This may take a few minutes to create, depending on your configuration and replication.

Deploy Azure VM Application

Deploy Azure VM Application to Virtual Machines using the Azure Portal

Now that your Azure VM Application has been created, it is now time to deploy to a Virtual Machine. I have a Windows Server 2022 Datacenter Azure Gen 2 VM running as a Standard_B2ms as my test machine, and because I am going to use the Datto RMM agent to connect to the machine, I don't need any RDP ports open etc.

  1. Open the Azure Portal
  2. Navigate to Virtual Machines
  3. Click on your Virtual Machine
  4. Under Settings, click Extensions + Applications
  5. Click VM Applications
  6. Click + Add application
  7. Select your application (note you can select a particular version, by default, it is the latest)
  8. Click Ok
  9. Azure Portal - VM-P01
  10. You can select your Install Order (i.e. if you had multiple applications, you can select which one installs 1st, 2nd, third and so on); I will select No Reference and click Save to start the deployment.
  11. If you click Extensions, you should see that a: VMAppExtension has started to be installed; click on Refresh to update the status and click on the Extension to a more detailed status message, hopefully you see ":Operational Install is SUCCESS"
  12. My Virtual Machine has now had the Datto Remote Management agent installed successfully and has appeared in the portal for me to connect to!
  13. Azure - Datto RMM

Deploy Azure VM Application to Multiple Virtual Machines using PowerShell

I've created the PowerShell script below to deploy an application to multiple Virtual Machines at once, it can easily be adjusted for a PowerShell Runbook that runs periodically to install software on machines it may be missing. As usual, please make sure you test and run any PowerShell scripts first in a demo environment.

$allvms = Get-AzVM
$applicationname = 'DattoRMM'
$galleryname = 'AzComputeGallery'
$galleryrg = 'vmapps-prod-rg'
$appversion = '0.0.1'

ForEach ($vm in $allvms)

$AzVM = Get-AzVM -ResourceGroupName $vm.ResourceGroupName -Name $vm.Name
$appversion = Get-AzGalleryApplicationVersion `
-GalleryApplicationName $applicationname `
-GalleryName $galleryname `
-Name $appversion `
-ResourceGroupName $galleryrg
$packageid = $appversion.Id
$app = New-AzVmGalleryApplication -PackageReferenceId $packageid
Add-AzVmGalleryApplication -VM $AzVM -GalleryApplication $app
Update-AzVM -ResourceGroupName $vm.ResourceGroupName -VM $AzVM -ErrorAction Stop

catch [Microsoft.Azure.Commands.Compute.Common.ComputeCloudException]
#Most likely failed due to duplicate package ID/identical version
[Management.Automation.ErrorRecord]$e = $_

$info = [PSCustomObject]@{
Exception = $e.Exception.Message
Reason = $e.CategoryInfo.Reason
Target = $e.CategoryInfo.TargetName


Troubleshooting VM Application

If you have problems installing a package, just a reminder that the VM Application, uploads your file based on the name of the Application, to the server and needs to be renamed with a valid extension as part of the install script.

Package Location

The package/extension location is here:

  • C:\Packages\Plugins\Microsoft.CPlat.Core.VMApplicationManagerWindows\{VERSION#}\

You will find your Application binary under Downloads.


For the extension status logs, navigate to:

  • C:\Packages\Plugins\Microsoft.CPlat.Core.VMApplicationManagerWindows\{VERSION#}\Status

You should see files such as:

  • 0.status

You can right-click these and open them in Notepad, and you should have the timestamp and the last status message, this should be identical to what you see in the Azure Portal.

For the application install logs, navigate to:

  • C:\Packages\Plugins\Microsoft.CPlat.Core.VMApplicationManagerWindows\{VERSION#}\Downloads\{APPNAME}\{APPVERSION}\

You may see files such as:

  • stderr
  • stdout

You can right-click these and open them in Notepad, any errors will be noted in these.

Troubleshooting during preview

Just in Time access to Azure Virtual Machines

· 4 min read

Microsoft Defender for Cloud offers advanced security features, combining functions such as adaptive application controls (application whitelisting), networking hardening (machine learning that learns the traffic passing through your network security group, which helps you create more restricted rules) and advanced antivirus and threat protection; however, a hidden gem of this suite is: Just in Time VM Access.

For a fee for Microsoft Defender for Cloud, you can use Just In Time or JIT to lock down inbound traffic to your Azure Virtual Machines when you only need it.

This reduces exposure to attacks while providing easy access when you need to connect to a VM.

Today, we will use the Azure Portal and configure Just-in-Time access for RDP for a Windows virtual machine running in Microsoft Azure that has a public IP.

This article assumes you have the authority and permissions (at least the Security Administrator role) to configure and pay for Defender for Cloud.

Configure Defender for Cloud

  1. Open the Azure Portal
  2. Navigate to the Virtual Machine you would like to enable Defender for Cloud on and enable Just in Time Access for
  3. Click on Configuration
  4. Click on: Upgrade your Security Center subscription to enable just-in-time access.
  5. Azure Portal - Configuration
  6. Select the Subscription that holds your VM and select Upgrade
  7. If you want to make use of the rest of the Cloud Defender offerings (and you should), then make sure you install the Log Analytics agent; however, you don't need it for Just In Time Access.
  8. Navigate back to your Virtual Machine
  9. Click on Configuration
  10. Now you should see: Enable for Just-in-Time VM access; select this to enable Just in Time.

Now, if you go to the Network Security Group attached to the network interface of the VM, you should see a Deny Rule for 3389 that's been created with a priority lower than the allowed rules, forcing the block.

Azure Portal

Configure Just In Time

Now that we have enabled Defender for Cloud, it's time to configure what ports (can be used for more than just RDP and SSH access) and the length of time that access is allowed.

  1. Click on Microsoft Defender for Cloud
  2. Select Workload Protections
  3. Select Just-In-Time VM access
  4. Azure Portal - Defender for Cloud
  5. Select the VM you have configured.
  6. Click the ellipsis on the right-hand side
  7. Select Edit
  8. Azure has automatically added the port for RDP (3389) and sets a maximum 3 hour request time (that I am allowed to connect to the VM); I can also restrict Just In TIme access from specific IP addresses, and IP ranges to avoid anyone being able to RDP from their home IP.
  9. Azure Portal - Defender for Cloud
  10. Make any adjustments you feel suits your environment. I am going to leave the configuration as is.

Request Access for Just In Time Access to RDP

You can programmatically_request JiT access to Azure VM through PowerShell and the REST API (see Additional Resources below for a PowerShell script to get you started), but we are going to use the Azure Portal.

  1. Open the Azure Portal
  2. Navigate to the Virtual Machine you would like to enable Defender for Cloud on and enable Just in Time Access for
  3. Click Connect
  4. You should see an information alert at the top of the blade "This VM has a just-in-time access policy. Select "Request access" before connecting."
  5. Azure Portal - Just In Time
  6. Select Source IP (My IP)
  7. Click Request access
  8. You should now have access to RDP to the machine!
  9. If you look at the Network Security Group, you should be able to see a new 'Allow' rule has been created with a priority lower than the block rule.
  10. Azure Portal - Just In Time
  11. After 3 hours, the allowed rules will be removed automatically.

Hopefully, this helps keep your environment secure; if you implement this, make sure you read about the custom roles. To prevent the people from just adding in a rule for their public IP in the address manually, it may be better to create a custom role (see the script in Additional Resources below to create this role).

Additional Resources

Application Security Groups in Microsoft Azure

· 5 min read

Azure Application Security Groups (ASG) allow you to define what workloads (Virtual Machines) you are running in Azure has access to what resource - without being tied by managing complex IP address rules inside a Network Security Group.

Application security groups enable you to configure network security as a natural extension of an application's structure, allowing you to group virtual machines and define network security policies based on those groups. You can reuse your security policy at scale without manual maintenance of explicit IP addresses.

These Azure Application Security groups allow you to define your workloads, for example, Azure Virtual Desktop Session Hosts as a 'group' and what they may have access to in your Azure Virtual Network without opening up the service to everything inside of that VNET or creating overly complex rules that could make it hard to troubleshoot.

There are a few things to be mindful of:

  • Azure Application Security Groups are Virtual Network-specific, so they can work to allow resources across subnets, but not in separate Virtual Networks, even if they have peered.
  • As with most Azure resources, there are Subscription levellimits; you cannot have more than 3,000 Azure Application Security groups in a single subscription and region.
  • The rules that specify an application security group as the source or destination are only applied to the network interfaces that are members of the application security group; this does not affect anything not in this group, even though your Network Security Group is based on the subnet.
  • You can assign more than one Application Security group to a resource

In my example, I have a single virtual network, with 2 subnets (one subnet, has an Azure Virtual Desktop session host and the other one has a webserver running IIS), using Azure Application Security Groups, we will restrict IIS access to the webserver from the Azure Virtual Session hosts only - so IIS won't be accessible from any other machine in the Virtual Network.

High Level  - Diagram ASG

Create Application Security Group

Let's get started by creating an Application Security Group.

  1. Open the Azure Portal
  2. Click on + Create a resource
  3. Search for: Application security group and select it
  4. Click Create
  5. Select the subscription that the Application Security group will be created in
  6. Select the Resource Group (in my example, I am selecting AVD)
  7. Create an Application Security Group
  8. Click Review + create
  9. Click Create

Assign Application Security Group

Now that the Application Security group has been created it's time to assign it this our Azure Virtual Desktop session hosts.

  1. Open the Azure Portal
  2. Navigate to your Azure Virtual Desktop session host (or other workloads you are going to use)
  3. Select Networking
  4. Select Application security groups
  5. Click Configure the application security groups
  6. Select the Application Security group created earlier
  7. Assign Application Security Group
  8. Click Save

Assign Block Rule Security Group

Now it's time to assign a block rule to our web server, for port 80 as by default it is allowed through the 'AllowVnetInBound' default rule.

  1. Navigate to the Network Security Group that holds your web server (I am going to make the change on a Network Security group that is tied to the Network Interface of the web server, but the same principle applies if it was applied to a Network Security Group on the subnet - you just need to add the destination IP of the webserver)
  2. Click on Inbound security rules
  3. Click + Add
  4. Add a Deny port rule for port 80 for all source
  5. Assign Block Network Security Group Rule
  6. Click Save

After a few minutes, traffic from any workloads on the virtual network will now be blocked from accessing the web server on port 80.

Port 80 blocked

Create Allow rule using Application Security Group

Just a note around the priorities of Network Security Group rules:

Rules are processed in priority order (using a number between 100 and 4096), with lower numbers processed before higher numbers, because lower numbers have higher priority. Once traffic matches a rule, processing stops.

As a result, any rules that exist with lower priorities (higher numbers) that have the same attributes as rules with higher priorities are not processed.

  1. Navigate to the Network Security Group that holds your web server (I am going to make the change on a Network Security group that is tied to the Network Interface of the web server, but the same principle applies if it was applied to a Network Security Group on the subnet - you just need to add the destination IP of the webserver)
  2. Click on Inbound security rules
  3. Click + Add
  4. For Source, select the Application Security Group
  5. Select HTTP as the service
  6. Select Allow as the action
  7. Set the Priority to be lower than the block rule, ie 4095
  8. Click Save
  9. Create Network Security Rule Allow

After a few minutes, traffic from any workloads on the virtual network will now be allowed for any workloads from your Azure Virtual Desktop farm only (assigned to the Application Security group).

AVD - Test Port 80 Allow

If I attempted to access the webserver from my application server, it fails:

AVD - Test Port 80 Deny

Hopefully, this helps you avoid overly complex security rules that are reliant on knowing and managing the IP of your workloads and help secure your networks.