#azure

Upgrading the omsagent on Linux

alistairl, Leave a comment

We have really good license coverage in the Innovations Team that I am part of and recently we had Microsoft 365 Defender reporting high exposure on two linux servers. In our case these were two syslog forwarders that we use to give Sentinel visibility of our FortiGate virtual appliances. We use the latter to offer services to IaaS workloads hosted in Azure.

Looking at the device specific recommendations it told us “Update Microsoft omsagent for Linux”. My immediate reaction was to log on to each server and run the only command I know:

sudo yum update

This was fine on one server, the other had run out of space. To cut a long story short, I found that a couple of Azure VM Extensions had failed to install and in complaint were filling the boot disk with logs. I removed the offending extensions and this got space back.

Unfortunately the update made no difference. I’ll clarify what my goal was here; to get the security recommendation in Microsoft 365 Defender to go away. This is a process that can take some days depending on the update cycle between the enrolled Linux Machine and the process that generates the security recommendations. Short story – updating the server did not remove the recommendation to Update Microsoft omsagent for Linux.

So I went hunting for more specific instructions and found information on the Log Analytics agent (aha, so that is what omsagent is!) documentation page on upgrading the Linux agent. This directed me to run the following command (per documentation on 29th March 2022):

sudo sh ./omsagent-*.universal.x64.sh --upgrade

I tried this on both servers, in one case it could not find the script, in the other it appeared to run fine but exited with status 0 (I didn’t know if this was good or bad). It turned out that the script location was different on the two servers and I found the script in a different place. It ran in a similar fashion with a big long list out output and status 0 (still none the wiser).

I checked in again and Microsoft 365 Defender still recommended that we Update Microsoft omsagent for Linux.

So I had a think, and got rid of some of my Linux related caution (I’m not a confident Linux admin) and found myself at the home / source of the agent in GitHub. By this time I had a few tabs open in Edge and I did some command modification to get some context. I ran the following:

rpm -qa | grep omsagent

And the output of this suggested returned omsagent-1.13.35-0.x86_64 which I took to mean I was looking at a server with v1.13.35 whereas at the time of writing, GitHub had a latest release of v1.14.9 . So running the command above had not upgraded to the latest version. So I had assumed incorrectly, my hypothesis then became that I need to run the latest version in upgrade mode, rather than that an older version would automatically update itself to the latest.

So working through the readme on the omsagent for Linux GitHub page I copied the URL for the latest OMS Agent for Linux (64-bit) and ran this with the wget command to download the script i.e.

wget https://github.com/microsoft/OMS-Agent-for-Linux/releases/download/OMSAgent_v1.14.9-0/omsagent-1.14.9-0.universal.x64.sh

Then I ran the new version that I had just downloaded with the upgrade switch thus:

sudo sh omsagent-1.14.9-0.universal.x64.sh --upgrade

This produced an even longer output with lots of messages. When I checked Microsoft 365 Defender that recommendation had been removed for the two syslog servers in question. Job Done!

Epilogue

What I also found out is that the upgrade scenarios for the Log Analytics Agent are interesting and there is interaction with extensions etc. Azure Virtual Machine Extensions also have a short list of very specific events that trigger an upgrade (if the setting is available and set) and that this list is quite small and fairly rare (e.g. sku changes). The choices now available for vulnerability scanning get better each day, in my case following through on those recommendations for Linux can be tricky!

Fun with PowerShell, Azure Automation and Microsoft Teams

alistairl, Leave a comment

I’m currently working on a solution at work which is ultimately a contribution to our process of trying to keep on top of our proof of concept environments usage of networking and in particular ip address ranges. We have a rolling set of Azure Virtual Networks that vary in size from a class C to the occasional class A when we have a silly scale HPC or Kubernetes CNI requirement for a gazillion addresses in a big subnet.

The solution is coming together in very small building blocks and this post is to provide me (and you interwebs folks) with a reference to the filter syntax for List all teams in Microsoft Teams using Microsoft Graph.

Although the automation method shouldn’t really matter for what is effectively a big REST API, you know how it is when you have to translate syntax and fiddle around with quotation marks and things. Anyway, to cut a long story short the rough PowerShell script for List all teams in Microsoft Teams in PowerShell is:

