Skip to main content

Azure Bicep - Principal does not exist in directory

· 2 min read

Recently, I was deploying an User Assigned Managed identity, and assigning the managed identity a role assignment with Azure Bicep, and ran into an issue, where the assignment would fail, but then after a rerun would work.

Principal e892476361114c90be141d9bf20cc94b does not exist in the directory 73160ae1-aa4a-48b5-a424-d5e43d808f53. Check that you have the correct principal ID. If you are creating this principal and then immediately assigning a role, this error might be related to a replication delay. In this case, set the role assignment principalType property to a value, such as ServicePrincipal, User, or Group. See https://aka.ms/docs-principaltype

PrincpalNotFound

What was happening, was that the User Assigned Identity was created, and immediately after the role assignment was attempted, leaving no time for the role assignment API to be aware that the User Assigned Managed identity existed, even with a hard coded dependson!

The fix was to Set the: principalType into the Bicep, as ServicePrincipal, making sure that the Azure platform can wait for the replication to complete, before trying the role assignment.

The principalType property specifies whether the principal is a user, a group, or a service principal. Managed identities are a form of service principal.


resource uami 'Microsoft.ManagedIdentity/userAssignedIdentities@2023-01-31' = {
name: azUserAssignedManagedIdentity
location: location
}

resource uamiassignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
name: guid(resourceGroup().id, 'contributor')
properties: {
principalId: uami.properties.principalId
principalType: 'ServicePrincipal'
roleDefinitionId: resourceId('Microsoft.Authorization/roleDefinitions', 'b24988ac-6180-42a0-ab88-20f7382dd24c') // Contributor
}
scope: resourceGroup()
}


Microsoft Azure Management with PowerShell - Introduction

· 8 min read

To see a video of these commands in action, take a look at the following YouTube-hosted video: Microsoft Azure Management with PowerShell - Introduction

PowerShell

PowerShell is a powerful scripting and automation framework developed by Microsoft. It is designed for task automation and configuration management and is particularly useful for managing and automating Microsoft Windows environments. PowerShell uses a command-line interface with a scriptable approach, and it's built on the .NET Framework.

PowerShell and Microsoft Azure

When it comes to Microsoft Azure, PowerShell provides a robust set of cmdlets (pronounced "command-lets") that enable you to interact with and manage Azure resources, making it a valuable tool for working with Azure services.

When you run a PowerShell cmdlet to, for example, create a virtual machine or retrieve information about an Azure resource, the cmdlet translates your request into an HTTP request to the relevant Azure REST API endpoint.

There is an assumption, that you have access to an Azure environment, and the ability to create resources, within that environment.

Microsoft Azure Management with PowerShell

First up, let's verify the version of PowerShell we have, open a Powershell terminal and run:

$PSVersionTable

A supported version of PowerShell version 7 or higher is the recommended version of PowerShell for use with the Az PowerShell module on all platforms including Windows, Linux, and macOS.

The Az PowerShell module is preinstalled in Azure Cloud Shell and in Docker images.

Setting up your Azure environment for PowerShell

First thigs first, lets installed the Azure (Azure Az PowerShell module)modules.

# Install Azure Modules
# The Set-PSRepository cmdlet is used to set values for a registered repository.
# The Install-Module cmdlet is used to download one or more modules from an online gallery and installs them on the local computer. In this case, the command is installing the Az module, which provides cmdlets for managing Azure resources.
Set-PSRepository -Name 'PSGallery' -InstallationPolicy Trusted
Install-Module Az

If you don't have local administrator rights, you can install it into your user profile like below:

# Install Azure Module as Current User (as opposed to System)
# '-Scope CurrentUser` specifies that the module should be installed only for the current user. If you don't specify a scope, the default is `AllUsers`, which requires administrator permissions.

Install-Module -Name Az -Repository PSGallery -Scope CurrentUser

You can install a specific version of the Az module by specifying RequiredVersion, like below:

# Install specific version of Azure Modules

Install-Module -Name Az -RequiredVersion 7.1.0

You will find that the Azure powershell cmdlets will constantly get updated, to resolve bugs, offer new functionality, to update the modules to the ltest you can use:

# Update Azure Module
# The command Get-InstalledModule -Name Az* | Update-Module is used to update all installed PowerShell modules that start with "Az".
Set-PSRepository -Name 'PSGallery' -InstallationPolicy Trusted
Get-InstalledModule -Name Az* | Update-Module

Az is a collection of different cmdlets, across multiple Azure resource types, to view a list of avaliable commands you use 'Get-Command', like below:

