Microsoft recently release the new Logs experience with this also removing the link to the Advanced Analytics Portal which was separate portal. My friend and fellow MVP Stefan Roth opened a e-mail discussion to some of us asking if there is a way to reach his workspace again from the Advanced Analytics Portal as that portal offered cleaner experience where Logs is a little bit cluttered due to being general portal for Azure services. I had some tips on how to use better the Logs experience in Azure Portal and my friend and fellow MVP Cameron Fuller thought that we should share this with the community thus this blog post.
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.
Not so long ago in Azure we only had resource group level deployment but a couple of months ago subscription level deployments were implemented. On resource group level we deploy resources like Azure VMs, Service Apps, Azure SQL databases, etc and on subscription level we deploy policy definitions and assignments, resource groups (yes they are resource as well), custom RBAC roles, etc. Because of that it the schema in the ARM templates for resource group and subscription level deployments is different. This is something I haven’t thought about it around the excitement of this new deployment method but my good friend Kristian Nese tipped me. So here are the schemas you should use depending on your deployment:
In my blog post Defining Input Parameters For Policy Definitions in ARM Template I’ve showed you how to use deploy policy definitions with parameters via ARM template. I didn’t described completely on why such workaround is needed but I think now it is good time to explain that as well. The topic is a little bit complex so I hope my explanation will help you understand it.
Azure Policy team has a GitHub repository of Policy definitions examples. Recently I’ve been looking at some of the examples there and I’ve noticed that one of them was not working correctly. Specifically I am referring to Platform Image Policy. Additionally the example contains only the rules. It does not have ARM template for deploying the definition. You will notice also that the policy is pretty static as it does not contain parameters. Because of that based on that sample I would like to create an example on my own and show it to you.