Update AA module management


Just a quick post, I updated the Import-PSGalleryModulesToAA.ps1 runbook to also handle running on a new Azure Automation account.

The runbook will now bring AzureRM.Profile, AzureRM.Automation, AzureRM.Resources up to the latest version before importing other modules. You will need to also set the parameters AutomationAccountName and AutomationResourceGroupName as the logic that automatically discovers the AA account does not work on the early versions of AzureRM.

If the runbook is started without setting the parameters it will terminate with an warning telling you to set the parameters.

After the AzureRM modules are on the latest version you can run the import runbook anew to install the wanted modules.

Happy tinkering

Refactoring AA Solution Onboarding to give Linux some love


So some of us are using the free update management and change management solution offered through Azure Automation.

There have been some code in the AA team github repo for some time, though as with all code it degrades over time as dependencies change.

This logic seemed to support onboarding both Windows and Linux, and I did not question this the first time I refactored the code. Though as it turns out Windows and Linux does not follow the same pattern when it comes to what identificator it uses to onboard VMs. The key difference is that for Windows the Id used can be extracted from the ARM api. Namely the VMid property on a VM object. The original assumption was that this was the same for Linux. Though after some investigation it seems that what Linux VMs has for VMid is not the same. The value is instead the internal UUID found inside the OS. This means that to get this, one will need to extract it by interacting with the OS. This is more difficult than for Windows, as this is already taken care of by Azure during VM creation.

Also as we are doing the one stepp to the right routine I added versions both for AzureRM and Az module.

AzureRM Single VM Onboarding:
AzureRM Multi VM Onboarding:

Az Single VM Onboarding:
Az Multi VM Onboarding:

In addition there seems to be no maintenance of onboarded VM’s to the different solutions. Therefor I wrote a runbook that will compare the onboarded VM’s to the VM’s deployed in Azure. If VM’s have been removed from Azure, the Runbook will also remove them from the solutions.

AzureRM Solution query cleanup:

Az Solution query cleanup:

If you need to import the Az modules into AA take a look at:

Azure Automation: Refactor module update logic


As I had a good go creating logic to handle modules on hybriod workers, I decided to also update some existing code the Automation team has had on their github for awhile. This code has become stale and does not work that good anymore.

The team is also deprecating their github soon as it does not comply to their internal standards for Open Source projects. They have a separate project that handles module updates here , though in my opinion some of the logic decisions taken creating it limited its flexibility potential.

This is why I chose to fix Update-ModulesInAutomationToLatestVersion instead. This logic supported updating all modules in account as long as the module in question exists in PSGallery. You could also use it to import a module from gallery with it’s dependencies. Working on it it I decided to split these two functionalities into two separate runbooks. So instead of the one, there now are two: Import-PSGalleryModulesToAA.ps1 and Update-PSGalleryModulesInAA.ps1.

The update module now support to either just update the Azure modules (Az and AzureRM) or try to update all modules to latest version. At the moment there is no support for setting a desired import version, though if this becomes an issue it can always be added to the logic.

The import logic can be used to get the Az module and all of it’s dependencies into the Automation account initially. Though note this is a big module and will take more than 30 minutes to complete. Also note that as AA does not support having multiple version of the same module imported, the logic will chose to keep the highest version that dependencies have on a given module. There is also a recursion limit of how far down the dependencies tree the logic will go. This is hardcoded to 3. To import multiple modules at the same time follow the syntax as shown below.

Sadly I’m not able to contribute this back to the Automations team github, though if they open a new one up there might be a option to surface it there.

Hope more will find this useful to keep their modules under management.

Happy tinkering!

Azure Automation: Update Management Runbook


This will be a quick one.

As I was looking for a solution to add Azure VM to update management through Terraform I came up short. Therefore we opted to have Terraform do a web call to trigger a Runbook in Azure Automation. I went spelunking and found that the AA team had already done most of the job, but it was a bit out of date. I therefore tok up the mantle and brought the code logic up to date and added support for sending parameters through a webhook.

The updated runbook to add VMs to both Update Management and Change Tracking:



A maintenance Runbook to remove retired VMs from Update Management and Change Tracking:


Happy Tinkering!