# Gets Az Commands
# Note: Will take a while for all the cmdlets to list.
Get-Command -Noun Az*

Getting started with Azure PowerShell module

Lets connect to Microsoft Azure

# Connect to Azure - Interactive will prompt for credentials
Connect-AzAccount

If your wanting to connect to Azure, from a device that doesn't supoport the credential prompt, like Azure Cloudshell you can connect using another device, using a device code:

# Connect to Azure
Connect-AzAccount -UseDeviceAuthentication

If you have a Service principal, you can use this to authenticate, commonly used for automation scripts, Azure DevOps agents and GitHub runners.

# Connect to Azure using Service Principal authentication
$SecurePassword = ConvertTo-SecureString -String "Password123!" -AsPlainText -Force
$TenantId = 'yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyy'
$ApplicationId = 'zzzzzzzz-zzzz-zzzz-zzzz-zzzzzzzz'
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $ApplicationId, $SecurePassword
Connect-AzAccount -ServicePrincipal -TenantId $TenantId -Credential $Credential

Once, connected - its time to check what Azure subscriptions you can use.

# Get Azure Subscriptions
Get-AzSubscription

Once you have selected the right Azure subscription to connect to, you can set your Subscription context (modify/delete resources). Add your subscription ID, from the earlier step in between ''.

# Select Azure Subscription
$subid = ''
Set-AzContext -SubscriptionId $subid

Now you have connected to your, Azure subscription, it is time to get your Azure resources and Resource Groups

# Get Azure resource groups and resources
Get-AzResourceGroup | Format-Table
Get-AzResource | Format-Table
# Get Azure resource
Get-AzResource
# Get Azure resource by ResourceType
Get-AzResource | Where-Object {$_.ResourceType -eq 'Microsoft.Network/virtualNetworks'}
# Sort Azure resource by Name and Resource Group
Get-AzResource | Where-Object {$_.ResourceType -eq 'Microsoft.Storage/storageAccounts'} | Sort-Object Name
Get-AzResource | Sort-Object ResourceGroupName
# Working with Variables

# Working with variables and data types in PowerShell
$resourceType = 'Microsoft.Network/virtualNetworks'
Get-AzResource | Where-Object {$_.ResourceType -eq $resourceType}
# Using PowerShell operators for comparisons and calculations

$resources = Get-AzResource
$count = $resources.Count
Write-Host "You have $count resources in your Azure subscription."
# Scripting constructs: loops and conditional statements
$resources = Get-AzResource

foreach ($resource in $resources) {
if ($resource.ResourceType -eq 'Microsoft.Network/virtualNetworks') {
Write-Host "Found a virtual network: $($resource.Name)"
Write-Host "This virtual network is in $($resource.ResourceGroupName)" -ForegroundColor Green
}
}
# Scripting constructs: loops and conditional statements
$subscriptions = Get-AzSubscription

foreach ($subscription in $subscriptions) {
$resource = Get-AzResource | Where-Object {$_.ResourceType -eq 'Microsoft.Network/virtualNetworks'}

if ($resource.ResourceType -eq 'Microsoft.Network/virtualNetworks') {
Write-Host "Found a virtual network: $($resource.Name)" -BackgroundColor Black -ForegroundColor White
Write-Host "This virtual network is in $($resource.ResourceGroupName)" -ForegroundColor Green
Write-Host "This Virtual Network is in $($subscription.Name)" -ForegroundColor Green
}
}
# Error handling in PowerShell
try {
Get-AzResource -ResourceGroupName "NonexistentResourceGroup" -ErrorAction Stop
} catch {
Write-Host "An error occurred: $_. Make sure you have selected the right Resource Group" -ForegroundColor Red
}

Resource Creation

# Import Module
Import-Module Az -Verbose
#Create Azure Resource Group
New-AzResourceGroup -Name "MyResourceGroup" -Location "West US"
# Get Regions
Get-AzLocation | Select-Object -First 1
Get-AzLocation | Select-Object DisplayName, Location, PhysicalLocation, GeographyGroup | Format-Table
ate Azure Resource Group
$region = 'AustraliaEast'
New-AzResourceGroup -Name "MyResourceGroup$region" -Location $region
# Create a storage account
$uniqueId = [guid]::NewGuid().ToString().Substring(0,4)
$region = 'AustraliaEast'
$ResourceGroupName = "MyResourceGroup$region"
New-AzStorageAccount -ResourceGroupName $ResourceGroupName -Name "mystgacc$uniqueId" -Location $region -SkuName Standard_LRS -AllowBlobPublicAccess $false -verbose
#Remove Azure Storage account
$region = 'AustraliaEast'
$ResourceGroupName = $ResourceGroupName
Remove-AzStorageAccount -ResourceGroupName $ResourceGroupName -Name "mystgacc$uniqueId" -Force -verbose
Get-AzStorageAccount -ResourceGroupName $ResourceGroupName -Name "mystgacc$uniqueId" -verbose
# Create an Azure Virtual Network
$region = 'AustraliaEast'
$ResourceGroupName = 'network-prod-rg'
$VNetname = 'vnet-prod'
$subnetname = 'infraservers'
$subnetAddressPrefix = '10.0.0.0/24'

