With over 70+ Microsoft Azure regions across the globe and new regions popping up all the time (for example new New Zealand North region coming in 2023)!

Migrating resources between regions is something that you may want to consider. Let's look at migrating workloads between them, by using Azure Resource Mover.

Overview​

Azure Resource Mover helps you to move Azure resources between Azure regions, offering a single pane of glass to migrate different resource types, such as Virtual Machines or Azure SQL databases from a single portal without having to know how to migrate the individual underlying resources, or trying to work out the dependencies for each resource.

Why would you migrate resources between Regions?​

Let’s start with why would you migrate resources between regions? Common scenarios include:

• Taking advantage of new Azure region expansions to be closer to customers and reduce latency (such as migrating from Australia East to New Zealand North).
• Increasing availability and resilience by moving to Azure Availability Zones, from regions that don’t currently support it.
• Meeting data residential and compliance requirements.
• Consolidating workloads for mergers and acquisitions.
• The cost of resources in one region may also be cheaper than in another.

So, what are the risks of migrating resources?​

Whatever your reason, moving your applications from Point A to Point B is often no easy task. Here are common reasons why:

• Moving resources can pose a risk of an outage.
• Workloads are often made up of multiple services, each requiring its own method and tools to move.
• Interdependencies are often not understood.
• Testing and rollback of these complex scenarios can be daunting.

So, what are the benefits of using Azure Resource Mover?​

So, what are some of the benefits that Azure Resource Mover offers us?

• The ability to plan with ease, reducing the time and complexity of your move.
• Streamline your move process by identifying dependencies.
• Plan and test your move multiple times.
• Stage your move as part of scheduled downtime.
• Azure Resource Mover helps you orchestrate seamlessly with a consistent experience across common Azure resources​:
• Move multiple resources through a single pane of glass.
• Reduce manual touchpoints, which could increase the change of services being missed.
• Reduce overall time for your move from months to weeks or days* (based on the service and data being consumed).
• Azure Resource Mover helps you move with confidence by planning, testing, and moving related resources together and validating and testing your move before final commitment (by testing your migrated services, while having the peace of mind that your source resources are left intact until you commit to the migration).

So to recap, Azure Resource Mover offers you a unified experience to move multiple resource types across regions while validating dependencies between services and giving you the flexibility to adjust resources such as the Names, SKUs and Availability Zones during the migration to the destination region.

What can Azure Resource Mover move?​

The currently supported resources (as of July 2022) are:

• Azure Virtual Machines
• Azure SQL Database
• Azure Virtual Network
• SQL elastic pools
• Azure Load balancer
• Public IP
• Resource group
• Network security group
• Network interfaces
• Azure Availability Sets

And Azure Storage account region replication support is scheduled in the next 6-9 months to be released so the storage account migration should be ready by the time the NZ North comes live.

An updated list of Resources currently supported by Azure Resource Mover can be found here: What resources can I move across regions using Resource Mover?

Azure Resource Mover - The 6-Step Process!​

Azure Resource Mover uses a 6-step process.

1. The first step is to select the resources you´d like to transfer! A tip is to just pick the Virtual Machine object if you are migrating Virtual Machines, the dependencies will be identified by the Azure Resource Mover service itself!
2. The dependency check will be performed, identifying that you need to move other resources along with your virtual machine (Resource Group, NIC, Managed Disks etc.)
3. Start the preparation. This step initiates the preparation while creating a resource group with a dedicated Storage Account and a Recovery Services Vault to perform the move. The prepare step also creates the underlying ARM template deployments for the destination region.
4. Move initiation starts the process of transferring the resources to the target region. Certain dependencies should be 'committed' before preparation can be initiated, on other resources. If your resource is stateless such as a Network interface, a new ARM deployment will occur, but if your machine is stateful such as a Virtual Machine, Azure Site Recovery will start to copy the disk of your source machine to the target region.
   ATTENTION! Resources might be temporarily not available – perform these steps out of business hours
5. Commit your move or discard the move! Depending on if you want to complete the move process you can decide whether you want to keep or remove the replicated resources in the destination region.
6. Delete the source is the cleanup step required to remove the source resources from the region you have transferred from to finish your migration.

Let's see Azure Resource Mover in action​

So enough talking, let us see Azure Resource Mover in action?

Demo​

For our demo, we are going to migrate from Australia East to West US3.

Make sure you review your quota and subscription limits, for the other region before you look to migrate them.

So what resources are we going to migrate?

• Virtual Network
• Azure SQL Database
• Azure Virtual Machine & associated dependencies (Resource Groups, Network Interfaces, Managed Disks).

Note: There is no Audio in the demo video below, but it will guide you through Azure Resource Mover and some of the options.

Some items to note​

• You can't select individual disks as resources to move across regions. However, disks are moved as part of a VM move.
• You can migrate encrypted Virtual Machines but needs manual intervention to copy the keys
• You can move resources to another subscription AFTER moving resources to the destination region.
• You cannot move peered Virtual Networks across subscriptions, you need to remove the peering first, then re-add it back in the destination region.
• Make sure your quota and required services have been registered and increased for the additional region
• Azure Resource Mover can be used to migrate Azure Virtual Desktop session hosts across regions.
• DNS records can be key to reducing the complexity and interruption to end users as part of your migration.
• There are PowerShell cmdlets (i.e., New-AzResourceMoverMoveCollection)

Additional Resources​

To learn more about Azure Resource Mover, visit the Azure Resource Mover page.

• azure.microsoft.com/services/resource-mover

Azure Resource Mover videos:

• Microsoft Azure Resource Region 2 Region Migration - Luke Murray
• Azure Unblogged - Azure Resource Mover
• Azure Friday Video
• Azure Resource Mover - Move resources between regions, subscriptions and resource groups -John Savill

We've all been there! In the Azure portal, looking for a resource or subscription and cannot find it! Once permissions are ruled out, you are left with the Portal itself, and the filter.

You may see a checkbox or message like the below:

Show only subscriptions selected in the global subscriptions filter.

This is because the Microsoft Azure portal has a default filter, which is very handy in hiding subscriptions and resources you don't want to see or use all the time.

The following Microsoft document 'Manage Azure portal settings and preferences' is a great place to start, but let us take a look ourselves.

Azure Portal Filters​

Global Subscription Filter​

Let us take a look at the Global subscription filter.

1. Log in to the Microsoft Azure Portal
2. Click on 'Settings' on the top right-hand navigation bar
3. 
4. Click on the dropdown list under the Default subscription filter
5. Here you can select or de-select the subscriptions you want to display by default in the Microsoft Azure Portal.
6. 
7. There is no Save button, the changes will automatically take effect.

Advanced Filters​

Let us take a look at the Advanced subscription filters.

1. Log in to the Microsoft Azure Portal
2. Click on 'Settings' on the top right-hand navigation bar
3. 
4. Toggle Advanced Filters
5. Click Continue to reload the Azure Portal, your Global subscription filter will be changed to an advanced filter.
6. Click Modify Advanced filters
7. Click + Create a filter
8. Here you have the ability to create a filter or filters, to help match your requirements. You can create filters based on subscription ID and subscription name.

1. Using the logic above, we can easily create filters based on the state of a subscription and name, an example is, creating a filter that displays all subscriptions with 'dev' in its name:
2. 

You can only have one Filter displayed at once in the Azure Portal, but you can easily switch between them, by clicking Activate, next to the filter name.

If you wish to disable Advanced Filters, and go back to the Global Filter, you can deselect the Toggle for Advanced Filters.

Additional Resources​

Microsoft Docs​

To get the most out of your Azure Portal experience, the below Microsoft documentation is worth a read (in no particular order).

• Manage Azure portal settings and preferences
• Azure subscription states
• Add, remove, and rearrange favorites
• View and filter Azure resource information

Send Feedback to Microsoft​

On the last note, Microsoft has made it easy to create Feedback, that will get fed back to the Azure Portal and product teams straight in the Microsoft Azure Portal, if you ever see anything that may need changing, or a link out of date don't hesitate to send your feedback to Microsoft, by pressing the little Feedback button on the top right of your navigation bar.

The Microsoft Azure portal is in development all the time and is now built with Azure Resource Graph capabilities, it is very easy not to try and see new functionality, so I recommend you keep your eyes out and try new features.

The Microsoft Azure Portal displays a list of Recent resources (whether they are subscriptions or Resources) you have accessed, usually when you first log in to the portal itself.

This capability makes it quick to access resources you use the most often, but sometimes you may want to view the resources in a list for easy access or clear the recent resources (ie if you are going to do a presentation) - this is how you can do it.

The Azure portal has a service called: Recent, to access it.

1. Log in to the Microsoft Azure Portal
2. In the search bar type in: Recent
3. 
4. Select Recent
5. You will be taken to the Recent Resources view, where you can select Clear to clear your Recent Resources, or you can view all your recent resources for easy access.
6. 

You may be attempting to deploy an Azure Landing Zone, such as the Enterprise Scale Landing Zone and receive the following error:

You don’t have authorization to perform action 'Microsoft.Resources/deployments/validate/action'.

This is because by default, even if you have Owner right on an Azure subscription, and are a Global Administer, you are unable to assign rights at the root '/' tenant level, to be able to create new Management Groups and move subscriptions between them.

However, users who have the Global Microsoft Entra ID role can elevate rights to do this. There are a few steps to enabling this, including using Azure PowerShell to assign rights.

With an account with Global Administrator rights, do the following:

1. Sign in to the Azure Portal

2. Open Microsoft Entra ID

3. Click Properties

4. Toggle the 'Access management for Azure resources' to 'Yes'

5. Click Save

6. Open PowerShell

7. Run:

   Connect-AzAccount
   

8. Login with your account, and make sure you are in the correct directory (if you aren't you can use Connect-Az Account - tenantid 'tenantidhere').

9. Type:

   Get-AzADUser
   

10. Copy the ID of the user you are logged in as, and run the following (replace the ObjectId to match the ID of your user):

    $user =  Get-AzADUser -ObjectId f53eaa59-0fc0-4103-b9cb-1650e3069da8
    

11. Once the user ID has been stored in a variable, its finally time to assign the rights, run the following:

    New-AzRoleAssignment -Scope '/' -RoleDefinitionName 'Owner' -ObjectId $user.Id
    

12. Give Microsoft Entra ID 10-15 minutes to replicate the Azure AD changes, log out and back in and you should now be able to deploy the Landing Zone.

Note: Remember to go back and change the toggle to 'Allow management of Azure resources' to 'No', or all Global Administrators of Microsoft Entra ID will be able to manage all Azure resources.

Once the Landing Zone is deployed, you should also remove your role assignment at the root level by running:

Remove-AzRoleAssignment -Scope '/' -RoleDefinitionName 'Owner' -ObjectId $user.Id

Turning off a Virtual Machine in Microsoft Azure on a schedule can quickly be done using the built-in Shutdown controls in the Virtual Machine blade (part of Azure Lab Services, but not a requirement), but what about starting it?

You have a few options, Logic Apps, PowerShell, Functions and Runbooks; most of the time, these will run on a standard 7 AM to 5 PM Monday to Friday schedule (meaning the Virtual Machine is off during off-peak hours and weekends, reducing compute cost).

This works fine for most scenarios, but what happens if a Bank or Public Holiday falls during the week? With the normal schedule, your Virtual Machine starts.

Because all your users are on Holiday, it wastes money while you and your users drink snicker cocktails at the beach?

This is where using a third party timezone API like 'AbstractApi' comes in handy; incorporating a lookup to check if it's a Public Holiday before starting that Virtual Machine can help reduce unnecessary costs.

Virtual Machines in Microsoft Azure have different states and, depending on what state the Virtual Machine is in, will determine whether you get billed or not (for the Compute, storage and network adapters are still billed).

I have written a base runbook that does precisely that, every time the runbook runs, it checks if it is a public Holiday. If it is - then the Virtual Machine isn't started; if it isn't, then the virtual machine is started.

Overview​

Today, we are going to set up an Azure Automation runbook, triggered by a scheduled will go through the following steps:

1. On a schedule (7 AM, it will trigger an Azure Automation runbook)
2. The Azure Automation runbook will do a lookup to an external API, in this case, AbstractApi.
3. The runbook will check the date and detect if it falls on a Public Holiday; if it is a Public Holiday, it will exit the Azure Automation runbook; if it is a standard workday, it will start the Virtual Machine.

To do this, we need a few resources.

• Azure Automation Account
• Azure Automation runbook (I will supply a PowerShell runbook below)
• AbstractAPI API Key

And, of course, 'Contributor' rights to the Microsoft Azure subscription to create the resources and the schedule, along with setting up the System Managed identity to grant the Azure Automation account access to start the Virtual Machine.

We will set up this from scratch using the Azure Portal and use an already created PowerShell Azure Automation runbook.

Deploy Start VM Solution​

Setup Azure Automation Account​

Create Azure Automation Account​

First, we need an Azure Automation resource.

1. Log into the Microsoft Azure Portal.
2. Click + Create a resource.
3. Type in automation
4. Select Create under Automation, and select Automation.
5. 
6. Select your subscription
7. Select your Resource Group or Create one if you don't already have one (I recommend placing your automation resources in an Azure Management or Automation resource group, this will also contain your Runbooks)
8. Select your region
9. 
10. Select Next
11. Make sure: System assigned is selected for Managed identities (this will be required for giving your automation account permissions to deallocate your Virtual Machine, but it can be enabled later if you already have an Azure Automation account).
12. Click Next
13. Leave Network connectivity as default (Public access)
14. Click Next
15. Enter in appropriate tags
16. 
17. Click Review + Create
18. After validation has passed, select Create

Configure System Identity​

Now that we have our Azure Automation account, its time to set up the System Managed Identity and grant it the following roles:

• Virtual Machine Contributor (to deallocate the Virtual Machine)

You can set up a custom role to be least privileged and use that instead. But in this article, we will stick to the built-in roles.

1. Log into the Microsoft Azure Portal.
2. Navigate to your Azure Automation account
3. Click on: Identity
4. Make sure that the System assigned toggle is: On and click Azure role assignments.
5. 
6. Click + Add role assignments
7. Select the Subscription (make sure this subscription matches the same subscription your Virtual Machines are in)
8. Select Role: Virtual Machine Contributor
9. Click Save
10. Click Refresh (it may take a few seconds to update the Portal, so if it is blank - give it 10 seconds and try again).
11. You have now set up the System Managed identity and granted it the roles necessary to execute the automation.

Setup Abstract API Key​

Now we need to create an API key, which will be used in the runbook to start the Virtual Machine, the API key will allow connections to the Abstract API to retrieve public Holliday information.

1. Create an Abstract API account
2. Log in to the newly created account
3. On the left-hand navigation bar, click on Holidays
4. 
5. Click on 'Try it out
6. Copy the API key
7. 
8. Copy the API key, as we will need it for the next steps.

Import Runbook​

Now that the modules have been imported into your Azure Automation account, it is time to import the Azure Automation runbook.

1. Log into the Microsoft Azure Portal.
2. Navigate to your Azure Automation account
3. Click on Runbooks
4. Click + Create a runbook
5. Specify a name (i.e. Start-AzureVirtualMachine)
6. Select Runbook type of PowerShell
   1. A select Runtime version of: 5.1 (7.1 works as well).
7. Type in a Description that explains the runbook (this isn't mandatory, but like Tags is recommended, this is an opportunity to indicate to others what it is for and who set it up)
8. 
9. Click Create
10. Now you will be greeted with a blank edit pane; paste in the Runbook from below:

#requires -Version 3.0 -Modules Az.Accounts, Az.Resources
<#
    .SYNOPSIS
    PowerShell Azure Automation Runbook for Starting/Stopping Virtual Machines. 
    .AUTHOR
    Luke Murray (https://github.com/lukemurraynz/)
    .VERSION
    1.0 - 28/04/22 - script versioned to '1.0'.
    .DESCRIPTION
    1. The script first checks if today is a holiday by making a call to the Abstract API.
    The Abstract API returns a JSON object containing the holiday name and (optional) description.
    The script checks if the name property is null. If it is not null, the script displays a message indicating that today is a holiday.
    If the name property is null, the script displays a message indicating that today is not a holiday.
    2. The script then checks if the virtual machine is running or not. If it is running, the script will stop the virtual machine.
    If it is not running, the script will start the virtual machine, depending on the Shutdown tag value
#>

Param(
  [Parameter(Mandatory = $true)]
  [String]
  $TagName,
  [Parameter(Mandatory = $true)]
     
  [String]
  $TagValue,
  [Parameter(Mandatory = $true)]
  [Boolean]
  $Shutdown
)

$CountryCode = 'NZ'

$tDate =(Get-Date).ToUniversalTime()
$tz = [System.TimeZoneInfo]::FindSystemTimeZoneById("New Zealand Standard Time")
$Date  = [System.TimeZoneInfo]::ConvertTimeFromUtc($tDate, $tz)


$API = Get-AutomationVariable -Name AbstractApiKey
$Holiday = Invoke-WebRequest -Uri ('https://holidays.abstractapi.com/v1/?api_key={0}&country={1}&year={2}&month={3}&day={4}' -f $API, $CountryCode, $Date.Year, $Date.Month, $Date.Day)

$Holidays = $Holiday.Content
$Holidays = $Holidays | ConvertFrom-Json

IF ($null -ne $Holidays.name) 
{
  Write-Output -InputObject ("Today is a holiday. The Holiday today is: {0}. The Azure Virtual Machine won't be started." -f $Holidays.name)
}
ELSE 
{
  Write-Output -Message 'No holiday today. The Virtual Machine will be started.'

  # Ensures you do not inherit an AzContext in your runbook
  Disable-AzContextAutosave -Scope Process
  # Connect to Azure with system-assigned managed identity (Azure Automation account, which has been given VM Start permissions)
  $AzureContext = (Connect-AzAccount -Identity).context
  Write-Output -InputObject $AzureContext
  # set and store context
  $AzureContext = Set-AzContext -SubscriptionName $AzureContext.Subscription -DefaultProfile $AzureContext
  Write-Output -InputObject $AzureContext

  $vms = Get-AzResource -TagName $TagName -TagValue $TagValue | Where-Object -FilterScript {
    $_.ResourceType -like 'Microsoft.Compute/virtualMachines' 
  }

  Foreach ($vm in $vms) 
  {
    if ($Shutdown -eq $true) 
    {
      Write-Output -InputObject "Stopping $($vm.Name)"        
      Stop-AzVM -Name $vm.Name -ResourceGroupName $vm.ResourceGroupName -Force
    }
    else 
    {
      Write-Output -InputObject "Starting $($vm.Name)"        
      Start-AzVM -Name $vm.Name -ResourceGroupName $vm.ResourceGroupName
    }
  }
}

12. Change the country code to align with your own country. You can use the IP geolocation API in Abstract API to do a live test, which will give you your country code. Feel free to amend the Write-Output messages to make sense for your environment.
13. Click Save
14. 
15. Click Publish (so the runbook is actually in production and can be used)
16. You can select View or Edit at any stage, but you have now imported the Azure Automation runbook!

Setup Variables​

Now that the Azure runbook has been imported, we need to set up the variables, which include the API key.

1. Log into the Microsoft Azure Portal.
2. Navigate to your Azure Automation account
3. Click Variables
4. Click + Add a variable
5. Create a Variable named: AbstractApiKey (this needs to match the variable name as part of the 'Get-AutomationVariable' cmdlet).
6. Enter in a description
7. Select String
8. Enter in the API key you retrieved earlier from Abstract API.
9. 
10. Click Save

Setup Schedule​

Now that the variables have been set up, we need to set up the schedule. This is the schedule that will be used to start the Virtual Machine. In the example below we are going to use a Standard Monday -> Friday work week, but adjust the time and date for when you need to start the virtual machine up.

1. Log into the Microsoft Azure Portal.
2. Navigate to your Azure Automation account
3. Click Schedule
4. Click + Add a schedule
5. Type in a name for the schedule (ie Azure Virtual Machine - Start).
6. Type in a Description
7. Select the Start Date to match when you want to start the Schedule (ie first Monday of the week).
8. Select your Timezone, so that the script runs on the right time/date which makes your timezone.
9. For Recurrance, specify: Recurring
10. Set it to Recur every: 1 Day
11. Check Monday, Tuesday, Wednesday, Thursday, and Friday
12. Leave Saturday and Sunday unchecked.
13. Click Create
14. Now that the Schedule has been created, we need to bind it to a Runbook
15. On the Automation account blade, click on Runbooks
16. Click on your 'Start Azure Virtual Machine' runbook
17. Select Schedules
18. Click Add a Schedule
19. Press: Link a schedule to your runbook
20. Select your newly created Schedule
21. For the Tag Name, select Shutdown
22. For the Tag Value name, Select Yes
23. For Shutdown, select false
24. Click Ok
25. Your schedule has now been configured and the runbook will run the next time it matches your scheduled date and time.

Configure Tags​

The runbook is written, so it doesn't need to be adjusted for future machines and making changes on the fly, this relies on each Virtual Machine that you want started to be started using the Runbook to be tagged.

1. Log into the Microsoft Azure Portal.
2. Navigate to your Azure Virtual Machine
3. Click Tags
4. Add the following tag:

Congratulations, the next time your schedule triggers, every runbook with the Shutdown tag will be started, according to your schedule, and workday. If it's a Public Holiday or a Weekend, the Virtual Machine will remain off - saving cost.