Powershell

Auto Shutdown ARM Virtual Machines in Azure | Azure Automation

With the release of the RunAs feature in Azure Automation.  A service account can now be called in Azure Automation scripts to enable and run Resource Manager functions.

I think one of the most useful features of this is to auto shutdown virtual machines by TAG.

In the example below I have set up the following:

  • A TAG called “Environment” with and ID of “Lab” and applied to each VM I want to control.
  • A RunAs service account as part of my AzureAutomation resource.
  • A PowerShell Workflow script to scan for the TAGs applied to Windows virtual machines and to shut them all down in parallel.
  • An Azure Automation schedule to run Monday-Friday at 17:00 to call the published workflow.

When configuring a schedule through the browser it uses the browser’s local time zone.  This is stored in UTC but is converted for you.   You’ll need to consider this is managing multiple resources across the globe.

This workflow and process has been created via the Azure Portal.

The -Parallel feature is only available in Powershell Workflows.

workflow TestPowershellworkflow
{
$Conn = Get-AutomationConnection -Name AzureRunAsConnection
Add-AzureRMAccount -ServicePrincipal -Tenant $Conn.TenantID -ApplicationId $Conn.ApplicationID -CertificateThumbprint $Conn.CertificateThumbprint

    $FindVMs = Find-AzureRmResource -TagName "Environment" -TagValue "Lab" | where {$_.ResourceType -like "Microsoft.Compute/virtualMachines"}

   Foreach -Parallel ($vm in $Findvms)

   {
    $vmName = $VM.Name
    $ResourceGroupName = $VM.ResourceGroupName

    Write-Output "Stopping $($vm.Name)";
    Stop-AzureRmVm -Name $vm.Name -ResourceGroupName $ResourceGroupName -Force;
    }
}

I’d be very interested in your feedback.  Happy automating.

Disclaimer:  Please note although I work for Microsoft the information provided here does not represent an official Microsoft position and is provided as is.

Moving Resources between Resource Groups | Azure

From a best practise point of view, I try to use Resource Groups as containers for all items I consider as part of the same lifecycle.  This allows me to remove, delete and recreate what I need without fear of losing a component and generally allows me to be more efficient.  I like peace of mind.

However, when it comes to best practise sometimes it feels slow and cumbersome.  “This is the Cloud I don’t want to be held back by anything” I shout from the roof tops in my superhero pyjamas!

The truth is best practise and / or procedure shouldn’t get in the way of anything at all but if I’m just spinning up a few resources to test a lab someone has sent me on a payment gateway or vNet to vNet VPN set up, this pyjama wearing superhero isn’t waiting around for anyone.   I therefore plough ahead.

Thankfully for rash people like me the Move-AzureRmResource command comes to the rescue.  https://msdn.microsoft.com/en-us/library/mt652516.aspx

For single resources I would first get the details of the resource you would like to move, this is important because you may have named two resources the same (remember what I was saying about being rash).

Get-AzureRmResource -name "resourcename" -ResourceGroupName "resourcegroupname"

Once you have the details you can then specify the ResourceType in the variable call.

Set up the variable as follows with the ResourceType, ResourceGroupName and ResourceName. Then move the resource.

$Resource = Get-AzureRmResource -ResourceType "Microsoft.Network/virtualNetworks" -ResourceGroupName "resourcegroupname" -ResourceName "resourcename"
Move-AzurermResource -ResourceId $Resource.ResourceId -DestinationResourceGroupName "newresourcegroupname"

Please note: It will move dependencies, for example if you want to move a VM it will move the components such as Public IP and Network Security Group.  As is, you will be prompted that you want to move the resource and the associated resources, if they exist.

Moving resources is simple and easy.  Best practise is important and no Cloud architect should be seen in public in their superhero pyjamas!

Azure Commander over and out……

Disclaimer:  Please note although I work for Microsoft the information provided here does not represent an official Microsoft position and is provided as is.