# PowerShell to list all teams in your tenant
# Assumes you have set up your certificate authentication
$appId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
$tenantId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
$cert = Get-AutomationCertificate -Name 'AzureAutomationCertificate'

# Magic we are doing needs beta apis for the filter to work
Select-MgProfile -Name "beta"

# Authenticate to MS Graph
Connect-MgGraph -ClientID $appId -TenantId $tenantId -Certificate $cert

# Get list of Teams i.e. Groups with the special resource provisioning options set
$teams = Get-MgGroup -Filter "resourceProvisioningOptions/Any(x:x eq 'Team')"
$teamscount = @($teams).Count
Write-Verbose "The number of teams is $teamscount" -Verbose

# Close Connection to MS Graph
Disconnect-MgGraph

A few caveats and notes

  • This isn’t a full working example, in my case I’m using Azure Automation Runbooks and they are very very particular about their outputs and object handling. I’m still working on my translation.
  • It assumes you have done the work to create a self-signed certificate, create the app registration, uploaded the certificate to the app registration *and* set it up in your automation account. (I might do a meta post on this as I found one blog post that had the wrong parameters for the cert generation and generated a cert file of format cer with a pfx extension…)
  • This is being written for an Azure Automation Account in PowerShell, remember to add the relevant modules that are needed. I was adding individual modules as I found them first but you will probably be quicker just using Microsoft.Graph – you will find it in the gallery. Otherwise for the above you will need Microsoft.Graph.Authentication, and Microsoft.Graph.Groups.
  • If your tenant is anything like ours then you will always get 100 as the count of teams, due to the way that the apis manage their output length.
  • The script doesn’t do anything useful but I thought it might help to see the filter syntax

References, Source Material and Inspiration

How life goes in circles

That a significant pointer would be found in a response on GitHub by Darrel Miller is quite fascinating. I met Darrel on the expo floor at Microsoft Ignite in Orlando in 2018 and only really because I was after some “Swag” and had to get a card stamped by various Product Managers and Architects on the Microsoft 365 stand. At the time I was up to my neck in Azure and trying my best to get away from SharePoint (and Microsoft 365) and my discussions with the people on those stands were all to try and get me to talk to Graph and get back in to SharePoint Development with the new SPFx thing.

So it’s taken me about 2 and a half years, but I’m finally getting there. Thankyou Darrel – check him out on twitter etc!

Passed DP-900: Microsoft Azure Fundamentals

alistairl, , Leave a comment

I’m pleased to say that I recently passed DP-900: Microsoft Azure Fundamentals. If you’ve come to this post via the home page then you’ll see that I recently passed DP-200 and DP-201 to achieve the Certified Data Engineer certification and as I had a discount voucher with 50% off an exam I decided to do another fundamentals exam.

Microsoft Certified: Azure Data Fundamentals
DP-900 Badge

Although my employer hadn’t asked, I decided to go for the set as a qualification for the Microsoft Partner Data Platform Competency. It appears that Microsoft are shifting away from the technical assessments that were delivered through partner university. This makes a bit of sense now that there are obvious public certifications available and while being a little more difficult, the fundamentals is more of a useful achievement.

From a personal milestone this is my 40th Microsoft Exam pass; way back before OneNote was a thing I started an exam ritual of creating a folder for the next exam I was targeting. In the small development company that was the first Microsoft Partner I worked at we used presentation binders for training packs – basically a ring binder with pockets in the front and spine for labelling. I would go through the ritual of creating a front cover for the binder, with my name, exam and “volume” number. I still go through this exercise and they have slowly counted up over the last year and a bit. Now my “exam process” tends to focus around OneNote but I still have a set of pipeline folders which have files related to an exam prep.

Microsoft Certification as a thing has ebbed and flowed through the years. Like a lot of things early in my career I just simply something because my employer asked me to. They wanted to get Microsoft Gold Partner and needed employees who had certifications. Thus started my journey with my first exam pass on April 19th 1996 which at the time of me writing this post is 25 years ago. That was also just under a year before I got married, so my long suffering wife has been with me for my entire certification journey!