# Create a resource group
$ResourceGroup = Get-AzResourceGroup -Name $ResourceGroupName -ErrorAction SilentlyContinue

if ($null -eq $ResourceGroup)
{
Write-Host "Creating Resource Group $ResourceGroupName in $region" -ForegroundColor Yellow
$ResourceGroup = New-AzResourceGroup -Name $ResourceGroupName -Location $region -Force
}
else
{
Write-Host "Resource Group $ResourceGroupName already exists in $region" -ForegroundColor Green
}

# Create a virtual network
$AzVNET = New-AzVirtualNetwork -ResourceGroupName $ResourceGroupName -Name $VNetname -AddressPrefix '10.0.0.0/16' -Location $region

# Create a subnet
$subnetConfig = Add-AzVirtualNetworkSubnetConfig -Name $subnetname -AddressPrefix $subnetAddressPrefix -VirtualNetwork $AzVNET
# Get full object output
# Alias (This is a pipeline to the Format-List cmdlet (fl is an alias for Format-List). It formats the output as a list of properties for each object. This can make it easier to read the details of the virtual network.)

Get-AzVirtualNetwork -ResourceGroupName $ResourceGroupName -Name $VNetname # | fl
# Alias

Get-Alias | Select-Object -First 2
#splat

$configData = @{
ResourceGroupName = "MyResourceGroup"
Location = "West US"
StorageAccountName = "stgacctest100"
}

try {
New-AzStorageAccount -ResourceGroupName $configData.ResourceGroupName -Name $configData.StorageAccountName -Location $configData.Location -SkuName Standard_LRS
} catch {
Write-Error "Failed to create storage account: $_"
}
#splat as parameters

$configData = @{
"ResourceGroupName" = "MyResourceGroup"
"Location" = "West US"
"StorageAccountName" = "stgacctest100"
"SkuName" = "Standard_LRS"

}

try {
New-AzStorageAccount @configData
} catch {
Write-Error "Failed to create storage account: $_"
}
# Tags
$ResourceGroupName = 'TagTestRG'
New-AzResourceGroup -Name $ResourceGroupName -Location 'AustraliaEast'
Set-AzResourceGroup -Name $ResourceGroupName -Tag @{ Department = "Finance"; Project = "Q1" }
# Get Tag Resource Group
$ResourceGroupName = 'TagTestRG'
(Get-AzResourceGroup -Name $ResourceGroupName).Tags
$ResourceGroupName = 'TagTestRG'
$tags = (Get-AzResourceGroup -Name $ResourceGroupName).Tags
$tags.Remove("Project")
Set-AzResourceGroup -Name $ResourceGroupName -Tag $tags

Private Endpoint traffic not appearing in Azure Firewall

· 3 min read

You may have a situation where you have implemented Private endpoints and the traffic from on-premises to those Private Endpoints, either doesn't work, even though on-premises firewalls say otherwise, or is working, but doesn't appear in the Azure Firewall.

I had this recently with Azure Arc, where the endpoints failed to connect once a site-to-site VPN connection (which was working) was replaced with an expressroute connection, but going through the Azure Firewall logs, was unable to see any 443 traffic for Arc, hitting the Firewall even when the connection was working.

Private Endpoint traffic not appearing in Azure Firewall

Traffic flow: Onpremises -- (ER Circuit) -- ER gateway -- Secured hub Azure Firewall -- (Vnet Connection) -- PE (Private Endpoint)

The issue was related to how private endpoint traffic is routed differently.

If the traffic has reached the Expressroute gateway from on-premises, with routing intent, normal traffic will be forced to the AzFW first before reaching its destination, as you would think and expect.

However, for the private endpoint scenario, once a Private Endpoint is deployed to any VNET, there will be an automatic system route with the PE IP and prefix /32 installed on all of the linked NICs. The next hop for this route will be InterfaceEndpoint. This route will allow the traffic to go directly to the PE, bypassing the routing intent and other user-defined routes that are larger than /32. The /32 route propagates to these areas: Any VPN or ExpressRoute connection to an on-premises system.

