The many faces of the Microsoft Monitoring Agent

Summary: Learn how the Microsoft Monitoring Agent is the one agent on your servers for all your hybrid cloud monitoring and management needs.

Hello, this is Graham Davies, a Microsoft Premier Field Engineer, and today I want to talk about a challenge we all face with multiple management and monitoring solutions. That is the number of agents that each of these applications require.

So, I have some great news for anyone who's looking to take advantage of System Center Operations Manager (SCOM) and the Operations Management Suite (OMS) for hybrid monitoring and management solution. Don’t be confused if you read about the OMS agent, the SCOM agent, or even the Log Analytics agent. The great news is there is only one agent—it is the Microsoft Monitoring Agent. And that means that you need just one agent on your servers for all your hybrid cloud monitoring and management needs.

Even better, when you decide to use Azure Automation for on-premises automation and install a hybrid runbook worker then, once again, it is the Microsoft Monitoring Agent that is being deployed.

Let’s start off with a customer who has SCOM 2012 R2 deployed. The version of the Microsoft Monitoring Agent that SCOM 2012 R2 uses is 7.1.10184.0. You can see the version in the SCOM console under Administration > Device Management > Agent Managed:

It's also in Control Panel > Microsoft Monitoring Agent:

Now, if we connect the server to OMS through the SCOM console, this does not update the Microsoft Monitoring Agent version that is displayed in the SCOM console - 7.1.10184.0.

However, one limitation of linking a server to OMS through SCOM is that currently the server can only connect to one OMS workspace. If you want to multi-home the server to multiple OMS workspaces, you need to install an updated version of the Microsoft Monitoring Agent as detailed in the blog post at OMS Log Analytics Agent multi-homing support. You then directly connect the Microsoft Monitoring Agent to OMS.

After you do this, you’ll see the version change in the SCOM console.

You’ll also see the Microsoft Monitoring Agent Properties dialog box in Control Panel update to include new tabs. For example, I have just done this for DC-01 below.

To complete the “migration” of the server from SCOM managed to direct attached, we still need to remove the server from SCOM. To do this, go to Administration > Operations Management Suite > Managed Computers > Add a Computer / Group.

Select the computer that we have just upgraded the Microsoft Monitoring Agent on, and then click Remove.

Add then, we need to add the OMS Workspace ID and on-boarding key details in Control Panel > Microsoft Monitoring Agent > Azure Log Analytics (OMS) tab.

 

 

Note: The version of the Microsoft Monitoring Agent from OMS today is 8.0.10900.0 although incremental changes could happen at any time.

One reason for this post is that I’m frequently  asked if the SCOM agent and the OMS agent can co-exist. Well, the great news is that they are one and the same thing! You can get all the benefits of SCOM + OMS with a single unified agent.

Graham Davies
Senior Premier Field Engineer

Comments

• Anonymous
  August 17, 2016
  So going forward, will patch updates for the MMA be part of SCOM update rollups or can they be published from WSUS?
  • Anonymous
    August 18, 2016
    Hi AdinWhen you follow the above process, the Microsoft Monitoring Agent doesn't disconnect from the SCOM Management Group. It still sends SCOM data to your SCOM management group without any interruption (other than when the service restarts). It just changes the way that the agent sends data to OMS.Directly attaching a Microsoft Monitoring Agent to OMS (as opposed to attaching through SCOM) just means that OMS data is now always sent directly to OMS. When the Microsoft Monitoring Agent is attached to OMS through SCOM then some OMS data goes via the Management Server. The table here shows how data is routed for SCOM attached versus Direct attached:https://azure.microsoft.com/en-us/documentation/articles/log-analytics-add-solutions/ Hope that helps. Let me know if I have misunderstood.RegardsGraham
  • Anonymous
    August 18, 2016
    Hi WilsonIt depends! If you have attached to OMS through SCOM (and hence have version 7.1.10184.0 of the Microsoft Monitoring Agent installed) then you'll need to apply the update rollups in the usual way. E.g. for agents pushed from the scom console, you can approve under pending management. For manually installed agents you'd need to manually apply the update or use WSUS \ an automation solution. If you have attached directly to OMS and have version 8.0.10900.0 of the Microsoft Monitoring Agent then that will be updated automatically through Azure. RegardsGraham
    • Anonymous
      August 18, 2016
      Hi Graham, thanks for the explanation. So for MMA v8.0.10900.0 agents configured to communicate directly with OMS.....that agent will automatically get updated by Azure? That's actually a bit of a concern as my company has strict change management processes in place. Any agent update or Windows service restart requires change approval and/or documentation. Is there a way to control this auto-update behavior? Can a maintenance window be defined somehow?
      • Anonymous
        August 22, 2016
        Hi WilsonApologies - let me clarify that after a chat I had with the Product Group.1. For direct attached agents, the update is done through Microsoft Update. 2. For Azure virtual machines on-boarded to OMS using the VM Extension, the agent is updated automatically be Azure. I'm going to ask the Azure team more about the automatic upgrade process and whether there is a way to control when the update takes place. It could well be the basis for another blog article.
• Anonymous
  August 17, 2016
  After you manually upgrade the Agent to the latest OMS agent (which allows for multi-homed), I believe you could still re-attach it to your SCOM environment afterwards, right?
  • Anonymous
    August 18, 2016
    Hi AdinWhen you follow the above process, the Microsoft Monitoring Agent doesn’t disconnect from the SCOM Management Group. It still sends SCOM data to your SCOM management group without any interruption (other than when the service restarts). It just changes the way that the agent sends data to OMS.Directly attaching a Microsoft Monitoring Agent to OMS (as opposed to attaching through SCOM) just means that OMS data is now always sent directly to OMS. When the Microsoft Monitoring Agent is attached to OMS through SCOM then some OMS data goes via the Management Server. The table here shows how data is routed for SCOM attached versus Direct attached:https://azure.microsoft.com/en-us/documentation/articles/log-analytics-add-solutions/ Hope that helps. Let me know if I have misunderstood.RegardsGraham
• Anonymous
  August 29, 2016
  Hi Graham,I'm having a hard time understanding the material presented here and wanted to see if you could clarify. Here is the sequence of actions required to upgrade to MMA 8 and maintain SCOM connectivity as I read them:1) Install MMA 82) Remove the computer(s) from SCOM3) Manually, through the GUI, add the Workspace ID and key to MMA on every computerThis leaves me with some questions:- Why must the computer be removed from SCOM? How does the MMA agent continue to be linked with the SCOM workplace after it is removed?- Are there any options for automating or scripting the addition of the workspace information from step 2?- How would we deploy MMA 8 to a brand new computer that has never been SCOM-managed? Would we have to install MMA from SCOM first, then deploy MMA 8 every time?Thanks
  • Anonymous
    September 02, 2016
    The comment has been removed
• Anonymous
  November 10, 2016
  Can we still Control OMS Reporting from SCOM when we use MMA instead of MOM agent?