So whats been changed is that I have moved the blog and rewritten it to be hosted through Github pages with Jekyll instead of WordPress with another hoster. This happened quite fast in a few days time over the last week when I could find the time, but it´s something ive been wanting to do for a long time.

Slow blog and full of maintenance

I know some has mentioned this when they´ve done the same move as I´ve done now. Tao Yang for instance mentioned all of the maintenance that comes with WrodPress as a big down-side with it. You can read his blog about it here in his blog. The maintenance part isn´t something I have missed out on, but the opposite. Every time I´ve logged in to the blog´s admin interface there has been 4-5 plugin updates to attend to. That´s boring, takes a lot of time and you never knew if things were gonna fail afterwards or not.

The other two main issues I have had with my current hoster is the amount of outages. I´ve been with the same hoster for about 5 or 6 years now and I lost count of how many times the blog alerted in the middle of the night for an outage lasting everywhere from 5 minutes to 4 hours. All with no previous notice. That along with the price, around $170 a year for a not so well performing blog got me to finally take the step of moving the blog. GitHub pages is free and you don´t need to pay for any extra SSL certificates, GitHub takes care of that for you and it took about 15 minutes after adding my custom domain before my site were secured and I had my new SSL certificate in place.

The switch

I saw Tao´s post earlier this year and that got me thinking about making the switch myself. Once I started digging into it, there were some serious time to put into it but most of the time were to just rewrite and make sure the formatting of the posts was correct even on the new blog. The switch isn´t that complicated once you get a hold of it, I managed to export all my post and have them converted into Markdown which saved me a lot of time in the end. After re-writing the posts, I had some issues getting the theme up and running but once that was handled I could just focus on publishing the blog and making sure the public DNS records pointed to the new site instead of the old one.

Switching provider completely

Since I was about to leave my hoster for GitHub Pages instead, I was thinking about where to keep my domain and the e-mail as well. In the end I decided to move my domain to GoDaddy since it opened up the opportunity for me to also use my custom domain (Orneling.se) with my Microsoft 365 Family subscription that I use privately.

Wrap-up

So, I mentioned I´ve put a lot of time into this move formatting and converting posts and apges, but that doesn’t mean everything will be 100% correct right now. If you see any faulty links or missing pictures etc. please leave a comment for me and I´ll try to take care of it as soon as possible.

Applications provisioned on Azure are built on top of architecture that is siloed and highly dynamic. Hence, it is inevitable to monitor the applications and services of Azure to maximise the availability, performance, reliability, and consumption.

Monitoring Azure Resources

Monitoring Azure Resources using the Azure-native tool can be challenging even for the most skilled and experienced person due to its complex and overlap offerings.

If you have tried monitoring in the Azure portal, you might have faced a situation where a tool-A would require monitoring a resource-R. Still, if you want to do another monitoring activity on the same resource-R, you will need to use tool-B. This would undoubtedly lead a user to collect cumbersome of data from disparate sources. In this blog, we will look at some of the critical challenges users face while monitoring Azure resources using Azure Monitor and how to overcome it.

Significant Azure Monitoring challenges

Azure application monitoring poses a long list of challenges that users must overcome to achieve better performance and efficiency.

Lack of Application-level/holistic monitoring

When examining typical Azure architecture’s anatomy, every application is designed with a combination of multiple siloed Azure resources like Service Bus, Azure Functions, and Virtual Machines across the stack. When the user intends to monitor in the business application context, it is impossible to do so.

Azure Monitor is restricted to monitor individual Azure resources, and users must move between different components to achieve visibility on them.

No Consolidated Report

It is not possible to generate a consolidated health, performance, or availability report of all the resources that participate in the Azure applications.

It would be challenging to correlate the reports on every resource from the Azure monitor.

Limitations of Alert Rule

In Azure Monitor, adding conditions to an alert rule comes with a considerable challenge where the users can apply only two conditions per rule. The ideal cost for adding those conditions would be $0.20. And hence, if you want to have more conditions, the only option available is to increase the number of alerts which would not be economical.

Unable to Monitor Resources Properties and Status

Business needs would demand monitoring solution way beyond resources metrics, like status and properties of the resources and detect failures in orchestrations.