See: Considerations for Hub and Spoke topology.

In an Azure Virtual Wide Area Network (VWAN), you could see this route in the virtual hub effective routes and which gets propagated to the expressroute gateway.

My traffic from on-premises to the Azure Arc went directly to the private endpoints (bypassing the Azure Firewall). Still, the route back via the Azure Firewall was completely different, leading to asymmetric routing (a packet traverses from a source to a destination in one path and takes a different path when it returns to the source).

To resolve this, we need to enable network security policies for User-Defined Routes on the subnet of the private endpoint(s):

Azure Portal - Private Endpoint - Routes

Once enabled, you should see the traffic connect and flow through your Azure Firewall almost immediately.

Reference:

Empowering Resilience with Azure backup services

· 23 min read

This article is part of Azure Back to School - 2023 event! Make sure to check out the fantastic content created by the community!

Empowering Resilience with Azure backup services

Along with the basics of the Azure Backup solutions, particularly on Virtual Machines running on Microsoft Azure, there have been a lot of changes in the last year, including Immutable vaults, enhanced policies, intelligence tiering, and cross-region restore.

Introduction

Let us start with the basics with a user story; what do we need to achieve:

"As a Cloud Infrastructure Administrator at Contoso, I want to implement an automated backup solution for virtual machines (Windows and Linux) hosted in Microsoft Azure, So that I can ensure data reliability, disaster recovery, and compliance with minimal manual intervention."

With some assumptions around further requirements, we can jump into solutions using native Microsoft Azure services to fulfil the Cloud Administrator's need. It is worth mentioning, especially around disaster recovery, that there is much more you can (and should do) do around mission-critical Azure architecture. This article will focus primarily on the data loss portion of disaster recovery with Azure Backup services.

RequirementAzure Service(s) Used
Specific (S): Backup virtual machines in AzureAzure Backup, Azure Site Recovery (ASR)
Measurable (M):
- Achieve 99% backup success rateAzure Backup, Azure Monitor
- Define and meet RTO (recovery time objective) for critical VMsAzure Backup, Azure Site Recovery (ASR)
- Monitor and optimise storage consumptionAzure Monitor, Microsoft Cost Management
Achievable (A):
- Select and configure Azure-native backup solutionAzure Backup
- Configure Azure permissions and access controlsAzure Role-Based Access Control (RBAC)
- Define backup schedules and retention policiesAzure Backup, Azure Policy
Relevant (R):
- Align with Azure best practicesAzure Well-Architected Framework, Azure Advisor
- Comply with data protection regulationsAzure Compliance Center, Azure Policy
- Support disaster recovery and business continuityAzure Site Recovery (ASR)
Time-bound (T):
- Implement within the next two Azure sprint cyclesAzure DevOps - Boards
- Regular progress reviews during sprint planningAzure DevOps - Boards
Definition of Done (DoD):
1. Select a cost-effective Azure-native backup solutionAzure Backup
2. Configure Azure permissions and access controlsAzure Role-Based Access Control (RBAC)
3. Define backup policies and RTOsAzure Backup, Azure Policy
4. Monitor and meet 99% backup success rateAzure Monitor
5. Optimize backup storage utilisationMicrosoft Cost Management
6. Create backup and recovery documentationMicrosoft Learn documentation
7. Train the team to manage and monitor the backup systemAzure Training
8. Integrate with Azure monitoring and alertingAzure Monitor
9. Conduct disaster recovery testsAzure Site Recovery (ASR)

Note: Azure DevOps - Boards are outside of the scope of this article; the main reflection here is to make sure that your decisions and designs are documented in line with business requirements. There are also some further assumptions we will make, particularly around security and RTO requirements for the organisation of Contoso.

We know to fulfil the requirements, we need to implement the following:

So, let us take our notebooks and look at the Backup sections.

Backup Center

When needing a single control plane for your Backups across multiple tenancies (using Azure Lighthouse), Subscriptions and regions, then Backup Center is the place to start with.

"Backup center provides a single unified management experience in Azure for enterprises to govern, monitor, operate, and analyze backups at scale. It also provides at-scale monitoring and management capabilities for Azure Site Recovery. So, it's consistent with Azure's native management experiences. Backup center is designed to function well across a large and distributed Azure environment. You can use Backup center to efficiently manage backups spanning multiple workload types, vaults, subscriptions, regions, and Azure Lighthouse tenants."

Backup center

