Retrieve custom DNS server settings on VNets using Kusto (KQL)

 You can use Kusto Query Language (KQL) to retrieve information about your Azure environment across subscriptions.

It's a fast tool and very useful in larger environments with many subscriptions and resources.

The following example shows how to list all VNets in the environment including their custom DNS server settings.

Go to Azure Portal -> Azure Resource Graph Explorer

In the query window, add the following KQL:

Resources

| where type == "microsoft.network/virtualnetworks"

| extend dnsServers = properties.dhcpOptions.dnsServers

| project id, name, dnsServers

Click: Run query

Result will look like below (custom DNS only set on one VNet):

You can download the content as a csv and import into xls for sorting and filtering.

Azure: Creating a route table in Bicep and addressing linter rule warning

 I was creating a route table in Bicep and using an example from MSFT, see example here.

The example uses the 'contains' function which throws a warning when deploying with a suggestion to simplify the syntax. Below you can see the warning:

The warning links to the Linter rule - use safe access page.

The suggested change can be seen below. It still performs the same function - it checks if the value exists, if it does, it uses it, if not it sets the value to null.

The updated example can be found on Github here (it uses routes for Databricks as an example, but can be replaced with your own routes).

Azure: Creating a naming convention for cloud resources

 Creating a maintaining a well functioning naming convention can be surprisingly difficult. And it can lead to many a heated discussion. One of the reasons for this is that there isn't necessarily one right answer and in the end it's about convention and just making a decision and sticking to it.

To help out with the standardization of naming resources in Azure, MSFT has a good article, under the Cloud Adoption Framework, which has suggestions for most of the Azure resources. It's a good starting point:

https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/resource-naming

Azure: Create a Workbook for centralized NSG log search - using VNet flow logs

 NSG flow logs will be retired in 2025, see more details here, and replaced by VNet flow logs.

This article will describe how to install a new Azure Workbook that enables centralized NSG log search using VNet flow log data. Note that to be able to retrieve and view logs with this workbook, VNet flow logs must deployed and configured in advance (you can deploy the workbook up front, but it will return empty queries).

The workbook is based on an existing workbook for NSG log search that uses NSG flow log data (see NSG workbook here). The logic is the same in the new workbook, it just retrieves data from another source (or another table in the Log analytics workspace, to be precise).

First, let's view the final result. Below you can see a screenshot of the workbook:

To install the workbook, do the following:

Download the workbook file from Github.

Go to Azure Portal -> Monitor -> Workbooks -> Click '+New'

Click on the Advanced editor, see below:

Choose Gallery template, then paste in the workbook code and click apply, see below:

That's it, this will create the workbook.

To ensure that you can find the workbook via Portal -> Monitor -> Workbooks, you have have to go into settings and choose Azure Monitor as a resource, see below (this might be set by default):

If you link it only to the log analytics workspace, then you have to navigate to the workspace first and then choose the workbook menu to see it.

If done right, you can navigate to Portal -> Monitor -> Workbooks -> Workbooks tab -> Click workbook to view, see below:

Below you can see the main Kusto query that the workbook uses (this is also included in the workbook file itself):

Note that if you run this as a query it won't return any results.

If you want to run a Kusto query directly (that returns a similar result), do the following:

Go to Portal -> Monitor -> Logs - Choose Kusto mode (instead of simple mode) -> paste in the below query and click run:

NTANetAnalytics

| where SubType == "FlowLog"

| extend Protocol = case(L4Protocol == 'T', "TCP", L4Protocol == 'U', "UDP", L4Protocol)

| extend TimeGenCET = datetime_utc_to_local(TimeGenerated, 'Europe/Stockholm')

| extend TimeGeneratedCET = format_datetime(TimeGenCET,'dd/MM/yyyy [HH:mm:ss]')

| project-rename NSGFL_Version = FaSchemaVersion

| project-rename AllowedOrDenied = FlowStatus

| project TimeGeneratedCET, VNet = split(TargetResourceId,"/")[2], NSG = split(AclGroup,"/")[8], SrcPublicIps, SrcIp, DestIp, DestPort, Protocol, L7Protocol, FlowDirection, AllowedOrDenied, AclRule, NSGFL_Version, FlowEncryption, Source_subnet = split(SrcSubnet,"/")[2], Destination_subnet = split(DestSubnet,"/")[2]  

You can see an example below:

Azure: NSG flow logs will be retired in June 2025

 On September 26, 2024 it was announced by MSFT that NSG flow logs will be retired in 2025. More specifically no new NSG flow logs can be created after June 30, 2025 and existing NSG flow logs will be retired on September 30, 2027, see link here or screenshot below:

The recommendation is to switch to VNet flow logs which covers the same as NSG flow logs plus some more things, see more info here. It also simplifies the setup somewhat as there will only be one flow log resource per VNet as opposed to one per NSG.

