Wednesday, April 20, 2016

Connecting the dots with OMS and SLACK

In my last blog post, I spent some time trying to explain why OMS is more than you think and how this fits into the next generation of hybrid IT management, with Management-as-a-Service.

Today, I want to highlight something I myself find very interesting, where we are using OMS as the source of our information towards operations engineers.

OMS Log Analytics

One of the key aspects of OMS is the Log Analytic workspace. This is where you harvest the data from your hybrid operational environment, and as I talked about in my previous blog post, you can have multiple data sources – and even use custom logs to retrieve and centralize the information you are looking for – but also (and perhaps more important) – the information that you didn’t knew you were looking for!

Log Analytics let you easily search for any of your data and from there, you can truly demonstrate your skillset by connecting the dots to a complete remediation solution, or plug into some other system to either deliver or manipulate the data or both.

With Log Analytics, we are able to:

·         Search for any of our data
·         Save searches and use them together with Dashboards
·         Use saved searches in conjunction with Alerts
·         Get e-mail notification with detailed information about the alert, search result and more
·         Connect Alerts with Azure Automation to trigger a Runbook that is either executed in Azure or through a Hybrid Worker
·         Connect Alerts with third-party systems using WebHooks

This blog post will focus on how to use OMS as the foundation for an operational department and centralize the alerts (informational, warning and critical) into SLACK.

First, let us quickly get a better understanding of what SLACK really is and why it might be useful in this particular scenario.

Many IT organizations are having a wide diversity of different ways of doing collaboration. Some of them are good, some of them are less good. However, the fact is that many channels might be used over time which leads to lack of communication and especially transparency when it comes to critical information around the operations.
Slack is a messaging application where teams can share files, talk and literally work together. This lets organizations have everything in one place, moving away from the devastating e-mail threads and so on.
With SLACK, everything that is shared is automatically indexed and archived which is searchable.

Some of the advantages you will get immediately when using SLACK is transparency to team communication for greater visibility into what other teams are working on, it speeds up feedback and decision making and make it a lot easier to find information and documents and more.
Las but not least – SLACK supports a wide range of tools, which means you can integrate existing apps, systems etc to communicate with SLACK to centralize the communication and information.

This is where OMS comes into play together with the WebHook integration to SLACK.

Ok, I get it. The information from our alerts can have a flow into one or more SLACK channels where our teams can get everything in a single view, but what exactly is a WebHook?

I am glad you asked.

WebHook is something you have used already if you have been using Azure Automation – and especially together with Alerts in OMS. This will leverage WebHooks.

The concept of WebHooks is really simple, and by simple I mean it is a simple HTTP POST that occurs when ‘something’ happens.

Using OMS together with SLACK, OMS will POST a message to a URL when certain things happen (the Log Analytic Search is showing some result that will trigger the Alert workflow).
WebHooks helps us to receive valuable information when it happens – instead of constantly pulling for the data.

In SLACK, you can add an ‘incoming webhook’ to your channel that will accept data from external sources that will send a JSON payload over HTTP.
Each channel in SLACK will be identified by a unique incoming Webhook URL to which you can post the message from outside.

A typical JSON payload will look similar to this:

  "text": "This is some random text from Virtualization and some Coffee",
  "channel": "#virtualization",
  "username": "Kristian",
  "icon_emoji": ":KristianDancing"

Once you have added the incoming WebHook to your SLACK channel, you can take advantage of this when creating alerts in OMS.

Here's an overview of the workflow and architecture

Here’s an example on how to configure an Alert in OMS to use a Webhook

And this is an example on how it could look like in SLACK, where we have different channels for different teams, depending on their area of expertise, responsibility etc.

Happy integrating!

Thursday, April 14, 2016

Why OMS is more than you think


Almost on a daily basis, customers ask me about the comparison of System Center Operations Manager (SCOM) and Microsoft Operations Management Suite (OMS).