As you can see, Backup center can be used to see manage:

  • Backup instances
  • Backup policies
  • Vaults
  • Monitor and report on backup jobs
  • Compliance (ie Azure Virtual Machines that are not configured for backup)

You can find the Backup Center directly in the Azure Portal.

Backup center

We can create and manage these resources by ourselves, but throughout this article, we will refer back to the Backup Center, to take advantage of the single pane of glass and integrate these resources.

Create Vault

In Microsoft Azure, there are two types of Vaults that the Backup center works with. These vaults are:

Backup center

Depending on your requirements depends on which Vault you will need to create (for our purposes, we will need the Recovery Services vault); Backup Center makes it remarkably easy to configure a new vault and select the right vault type by using the wizard.

Please refer to: Support matrix for Azure Backup for further information.

  1. Navigate to Backup Center
  2. Click on Vaults
  3. Click + Vault
  4. Select Recovery Services vault
  5. Select Continue
  6. Specify a location and Resource Group to house your Recovery Services vault
  7. Specify your vault name (abbreviation examples for Azure resources)
  8. Click Next: Vault properties

Immutability: I talked a bit about immutability in another blog article: You Can't Touch This: How to Make Your Azure Backup Immutable and Secure. Essentially an immutable vault, prevents unauthorised changes and restore point deletions, for this article, we will enable it to prevent unintended or malicious data loss (keep in mind with immutable vaults, reducing retention of recovery points is not allowed).

  1. Check enabled immutability, and click Next: Networking.
  2. We can join our Recovery Services vault to our private network using private endpoints, forcing Azure Backup and Site Recovery to traverse a private network, for the purposes of this article, we will skip it. Click Next: Tags
  3. Enter in Tags (tags useful for a Recovery Service vault, could be: Application, Support Team, Environment, Cost Center, Criticality)
  4. Click Review + Create

Create Azure Recovery Services Vault

If we navigate back to the Backup Center and then Vaults (under Manage), we will be able to see the newly created vault.

We now have our Backup solution provisioned for the Cloud Administrator to use, but we next need to define the policies for the backup.

Create Backup Policies

Now that we have our Recovery Services vault, we need to create backup policies; these backup policies will help define the frequency of backups, the retention (Daily, weekly, monthly, yearly) and vault tiering, which enables the Recovery Services Vault to move recovery vaults to an archive tier (slower to restore, but can be cheaper overall, for those long retention policies).

Backup policies are very organisation-specific and can depend a lot on operational and industry requirements; some industries have a legal obligation to store their backups for a certain number of years, the Azure compliance center documentation may help, around security and data requirements, make sure your backup policies are understood by the business you are working with.

For Contoso, we have the following requirements:

ResourceDailyWeeklyMonthlyYearlySnapshot Retention (Hot)
Critical Application DB - Prod7 days - Every 4 Hours4 weeks6 months7 years5 days
File Server- Prod7 days - Every 4 Hours6 weeks6 months7 years5 days
Web Application VM - Dev20 days8 weeks12 months2 years2 days
Database Server - Dev30 days8 weeks12 months2 years2 days

There are a few things to call out here:

  • We can see that for Development, items need to be retained for 2 years
  • For Production, its 7 years
  • Snapshots need to be stored for 5 days and 2 days to allow fast restore
  • Production requires a backup to be taken every 4 hours to reduce RTO (Recovery point objective)

Create Azure Recovery Services Vault

If we take a look at the Snapshot retention, we can leverage Instant restore snapshots, to restore the workloads, quickly from the previous 5 days, reducing our time RTO (recovery time objective), and overall impact of an outage or restore, by storing the snapshots locally (as close to the original disk) without putting it (waiting for it) into archive (slower disk), this will incurr more cost, but dramatically reduces restores time. I recommend always keeping a few Instant restore snapshots available for all production systems.

Snapshot

Let us create the policies (we will only create one policy, but the same process can be used to create the others).

  1. Navigate to Backup Center
  2. Click on Backup policies
  3. Click + Add 1 .Select Azure Virtual Machines
  4. Select the Vault created earlier
  5. Click Continue
  6. As this will be the policy for the Critical Application DB, we will specify: Enhanced (due to the multiple backups, Zone-redundant storage (ZRS) snapshots)
  7. Specify a Policy name, ie Tier-1-Prod-AppDB
  8. Specify Frequency to: Hourly, Schedule to Every 4 Hours, and Duration: 24 Hours
  9. Specify Retain instance recovery snapshots for '5' days
  10. Update Daily Backup point to: 7 days
  11. Configure the Weekly backup point to occur every Sunday and retain for 4 weeks
  12. Configure the Monthly backup point to occur on the first Sunday of the month and retain for 6 months
  13. Configure the yearly backup point to occur on the first Sunday of the year and retain for 7 years
  14. Select enable Tiering, and specify Recommended recovery points
  15. You can also update the Resource Group name used to store the Snapshots.
  16. Click Create

