This is a bit of a hasty post. Been a shortened week for me, and I’m heading out of town tomorrow for my brother’s wedding. But in conversation late today, a question was raised: “Can you add VMs to a Recovery Service Vault’s backup policy dynamically using Azure Policy and a naming pattern?”
The answer? Sure!
Let’s set the stage. I have the following Recovery Services Vault, with all the default backup policies:
I also have the following 3 VM’s:
The goal is to build an Azure Policy such that all the servers that start with AZM**** are automatically backed up to the RSV-MANAGEMENT vault using the built-in policy (ignoring that third AZS*** server). It must remediate existing servers and capture newly built machines and add them to the vault as well.
To start, we need to locate an Azure Policy that we can use as a template for tinkering. From the list of built-in Azure Policies, I filtered by the word ‘backup’ and got quite a list.
Don’t ask me why, but I used the marked policy above as my base. It will work just fine, but the first one in the list is a simpler, cleaner policy. Again, both of these will work (and I’m too lazy to tear it all down and rebuild it at this point).
Start by duplicating the definition – never edit a built-in policy definition (I’m not that lazy). In the definition for the newly copied policy, we simply want to add a filter which will include servers that match a pattern.
Since coding Azure Policy isn’t something I do on a regular basis, I needed to ask Bing how to format it properly. I stumbled on the official Microsoft documentation for the policy Definition structure, and that led me to the following two blocks:
I need a way to match the pattern AZM***, and I don’t know exactly how long the server name will be (could be AZMFOO01, could be AZMFOOBAR01), so using like with the wildcard * seems to be the way to go.
This one was simple – I can just use the name properly of the resource. So now I can put the condition and field together to come up with my pattern:
In my policy definition, notice that I added it as the first check, above the built-in condition that it must be a virtual machine. For me, this is just easier to read – you do what works best for you.
Once the definition is created, now it needs to be assigned. I assigned my policy to the subscription (to capture any VMs built anywhere in the sub that matches the name pattern), and I also allowed the creation of a managed identity for remediation. This created a system assigned MI and apply the appropriate permissions at the desired scope so that the policy can be enforced:
The parameters for this particular policy assignment want location and backup policy :
This says that it will check for VM’s in West US 2 only, and the properties of the Backup Policy show the built-in EnhancedPolicy in the vault I chose:
With the assignment complete, I let it run a remediation task for existing VM’s that match the pattern.
In this case it found the two existing VMs that were there, and it successfully added them both to the Recovery Vault.
The last test was to build a brand new machine, named AZMFOO03 and see if the policy automatically added it to the vault.
Click-Ops’d my way to getting a third VM built, waited about 10 minutes or so after the VM was built, and I now have all three of these VM’s in the Recovery Services Vault:
Pretty slick, and pretty easy. The hardest part, really, is just deciding which of the pattern statements to use. If your environment has a server naming convention that segregates servers by [insert method], then this could be a way of segregating the backup vaults as well. And by incorporating Azure Policy with a Managed Identity, we’ve now achieved an automated way of ensuring all current and future servers deployed get backed up properly.