There is no way you can monitor the resource properties like Dead Lettered Message count in Service Bus Queue/Topic Subscription, Incoming messages to an Event Hub partition.

You can also monitor the status of the resources that may go down due to various reasons like component failure, server failure, or a faulty data centre network switch, rather than disasters like floods or earthquakes.

Lack of Auto-healing capability

As we have seen above, there are quite significant reasons why a resource may go unavailable in different scenarios, and hence they turn to a disabled state. It is significant to ensure that mission-critical resources are always up and running despite unplanned outages and potential errors.

At a bare minimum, we should bring back the resources state to “Enable” (expected state) as soon as the issues get fixed at solution providers back end.

Limited data visualisation

While Azure Monitor provides some pre-built dashboards, specifically for metrics, users might find themselves somewhat limited to how much they can customise the data displayed using in-built capabilities like Azure Dashboards, Workbooks etc.

Lack of notification channels

In Azure Monitor, it is not easy to create incidents and support tickets to the most used platforms like PagerDuty and Service Now. It is not possible to Notify appropriate stakeholders on violations through various collaboration tools like Teams, Slack to stay on top of critical issues.

The email notification templates are pre-defined which the users cannot customise to best of their interest.

All-in-one solution for all your Azure monitoring needs – Serverless360

With a detailed study and understanding of Azure application architectures & its monitoring needs, we built Serverless360 to fill all the gaps in the Azure-native and other third-party monitoring tools currently available in the market.

It has the following capabilities to address the above monitoring challenges.

With Serverless360’s Composite Application feature, you can logically group all your siloed Azure resources in a single pane of glass to monitor in a business application context.

Serverless360 built-in monitors provide you with a consolidated report on the status of all resources of your Azure application

You can monitor any number of resources on multiple metrics in a single alert to eliminate the additional cost
With Serverless360’s extensive monitors, you can monitor the properties and status of the Azure resources with customizable warning and error thresholds to prevent outages Threshold monitor in Serverless360 allows restoring business by auto-correcting resource state absolutely with no manual intervention

Whether you are running Azure Functions, Logic Apps, Azure Data Factory, or something else entirely – Serverless360 got you covered. Visualize the performance of more than 100+ Azure resources with customizable, plug and play dashboards

Serverless360 supports a wide range of Notification channels like Pager Duty, Slack, OMS, Microsoft Teams along with Webhook and email channels that Azure Monitor does not support.

Firstly, if you haven´t read my previous posts about ARM Templates you can find them below:

• Getting started with Azure ARM templates
• ARM Templates: Working with naming conventions
• ARM Templates: Working with tags in Azure
• ARM Templates: Working with parameters in Azure
• ARM Templates: Working with nested templates in Azure

I am deploying a workspace with a bunch of performance counters pre-configured on which the alerts rely on. If you don’t know how to do that yet, go through the previous posts where I show it in detail.

Preparing the main template with parameters and variables

Before we can deploy the alert rules, we need to state what kind of information we need. The first thing I´m going to do is to set the e-mail recipient of the alerts I will be creating. There is a possibility to ad SMS recipients as well, but I won´t go through that in this post. Basically, what you need to state is the name of the recipient and it´s e-mail address. I´ve chosen to put this as a parameter since this is most likely something that will change for most deployments.

The next thing I will do is to prepare the name of the action group to create, and a short name for it as variables. What you need to know is that the short name can never exceed 12 characters. That´s why I´ve put a rather simple name for it with the workspace name followed by “-AG”.

The QueriesAlertsLink variable is pointing to my Azure storage account, but you can use the link already in the template as it´s publicly accessible. This is where the main template will look for the nested template containing all the alert rules.

Preparing the main template with the resources needed

In this main template we will add two resources. An action group and a nested deployment looking at the alert template itself.

As you can see below, I have highlighted the most important things in this deployment. As I mentioned above, you can create SMS recipients as well, but for this demo I will only add myself with my e-mail address. The action group depends on the workspace which is created through the main template, and it´s also towards that workspace the alerts will look for the information to trigger on.

The nested deployment itself isn´t that different from what I showed in my previous post. It´s basically another template and with one more parameter passed on, the actionGroupName variable. If you´re curious for more information about nested templates, read about that here.