Snapshot

Note: If you want, you can repeat the same process to create any others you need. Remember, with immutable vaults, you cannot reduce the retention (but you can add), so if starting for the first time, keep the retention low until you have a clear direction of what is required. A workload can use the same policy. A Standard (not Enhanced) policy may be all you need for Development workloads.

Add Virtual Machines

Now that we have our Recovery Services Vault and custom backup policies, it's time to add our Virtual Machines to the backup! To do this, we can use the Backup center to view Virtual Machines that are not getting backed up, and then configure the backup.

  1. Navigate to Backup Center
  2. Click on Protectable data sources
  3. Click on the ellipsis of a Virtual Machine you want to backup
  4. Click on Backup
  5. Select the appropriate Backup vault and policy
  6. Click Enable backup

Although cross-region restore is now supported on a Recovery Services vault, the second region is read-only (RA-GRS), so make sure you have a backup recovery vault created in the region (and subscription) of the virtual machines you are trying to protect. Backup center, can see all Recovery services vaults across multiple regions and subscriptions that you have access to.

Add Virtual Machines

Once added, the Virtual Machine will now get backed up according to the specified policy.

Its worth noting that you can backup a Virtual Machine if it is deallocated, but it will Crash-consistent (Only the data that already exists on the disk at the time of backup is captured and backed up, and it triggers a disk check during recovery) compared to Application consistent, which is more application and OS aware, so can prepare to the OS and applications for the backups to make sure that everything is written successfully to the disk ahead of the backup. You can read more about Snapshot consistency.

Monitor Backups

Now that we have our Recovery Services Vault, policies and protected items (backed up Virtual Machines), we need to monitor to make sure that the backups are working. Backup center gives us a complete view of Failed, In Progress, and Completed jobs in the overview pane, which is excellent for a quick view of the status across subscriptions and regions.

Azure BackupCenter

But you may want something a bit more detailed; let us look into some of the options for monitoring your backups.

Alerts

As part of operational checks, you may want assurance or a ticket raised if there's an issue with a backup; one of the ways to achieve this is to set up an email alert that will send an email if a backup fails.

By default, these types of alerts are enabled out-of-the-box on a recovery services vault; examples of alerts can be found here: Azure Monitor alerts for Azure Backup, these can be displayed in the Recovery Services Vault or Backup Center blade, immediately.

If a destructive operation, such as stop protection with deleted data is performed, an alert is raised, and an email is sent to subscription owners, admins, and co-admins even if notifications aren't configured for the Recovery Services vault.

TypeDescriptionExample alert scenariosBenefits
Built-in Azure Monitor alerts (AMP alerts)These are alerts that will be available out-of-the-box for customers without needing additional configuration by the customer.Security scenarios like deleting backup data, soft-delete disabled, vault deleted, etc.Useful for critical scenarios where the customer needs to receive alerts without the possibility of alerts being subverted by a malicious admin. Alerts for destructive operations fall under this category
Metric alertsHere, Azure Backup will surface backup health-related metrics for customers' Recovery Services vaults and Backup vaults. Customers can write alert rules on these metrics.Backup health-related scenarios such as backup success alerts, restore success, schedule missed, RPO missed, etc.Useful for scenarios where customers would like some control over the creation of alert rules but without the overhead of setting up LA or any other custom data store.
Custom Log AlertsCustomers configure their vaults to send data to the Log Analytics workspace and write alert rules on logs.'N' consecutive failed backup jobs, Spike in storage consumed, etc.Useful for scenarios where there is a relatively complex, customer-specific logic needed to generate an alert.

Backup alerts are supported by Azure Monitor, so under Azure Monitor, and Alerts pane you can see all your other alerts, including Azure Backup alerts from a single pane.

Azure BackupCenter

If you want to configure notifications via emails for other types of alerts, such as Backup failures, we can use Azure Monitor Action Groups and Alert processing rules, to let us know, without having to login to the Azure Portal directly, so let us create an email alert.

To do this, we will create an Action Group and Alert Processing rule.

