Azure: Installing the Microsoft Antimalware and Log Analytics extensions on VM Scale Sets

I’ve been engaged with a customer over the the past few months that hosts multiple virtual machine scale sets across their Azure estate. For the most part, the scale sets are used to offer public facing web services.

Using scale sets allows them to provide redundancy and improved performance by distributing their web applications across multiple VM instances. Azure load balancers then sit above the scale sets distributing traffic.

Scale sets also give them the ability to scale the number of VM instances as required. Either manually or automatically using predefined auto scale rules based on resource usage like CPU, memory demand or network traffic. 

As with any virtual machine, it is important to protect the scale set VM instances by installing the latest security updates and running Antimalware to maintain a strong security posture. For scale sets running Windows 2016 VM instances , Windows defender is built into the OS but for Windows 2012 R2 this is something that needs to be managed.

The Azure marketplace offers many third party security extensions that can be implemented. But in this article I’m going to concentrate on the following two and how to go about installing them.

  • Microsoft Antimalware
  • Log Analytics

Installing the Microsoft Antimalware extension 

One way to install the Microsoft Antimalware extension is by browsing to the Extensions blade of the scale set, clicking on the + Add button and then selecting the extension from the popup list.

It’s worth noting that not all extensions are available via the portal so I tend to use the following PowerShell snippet which can be found on the Azure virtual machine scale set FAQ page. I have included the link for additional information.

Once the extension has been installed on the scale set reference image, the image then needs to be rolled out to all of the running VM instances. The simplest way I have found to do this is through the portal.

Browse to the Instances blade of the scale set and then simply select which instances need upgrading. Finally click the Upgrade button to upgrade them to the latest OS image. 

NOTE: If all instances are upgraded at once, the scale set will be offline during the upgrade process.  

Installing the Log Analytics extension

Having installed the chosen Antimalware extension, it’s important to have some visibility into the health of the scale set. Integration of scale sets into services such as Security Center and Log Analytics are still quite limited but viewing the logs that are produced can offer some invaluable insight.

Before we go ahead and install the Log Analytics extension, we first need to make note of the Log Analytics Workspace ID and one of the Workspace Keys. This can be found in a couple of ways, arguably the easiest is by browsing to the Advanced Settings blade of the chosen Log Analytics workspace.

Unlike the Antimalware extension, the Log Analytics extension does not appear in the list accessible through the portal and needs to be installed using either PowerShell or Azure CLI

The following script created by Tim Omta is the method I have tended to use.

Alternatively the same things can be achieved by the following single line of Azure CLI

In the same way the VM instances required upgrading after the reference image had been updated with the Antimalware extension, the same is true for the Log Analytics extension.

In most production environments, I would recommend installing both extensions before upgrading the scale set once from the updated reference image.  

Deleting a virtual machine scale set extension

Having stepped through installing both extensions, it’s worth covering off how to remove them. Even though it’s not possible to install both via the portal, it is possible to remove them manually through the GUI.

For completeness, the following PowerShell script can also be used to remove extensions from VM scale sets.  

As a final note, I’m aware that over the coming months the integration between Azure Security Center and VM Scale Sets is likely to improve. As things change, I plan to feedback on the key improvements.


Azure: Cost Optimisation – Enabling Hybrid Use Benefit (HUB)

I used to spend most of my time discussing with customers the benefits of moving business services to the cloud. Most no longer need to be convinced, in fact many have already dabbled with services and instead are looking for guidance on how to enforce governance and better manage costs.

Cost optimisation in Azure is a large topic and by adopting a number of technologies and processes it is possible to make rewarding cost savings.

Along with investing in reserved instances one of the biggest cost savers for Windows VMs can be make through the use of the Microsoft Hybrid Use Benefit (HUB).

What is Hybrid Use Benefit (HUB)

The Azure Hybrid Benefit helps you get more value from your Windows Server licences and save up to 40 per cent* on virtual machines. You can use the benefit with Windows Server Data Centre and Standard edition licences covered with Software Assurance or Windows Server Subscriptions. Depending on the edition, you can convert or re-use your licences to run Windows Server virtual machines in Azure and pay a lower base compute rate (Linux virtual machine rates).

* Actual savings may vary based on region, instance type or usage.

Paragraph from HUB FAQ