Looking at the template containing the alert rules

Looking at the template used for deploying Azure Monitor alerts, we can see the parameters section will get the information that is being pushed in during the deployment. The workspace and action group name is used to pick up the resource Id of those two resources to be used later on.

The information needed to declare an alert in an ARM template is seen below. I have highlighted the important things that make up the alert itself. You can see I´ve pointed out the location of the workspace, the workspace as the data source and the query to run.

When it comes to the schedule, the maximum number you can set (as of the time writing this post) is 1440 minutes, which is equal to 24 hours.

I also tell which action group to use, along with the formatting of the alert being sent out.

Post-deployment checkup in the Azure portal

As soon as the deployment succeeded, we can head into the Monitor section of the Azure portal and find our alert rules. All we need to do is to highlight the resource group we´re looking at. Now, we will immediately see all alerts that´s been created. As you can see below as well, the “Workspace-Finance-001” workspace is being used as the data source for those alert rules.

As soon as one of the queries has a result count of 1 or more, the alert will fire and in this case, I will receive an e-mail.

Summary

As you see here, deploying Azure Monitor alerts don´t need to be that complicated. Sure, there´s a bit of a learning curve of doing it with ARM templates but once passed that it´s a lot faster.

The template itself isn´t that complicated, but there are some things to think about. The main thing I want to point out is the action group short name which needs to be a maximum of 12 letters. If you want to read more about setting up Azure Monitor alerts using ARM templates, look here.

I have uploaded the templates and the PowerShell deployment script to my GitHub repo, which you can find here. Use them just as you want.

If you have any comments or questions, leave a comment below and I´ll get back as soon as possible.

In my previous posts in this ARM template seriesyou can see how to get started, from using tags to how to work with parameters. But one more thing I want to show is how to work with more complex deployments, and that´s where nested templates come in.

The goal of the deployment

With this ARM template, I will deploy a Log Analytics workspace along with a bunch of performance counters and a bunch of saved searches (queries). The information I´m including is something I´ve based on how SCOM collects information about things as CPU usage, memory usage etc. Near real time performance counter collection is cool, but how often do we really need that?

The timing of the collection intervals I´ve gone with here is either five or ten minutes.

Adding a performance counter to the template

When wanting to add anything, such as in this case a performance counter or an event log, we need to look in the resources section of the resource itself. In this case it´s a workspace.

As you can see below, there are some information needed, but everything is quite straight forward once you get a hold of it. The name of the resource as seen below needs to be unique for the template. There are a total of twelve performance counters added with this template, along with the System, Application and Setup event logs.

Adding saved searches to a template

Looking at the template to be used as the nested template, there are some things to tink about. First, the parameter (in this case WorkspaceName) can´t have a value. Just define it as string as seen below. This way, the vaue will be used that we´re passing along from the main template.

When it comes to the resources, it´s not a big difference in how you write it. In this case we include saved searches as seen below, but it could just as well be an automation account, storage account or whatever. The same thing goes for other resource types as well.

Looking at the “Query” section below, the \r\n in the query are JSON formatting to switch line in the query.

Calling the nested template

What I´ve done for this demo is that I have uploaded the template I will be calling to an Azure storage account that allows anonymous access. In other words, you can use this URL when trying it out yourself.

This variable will be used when the main template calls the nested one, and knows where to find it.

Using a nested template is quite easy actually. Just need to understand the language to be used first (of course). It goes in to the template as a resource and there are some things you need to be aware of.

In the properties section, set the mode to incremental and the URI to the link where to find the nested template. To make thins easier and look cleaner, I have created a variable containing the URI of the template.

You can also choose to pass parameters on to the nested template. See below for how that´s done. This is why you should never set a value for the parameter in the nested template as I mentioned above. If there is a value in the nested template, the value you pass on from here will be overwritten by the default value in the nested template.

Deploying the template

As usual, I have used a PowerShell script to deploy the template. Find the link in the end of the post.

As you can see there have been some tagging, you can see the workspace name and location.

Looking at the results

When we look into the advanced settings section of the workspace, we can see that our performance counters have been deployed. Together with the timing intervals I mentioned above. These counters will now be collected from the servers reporting to the workspace, and can be used when writing queries.

