For the last several months Pete Zerger, Tao Yang, Kevin Greene, Anders Bengtsson and me have been working hard to update Inside OMS book. With the latest changes we are now on version 3 of the book and with new name: Inside Azure Management
For the last a couple of years many Azure services has started to produce diagnostic logs and metrics. These two allows you to monitor and troubleshoot the Azure Services. Unfortunately still there are some services that are missing those. To pull diagnostic logs and metrics Azure Monitor has capability called Diagnostic settings which allows you to place them on Azure Storage, Event Hub or Log Analytics. Microsoft has done a good job to document many of diagnostic logs available but still I find some services that haven’t be documented. Luckily there is a way to find what diagnostic logs are available for a service (resource) and this blog post will focus on that.
As I still see people confused and not informed about OMS I’ve decided to write this blog post and lay my thoughts around the end of OMS.
If you are not sure what is OMS that is ok and you do not necessary need to know but if you are curious you should check out my blog post What is OMS and a Brief History of It. At Ignite 2018 Microsoft probably announced the last major change related to OMS. This was announced on the Azure blog and at Ignite session. To put it in short Log Analytics (which is in 99% what people refer to when they say OMS) is part of Azure Monitor. In Azure Monitor you might see it being called just Logs for short. But besides that there are actually way more changes some of which happened at Ignite others were happening for quite some time.
Recently I’ve came into the following situation. I needed to store a json as Azure Automation string variable. To do that is easy as you just need to pass the json as text by first escaping it. That is easy peasy when using PowerShell. But what if you want to pass the json as object parameter via ARM template parameters file and do the escape completely within the ARM template. Apparently that is possible as well and I will show you how.
My good friend and fellow MVP Tao Yang wrote a great post on Using ARM Templates to Deploying Azure Policy Definitions That Requires Input Parameters. Azure Policy has two terms that you should be aware:
- Policy Definition – This is the policy itself. This is the definition of what will be governed. The policy definition when created does not do anything until it is assigned. There are policy definitions available out of the box (created by Microsoft) and such that can be created on your own. Out of box policies are of type built-in and the ones created by you are custom.
- Policy Assignment – This assigns policy definition to be applied at specific level like subscription, management group or resource group.