Category Archives: Azure

Using Custom PowerShell Modules in Azure Functions

Written by Tao Yang

Like many other fellow MVPs, I have started playing with Azure Functions over the last few weeks. Although Azure Functions are primarily designed for developers and supports languages such as C#, Node.JS, PHP, etc. PowerShell support is currently in preview. This opens a lot of opportunities for IT Pros. My friend and fellow CDM MVP David O’Brien has written some really good posts on PowerShell in Azure Functions (https://david-obrien.net/). Although the PowerShell runtime in Azure Functions comes with a lot of Azure PowerShell modules by default (refer to David’s post here for details), these modules are out-dated, and some times, we do need to leverage other custom modules that are not shipped by default.

While I was trying to figure out a way to import custom modules into my PowerShell Azure Functions, I came across this post showing me how to upload 3rd party assemblies for C# functions: http://www.robfox.nl/2016/04/27/referencing-external-assemblies-azure-functions/. So basically for adding assemblies for C#, you will need to create a folder called “bin” under your function root folder, and upload the DLL to the newly created folder using a FTP client. I thought I’d give this a try for PowerShell modules, and guess what? it worked! I’ll use one of my frequently used module called GAC as an example in this post and work through the process of how to prepare the module and how to use it in my PowerShell code.

01. I firstly download the Gac module from the PowerShell Gallery (https://www.powershellgallery.com/packages/Gac/1.0.1):

02. Make sure the Azure Functions App Service has the deployment credential configured

image

03. FTP to the App Service using the deployment credential configured in the preview step, create a “bin” folder under the Azure Functions folder (“/site/wwwroot/<Azure Functions Name>”) and upload the module folder:

image

04. In Azure Functions, launch the Kudu console

image

05. Identify the PowerShell module file system path in Kudu. The path is D:\home\site\wwwroot\<Azure Function Name>\bin\<PS module name>\<PS module version>

image

06. By default, the PowerShell runtime is configured to run on 32-bit platform. If the custom module requires 64-bit platform, you will need to configure the app setting and set the Platform to 64-bit

image

image

Now that the module is uploaded, and because the module is not located in a folder that’s listed in the PSModulePath environment variable, we have to explicitly import the module manifest (.psd1 file) before using it. For example, I have created a function with only 2 lines of code as shown below:

The “Get-GacAssembly” cmdlet comes from the Gac PowerShell module. As the name suggests, it lists all the assemblies located in the Gac (Global Assemblies Cache). When I call the HTTP trigger function using Invoke-WebRequest, you’ll see the assemblies listed in the logs window:

image

image

I have also tested stopping and restarting the Azure App Service, and I can confirm the module files stayed at the original location after the restart based on my tests.

This concludes my topic for today. I have few other really cool blogs in the pipeline for using PowerShell in Azure Functions, stay tuned.

Scripting Azure Automation Module Imports Directly from MyGet or PowerShell Gallery

Written by Tao Yang

There are few ways to add PowerShell modules to Azure Automation accounts:

1. Via the Azure Portal by uploading the module zip file from local computer.

image

2. If the module is located in PowerShell Gallery, you can push it to your Automation Account directly from PowerShell Gallery.

image

3. Use PowerShell cmdlet New-AzureRmAutomationModule from the AzureRM.Automation module.

One of the limitation of using New-AzureRMAutomationModule cmdlet is, the module must be zipped and located somewhere online that Azure has access to. You will need to specify the location by using the –ContentLink parameter. In the past, in order to script the module deployment, even when the module is located in PowerShell Gallery, I had to save the module to a place where my Automation Account has access to (such as an Azure blob storage, or creating a release in a public Github repo).

Tonight, I was writing a script and I wanted to see if I can deploy modules to my Automation Account directly from a package repository of my choice – other than PowerShell Gallery, I also have a private MyGet feed that I use for storing my PowerShell modules.

It turned out to be really easy to do so, only took me few minutes to figure out how. I’ll use a module I wrote in the past called “SendEmail” as an example. It is published in both PowerShell Gallery, and my private MyGet feed.

Importing from PowerShell Gallery

the URL for this module in PowerShell Gallery is: https://www.powershellgallery.com/packages/SendEmail/1.3

The –ContentLink URI that we need to pass to the Add-AzureRmAutomationModule cmdlet would be:

https://www.powershellgallery.com/api/v2/package/SendEmail/1.3.

As you can see, all you need to do is to add “api/v2/” in the URI. The PowerShell command would be something like this:

Importing from a private MyGet feed

For a private MyGet feed, you can access it by embedding the API key into the URL:

image

The URL for my module would be: “http://www.myget.org/F/<Your MyGet feed name>/auth/<MyGet API Key>/api/v2/package/<Module Name>/<Module Version>

i.e. for my SendEmail module, the PowerShell command would be something like this:

Importing from a public MyGet feed

If the module is located in a public MyGet feed, then the API key is not required. the URI for the module would be very similar to PowerShell Gallery, you will just need to embed “api/v2/” in to the original URI:

‘https://www.myget.org/F/<MyGet Public Feed Name>/api/v2/package/<Module Name>/<Module Version>

the PowerShell script would be something like this:

Calculating SQL Database DTU for Azure SQL DB Using PowerShell

Written by Tao Yang

over the last few weeks, I have been working on a project related to Azure SQL Database. One of the requirements was to be able to programmatically calculate the SQL Database DTU (Database Throughput Unit).

Since the DTU concept is Microsoft’s proprietary IP, the actual formula for the DTU calculation has not been released to the public. Luckily, Microsoft’s Justin Henriksen has developed an online Azure SQL DB DTU Calculator, you can also Justin’s blog here. I was able to use the web service Justin has developed for the online DTU Calculator, and I developed 2 PowerShell functions to perform the calculation by invoking the web service. The first function is called Get-AzureSQLDBDTU, which can be used to calculate DTU for individual databases, the second function is called Get-AzureSQLDBElasticPoolDTU, which can be used to calculate DTU for Azure SQL Elastic Pools.

Obviously, since we are invoking a web service, the computer where you are running the script from requires Internet connection. Here’s a sample script to invoke the Get-AzureSQLDBDTU function:

Note: you will need to change the variables in the ‘variables’ region, the $LogicalDriveLetter is the drive letter for the SQL DB data file drive.

The recommended Azure SQL DB service tier and coverage % can be retrieved in the ‘Recommendations’ property of the result:

image

the raw reading for each perf sample can be retrieved in the ‘SelectedServiceTiers’ property of the result:

image

Lastly, thanks Justin for developing the DTU calculator and the web service, and pointing me to the right direction.

HybridWorkerToolkit PowerShell Module Updated to Version 1.0.3

Written by Tao Yang

Few days ago, I published a PowerShell Module to be used on Azure Automation Hybrid Workers called HybridWorkerToolkit. You can find my blog article HERE.

Yesterday, my good friend and fellow CDM MVP Daniele Grandini (@DanieleGrandini) gave me some feedback, so I’ve updated the module again and incorporated Daniele’s suggestions.

This is the list of updates in this release:

  • A new array parameter for New-HybridWorkerEventEntry called “-AdditionalParameters”. This parameter allows users to insert an array of additional parameters to be added in the event data:

SNAGHTMLb6e7547

  • A new Boolean parameter for New-HybridWorkerEventEntry called “-LogMinimum”. This is an optional parameter with the default value of $false. When this parameter is set to true, other than the user specified messages and additional parameters, only the Azure Automation Job Id will be logged as event data:

image

As we all know, we pay for the amount of data gets injected into our OMS workspace, this parameter allows you to minimise the size of your events (thus saves money on your OMS spending).

I have published this new release to both GitHub and PowerShell Gallery.

New PowerShell Module HybridWorkerToolkit

Written by Tao Yang

HybridWorkerToolkit23/04/2016 Update: released version 1.0.3 to GitHub and PowerShell gallery. New additions documented in this blog post.

21/04/2016 Update: updated GitHub and PowerShell gallery and released version 1.0.2 with minor bug fix and updated help file.

Introduction

Over the last few days, I have been working on a PowerShell module for Azure Automation Hybrid Workers. I named this module HybridWorkerToolkit.

This module is designed to run within either a PowerShell runbook or a PowerShell workflow runbook on Azure Automation Hybrid Workers. It provides few functions that can be called within the runbook. These activities can assist gathering information about Hybrid Workers and the runbook runtime environment. It also provides a function to log structured events to the Hybrid Workers Windows Event Logs.

My good friend and fellow MVP Pete Zerger posted a method he developed to use Windows event logs and OMS as a centralised logging solution for Azure Automation runbooks when executed on Hybrid Workers. Pete was using the PowerShell cmdlet Write-EventLog to log runbook related activities to Windows event log and then these events will be picked up by OMS. Log Analytics. This is a very innovative way of using Windows event logs and OMS. However, the event log entries written by Write-EventLog are not structured are lacking basic information about your environment and the job runtime.  Couple of weeks ago, another friend of mine, Mr. Kevin Holman from Microsoft also published a PS script that he used to write to Windows event logs with additional parameters.

So I combined Pete’s idea with Kevin’s script, as well as some code I’ve written in the past for Hybrid Workers, and developed this module.

Why do we want to use Windows Event logs combined with OMS for logging runbook activities on Hybrid workers? As Pete explained on this post, it provides a centralised solution where you can query and retrieve these activity logs for all your runbooks from a single location. Additionally, based on my experience (and also confirmed with few other friends), is that when you use Write-Verbose or Write-Output in your runbook and enabled verbose logging, the runbook execution time can increase significantly, especially when loading a module with a lot of activities. Based on my own experience, I’ve seen a runbook that would normally takes a minute or two to run with verbose logging turned off ended up ran over half an hour after I enabled verbose logging. This is another reason I’ve developed this module so it gives you an alternative option to log verbose, error, process and output messages.

Functions

This module provides the following 3 functions:

  • Get-HybridWorkerConfiguration
  • Get-HybridWorkerJobRuntimeInfo
  • New-HybridWorkerRunbookLogEntry

Note: Although the job runtime are different between PowerShell runbooks and PowerShell Workflow runbooks, I have spent a lot of time together with Pete making sure we can use these activities exactly the same ways between PowerShell and PowerShell workflow runbooks.

Get-HybridWorkerConfiguration

This function can be used to get the Hybrid Worker and Microsoft Monitoring Agent configuration. A hash table is returned the following configuration properties retrieved from Hybrid Worker and MMA agent:

  • Hybrid Worker Group name
  • Automation Account Id
  • Machine Id
  • Computer Name
  • MMA install root
  • PowerShell version
  • Hybrid Worker version
  • System-wide Proxy server address
  • MMA version
  • MMA Proxy URL
  • MMA Proxy user name
  • MMA connected OMS workspace Id

Get-HybridWorkerJobRuntimeInfo

This function retrieves the following information about the Azure Automation runbook and the job run time. They are returned in a hashtable:

  • Runbook job ID
  • Sandbox Id
  • Process Id
  • Automation Asset End Point
  • PSModulePath environment variable
  • Current User name
  • Log Activity Trace
  • Current Working Directory
  • Runbook type
  • Runbook name
  • Azure Automation account name
  • Azure Resource Group name
  • Azure subscription Id
  • Time taken to start runbook in seconds

New-HybridWorkerRunbookLogEntry

This function can be used to log event log entries. By default, other than the event message itself, the following information is also logged as part of the event (placed under the <EventData> XML tag:

  • Azure Automation Account Name
  • Hybrid Worker Group Name
  • Azure Automation Account Resource Group Name
  • Azure Subscription Id
  • Azure Automation Job Id
  • Sandbox Id
  • Process Id
  • Current Working Directory ($PWD)
  • Runbook Type
  • Runbook Name
  • Time Taken To Start Running in Seconds

This function also has an optional Boolean parameter called ‘-LogHybridWorkerConfig’ When this parameter is set to $true, the event created by this function will also contain the following information about the Hybrid Worker and MMA:

  • Hybrid Worker Version
  • Microsoft Monitoring Agent Version
  • Microsoft Monitoring Agent Install Path
  • Microsoft Monitoring Agent Proxy URL
  • Hybrid Worker server System-wide Proxy server address
  • Microsoft OMS Workspace ID

Sample Runbooks

Sample PowerShell Runbook:

Sample PowerShell Workflow Runbook

As you can see, the way to call these functions between PowerShell and PowerShell Workflow runbooks are exactly the same.

Hybrid Worker Configuration output:

SNAGHTML40e35ad

Hybrid Worker Job Runtime Info output:

SNAGHTML40f4d28

Event generated (with basic information / without setting –LogHybridWorkerConfig to $true):

SNAGHTML4159a60[4]

Event generated (whensetting –LogHybridWorkerConfig to $true):

SNAGHTML4150515

Consuming collected events in OMS

Once you have collected these events in OMS, you can use search queries to find them, and you can also create OMS alerts to notify you using your preferred methods.

Searching Events in OMS

i.e. I can use this query to get all events logged by a particular runbook:

Type=Event “RunbookName: Test-HybridWorkerOutput-PSW”

image

or use this query to get all events for a particular job:

Type=Event “JobId: 73A3827D-73F8-4ECC-9DE1-B9340FB90744”

image

OMS Alerts

i.e. if I want to create an OMS alert for any Error events logged by New-HybridWorkerRunbookLogEntry, I can use a query like this one:

Type=Event Source=AzureAutomation?Job* EventLevelName=Error

image

image

Download / Deploy this module

I have published this module on Github as well as PowerShell Gallery:

GitHub Repository: https://github.com/tyconsulting/HybridWorkerToolkit

PowerShell Gallery:  http://www.powershellgallery.com/packages/HybridWorkerToolkit/1.0.3

Credit

I’d like to thank Pete and Kevin for the ideas in the first place, also I’d like to thank Pete, Jakob Svendsen, Daniele Grandini and Kieran Jacobsen for the testing and feedback!

A Major Update for the SharePointSDK PS Module

Written by Tao Yang

Sharepoint-2013-LogoIntroduction

This blog has been a bit quiet over the last few weeks. This is because I have been really really busy. I have spent a lot of time working on an updated version of the SharePointSDK PS module. Just in case you have not played with this module, here’s some background info:

Just over a year ago, I posted a PowerShell / SMA / Azure Automation module on this blog called SharePointSDK. Few months ago, I have also published this module on Github and PowerShell Gallery. This module was designed to help automate operations around SharePoint lists (i.e. CRUD operations for SharePoint list items). Coupling SharePoint (both On-prem version or SharePoint Online) with Azure Automation (or even SMA) is becoming more and more common in the community when designing automation solutions. This module provides ways for your automation runbooks to interact with SharePoint list items.

However, I believe the original 1.0 release was really basic, and there are still a lot I’d like to cover in this module. Now I’m pleased to announce the new major release (version 2.0.1) is now available on both Github and PowerShell Gallery.

What’s New?

I’ve included the following updates in version 2.0.1:

  • 26 additional functions!
  • Updated the SharePoint CSOM (Client Component SDK) DLLs to the latest version in the module.
  • Created a separate help file for the module. Get-Help is now fully working
  • Various bug fixes

The table below lists all the functions that are shipped in the current release (version 2.0.1):

Function Description Released on Version
Import-SPClientSDK Load SharePoint Client SDK DLLs 1.0
New-SPCredential Create a SharePoint credential that can be used authenticating to a SharePoint (online or On-Premise) site. 1.0
Get-SPServerVersion Get SharePoint server version. 1.0
Get-SPListFields Get all fields from a list on a SharePoint site. 1.0
Add-SPListItem Add a list item to the SharePoint site. 1.0
Get-SPListItem Get all items from a list on a SharePoint site or a specific item by specifying the List Item ID. 1.0
Remove-SPListItem Delete a list item to the SharePoint site. 1.0
Update-SPListItem Update a list item to the SharePoint site. 1.0
Get-SPListItemAttachments Download all attachments from a SharePoint list item. 1.0
Add-SPListItemAttachment Upload a file as a SharePoint list item attachment. 1.0
Remove-SPListItemAttachment Remove a SharePoint list item attachment. 1.0
New-SPList Create a new list on the SharePoint site. 2.1
Remove-SPList Remove a list from the SharePoint site. 2.1
Get-SPList Get a list from the SharePoint site. 2.1
New-SPListLookupField Create a new lookup Field for a SharePoint list. 2.1
New-SPListCheckboxField Create a new checkbox Field for a SharePoint list. 2.1
New-SPListSingleLineTextField Create a new single line text Field for a SharePoint list. 2.1
New-SPListMultiLineTextField Create a new Multi-line text Field for a SharePoint list. 2.1
New-SPListNumberField Create a new number Field for a SharePoint list. 2.1
New-SPListChoiceField Create a new choice Field for a SharePoint list. 2.1
New-SPListDateTimeField Create a new date time Field for a SharePoint list. 2.1
New-SPListHyperLinkField Create a new Hyperlink or Picture Field for a SharePoint list. 2.1
New-SPListPersonField Create a new Person or Group Field for a SharePoint list. 2.1
Remove-SPListField Remove a Field from a SharePoint list. 2.1
Update-SPListField Update a SharePoint list field. 2.1
Set-SPListFieldVisibility Set the visibility of a SharePoint list field. 2.1
Get-SPGroup Get a single group or all groups from the SharePoint site. 2.1
New-SPGroup Create a new SharePoint group. 2.1
New-SPGroupMember Add an user to a SharePoint group. 2.1
Remove-SPGroupMember Remove an user from a SharePoint group. 2.1
Clear-SPSiteRecycleBin Empty the SharePoint site recycle bin. 2.1
Get-SPSiteTemplate Get avaialble Site Template(s) from the SharePoint site. 2.1
New-SPSubSite Create a new SharePoint sub site. 2.1
Get-SPSubSite Get all SharePoint sub sites from a root site. 2.1
Remove-SPSubSite Delete a SharePoint sub site. 2.1
Add-SPListFieldToDefaultView Add a SharePoint list field to the list default view. 2.1
Remove-SPListFieldFromDefaultView Remove a SharePoint list field to the list default view. 2.1

As you can see, the previous version has shipped 11 functions, and 26 additional functions have been added to the current release (2.0.1). With this release, other than the SharePoint list items, we are also able to manage SharePoint lists, list fields, groups, group members, and even subsites. I have included functions to create what I believe the most common list fields (as highlighted below):

image

Future Plans

At this stage, there are still few things I’d like to cover in this module but I simply do not have time. Since I think I have reached another milestone at this stage, I have decided to release this version now and roll other ideas into the future release.

In the second week of March, I will be presenting at SCU APAC (Kuala Lumpur, Malaysia) and Australia (Melbourne).  I am presenting 2 identical sessions at both locations:

  • Be a hero and save the day with OMS and Power BI (Co-present with CDM MVP Alex Verkinderen)
  • Automation for IT Ops with OMS and Azure Automation (Co-present with CDM MVP Pete Zerger)

As part of the demos I have prepared for the Azure Automation session with Pete, I will cover how I’m using this module as part of my automation solutions.

After SCU, I am planning to write another blog post for my Automating OpsMgr series which will cover one of the our SCU demos (I know, it has been a long time since my last post for that series). I will also cover this module in more details in this upcoming blog post.

Download the Module

So for now, if you’d like to give this module a try, you can find it from both GitHub and PowerShell Gallery. All functions are fully documented in the help file. You can access the help document as well as code examples using Get-Help with –Full switch.

Lastly, if you have any feedback, or suggestions for future releases, please feel free to drop me an email.

This is all I have to share for today, until next time, happy automating Smile.

Azure Automation Runbook: Test-OMSAlertRemediation

Written by Tao Yang

Couple of weeks ago, I published a post titled OMS Alerting Walkthrough. I mentioned in the post that I have written a test runbook called Test-OMSAlertRemediation that extracts information from the OMS alert JSON input sends to you via email.

Once you have created this rnbook in your Azure Automation account, you can use it as the remediation runbook for any OMS alerts.

Source code:

Requirements

This runbooks uses the SendEmail module for sending emails. You can install it to your automation account directly from PowerShell gallery(https://www.powershellgallery.com/packages/SendEmail/), or download the source code from GitHub(https://github.com/tyconsulting/SendEmail_PowerShellModule). Once the module is deployed to your Automation Account, you will then need to create a connection with type “SMTPServerConnection” with the name “SMTPNotification”:

SNAGHTML2d83c96

You will also need to place your email address in the last line of the runbook.

The email below is a sample of what this runbook produces:

SNAGHTML2e18888

Hopefully this runbook would help you when you are designing your OMS alerting solutions.

OMS Alerting Walkthrough

Written by Tao Yang

imageIntroduction

Earlier today, the OMS product team has announced the OMS Alerting feature has entered Public Preview. This is indeed an exciting news and it is another good example that Microsoft is working very hard to close the gaps between OMS and the existing On-Prem monitoring solution – System Center Operations Manager. Alex Frankel from the OMS product team has already given a brief introduction on this feature from the announcement blog post. In this post, I will demonstrate how I used this feature to alert and auto-remediate an issue detected in my lab environment.

Background

Few months ago, I have lost my lab OpsMgr management group completely due to hardware failures. After I replaced faulty hardware and built a brand new management group, I re-configured all the servers in my lab reported to the new management group. However, I then started getting many “Failed to enable Advisor Connector on the computer” alerts in my OpsMgr environment:

image

These alerts were raised because I did not unregister these agent computers from the previous management group (I couldn’t because it was dead), as explained in this forum thread. To fix this issue, on each OpsMgr agent, I must delete several registry keys, reset a regkey  values and then restart the health service.

Since My OpsMgr management group is connected to an OMS workspace, and I have enabled Alert Management solution (so all OpsMgr alerts are also uploaded into OMS), I have configured using the new OMS alerting feature to automatically remediate this error for me.

In order to configure the alerting and remediation for this OpsMgr alert, I need to following components:

  • OpsMgr management group connected to OMS
  • OMS Alert Management solution enabled
  • OMS Automation solution (Azure Automation) enabled
  • At least one Azure Automation Hybrid Worker is configured (because I need to target the remediation runbook to on-premises lab servers.
  • OMS Alerting and Alert remediation feature enabled

Creating Azure Automation Runbook

So first things first, I must create and publish the remediation runbook in the Azure Automation account before we can select it when we create the OMS alert. Although we cannot configure what parameters to pass into the runbook, the OMS alert passes the search result and some meta data into the runbook in JSON format (I will show it later). So based on my experience, in order to make the runbooks re-useable, we can some optional input parameters for the runbook, and inside the runbook, check if any of these optional parameters are null, then retrieve the value elsewhere (i.e. Azure Automation variable and credential assets).

In this case, I have created a PowerShell based runbook called Remove-SCAdvisorRegistration, the code is listed below:

Now, let’s fast forward a little bit and explain what does the input parameter from OMS alert look like. When we have configured Alert remediation during the OMS alert creation, a webhook for the runbook is automatically created. OMS uses this webhook to start the runbook. It passes a parameter called “WEBHOOKDATA”, which is in JSON format into the runook. You can see the actual input by clicking on the INPUT tile in the runbook job execution history:

image

If you copy and paste this input into a text editor such as Notepad++ and format it as a JSON document, it looks like this:

image

As you can see, the “SearchResults” contains 3 elements:

  • id
  • __metadata
  • Value

The Value property is where you can retrieve the search result, and it is defined as an array. When I was writing the remediation runbook, I was able to get the offending OpsMgr agent computer name from the “SourceDisplayName” field of each item in the “Value array”.

Now the runbook is created, make sure it is published before we heading back to the OMS portal start creating the alert. Please note that we will have to come back and revisit this runbook after the alert is created.

Creating OMS Alert

The search query that I’m using for this alert is:

Type=Alert AlertState=New AlertName=”Failed to enable Advisor Connector on the computer.”

image

I’m creating the alert with the following parameters:

  • Name: Alert – Failed to enable Advisor on computer
  • Schedule: every 15 minutes
  • Generate Alert when: Greater than 0
  • Over the time window: 15 minutes
  • Send Email Notification: Yes
  • Email Subject: Failed to enable Advisor on computer alert
  • Email Address: <Your email address>
  • Enable Remediation: Yes
  • Remediation Runbook: Remove-SCAdvisorRegistration

SNAGHTML1a29c296

After the alert is saved, you will be able to see it in the Settings/Alerts page:

image

Reconfiguring Runbook Webhook

In this example, because the runbook must be executed against a Hybrid Worker group (as we are targeting computers in on-prem network), I must reconfigure the webhook (created by OMS alert) to target a Hybrid Worker group (instead of the default config of targeting Azure workers). You can do so by going to the webhook parameters section, and choose Hybrid Worker group from the drop down list:

image

Note:

Please do not modify any other input parameters for the webhooks created by OMS alerts. If you do, the changes you’ve made won’t be saved in Azure Automation. Based on my experience, the only change you can modify for the webhook is the “Run on” parameter (Azure VS. Hybrid Worker).

From now on, this alert will be executed every 15 minutes, and search for the result (based on the search query) created within the last 15 minutes. If the number of records returned from the search is greater than 0 (as we configured), you will get an email similar to this one:

image

The OMS alert will also kick off the remediation runbook via the webhook. Because I have enabled verbose logging for this runbook, I was able to see some additional verbose messages:

image

Additional Resources

Test-OMSAlertRemediation Runbook

I have also written a test runbook called Test-OMSAlertRemediation that you can use for any OMS alerts. This extracts information from the JSON input and send to you via email. It should be very helpful for you when you are authoring real remediation runbooks (so you know what kind of input data you can play with). I will publish it in the next blog post as it’s getting closer to mid night now.

New OMS Ebook – Inside the MS Operations Management Suite

Over the last few months, I have been working with Pete Zerger, Stanislav Zhelyazkov and Anders Bengtsson on a free ebook for OMS. OMS Alerting is also explained in more details in this book. It will be released very soon, so stay tuned!

OMS_Book_Anncmt

Azure Automation Runbook: New-FakeVirus

Written by Tao Yang

Often when you are playing with security related products, you would need to create dummy/fake viruses on your computers. The most common way to do this is to create a EICAR test file (https://en.wikipedia.org/wiki/EICAR_test_file).

I have used this method in the past when testing the Microsoft Forefront Endpoint Protection management pack in OpsMgr. Today I needed to use it again when I was preparing a demo for the OMS Malware Assessment. I thought, why not make an Azure Automation runbook that automatically create the EICAR test file for me on remote computers, so I can trigger it manually or schedule it to run on a regular basis? So here’s what I came up with.

CAUTION: Use it at your own risk! And obviously, this runbook is designed to run on hybrid workers Smile.

Runbook: New-FakeVirus

You will need to specify 3 optional input parameters:

image

  • Credential: The name of the credential asset saved in your Azure Automation account – If you need to use an alternative credential to connect to the target computer (via WMI)
  • ComputerName: The target computer of where the fake virus is going to be created, if not specified, it will be created on the runbook worker itself.
  • Folder: the folder of where the file is going to be created on the target computer. If not specified, the runbook will use the System environment variable %TEMP%.

Runbook Output:

image

If your Windows Defender or System Center Endpoint Protection (SCEP) is working correctly, you will see this on your target computer straightaway:

image

If the target computer is monitored by OpsMgr and you have imported the Forefront Endpoint Protection (FEP) 2010 MP, you’ll get an alert:

image

And you will also see in the OMS Malware Assessment dashboard shortly:

image

image

Start A Child Runbook From Azure Automation Hybrid Worker on the Same Hybrid Worker Group

Written by Tao Yang

Today I was writing a PowerShell runbook (let’s call it Runbook A) that’s designed to run on on-prem hybrid workers. At the end of Runbook A, I needed to kick off another runbook (let’s call it Runbook B) that must run on the same Hybrid Worker group. Because I don’t want to hardcode the Hybrid Worker group name in the script (or using an Automation variable), I wrote a very simple function that returns the Hybrid Worker configuration (including the Hybrid Worker group name) from registry if runs on a Hybrid Worker.

To use it, simply place the function shown below in the parent runbook (Runbook A in this case), and call this function to retrieve the Hybrid Worker configuration.

Function:

SNAGHTML2f76e97b

Code Sample:

Note:

The Get-HybridWorkerConfig function would return $null value if the computer is not a Hybrid Worker.