top of page
  • Writer's pictureShannon

Log Analytics Build Options

So in my quest of spreading knowledge about how to build/deploy/configure Azure native monitoring for customers and the broader community, I thought it might make sense to go through a few ways of provisioning a Log Analytics workspace. I've found that customers tend to stick with what they know and bring their on-premises solutions to Azure, so they may not understand how to make use of some of the cloud native tools.

Like any resource in Azure, you can deploy a brand new Log Analytics workspace in the portal by following these instructions. Much like any resource in the Azure portal, you fill in a few fields at the start, you can select a pricing tier (although I'll stress to leave that alone as the perGB2018 SKU is what you'll want to leave your workspace on), you add any tags if you need them, select Review + Create, and finally select Create.

But what if you want a more automated way of building Log Analytics workspace resources?

I tend to hang out in PowerShell and ARM Template land, so I have a script and a template that I use, which are largely abased off of the following examples within the Microsoft documentation:

I even found examples in the AZ-CLI and Terraform space (admittedly, I need to noodle on these as my go-to's are PowerShell and ARM Templates):

I figured it might be helpful to showcase what I wind up building most often (psssst, I use PowerShell), as the examples above might need a real life example. In my script, I build a brand new resource group, build a brand new Log Analytics workspace, set the SKU, and add in the solutions I need to build the workspace.

The actual code to copy/paste can be found here. In order to extract the solutions, I used the PowerShell script I talked about in this post and plugged in the names accordingly.

One thing to bring up is a Log Analytics workspace can have an Azure Automation account linked. This will help customers enable Update Management, Change Tracking, Inventory, Start/Stop VMs, etc. Using PowerShell, I've not found a way to tie an Azure Automation account to a Log Analytics workspace (if it can be done, please reach out - I'd love to showcase if there's an automated way to achieve this task via PowerShell). You can link the two resources within an ARM Template and I'll showcase what I tend to use. For folks who are unfamiliar, please reference a few different Microsoft docs links that will help tell the tale:

In order to link your Azure Automation account to a Log Analytics workspace, select the Azure Automation account from the portal. Once that loads up into view, scroll down to something like "Inventory", "Change tracking", or "Update management". When the pane to the right opens, you will see something like what is shown below:

Once you have linked the Azure Automation account to the right Log Analytics workspace, select Enable. This issues a command to the ARM REST APIs to establish a connection between the Azure Automation account and the existing Log Analytics workspace.

Inventory, Change tracking, and Update management contain similar dialogue prompts in the pane that opens up to the right, which allows you to tie the Azure Automation account to an existing Log Analytics workspace. One thing to note is that enabling Inventory will automatically enable Change tracking and State configuration (DSC). If you need to enable Update management after enabling one of the proceeding features, you will follow a similar onboarding as Inventory or Change tracking. The minor change is that since you have already enabled Inventory or Change tracking, the Azure Automation account will automatically be linked to the same Log Analytics workspace and options to change those configurations will be grayed out. Visually, it will look like this:

In order to complete the configuration, ensure you select Enable. This configuration aligns the service to link the Azure Automation account with your existing Log Analytics workspace.

If you're unfamiliar with the solutions I referenced earlier, please take a look at the following links for more information. In my own opinion, these services are invaluable for VMs within your environment. Manage Change Tracking and Inventory

State Configuration (DSC) - in case you're curious

I have an ARM Template (parameters file is here) I use for quick setups of Log Analytics workspaces and Automation Accounts. I once plucked it from an existing environment and tweaked it to fit my purpose. It just deploys a Log Analytics workspace and a linked Azure Automation Account. The Automation Account configuration skips all the tutorial runbooks you will receive if you build the Azure Automation account from the portal or via PowerShell, so keep that in mind. It's straightforward enough to add those in if you need them, but I find browsing the PowerShell gallery or Microsoft's GitHub repo more helpful so I'm not building a runbook from scratch.

And with that, I'm at the end of another blog post. Hopefully you found this post insightful as you plot out building a Log Analytics workspace with automation or if you need a step-by-step tutorial in the portal. I'm going to hold off on writing a blog for consolidation/switching a resource from one Log Analytics workspace to another at the moment. At some point in the near future, I'll post more about ways to accomplish that task for your resources if you're curious. There are various considerations you need to make within your environment and it may very well be fine to leave your environment as is. If there's one thing I've found, it's that customers tend to find themselves in weird spots where they want consolidation and optimization within their Azure native monitoring environment, so stay tuned!

As a refresher, here are all the blog posts in this series so far:'s my GitHub repo with all code I've showcased throughout the series.

Recent Posts

See All

Enforcing Design Consistency with Azure Policy and Tags

Azure Policy allows you to create, assign, and manage policies in Azure (that definition feels a little like one of those awful definitions in Merriam Webster, right?). These policies enforce differen


bottom of page