Azure and OMS – Better Together

Azure and OMS – Better Together

Recently, Microsoft announced an enhancement to both Azure and OMS where you can now simply enable the OMS extension for your virtual machines and they will start to report directly to the OMS Workspace associated with that subscription.

In this blog post, I will walk you through a real-world example on how we integrated OMS with Azure to ensure availability for some Windows Server Containers as part of a project.

Overview

We wanted to be able to rapidly test and deploy Windows Server containers to Azure using Azure Resource Manager templates. This would of course lead to development of one or more ARM templates, leveraging custom script extension to perform the heavy lifting within the virtual machine(s).

If you are familiar with container technology and have followed the investment from Microsoft in this area lately, you have probably heard of the Azure Container Service that now is in the public preview. This is an end-to-end solution that you can spin up in Azure using a very abstracted template that will instantiate around 23 resources for you.

If you want to achieve the same with Windows Server Containers today, you must rely on your own ARM skills to make this happen, as the current Container Service is Linux-only.

Container technology is an additional layer of abstraction that you can host on a virtual machine, and whatever you put inside a container today should either be considered as stateless, or you should have externalized the state through the application layer.

In our case we were using stateless containers that would go down in case the container host (the virtual machine) went down or had a reboot in Azure.

With the capabilities available in Microsoft OMS today, this should be a real good use case to combine resources in Azure and OMS to ensure that if the specific event occurred, the container should be running and respond to requests in minutes.

Understanding the requirements

Windows Container is a part of Windows Server 2016 Technical Preview 4 today, which is an available image for you to use in Azure.

Although there’s two supported runtimes for containers in 2016, only Windows Server – and not Hyper-V Containers is supported, as the latter requires support for nested virtualization.

Further, the image in Azure is running Server Core – which also applies to the Windows Server Containers you can host there. In other words, there’s no graphical user interface J

When you use the image in Azure, you will get a default – empty Windows Server Core Image to use for your container exploration. If you want to add applications, server roles and more to a container, you need to be aware that you should treat your containers as Lego blocks.

In our case, there was a need to test several specific Web applications hosted on a Windows Server Containers.

This meant we had to build something that would spin up a new container image, add the Web-Server Role to it, and commit the container to the library as an image so that we could use that image when deploying the web applications on top of it.

From an ARM template perspective, that would mean that we would add a Custom Script Extension resource and associate it with the virtual machine resource.

The Custom Script Extension would then point to a repository that contains the script (PowerShell script in this case). The PowerShell script would support several input parameters so that the entire ARM template would be reusable for others who would like to deploy something similar in the same fashion.

The script would spin up and create containers, and ensure that the correct firewall settings and NAT rules were applied from the container host to the container(s), so the container could be publicly accessible from the outside, following the rules that were defined in the Network Security Group in the template.

So far, so great

From a deployment perspective, this should be good.

Since containers aren’t the same as virtual machines as you can run on your local Hyper-V, you will not get anything that reminds you of Live Migration in the current build. So for us to increase uptime and availability for the containers on the container host, OMS became very interesting.

With the OMS extension, we could easily associate the virtual machine with an OMS Workspace to retrieve critical information about our containers runtime environment.

Not only do we get the insight of our environment in OMS, but we can also leverage the agent to invoke another powerful Azure/OMS resource – Azure Automation.

The goal was now to monitor the virtual machine for specific events, and if the Log Search query would return such result in a given timeframe, we would link that result to an alert we have created in OMS.

From there, we could do remediation through an Azure Automation Runbook.

Since this was an event that was going on inside the operating system of the virtual machine, a Hybrid Worker was considered as the best solution, so that we could trigger Azure Automation to invoke the runbook within the Hybrid Worker context.

Since the OMS agent is also the same agent you would use for Hybrid Worker to Azure Automation, we only had to tell the agent where to register post deployment.

In order to handle this, another Extension (OMS agent) was added to the ARM template, instructed to be deployed before the Custom Script Extension who now also would be responsible for registering the OMS agent with Azure automation.

OMS

Generally speaking, people seems to be confused when it comes to OMS at its capabilities.

Out of the box you get an extreme amount of intel that you can leverage to act upon and become predictive in the way you do management of your resources, regardless of cloud, operating system and location.

This is brought to through Log Analytics, which now is a resource within the Azure Resource Manager API. Together with Log Analytics, you can use Azure Automation (tight integration) as well as Azure Site Recovery and Azure Backup – both who will reach the UX experience in the new portal in the near future.

Once you have connected sources to OMS, the data harvest can begin.

You can decide what type of data you will gather, and you can take advantage of existing solutions from a ‘Solution Gallery’ that gives you pre-defined searches, views and insight based on the solution it represent. Examples here are:

·         Change tracking

·         Security and Audit

·         System Update & Assessment

·         SQL Assessment

·         AD Assessment

·         Malware Assessment

These are just a few examples, and by using OMS – which is Management as a Service delivered from the cloud, you can expect the cloud cadence to be applied to these solutions, reducing Time-To-Market and Time-To-Value which is very good for your business.

The Solution

Azure Resource Manager template

The example Azure Resource Manager Template I will describe here is constructed so that it currently takes input parameters for:

·         Containerhost (name of the virtual machine that will host the container(s)

·         Containername (name of the container to instantiate)

·         vmSize (SKU)

·         adminaccount (administrator account for the container host vm)

·         adminpwd (password for the admin account)

·         vNetName (name of the virtual network to be created)

·         OMSWorkspaceID (the ID for your OMS Workspace)

·         OMSWorkspaceKey (the primary key for your OMS Workspace)

·         AAEndpoint (the endpoint to your Azure Automation account)

·         Token (the primary key for your Azure Automation account)

The resources that will be deployed (in this specific order) are:

·         Storage accounts, public IP address, network security group and availabilityset are deployed in parallel

·         Virtual network will start deployment as soon as the network security group has completed

·         Virtual network interface will start deploying when virtual network and public IP address has completed

·         Virtual machine will start deployment once storage accounts and virtual network interface has completed

·         Virtual machine extension (OMS agent) will start deployment when the virtual machine has completed

·         Virtual machine extension (Custom Script Extension) will start deployment once the OMS extension has completed

·         Once everything has deployed, we should receive an output from the template that will give us the URL to the deployed container, available on port 80

OMS Search

For OMS to find relevant information, the following search was used:

Type=SecurityEvent EventID=4608 OR EventID=1100 "4608 - Windows is starting up." contp4 | Select Computer, Activity, TimeGenerated

This search is targeting the specific virtual machine running the containers.

From this search, an alert was created that was linked to a runbook I had created to start any containers that had State –eq “Off”.

The runbook should then be executed by a Hybrid Worker, which would be the container host itself.

Testing

To test and verify that things are working, we would trigger a restart of the virtual machine in Azure.

Once the virtual machine has started, we can see that the following event has been logged to our OMS Workspace

This also results in an e-mail notification according to our configuration, and should also generate a webhook to invoke the remediation runbook that’s created in Azure Automation

By hitting the ULR to my container again, I can verify it is responding on port 80 and is brought up again just as expected.

Hopefully you found this blog post useful to show some of the capabilities by leveraging Microsoft OMS together with Azure services.

In the next blog post, I'll cover the ideal setup for Microsoft OMS for Service Providers.

(The templates, scripts and examples will be live on my github.com/krnese account as soon as they are polished a bit. Check in there later or follow me on twitter @KristiaNese to get the latest updates)