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.

Overview​

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:

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​

Prerequisites​

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. 
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. 
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.

Setup Azure Compute Gallery​

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. 
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. 
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. 
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. 

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. 

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. 
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. 

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'

  
try
{
  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
  }

  $info
}

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.

Logs​

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​

• Troubleshooting during preview

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. 
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.

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. 
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. 
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. 
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. 
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​

• Secure your management ports with just-in-time access
• Understanding just-in-time (JIT) VM access
• Just in Time Access Policy Script & Custom Role Script

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.

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. 
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. 
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. 
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.

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. 

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).

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

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.

A very brief Blog article today, I have created an AWESOME-Azure-Architecture list, this list is hosted in Github and located here:

• AWESOME-Azure-Architecture

This list is a curated list of AWESOME blogs, videos, tutorials, code, tools & scripts, related to the design and implementation of solutions in Microsoft Azure.

This list contains anything that can help with your Microsoft Azure architecture and quickly get you up and running when designing, planning, and implementing services that empower organisations around the planet to achieve more.

You may be working remotely or only have a few devices needing access to your resources in Azure; a solution that can be deployed is a point to site connection straight into your Microsoft Azure network.

This functionality allows your computer to connect privately to resources over a secure tunnel using your internet connection, using an Azure Virtual Network gateway, you can seamlessly connect to resources without the need of opening up your resources to the internet or having to whitelist your (or third party vendor) IP address, which may change daily.

You know only your specified users access your Azure resources using Microsoft Entra ID.

You can have a site to site and point to site VPN running on the same Gateway today. We will set up a Point to Site VPN using Windows 11.

Depending on the SKU of your Virtual Network Gateway, depends on the number of concurrent connections and throughput you are allowed; because we are using Microsoft Entra ID and the OpenVPN protocol, I will be selecting Generation 1, VpnGw1, supporting a max of 250 connections (you can double the number of throughput and connections if you are running in Active/Active and have a second gateway, or select a higher SKU).

Azure AD authentication is supported for OpenVPN® protocol connections only and requires the Azure VPN client.