It’s worth noting that licensing entitlement is different between Windows Server Datacentre and Windows Server Standard editions.

  • Windows Server Datacentre with Software Assurance allows you to use the license on-premises and simultaneously in Azure
  • Windows Server Standard with Software Assurance allows you to use the license on-premises or in Azure

With both editions, each two-processor licence or each set of 16-core licences are entitled to two instances of up to 8 cores, or one instance of up to 16 cores.

Enabling Hybrid Use Benefit 

Hybrid Use Benefit can be enabled when deploying a Windows VM either from the marketplace, as part of an ARM template or PowerShell script. It can also be enabled post deployment.

I’ve focused on PowerShell and outlined below are a few commands that might be of use. Its also worth mentioning that its possible to do the majority of this through the portal or Azure CLI.


The first thing to do is make sure that you have the Azure PowerShell module installed.

If you already have the module installed, I would suggest checking that you are running the latest version. This can be done by running the following command.

How do I know if Hybrid Use Benefit is enabled on a VM?

Its possible to check if Hybrid Use Benefit is enabled on a machine by looking at the virtual machines blade in the Azure Portal.

Browse to the virtual machine blade, from the top ribbon select Edit columns and then add Azure Hybrid Benefit to the selected columns list.

Once the Hybrid Use Benefit column has been added to the blade view, its easy to scan down and see which machines have been enabled or not.

As you would expect, its also straight forward to pull back the same information across all machines using a simple PowerShell command.

The following PowerShell snippet outputs just the Windows machines that HUB is enabled for and ignores the rest.

This screenshot is of the above PowerShell snippet being run from within Azure Cloud Shell.

Converting an already deployed VM

For Windows machines deployed with Pay-as-you-go licensing, its a simple process to convert them to Hybrid Use Benefit. As before this can either be done from within the Azure portal or using a simple PowerShell command such as the one below.

NOTE: Changing the license type only updates the machines metadata flag. This means there is no downtime or service interruption to the system. 

Converting back to Pay-as-you-go Licensing

Reverting the VM to Pay-as-you-go licensing is done using the same command. This time, the licensing type needs to be changed to None before running.

Change the license type of every Windows VM in the subscription

Updating the license type of multiple VMs one at a time can be very time consuming. To speed things up, I would recommend reviewing the following script created by Neil Bird a Premier Field Engineer at Microsoft.

The script not only allows you to change the licensing type across all Windows VMs but it also offers a Simulate Mode where no changes are actually made. Instead, LOG and CSV export files are generated to show what changes the script would make if ran in Update Mode.


For more details checkout the Microsoft document site

Application Gateway

Azure: Application Gateway https to https redirect

One key feature of the Application Gateway service is its support for Secure Sockets Layer (SSL) termination. This feature means that the overhead of encrypting and decrypting traffic can be offloaded to the gateway, rather than have this impact performance on the backend web server.

This does however mean that communication between the application gateway and the backend web server is unencrypted which in some cases, perhaps due to security or compliance requirements, may not be acceptable. For those situations, the application gateway also fully supports end to end SSL encryption.

For the purpose of this article, the assumption has been made that SSL termination is enabled on the gateway. Standard web traffic should now be redirected to the https listener so that web requests don’t just fail when they are unable to traverse the application gateway over https.

Enabling https to https redirection

When an application gateway is configured with SSL termination, a routing rule is used to redirect https traffic to the https listener. The remainder of this article steps through configuring this routing rule.


The following assumptions have been made:

  • https and https listeners already exist
  • Azure PowerShell module version 3.6 or later is installed.

NOTE: To check what version of PowerShell is installed and for help on upgrading it if required, see Install Azure PowerShell module.

Configuring the routing rule

1. The first thing we need to do is get the application gateway object and store it as a variable

2. Get the existing https listener

3. Get the existing https listener

4. Now create a redirection configuration using a permanent redirect and targeting the existing listener

5. Get the newly created redirect configuration

6. Add a new rule to handle the redirect from the https listener

7. Finally, update the application gateway

To make it a little simpler to copy all steps, they have been combined into one script below. A copy of the file can also be downloaded from my GitHub repository app-gateway-https-https-redirect.ps1

More information about the application gateway and all of its features can be found by following the link to Microsoft document repository –