How To Flush Microsoft Monitoring Agent Cache Using Azure Automation

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

Greetings from Bruno :smile:

The question of the day is how can we make sure our Log Analytics agent (aka Microsoft Monitoring Agent (MMA)) is always working properly to include an up to date configuration?

Have you ever experienced a situation in which the MMA service was running but doing really nothing? Similar to a grey agent when referring to System Center Operations Manager (SCOM)?

 

Why flushing

There are several reasons why we’d want to flush the MMA cache. The most common being:

  • Heartbeat failure
  • Invalid configuration
  • System workflows failure
  • Network or authentication issues
  • Health service issues (service is not running)

Inevitably, it almost always comes down to your MMA(s) not working as expected.

If you’re curious to learn more about how and when to flush the MMA cache, take a look at the How and When to Clear the Cache Microsoft article for more details.

 

How to flush

According to many online blogs and documentation, you have probably learned by now that flushing the MMA cache is quite easy. In a nutshell, here is what that entails:

  1. Stop the Microsoft Monitoring Agent service (service name: HealthService).
  2. Delete (or rename if you prefer) the C:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State folder.
  3. Start the Microsoft Monitoring Agent service.

The steps above can result in something boring when have to be repeated frequently, so why not leverage Azure Automation?

 

You can easily create an Automation Runbook that will do this for you. However, this operation could be a bit tricky. Since we need to manage resources on a guest OS in the local environment or possibly within 3rd party cloud environments, we’ll need to install and configure a few components on each machine. More specifically:

  1. The Microsoft Monitoring Agent itself.
  2. The Hybrid Runbook Worker (HRW).

In comparison to what we see in SCOM, where  flushing steps are executed as an agent task by the MMA,  we have the sandbox agent that is responsible thus making our effort easier.

 

Yessss, you got it … All you have to do is create an Azure Automation runbook that manages the flushing steps and that’s it.

 

Of course, this is just one use case. You could also decide to leverage other methods such as:

  • An Azure Automation runbook that call a scheduled task.
  • An Azure Automation runbook that picks the necessary components (i.e. scripts) from a storage account / share and copies it to the relevant computers.

In reference to the given scenario, here’s the script I will be using. Feel free to make any necessary change:

 

 

#Stopping Service Write-Output "Stopping the 'Microsoft Monitoring Agent' service ..." Stop-Service -name Healthservice -Force -Confirm:$false Write-Output "The 'Microsoft Monitoring Agent' service has been succesfully stopped." #Getting installation folder $installationPath = Get-ItemProperty -Path Registry::"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup" | Select-Object -expandproperty InstallDirectory Write-Output "The 'Microsoft Monitoring Agent' is installed in the '$installationPath' folder" #Removing Health Service State folder Write-Output "Deleting the 'Health Service State' folder ..." Remove-Item -LiteralPath "$installationPath\Health Service State" -Recurse:$true -Force -Confirm:$false Write-Output "The folder 'Health Service State' as been succesfully deleted." #Wait a bit before restarting the agent Start-sleep -Seconds 10 #Starting service Write-Output "Starting the 'Microsoft Monitoring Agent' service ..." Start-Service -name Healthservice -Confirm:$false Write-Output "The 'Microsoft Monitoring Agent' service has been succesfully started." #Logging runbook completion Write-Output "Runbook execution completed."

 

 

Keep in mind that the HRW depends on the Log Analytics agent which writes to an Azure Monitor Log Analytics workspace. The workspace is not only to monitor the machine, but also to download the components required for the Hybrid Runbook Worker.

 

I won’t get into details of deploying the HRW. For more information about the subject, you can check out the Deploy a Windows Hybrid Runbook Worker Microsoft article.

 

Once you have correctly configured your HRW, proceed to include the PowerShell script listed above into a new runbook. I can’t stress this enough: TEST!, TEST!, TEST! this out before implementing in Production.

 

  1. Import the PowerShell runbook. Here’s an example of what this looks like:

 

ImportRunbook.png

 

  1. Schedule it or run it manually as required against the preferred hybrid worker:

 

ScheduleRunbook.png

 
  1. Test! Test! Test!

 

What’s next? That’s all folks …

Thank you for reading and Happy flushing :lol:.

 

Disclaimer

The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.