ComponentDescription
Action GroupAn Action Group is a collection of actions or tasks that are executed automatically when an alert that matches specific criteria is triggered. Actions can include sending notifications, running scripts, triggering automation, or escalating the alert. Action Groups help streamline incident response and automate actions based on the nature and severity of an alert.
Alert Processing RuleAn Alert Processing Rule is a set of conditions and criteria used to filter, categorize, or route incoming alerts within a monitoring or alerting system. These rules enable organizations to define how alerts are processed, prioritize them, and determine the appropriate actions to take when specific conditions are met. Alert Processing Rules are crucial for managing and efficiently responding to alerts.
  1. Navigate to Backup Center
  2. Click on Alerts
  3. Click on Alert Processing rule
  4. Click + Select Scope
  5. Click All Resource Types, and Filter by: Recovery Services Vault
  6. Select your Recovery Services vault, you would like to alert on
  7. Click Apply
  8. Click on Filter, and change: Alert condition = Fired.
  9. Click Next: Rule Settings
  10. Click Apply action group
  11. Click + Create action group
  12. Select the Subscription, Resource Group to store your action group (i.e. monitor resource group)
  13. Give the Action Group a name, and give it a Display name
  14. Specify Notification type (ie Email/SMS message/push/voice)
  15. For this article, we will add an Email (but you can have it ring a number, push a notification to the Azure Mobile App)
  16. Enter in your details, then click Next: Actions
  17. In the Actions pane, is where you can trigger automation, such as Azure Logic Apps, Runbooks, ITSM connections, Webhooks etc., to help self-remediate the issues, or better notifications, such as a Logic App that posts in a Teams channel when an alert is fired, or a wehbook that triggers a webpage to update. In this example, we will leave it empty and rely on email notifications and click Next: Tags
  18. Enter any Tags and click Review + create
  19. Make note of Suppress Notifications; this could be handy during scheduled maintenance windows where backups may fail due to approved work.
  20. Once the Action Group has been created, click Next: Scheduling
  21. Select Always
  22. Click Next: Details
  23. Enter in a Resource Group, for the Alert processing rule to be placed
  24. Enter in Rule name, description and click Review + Create

Azure BackupCenter

As you can see Azure Monitor integration into backups, gives you some great options to keep on top of your backups, and integrate with other systems, like your IT Service Management toolsets.

Azure Site Recovery

Azure Site Recovery (ASR) can be used to migrate workloads, across Availability Zones and regions, by replicating the disks of a Virtual Machine to another region (GRS) or zone (ZRS), in fact Azure Resource Mover uses Azure Site Recovery when moving virtual machines between regions. Azure Site Recovery can also help with migrating workloads outside of Azure, to Azure, for disaster recovery.

When looking at migrating workloads, to Azure from the VMWare stack, consider the Azure Site Recovery Deployment Planner for VMware to Azure to assist.

For the purposes of this guide, we will achieve disaster recovery of our virtual machine, by replicating it to another region (i.e. from Australia East to Central India).

Azure Recovery Services contributes to your BCDR strategy: Site Recovery service: Site Recovery helps ensure business continuity by keeping business apps and workloads running during outages. Site Recovery replicates workloads running on physical and virtual machines (VMs) from a primary site to a secondary location. When an outage occurs at your primary site, you fail over to a secondary location, and access apps from there. After the primary location is running again, you can fail back to it. Backup service: The Azure Backup service keeps your data safe and recoverable.

Azure BackupCenter

Just as important (if not more) than the technology to enable this, clear business requirements and preparation is paramount for a successful disaster recovery solution, I highly recommend the Azure Business Continuity Guide. Supplied by the Microsoft Fastrack team, this guide includes resources to prepare for thorough disaster recovery plan.

The key to successful disaster recovery is not only the workloads themselves but supporting services, such as DNS, Firewall rules, connectivity etc., that need to be considered, These are out of the scope of this article but the following Microsoft Azure architecture references are worth a read:

For Azure Site Recovery to work, it relies on a mobility service running within the Virtual Machine to replicate changes, the source virtual machine needs to be on to replicate the changes.

When you enable replication for a VM to set up disaster recovery, the Site Recovery Mobility service extension installs on the VM and registers it with Azure Site Recovery. During replication, VM disk writes are sent to a cache storage account in the source region. Data is sent from there to the target region, and recovery points are generated from the data.

Azure Site Recovery, does not currently support virtual machines protected with Trusted Launch.

Enable Azure Site Recovery

For now, we have 'VM1' a Ubuntu workload, running in Australia East, with a Public IP, that we will failover to Central India. The source Virtual Machine can be backed up normally by a vault in the source region, and replicated to another vault in the destination region.