When it comes to the queries we deployed with the nested template, these can be seen in the Saved Searches section of the workspace. Some queries with basic checks for CPU, disk and memory (and some more) that can be used to generate alerts when something happens with your server(s).

Summary

When I first heard of nested templates I thought it sounded cool but awefully complicated. However once I started looking into it, it turned out to be cool and surprisingly easy to get going with.

This is a great way to divide a large main template into a smaller main template with multiple smaller templates to be called. This makes it a lot easier to build more complex solutions as these can be tailor made including just the components you want.

I have uploaded the templates and the PowerShell deployment script to my GitHub repo, which you can find here

If you havent read my previous posts about ARM Templates you can find them below:

• Getting started with Azure ARM templates
• ARM Templates: Working with naming conventions
• ARM Templates: Working with tags in Azure
• ARM Templates: Working with parameters in Azure

As always, if you have any comments or questions, leave a comment below and I´ll get back as soon as possible.

Stay tuned for more posts on cool Azure technologies.

Instead of creating one parameter for each tag, I have switched over to a new way of doing it. Instead of creating a single string, I create the tags as an object type. This means that I will be able to pass multiple values (in this case its tags) as one parameter instead. Have a look below.

The single value way vs the multiple values way

The two examples below show the single string way, while the other shows the object type way. By doing this we can shave off lots of code, but we can also save a lot of parameters. For this small example it makes no real difference in functionality. But in larger deployments it can help as there´s a limit of 255 parameters per deployment.

The amount of tags I put in is the same, but here it´s combined into one single parameter instead of three. The main difference is that I erase the single parameter (the bottom square) and rely only on the upper one instead.

Using the parameter values

When referencing the values of the multiple value parameter, there is a slight change. Before, we could just reference the whole parameter, but now we need to break it down a little.

Before we had to write “[concat(parameters(‘Department’))]” for example, but now we need to write “[concat(parameters(‘Tags’).Department)]” instead. In other words, we change the main parameter we´re calling and adding the value which in this example is Department.

This way of doing things is not limited to tags in any way, but it can be used for any parameter of your choice.

Changing the parameters file

Now when we´ve changed the way we´re writing the parameters, we also need to update the parameters file as well. Of course, you don´t need a template file, but I highly recommend it. Thatway you don´t have to edit the main template every time you want to change an input value. What we need to do is to add the different values into the “value”:{} section of the parameter. As you can see below, it´s pretty much the same but with some minor changes.

The Department parameter in the bottom square is not in the final parameters file. It´s only there for the purpose of this demo.

Deploying the template

When deploying the template, I have used the same PowerShell script I´ve been using for the past few blog posts in this ARM Template series.

What you see below is the output in PowerShell after a successful deployment.

Looking in the Azure portal we can see the tags are added just as expected. There´s no difference in the functionality with this better way of doing parameters, it just saves us time and lines of code.

Summary

So this was another blog post in my series where I go through how to work with ARM Templates for you Azure deployments. As soon as I heard about this I checked it out, and in about 10 minutes I was up to speed and had made the changes necessary to make the change. Thank you Martin!

I have posted the sample templates and the deployment script I´ve been using to my Github repo and you can find the files here. There´s also a great article from Microsoft here, which explains the things I´ve done here if you´re curious about more.

If you havent read my previous posts about ARM Templates you can find them below:

• Getting started with Azure ARM templates

• ARM Templates: Working with naming conventions

• ARM Templates: Working with tags in Azure

If you have any questions or concerns, leave a comment below and I´ll get back asap.

First things first, why should you work with tags?

Tagging resources is a way to keep track of things like who is the owner, what department it belongs to, the environment and cost center to name a few examples. In a small Azure environment with just a few resources, it´s quite easy to keep track of the resources as is. But once you build a larger environment you´re going to need tagging to keep track of the different resources.

Using tags is also a way to control how much money a team is spending on Azure resources. This way you can get a cost analysis based on certain tags.

Get started using tags in Azure

For this example, I´m going to use an ARM template to apply tags to resources as a part of the deployment. The example is the same as was used in my last post about naming conventions, but with a few changes.

The first thing I have done is to add three new parameters: Department, Environment and Owner. Nothing fancy, you just copy a previous parameter and switch out the values to the new one you desire.

