Select Page

Azure tagging. Revisiting case sensitivity.

As we keep seeing – Azure tag names are not case-sensitive, until they are.

Per the documentation

Tag names are case-insensitive for operations. A tag with a tag name, regardless of the casing, is updated or retrieved. However, the resource provider might keep the casing you provide for the tag name. You’ll see that casing in cost reports.

Tag values are case-sensitive.

Per the now four year old bug, Azure Resource Manager itself should respect this (i.e. case insensitive and case preserving)

Then we get issues with:

CostCenter, Costcenter, costcenter – all being different depending on the tooling in use.


Released back in May, this looks to be stable.

Update is (again) super clean:

zypper migration

select the migration target (i.e. SLES 15 SP5), approve the EULA, wait a while.

I’ve been flagging the ease of upgrade for several years. SUSE have this nailed.

Update: except Redis got a tad confused. Needed to get it re-setup to start correctly.

Update again: openSUSE build server saves the day again: Install package openSUSE:Backports:SLE-15-SP5 / php8-redis along with

More kusto – reading all Azure VNETs and their associated network space

Another one, again demonstrating the use of extend and mv-expand to pull out the multi-valued array.


| join kind=leftouter (ResourceContainers | where type==’microsoft.resources/subscriptions’ | project SubName=name, subscriptionId) on subscriptionId

| where type == “”

| extend vnetCount =array_length(properties.addressSpace.addressPrefixes)

| mv-expand vnet = properties.addressSpace.addressPrefixes

| project SubName, resourceGroup, name, vnetCount, vnet

| order by tostring(vnet) asc

More kusto – Reading email recipients for Azure Action Groups

Lots of hygiene work, including cleaning up Azure Action Groups that send to individual emails. That’s a red flag and anti pattern.

Here’s the KQL to read the Action Groups, their subscriptions, and expand out the recipients.

It’s easy work to continue to audit this, and clean up the dead wood.


| join kind=leftouter (ResourceContainers | where type==’microsoft.resources/subscriptions’ | project SubName=name, subscriptionId) on subscriptionId

| where type == “microsoft.insights/actiongroups”

| extend emailRecsCount =array_length(properties.emailReceivers)

| mv-expand emailRecs = properties.emailReceivers

| project SubName, resourceGroup, name, emailRecsCount,, emailRecs.status, emailRecs.emailAddress

| order by [‘name’] asc

Using the Azure VM Agent to find server health

I discovered a pool of servers that seemed to be unused, and used the Azure VM Agent “Run PowerShell Script” to determine the real health.

The output told me: not domain joined, not managed, not being patched, so targets for decommissioning.

$boot = Get-CimInstance -ClassName Win32_OperatingSystem

$hotfix = Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 1

$name = Get-CimInstance -Classname Win32_ComputerSystem

write-host “Server $($ Domain $($name.domain)”

write-host “Last reboot $($boot.LastBootUpTime)”

write-host “Last patch $($hotfix.HotFixID) $($hotfix.InstalledOn)”

Last reboot 10/12/2022 18:50:02
Last patch KB4495585 05/15/2019 00:00:00

Windows Admin Center and Dell OpenManage/iDRAC integration

Back in a previous life I worked closely with colleagues working on the integration of Dell, HPE and other server hardware vendors into the Microsoft infrastructure management tooling from System Center.

I’m a year in to using Windows Admin Center and the integration with Dell OpenManage and the Dell iDRAC.

It’s (usually) a joy; as part of the patching cycle, open the Dell OpenManage integration blade in Windows Admin Center, check for compliance, see which components need updating, update them.