If you want to read more about how VNet flow logs work, which tables it creates in log analytics workspace, and how to query data (using Kusto queries), I can recommend this great article from cloudtrooper.net.

Depending on how NSG flow logs have currently been configured in your environment, this can be a bit complicated to address and involves multiple steps. At current client the NSG flow logs are deployed via an Azure policy (using the DeployIfNotExist effect). Logs are shipped both to a storage account and to a log analytics workspace. An Azure workbook is in place which reads data from the LA workspace so that NSG flow logs can be viewed and sorted in an easy manner (specifically this relates to all traffic in and out of the NSGs, source/dest, port, protocol, etc.).

Before retiring NSG flow logs, a similar setup has to be in place for VNet flow logs. The good news is that both these flow log types can run in parallel. They store data in the LA workspace in two different tables. So VNet flow logs can be set up and verified before retiring NSG flow logs.

There are two main items to be addressed (will depend on your specific setup). These will be described in separate posts:

• An Azure policy that deploy VNet flow logs for all VNets (there is a built-in policy, but we had to modify it a bit to allow for multiple subscriptions. Update 2024.10.07: The built-in policy actually works, it's just a bit unclear that it will work across subscriptions since a strongType parameter is used for choosing a the network watcher resource)
• An Azure workbook to view/search through NSG logs using the VNet flow logs data, see article here.

Using Azure Verified Modules (AVM) - Bicep

 In January 2024 Microsoft launched a new initiative called Azure Verified Modules (AVM). It's a collection of official and supported Bicep and Terraform modules that makes it easier to deploy resources in a standardized fashion as-code.

It's easy to use and fast to get started. And I was actually surprised at how well it works. One of the reasons for this initiative is that until now there hasn't been a formal, centralized repository for modules or templates so people have been relying on either there own or some public repo that might not be maintained over time.

The link for AVM is: http://aka.ms/avm

And the getting started guide (which is quite good) is here: http://aka.ms/avm/using

You should have VS Code installed and the Bicep extension. And Azure CLI, see install info here for Windows or here for MacOS.

And then you just follow the guide.

To use the modules you have to have internet connection from your source. If not, you can download a local copy of all the content and reference them locally.

For each resource module there is a basic version and an extended version with more options. You can copy the additional parameters from the extended version into the basic version or start with the extended version and remove the parts you don't need.

The good thing about modules is that most of the code (or the Bicep file) is managed/written by MSFT and you only have to reference the module in your Bicep file and fill in the relevant parameters. Below you can see a file for a basic blob storage account. 

There are several ways to deploy the code, but one is using Azure CLI, see below:

From VS Code, open a terminal and login to Azure:

> Az Login

If you are using the newest version of Azure CLI, you will be presented with a list of subscriptions available, choose the relevant subscription (alternatively run: az account set <sub name> see more info here).

Navigate to the folder where your Bicep files are located.

Deploy the Bicep with a what-if first (optional):

> az deployment group what-if --resource-group "<resource group name>" --template-file "<bicep file.bicep>"

And to deploy:

> az deployment group create --resource-group "<resource group name>" --template-file "<bicep file.bicep>"

I tried tested out a few of the modules, and they all worked fine. These are:

• Blob storage account
• Private DNS zone (for key vaults)
• Private endpoint with privateDnsZoneGroup (adds A record in PDNS zone), requires existing PDNS zone for blob storage
• Simple Windows virtual machine with public IP
• VNet with one subnet and a VNet peering (requires existing Hub VNet)

The files can be found on GitHub, see link here.

Azure: ARM template for resource health alerts

 Azure keeps track of the general resource health of a number of components. This information can be viewed under the resource -> Help -> Resource health. However, this information is available only in the portal. To receive alerts around resource health, this must be configured separately.

Resource health alerts belongs, in my opinion, in the category of essential monitoring. You want to know if any of your key components become unavailable or degraded. Once this is setup and running, then implementing utilization based alerts would be the natural next step. See here for example of a VPN tunnel bandwidth utilization alert.

Resource health alerts can be defined on a per component type level. This means that you don't have to have any of the components deployed or specified in advance. If you deploy a health alert for e.g. VPN gateways, then all existing and future VPN gateways will be included in the scope (this will also include ExpressRoute virtual network gateways).

The ARM template in this example (Based on this MSFT ARM template) is useful for a connectivity hub where you have components such as VPN gateways, connections, firewalls, and load balancers.

If you want to add or remove components, it is done in following section of the code:

Once the alert is deployed, it can be viewed in the portal under Monitor -> Alerts -> Alert rules, see below:

The ARM template also deploys an action group which sends the alerts as emails to the specified address in the parameters file.

The files are available on GitHub:

alert-ResourceHealthAlert-weu-001.json

alert-ResourceHealthAlert-weu-001.parameters.json