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.

Using Git rebase to sync latest changes in main branch to feature branch

You have a scenario where you create a feature branch from the main branch. Then you work for a while on the feature branch and want to merge these changes into main.

But in the meantime changes have also been made to main and you are unsure if there are now conflicts.

With Git rebase you can take all the latest changes from main and sync them into your current feature branch. And all your current commits will be added on top of those changes from main (this keeps the commit history clean). It is similar to if you started over on a fresh feature branch from main and then added all your changes again.

It is also described here and on YouTube here.

To use git rebase, run the following commands:

Go to main branch first and get latest changes:

git switch main

git pull

Then switch to your existing feature branch:

git switch feature/my-feature-branch

If others have worked on the same feature branch, you can pull the latest changes with:

git pull --rebase (optional)

If only you have worked on the feature branch you can skip that (as you know you have the latest changes) and then run the rebase command:

git rebase main

This will add all the latest changes to your local feature branch.

Then you need to push those changes to the remote feature branch (typically, so you can create a pull request and merge everything into main):

git push --force-with-lease

You cannot run a regular git push since the local and remote branch history are no longer the same (since changes from main have been interjected into the feature branch). Using --force-with-lease is safe as it checks that remote and local are still the same before pushing and if not it will fail.

That's it.

If you run into a merge conflict you can try and open the file and update as needed and then run: 

git add the-file-name-you-updated

git rebase --continue

Or if you want to cancel entirely, run:

git rebase --abort

To see more info on general Git usage and commands, see here.

Compare two columns in Excel

 If you have two large lists that you need to compare (to identify what items are missing in one of the lists), this can be done in excel.

Add the first list (the bigger of the two) in column A and the other list in column B.

For column C, add this formula in cell C2 and drag it all the way down to the bottom column C:

=IF(COUNTIF($B:$B; A2)=0; "Item in column A is missing in column B"; "Item exists in both lists")

What it does is for each cell in column A, it will run through all the items in column B and look for a match and note if it finds one, see screenshot below.

An example xlsx file is available on GitHub (choose download raw file).

Create architecture diagrams with Mermaid and ChatGPT

 Mermaid is a practical tool that can create all sorts of diagrams as code. And if you combine it with an LLM, you can create it with a prompt.

To view the results, go to https://mermaid.live and add the code in the box on the left.

As an example, I had ChatGPT create a hybrid cloud architecture diagram with an on-prem location connected to Azure via an ExpressRoute. For encryption, VPN runs inside the ER circuit. The Azure setup is hub-spoke meaning the central networking components are in the hub and are connected to multiple spoke VNets. Traffic flows through an Azure Firewall.

I have put the code in a markdown file on Github (click Raw to view code).

Result looks like below:

If saving the mermaid code in a markdown file (.md) it will render the diagram directly in Github as long as it is wrapped with ```mermaid at the beginning and ``` at the end.

And if you copy raw code to mermaid.live, only use the text inside the wrapper.

Here's what it looks like at mermaid.live:

You can also preview the diagram in Visual Studio Code if you install the Markdown Preview Mermaid Support extension (and save file as .md). To view diagram, just right-click the .md file and choose "Open preview". It looks like this:

The native Mermaid file format extension is .mmd and there are extensions for VS Code for that as well.

Azure Bastion Developer - shared Bastion pool

 The Azure Bastion is useful for connecting securely to virtual machine without exposing the VMs to the internet using public IP's.

This however, requires a dedicated Bastion instance to be deployed and an AzureBastionSubnet.

With Bastion Developer, test/dev users can connect to the local IP of the VM via Bastion using a shared pool, so no dedicated setup required. The features are limited though. See here for more info.

To use, in the portal simply go to the VM -> Connect -> Bastion.

Add credentials and click Connect. This will open a remote session in the browser, see below: