Reinstalling your SCOM agents with the NOAPM switch


This one comes from collaboration with my colleague Brian Barrington.

Because of the issues with SCOM 2016 and the default APM modules impacting IIS and SharePoint servers…..  (Read more about that issue HERE, HERE, and HERE)


Brian was looking for a way to easily remove the APM components from the deployed agents with minimal impact.

Normally, the guidance would be to uninstall the SCOM agent, then reinstall it from a command line installation using the NOAPM=1 command line parameter.  That could be a challenging task if you have hundreds or thousands of agents!


His idea?  Use my SCOM Agent Tasks MP here:


It has a class property in the state view called “APM Installed” to help you see which agents still have the APM components installed (which are installed by default)



It has a task called “Execute any PowerShell” 

In the task – Override to provide the command you want to run – such as:

To repair an existing SCOM 2016 agent, but remove the APM components:

msiexec.exe /fvomus "\\server\share\agents\scom2016\x64\MOMagent.msi" NOAPM=1

To upgrade an agent, such as upgrading the agent from SCOM 2012 to SCOM 2016:

msiexec.exe /i "\\server\share\agents\scom2016\x64\MOMagent.msi" NOAPM=1 AcceptEndUserLicenseAgreement=1


You just need to place the MOMAgent.msi file on a share that your domain computer accounts would have access to.  The agent will connect to the share as the Local System account, so you need to ensure these domain computer accounts have access at the share permission and NTFS permission.  For something simple like this, I generally just grant Everyone/Read, or Authenticated Users/Read.

The below image example is for a repair:



This performs a lightweight repair or upgrade (depending on which command line you choose) of the agent, but only changes the switch “NOAPM=1” which will result in leaving all other settings alone, and only removing the APM service and components!

We have gotten good feedback on the success of this process across hundreds of agents in a short time frame.  You can multi-select a lot of agents and run this task on many at a time.


Removing the APM MP’s

On another note – if you have no plans to use the APM feature in SCOM – you should consider removing those MP’s which get imported by default.  They discover by default a LOT of instances of sites, services, and instances of classes where APM components are installed on the agents.

MP’s to remove in SCOM 2016:

  • Microsoft.SystemCenter.DataWarehouse.ApmReports.Library (Operations Manager APM Reports Library)
  • Microsoft.SystemCenter.Apm.Web  (Operations Manager APM Web)
  • Microsoft.SystemCenter.Apm.Wcf  (Operations Manager APM WCF Library)
  • Microsoft.SystemCenter.Apm.NTServices  (Operations Manager APM Windows Services)
  • Microsoft.SystemCenter.Apm.Infrastructure.Monitoring  (Operations Manager APM Infrastructure Monitoring)
  • Microsoft.SystemCenter.Apm.Library (Operations Manager APM Library)
  • Microsoft.SystemCenter.Apm.Infrastructure (Operations Manager APM Infrastructure)

All of the above can be deleted.  However – in order to delete the Microsoft.SystemCenter.Apm.Infrastructure MP, you will need to remove a RunAs account profile association, then clean up the SecureReference library manually by deleting the reference.

In the Admin pane > Run As Configuration > Profiles, in the Data Warehouse Account.  On the RunAs accounts, you will need to remove the Operations Manager APM Data Transfer Service:


Then – manually export the Microsoft.SystemCenter.SecureReferenceOverride MP, and edit it using your favorite XML editor.  (Make a Backup copy of this FIRST!!!!!)

Delete the reference to the Microsoft.SystemCenter.Apm.Infrastructure MP.



Save this, then reimport the Microsoft.SystemCenter.SecureReferenceOverride MP.

At this point you can delete the final APM MP – Microsoft.SystemCenter.Apm.Infrastructure (Operations Manager APM Infrastructure)


Deleting that MP with manual edits too scary for you?

At a bare minimum – if you are not using the APM feature – you should disable the discoveries:



Then run Remove-SCOMDisabledClassInstance in your SCOM Command Shell, which will remove all these discovered instances that you don’t use.

Comments (27)

  1. Ian Blyth says:

    Excellent idea. I have added a link to this post from where I just show overriding one rule but this completes it with all the additional options.


  2. AlexP says:

    Is there any solid reason to actually keep APM on, given the fact that most public websites are monitored via other tools, and internal sites are often not that critical?

    1. Kevin Holman says:

      The best/only reason to leave APM components, is only if you wish to use APM in SCOM for your custom developed .NET applications, as a developer performance tool. You do not need it to use SCOM’s URL monitoring.

  3. staxkill says:

    Helpful articel as usual!
    Does the “lightweight upgrade/installation of the agent” consider any installed update rollup as the msi will be rerun without the msp from an UR?

    Best Regards,

    1. Kevin Holman says:

      From my testing – it appears the UR is unaffected – when I checked the versions of the UR files – they remained intact.

  4. Peter says:


    If you use the cmdlet Install-SCOMAgent (like we do via Orchestrator) how can you prevent the APM installation? It doesn’t seem to have that Parameter.

    1. rob1974 says:

      You can’t, but you can write a script that automatically removes APM after the installation as a last step (you need to check with get-scomagent if the agent has been deployed already). If you don’t have access to the computer directly you can wait (loop check in orchestrator) until this mp has discovered the agent and then call the scom task with a script.

  5. AlexLarkin says:

    Hi Kevin, (FYI)
    I have found that this APM issue not only affects SharePoint but most applications that are running the .NET v2.0 framework. It only appears after a reboot of the server.


  6. Hey!
    Is there any news about an Update Rollup 4 for SCOM 2016? Hopefully this is fixed in an new UR.


    1. Kiwifulla2 says:

      I’m not sure if this is a locale (US-NZ) thing for me or VL thing (?!), however firstly I had to add AcceptEndUserLicenseAgreement=1 to the command or else it failed?

      But more impotrtantly, if I use msiexec.exe /fvomus “\\server\share\agents\scom2016\x64\MOMagent.msi” NOAPM=1 AcceptEndUserLicenseAgreement=1, the repair only took about 2 seconds, reported (Event Log) that it was successful, but the Microsoft Monitoring APM service was still installed (yes I hit refresh :))?

      I then resorted to a /i instead of the /fvomus command which resolved it – e.g.:
      msiexec.exe /i “\\server\share\agents\scom2016\x64\MOMagent.msi” NOAPM=1 AcceptEndUserLicenseAgreement=1

      Any ideas why /fvomus didnt remove the APM service? I tested this on multiple machines. Also, do you not get prompted for the license agreement like I do?


      1. Kiwifulla2 says:

        Sorry I’ve upgraded a few more via SCCM and using this ((still needed that license piece) worked now: msiexec /fvomus “MOMAgent.msi” NOAPM=1 /q AcceptEndUserLicenseAgreement=1

        Still not sure why it didnt remove the APM service when I ran it manually via the command line as per my previous post. I didn’t have the /q there before and manually selected upgrade, so perhaps that was the issue.

        Apologies for the confusion.

        BTW, I read somewhere else that the UR needs the NOAPM=1 too. Is this required if UR3 is already on there, and I am reinstalling the main MOMAgent.msi with the NOAPM=1 switch first, which effectively at that point removed the APM stuff anyway?

        Step 1: msiexec /fvomus “MOMAgent.msi” NOAPM=1 /q AcceptEndUserLicenseAgreement=1
        Step 2: KB4016126-AMD64-Agent.msp NOAPM=1

        Appreciate your help Kevin!

        1. T_Schneider says:

          Right, I had the same problems as Kiwifulla2 and the package wouldn’t get installed. For me it turned out to be a problem with whitespaces in the path. Even though the complete path and package name got enclosed in quotes it wouldn’t execute. After putting the msi to a share without any spaces it started to work.
          For me it works without /q AcceptEndUserLicenseAgreement=1. Only the whitespaces have been the problem


          1. Kiwifulla2 says:

            Excellent, thanks Thorsten – that is it! My path did have a space in it (wrapped in quotes). Thanks for that!


  7. Steve E says:

    Does this only work with SCOM 2016 or will it work with 2012 as well? The reason I ask is because I cannot get this to change to NOAPM on 2012. The override runs for maybe 2 seconds and nothing changes. I tried using the “/i” and adding the “AcceptEndUserLicenseAgreement=1” to no avail. I also tried running the MOMAgent from and network folder and locally, but still not successful.

    1. rob1974 says:

      I only have issue with agent that have an OMS workspace as well.

  8. Mustafa Birdal Cicek says:

    Hi Kevin,
    Thank you for your very helpful article. We deployed SCOM 2016 UR4, and had got also this issue in SharePoint farm IIS servers.
    You wrote “Deleting that MP with manual edits too scary for you? — At a bare minimum – if you are not using the APM feature – you should disable the discoveries…”
    Do you speak here only about “Microsoft.SystemCenter.Apm.Infrastructure MP” or also other SCOM 2016 MPs which you listed above?
    Best Regards

    1. Birdal says:

      Hi Kevin,
      although we deleted all MPs related to APM as you defined above, the Agents staus are listed in Operation Console still in “APS Installed > true”?
      Is there any other step in this workaround?
      Best Regards

  9. Birdal says:

    Hi Kevin,
    although we deleted all MPs related to APM as you defined above, the Agents staus are listed in Operation Console still in “APS Installed > true”?
    Is there any other step in this workaround?
    Best Regards

  10. Brett says:

    Thank you so much for this! I was going the route of creating an SCCM package and config baseline but this was much faster with your MP. I have a huge criticism for the OM team enabling APM by default in 2016 when it wasn’t in 2012 especially since the APM agent broke SP and IIS. I was able to path this directly to my agent folder on the OM server and using an account with local admin rights on the agent servers and not the default action account.
    msiexec.exe /fvomus “\\SCOM01\d$\Program Files\Microsoft System Center 2016\Operations Manager\Server\AgentManagement\amd64\MOMagent.msi” NOAPM=1

    Thanks for the MP as well. That will be helpful for more things going forward.


  11. Paul says:

    We also deployed 2016 agents with UR4 – and the IIS/APM apppool crashing issue has occurred. The issue is still not fixed in scom2016 UR4!!!

    Happenned today following first restart of an application server where the 2016 agent and UR4 had been installed several weeks ago. We worked around by running agent install with NOAPM=1 which resolved the issue.

    Kevin, Please ask Microsoft to fix this once and for all!

    1. Kevin Holman says:

      Yes, I covered this in my UR4 update documentation. The issue is not complete fixed. This is why I recommend to use NOAPM switch on agent installs, and remove the APM management packs from SCOM. I don’t have a timeline for when this will be fixed, so the safe route is best.

  12. Amir Magdi says:

    Hi Kevin

    I removed all APM management packs and pushed SCOM agent to a new server but I still see the Monitoring APM service installed on the agent.
    even after removing the APM management packs do I still need to import the MP you created and run the task that disable the APM ?
    What if my environment doesn’t allow importing such customized MP’s, is there is other solutions doesn’t include uninstall and install the agent ?


    1. Kevin Holman says:

      Removing the APM packs has zero impact. If you want to remove the APM service from the agent – you must reinstall the agent with the -NOAPM switch. There is no other solution outside of reinstalling the agent. What kind of environment does not allow install of custom MP’s? If that was the case, then I’d say write your own using mine as a template. Without community MP’s or custom authored MP’s, SCOM will be very basic. I cannot imagine that scenario.

  13. Andy Eubanks says:

    Hi Kevin,
    We are ready to use APM with some of our systems and would like to know the proper way to add it back to agents that were deployed with the NOAPM=1 switch.
    Should we repair with NOAPM=0?
    or repair without the NOAPM switch?
    or is there another option than running a repair installation?


    1. Andy Eubanks says:

      Any guidance her would be appreciated.


      1. Kevin Holman says:

        I have not tested it. I’d assume a repair without the NOAPM might do it, but if that fails an uninstall/reinstall of the agent certainly will.

Skip to main content