Clean up Azure Resource Groups with a Tag

In my environment I use an Azure Automation Runbook that every evening is cleaning up my environment based on a Tag. When the tag “RemoveResourceGroup” is set to “Yes” on a Resource Group I will delete it and everything in that group.

If you want to try my Runbook you can download the script and run it on your local client or in Azure Automation. I have tested the script with PowerShell module AzureRM.Resources version 6.7.3. If you need to upgrade the module in Azure Automation, to a newer version, just do a new import of the module from the gallery.

The script can be downloaded from GitHub.

        Removes Resource Groups that have a tag "RemoveResourceGroup" set to "Yes"
        Script can be used in both Azure Automation and direct from PowerShell prompt
        The script have been tested in Azure Automation with module AzureRM.Resources version 6.7.3

        Author: Jonathan Andersson
        Last Updated: 12/09/2019

    .PARAMETER TagResourceGroupName
        Tag name

    .PARAMETER TagValue
        Tag value

    .PARAMETER AzureAutomation
        If script sould be run in Azure Automation

    .PARAMETER ConnectionName
        A<ure Automation RunAs Connection to Azure

        RemoveResourceGroupAutomation -TagResourceGroupName "RGName" -TagValue "Yes" -AzureAutomation $false

param (
    $TagResourceGroupName = "RemoveResourceGroup",
    $TagValue = "Yes",      

    $AzureAutomation = $true,

    $ConnectionName = "AzureRunAsConnection"

# Create a Tag object
[object] $Tag = @{}

try {
    if ($AzureAutomation) {
        # Get the connection "AzureRunAsConnection "
        $servicePrincipalConnection = Get-AutomationConnection -Name $ConnectionName         

        # Logging in to Azure
        Add-AzureRmAccount `
            -ServicePrincipal `
            -TenantId $servicePrincipalConnection.TenantId `
            -ApplicationId $servicePrincipalConnection.ApplicationId `
            -CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint | Out-Null
    $Tag.Add($TagResourceGroupName, $TagValue)
    Write-Output "Using TagResourceGroupName: $TagResourceGroupName and TagValue: $TagValue"

    $ResourceGroups = Get-AzureRmResourceGroup -Tag $Tag

    foreach ($ResourceGroup in $ResourceGroups) {
        Remove-AzureRmResourceGroup -Name $ResourceGroup.ResourceGroupName -Force | Out-Null
        Write-Output "Removed Resource Group: " $ResourceGroup.ResourceGroupName
catch {
	if (!$servicePrincipalConnection)
		$ErrorMessage = "Connection $ConnectionName not found."
		throw $ErrorMessage
		Write-Error -Message $_.Exception
		throw $_.Exception

Send Email when Azure Site Recovery is done or manual step is needed

This post is about sending an email when a Azure Site Recovery (ASR) failover is done or before a manual step in the ASR failover plan. In the example I have used an Azure Automation runbook in the ASR plan to send an email through the service SendGrid. SendGrid can off course be changed to another solution but in my case, I find it easy to use.

If you want to try it, start by creating a SendGrid account in Azure.

Make a note of the username and your password, you will need it later.

Create or import an Azure Automation Runbook that will send the email. This is the Runbook I used: SendEmail Runbook. Read the information in the description of the Runbook to get it working.

In the example Runbook above, an Azure Automation credential is needed. This is how it should look like. Add the username and password from the SendGrid account.

Edit the variables in the Runbook script and publish it.

Go to the Recovery Services vault and add the Runbook to the ASR plan.

Clone VMs after ASR Test Failover

If you want to clone a production environment on-prem to Azure and then, for example, test an upgrade or do new development on those servers, here is one way to do it.

My solution is using Azure Site Recovery (ASR) and a PowerShell script. It does not have any impact on the on-prem environment because I am using Test Failover in ASR which is starting the servers on a separate VNet in Azure which is not having any connectivity back on-prem. The Test Failover feature in ASR will make a clone of the on-prem servers in Azure and will not shut them down.

In ASR, as of today, you can only do one Test Failover at the time. This means that if you have done one Test Failover you cannot do another one while the first one is running. Because of this I am using a script in ASR to clone the Test Failover VMs so you can do more than one environment for testing.

Here is how I did it!

1.       First step is to install and configure ASR to replicate the servers that is going to be cloned When that is done, control that the servers are using Managed Disks. It they are not, change so they do.

2.       Next step is to create an Azure Automation Account and a Runbook for cloning the servers. Here is the script I use: My GitHub. If you are using my script, change the variables to fit your needs.

If you have issues with the script, update the Azure Automation Account modules and import the modules that are needed. Here is a screenshot of the modules I have tested the script with.

3.       When the servers have been replicated with ASR, create an ASR Recovery Plan and add the servers to a Group. Add the earlier created Runbook from Azure Automation as a Recovery Plan post step on the Group with the servers.

When this is done, do a Test Failover to test you Recovery Plan and clone of the servers.

Monitor Azure DSC in Azure Automation with Azure Log Analytics

Recently it became possible to monitor Azure DSC in Azure Automation with Log Analytics. Here is how to do this setup in the Azure Portal.

First go to the Log Analytics workspace and click on Azure Resources. Select the Automation Account where DSC exists.

Monitor Azure DSC in Azure Automation with Azure Log Analytics 1

Select DscNodeStatus and click Save. In my example, I also want information about jobs in Azure Automation.

Monitor Azure DSC in Azure Automation with Azure Log Analytics 2

Verify that you have nodes added for Azure DSC and then go to Search in Log Analytics.

Monitor Azure DSC in Azure Automation with Azure Log Analytics 3

Do a search for Category=DscNodeStatus and you will see information from Azure DSC.

Monitor Azure DSC in Azure Automation with Azure Log Analytics 4

For more information and to do this in PowerShell, see the following documentation page:

Keep service running with DSC on Windows Server

If you are in the need for keeping a service running or if you have a service that doesn’t start when you reboot your server, DSC in Azure Automation could be the thing for you!

In this post I will show how easy it is to create a DSC configuration that you can import, compile and then use on your servers. This off course works well both in on-premises datacenters as well as in Azure or any other public cloud provider.

Edit the following code and change the service you want to have started and save it to a PowerShell ps1-file (Example: MyDSC.ps1).

Configuration SpoolerService
    Import-DscResource –ModuleName ’PSDesiredStateConfiguration’
    Node localhost
        Service Spooler
            Name = "Spooler"
            State = "Running"

Create an Azure Automation Account and click on it.

Click DSC Configuration and then Add a configuration up to the left of the portal. Import the file created.

Keep service running with DSC on Windows Server 1

Click on the DSC Configuration in the portal and then Compile. When the compile is Completed you can start to use the configuration.

Keep service running with DSC on Windows Server 3

Click DSC Nodes and add the server you want to use DSC on.

Keep service running with DSC on Windows Server 2

Select if you want to deploy the configuration on an Azure VM och on-prem VM.

Keep service running with DSC on Windows Server 4