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
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
Recently when I was writing an Azure Automation PowerShell runbook, I had an requirement that I need to make sure there should be only one job running at any given time. Since this runbook will be triggered by a webhook from external systems, there was no way for me to control when and how the webhook would be triggered. So I had to add some logic in the runbook that only execute the core code block if there are no other jobs running. The key for this technique is to use the built-in variable that is available in any Azure
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
Over the last few weeks, it occurred to me twice that I had to change my original design of the automation solutions I was working on because of the limitations of Azure Automation Azure Runbook Workers. Last month, my fellow CDM MVP Michael Rueefli has published an article and explained Why deploying Hybrid Runbook Workers on Azure makes sense. In Michael’s article, he listed some infrastructural differences between Azure runbook workers and the Hybrid runbook workers. However, the issues that I faced that made me to change my design were caused by the functional limitations in Azure runbook workers. Therefore
Background Managing the life cycle of PowerShell module assets in your Azure Automation accounts can be challenging. If you are currently using Azure Automation, you may have already noticed the following behaviours when managing the module assets: 1. It is difficult to automate the module asset deployment process. If you want to automate the module deployment to your Automation Account (i.e. using the PowerShell cmdlet New-AzureRmAutomationModule), you must ensure the module that you are trying to import is zipped into a zip file and located on a public location where Azure Automation can read via HTTP (i.e. Azure Blob storage).
PowerShell Gallery has a very cool feature that allows you to import modules directly to your Azure Automation Account using the “Deploy to Azure Automation” button. However, if you want to automate the module deployment process, you most likely have to firstly download the module, zip it up and then upload to a place where the Azure Automation account can access via HTTP. This is very troublesome process. I have written a PowerShell script that allows you to search PowerShell modules from ANY PowerShell Repositories that has been registered on your computer and deploy the module DIRECTLY to the Azure
Over the last few days, I had an requirement injecting events from .evtx files into OMS Log Analytics. A typical .evtx file that I need to process contains over 140,000 events. Since the Azure Automation runbook have the maximum execution time of 3 hours, in order to make the runbook more efficient, I also had to update my OMSDataInjection PowerShell module to support bulk insert (http://blog.tyang.org/2016/12/05/omsdatainjection-powershell-module-updated/). I have publish the runbook on GitHub Gist: View the code on Gist. Note: In order to use this runbook, you MUST use the latest OMSDataInjection module (version 1.1.1) because of the bulk insert.
There are few ways to add PowerShell modules to Azure Automation accounts: 1. Via the Azure Portal by uploading the module zip file from local computer. 2. If the module is located in PowerShell Gallery, you can push it to your Automation Account directly from PowerShell Gallery. 3. Use PowerShell cmdlet New-AzureRmAutomationModule from the AzureRM.Automation module. One of the limitation of using New-AzureRMAutomationModule cmdlet is, the module must be zipped and located somewhere online that Azure has access to. You will need to specify the location by using the –ContentLink parameter. In the past, in order to script the module
Few days ago, I published a PowerShell Module to be used on Azure Automation Hybrid Workers called HybridWorkerToolkit. You can find my blog article HERE. Yesterday, my good friend and fellow CDM MVP Daniele Grandini (@DanieleGrandini) gave me some feedback, so I’ve updated the module again and incorporated Daniele’s suggestions. This is the list of updates in this release: A new array parameter for New-HybridWorkerEventEntry called “-AdditionalParameters”. This parameter allows users to insert an array of additional parameters to be added in the event data: A new Boolean parameter for New-HybridWorkerEventEntry called “-LogMinimum”. This is an optional parameter with the