Move from Microsoft Monitoring Agent to Azure Monitor Agent

[jemrobinson]

🍓 Desired behaviour

We currently install Microsoft Monitoring Agent as a VM extension to enable update management.

This is deprecated and is being replaced byAzure Monitor agent. Additionally Microsoft Monitoring Agent does not support Ubuntu 22.04 and probably won't do in future.

Azure Monitor agent has more requirements than Microsoft Monitoring Agent. All VMs need a managed identity and enrolment in Update Management will require additional steps.

🚂 Possible workarounds, remediations or solutions

• For the moment using Microsoft Monitoring Agent and Ubuntu 20.04 is an acceptable workaround

[craddm]

MMA is deprecated from August 31st 2024, by which time we are expecting to be using a different codebase which shouldn't rely on this method of monitoring anyway. Possibly close.

Update 29th Jan: still decision is not to do this until/unless it proves necessary at a later date

[craddm]

Note that even MS suggest it will still function for 6-9 months after retirement date

The Log Analytics agent will be retired on August 31, 2024. You can expect the following when you use the MMA or OMS agent after this date.

Data upload: You can still upload data. At some point when major customer have finished migrating and data volumes significantly drop, upload will be suspended. You can expect this to take at least 6 to 9 months. You will not receive a breaking change notification of the suspension.
Install or reinstall: You can still install and reinstall the legacy agents. You will not be able to get support for installing or reinstalling issues.
Customer Support: You can expect support for MMA/OMS for security issues.

[craddm]

As we discovered recently, there is an Azure Policy that checks if the retiring log analytics agent is installed, and installs it if not. Turns out this appears to be a default policy applied by MS itself. We can directly change the policies on the dev subscription, so it's not being applied/controlled by IT. Seems that MS's own defaults don't seem to have quite caught up with the impending retirement of MMA/OMS.

[jemrobinson]

Could this be because the subscription was set up a while ago, before retirement was on the horizon?

[craddm]

I think the policy itself autoupdates, as it operates from the Microsoft cloud security benchmark definition. So when you try to look at the policy definition, it links you to that definition, which is versioned with the latest version number (57.35.0)

[craddm]

I'd add that some of the policy entries seem to have been changed from their default values already. e.g. Key Vault secrets should have an expiration date has been disabled, whereas by default it would be set to Audit. So the policy has all the default individual definitions but has historically been modified so that some items are not enforced.

[craddm]

Some further notes - I've now got this working on a few Linux VMs.

• Install AMA on VMs
• Create a Data Collection Rule
  • I generated some ARM templates using this tool
  • I manually created an ARM template from these templates
  • Can do this without the template too
• Associate resources with the DCR
• Create Data Collection Endpoint to associate with rule
  • The DCE is what links to a log analytics workspace
  • This also needs some private DNS links to be added
• Create a Maintenance Configuration
  • This sets when the maintenance takes place and what updates should be installed (e.g. security/critical only is possible)
• Assign resources to the Maintenance Configuration
  • Need to set VMs to -PatchMode "AutomaticByPlatform" to allow this to work

Doesn't seem to be necessary to turn on "periodic assessment", which periodically checks for updates. It simply checks for updates during the maintenance window and applies them where necessary

[JimMadge]

This is no longer needed for update management (because of #1885).

Could still add as a logging solution for Ubuntu > 20.04.
Will leave in 4.2.1 and remove from v5.