Azure Site Recovery has a specific Operating System and Linux kernel support. Make sure you confirm that your workloads are supported.

  1. Navigate to Backup Center
  2. Click on Vaults
  3. Create a new Recovery Services vault in your DR (Disaster Recovery region - ie Central India)
  4. Click on Site Recovery
  5. Under Azure Virtual Machines, click on: Enable replication
  6. Specify the source Virtual Machine, you wish to migrate
  7. Click Next
  8. Select your source Virtual Machine
  9. Click Next
  10. Select the target location (i.e. Central India)
  11. Select the target Resource Group
  12. Select the Target Virtual Network (create one if it doesn't exist)
  13. Select the target subnet
  14. Under the Storage, you can consider changing the replica disk to Standard, to reduce cost (this can be changed later).
  15. Select a cache storage account (The cache storage account is a storage account used for transferring the replication data before its written to the destination disk)
  16. You can then adjust the availability zone of the destination virtual machine
  17. Click Next
  18. Here we can define a Replication Policy (a replication policy in Azure Site Recovery is a set of rules and configurations that determine how data is replicated from the source environment to the target environment (Azure) in case of a disaster or planned failover, such as retention, ie you can restore a point within the retention period) we will leave the default 24-hour retention policy.
  19. We can specify a Replication Group, An example of a replication group is application servers that need to be consistent with each other, in terms of data ( replication policy in Azure Site Recovery is a set of rules and configurations that determine how data is replicated from the source environment to the target environment (Azure) in case of a disaster or planned failover.).
  20. Specify an automation account to manage the mobility service, and we will leave the update extension to be ASR (Azure Site Recovery) managed.
  21. Click Next
  22. Click Enable replication
  23. At the Recovery Services Vault, under Site Recovery Jobs you can monitor the registration, registration and initial replication can take 30-60 minutes to install the agent and start the replication.

Azure BackupCenter

Failover to the secondary region using Azure Site Recovery

Once your virtual machine has been replicated in the secondary region. you can do a Failover, or Test failover. A Test failover is recommended, in your DR testing, and application testing.

Azure BackupCenter

AspectFailoverTest Failover
PurposeTo switch to a secondary site during a disaster or planned maintenance event.To validate your disaster recovery plan without impacting production.
Impact on ProductionDisrupts production services as the primary site becomes unavailable during the failover process.No impact on production services; the primary site remains operational.
Data ReplicationReplicates data from primary to secondary site, making it the active site during the failover.Uses the same replicated data but doesn't make the secondary site the active site; it's for testing purposes only.
Recovery TimeLonger recovery time, as it involves setting up and activating the secondary site.Faster recovery time, as it doesn't require making the secondary site the active site.
Data ConsistencyEnsures data consistency and integrity during the failover process.Ensures data consistency for testing but doesn't make the secondary site the primary site.
CostMay incur additional costs due to the resources activated at the secondary site.Typically incurs minimal additional costs as it's for testing purposes.
Use CasesActual disaster recovery scenarios or planned maintenance events.Testing and validating disaster recovery procedures, training, and compliance.
Post-OperationThe secondary site becomes the new primary site until failback is initiated.No change to the primary site; the secondary site remains inactive.
Rollback OptionFailback operation is required to return to the primary site once it's available.No need for a rollback; the primary site remains unaffected.
  1. Navigate to your destination Recovery Services Vault
  2. Click on REplicated Items
  3. Select the Virtual Machine you wish to recover in your second region
  4. Select Test Failover (or Failover, depending on your requirements)
  5. Select your Recovery point and destination Virtual network
  6. Select Failover
  7. If it is a test failover, you can then Clean up your Test failover (deleted replicated item) after you have tested

Azure BackupCenter

Azure Policies

Automatically, mapping of Virtual Machines, to backup policies can be done using Azure Policy.

Azure policies such as:

  • Azure Backup should be enabled for Virtual Machines
  • Configure backup on virtual machines without a given tag to an existing recovery services vault in the same location
  • Disable Cross Subscription Restore for Backup Vaults
  • Soft delete should be enabled for Backup Vaults

More, are built-in to the Azure policy engine and can be easily assigned, across subscriptions and management groups, found in the Backup Center.

  1. Navigate to Backup Center
  2. Click on Azure policies for backup
  3. Click on a policy and click Assign

You can find a list of custom and built-in policies at the AzPolicyAdvertizerPro website.

Azure AutoManage

Azure Automanage can be used alongside Azure policy, to onboard Virtual Machines, into backup, patching etc automatically, with reduced manual intervention, and although not directly part of this article, what you have learned can be used to develop your automanage profiles.