Creating Azure Monitor Alerts using Azure Log Analytics Query Language Based On Azure Automation Runbook Job Output

Well, this post has such a long title – but I’ve tried my best. It is based on an idea I had – We all have many “Health Check” PowerShell scripts in our collections, why not use them in OMS without too much modification and generate meaningful alerts based on the outputs of these scripts? I have been meaning to write this post for at least 4 months, I finally found some spare time this weekend so I can work on this. In the past, when I was still working on System Center Operations Manager, I always get requests from

Log-In to AzureRM PowerShell module using oAuth Tokens

In my last post, I demonstrated how to generate Azure AD oAuth tokens using my AzureServicePrincipalAccount PowerShell module. Although personally, I pretty much use Azure Resource Manager REST API for everything – this is where the oAuth token come in play, but often, I have seen colleagues and customers use a mixture of both ARM REST APIs calls and AzureRM modules within same PowerShell scripts. This could potentially be troublesome because in order to use AzureRM modules, you will need to sign-in to Azure using Add-AzureRMAccount (or it’s alias Login-AzureRMAccount). Luckily, Add-AzureRMAccount also supports signing in using an existing AAD

Generating Azure AD oAuth Token in PowerShell

Recently in a project that I’m currently working on, myself and other colleagues have been spending a lot of time dealing with Azure AD oAuth tokens when developing code for Azure. There are so many scenarios and variations when trying to generate the token, and you have probably seen a lot of samples on the Internet already. I have spent a lot of time trying to develop a common method that the project team can use in all the scenarios. To summarise, you can generate oAuth tokens for the following security principals (and different configurations): Azure AD Application Service Principals

Bulk Register Azure Resource Providers Using PowerShell

Azure Resource Providers registration dictates what types of resources you allow users to provision within your Azure subscription. Although by default, some resource providers are automatically registered, the user must have required permission to register resource providers ( I had to create a script to bulk-register resource providers for a subscription because normal users have not been given the permissions to do so. In the following sample script, I am using regular expressions to match the resource provider names, and it is registering all Microsoft resource providers except for the classic (ASM) resource types. View the code on Gist. This

Getting Azure AD Tenant Common Configuration Such as Tenant ID Using PowerShell

It has been a long time since my last post. I was very busy right until the Christmas eve, and it my to-be-blogged list is getting longer and longer. I had a very good break during the holiday period. My partner and I took our daughter to Sydney on the Christmas day and spent 5 days up there. When we were in Sydney, I visited Hard Rock Cafe for the first time in my life, and also spent 2 days with my buddy and MVP colleague Alex Verkinderen. Now that I’m somewhat recharged, I will start working on the backlog

Searching OMS Using the New Search Language (Kusto) REST API in PowerShell

Currently Microsoft is in the process of upgrading all OMS Log Analytics workspaces to the new query language (named Kusto). Once your workspace has been upgraded, you will no longer able to invoke search queries using the Get-AzureRmOperationalInsightsSearchResults cmdlet from the AzureRM.OperationalInsights PowerShell module. Kusto comes with a new set of REST APIs, you can find the documentation site here: According to the documentation, this REST API has the following limitations: Queries cannot return more than 500,000 rows Queries cannot return more than 64,000,000 bytes (~61 MiB total data) Quries cannot run longer than 10 minutes by default. From

New PowerShell Module For Azure Automation: AzureServicePrincipalAccount

I’m currently working on a project where there has been a lot of discussion on how to use Azure AD Service Principals in Azure Automation and other solutions that involves any automated processes (i.e. VSTS pipelines). When signing in to Azure using a Service Principal, you can use either a key (password) or a certificate associated to the Service Principal. When using the Add-AzureRMAccount cmdlet, you can use one of the following parameter set: Key (password) based: Azure AD Tenant ID Azure Subscription Name or ID PS Credential object User name: Azure AD Application ID Password: Service Principal key Certificate

AzureTableEntity PowerShell Module Updated

I have updated the AzureTableEntity PowerShell module few days ago. The latest version is and it is published at: PowerShell Gallery: GitHub: What’s changed? New function Merge-AzureTableEntity Merge one or more entities in a Azure table. Please make sure you understand the difference between Azure table merge and update operations: Update: replace entity fields with the the fields specified in the update operation Merge: update the value of existing fields specified in the merge operation If you want to update the value of an existing field and having the rest of the fields unchanged, make sure you

Deploying PowerShell Module from GitHub to a MyGet Feed using VSTS CI/CD Pipeline

Introduction Lately I have been playing with VSTS and its CI/CD capabilities. Since I have been writing a lot of PowerShell modules and I’m using GitHub and MyGet in this kind of projects, I thought a good scenario to build is to use VSTS CI/CD pipeline to automatically deploy the module from GitHub to my MyGet feed whenever I commit to the master branch for the particular PS module. In summary, this is the process: I commit code changes to master branch VSTS starts the build process (CI) fetch the artefact run pester test making sure the module can be

Programmatically Creating Azure Automation Runbook Webhooks Targeting Hybrid Worker Groups

In Azure Automation, you can create a webhook for a runbook and target it to a Hybrid Worker group (as opposed to run on Azure). In the Azure portal, it is pretty easy to configure this ‘RunOn’ property when you are creating the webhook. However, at the time of writing this blog post, it is STILL not possible to specify where the webhook should target when creating it using the Azure Automation PowerShell module AzureRM.Automation (version 3.1.0 at the time of writing). The cmdlet New-AzureRMAutomationWebhook does not provide a parameter where you can specify the webhook “RunOn” target: there are

%d bloggers like this: