Scom Agent Not Monitored Assignment Manual

Posted on by Sahn

Install Windows Agent Manually Using MOMAgent.msi

You can use MOMAgent.msi to deploy System Center Operations Manager agents from the command line or by using the Setup Wizard. Deploying agents from the command line is also referred to as a manual install. For a list of the supported operating system versions, see Microsoft Monitoring Agent Operating System requirements.

Before you use either method to manually deploy the agent, ensure the following conditions are met:

  • The account that is used to run MOMAgent.msi must have administrative privileges on the computer on which you are installing agent.

  • Each agent that is installed with the Setup Wizard or from the command line must be approved by a management group. For more information, see Process Manual Agent Installations.

  • If an agent is manually deployed to a domain controller and the Active Directory management pack is later deployed, errors might occur during deployment of the management pack. The Active Directory helper object is used by the Active Directory management pack on Windows domain controllers. The Active Directory Management Pack helper object is normally installed automatically when the agent is deployed using the Discovery Wizard. To prevent errors from occurring or recover from errors already occurring, you need to manually install the Windows installer package OomADs.msi on the affected domain controller. The file can be located on the domain controller in the %ProgramFiles%\Microsoft Monitoring Agent\Agent\HelperObjects folder.

  • A management group (or single management server) must be configured to accept agents installed with MOMAgent.msi or they will be automatically rejected and therefore not display in the Operations console. For more information, see Process Manual Agent Installations. If the management group or server is configured to accept manually installed agents after the agents have been manually installed, the agents will display in the console after approximately one hour.

MOMAgent.msi can be found in the Operations Manager installation media and in the following folder on a System Center 2016 - Operations Manager management server %ProgramFiles%\Microsoft System Center 2016\Operations Manager\Server\AgentManagement<platform>. For a version 1801 management server, the agent installation files can be found in the following folder - %ProgramFiles%\Microsoft System Center\Operations Manager\Server\AgentManagement<platform>.


The Application Performance Monitoring (APM) feature in System Center 2016 Operations Manager and version 1801 agent causes a crash with IIS Application Pools that are running under the .NET Framework 2.0 runtime. By default when the agent is installed on a Windows computer, the APM components are installed by default. To avoid issues and prevent installation of the APM components on target Windows servers when you deploy the agent, add the parameter

To deploy the Operations Manager agent with the Agent Setup Wizard

  1. Use local administrator privileges to log on to the computer where you want to install the agent.

  2. On the Operations Manager installation media, double-click Setup.exe.

  3. In Optional Installations, click Local agent.

  4. On the Welcome page, click Next.

  5. On the Important Notice page, review the Microsoft software license terms and then click I Agree.

  6. On the Destination Folder page, leave the installation folder set to the default, or click Change and type a path, and then click Next.

  7. On the Agent Setup Options page, you can choose whether you want to connect the agent to Operations Manager. When you connect the agent to Operations Manager, you can manually choose the management group that this agent will participate with in monitoring. If you do not select this option, the agent can still collect Application Performance Monitoring data locally. You can change your selection in the Monitoring Agent item in Control Panel.

  8. On the Management Group Configuration page, do the following:

    a. Type the name of the management group in the Management Group Name field and the (which server?) server name in the Management Server field.


    To use a gateway server, enter the gateway server name in the Management Server text box.

    b. Type a value for Management Server Port, or leave the default of 5723.

    c. Click Next.

  9. On the Agent Action Account page, leave it set to the default of Local System, or select Domain or Local Computer Account; type the User Account, Password, and Domain or local computer; and then click Next.

  10. On the Ready to Install page, review the settings and then click Install to display the Installing Microsoft Monitoring Agent page.

  11. When the Completing the Microsoft Monitoring Agent Setup Wizard page appears, click Finish.

To deploy the Operations Manager agent from the command line

  1. Log on to the computer where you want to install the agent by using an account with local administrator privileges.

  2. Open a command prompt as an administrator.

  3. Run the following command:


    Ensure you use the correct 32-bit or 64-bit version of MOMAgent.msi for the computer you are installing the agent on.


    USE_SETTINGS_FROM_AD={0|1}Indicates whether the management group settings properties will be set on the command line. Use 0 if you want to set the properties at the command line. Use 1 to use the management group settings from Active Directory.
    MANAGEMENT_GROUP=MGnameSpecifies the management group that will manage the computer.
    MANAGEMENT_SERVER_DNS=MSnameSpecifies the fully qualified domain name for the management server. To use a gateway server, enter the gateway server FQDN as MANAGEMENT_SERVER_DNS.
    MANAGEMENT_SERVER_AD_NAME=ADnameUse this parameter if the computer's DNS and Active Directory names differ to set to the fully qualified Active Directory Domain Services name.
    SECURE_PORT=PortNumberSets the health service port number.
    ENABLE_ERROR_REPORTING={0|1}Optional parameter. Use this parameter with "1" to opt in to error report forwarding to Microsoft. If you do not include this parameter, the agent installation defaults to "0", which opts out of error report forwarding.
    QUEUE_ERROR_REPORTS={0|1}Optional parameter. Use this parameter with "1" to queue error reports or with "0" to send reports immediately. If you do not include this parameter, the agent installation defaults to "0".
    INSTALLDIR=pathOptional parameter. Use this parameter if you want to install the agent to a folder other than the default installation path. Note that \Agent will be appended to this value.
    ACTIONS_USE_COMPUTER_ACCOUNT={0|1}Indicates whether to use a specified user account (0) or the Local System account (1).
    ACTIONSUSER=UserNameSets the Agent Action account to UserName. This parameter is required if you specified ACTIONS_USE_COMPUTER_ACCOUNT=0.
    ACTIONSDOMAIN= DomainNameSets the domain for the Agent Action account identified with the ACTIONSUSER parameter.
    ACTIONSPASSWORD= PasswordThe password for the user identified with the ACTIONSUSER parameter.
    NOAPM=1Optional parameter. Installs the Operations Manager agent without .NET Application Performance Monitoring. If you are using AVIcode 5.7, NOAPM=1 leaves the AVIcode agent in place. If you are using AVIcode 5.7 and install the Operations Manager agent by using momagent.msi without NOAPM=1, the AVIcode agent will not work correctly and an alert will be generated.
    AcceptEndUserLicenseAgreement=1Used to specify that you accept the End User License Agreement (EULA). This parameter is required when you use /qn to perform a fully silent installation of the agent.

Examples of installing the agent from the command line

The following examples show different ways in which you can install the MOMAgent.msi Windows Installer package manually from the command line. You can perform new installations of agents, upgrade agents from previous releases of Operations Manager, uninstall the agent, or change the configuration of an agent (such as the management group or management server associated with the agent).

Agent installation using a specific Action Account

The following example shows a fresh installation of an agent and uses a specific Action Account.

Agent installation using the Local System account

The following example shows a fresh installation of an agent and uses the Local System for the Action Account.

Agent installation with Active Directory integration and using a specific Action Account

The following example installs an agent by using Active Directory and a specific Action Account.

Agent installation with Active Directory integration and using the Local System account

The following example installs an agent by using Active Directory and the Local system account for the Action Account.

Agent upgrade from a previous release of Operations Manager

The following example upgrades an agent.

Uninstall the agent

The following example uninstalls an agent.

Next steps

Sometimes agents either will not “talk” to the management server upon initial installation, and sometimes an agent can get unhealthy long after working fine.  Agent health is an ongoing task of any OpsMgr Admin’s life.

This post in NOT an “end to end” manual of all the factors that influence agent health…. but that is something I am working on for a later time.  There are so many factors in an agent’s ability to communicate and work as expected.  A few key areas that commonly affect this are:

  • DNS name resolution (Agent to MS, and MS to Agent)
  • DNS domain membership (disjointed)
  • DNS suffix search order
  • Kerberos connectivity
  • Kerberos SPN’s accessible
  • Firewalls blocking 5723
  • Firewalls blocking access to AD for authentication
  • Packet loss
  • Invalid or old registry entries
  • Missing registry entries
  • Corrupt registry
  • Default agent action accounts locked down/out (HSLockdown)
  • HealthService Certificate configuration issues.
  • Hotfixes required for OS Compatibility
  • Management Server rejecting the agent


How do you detect agent issues from the console?  The problem might be that they are not showing up in the console at all!  Perhaps they might be a manual install that never shows up in Pending Actions?  Or a push deployment, that stays stuck in Pending actions and never shows up under “Agent Managed”.  Or even one that does show up under “Agent Managed” but never shows as being monitored… returning agent version data, etc.


One of the BEST things you can do when faced with an agent health issue… if to look on the agent, in the OperationsManager event log.  This is a fairly verbose log that will almost always give you a good hint as to the trouble with the agent.  That is ALWAYS one of my first steps in troubleshooting.


Another way of examining Agent health – is by the built in views in OpsMgr.  In the console – there is a view – Located at the following:




This view is important – because it gives us a perspective of the agent from two different points:

1.  The perspective of the agent monitors running on the agent, measuring its own “health”.

2.  The perspective of the “Health Service Watcher” which is the agent being monitored from a Management Server".


If any of these are red or yellow – that is an excellent place to start.  This should be an area that your level 1 support for Operations manager checks DAILY.  We should never have a high number of agents that are not green here.  If they aren't – this is indicative of an unhealthy environment, or the admin team not adhering to best practices (such as keeping up with hotfixes, using maintenance mode correctly, etc…

Use Health Explorer on these views – to drill down into exactly what is causing the Agent, or Health Service Watcher state to be unhealthy.


Now…. the following are some general steps to take to “fix” broken agents.  These are not in definitive order.  The order of steps really comes down to what you find when looking at the logs after taking these steps.


  • Start the HealthService on the agent.  You might find the HealthService is just not running.  This should not be common or systemic.  Consider enabling the recovery for this condition to restart the HealthService on Heartbeat failure.  However – if this is systemic – it is indicative of something causing your HealthService to restart too frequently, or administrators stopping SCOM.  Look in the OpsMgr event log for verification.


  • Bounce the HealthService on the agent.  Sometimes this is all that is needed to resolve an agent issue.  Look in the OpsMgr event log after a HealthService restart, to make sure it is clean with no errors.


  • Clear the HealthService queue and config (manually).  This is done by stopping the HealthService.  Then deleting the “\Program Files\System Center Operations Manager 2007\Health Service State” folder.  Then start the HealthService.  This removes the agent config file, and the agent queue files.  The agent starts up with no configuration, so it will resort to the registry to determine what management server to talk to.  From the registry – it will find out if it is AD integrated, or a fixed management server to talk to if not.  This is located at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Agent Management Groups\PROD1\Parent Health Services\ location, in the \<#>\NetworkName string value.  The agent will contact the management server – request config, receive config, download the appropriate management packs, apply them, run the discoveries, send up discovery data, and repeat the cycle for a little while.  This is very much what happens on a new agent during initial deployment.


  • Clear the HealthService queue and config (from the console).  When looking at the above view (or any state view or discovered inventory view which targets the HealthService or Agent class) there is a task in the actions pane - “Flush Health Service State and Cache”.  This will perform a very similar action to that above…. as a console task.  This will only work on an agent that is somewhat responsive…. if it does not work you need to perform this manually as the agent is really broken from communication with the management server.  This task will never complete, and will not return success – because the task breaks off from itself as the queue is flushed.


  • “Repair” the agent from the console.  This is done from the Administration pane – Agent Managed.  You should not run a repair on any AD-integrated agent – as this will break the AD integration and assign it to the management server that ran the repair action.  A “repair” technically just reinstalls the agent in a push fashion, just like an initial agent deployment.  It will also apply/reapply any agent related hotfixes in the management server’s \Program Files\System Center Operations Manager 2007\AgentManagement\ directories.


  • Reinstall the agent (manually).  This would be for manual installs or when push/repair is not possible.  This section is where the combination of options gets a little tricky.  When you are at this point… where you have given up, I find just going all the way with a brute force reinstall is the best way.  This means performing the following steps:
    • Uninstall the agent via add/remove programs.
    • Run the Operations Manager Cleanup Tool CleanMom.exe or CleanMOM64.exe.  This is designed to make sure that the service, files, and all registry entires are removed.
    • Ensure that the agent’s folder is removed at:  \Program Files\System Center Operations Manager 2007\
    • Ensure that the following registry keys are deleted:
      • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager
      • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService
    • Reboot the agent machine (if possible)
    • Delete the agent from Agent Managed in the OpsMgr console.  This will allow a new HealthService ID to be detected and is sometimes a required step to get an agent to work properly, although not always required.
    • Now that the agent is gone cleanly from both OpsMgr console and the agent Operating System…. manually reinstall the agent.  Keep it simple – install it using a named management server/management group, and use Local System for the agent action account (these will remove any common issues with a low priv domain account, and AD integration if used)  If it works correctly – you can always reinstall again using low priv or AD integration.
    • Remember to import certificats at this point if you are using those on the individual agent.
    • As always – look in the OperationsManager event log…. this will tell you if it connected, and is working, or if there is a connectivity issue.


To summarize…. there are many things that can cause an agent issue, and many methods to troubleshoot.  However – to summarize at a very general level, my typical steps are:

  1. Review OpsMgr event log on agent
  2. Bounce HealthService
  3. Bounce HealthService clearing \Health Service State folder.
  4. Complete brute force reinstall of the agent.

If it an external issue is causing the issue (DNS, Kerberos, Firewall) then these steps likely will not help you…. but those should be available from the OpsMgr event log.


Also – make sure you see my other posts on agent health and troubleshooting during deployment:

Console based Agent Deployment Troubleshooting table

Agent discovery and push troubleshooting in OpsMgr 2007

Getting lots of Script Failed To Run alerts- WMI Probe Failed Execution- Backward Compatibility

Agent Pending Actions can get out of synch between the Console, and the database

Which hotfixes should I apply-

Categories: 1

0 Replies to “Scom Agent Not Monitored Assignment Manual”

Leave a comment

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *