Did you know you can contribute to Microsoft documentation (ms docs)?

Suppose you see something not quite right, technically or even if the document's readability doesn't look right! Then, in true community style, you can contribute!

Tip: You can edit it straight from the Github webpage directly, or pressing "." in a Github repository will open up Visual Studio Code in Dev spaces with the markdown linter to help check against best practices from your browser.

See the image below for an example:

Once the pull request is made, it will be reviewed by designated technical document reviewers/product owners at Microsoft. Then your changes will be merged live if successful (and if not, the reviewers will let you know why and what changes could be made)!

• Microsoft Docs contributor guide overview

If you don't want to make the edit yourself, you can also raise an issue and give your feedback by linking to the document, and this will then be worked on by someone to review, contact the relevant product owners, and amended.

Try to be as concise as possible, as people reading it may not have the same experience as you!

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).

Suppose a Virtual Machine is not being used. In that case, turning off a Virtual Machine from the Microsoft Azure Portal (or programmatically via PowerShell/Azure CLI) is recommended to ensure that the Virtual Machine is deallocated and its affinity on the host has been released.

However, you need to know this, and those new to Microsoft Azure, or users who don't have Virtual Machine Administrator rights to deallocate a Virtual Machine, may simply shut down the operating system, leaving the Virtual Machine in a 'Stopped' state, but still tied to an underlying Azure host and incurring cost.

Our solution can help; by triggering an Alert when a Virtual Machine becomes unavailable due to a user-initiated shutdown, we can then start an Azure Automation runbook to deallocate the Virtual Machine.

Overview​

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

1. User shutdowns Virtual Machine from within the Operating System
2. The Virtual Machine enters an unavailable state
3. A Resource Alert is triggered when the Virtual Machine becomes unavailable (after being available) by a user initiated event
4. The Alert triggers a Webhook to an Azure Automation runbook
5. Using permissions assigned to the Azure Automation account through a System Managed Identity connects to Microsoft Azure and checks the VM state; if the Virtual Machine state is still 'Stopped', then deallocate the virtual machine.
6. Then finally, resolve the triggered alert.

To do this, we need a few resources.

• Azure Automation Account
• Az.AlertsManagement module in the Azure Automation account
• Az.Accounts module (updated in the Azure Automation account)
• Azure Automation runbook (I will supply this below)
• Resource Health Alert
• Webhook (to trigger to the runbook and pass the JSON from the alert)

And, of course, 'Contributor' rights to the Microsoft Azure subscription to provide the resources and the alerts and resources and set up the system managed identity.

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

Deploy Deallocate 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)
• Monitoring Contributor (to close the Azure Alert)

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. Now we repeat the same process for Monitoring Contributor
11. lick + Add role assignments
12. Select the Subscription (make sure this subscription matches the same subscription your Virtual Machines are in)
13. Select Role: Monitoring Contributor
14. Click Save
15. Click Refresh (it may take a few seconds to update the Portal, so if it is blank - give it 10 seconds and try again).
16. You have now set up the System Managed identity and granted it the roles necessary to execute the automation.

Import Modules​

We will use the Azure Runbook and use a few Azure PowerShell Modules; by default, Azure Automation has the base Azure PowerShell modules, but we will need to add Az.AlertsManagement, and update the Az.Accounts as required as a pre-requisite for Az.AlertsManagement.

1. Log into the Microsoft Azure Portal.
2. Navigate to your Azure Automation account
3. Click on Modules
4. Click on + Add a module
5. Click on Browse from Gallery
6. Click: Click here to browse from the gallery
7. Type in: Az.Accounts
8. Press Enter
9. Click on Az.Accounts
10. Click Select
11. 
12. Make sure that the Runtime version is: 5.1
13. Click Import
14. Now that the Az.Accounts have been updated, and it's time to import Az.AlertsManagement!
15. Click on Modules
16. Click on + Add a module
17. Click on Browse from Gallery
18. Click: Click here to browse from the gallery
19. Type in: Az.AlertsManagement (note its Alerts)
20. Click Az.AlertsManagement
21. 
22. Click Select
23. Make sure that the Runtime version is: 5.1
24. Click Import (if you get an error, make sure that Az.Accounts has been updated, through the Gallery import as above)
25. Now you have successfully added the dependent modules!

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. Deallocate-AzureVirtualMachine)
6. Select Runbook type of: PowerShell
7. Select Runtime version of: 5.1
8. 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)
9. 
10. Click Create
11. Now you will be greeted with a blank edit pane; paste in the Runbook from below:

#requires -Version 3.0 -Modules Az.Accounts, Az.AlertsManagement
<#
    .SYNOPSIS
    PowerShell Azure Automation Runbook for Stopping Virtual Machines, that have been Shutdown within the Windows Operating System (Stopped and not Deallocated). 
    .AUTHOR
    Luke Murray (https://github.com/lukemurraynz/)
#>

[OutputType('PSAzureOperationResponse')]
param ( 
    [Parameter(Mandatory = $true, HelpMessage = 'Data from the WebHook/Azure Alert')][Object]$WebhookData
)

Import-Module Az.AlertsManagement
$ErrorActionPreference = 'stop'

# Get the data object from WebhookData
$WebhookData = $WebhookData.RequestBody
Write-Output -InputObject $WebhookData 
$Schema = $WebhookData | ConvertFrom-Json

#Sets the Webhook data into object
$Essentials = [object] ($Schema.data).essentials
Write-Output -InputObject $Essentials 

# Get the first target only as this script doesn't handle multiple and and export variables for the resource.
$alertIdArray = (($Essentials.alertId)).Split('/')
$alertTargetIdArray = (($Essentials.alertTargetIds)[0]).Split('/')
$alertid =  ($alertIdArray)[6]
$SubId = ($alertTargetIdArray)[2]
$ResourceGroupName = ($alertTargetIdArray)[4]
$ResourceType = ($alertTargetIdArray)[6] + '/' + ($alertTargetIdArray)[7]
$ResourceName = ($alertTargetIdArray)[-1]
$status = $Essentials.monitorCondition
Write-Output -InputObject $alertTargetIdArray
Write-Output  -InputObject "status: $status" -Verbose

#Sets VM shutdown
if (($status -eq 'Activated') -or ($status -eq 'Fired')) {
    $status = $Essentials.monitorCondition
    Write-Output -InputObject "resourceType: $ResourceType" -Verbose
    Write-Output  -InputObject "resourceName: $ResourceName" -Verbose
    Write-Output  -InputObject "resourceGroupName: $ResourceGroupName" -Verbose
    Write-Output  -InputObject "subscriptionId: $SubId" -Verbose

    # Determine code path depending on the resourceType
    if ($ResourceType -eq 'Microsoft.Compute/virtualMachines') {
        # This is an Resource Manager VM
        Write-Output  -InputObject 'This is an Resource Manager VM.' -Verbose

        # Ensures you do not inherit an AzContext in your runbook
        Disable-AzContextAutosave -Scope Process

        # Connect to Azure with system-assigned managed identity
        $AzureContext = (Connect-AzAccount -Identity).context

        # set and store context
        $AzureContext = Set-AzContext -SubscriptionName $AzureContext.Subscription -DefaultProfile $AzureContext
        Write-Output   -InputObject $AzureContext 
        #Checks Azure VM status
        $VMStatus = Get-AzVM -ResourceGroupName $ResourceGroupName -Name $ResourceName -Status

        Write-Output  -InputObject $VMStatus
        If ($VMStatus.Statuses[1].Code -eq 'PowerState/stopped') {
            Write-Output  -InputObject "Stopping the VM, it was Shutdown without being Deallocated - $ResourceName - in resource group - $ResourceGroupName" -Verbose
            Stop-AzVM -Name $ResourceName -ResourceGroupName $ResourceGroupName -DefaultProfile $AzureContext -Force -Verbose
      
            #Check VM Status after deallocation
            $VMStatus = Get-AzVM -ResourceGroupName $ResourceGroupName -Name $ResourceName -Status -Verbose
            
            Write-Output  -InputObject $VMStatus

            If ($VMStatus.Statuses[1].Code -eq 'PowerState/deallocated') {
                #Closes Alert
                Write-Output  -InputObject $VMStatus.Statuses[1].Code
                Write-Output  -InputObject $alertid 
                Get-AzAlert -AlertId $alertid  -verbose -DefaultProfile $AzureContext
                Get-AzAlert -AlertId $alertid  -verbose -DefaultProfile $AzureContext | Update-AzAlertState -State 'Closed' -Verbose -DefaultProfile $AzureContext
            }
        }
             
        Elseif ($VMStatus.Statuses[1].Code -eq 'PowerState/deallocated') {
            Write-Output  -InputObject 'Already deallocated' -Verbose
        }

        Elseif ($VMStatus.Statuses[1].Code -eq 'PowerState/running') {
            Write-Output  -InputObject 'VM running. No further actions' -Verbose
        }

        # [OutputType(PSAzureOperationResponse")]
    }
}
else {
    # The alert status was not 'Activated' or 'Fired' so no action taken
    Write-Output  -InputObject ('No action taken. Alert status: ' + $status) -Verbose
}

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 Webhook​

Now that the Azure runbook has been imported, we need to set up a Webhook for the Alert to trigger and start the runbook.

1. Log into the Microsoft Azure Portal.
2. Navigate to your Azure Automation account
3. Click on Runbooks
4. Click on the runbook you just imported (i.e. Deallocate-AzureVirtualMachine)
5. Click on Add webhook
6. Click Create a new webhook
7. Enter a name for the webhook
8. Make sure it is Enabled
9. You can edit the expiry date to match your security requirements; make sure you record the expiry date, as it will need to be renewed before it expires.
10. Copy the URL and paste it somewhere safe (you won't see this again! and you need it for the next steps)
11. 
12. Click Ok
13. Click on Configure parameters and run settings.
14. Because we will be taking in dynamic data from an Azure Alert, enter in: [EmptyString]
15. Click Ok
16. Click Create
17. You have now set up the webhook (make sure you have saved the URL from the earlier step as you will need it in the following steps)!

Setup Alert & Action Group​

Now that the Automation framework has been created with the Azure Automation account, runbook and webhook, we now need a way to detect if a Virtual Machine has been Stopped; this is where a Resource Health alert will come in.

1. Log into the Microsoft Azure Portal.
2. Navigate to: Monitor
3. Click on Service Health
4. Select Resource Health
5. Select + Add resource health alert
6. Select your subscription
7. Select Virtual machine for Resource Type
8. You can target specific Resource Groups for your alert (and, as such, your automation) or select all.
9. Check Include all future resource groups
10. Check include all future resources
11. Under the Alert conditions, make sure Event Status is: All selected
12. Set Current resource status to Unavailable
13. Set Previous resource status to All selected
14. For reason type, select: User initiated and unknown
15. 
16. Now that we have the Alert rule configured, we need to set up an Action group. That will get triggered when the alert gets fired.
17. Click Select Action groups.
18. Click + Create action group
19. Select your subscription and resource group (this is where the Action alert will go, I recommend your Azure Management/Monitoring resource group that may have a Log Analytics workspace as an example).
20. Give your Action Group a name, i.e. AzureAutomateActionGroup
21. The display name will be automatically generated, but feel free to adjust it to suit your naming convention
22. Click Next: Notifications
23. Under Notifications, you can trigger an email alert, which can be handy in determining how often the runbook runs. This can be modified and removed if it is running, especially during testing.
24. Click Next: Actions
25. Under Action Type, select Webhook
26. Paste in the URI created earlier when setting up the Webhook
27. Select Yes to enable the common alert schema (this is required as the JSON that the runbook is parsing is expecting it to the in the schema, if it isn't the runbook will fail)
28. 
29. Click Ok
30. Give the webhook a name.
31. Click Review + create
32. Click Create
33. Finally, enter in an Alert name and description, specify the resource group for the Alert to go into and click Save.

Test Deallocate Solution​

So now we have stood up our:

• Azure automation account
• Alert
• Action Group
• Azure automation runbook
• Webhook

It is time to test! I have a VM called: VM-D01, running Windows (theoretically, this runbook will also run against Linux workloads, as its relying on the Azure agent to send the correct status to the Azure Logs, but in my testing, it was against Windows workloads) in the same subscription that the alert has been deployed against.

As you can see below, I shut down the Virtual Machine. After a few minutes (be patient, Azure needs to wait for the status of the VM to be triggered), an Azure Alert was fired into Azure Monitor, which triggered the webhook and runbook, and the Virtual Machine was deallocated, and the Azure Alert was closed.

Tags in Microsoft Azure are pivotal to resource management, whether it's used for reporting or automation.

But sometimes, you need that extra bit of information to help discover what resources are for, or you may way to add information to a resource that isn't directly displayed in the portal, especially when complex tags are in use that might be used in automation initiatives.

This is where 'hidden' Azure Tags come in handy.

Tags starting with the prefix of 'hidden-' will not be displayed under Tags in the Azure Portal; however, they will be displayed in the resource metadata and utilised by PowerShell and Azure CLI for automation initiatives.

Examples are:

hidden-title​

As I mentioned above, every tag with 'hidden-' in front of it will be hidden in the Azure Portal. However, 'hidden-title' behaves differently.

You may have noticed that some resources in Azure, especially if the Azure ARM (Azure Resource Manager) creates them and the name is GUID based, has a '(name)' around them after the resource name; this is because of the hidden-title tag.

The hidden-title tag is especially useful for being able to pick resources that belong to a specific service or application.

An example is below:

In this case, I have used the hidden-title of 'Web Server', allowing me to quickly view what resources may be mapped to my Web Server.

You may notice that the Test-Virtual Machines title, is displayed in the Resource Groups search blade and not in the actual Resource Group, there are some areas of the Portal that will not display the hidden-title tag currently.

If I navigate to my Virtual Machine and click on the Tags blade, all I see is my CreatedBy tag.

However, if I navigate to the Overview page and click on JSON View, I can see the hidden tags in the resource metadata.

hidden tags​

Azure Portal​

You can use the Azure Portal directly to add the Tags to apply hidden tags.

You can remove the Tag by adding the hidden-tag again and keeping the value empty (ie blanking out the hidden-title will remove the title), but it will still be against the metadata (Resource Graph) as a Tag that exists (as seen in the screenshot below) - it is much cleaner to use PowerShell.

PowerShell​

Get-AzTag and Remove-AzTag, do not display the hidden tags, to add and remove the tags, you need to add them through 'Update-AzTag' and 'Replace' or 'Merge' to overwrite the tags, which requires the Resource targetted by Resource ID.

A handy snippet to use to add/remove the Tags on individual or multiple resources is:

$replacedTags = @{"hidden-title" = "Web Server"; "hidden-ShutdownAutomation" = "Yes"}
$resouceGroup = 'vm-dev-rg'
Get-AzResource -ResourceGroupName $resouceGroup | Select-Object ResourceId | Out-GridView -PassThru | Update-AzTag -Tag $replacedTags -Operation Merge

This will snippet will gather all the resources in your Resource Group, then select their Resource IDs; the script will then prompt with a GUI allowing you to select which resources or resources you want to update your tags on, then once you click Ok, it will update the Tags on the resources you selected.

You may be wondering if the Hidden tags are useful for automation, but if the 'Get-AzTag' cmdlet doesn't work, how can I retrieve the resources? It's a good question, and that is where 'Get-AzResource' comes to the rescue.

Examples are:

Get-AzResource -TagName hidden-ShutdownAutomation

Get-AzResource -TagValue Yes

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

Azure Bicep​

You can also add the Tags, with Azure Bicep.

Example is:

param resourceTags object = {
   hidden-title: 'Web Server'
   hidden-ShutdownAutomation: 'Yes'
}

tags: resourceTags

Azure Arc Bridge(currently in preview) is part of the core Azure Arc Hybrid Cloud platform.

Overview​

The Azure Arc resource bridge allows for VM (Virtual Machine) self-servicing and managing on-premises Azure Stack HCI and VMWare virtualised workloads, supporting Linux and Windows.

Along with standard integration of Azure Arc workloads, such as support for Azure Policy and Azure extensions, Azure Update Management and Defender for Cloud support. The Azure Arc resource bridge offers the following self-service functionality direct from the Microsoft Azure portal, offering a single pane of a glass of your workloads, whether they exist on-premises or in Azure:

• Start, stop and restart a virtual machine
• Control access and add Azure tags
• Add, remove, and update network interfaces
• Add, remove, and update disks and update VM size (CPU cores and memory)
• Enable guest management
• Install extensions
• Azure Stack HCI - You can provision and manage on-premises Windows and Linux virtual machines (VMs) running on Azure Stack HCI clusters.

The resource bridge is a packaged virtual machine, which hosts a management Kubernetes cluster that requires no user management. This virtual appliance delivers the following benefits:

• Enables VM self-servicing from Azure without having to create and manage a Kubernetes cluster
• It is fully supported by Microsoft, including update of core components.
• Designed to recover from software failures.
• Supports deployment to any private cloud hosted on Hyper-V or VMware from the Azure portal or using the Azure Command-Line Interface (CLI).

All management operations are performed from Azure, no local configuration is required on the appliance.

Azure Arc resource bridge currently supports the following Azure regions:

• East US
• West Europe

These regions hold the Resource Bridge metadata for the resources.

Today, we will stand up an Azure Arc Bridge that supports VMWare vSphere.

I will be running vSphere 6.7 on a single host in my home lab, connected to my Visual Studio subscription.

Prerequisites​

Private cloud environments​

The following private cloud environments and their versions are officially supported for the Azure Arc resource bridge:

• VMware vSphere version 6.7
• Azure Stack HCI

Note: You are unable to set this up on vSphere 7.0.3, as it is not currently supported - I tried!

Permissions​

• Contributor rights to the Resource Group that the Azure Arc bridge resource will be created.
• vSphere account (with at least Read and modify VM rights)

Required Azure resources​

• Resource Group for your Azure Arc Resource Bridge

Required On-premises resources​

• Resource pool with a reservation of at least 16 GB of RAM and four vCPUs. It should also have access to a datastore with at least 100 GB of free disk space.
• A workstation with rights to run PowerShell and install Python and the Azure CLI, with a line of sight to vCenter.

Networking​

• The Arc resource bridge communicates outbound securely to Azure Arc over TCP port 443
• At least one free IP (Internet Protocol) address on the on-premises network (or three if there isn't a DHCP server). Make sure this isn't a used IP; you will need to enter this during the bridge provisioning script.

Create Azure Arc Resource Bridge​

Create Resource Bridge​

1. Log in to the Azure Portal
2. In the search box up the top, type in: Azure Arc
3. Click Azure Arc
4. Click on: VMware vCenters (preview)
5. Click Add
6. 
7. Click: Create a new resource bridge
8. 
9. Click Next: Basics
10. Enter the following information to suit your environment:

• Name (of the Resource Bridge resource)
• Select the region for your Metadata
• Create a Custom Location(that matches your on-premises location, where your resources are stored, i.e. could be a data centre prefix that matches your naming convention)
• Enter in the name of your vCenter resource (this will represent your vCenter in Azure, so make sure it is easily identifiable)

1. 

2. Click Next: Tags

3. A list of default tags has been supplied; feel free to enter or change these to suit your environment.

4. 

5. Click Next: Download and run the script.

6. Click on Register to register the Azure Arc Provider to your subscription. Please wait for this process to complete (it may take a minute or two, you will see: Successfully register your subscription(s) when completed).

7. Once completed, download the onboarding PowerShell script

8. Run the PowerShell script from a computer that has access to Azure and vCenter. This script will download the necessary dependencies (Azure CLI, Python) and, if necessary, authenticate to Azure.

   Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
   ./resource-bridge-onboarding-script.ps1
   

9. When the script runs, you will be prompted for the following information.

   • Proxy information (if the Workstation is behind a proxy)
   • UAC (User Access Control) approval for the script to install Azure CLI/Python on the workstation
   • Azure authentication
   • vCenter FQDN/Address
   • vCenter Username & Password
   • vCenter datastore
   • vCenter folder (to place the template in)
   • IP address

10. 

Link vCenter to Azure Arc​

You may not need to do the below, but my Bridge was in a 'running' state but hadn't added in the connection to vCenter.

1. Log in to the Azure Portal
2. In the search box up the top, type in: Azure Arc
3. Click Azure Arc
4. Click on: Resource bridges (preview)
5. Click on your Azure Arc Bridge and verify the status is 'Running' (if it is not, make sure it has been started on-premises)
6. In the Azure Portal, click on VMWare vCenters (preview)
7. Click Add
8. Click Use an existing resource bridge
9. Click Next: Basics
10. Create your Custom Location, then enter in the on-premises vCenter details
11. 
12. On the next blade, enter in your appropriate Tags, then click Create
13. Wait for the deployment to complete; this could take 2-5 minutes.
14. In the search box up the top, type in: Azure Arc
15. Click Azure Arc
16. Click on: VMware vCenters (preview)
17. You should now see your vSphere instance in a Connected state.
18. 

Enable vCenter resources to be managed in Microsoft Azure​

Now that the Bridge has been created, we need to allow resources (such as Virtual Machines, Datastores, Networks).

1. Log in to the Azure Portal
2. In the search box up the top, type in: Azure Arc
3. Click Azure Arc
4. Click on: VMware vCenters (preview)
5. Click on your vCenter instance
6. Under vCenter Inventory, select Virtual Machines
7. 
8. Select the Virtual Machines you want to enable for management in Azure and click 'Enable in Azure'
9. Select your applicable Subscription and Resource Group (this is where the Azure Arc VM resources will be placed)
10. Make sure 'Enable Guest management' is selected.
11. Enter in your Administrator (this is the Admin Username and password of the workloads you want to install the Azure guest management too)
12. 
13. Click Enable
14. It can take a few minutes to onboard these clients. If it fails, pick a single Virtual Machine and attempt to onboard that.
15. You can now repeat the process to onboard Networks, Resource Pools etc.

Manage Virtual Machines in Microsoft Azure​

Now that you have set up an Azure Arc Bridge and onboarded vCenter resources. You can now see and manage your vCenter Virtual Machines in Azure, examples below.

• Ensure that you have VMWare Tools installed and up-to-date to help full functionality, such as Restart, or there may be issues managing these.

Stop/Stop Virtual Machines​

Resize Virtual Machines - CPU/Memory​

Resize Virtual Machines - Disk​

Troubleshooting​

• The 'resource-bridge-onboarding-script.ps1' script contains an output file, named: arcvmware-output.log. This log file exists in the same directory as the script and is useful for investigating any errors.
• If you get no Folders, listed when the script prompts you to select a folder (i.e. Please select folder):

1. Right-click the Datacenter in vSphere
2. Select New Folder
3. Select New VM and Templates folder
4. Create a folder

• If your Center becomes unavailable, it is most likely because you specified the same IP for the Azure Arc Appliance; if this is the case, log in to the host containing your Azure Arc Bridge and stop/delete the resources from the disk and remove from inventory. Then rerun deployment, this time selecting an appropriate IP.

The Ubiquiti Dream Machine Pro has a lot of functionality built-in, including IPsec Site-to-site VPN_(Virtual Private Network)_ support.

I recently installed and configured a UDM-PRO at home, so now it's time to set up a site-to-vpn to my Microsoft Azure network.

I will create Virtual Network and Gateway resources using Azure Bicep, but please skip ahead.

My address range is as follows (so make sure you adjust to match your setup and IP ranges):

Prerequisites​

• The latest Azure PowerShell modules and Azure Bicep/Azure CLI for local editing
• An Azure subscription that you have at least contributor rights to
• Permissions to the UDM Pro to set up a new network connection

I will be using PowerShell splatting as it's easier to edit and display. You can easily take the scripts here to make them your own.

Deploy - Azure Network and Virtual Network Gateway​

I will assume that you have both Azure Bicep andPowerShell Azure modules installed and the know-how to connect to Microsoft Azure.

Azure Bicep deployments (like ARM) have the following command: 'TemplateParameterObject'. 'TemplateParameterObject' allows Azure Bicep to accept parameters from PowerShell directly, which can be pretty powerful when used with a self-service portal or pipeline.

I will first make an Azure Resource Group using PowerShell for my Azure Virtual Network, then use the New-AzResourceGroupDeployment cmdlet to deploy my Virtual Network and subnets from my bicep file.

Along with the Virtual Network, we will also create 2 other Azure resources needed for a Site to Site VPN, a Local Network Gateway _(this will represent your on-premises subnet and external IP to assist with routing)_and a Virtual Network Gateway (which is used to send encrypted traffic over the internet between your on-premises site(s) and Azure).

Update the parameters of the PowerShell script below, to match your own needs, and you may need to edit the Bicep file itself to add/remove subnets and change the IP address space to match your standards.

The shared key will be used between the UDM Pro and your Azure network; make sure this is unique.

#Connects to Azure
Connect-AzAccount
#Resource Group Name
$resourcegrpname = 'network_rg'
#Creates a resource group for the storage account
New-AzResourceGroup -Name $resourcegrpname -Location 'AustraliaEast'
# Parameters splat, for Azure Bicep
# Parameter options for the Azure Bicep Template, this is where your Azure Bicep parameters go
$paramObject = @{
'sitecode' = 'luke'
'environment' = 'prod'
'contactEmail' = '[email protected]'
'sharedkey' = '18d5b51a17c68a42d493651bed88b73234bbaad0'
'onpremisesgwip' = '123.456.789.101'
'onpremisesaddress' = '192.168.1.0/24'
}
# Parameters for the New-AzResourceGroupDeployment cmdlet goes into.
$parameters = @{
'Name' = 'AzureNetwork-S2S'
'ResourceGroupName' = $resourcegrpname
'TemplateFile' = 'c:\temp\Deploy-AzVNETS2S.bicep'
'TemplateParameterObject' = $paramObject
'Verbose' = $true
}
#Deploys the Azure Bicep template
New-AzResourceGroupDeployment @parameters -WhatIf

Note: The '-whatif' parameter has been added as a safeguard, so once you know the changes are suitable, then remove and rerun.

The Virtual Network Gateway can take 20+ minutes to deploy, leave the Terminal/PowerShell window open, you can also check the Deployment in the Azure Portal (Under Deployments panel in the Resource Group).

The Azure Bicep file is located here:

targetScope = 'resourceGroup'

///Parameter and Variable Setting

@minLength(3)
@maxLength(6)
param sitecode string = ''

param environment string = ''
param contactEmail string = ''

param resourceTags object = {
  Application: 'Azure Infrastructure Management'
  CostCenter: 'Operational'
  CreationDate: dateTime
  Environment: environment
  CreatedBy: contactEmail
  Notes: 'Created on behalf of: ${sitecode} for their Site to Site VPN.'
}

param dateTime string = utcNow('d')
param location string = resourceGroup().location

param sharedkey string = ''
param onpremisesaddress string = ''
param onpremisesgwip string = ''

//Resource Naming Parameters
param virtualNetworks_vnet_name string = '${sitecode}-vnet'
param connections_S2S_Connection_Home_name string = 'S2S_Connection_Home'
param publicIPAddresses_virtualngw_prod_name string = '${sitecode}-pip-vngw-${environment}'
param localNetworkGateways_localngw_prod_name string = '${sitecode}-localngw-${environment}'
param virtualNetworkGateways_virtualngw_prod_name string = '${sitecode}-virtualngw-${environment}'

resource localNetworkGateways_localngw_prod_name_resource 'Microsoft.Network/localNetworkGateways@2020-11-01' = {
  name: localNetworkGateways_localngw_prod_name

  location: location
  properties: {
    localNetworkAddressSpace: {
      addressPrefixes: [
        onpremisesaddress
      ]
    }
    gatewayIpAddress: onpremisesgwip
  }
}

resource publicIPAddresses_virtualngw_prod_name_resource 'Microsoft.Network/publicIPAddresses@2020-11-01' = {
  name: publicIPAddresses_virtualngw_prod_name
  tags: resourceTags
  location: location
  sku: {
    name: 'Standard'
    tier: 'Regional'
  }
  properties: {
    publicIPAddressVersion: 'IPv4'
    publicIPAllocationMethod: 'Static'
    idleTimeoutInMinutes: 4
    ipTags: []
  }
}

resource virtualNetworks_vnet_name_resource 'Microsoft.Network/virtualNetworks@2020-11-01' = {
  name: virtualNetworks_vnet_name
  location: location
  tags: resourceTags
  properties: {
    addressSpace: {
      addressPrefixes: [
        '10.0.0.0/16'
      ]
    }
    subnets: [
      {
        name: 'GatewaySubnet'
        properties: {
          addressPrefix: '10.0.0.0/26'
          delegations: []
          privateEndpointNetworkPolicies: 'Enabled'
          privateLinkServiceNetworkPolicies: 'Enabled'
        }
      }
      {
        name: 'AzureBastionSubnet'
        properties: {
          addressPrefix: '10.0.0.64/27'
          delegations: []
          privateEndpointNetworkPolicies: 'Enabled'
          privateLinkServiceNetworkPolicies: 'Enabled'
        }
      }
      {
        name: 'AzureFirewallSubnet'
        properties: {
          addressPrefix: '10.0.0.128/26'
          delegations: []
          privateEndpointNetworkPolicies: 'Enabled'
          privateLinkServiceNetworkPolicies: 'Enabled'
        }
      }
      {
        name: 'appservers'
        properties: {
          addressPrefix: '10.0.2.0/24'
          delegations: []
          privateEndpointNetworkPolicies: 'Enabled'
          privateLinkServiceNetworkPolicies: 'Enabled'
        }
      }
    ]
    virtualNetworkPeerings: []
    enableDdosProtection: false
  }
}

resource virtualNetworks_vnet_name_appservers 'Microsoft.Network/virtualNetworks/subnets@2020-11-01' = {
  parent: virtualNetworks_vnet_name_resource
  name: 'appservers'
  properties: {
    addressPrefix: '10.0.2.0/24'
    delegations: []
    privateEndpointNetworkPolicies: 'Enabled'
    privateLinkServiceNetworkPolicies: 'Enabled'
  }
}

resource virtualNetworks_vnet_name_AzureBastionSubnet 'Microsoft.Network/virtualNetworks/subnets@2020-11-01' = {
  parent: virtualNetworks_vnet_name_resource
  name: 'AzureBastionSubnet'
  properties: {
    addressPrefix: '10.0.0.64/27'
    delegations: []
    privateEndpointNetworkPolicies: 'Enabled'
    privateLinkServiceNetworkPolicies: 'Enabled'
  }
}

resource virtualNetworks_vnet_name_AzureFirewallSubnet 'Microsoft.Network/virtualNetworks/subnets@2020-11-01' = {
  parent: virtualNetworks_vnet_name_resource
  name: 'AzureFirewallSubnet'
  properties: {
    addressPrefix: '10.0.0.128/26'
    delegations: []
    privateEndpointNetworkPolicies: 'Enabled'
    privateLinkServiceNetworkPolicies: 'Enabled'
  }
}

resource virtualNetworks_vnet_name_GatewaySubnet 'Microsoft.Network/virtualNetworks/subnets@2020-11-01' = {
  parent: virtualNetworks_vnet_name_resource
  name: 'GatewaySubnet'
  properties: {
    addressPrefix: '10.0.0.0/26'
    delegations: []
    privateEndpointNetworkPolicies: 'Enabled'
    privateLinkServiceNetworkPolicies: 'Enabled'
  }
}

resource connections_S2S_Connection_Home_name_resource 'Microsoft.Network/connections@2020-11-01' = {
  name: connections_S2S_Connection_Home_name
  location: location
  properties: {
    virtualNetworkGateway1: {
      id: virtualNetworkGateways_virtualngw_prod_name_resource.id
    }
    localNetworkGateway2: {
      id: localNetworkGateways_localngw_prod_name_resource.id
    }
    connectionType: 'IPsec'
    connectionProtocol: 'IKEv2'
    routingWeight: 0
    sharedKey: sharedkey
    enableBgp: false
    useLocalAzureIpAddress: false
    usePolicyBasedTrafficSelectors: false
    ipsecPolicies: []
    trafficSelectorPolicies: []
    expressRouteGatewayBypass: false
    dpdTimeoutSeconds: 0
    connectionMode: 'Default'
  }
}

resource virtualNetworkGateways_virtualngw_prod_name_resource 'Microsoft.Network/virtualNetworkGateways@2020-11-01' = {
  name: virtualNetworkGateways_virtualngw_prod_name
  location: location
  properties: {
    enablePrivateIpAddress: false
    ipConfigurations: [
      {
        name: 'default'
        properties: {
          privateIPAllocationMethod: 'Dynamic'
          publicIPAddress: {
            id: publicIPAddresses_virtualngw_prod_name_resource.id
          }
          subnet: {
            id: virtualNetworks_vnet_name_GatewaySubnet.id
          }
        }
      }
    ]
    sku: {
      name: 'VpnGw2'
      tier: 'VpnGw2'
    }
    gatewayType: 'Vpn'
    vpnType: 'RouteBased'
    enableBgp: false
    activeActive: false
    bgpSettings: {
      asn: 65515
      bgpPeeringAddress: '10.0.0.62'
      peerWeight: 0

      
    }
    vpnGatewayGeneration: 'Generation2'
  }
}

Once deployed, run the following command to capture and copy the Gateway Public IP:

Get-AzPublicIPAddress | Select-Object Name, IpAddress 

Copy the Public IP, we will need this for configuring the UDM Pro, this would have been generated dynamically.

Configure - Ubiquiti Dream Machine Pro​

1. Login to the UDM-Pro

2. 

3. Click on Network (under Applications heading)

4. Click Settings (Gear icon)

5. 

6. Click VPN

7. 

8. Scroll down and click + Create Site-to site-VPN

9. Fill in the following information:

   • Network Name(ie Azure - SYD)
   • VPN Protocol (select Manual IPsec)
   • Pre-shared Key (enter in the SAME key that was used by Azure Bicep to create the Connection - if you have lost it, it can be updated in Azure, under Shared key on the connection attached to the Virtual network gateway, but will stop any other VPN connections using the old key)
   • Server Address (make sure you select the interface for your WAN/External IP)
   • Remote Gateway/Subnets (Enter in the Address Prefix of your Azure virtual network or subnets, remember to add any peered virtual networks and Press Enter)
   • Remote IP Address (Enter in the Public IP of the Virtual Network gateway, the same IP retrieved by Get-AzPublicIPAddress cmdlet )

10. 

11. Select Manual

12. 

    Select IPSec Profile, and select Azure Dynamic Routing

13. Click Apply Changes

After a few minutes, the VPN should become connected and you should be able to connect to devices on the Azure Network using their private IP address.

If you have problems, make sure that the Gateway IPs line up and are correct, along with the pre-shared key. You can also Pause the Network from the UDM-Pro and Resume to reinitiate the connection.

You can also troubleshoot the VPN connection, from the Azure Portal, by navigating the Virtual network gateway and selecting VPN Troubleshoot.