Azure: Bicep file for Infoblox vNIOS in HA Cluster mode

 Infoblox released a high availability (HA) cluster feature for their vNIOS marketplace image (DNS server and more) around August 2025.

This is an active/passive cluster and it works by adding an additional NIC to two Infoblox VMs and then adding permissions to the VMs so that they can move a virtual cluster IP between them. There is no witness server.

The main differences between a standalone Infoblox VM and an HA cluster Infoblox VM are:

• 1 x additional NIC per VM. The standard is two NICs, so three NICs in total (included in bicep template)
• Note that the virtual machine SKU must support 3 NICs. Standard_DS12_v2 will work but Standard_DS11_v2 will not, just as an example.
• The new NIC should be added in the same subnet as LAN-1 (so the data interface, not the management interface)
• Using a SAMI must be enabled for the VM (included in bicep template)
• A custom RBAC must be created (separate step) and assigned to the Infoblox VMs via s SAMI (system-assigned managed identity) (included in bicep template).
• If you are assigning the SAMI at resource group level, ensure that the RG containing the VNet is also added. This can be done in Bicep by referencing a module (as opposed to nested ARM templates (included in bicep template)
• In NIOS (this is a post-deployment step once VM is up and running), configure a DNS resolver in the Grid Properties Editor, see link.

Previously, Infoblox had official ARM templates that could be used to deploy the marketplace images, but this is no longer the case. Their recommendation is to either deploy from portal via clickOps, use CLI, or alternatively go through the deployment steps in the portal and then export the automation templates at the last step immediately before deploying (this information we have gotten by asking the vendor directly).

However, these ARM templates include some unnecessary resources and checks which make them unnecessarily complex. The fact that they have a mandatory dedicated storage account for boot diagnostics and are not using managed storage accounts, indicates that they are not putting a lot of effort into these templates.

An alternative that we are trying out currently is to deploy the marketplace image via the portal using clickOps and then once deployed, we export the bicep file of what has actually been deployed. It takes a bit more effort to modify the template (NICs and NSGs have to be added manually) but it simplifies the templates in the end.

Bicep files

Here are examples of bicep file, param file, and a module that is used to add permissions to an additional resource group if required:

• https://github.com/norregaard/Azure/blob/main/Infoblox/infobloxvm001.bicep
• https://github.com/norregaard/Azure/blob/main/Infoblox/infobloxvm001.parameters.json
• https://github.com/norregaard/Azure/blob/main/Infoblox/SAMI_roleAssignment.bicep

Note, that in the bicep file the NSG is commented out. This is because we already have an NSG associated at the subnet level which makes an additional NSG at NIC level redundant. But if you don't have an NSG already, then use the one in the file.

Links to documentation

In the following will be listed relevant links for installation instructions from Infoblox:

General information about vNIOS in Azure

General info around vNIOS with High Availability option (including how to assign the custom RBAC to the SAMI)

Creating the custom RBAC role

Other info

The marketplace image terms and conditions must be accepted up front before vNIOS can be deployed. It is done at subscription level, see link for more info.

Azure: Enable and configure subnet peering

 Subnet peering in Azure is a feature that was introduced in April 2025. My guess is that not that many organizations are using it, as it has a quite specific/limited use case.

Subnet peering is enabled on the VNet peering resource. So you still have a local and remote VNet peering resource that peers two VNets but you specify a property in those peerings (peerCompleteVnets: false) that enables the subnet peering - and disables full VNet peering.

A VNet peering resource cannot be both a VNet peering and a subnet peering, it is either or.

Prerequisites

Before being able to deploy this feature, it has to be enabled at the subscription level. According to the documentation, a request form must be filled out first. But when you do that, Microsoft just replies with the instructions on how to enable the feature.

They do this because there are some hard limitations for the use currently, the most important one being the following:

Note: The following instructions to enable feature on subscription level use AZ CLI:

# Log in to Azure: 

az login

# Set the correct subscription: 

az account set –subscription <sub id>

# Verify correct sub is set:

Az account show

# Enable subnet peering on subscription

az feature register --namespace Microsoft.Network --name AllowMultiplePeeringLinksBetweenVnets

# You will be prompted to run this command as well to complete the registration:

az provider register -n Microsoft.Network

# Verify

az feature show --name AllowMultiplePeeringLinksBetweenVnets --namespace Microsoft.Network --query 'properties.state' -o tsv

# If done correctly, the command will output (see screenshot below): Registered

Enable subnet peering on VNet peering resource

You can enable subnet peering via az cli commands or directly in the ARM/Bicep template.

Example using AZ CLI (that I have tested):

az network vnet peering create --name vnet-conn-weu-001_to_vnet-conn-weu-004 --resource-group rg-deploymentstack-001 --vnet-name vnet-conn-weu-004 --remote-vnet vnet-conn-weu-005 --allow-forwarded-traffic --allow-gateway-transit --allow-vnet-access --peer-complete-vnet false --local-subnet-names snet-conn-weu-002 --remote-subnet-names snet-conn-weu-001

az network vnet peering create --name vnet-conn-weu-004_to_vnet-conn-weu-001 --resource-group rg-deploymentstack-001 --vnet-name vnet-conn-weu-005 --remote-vnet vnet-conn-weu-004 --allow-forwarded-traffic --allow-gateway-transit --allow-vnet-access --peer-complete-vnet false --local-subnet-names snet-conn-weu-001 --remote-subnet-names snet-conn-weu-002

Example using Bicep:

When configuring this via Bicep, there are two main changes to be done to the VNet peering resource:

1) The property peerCompleteVnets for the VNet peering must be set to false

2) localSubnetNames and localSubnetNames values must be specified as well. The values are the subnet names, not the subnet IP ranges. See screenshot below:

When the subnet peering has been implemented, it can be viewed from the Azure Portal by going to the VNet peering itself (under VNets). Under Peering type, Subnet will be active, see below:

Enable VNet encryption in Azure

 It is possible to enable encryption on a VNet so that in-transit traffic between virtual machines within the VNet is encrypted (using DTLS). See MS article here for more info.

It is straightforward to enable, it can be done in different ways e.g. via the portal or via code.

To enable in Azure portal, go to the VNet -> Overview -> Properties tab -> click the Encryption link currently saying 'disabled' -> check the 'enabled' box -> save the changes

To enable it using Azure Verfied Modules, you just add vnetEncryption: true under VNet parameters, see below, or full example on GitHub.

module vnet 'br/public:avm/res/network/virtual-network:0.7.2' = {

  name: 'vnetDeployment'

  params: {

    name: vnetName

    addressPrefixes: vnetAddressPrefixes

    subnets: [

      {

        addressPrefix: subnetAddressPrefix

        name: subnet_01_name

        networkSecurityGroupResourceId: networksecuritygroup.outputs.resourceId

      }

    ]

    vnetEncryption: true

  }

}

If you look at the final ARM template result in the portal, the following section is added under VNet paramters:

"encryption": {

                    "enabled": true,

                    "enforcement": "AllowUnencrypted"

                }

The enforcement flag only allows AllowUnencrypted for now. MS mentions that an option to drop unencrypted traffic will be added later.

Note that there are certain requirements and limitations, for example, certain VM SKUs must be used for this to work, see more here.