The next step is to insert the tagging information in the ARM template in the right place. It should be inserted like you can see below right between “location” and “properties”. You just insert the tag as “TagName”: “[parameters(‘TagName’)]” followed by the rest of the tags.

And that´s it for the arm template in this example. You just need to repeat this process for each different resource you have added to your template. Just paste the information right between location and properties on the rest of the resources and you´re good to go.

Deploying the template and verifying its function

I used the same PowerShell script as last time to deploy the ARM template. As you can see here it lists the parameters we typed in and all looks good.

Looking in the Azure portal we can see the new workspace created, along with the tags we provided.

Tagging resources isn´t at all complicated, but it adds a real value useful in multiple scenarios. Just to be able to check who is spending the most money or to see which department using the most resources is a completely new way to keep track of the expense in the company.

Checking all resources with a certain tag

As you can see in the below picture you can push the button, I pointed out to see all resources with that certain tag. In my case where it´s my own lab environment there’s no chock that most resources are tagged with my name, but in a live customer environment this is a great way to find the person responsible for the resource. In this view, you can also add new tags to a resource.

Below is a view where you can see all resources tagged with me as the owner.

Summary

This post isn´t as long as they usually are, and that´s basically since tagging resources is a real straight-forward task and not at all complicated. Even though it isn´t complicated at all, it really adds value since we can follow up on resources in a completely different way than we could before tags was introduced.

With this post I wanted to show how simple it is to start tagging, but also to explain why you should use it. I really think that tagging resources should be a part of the routines when deploying new resources, as it helps big time when finding owners or doing cost analysis for the resources.

I have uploaded the ARM template sample to my GitHub repo and you can download it from here. As always if you have any questions do not hesitate to leave a comment below.

As long as you don´t need anything else than just setting a simple name, that sample template works fine to create a simple automation account. But what if you want to comply with your naming conventions that you´ve come up with for your cloud resources? To do this we need to look at another ARM template function, which I use heavily to set the correct names etc. for my resources.

Concatenate

The function I´m talking about is called concatenate and it´s used to combine several different input values and some static information if that´s needed. For this blog post I´m going to demonstrate how you can create a new empty Log Analytics workspace, combining different parameters for the purpose of naming the resource using the concatenate function. The three sections of the ARM template we´re interested in for this demo are parameters, variables and resources. Those three will be used together to finalize the naming of the resource.

Parameters

To be able to combine values, we need to put in a bunch of parameters. For this example, we will put in name, location and the department for which the workspace is deployed. You can see the complete parameters section below, just like we did in the last blog post. The only new addition is that I have used several different regions where the workspace can be deployed. If you try to put it in any other region than the ones I have typed below, the deployment will fail immediately, and you will have to go back and change the value.

Variables

For this example, we will use two different variables. A variable can be a hard-coded value, such as License below, but it can also be a combination of different values. That´s where the concatenate function comes into play.

In this case, I want my workspace to be named “Workspace-Department-001”. To be able to achieve this, we need to type like I have done in the picture below. In real life, this workspace will be named “Workspace-HumanResources-001”. It can be a little tricky at first with this concatenate function, but once you get a hold of it, it´s really neat to know and it will help you leave those hard-coded values that no one ever really wants to use.

Resources

To deploy our workspace, we need to use a resource of the type “Microsoft.OperationalInsights/workspaces”. The code you see below is also available as a snippet in the Azure Resource Manager Snippets _extension I recommended in my last post. For this workspace to look the way we want, we need to change three values: name, location and sku.

See below for what it should look like in your template.

The complete template

The complete template consists of 56 lines of code and will be deployed using the parameter values set in my “azureDeploy.parameters.json” file. I will link the template below for you to use however you like and to build upon. These 56 lines of code is really all you need to deploy a workspace with this naming convention, and you don´t ever need to touch most of these lines at all.

Deploying the workspace

As last time, I have provided a PowerShell script that you can use to deploy the template, that will also be linked below together with the template files.

The deployment took about five seconds using PowerShell through VS Code and you can see the values from the parameters in the picture below.

Looking in the Azure portal we can find the new workspace in our shiny new resource group. The workspace has now been deployed and is ready to start collecting your information from servers, web apps, metrics and much more.

