The Real Problem
This post is following on from part 1 about resource tagging on resource groups where we setup azure policies to look for the existence of resource tags on resource groups. While this is helpful to understand the scale of the problem, the real problem is getting people to tag their resource groups when they create them. I work with a bunch of misfits and mavericks and while all brilliant in their own right, asking them to do anything as simple as tagging their stuff is about as futile as yelling at the rain to stop.
The Solution
Since asking failed, let's try telling them. Same as in part one let's assign a policy that will force tags to be applied during object creation. You can set the tag value to the text wildcard *
While this will work 100% of the time, it does come along with a few issues. This list is by no means exhaustive and I will update it when and if we find more. If you have tried or are trying this and find any other issues arising from enforcing tags on resource groups, please comment and I can explore and add the content to this post.
Can't use the Portal
At the time of writing this, unfortunately, Azure does not ask you to add tags during the creation of Resource groups through the UI so you simply get an error.
You have to use PowerShell or ARM templates to create resource groups.
New-AzureRmResourceGroup -Name "Blahdedah" -Location "WestUS" -Verbose -Force -Tag @{Owner="matt quickenden"; Solution="IoT Testing"}
Adding a template to Azure
So you're thinking you could upload a template with parameters for tags to Azure Template so you could keep a UI experience?
{ "$schema": "https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentTemplate.json#", "contentVersion": "1.0.0.1", "parameters": { "ResourceGroupName": { "type": "string" }, "ResourceGroupLocation": { "type": "string" }, "OwnerTag": { "type": "string" }, "SolutionTag": { "type": "string" } }, "variables": { "tags": { "Owner": "[parameters('OwnerTag')]", "Solution": "[parameters('SolutionTag')]" } }, "resources": [ { "type": "Microsoft.Resources/resourceGroups", "apiVersion": "2018-05-01", "location": "[parameters('ResourceGroupLocation')]", "name": "[parameters('ResourceGroupName')]", "properties": {}, "tags": "[variables('tags')]" } ], "outputs": {} }
Close enough, you could limit the location to actual Azure locations etc, but let's check if it works.
Interestingly, Azure creates a resource group first before trying to execute your code. This could work for creating a blank template using ARM but the PowerShell is probably easier or just including the tags in your main ARM template.
Visual Studio Deployments
Deploying quickstart templates from visual studio fails.
the workaround is to open the Deploy-AzureResourceGroup.ps1 script inside the project. Scroll down to the line that starts with New-AzureRmResourceGroup. It should be around line 93.
Edit that line so your tags are added at deployment. That line should look something like this after you have edited it:
New-AzureRmResourceGroup -Name $ResourceGroupName -Location $ResourceGroupLocation -Tag @{Owner="harry potter"; Solution="Deploy with tags "} -Verbose -Force
Azure Backup
Using Azure backup vault to create a backup of a VM. If you have it already set up it seems to be just fine, however, when you attempt to create a new one backup it seems to fail.
Taking a look at the activity log reveals 'Update resource group' failed
cutting through the rest we can find the status error message
"statusMessage": "{\"error\":{\"code\":\"RequestDisallowedByPolicy\",\"target\":\"AzureBackupRG_westus_1\",\"message\":\"Resource 'AzureBackupRG_westus_1' was disallowed by policy. Policy identifiers: '[{\\\"policyAssignment\\\":{\\\"name\\\":\\\"Enforce Resource Group Tag Like Value SOLUTION Pattern\\\",\\\"id\\\":\\\"/subscriptions/....
Adding an exclusion to the enforcement policy for the resource group seems to have done the trick. New backups to this backup vault can be created and continue to run without any issues.
Next Steps
While this enforcement has created some problems, there aren't any show stoppers at the moment and if it really is an issue, for a particular use case or project if you can't simply add an exclusion you can disable the policy temporarily and re-enable it for a month. Some deployments might get through without tags but we can hunt those people down through the activity logs. This is more a catch-all tool so I still consider this useful and still functional so we will proceed.
Next up we will take a look into getting at the data and trying to get closer to the ultimate goal of putting data in an email targeted at the resource group owners.