Their first impression is that OMS is 'all about monitoring', and they are struggling to see the big picture. The purpose of this blog post is to drive awareness of what OMS is capable of, what you get, where it lives and what to do next. 

It’s almost a year since Jeremy Winter announced the Microsoft Operations Management Suite during Ignite. It got a lot of attention and people started to show interest right after the big announcement. 
Microsoft Operations Management Suite (OMS) made its entry as a Management-as-a-Service offering, delivered entirely from the cloud as a SaaS solution, helping organizations to gain insight into their operations across clouds.
With insight, we got a holistic view of the entire operations from a Windows/Linux point of view, security, identity, malware, updates, configuration changes and much more - regardless of clouds.

This was an important and strategic move by Microsoft, knowing that organizations aren’t running entirely from a single datacenter anymore and that the cloud cadence had definitively been forming the landscape and the new demand for management in an entirely new way.
It was about time to reduce the complexity of doing cloud management.

Let us start this blog post by doing a breakdown of Microsoft OMS.

Microsoft Azure

First thing first, we need to emphasize that OMS is “nothing but a set of services within Microsoft Azure Cloud”.

This is important to know and be aware of, as you will bring this into consideration when you are later planning to deploy OMS into your organization, or behalf of customers if you are a Service Provider.

Microsoft Azure has been undergoing huge changes over the last 14-16 months with the release of Azure Resource Manager (ARM) API – and the new portal ( that is built upon the new ARM model. For those of you who have been using Azure for a while, you know that the ‘previous’ Azure, also referred to as Service Management API and classic is still there, it is still available, and you can deploy and manage your resources into that model as well.
However, moving forward you will likely focus entirely on Azure in the context of Azure Resource Manager, which also brings consistency ‘down to earth’ with Microsoft Azure Stack.
The reason why I am bringing all this up is to give you a better understanding of where we are coming from and where we are going with OMS in all of this.

OMS is a set of Azure services and during its birth, it was based on the following services in Classic Azure:

·         Operational Insight
·         Azure Automation
·         Azure Site Recovery
·         Azure Backup

These were the services you got when you started with OMS.
They would surface into the OMS Workspace and gave you a consolidated view of what was going on.
However, most of the configuration had to take place on the actual resource level in the Azure portal.

With the ongoing transition to Azure Resource Manager (Microsoft is moving their Resource Providers and their resource types into the new Azure), we have seen a new birth for these Azure resources.

In Azure now, they are referred to as:

·         Log Analytics (formerly known as Operational Insight)
·         Azure Automation (same name, but new capabilities, features and much more)
·         Azure Recovery Vault (formerly known as Azure Backup and Azure Site Recovery, are now sharing the same Resource Provider within ARM)

What does this really mean?

Since these services has reached ARM, this gives you and me plenty of more opportunities!
In regards to deployment, operations, management, RBAC and much more, we can leverage ARM templates to literally instantiate whatever we need in Azure.
In other words, we can threat our OMS resources just as any first class citizen in Azure.

Each of these Resource Providers have their unique namespace with different resource types.

Log Analytics: "Microsoft.OperationalInsights/workspaces”
Azure Automation: “Microsoft.Automation/automationAccounts”
Azure Recovery Vault: "Microsoft.RecoveryServices/vaults"

Since they are now within ARM, we can take advantage of built-in RBAC capabilities, Tags, policies, resource locks and much more.

It’s also worth mentioning that OMS will likely pull on other Azure services as well, such as Storage Accounts when you want to enable diagnostics on services and ingest this into Log Analytics for further analytics and research.

Here’s an example on a design of the OMS related services in an Azure subscription.

Ok – I get it, OMS contains several native Azure services, but what do we get?

With OMS, you are not just getting state of the art service from Microsoft Azure, but you are stepping into the future leveraging management as a service. In order to understand the capabilities you are now empowered with, we will spend some time to go through the concept of using management as a service.

Management as a Service

If you head over to your preferred search engine on the internet and search for ‘management as a service’, you won’t find too much information about what this actually is.
It is not something that has been incorporated into the NIST definition of cloud computing, that contains the three universal accepted service models – such as IaaS, PaaS and SaaS.
However, management as a service can first and foremost be seen as a software as a service solution, where you can consume the services without worrying about the configuration and operation of the actual infrastructure, middleware, runtime and applications that hosts the service you are using.
If we do a comparison to the well-known System Center components, it’s easier to explain the difference and also point out some of the benefits with the new model compared to where we came from.
In the end, we will also see that there’s a really good business case for both and a window of opportunity to unlock new scenarios combining these.

Without having your management solution delivered as a service, you need to bring the following into account:

You need…

·         …the infrastructure to power the solution. This can be on-prem, service provider cloud or a public cloud running the virtual instances, storage and networking
·         …backup and DR in place
·         …customization and implementation
·         …maintenance
·         …training
·         …to apply fixes, update rollups, patches and bigger upgrades
·         …rewrite customizations and integrations
·         …upgrade network, security, databases and other dependencies

With management solutions delivered as a service, the list is shorter.

You need…

·         …customization
·         …training
·         …configuration

Of course, there might be more and there might even be less depending on the specific case and environment, but in general these are the key differences when we compare management as a service with traditional management solutions.

In addition, management as a service with OMS follow the same cloud cadence as we know from Azure and other services, so whenever there’s something new – you will get access to it immediately.
It’s literally just there.

This should not be undermined, because this is a massive opportunity for organizations to take advantage of advance technology without doing any form for implementation, verify that there’s enough capacity and everything else you normally would bring into consideration for enabling new solutions.

The fact that the infrastructure that’s required to run and operate a management solution today is normally significantly enormous should not be forgotten in this context. This will fall into place when you keep on reading about the services that OMS contains.

Microsoft OMS

You now know that OMS is a set of first-class citizen services in Azure, and that these management services are delivered to you as a Service.

It is time to crack open the OMS hood and see what’s underneath.

Log Analytics

OMS brings you the OMS Workspace which is very tightly connected with the Log Analytic resource in Azure and this is where you crunching the Big Data of yours.
Log Analytics let you bring in “whatever” data you want, coming from all kinds of data sources.

·         Windows
o   Windows Event Logs
o   Windows Performance Counters
·         Linux
o   Linux Performance Counters
·         Azure diagnostics (storage account, ingesting data from Azure tables)
·         Custom logs (yes, you define this yourself. Bring in anything)
·         Syslog

The OMS agent can be installed onto your machines regardless of location, no more stress around firewalls, domain membership and certificates – and report directly to the OMS Workspace.
If you are using System Center, you can easily get some value-added solutions by either connect the Operation Manager component to your workspace, or instruct the agents to report there as well.

Ok, I get a lot of data in there. What’s next?

OMS will also bring you some Solutions out of the box.
These solutions will give you insights into your operations – as well as recommendations on what actions you need to consider. Some solutions depends on the presence of Operations Manager, but the majority is native OMS solutions.
OMS solutions can easily be added to your workspace, using the workspace portal directly, ARM or PowerShell, and requires minimal configuration.
The solutions are delivering functionality and define additional data to be collected into the OMS repository.
An example here is the solution around Security and Audit, that brings several valuable views that quickly gives you a summary of critical information in your managed environment. You can further drill down to pinpoint the root cause, recommendation and more.
There’s plenty of more solutions we could mention, such as Key Vault, Service Fabric, AD Assessment and SQL Assessment, but I am sure you get an idea of what they will bring of value.

All the data that goes into the OMS repository can also be accessed through the Log Search – which gives you an opportunity to tap all of your data.
This is extremely powerful, letting you query any data you have, analyze it and ultimately take it to the next step by invoking a runbook in Azure Automation, or use a webhook towards a 3rd party solution.

So, with this big harvest of data, what are the common use cases after that?

With Log Analytics, you now have an insight into your operations regardless of location and runtime.
As part of this, you can create alerts and associate them with your Log Search Queries. This can fire an alert to one or more mailboxes and also be associated with Azure Automation – where only your imagination is the limit.

Azure Automation

Automation in a management solution is absolute key. With OMS, you now have the insight you want and you can literally do whatever you want with whatever you want.

Azure Automation brings you value-added capabilities you can use together with Log Analytics.

·         Runbooks (executed in Azure or through Hybrid Workers)
o   PowerShell
o   PowerShell Workflow
o   Graphical Runbooks
·         Automation DSC

You can create your state-of-the-art automation environment by importing the required modules, assets, variables and more, and get automation at scale.
In the context of OMS, Log Analytics with alerts is very often used to trigger a runbook, either in Azure or through Hybrid Worker Groups that will go ahead and do what it’s told.
This can be everything from solving a specific issue within a machine located anywhere, or perform larger operations on multiple services in Azure.
Since Automation also brings DSC to the table, you can easily register your machines with the DSC pull service, retrieve the contract and the workloads can be configured according to your desired state.

Recovery Services

Things like backup and disaster recovery is something that has haunted any person who’s been working with IT, but luckily Azure and OMS has now democratized this and made it simpler than ever.

With backup, you can protect your machines regardless of cloud, and with disaster recovery you can leverage Hyper-V Replica on your on-prem Hyper-V hosts – either with – or without System Center Virtual Manager to replicate your virtual machines to Azure or to your 2nd site on-prem.
Also, if you have physical or/and VMware infrastructure, these can be protected using the Recovery Services.
All of these operations going on with backup and recovery can be deeply integrated with the other OMS services, such as Log Analytics and Automation. Here's an example: Automated VM protection using OMS


OMS consist of many Azure services and comes as a service delivered from the cloud.
It reduces cost in many areas and brings some real time to value for your organization, users and customers.
With Management as a Service, we are about to investigate many new opportunities as we see the landscape evolve over time, the requirements are changing and increasing as well as our way of doing operations will play a role here too.
We will reduce the time spent on managing the actual management systems, and rather focus on value-added solutions.

In the next blog post, we will walk through a real-world scenario on how to leverage the capabilities of OMS to do modern management.

Stay tuned!

Wednesday, February 24, 2016

OMS: Automated VM protection using Azure Recovery Services, Automation and Log Analytics

It’s me again, blogging from a random hotel room.
Last time we had a look into the combination of OMS and Azure in order to ensure availability of a Windows Server container hosted on a virtual machine in Azure.

(The templates and scripts will be published soon).

This time, I would like to focus on another scenario I think is very useful in the combination of Azure and OMS.

Recently, the GA of Azure Recovery Services were announced under the ARM APIs, which I talked about in this post and covered some considerations to be aware of -

In this blog post, I would like to cover a common scenario that we will run into every now and then when customers wants to protect virtual machines automatically to Azure in a programmatic way.


More and more customers are looking into how they can leverage the Azure cloud today, and one of the low-hanging fruits are services that can easily be plugged into existing services on-premises that will easily enable hybrid cloud scenarios, such as Business Continuity and Disaster Recovery. These services can be harnessed directly from Azure but provides you with a more comprehensive solution when used in conjunction with the entire OMS suite – that includes these services as well.
In a couple of minutes, you can have your services and applications running healthy as ever in an Azure region once this has been configured, in case of a failover.

In this article I will not go into design principals around the recovery processes (we’ll save that one for later), but rather cover a scenario that automatically will take care of some heavy lifting for you.

Use case

Many organizations have Hyper-V running as their primary hypervisor on-premises today, powering test, dev and production virtual machines. Since Azure has been able to democratize disaster recovery with their recovery services, people are looking into how to take advantage of this in a streamlined and efficient way. My goal here is to show how you can onboard and enable protection for newly created virtual machines on a Hyper-V host that has been registered to your Recovery Services Vault in Azure, by combining events that are logged into Log Analytics in OMS, monitored by a saved search that also has an associated alert with remediation attached to it.
This will invoke a Runbook created in Azure Automation that will enable replication on newly created virtual machines on that particular Hyper-V host and replicate to Azure as the recovery site.

Breakdown of the workflow

·       A VM gets created on the Hyper-V host. Regardless of how it’s created, this will log a specific informational event in the Hyper-V-VMMS-Admin log on the host, EventID 13002 that “A new virtual machine was created”

·       The OMS agent deployed on the host will fetch this and ingest this into Log Analytics

·       A search query is defined to monitor for this specific event on this specific host

·       An alert is created and associated with this query, so an e-mail will be sent when this occur

·       A runbook is created in Azure Automation that will search for newly discovered virtual machines on the registered Hyper-V host in the Azure Recovery Vault, look for VMs that isn’t protected and enable protection for them.

·       This runbook is associated with the alert and is part of the remediation process

Getting started

Before we can enable this scenario, we have to have some prerequisites in place:

·       OMS Workspace
·       Azure Automation account
·       OMS agent installed on the applicable Hyper-V hosts
·       Azure Recovery Vault in ARM
·       Runbooks

Assuming you have all of the above except the runbooks, I’ll cover the creation of the Azure Recovery Vault and the Runbook and stitch everything together.

Creating Azure Recovery Vault with Azure Resource Manager

The following PowerShell cmdlets will enable Azure Recovery Vault in your subscription and go through the creation of the Vault:

Note: You must install and register the agent on your Hyper-V host manually in this process, before proceeding with the rest of the script.

# Login to Azure and select Azure subscription

Login-AzureRmAccount -Credential (get-credential -Credential

Select-AzureRmSubscription –SubscriptionID $subID

# Check to see if your Azure subscription is enabled with ASR resource providers

Get-AzureRmResourceProvider -ProviderNamespace "Microsoft.RecoveryServices"

Get-AzureRmResourceProvider -ProviderNamespace "Microsoft.SiteRecovery"

# Register ASR Resource Provider

Register-AzureRmResourceProvider -ProviderNamespace "Microsoft.SiteRecovery"

Register-AzureRmProviderFeature -FeatureName "betaAccess" -ProviderNamespace "Microsoft.RecoveryServices"

Register-AzureRmResourceProvider -ProviderNamespace "Microsoft.RecoveryServices"

# Verify to see that the RP is registered correctly

Get-AzureRmResourceProvider -ProviderNamespace "Microsoft.RecoveryServices"

Get-AzureRmResourceProvider -ProviderNamespace "Microsoft.SiteRecovery"

# Create a new ASR Recovery Vault

mkdir -Path "c:\ASRDemo"

$RG = "DRGroup"
$Location = "west europe"
$vault = "HyperV"
$path = "c:\ASRDemo"

New-AzureRmResourceGroup -Name $rg -Location $location

$vault = New-AzureRmRecoveryServicesVault -Name $vault -ResourceGroupName $rg -Location $location

$FilePath = Get-AzureRmRecoveryServicesVaultSettingsFile -Vault $vault -Path $path | % FilePath # changed this to make sure we get the right filepath

Import-AzureRmSiteRecoveryVaultSettingsFile -Path $FilePath

# Create a new Hyper-V Site in the ASR vault

$sitename = "KNHVSite"

New-AzureRmSiteRecoverySite -Name $sitename

# Query the job


# Generate and download registration key for the site (Copy the downloaded key to the Hyper-V host. You'll need the key to register the Hyper-V host to the site)

$SiteIdentifier = Get-AzureRmSiteRecoverySite -Name $sitename | Select -ExpandProperty SiteIdentifier

Get-AzureRmRecoveryServicesVaultSettingsFile -Vault $vault -SiteIdentifier $SiteIdentifier -SiteFriendlyName $sitename -Path $Path

# Download and install the agent on the Hyper-V host(s) from this URL:

# Verify that the Hyper-V host is registered in ASR


# Create storage account with Geo-redundant storage

$storageaccountID = New-AzureRmStorageAccount -ResourceGroupName $RG -Name "knasrdemo01" -Type Standard_GRS -Location $Location

# Create a replication policy and associate it with the protection container

$ReplicationFrequencyInSeconds = "300"
$PolicyName = “DefaultPolicy”
$Recoverypoints = 1
$storageaccountID = Get-AzureRmStorageAccount -Name "knasrdemo01" -ResourceGroupName $RG | Select -ExpandProperty Id

$PolicyResult = New-AzureRmSiteRecoveryPolicy -Name $PolicyName -ReplicationProvider “HyperVReplicaAzure” -ReplicationFrequencyInSeconds $ReplicationFrequencyInSeconds  -RecoveryPoints $Recoverypoints -ApplicationConsistentSnapshotFrequencyInHours 1 -RecoveryAzureStorageAccountId $storageaccountID

# Get the protection container and start the association

$protectionContainer = Get-AzureRmSiteRecoveryProtectionContainer

$Policy = Get-AzureRmSiteRecoveryPolicy -FriendlyName $PolicyName
$associationJob  = Start-AzureRmSiteRecoveryPolicyAssociationJob -Policy $Policy -PrimaryProtectionContainer $protectionContainer

Once this has been created and the Hyper-V host(s) are registered to Azure, you should be able to see the virtual machines on that host by executing the following cmdlet:

Get-AzureRmSiteRecoveryProtectionEntity -ProtectionContainer $protectionContainer | select friendlyname


Preparing Azure Automation

There’s a few things we need in order to successfully create and run our runbook in Azure Automation

·       Assets
o   Credentials
o   Variables
o   Modules
·       Runbook

For the assets, you can easily add the required assets by using PowerShell.
In my case, I need the credentials to login to an Azure subscription, and I also need to store the subscription ID in a variable.
This can be achieved using the following cmdlets:

Creating Automation Variable
New-AzureRmAutomationVariable -Name SubscriptionID -Encrypted $false -Value $Subscription -ResourceGroupName $RGName -AutomationAccountName $AAName

Creating Automation Credential
New-AzureRmAutomationCredential -Name AutoAdmin -ResourceGroupName $RGName -AutomationAccountName $AAName -Value $cred 

Uploading Automation Module

Normally you would use a cmdlet for uploading PowerShell modules to Azure Automation as well, but since we just want to grab a few of them directly from the available PowerShell Gallery in the AA itself, we quickly head over to the portal and grab them from there.

Install the following modules in this specific order.
Note: it can take several minutes before the modules are installed and ready. You might find yourself a cup of coffee while doing this, as some of these modules has dependencies of each other and won’t import before the dependencies has completed the import process

Creating the Runbook

Now that the prereqs are in place, it is time to author the Runbook that will do the following:


# Runbook for enabling DR on unprotected Hyper-V VMs

$Admin = Get-AutomationPSCredential -Name AzureAdmin
$Subscription = Get-AutomationVariable -Name SubscriptionID

Login-AzureRmAccount -Credential $Admin

Select-AzureRmSubscription -SubscriptionId $Subscription

# Fetching some variables for this particular setup

$RG = "DRGroup"
$Location = "west europe"
$vault = "HyperV"
$sitename = "KNHVSite"
$vault = Get-AzureRmRecoveryServicesVault -Name $vault -ResourceGroupName $rg
$storageaccount = "knasrdemo01"

# Creating a temp directory to store the VaultSettingsFile

$tempFileName = $env:TEMP

$FilePath = Get-AzureRmRecoveryServicesVaultSettingsFile -Vault $vault -Path $tempFileName | % FilePath # changed this to make sure we get the right filepath

Import-AzureRmSiteRecoveryVaultSettingsFile -Path $FilePath

$SiteIdentifier = Get-AzureRmSiteRecoverySite -Name $sitename | Select -ExpandProperty SiteIdentifier

Get-AzureRmRecoveryServicesVaultSettingsFile -Vault $vault -SiteIdentifier $SiteIdentifier -SiteFriendlyName $sitename -Path $tempFileName

$protectionContainer = Get-AzureRmSiteRecoveryProtectionContainer

# Get Storage Account

$storageaccountID = Get-AzureRmStorageAccount -Name $storageaccount -ResourceGroupName $RG | Select -ExpandProperty Id

# Get Recovery Policy

$policy = Get-AzureRmSiteRecoveryPolicy

# Enabling VMs for protection

$protectionEntity = Get-AzureRmSiteRecoveryProtectionEntity -ProtectionContainer $protectionContainer | Where-Object {$_.FriendlyName -like "*asr*" -and $_.ProtectionStatus -eq "Unprotected"}

foreach ($entity in $protectionEntity)
        if ($protectionEntity.ProtectionStatus -eq "Unprotected")
            Write-Output "They aren't protected!"
            Set-AzureRmSiteRecoveryProtectionEntity -ProtectionEntity $entity -Policy $Policy -Protection Enable -RecoveryAzureStorageAccountId $storageaccountID -OS Windows -OSDiskName $protectionEntity.Disks[0].Name -Verbose
            Write-Output "They were protected already :-)"

If you want to use this in your environment, ensure you are changing the variables to meet your needs.

Assuming you already have the host registered to the Workspace, you should do the following steps to be able to get the information you are looking for to enable this scenario where you want to leverage the runbook to protect newly created VMs.

Adding logs to OMS

In the OMS workspace, Click on ‘Settings’

Navigate to ‘Data’ and click on ‘Windows Event Logs’

Add the following log that will contain the information about creation of virtual machines on the host

Ensure that Error, Warning and Information is selected

Note: OMS doesn’t care about what has already happened, so only new events in this log will appear in OMS.

Next, go back and drill into ‘Log Search’

I use the following search to pinpoint the specific EventID and the Hyper-V host

EventID=13002 host11 | Select Computer, Activity, TimeGenerated, Message, EventLog

I have saved the search and categorized it as ‘Hyper’V.

Now, I want to enable alerting on this search, so I click on the search and then on the ‘Alert’ button

Assign a name to the alert and specify when the query should run and when an alert should be generated.

I then specify the recipient of the alert and give it a name.

As a last step, I connect the alert with the newly created Runbook in Azure Automation and ensure that it will be executed by using an Azure worker and click save.

Creating a new VM to trigger the alert

Heading over to my Hyper-V host I created some new virtual machines.

Coffee time

Since OMS will use this search query every 15 mins, I had enough time to make myself some coffee while waiting for the e-mail to drop in my inbox


Once the search query detect a new event, the alert is triggered and an e-mail is fired away to my inbox.


This should invoke the associated runbook for remediation, and when I check into the Job view in Azure, I can see that it has successfully been executed and also the output that tells me that replication has now been enabled on the unprotected VMs.

Verifying the remediation

Using PowerShell, I can access my Recovery Vault and check to see which VMs are in the process of being protected in Azure by using the following cmdlet:

Get-AzureRmSiteRecoveryProtectionEntity -ProtectionContainer $protectionContainer | select FriendlyName, ProtectionStateDescription

The output shows that several machines are already protected while the newly created VM is in the process of doing an initial replication

FriendlyName ProtectionStateDescription       
------------ --------------------------       
ASRGEN2-04   Protected                        
ASRGEN2-02   Protected                        
ASRGEN2-01   Initial replication is in progress
ASRGEN2-03   Protected                        

Closing note

This was yet another blog post that shows some of the capabilities of combining OMS, Azure and Azure Services together.
Moving forward, I will focus more on some of these scenarios to show where we have some gaps today, and how you can overcome those gaps with a little effort in engineering.

By the end of the day, we can more or less achieve whatever we want as long as there’s an API for it, and that’s exactly what this blog post was showing.