A note about Gateway SKUs (apart from Basic) you can resize in the same generation (i.e. Generation 1 VpnGw1 to VpnGw3, but you can't go from Generation 1 VpnGw1 to Generation 2 VpnGw5, in order to upgrade, you have to delete and recreate the Gateway, just keep this in mind when deciding on the SKU of your resources).

You can read more about the Virtual Network Gateways and VPN SKUs at the official Microsoft documentation here; your Gateway SKU may differ depending on your requirements.

Create Azure Point to Site VPN using Microsoft Entra ID authentication​

Prerequisites​

• An Azure subscription (that you have at least contributor rights to and the ability to create Users and Groups)
• An endpoint device running Windows 10 or 11 that you can install the Azure VPN client onto

Create Virtual Network​

First things first, let's create a Virtual Network.

1. Log in to the Azure Portal
2. Click on + Create a resource
3. Search for: Virtual Network and click on it
4. Click Create
5. Select or create your Resource Group that you want your network resource to sit in (I recommend Virtual Network and the gateway resources sit in its own Resource Group away from other resources so that they can be protected by resource locks, RBAC and they are usually classified as a shared resource).
6. 
7. Click Next: IP Addresses
8. Now we need to define the Address space and subnets; I will leave the Address space as 10.0.0.0/16 but remove the Default subnet (select the checkbox next to the Subnet and select Delete)
9. Click +Add Subnet, and add a new subnet with the name of GatewaySubnet with an IP range of: 10.0.1.0/27 (this Subnet will be used by our Virtual Network Gateway, and the name needs to be exactly GatewaySubnet).
10. Now I will add a subnet named: app servers, for the Virtual Machines I will need to connect to will be placed.
11. 
12. Click Next: Security
13. Leave everything (BastionHost, DDoS Protection Standard, Firewall) as Disabled.
14. Click Next: Tags
15. Enter in any tags and click Review + Create
16. Review your configuration and click Create

Create Virtual Network Gateway​

Now that we have the foundation of our setup - an Azure Virtual Network, it is time to provision the Gateway itself; just a note before we continue, the Gateway can take 30-60 minutes to provision.

1. Log in to the Azure Portal
2. Click on + Create a resource
3. Type in and search for: Virtual Network Gateway
4. Click Create
5. Type in the name of your Azure Virtual Network Gateway
6. Select the region (it must be the same region as your virtual network)
7. Select the Gateway Type: VPN
8. The VPN type is: Route-based
9. Select the SKU, in this example - I will be going with VpnGw1
10. Select the Generation of the Virtual Network Gateway; I am going with: Generation 1
11. Select the Virtual Network that you created earlier, and it will automatically find and assign the Gateway to the Subnet named: GatewaySubnet
12. Select Standard public IP address SKU
13. Select Public IP address and select: Create new
14. Type in your public IP name
15. Leave 'Enable active-active mode' and 'Configure BGP' as Disabled.
16. Click Review + Create
17. 
18. Verify configuration is correct and clicks Create
19. It can take up to 30-60 minutes for the Virtual Network Gateway to be created.

Setup Microsoft Entra ID authentication on the Virtual Network Gateway​

Now that the Virtual Network has been created, we can now set up Microsoft Entra ID authentication.

Collect Microsoft Entra ID Tenant ID​

First, we need to collect the Azure AD Tenancy ID

1. Log in to the Azure Portal
2. Click on Microsoft Entra ID
3. In the Overview pane, copy the Tenant ID and save this for the next step.

Grant Azure VPN Client permisisons​

Now we need to grant the Azure VPN application permissions.

1. Log in to the Azure Portal

2. Open a new window and type in and press Enter:

   https://login.microsoftonline.com/common/oauth2/authorize?client_id=41b23e61-6c1e-4545-b367-cd054e0ed4b4&response_type=code&redirect_uri=https://portal.azure.com&nonce=1234&prompt=admin_consent
   

3. If you get an error about external identity, then replace /common/ with your tenant ID.

4. 

5. Click Accept

6. Navigate back to Microsoft Entra ID

7. Select Enterprise Applications

8. Select Azure VPN

9. Copy the Application ID of the Azure VPN enterprise application (you will need both Application ID and tenant ID for the next steps)

10. 

Configure Point to Site Connection​

Now its time to configure the Virtual Network Gateway

1. Log in to the Azure Portal
2. Navigate to the Virtual Network Gateway you created earlier
3. Click on Point-to-site configuration
4. Click Configure now
5. Enter in your address pool (this is the address pool of the VPN clients, make sure this doesn't overlap with any other IP range you use, I will go with: 172.0.0.0/16)
6. Make sure the Tunnel type is: OpenVPN (SSL)
7. Select Microsoft Entra ID for the Authentication type
8. For Tenant, ID enter in: https://login.microsoftonline.com/**TENANTID**/ and enter in your own Tenant ID.
9. For the Audience (this is the users and groups that are assigned to the Enterprise Azure VPN application), put in the Application ID of the Azure VPN.
10. For the Issuer, enter in: https://sts.windows.net/**TENANTID**/
11. 
12. Click Save
13. It may take 1-5 minutes to save the configuration

Install and connect using the Azure VPN client​

Now that the Point to Site VPN has been configured it's time to connect!

1. Click on Download VPN client (if it is greyed out, then navigate to the Overview pane, then back to the Point-to-site configuration).
2. Extract the zip file, you will need these files
3. Download the Azure VPN Client to your computer.
4. 
5. Once, downloaded click Open.
6. Click the + sign (lower left)
7. Click Import
8. Navigate to the: azurevpnconfig.xml file that you downloaded earlier and click Open
9. You can change the Connection Name to something more user friendly (you can also edit the file directly for when you look at pushing out this to multiple users, but make sure you have a backup of the file)
10. Click Save
11. 
12. Click Connect
13. Enter in your Microsoft Entra ID credentials (you may be prompted for MFA, depending on the rules - you can use Azure VPN application under conditional access)
14. 
15. You should now be connected to the Azure network through a point to site VPN!
16. If I run 'ipconfig /all' on my device, I can see a PPP adapter that is connected and on the VPN address range created earlier: 172.0.0.2
17. 
18. If I navigate back to the Point-to-site connection in the Azure Portal, I can see, my connection has been allocated:
19. 
20. I can now use Remote Desktop to connect to a Virtual Machine, running in my AppServers Subnet, which I am running without the need of a Public IP or bastion/jump host:
21. 

Note: I don't have a DNS service running in Azure, but the Azure VPN agent will take DNS from the Virtual Network if you have this configured to point towards a DNS server (Active Directory, or other DNS forwarder (pointing towards Azure DNS IP: 168.63.129.16) such as Azure Firewall DNS proxy; you can set Custom DNS servers by modifying your DNS configuration, or add entries into the host file of the computers.

You can set your Custom DNS settings (remember to add the DNS suffix if needed) and configure the VPN to automatically connect by following the details on the OpenVPN Azure AD Client page.

Using Intune, you can also push this configuration to your Windows 10 and 11 clients

• Create custom Intune profiles to deploy VPN client profiles