Create Windows 365 Azure Network Connections with PowerShell

Windows 365 and Azure Network connections offers additional control over routing, IP Addresses, Subnets, Peerings and so on. It can also be incredibly useful to help with testing moving to Azure AD Only (Can you tell, I’m already not a fan of HAADJ), as with the right configuration on your Azure vNet you can connect back to your internal network and get straight to testing.

Using an ANC with Windows 365 and Cloud PCs does bring an additional cost, not to the license or compute though, just the network usage cost. Microsoft do recommend using their Hosted Network, but they are not fools, they have built a system for enterprise and allowing the capability of Bring-Your-Own-Network (BYON) is a clear no brainer for organisations with existing on-premise infrastructure.

BYON doesn’t just have to be used for a gateway connection back to on-premise though, it can be used to just add more control over the network traffic on these endpoint with firewalls etc. There is some further documentation on Azure Network Connections over on the Microsoft Learn Page.

For this post, I wanted to explore creating these connections with PowerShell and the Graph API. We will explore both Azure AD Only and Hybrid Joined ANCs and the differences in the policy creation.


Hybrid Azure AD Join

If the chosen deployment option is HAADJ, you will need to ensure the network has line of sight to your domain controllers and that DNS can be resolved.

In addition to the above, you will require a domain Service Account which can join devices to the domain.

Creating the Policies

You may need to grant permissions to the PowerShell module within your Tenant. If this is the case and you do not have access to grant the relevant permissions, please reach out to an administrator who can grant these rights.

In both instances, there are details we require for the creation of the connection so lets grab them first.

  • SubscriptionID - The Subscription ID in which the Virtual Network Resides
  • Resource Group Name - The name of the resource group where the Virtual Network resides
  • Virtual Network Name - The name of the Virtual Network
  • vNet Subnet Name - The name of the Subnet which resides within the vNet

In addition to the above, for Hybrid machines you will also require the following;

  • Domain Join Service Account
  • OU Path
  • Domain DNS Suffix (e.g euc365.lab)

As noted in the prerequisites, ensure you have Owner rights at the time of creation on the Subscription.

The scripts quoted in this article, are available on GitHub, please use the link below.

GitHub Resource

First of all, lets look at creating a NON Hybrid connection. If you download the files from the GitHub Repo, this will be the create-w365-ANC-aad.ps1 script.

If you open it up and take a look inside, you can see, there is no major magic that is happening inside, it is just taking out passed in variables and building up the $params variable, which will be used as the body of our Graph Call.

Once the call is made, Windows 365 then runs checks on the Network connection to make sure everything is good to run machines from, for that reason you can not know for sure if it will work straight away, which is why at the end their is a DO, WHILE loop to ensure we know the final outcome.

These tests can vary in the amount of time taken to complete, but I haven’t seen one take more than 10 Minutes.

If we look at how we can then execute this script using the command line, we would use the following command with the placeholders replaced with their representational values.

create-w365-ANC-aad.ps1 -subscription <SubscriptionID> -resourceGroupName <RGName> -vNetName <vNetName> -subnetName <subnetName> -ancName <ancName>

Once executed, you will see the following in the shell window.

AAD Creation

The Network connection will also be available in the Windows 365 blade within Intune.

ANC Created

Now if we take a look at the HAADJ Scenario, there are a few more variables required which are, $domainOU, $domainDNSSuffix, $domainJoinUser and $domainJoinUserPWD. The $domainOU variable must be populated with the distinguished name of the OU, for example OU=Devices,DC=EUC365,DC=LAB and the $domainJoinUser must be the user principal name, for example **[email protected]".

The password will be plain text.

We execute this script in the same way as the above with the additional cmdlets as shown below with the additional placeholders.

create-w365-ANC-haadk.ps1 -subscription <SubscriptionID> -resourceGroupName <RGName> -vNetName <vNetName> -subnetName <subnetName> -ancName <ancName> -domainOU <e.g OU=Devices,DC=EUC365,DC=LAB> -domainDNSSuffix <e.g euc365.lab> -domainJoinUser <e.g J[email protected]> -domainJoinUserPWD "iamplaintext"

The platform will then again perform the relevant checks to ensure it can connect to the domain, look up DNS etc, so please ensure your vNet and subnet are configured accordingly for this test to pass.


This is only one piece of the puzzle, but what I would say, is if you do not need one for a certain purpose (i.e routing back to on-premise) do not create one. It adds another level of management and complexity where it is not required, and if you use the moto of less is more, then you can save the management in the long run.

Please leave comments and reactions below, and let me know your experiences.

comments powered by Disqus