The resources used for this post

You can find the template files needed along with the PowerShell script to deploy it in my GitHub repo here. Feel free to use it whichever way you like, it´s there for you to develop and to keep learning about writing ARM templates.

Summary

As you have seen in this post, it doesn’t have to be that hard to leave the hard-coded values and going over to complying with your previously stated naming conventions. To be able to put together the resource name from several parameters instead, you can make your Azure environment a whole lot cleaner, and make it a lot easier to find which resources belongs to which department.

If you have any questions about what I´ve done here or just want to leave a tip for other readers, leave a comment below. Stay tuned for more posts in this ARM template deep-dive, next up is tagging the resources.

If you want to see another example of the concatenate function, you can have a look at Microsoft’s example here.

As I mentioned, this was back in 2015 so nearly five years ago now, but even more important nowadays. My first experience with this new way of working with Azure was a bit of a rollercoaster, every time I grasped something, another thing showed up that made absolutely no sense at the time. Back then I looked at a lot of sample templates and practiced my copy/paste skills to build a template that was deploying the resources I wanted to deploy.

The foundation

Now it´s 2020 and a lot has happened in many ways, and thankfully it´s a lot easier to get started writing ARM templates with a bunch of different tools, of which of I´m going to show a few in this post. If you don´t know what an ARM template is, it´s basically a JSON file which define the objects you want to deploy, their names, types and properties. This file is then read by the Azure Resource Manager API and deployed in the exact same way each time you run it. If something already exists, it checks for changes and if there are no changes it just skips that part of the template.

The base template

The base template looks like below and consists of several different sections.

• Parameters: Can be set to a default value, with a drop-down list of allowed values (which regions you can deploy to for example) and can be changed upon deployment.
• Variables: Used in the resources section of the template. Can be a combination of several parameters, or just hard-coded values. Used to define naming standards just to mention one use case.
• Resources: The resources to be deployed along with it´s name, properties and tags etc.
• Outputs: Used to return values from the template, the endpoints of a storage account for example

The base template.

Getting started writing code

Over the years I have come to a good understanding of ARM templates and how to write them to do the things I want them too, but it hasn´t been easy. To help you get started, I want to recommend those tools I use in my work with ARM templates to make things and life in general a lot easier. And it also saves a lot of time. With these tools I´m about to recommend I can build a new ARM template to deploy a new automation account or a Log Analytics workspace in about five minutes, and that´s with some tweaking of the naming etc.

The first tool I recommend using as the foundation is Visual Studio Code, which is an awesome tool to write code. I use it to write PowerShell, JSON and also YAML (for my home automation). If you haven´t tried it yet, download it here to get started. A pro tip is to create a new file and just saving it as “new-file.json” or .ps1 for example, just keep the “” when you save it. VS Code will then recognize it´s either a JSON file or a PowerShell script, and highlight the script in a correct and easy-to-work-with way.

Visual Studio Code Extensions

Azure Resource Manager (ARM) Tools

This is the first extension to install when looking at writing ARM templates using VS Code. With this extension, VS Code understands Azure Resource Manager deployment template files. It also helps pointing out sections where the JSON code is faulty.

With this extension you get some snippets to start building your templates. Just type arm! in a json file and you will get to choose from the below snippets.

• arm! - Adds the framework for a full deployment template file for resource group deployments
• arm!s - Adds the framework for a full deployment template file for subscription deployments
• arm!mg - Adds the framework for a full deployment template file for management group deployments
• arm!t - Adds the framework for a full deployment template file for tenant deployments
• armp! - Adds the framework for a full deployment template parameters file

Download the extension from Visual Studio Marketplace here, or from within VS Code directly (see below), from the Extensions section. At the extension page, you can also see all the snippets available.

The extensions pane of VS Code

Azure Resource Manager Snippets

When I said I can write a new template in five minutes, I am relying on an extension written by MVP Sam Cogan. It´s by far the extension I have had the most use of so far. It consists of a bunch of snippets which lets you deploy the resources you want. All you have to do is to launch a new json file and start typing “arm-“ and the snippets will show up and you can choose whichever you would like to use. Start with a Skeleton ARM Template (provided by the first extension above) and you will get the content shown above, ready to be filled up with different parameters and resources etc. It can also help you write the parameters necessary. Find a complete sample template further down in the article.

Download the extension here or through VS Code Extensions as shown above.

Some of the available snippets

ARM Params Generator

The next extension on my list is one that helps generating a parameters file. This file is used to point out the custom values that are to be changed upon deployment and consists of only a parameters section with the different values. Once you have created your ARM template and have installed this extension, just right click somewhere in the code section and choose “Azure ARM: Generate parameters file”, and it will create a file named “templatename.parameters.json”. See below what it looks like.

Generate a parameters file for your ARM template

The parameters file. Find the source code further down.

Download the extension here or through VS Code Extensions as shown above.

JSONLint

The last tip for the day is a web site helping you validate your JSON code. It points you to where you need to check your code, which have saved me numerous times since it´s really easy to miss an indentation or a parenthesis or whatever when writing code. Find the JSON validator here and remember to bookmark it, cause you will need it.

Sample code

I have placed a complete sample of the ARM template I used for this blog, along with a parameters file and a PowerShell script to deploy it over at Github.

Find it in my public repository here.

Microsoft Tutorial: Create and deploy your first ARM template

If you´d like to, you could also check this tutorial out that Microsoft has created on how to create and deploy your first ARM template. It will guide you from the start to the finish line where you have deployed your first template. Find the tutorial here.

Summary

As I´ve shown here, it doesn’t have to be that big of deal to get going with ARM templates and JSON. There are tools out there to help, so use them just as everyone else. The extensions itself won´t help you understand the JSON language, but along the way you will get a grasp of it and hopefully you will have that aha feeling, just like I did when I was learning JSON.

I will go through the area of ARM templates even more and tell more about what can be done, such as skipping hard-coded names etc. in upcoming posts. If you like the post or have questions, please leave a comment below and I´ll get back as soon as possible.

The past

I´ve been doing SCOM for about 9 years now and it´s time for a change. I have retired from Approved after about 3 years. There I was working almost 100% of the time with SCOM. There was a lot of really nice projects, and it has been a great time there. But since my personal focus has been with Azure for quite some time now I needed a change. With this shifting personal focus I thought it was time to look around for new openings.

The future

As of today I am working for AddPro as a Senior Consultant where I will focus on Azure Infrastructure instead. With the change of employer comes a change in the focus of this blog as I move on from SCOM. I will not write more about SCOM unless it´s directly connected to a subject I´m writing about of course.

Shifting focus of the blog

From now on I will publish Azure related articles here instead. I will share a lot of different things from how to get started using ARM templates to creating custom monitoring in Azure Monitor just to mention a few of the ideas I have.

I hope you stay with me on this journey and continue reading the blog. It goes without saying of course, but all the SCOM articles will remain intact on the blog as many of them still helps people on a daily basis.

If you have any comments or questions, feel free to drop a comment below and I´ll get back ASAP.

The evolution of Azure

Sure, that was easy and something anyone could do, but was it the right way? Since 2012 when these events occurred, a lot has happened with Azure, and I really mean a lot! The most important change is that we´ve gone from Azure “Classic” to Azure Resource Manager (ARM), where the first generation of Azure were built upon XML, while the second generation is built upon JSON. That and a lot of other possibilities, such as the use of Rescource Groups make it more complex, but at the same time a more mature and safer experience using Azure. The right way to deploy new resources nowadays is to use ARM templates, which is a JSON formatted template telling what to deploy and how to configure it. The advantage of this is that every time you´re deploying something using the template it will be deployed the exact same way, eliminating the human factor.

The easy way vs. the right way

I´ve mentioned how easy it is to get started, but does that mean it’s the right way to do it? Nope, not necessarily. Just as were used to from our on-prem environments, there´s this thing called best-practice to take into consideration. More possibilities also mean we must think our deployments through a lot more. I mentioned resource groups earlier which gives us the ability to split our deployments into several different resource groups, all which can be provided with their own sets of rights assignments.

While we deploy more and more resources, there are another huge thing to remember, Azure Governance, which lets us control our Azure based environment using policies to control how it´s being both deployed but also managed.

Azure Governance - The right way

Azure governance consists of three mayor areas, Management Groups, Policies and Blueprints (more about this in a later post). Just as we have Group Policy on-prem, this is our way of controlling the environment in the cloud. Management Groups let us group several different subscriptions to make it able to mirror the organization. For example, you can assign one subscription to the HR department, and others for the dev team such as a Dev and Staging environment. This makes it easy to follow up on which parts of the organization spends the most money, but that’s not the only advantage this bring. We can also assign policies subscription-wide and use access control based on our preferences.

With policies comes the ability to control how the environment should behave and if we have any requirements about how a resource should be equipped.

Below are just a few already made policies which involves virtual machines. Should you not find anything of your liking, you can always create your own policies.

Azure Policy – The way to keep the control

With Azure Policy we can assign several policies and we can choose if they should just be auditing or forcing. The difference is that a policy that audits does nothing with the resource, it just audits and reports it back for us to know about, while a forcing policy actively denies certain configurations or won’t let you continue until certain requirements are met.

A few examples of what a policy can achieve:

• Enforce the use of tags for our resources making some tags mandatory, such as cost place, business unit or environment
• Specifying which VM sizes can be used when deploying new servers
• Allowing certain regions only for resources to be deployed (extra useful when the company spans over different countries or continents)
• Enforcing a naming policy
• Installing an extension to all new servers, connecting it to Azure Monitor for example

Enforcing a monitoring policy to all servers

The last example mentioned above is something I want to spend some more time elaborating. We´re (hopefully) already used to monitoring our on-prem environment using System Center Operations Manager for example, but most often this tool isn’t used to monitor cloud resources other than IaaS VM´s from time to time, but now we need to be monitoring our cloud resources as well to keep the environment safe and running.

To make sure our resources are being monitored we can assign a policy that forces the installation of the Log Analytics monitoring agent for all servers that are deployed in the subscription. This can be configured to take effect subscription-wide or for certain resource groups only. This means that if a user deploys a server from an ARM template that don’t include the Log Analytics agent extension, this will be automatically deployed afterwards, ensuring our resources are being monitored the way we intend to, in a certain workspace.

I assigned this policy to my subscription, deployed two servers as seen below, “EU-SE-VM0001” and “NA-US-VM0001” and in about twenty minutes they had the Log Analytics agent installed, just as intended.

And just to verify that the servers are communicating with Azure Monitor (of which Log Analytics is a part) I ran this simple query seen below to collect the information about the server’s heartbeats and their IP address along with the country they are deployed.

Yes, the SE VM is based in Ireland but that´ll change once the Azure datacenter in Sweden opens.

Learn more about Azure Monitor in these posts:

• Get notified on Azure service health issues
• Looking at the available Azure Monitor data sources
• Azure Monitor – Getting started with alerting
• Migrating lots of agents to Azure Log Analytics

So how can I Azure Governance in my environment?

There´s no short answer to that. You can either use a single policy or multiple policies, where the latter is the recommendation to make sure you take good care of your resources. Earlier this week during Microsoft Ignite in Orlando, Microsoft announced Azure ARC which is a tool that you can use to manage all your resources “the Azure way” no matter where they´re deployed. This means that even if your resource is deployed in AWS, Google Cloud or on-prem, you can still use ARM templates and policies like the one above installing agents for those resources. Azure ARC is still the new kid on the block, but I have a feeling we will hear a lot about it soon and I´m pretty sure it will come to great use.

It also helps big time in controlling the environment and keeping it safe even with those resources that aren´t deployed in Azure, and we can keep control of them in one place instead of several different portals and tools.

If you want to read more about Azure ARC, you can do so here.

Summary

With this post I have started scraping the surface when it comes to Azure Governance and I´m no way near showing it all off since there’s really a lot to show in this area. It´s really important to invest in this area since it´s about securing our cloud resources, especially when more and more investments are being made in the cloud. With all the new resources being deployed, there´s a bigger need for tagging and RBAC (access control) etc. and all that can be pretty easily controlled using policies and placing them in different management groups.

I will keep digging in to this area of Azure Governance and instead of doing one mayor post I´ll write several covering different scenarios instead so keep your eyes open if you think this seems interesting.

If you have any questions, leave a comment below and I´ll get back to you.